Skip to main content

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

Hi All, any feedback about this topic???


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:
It is strange to have AS that are full platform certified like openliberty,
but which then do not fully support transactional remote calls see
( using-enterprise-javabeans-remote-interfaces)

What do you think?


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

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.


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
it's correct?


Da: Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
Inviato: martedì 24 ottobre 2023 08:14
A: Jakarta specification discussions <>
Cc: jakartaee-spec-project-leads@xxxxxxxxxxx <jakartaee-spec-project-leads@xxxxxxxxxxx>; Angelo Rubini <angelorubini@xxxxxxxxxx>
Oggetto: Re: [] 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:

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 (
If you think more clarification is needed, I suggest bringing it up with the Jakarta EE Platform project.

Hope this helps!


On Mon, Oct 23, 2023 at 5:48 PM Angelo Rubini via <> 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(

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....

Angelo Rubini

Da: <> per conto di Edward Burns via <>
Inviato: mercoledì 18 ottobre 2023 18:22
A: jakartaee-spec-project-leads@xxxxxxxxxxx <jakartaee-spec-project-leads@xxxxxxxxxxx>; Edward Burns via <>
Cc: Edward Burns <Edward.Burns@xxxxxxxxxxxxx>
Oggetto: [] 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.




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.






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.







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

| Calendar Booking:


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

| of your normal working hours.


| Reply anonymously to this email:

_______________________________________________ mailing list
To unsubscribe from this list, visit


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. 

Back to the top