> On Oct 22, 2015, at 2:24 PM, Kevin Sutter <sutter_at_us.ibm.com> wrote:
>
> Jason Greene <jason.greene_at_redhat.com> wrote on 10/21/2015 03:27:03 PM:
>
> > From: Jason Greene <jason.greene_at_redhat.com>
> > To: jsr366-experts_at_javaee-spec.java.net
> > Date: 10/21/2015 03:28 PM
> > Subject: [jsr366-experts] Re: Proposed Optionality of CORBA / IIOP interop
> >
> >
> > > On Oct 12, 2015, at 4:41 PM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> > >
> > > Jason Greene wrote on 10/05/15 13:48:
> > >>
> > >>> On Oct 1, 2015, at 2:00 PM, Linda DeMichiel <linda.demichiel_at_oracle.com>
> > >>> wrote:
> > >>
> > >> -snip-
> > >>>
> > >>> We believe it is time to deemphasize CORBA support and make it optional in
> > >>> the platform. The first step here would be to make it Proposed
> > Optional in
> > >>> Java EE 8. CORBA support is a required component of Java SE 8,
> > which would
> > >>> not change. The additional requirements related to CORBA in Java EE 8,
> > >>> such as the use of RMI-IIOP with EJB, would be made Proposed Optional.
> > >>>
> > >>> Since the EJB 2.x remote interfaces (EJBHome and EJBObject interfaces)
> > >>> require the use of RMI-IIOP, we propose that support for the EJB2.x client
> > >>> view (EJBHome, EJBObject, EJBLocalHome, EJBLocalObject) be made Proposed
> > >>> Optional as well, since it was superseded by the simplications of EJB 3.0
> > >>> that were made as part of Java EE 5. Note that support for remote EJBs is
> > >>> still required, since the remote interfaces defined by EJB 3.0 are not
> > >>> required to use CORBA. In addition, EJBs can be used to provideboth REST
> > >>> and SOAP-based web services for remote access.
> > >>>
> > >>> Please let us know whether you support this proposed change or not.
> > >>
> > >> The concern we have with removing this requirement is that there
> > is really no
> > >> equivalent alternative that achieves the same level of remote EJB interop
> > >> between application servers. With RMI-IIOP, you get transaction propagation
> > >> (via JTS), a wire optimized format, and it’s minimally invasive.
> > With JAX-RS
> > >> and JAX-WS you essentially have to architect your application around the
> > >> technology, and are limited in what you can do since these approaches
> > >> encourage a high level of decoupling. In some cases this is exactly how it
> > >> should be done, but in others all you care about is that you can take a
> > >> remote EJB client and point it somewhere.
> > >
> > > We aren't seeing a lot of new applications choosing to use remote EJBs as
> > > a way to interoperate with products from multiple vendors. If you have
> > > data in this area, please share it.
> >
> > Over the last several years we have seen a lot of customers
> > migrating from two other prominent Java EE Full Profile platforms to
> > Red Hat and EAP. Typically they do this with one application at a
> > time rather than trying to boil the ocean. And they also want to
> > stay on the latest and greatest versions of EE. As we expect many
> > more customers to move to EAP, and greenfield development using Java
> > EE still happens, we believe that IIOP support is a necessity. We
> > also still see new applications picking @Remote over JAX-WS and JAX-
> > RS because Java serialization is easier. Converting to IIOP from a
> > native protocol @Remote implementation is fairly trivial, so its a
> > very low effort mechanism to achieve EE to EE interop.
> >
> > Obviously the door can swing both ways, but we feel the
> > compatibility benefit to the user leads to an overall better ecosystem.
> >
> > Perhaps a better solution, instead of removing wire compatibility
> > from the full profile, is to introduce a new "Web Plus” profile that
> > removes this support. Then the market can decide which is valuable,
> > and at a time of its choosing.
> >
>
> Jason, nobody is proposing that CORBA/IIOP interop be removed from the spec -- just make it an optional portion of the spec.
Sure but compatibility is only as strong as the weakest link. Making it optional effectively ends compatibility, or at least the reliance of it, which is the reason we don’t just make everything in Java EE optional.
> And, actually, at this point, it is only "proposed optional" for Java EE 8.
I don’t think we should propose something as optional unless we truly want to phase something out. I mean it is the “pruning” process after all.
> I think one of the main reasons behind this request is to remove this "hurdle" for any new prospective application servers that want to be Java EE compliant. Currently, if an application server wants to be Java EE compliant, they have to provide this CORBA / IIOP interop and that's a major hurdle. Especially for such an archaic architecture. I can fully understand and appreciate your arguments for keeping this capability in place. But, I wouldn't expect any existing application servers to remove the capability just because it becomes "optional". It's just to remove the hurdle for new application servers that want to play in this space.
I’m not so sure I agree that the hurdle is all that high. I’d argue its much harder to implement a JMS 2 messaging server then it is to grab one of the open source ORBs (including the one within the JDK, which even includes RMI-IIOP support) and write bindings for it. I am sympathetic to the new vendor argument, but that’s why we have the web profile.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat