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.
Certainly there are existing applications using CORBA and IIOP that will need
to be supported for quite some time. If CORBA support is made Proposed
Optional in Java EE 8 in 2017, it would be made Optional in Java EE 9 in
approximately 2022, and existing vendors might ship a product without
CORBA support in 2024, which might be deployed by customers with existing
applications in 2025. Given the low level of use by new applications,
this seems like plenty of time to transition to alternatives for
interoperability.
I strongly suspect most existing vendors to keep providing CORBA support as
long as they have customers using it, so even the above timeline is unlikely
to impact most existing users of CORBA.
> We would really like to see a spec defined wire protocol that full profile
> platforms must support (in addition to their native protocols) that could
> serve as a substitute before dropping IIOP support as a requirement.
Feel free to propose such a spec. It would be interesting to see what level
of support there is for it in the community. If we're surprised and it sees
significant support, we would likely modify our plans. There's plenty of time
to gather this data before CORBA support would actually be made Optional.