Linda DeMichiel <linda.demichiel_at_oracle.com> wrote on 05/10/2012 02:50:43
PM:
> 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.
Apologies for the late reply. In general, I'm in favor of making optional
some of the less used parts of the platform, so consider this a +1.
However, we all need to agree on what this means as there are intended
compliance implications. I agree with Jason that interop is important
and that there are certain QoS characteristics that go along with
RMI-IIOP.
> 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.
> * Implementing the required support is seen as an unnecessary
> burden on Java EE implementors.
> * 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.
The first bullet above implies more than just making RMI-IIOP optional
to me. It says that the RMI programming model itself with its
corresponding QoS has been replaced by web services / REST when
interop is required.
The second bullet is not quite true. It's an implementation burden
for any _new_ Java EE implementor, but any existing vendor who already
supports RMI-IIOP is not likely to remove support from their
existing customers just because it's optional now. As usage drops to
zero, then existing vendors can stop supporting it, but it's still
a non-zero effort in the meantime.
There's more than a perception that RMI-IIOP is heavyweight. There's
a very noticeable memory footprint that goes with an ORB, OTS, INS,
and CSIv2 and not everyone will require this. So making this optional
is a definite improvement for a large customer segment.
> Removing this requirement would mean that an implementation of the
> Platform would still be required to support remote access to EJBs, but
> would not be required to use IIOP to do so. That is, we would be
> removing requirements that provide interoperability across products,
> but would not be removing requirements that require support for remote
> access within a single product, since other protocols could be used.
This is where we start to get into ironing out a common understanding
of what is truly being proposed. The first bullet implies that all of
the RMI programming model is optional and you just annotate your web
profile EJBs with @WebService if you want to expose remote access (or
use REST). I like the idea of provisioning in web services remoting
function without also being required to provide RMI remoting function.
The way the spec is today, vendors are technically in violation of
the spec if they provide one without the other. However, the previous
paragraph implies that RMI stays and it's only the CORBA interop
(ORB, OTS, INS, CSIv2) requirements that disappear.
Let's assume for the moment that just the CORBA interop requirements
go away and we keep the RMI programming model. Will transaction and
security context flows still be required? What about remote JNDI
lookup? If we have no portability requirements, are we confident
that CTS can validate compliant behavior when the client and the
server are vendor specific?
From my perspective, RMI, RMI-IIOP, and all the OTS, CSIv2, INS
related aspects and qualities of service should be tied together.
I don't mind them being made optional and vendors can implement
RMI or not as they choose, but if they choose to implement RMI,
a compliant and interoperable set of QoS should be part of the
package.
If push came to shove, I could accept non-interoperable RMI iff:
1. RMI is separately optional (e.g. you can deliver web profile +
JAX-WS + EJBs as JAX-WS components without requiring RMI,
MDBs, etc.)
2. a non-interoperable RMI is required to support the same QoS
as RMI-IIOP based RMI.
While you're at it, how about making MDBs optional so I can
deliver web profile + MDBs, but without web services and RMI
if I want?
Thanks,
Jim Knutson
WebSphere Java EE Architect