[javaee-spec users] [jsr366-experts] Re: Proposed Optionality of CORBA / IIOP interop

From: Kevin Sutter <>
Date: Thu, 22 Oct 2015 14:24:01 -0500

Jason Greene <> wrote on 10/21/2015 03:27:03 PM:

> From: Jason Greene <>
> To:
> Date: 10/21/2015 03:28 PM
> Subject: [jsr366-experts] Re: Proposed Optionality of CORBA / IIOP
> > On Oct 12, 2015, at 4:41 PM, Bill Shannon <>
> >
> > Jason Greene wrote on 10/05/15 13:48:
> >>
> >>> On Oct 1, 2015, at 2:00 PM, Linda DeMichiel
> >>> 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
> >>> such as the use of RMI-IIOP with EJB, would be made Proposed
> >>>
> >>> Since the EJB 2.x remote interfaces (EJBHome and EJBObject
> >>> require the use of RMI-IIOP, we propose that support for the EJB2.x
> >>> view (EJBHome, EJBObject, EJBLocalHome, EJBLocalObject) be made
> >>> 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
> >>> required to use CORBA. In addition, EJBs can be used to provideboth
> >>> 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
> >> between application servers. With RMI-IIOP, you get transaction
> >> (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
> >> 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
> >> remote EJB client and point it somewhere.
> >
> > We aren't seeing a lot of new applications choosing to use remote EJBs
> > a way to interoperate with products from multiple vendors. If you
> > 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. And, actually, at
this point, it is only "proposed optional" for Java EE 8. 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.

Kevin Sutter
WebSphere Java EE Architect

> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat