-- Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR Skype werner.keil | Google+ gplus.to/wernerkeil * Chip-to-Cloud Security Forum: September 19 2012, Nice, French Riviera. Werner Keil, JCP Executive Committee, JSR-321 EG Member will present "Trusted Computing API for Java™" * Eclipse Day Delft: September 27 2012, Delft, Netherlands. Werner Keil, Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Triple-E class Continuous Delivery with Hudson, Maven and Mylyn" On Fri, Jul 20, 2012 at 12:00 AM, Jim Knutson <knutson_at_us.ibm.com> wrote: > 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 > >
(image/gif attachment: 326.gif)