Response inline.
On 5/10/12 2:50 PM, Linda DeMichiel wrote:
>
> The Java EE Platform and EJB specifications currently require the
> capability of using RMI-IIOP to export EJB components and to access EJB
> components over a network. This requirement enables interoperability
> between Java EE products.
>
> It has been suggested that we consider removing the requirement for
> such interoperability support from the Java EE Platform and EJB
> specifications.
Red Hat is strongly against removing Java EE interoperability, and by
extension IIOP until a suitable replacement is available. We also
believe that making it optional is effectively the same as removing it,
since there is no longer guaranteed portability.
>
> There are several reasons behind this proposed change:
>
> * RMI/IIOP has been largely superseded by modern web technologies
> that provide interoperability support, such as SOAP and REST.
> Hence, few developers are currently relying on RMI/IIOP for this purpose.
The problem is that SOAP and REST are not a complete and adequate
replacement for all interop scenarios. Sure they are a better fit for
public facing and B2B interactions, but IIOP is superior if you want
real Java EE container to Java EE container interop. I can take a remote
EJB RMI/IIOP application and run it in on any EE full profile certified
server with trivial adjustments. Security and Transaction calls
propagate as expected. Now to do the same with JAX-RS, or JAX-WS, I have
to completely rearchitect the entire application, both client and server
elements. Sure we make that pretty easy with good APIs and tools, but
still the entire model changes. You can no longer involve two calls in
the same transaction (using UserTransaction), so you have to restructure
everything into a coarser representation. You also can't distribute
calls using JTS and CSIv2 (e.g. server1 -> server 2 -> server 3) and
have everyone participate as if it was local.
Another gap that would be created is lack of a high performance interop
solution. Processing clear text XML and/or JSON is typically an order of
magnitude slower than a binary transport like IIOP. Right now with IIOP
its possible to have fast native clients communicating efficiently with
any full EE server.
That said, I am sure we all can agree the future of IIOP is uncertain.
There is certainly a lot about it that could have been done better, but
it does do its job. Ultimately it's the above capabilities (not the
protocol) that are important. We have customers and users relying on
this. We would support a standardization effort on a replacement
protocol that achieved the same goals.
* Implementing the required support is seen as an unnecessary
> burden on Java EE implementors.
I am extremely sympathetic to this, as it is one of the hardest ares of
the TCK to pass. However, the reason it's hard is precisely so we can
have real interop between application servers.
> * There is a perception that this requirement makes Java EE seem
> heavyweight at a time when we're trying to appeal to developers
> who want a lightweight solution.
I completely agree on this point, but this is exactly why we have the
web profile. I think its worth pursuing other avenues to this, like
perhaps more flexible usage of profiles. As an example, we could require
all vendors implement IIOP, but allow vendors to require it be
explicitly enabled in their "full" profile if they choose.
In summary, we are against making this optional *to implement* in the
full profile, but are supportive of it being optional for users *to
enable*. We believe Java EE interoperability is important and should
remain. We are open to and will support any other approach to achieve
the same benefits.
Thanks
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat