Hi everyone,
Making a comparison with the automotive world: "Let's not make the mistake like Europe which deprecated/removed the production of petrol/diesel powered engines, without building/providing a valid alternative immediately..."
I like Ondro's, Bernd Müller, Ralph Soika,Ondro Mihályi comment EJB is not a bad spec. Whatever the new spec like @Service may be, It will be important to maintain ejb features such as: remote calls between ejbs (with efficient binary protocols), keeping transactions DISTRIBUTED, between remote calls between ejbs, security context distribution.
Perhaps it would be desirable to retain the functionality that if an ejb is calling a method of another ejb the AS, understands that if the two ejbs are on the same instance of jvm the call will be local rather than remote.
By comparison, spring boot or other frameworks like helidon and quarkus do not have these features, for example in spring boot the giant Alibaba/Alipay have written a framework for rpc Dubbo (https://dubbo.apache.org/en/) for satisfy remote calls with (efficient) binary protocols between services and also wrote the seata(https://seata.apache.org/) framework for distributed transactions.
This shows that in complex/enterprise contexts rmi/rcp calls between components(like EJB @Remote Stateless/new @Service) and distributed transactions between them ARE IMPORTANT.
Lastly, but still important, Google has written a new framework Service weaver (https://serviceweaver.dev/blog/vision.html) which practically refers to the EJB component model of the first J2EE specifications.
Finally I say, ok to change the name of a specification, but let's not lose these features which, as we see in complex and enterprise contexts, are fundamental. Furthermore, it would be important that in future talks on Jakarta ee we start talking about distributed transactions between distributed applications again and show how Jakarta ee applications solve these problems.
What do you think? Greetings everyone
Angelo Rubini
Da: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> per conto di Abraham Marin-Perez via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Inviato: mercoledì 30 ottobre 2024 18:11
A: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Abraham Marin-Perez <abraham.marin.perez@xxxxxxxxxx>; JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>; jakarta.ee-wg@xxxxxxxxxxx <jakarta.ee-wg@xxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Oggetto: Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan
We could talk about CDI achieving feature parity with EJB, this will signal users that they can do with CDI everything that they do with EJB, it’s just a matter of how.
—
Abraham Marin-Perez
🖥️ https://www.cosotateam.com/
💼 https://www.linkedin.com/in/abraham-marin-perez/
🐦 https://twitter.com/AbrahamMarin
On Oct 23, 2024, at 10:05 AM, Reza Rahman via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:
Do you mind suggesting alternative verbiage? How about “Provide modernized equivalents of all key EJB functionality using CDI across the platform”?
Even if we cannot achieve complete consensus by October 31, I would like to see what level of consensus could indeed be achieved. For example, at a bare minimum, can we commit to a projected delivery date and Java SE support? The
release plan (draft?) appears to do so?
From: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
Sent: Wednesday, October 23, 2024 6:46 PM
To: Reza Rahman <reza_rahman@xxxxxxxx>
Cc: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; jakarta.ee-wg@xxxxxxxxxxx <jakarta.ee-wg@xxxxxxxxxxx>; JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan
I'm not in a position to provide a lot of feedback by October 31.
A quick input is that we should be cautious about language like 'Fully replace EJB with equivalent CDI centric functionality across the platform'. People are going to read
that and interpret it as 'we're removing EJB in EE 12' when actually
https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=gmail talks about how "we can declare our intent to deprecate EJB". Your more detailed write up is about covering the EJB use cases via other specs so EE 12 users don't
have barriers to moving away from EJB.
I understand EJB makes marketing pitches harder, but OTOH a lot of people use it and I don't think scaring them will help Jakarta EE.
Yes, I understand you folks have been discussing EE 12 to some extent. What I would like to see is if we can achieve more concrete early consensus (including at least some things we can all agree is important to try and deliver)
that can be documented (and publicized) as part of the Working Group Program Plan itself.
Thank you, Reza, for kickstarting this.
Speaking to a friendly JUG leader at Open Community for Java about this, I think I should be even more explicit about deadlines.
The Program Plan is due by the first week of November. To include a specific scope for EE 12 in the Program Plan, a reasonable level of consensus must be achieved by October 31 at the latest. Ideally consensus by October 29 would
be great as this is when the next Steering Committee meeting is.
Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
+1 717 329 8149
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
+1 717 329 8149
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
reza.rahman@xxxxxxxxxxxxx
+1 717 329 8149
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
Da: jakarta.ee-spec <jakarta.ee-spec-bounces@xxxxxxxxxxx> per conto di Abraham Marin-Perez via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx>
Inviato: mercoledì 30 ottobre 2024 18:11
A: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>
Cc: Abraham Marin-Perez <abraham.marin.perez@xxxxxxxxxx>; JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>; jakarta.ee-wg@xxxxxxxxxxx <jakarta.ee-wg@xxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Oggetto: Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan
We could talk about CDI achieving feature parity with EJB, this will signal users that they can do with CDI everything that they do with EJB, it’s just a matter of how.
—
Abraham Marin-Perez
🖥️ https://www.cosotateam.com/
💼 https://www.linkedin.com/in/abraham-marin-perez/
🐦 https://twitter.com/AbrahamMarin
On Oct 23, 2024, at 10:05 AM, Reza Rahman via jakarta.ee-spec <jakarta.ee-spec@xxxxxxxxxxx> wrote:
Do you mind suggesting alternative verbiage? How about “Provide modernized equivalents of all key EJB functionality using CDI across the platform”?
Even if we cannot achieve complete consensus by October 31, I would like to see what level of consensus could indeed be achieved. For example, at a bare minimum, can we commit to a projected delivery date and Java SE support? The
release plan (draft?) appears to do so?
From: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
Sent: Wednesday, October 23, 2024 6:46 PM
To: Reza Rahman <reza_rahman@xxxxxxxx>
Cc: Jakarta specification discussions <jakarta.ee-spec@xxxxxxxxxxx>; jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>; jakarta.ee-wg@xxxxxxxxxxx <jakarta.ee-wg@xxxxxxxxxxx>; JakartaEE Spec Project Leadership discussions <jakartaee-spec-project-leads@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec] Defining Jakarta EE 12 Scope in Program Plan
I'm not in a position to provide a lot of feedback by October 31.
A quick input is that we should be cautious about language like 'Fully replace EJB with equivalent CDI centric functionality across the platform'. People are going to read
that and interpret it as 'we're removing EJB in EE 12' when actually
https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=gmail talks about how "we can declare our intent to deprecate EJB". Your more detailed write up is about covering the EJB use cases via other specs so EE 12 users don't
have barriers to moving away from EJB.
I understand EJB makes marketing pitches harder, but OTOH a lot of people use it and I don't think scaring them will help Jakarta EE.
Yes, I understand you folks have been discussing EE 12 to some extent. What I would like to see is if we can achieve more concrete early consensus (including at least some things we can all agree is important to try and deliver)
that can be documented (and publicized) as part of the Working Group Program Plan itself.
Thank you, Reza, for kickstarting this.
Speaking to a friendly JUG leader at Open Community for Java about this, I think I should be even more explicit about deadlines.
The Program Plan is due by the first week of November. To include a specific scope for EE 12 in the Program Plan, a reasonable level of consensus must be achieved by October 31 at the latest. Ideally consensus by October 29 would
be great as this is when the next Steering Committee meeting is.
Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
+1 717 329 8149
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
+1 717 329 8149
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
reza.rahman@xxxxxxxxxxxxx
+1 717 329 8149
_______________________________________________
jakarta.ee-spec mailing list
jakarta.ee-spec@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec
|
