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


On Tue, Nov 7, 2023 at 11:31 AM Angelo Rubini via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
Hi all,

continue on this topic 🙂.....

On Twitter i found this paper " Towards Modern Development of Cloud Applications" (from Google) it's interesting beacause, they mention the limitations of microservices and their solution to solve them.
And in the proposed solution paragraph they mention remote and local call management execution components and runtimes and their optimization and distribution, and it seems to me that they are remaking what ejbs and application servers are...
Aside from reading, it makes me think that this could be further food for thought in the Jakarta community and in removing the distributed programming model of EJBs in future releases, don't you think?

+1 for considering all possibilities for future distributed systems!

I looked for a link to the (Sun) JINI specification and could find some copies but not the original.  I had only read the specification but didn't actually use it, so I don't really know why Jini didn't get more exposure and use.  https://www.infoworld.com/article/2076783/sun-opens-jini-spec-for-review.html is article about it when it first came out and https://www.amazon.com/Jini-Specifications-Edited-Ken-Arnold/dp/0201726173 is a book written about it from one of founders.
 

Thanks for sharing!

Scott
 
Best 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: lunedì 6 novembre 2023 09:58
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
 
Yes, that's it! 

On Sat, Nov 4, 2023 at 7:04 PM Angelo Rubini <angelorubini@xxxxxxxxxx> wrote:
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



On Thu, Oct 26, 2023 at 8:56 AM Angelo Rubini via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
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. 



--

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

Back to the top