jsr366-experts@javaee-spec.java.net

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

From: Linda DeMichiel <linda.demichiel_at_oracle.com>
Date: Mon, 05 Oct 2015 14:12:42 -0700

Thanks, Jason.

I'd really like to hear from others regarding the points
made here as well.

-Linda

On 10/5/15 1:48 PM, Jason Greene wrote:
>
>> 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.

Just a point on clarification on this. The EJB spec has never
required transaction interoperability between vendors' products:
it has always been optional

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