+1 for CORBA optionality.
cheers,
adam
> On 01.10.2015, at 22:42, users-request_at_javaee-spec.java.net wrote:
>
> Table of contents:
>
> 1. [javaee-spec users] [jsr366-experts] Proposed Optionality of CORBA / IIOP interop - Linda DeMichiel <linda.demichiel_at_oracle.com>
> 2. [javaee-spec users] [jsr366-experts] Re: Proposed Optionality of CORBA / IIOP interop - Jeff Genender <jgenender_at_savoirtech.com>
> 3. [javaee-spec users] [jsr366-experts] Re: Proposed Optionality of CORBA / IIOP interop - Antonio Goncalves <antonio.goncalves_at_gmail.com>
>
>
> From: Linda DeMichiel <linda.demichiel_at_oracle.com>
> Date: 1. Oktober 2015 um 21:00:39 MESZ
> To: jsr366-experts_at_javaee-spec.java.net
> Subject: [javaee-spec users] [jsr366-experts] Proposed Optionality of CORBA / IIOP interop
>
>
> 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
>
>
>
> From: Jeff Genender <jgenender_at_savoirtech.com>
> Date: 1. Oktober 2015 um 21:13:46 MESZ
> To: jsr366-experts_at_javaee-spec.java.net
> Subject: [javaee-spec users] [jsr366-experts] Re: Proposed Optionality of CORBA / IIOP interop
>
>
> I totally agree… its time for CORBA to go…
>
> Jeff
>
>
>> On Oct 1, 2015, at 1:00 PM, Linda DeMichiel <linda.demichiel_at_oracle.com> wrote:
>>
>> 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
>
>
>
>
> From: Antonio Goncalves <antonio.goncalves_at_gmail.com>
> Date: 1. Oktober 2015 um 22:17:06 MESZ
> To: jsr366-experts_at_javaee-spec.java.net
> Subject: [javaee-spec users] [jsr366-experts] Re: Proposed Optionality of CORBA / IIOP interop
>
>
> +1 of course
>
> Antonio
>
> On Thu, Oct 1, 2015 at 9:13 PM, Jeff Genender <jgenender_at_savoirtech.com> wrote:
> I totally agree… its time for CORBA to go…
>
> Jeff
>
>
> > On Oct 1, 2015, at 1:00 PM, Linda DeMichiel <linda.demichiel_at_oracle.com> wrote:
> >
> > 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
>
>
>
>
> --
> Antonio Goncalves
> Software architect, Java Champion and Pluralsight author
>
> Web site | Twitter | LinkedIn | Pluralsight | Paris JUG | Devoxx France
>
>
> End of digest for list users_at_javaee-spec.java.net - Thu, 01 Oct 2015
workshops.adam-bien.com
effectivejavaee.com
blog.adam-bien.com
airhacks.news
Author of:
"Real World Java EE Night Hacks”,
"Real World Java EE Patterns— Rethinking Best Practices"