> 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 EJB 2.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 provide both 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 T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat