Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jakartaee-platform-dev] R: R: Help - The future of jakarta ejb vs RMI-IIOP

Hi Ivar,

thank a lots for the respone.


regards
Angelo Rubini

Da: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> per conto di Ivar Grimstad via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Inviato: giovedì 26 ottobre 2023 09:09
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] R: Help - The future of jakarta ejb vs RMI-IIOP
 
Hi Angelo,

Yes, sorry for the wait :)

Which protocol to use for remote invocations is, and has always been up to the implementor. Support for CORBA/RMI-IIOP is today optional, hence removing the requirement for it does not change anything.
But the technology isn´t going away just because it is not required any longer by a specification. The vendors are free to support this and any other protocols for as long as they whish.

It was discussed in the Jakarta EE Platform call this week. If you still need more clarification, I suggest joining that call next week and bringing it up on the agenda.

Ivar



Hi All, any feedback about this topic???

Regards
Angelo


Da: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> per conto di Angelo Rubini via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Inviato: martedì 24 ottobre 2023 13:15
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Angelo Rubini <angelorubini@xxxxxxxxxx>
Oggetto: [jakartaee-platform-dev] R: Help - The future of jakarta ejb vs RMI-IIOP
 
ok thanks for the reply. 
But if you want to leave the choice of the rmi protocol to the application server provider,
perhaps it is the case that the full platform certification obliges the various providers
to have distributed and transactional remote calls and that
they support all types of propagation attributes of a inbound and outbound transaction:
REQUIRED,REQUIRED_NEW,MANDATORY,SUPPORT AND NOT_SUPPORT).
It is strange to have AS that are full platform certified like openliberty,
but which then do not fully support transactional remote calls see
(https://www.ibm.com/docs/en/was-liberty/zos?topic=liberty- using-enterprise-javabeans-remote-interfaces)

What do you think?

Regards,
Angelo


Da: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> per conto di Ivar Grimstad via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Inviato: martedì 24 ottobre 2023 11:52
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] Help - The future of jakarta ejb vs RMI-IIOP
 
Hi,

The Jakarta EE Specification Committee has passed a resolution to not allow optional features in the Platform specification.
Since CORBA, IIOP, and IDL are optional features today, we have two choices:

1. Make them required
2. Remove them

Since they are optional today, I don't see them being made required again, so removal is the likely thing to happen.

That said, even if a feature is no longer part of the platform does not mean that it goes away automatically from all implementations. Remember they are optional today, so it is likely only a subset of implementations supporting it.
I guess that the implementations supporting these features today will continue to do so at least for a while. But that is a question for the vendor providing the implementation you are using.

Ivar

On Tue, Oct 24, 2023 at 9:28 AM Angelo Rubini <angelorubini@xxxxxxxxxx> wrote:
Hi Ivar,

my doubt, arises from the fact that one of the great features of jakarta ee is remote transactional 
calls distributed between multiple ejbs
(based on rmi-iiop, both Glassfish(sun orb) and Openliberty(yoko orb) use iiop for remote and transaction
calls between ejbs).
If the plan is want to remove rmi-iiop(corba) from jakarta ee(version 11),

how will ensure and continue to use distributed transactional remote calls (inbound and outbound)
between multiple ejbs?

The jakarta ee 11 plan is, remove all spec marked optional and in this slide the removed items in list are:
  • corba, rmi-iiop, idl
https://speakerdeck.com/ivargrimstad/prepare-for-jakarta-ee-11?slide=19
it's correct?

Thanks
Angelo



Da: Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Inviato: martedì 24 ottobre 2023 08:14
A: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: jakartaee-spec-project-leads@xxxxxxxxxxx <jakartaee-spec-project-leads@xxxxxxxxxxx>; Angelo Rubini <angelorubini@xxxxxxxxxx>
Oggetto: Re: [jakarta.ee-spec] R: Heads-up: Get your specs ready for release review by 2024-01-30 (94 days from now)
 
Hi Angelo,

Thanks for your interest in Jakarta EE!
I'll try to quickly provide some input on your questions here, but please state any follow-up questions on the Jakarta EE Platform mailing list: https://accounts.eclipse.org/mailing-list/jakartaee-platform-dev.

1. The removal of Managed Beans does not relate to CORBA/RMI-IIOP. It is just about the removal of the component model that CDI supersedes. Managed Beans was deprecated in Jakarta EE 10, so this removal follows that.

2. Support for CORBA as an application service has been optional since Jakarta EE 9. See section 5.12 of the Jakarta EE Platform Specification (https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#a1385).
If you think more clarification is needed, I suggest bringing it up with the Jakarta EE Platform project.

Hope this helps!

Ivar

On Mon, Oct 23, 2023 at 5:48 PM Angelo Rubini via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:
Hi All,

if it is planned to remove corba&rmi-iiop from jakarta ee 11, 
how will the ejb components make remote and transactional calls distributed between
both inbound and outbound ejbs?
 
In the slide(
https://speakerdeck.com/ivargrimstad/prepare-for-jakarta-ee-11-af58e464-eeb9-49d7-a7ae-8c39749455f3?slide=17)

presented at EclipseCon 2023,

it is highlighted how Managed Beans 2.0 will be removed and replaced by CDI.
How do you remove corba&rmi-iiop without knowing what it will be replaced with,
to continue having remote transactions calls between distributed ejbs ?
To date there are still many software that use,
work and continue to be developed by having remote calls between EJBs with distributed transactions....

Thanks
Angelo Rubini


Da: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> per conto di Edward Burns via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Inviato: mercoledì 18 ottobre 2023 18:22
A: jakartaee-spec-project-leads@xxxxxxxxxxx <jakartaee-spec-project-leads@xxxxxxxxxxx>; Edward Burns via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Edward Burns <Edward.Burns@xxxxxxxxxxxxx>
Oggetto: [jakarta.ee-spec] Heads-up: Get your specs ready for release review by 2024-01-30 (94 days from now)
 

On 2023-08-03, Ed wrote:

 

Executive Summary

 

At the platform project weekly meeting on 2023-07-25, we put a stake in the ground to say that all Jakarta EE 11 component specs should be ready to start their release review by 2024-01-30 at the latest.

 

Details

 

Now that we have received the plans, and the plans have been approved by the Specification Committee, it is time to get started working toward a release. To deliver Jakarta EE 11 on time, we would like all component specifications to be ready for release review by 2024-01-30. Please don't hesitate to let us know at the earliest time if this deadline is not achievable.

 

This date was picked to give component specs that are heavily exposed to the Java SE 21 release sufficient time after that release to tie up all their SE 21 exposures.

 

If you can get your spec done before 2024-01-30, please do.

 

Thanks,

 

Ed

 

Nearly 90 days have elapsed. How’s it going? I hope you are all making progress toward getting your specs ready for release review.  I want to bring your attention to the new Spec versioning, change, and deprecation process: Jakarta EE Specification Versioning, Change, and Deprecation Process | The Eclipse Foundation.  Please consider this as you author your spec updates for EE 11.

 

Thanks,

 

Ed

 

 

| edburns@xxxxxxxxxxxxx | office: +1 954 727 1095

| Calendar Booking: https://aka.ms/meetedburns

|

| Please don't feel obliged to read or reply to this e-mail outside

| of your normal working hours.

|

| Reply anonymously to this email: https://purl.oclc.org/NET/edburns/contact

_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec


--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration. 



--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration. 

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev


--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration. 


Back to the top