Jakarta component model programming discussion(The future of jakarta ejb )

[AngeloRubens]

Hi All,

taking inspiration from this paper https://sigops.org/s/conferences/hotos/2023/papers/ghemawat.pdf
" Towards Modern Development of Cloud Applications" (from Google) it's interesting beacause, they mention the limitations of microservices and their solution to solve them.

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, What do you think in relation to EJb deprecation/removal, RMI-IIOP deprecation/removal?
The @service is the new way for jakarta enterprise for build a component model programming in distributed environment(features like, location, trasparency, rmi invocation, trasparency local or rmi invocation, concurrency, transaction,security)?

[anbusampath]

What do you think in relation to EJb deprecation/removal, RMI-IIOP deprecation/removal?

Payara replaced remove ejb with http calls - https://blog.payara.fish/remote-ejb-via-http

What do you think in relation to EJb deprecation/removal, RMI-IIOP deprecation/removal?

Tomee also uses http - https://tomee.apache.org/master/docs/ejbd-transport.html

[AngeloRubens]

Hi @anbusampath , the issue arose after reading this document, which raises a series of gaps on microservices. Many of the observations in the document refer to the component model born with j2ee and still present today in jakarta ee. Mine was intended to be an issue of reflection on the possible evolution/update on ejb component model. What do you think about it? or others jakarta ee members(@arjantijms @kazumura , @edburns , @Emily-Jiang , @ivargrimstad)

[anbusampath]

Mine was intended to be an issue of reflection on the possible evolution/update on ejb component model. What do you think about it

I would advise remove EJB as we formally know and let promote CDI as single component model. About all the distributed capabilities can be added from EJB to CDI.

http://blog.dblevins.com/2012/11/cdi-when-to-break-out-ejbs.html - this blog is decade old. David also talked about it many times as well(https://youtu.be/5wX8RmBHMVY?si=9mXh2nC1qBTgFt9C). Let him share his view @dblevins

https://omnifish.ee/2022/06/29/the-future-of-ejb/ - @arjantijms also share similar view.

[AngeloRubens]

I absolutely agree with the transition/promotion from EJB to CDI, maintaining the functionality of the EJB. But as demonstrated in the "Towards Modern Development of Cloud Applications" paper, it is important to have a mechanism protocol that allows you to have a component on which it is possible to invoke methods both locally and remotely, and remotely using an efficient protocol, today this functionality is present with ejbs (through @Local and @Remote) and the container is able to understand/decide whether the call is local or remote. What do you think of the paper "Towards Modern Development of Cloud Applications" in relation to jakarta ejb?

[hantsy]

@anbusampath I do not think removing EJB is a good idea, there are a lot of Java EE/Jakarta EE applications are still using EJB today.

We can improve the CDI functionality for the current Jakarta EE, and provide a migration chapter/section to move to CDI from EJB components in Jakarta EE tutorial.

When we can use CDI to replace EJB completely, then we can refactor related content(spec/Jakarta EE tutorial) to use CDI instead, then deprecate the EJB content at that moment.

But EJB as a mature spec in Jakarta EE, it should be included in the Jakarta EE tutorial/spec for a few years.

[anbusampath]

We can improve the CDI functionality for the current Jakarta EE, and provide a migration chapter/section to move to CDI from EJB components in Jakarta EE tutorial.

@hantsy Completely agree. I meant the same improve CDI with capabilities missing from EJB and retire it. I should used better word in my initial comment.

What do you think of the paper "Towards Modern Development of Cloud Applications" in relation to jakarta ejb?

@AngeloRubens it's possible to extend the EJB features to support what mentioned in the article for local and remote execution of code which is the original purpose of EJB , but current deployment model is EAR/WAR can't to best option in my option with respect that article. New deployment model might emerge where each layer can scale independently depends on the usage and patterns with it's runtime(different from code base). Because runtime should bundle specific dependencies of that layer. When I say new model during deployment or after, some component can deploy as serverless or run always, lt should also support different mode of invoking eg Http, event bases, scheduled etc. but only question remains is who need such a complex architecture of deployment.

[urbandroid]

The thing never talked about on this subject is EJBs pooling and caching capabilities they make high throughput and increase efficiency, object creation cost paid only once, if EJBs going to deprecated this subject also need consideration.

[AngeloRubens]

I really hope that the possible transformation of EJBs into CDIs does not cause the fantastic functionality of EJBs to be lost. Having said this, I think that many developers have not fully understood the true value of EJBs but more than anything they have not understood the component model behind them. We need to make sure that the future of ejbs is bright and better and that all in all, given the proliferation of yaml files to manage kubernetes, the ejb-jar-xml descriptor files were not evil and allow us to add functionality to our logic simply editing a deployment file instead of rebuilding the software module. I like the Jakarta ee platform because it has always allowed me to have everything available, remote and distributed transactions, efficient remote invocations, ejb configuration via file descriptor, etc etc. I created this issue with the aim of carrying forward and spreading the component model for the new generations (uber jar generation), for this reason I took inspiration from the Google paper which mentions how they are reinventing the wheel with service weaver (in go) . Already from ejb 1.1 it was possible to run a component locally or remotely, just deploy/assemble the module (jar) with a configuration and that's it.

ps probably a starting point to promote ejb under cdi, will it be to have a first release of jakarta rpc in the next release of jakarta ee, as it was at the time of corba (the rmi-iiop specification)....

@urbandroid similar ejb staless feature into cdi (probably the first example...)see https://github.com/omnifaces/omniservices

[AngeloRubens]

hi @anbusampath, yes this solution (tomee ejbd over http or payara ejb over http)for invoking ejb over http is good solution but not the best/standard solution. I looking another solution by widlfy https://github.com/wildfly/wildfly-http-client/blob/master/docs/src/main/asciidoc/wire-spec-v1.asciidoc for ejb over http, this solution cover ejb stateless, distributed xa transaction and stateful ejb over http. But all of these features are not a compliant with a specification standard, it's only a custom provider solution.

if there was a first implementation of jakarta rpc, but there is no trace of it, we would have the possibility to invoke jakarta ee remote components, through efficient serialization via http2 (and perhaps also http3/quic). Currently the only standard solution offered by the Jakarta ee platform for remote invocations over http is jax-rs or jax-ws(json or xml). Besides google service weaver, there are many examples(alibaba dubbo(apache), linkedin convert all rest/json to protobuf grpc (https://www.infoq.com/news/2023/12/linkedin-grpc-protobuf-rest -json/)) to date which are moving towards efficient protocols in terms of performance and latency to help reduce network/hardware costs/power and implicitly consume less power (less CO2).

[hantsy]

There is a RPC XML spec a few years ago, finally it is replaced with SOAP.

I am not sure we need the RPC again for the new Google gRPC or Apache Dubbo, etc. And these RPC projects use their own formats in the transport layer, it is difficult to unite them into one specification.

Support only one RPC such as gRPC can be a side project of Jakarta EE, but when talking about specification it is meaningless.(And from the lang SDK provided by gRPC, I think it is easy to integrate it with CDI/Jakarta EE)

[AngeloRubens]

Hi @hantsy i refer to this jakarta rpc specification: https://github.com/jakartaee/rpc

[arjantijms]

The thing never talked about on this subject is EJBs pooling and caching capabilities

We actually do talk about it ;)

https://github.com/omnifaces/omniservices/tree/develop/src/main/java/org/omnifaces/services/pooled

[arjantijms]

Payara replaced remove ejb with http calls - https://blog.payara.fish/remote-ejb-via-http

I didn't actually replace remote EJB, just added an extra option. It's not "true" remote EJB over HTTP. I tried looking at that first, but it was rather complicated to do. Together with Steve we figured out a simpler way, which just emulates the main external visible aspect of remote EJB and the programming paradigm.

It's a bit of a pity perhaps that this HTTP approach AFAIK was never continued. I had a lot of plans and it seemed all quite doable, but alas.

[anbusampath]

I didn't actually replace remote EJB, just added an extra option.

Sorry, My bad I used wrong word.

[arjantijms]

Sorry, My bad I used wrong word.

No worries ;)

Still, like I said above, it's really a pity that this development for the alternative HTTP/EJB stopped. We had a lot of those type of projects in development back then, and it was a really interesting time.

[AngeloRubens]

Hi @arjantijms, but couldn't all these custom developments of ejb over http, see payara, wildfly, tomee have a single common effort and contribute to a first RI of jakarta rpc(https://github.com/jakartaee/rpc)?

[arjantijms]

but couldn't all these custom developments of ejb over http, see payara, wildfly, tomee have a single common effort and contribute to a first RI of jakarta rpc

I'd wish, but at the moment nobody seems to have the resources for it. It's already difficult enough to get any work to be done for Jakarta REST, and that is probably next to Jakarta Persistence and Jakarta Servlet the most used technology.

Also vendors (engineers really) always disagree over everything. Look at Jakarta Data now. One half of the vendors want query by name, the other half want annotations. Also, when a common effort has been done, vendors not rarely tend to "forget" about it, and continue improving their own thing. Look at Jakarta Security, and how so many vendors are still inventing security themselves all over again. Helidon, Quarkus, WildFly to a degree all have their own security APIs and libraries that they promote.

[AngeloRubens]

Hi @arjantijms ,Of course I absolutely agree with what you say, I often see this also in the latest topic "Behavior of virtual=true on Java SE 17". I thought that since Payara, Wildfly and OpenLiberty(webshere) already offer a grpc implementation it could be combined into the jakarta rpc specification. Do you think this can be brought to attention in the next jakarta member call? To date REST is widespread but so is grpc. This issue was born from this paper: https://sigops.org/s/conferences/hotos/2023/papers/ghemawat.pdf, more and more customers/companies are highlighting/understanding how it is necessary to have an efficient remote invocation mechanism to optimize latency, performance and hardware and network costs, especially in cloud contexts. An example is Google which set up Service Weaver (the paper that started this issue), LinkedIn with the transition from rest to grpc, Apache Pulsar in favor of Kafka and last but not least, data persistence solutions such as ScillaDB instead of Cassandra.