Hello,
I’d support this proposed change. Since around 2 years, I do not met CORBA and EJB 2.x applications in the
customer field. So for me it’s absolutely valid to mark this technologies as optional in JavaEE 8.
Regards, Markus
oparco - open architectures & consulting
>
>
>>
>>> Am 01.10.2015 um 21:00 schrieb Linda DeMichiel <linda.demichiel_at_oracle.com>:
>>>
>>> When CORBA support was first added to Java SE, distributed objects
>>> were a popular way to structure applications, and CORBA provided a
>>> standard protocol to interact with non-Java applications as an
>>> alternative to the Java-specific JRMP protocol used by RMI. This was
>>> a natural fit for EJB, which started as a distributed object
>>> technology for enterprise applications, and thus CORBA support was a
>>> required part of Java EE.
>>>
>>> The industry has learned much from CORBA and has since moved on, first
>>> to SOAP web services and most recently to REST web services. REST web
>>> services generally provide a better way to interoperate between
>>> distributed components of an application, and between applications
>>> written in multiple languages.
>>>
>>> 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.
>>>
>>> thanks,
>>>
>>> -Linda
>>
>