| Re: [jakarta.ee-community] Defining Jakarta EE 12 Scope in Program Plan |
From a functional standpoint, indeed already possible in one way or the other. For example, I remember in the Java EE 7 time frame I helped replace a really bizarre architecture consisting of AWT, EJB Remote, and Stateful Session Beans with WebSocket. More fundamentally, anything in EJB can be re-written and modernized with CDI - so the ultimate answer is definitely yes.
The better question for me is whether it is even needed. I have
not seen a single new application in more than ten years that uses
this stuff, only old legacy applications. Spring never supported
this stuff really and basically treats this stuff as
anti-patterns. It's mostly just REST web services these days.
Arguably the more modern analog of this stuff - gRPC and GraphQL -
hardly still have any traction:
https://trends.google.com/trends/explore?date=all&q=gRPC,GraphQL,REST&hl=en.
I am not sure if CDI could replace the following two things in EJB.* Stateful Bean (and Extended Persistence Context to span multiple client requests)* EJB Remote Interface and Client/Server interaction in a Cluster deployment
---
Regards,
Hantsy Bai
Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker
GitHub: https://github.com/hantsy
Twitter: https://twitter.com/@hantsy
Medium: https://medium.com/@hantsy
On Mon, Oct 28, 2024 at 9:55 PM Ralph Soika via jakarta.ee-community <jakarta.ee-community@xxxxxxxxxxx> wrote:
_______________________________________________Hello,
I became aware of this discussion through the topic "EJB -> CDI migration" and would like to briefly share my thoughts about it.
My fear here is to "ban" EJBs as something outdated, complicated and unnecessary. But is that right?
I myself run with imixs.org a very large Jakarta EE project. And my opinion is that you should always implement the DataAccessLayer as also complex ProcessingServices in a stateless EJB in order to make use of the transaction capability.
I do know that you can also use CDI for data access. But is it the same?For example in my own project (a BPMN workflow engine) the DataAccess Service as also the Engine itself is implemented as a stateless EJB.
A project that is using the library just need to inject the WorkflowEngine. The user does not have to think about transactions or EJBs at this moment. The app developer can now extend the engine behavior by implementing so called 'Plug-Ins' as simple CDI beans. Such a CDI bean is a kind of adapter class that can for example react on specific CDI Events in the processing life-cycle. And of course the developer can again inject the DataService form the Workflow Engine to create new data.The point is that if something goes totally wrong, the default transaction manager takes care about the rollback over all layers.
And this all comes for free just because of using the stateless local EJB pattern. For the developer there is no need to think about EJBs at all.
I may be wrong here, but I would always advise a developer to implement the data access layer via EJBs to keep the rest of the application as lean as possible.
Therefore, in my opinion, EJBs play an important role. A tutorial should not hide its concepts.
Best regards
Ralph
On 28.10.24 14:21, Reza Rahman via jakarta.ee-community wrote:
I think the Tutorial refactoring work could easily be tagged “good first issue” and “help wanted”. We have a shockingly low number of those across EE4J projects.
From: Kito Mann <kito.mann@xxxxxxxxxxx>
Sent: Sunday, October 27, 2024 11:50 PM
To: jakarta.ee-spec@xxxxxxxxxxx <jakarta.ee-spec@xxxxxxxxxxx>; Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>; jakarta.ee-marketing@xxxxxxxxxxx <jakarta.ee-marketing@xxxxxxxxxxx>; Reza Rahman <reza_rahman@xxxxxxxx>
Cc: Jakarta EE Ambassadors <jakartaee-ambassadors@xxxxxxxxxxxxxxxx>; juneau001@xxxxxxxxx <juneau001@xxxxxxxxx>; Kito Mann <kito.mann@xxxxxxxxxx>
Subject: Re: EJB -> CDI migration (was Re: Defining Jakarta EE 12 Scope in Program Plan)I love all three of these ideas:
- EJB -> CDI Migration Guide
- New EJB -> CDI Migration talk
- Updating the Jakarta EE Tutorial to remove EJB when possible
(3) is non-trivial since a lot of work needs to be done upgrading/rewriting the examples in general, but that doesn’t mean I can’t at least break that work down into the issue tracker. Also, the intro (which I rewrote) specifically does not mention EJB.
I’d like to add another: Writing an OpenRewrite for migrating from EJB->CDI.
___
Kito D. Mann | @kito99@mastodon.social | LinkedIn
Java Champion | Google Developer Expert Alumni
Expert consulting and training: Cloud architecture and modernization, Java/Jakarta EE, Web Components, Angular, Mobile Web
Virtua, Inc. | virtua.tech
+1 203-998-0403
* Enterprise development, front and back. Listen to Stackd Podcast.
* Speak at conferences? Check out SpeakerTrax.On Oct 27, 2024 at 2:46 PM -0400, Reza Rahman <reza_rahman@xxxxxxxx>, wrote:I am moving comments on my Jakarta EE 12 Google Doc
(https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=sharing)
to Jakarta EE mailing lists when possible. The problem with Google Docs
comments is that they do not scale very well, aren't very readable on
smaller devices, and do not archive well. I will do so one email per
comment. The person commenting is copied.
Context: Why does replacing EJB matter?
Josh Juneau (Community): Are there any comprehensive tutorials on how to
utilize CDI rather than EJB for querying entities? It seems like these
tutorials need to be made front and center in an effort to help steer
people to CDI and to show that EJB is no longer needed in many cases.
Reza Rahman (Microsoft): Good point. As of Jakarta EE 11, it is indeed
possible to just use CDI now for basic CRUD in a transactional and
thread safe manner with Jakarta Persistence. The same for EJB
@Asynchronous and @Schedule. At the bare minimum, this is worthy of an
Eclipse Foundation newsletter article and/or JakartaOne talk. The
material could cover where EJB is not needed any more and where it is
still needed. The title could be something attention grabbing like -
"EJB is Dead, Long-Live CDI and Jakarta EE". We could also ensure a
revised Jakarta EE 11 Tutorial can avoid using EJB when possible. Maybe
Kito could comment on this? Additionally, the Marketing Committee has
been sponsoring some guides. Could we consider already starting an EJB
migration guide?
On 10/22/2024 5:30 AM, Reza Rahman wrote:
Hi folks,
I would like to see if we can define clear, compelling, and specific
scope for Jakarta EE 12 as part of the Steering Committee Program
Plan:
https://docs.google.com/presentation/d/1xUNDHMP_qTHH1wA3m0yCmWVf_sHp41Qd7Opq3FhgINs/edit?usp=sharing.
I believe this is of critical importance at this juncture. If I did
not think so, I would not bother trying. I have detailed all the
rationale here:
https://docs.google.com/document/d/1U2qEqF9K969t5b3YuX4cwex5LJPvF3bt1w27cdKNpDM/edit?usp=sharing.
For those that recall, something very similar was done for Jakarta EE
11, so this isn't exactly without precedent.
I would like to see if this can be done in the following couple of
weeks, when the Program Plan is due.
Thanks,
Reza
Reza Rahman
Principal Program Manager
Java on Azure at Microsoft
+1 717 329 8149
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community--
Imixs Software Solutions GmbH
Web: www.imixs.com Phone: +49 (0)89-452136 16
Timezone: Europe/Berlin - CET/CEST
Office: Frei-Otto-Str. 4, 80797 München
Registergericht: Amtsgericht München, HRB 136045
Geschäftsführer: Gaby Heinle u. Ralph SoikaImixs is an open source company, read more: www.imixs.org
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community