hello everyone, regarding the possibility of having a standard I thought that the starting idea of the public specifications of wildfly that cover all the features of ejb, stateless, stateful, distributed transactions, security could be a good starting point,
also because they also provide a complete implementation. To date all application servers offer ejb with rmi calls but, unfortunately, not being a specification of jakarta ee, not all offer the possibility of making ejb calls (with all the features) on http/http2.
I think that being able to go to old and new customers and being able to propose enterprise solutions such as ejb features in modern contexts such as the cloud, would earn and re-evaluate further positive credit towards jakarta ee and its application servers.
The article where the use case of redhat is brought should make us reflect on how customers with enterprise applications based on ejb have been able to deploy their application simply by changing the configuration of the application server. In complex enterprise
contexts, such as alibaba (aliexpress), their team of developers, has a platform developed on spring boot and has created the rpc dubbo framework for rmi calls on http2 and have developed the seata framework to manage distributed transactions, but if you see
how much work you have to do to configure everything and the code to write compared to the solution, presented by redhat with widlfly, you can see how on jakarta ee implementing this type of solution would/could be much easier. Another thing in the life of
j2ee is how for example from hibernate, an adHoc implementation, the jpa specification was created. I remain at your complete disposal for further information and other discussions.
kind regards to all and happy easter....
Angelo Rubini
Da: ejb-dev <ejb-dev-bounces@xxxxxxxxxxx> per conto di Tomasz Adamski via ejb-dev <ejb-dev@xxxxxxxxxxx>
Inviato: giovedì 17 aprile 2025 15:57
A: ejb developer discussions <ejb-dev@xxxxxxxxxxx>
Cc: Tomasz Adamski <tadamski@xxxxxxxxxx>
Oggetto: Re: [ejb-dev] Ejb Over http/Http2 (Re: New release for Jakarta EE 12?)
We are designing the protocol so that it is easily integrated with cloud environments. I was thinking that standardizing this in specification may be considered as a message to the community that EJBs are cloud-ready,
and, as Angelo mentioned, they can rely on EJBs robust and proven capabilities (f.e. distributed transactions) in more modern environments. Interoperability may be another benefit. OTOH, I agree with the point that it may require a lot of work to create a
standard from implementations present in various distributions and I'm also thinking that the timing may be wrong (that is maybe it would be better to standardize if those protocols happen to gain wider adoption instead of when anticipating it).
Regards,
Tomek
Despite the fact many people shut it down, it'd be great to know what you were thinking. I think it's important people feel welcome to express unpopular opinions.
Was the goal a standard protocol so one client could talk to any server (what we've typcially called "interop"). Or was the goal simply to ensure EJB users could be guaranteed that calling an EJB over HTTP is supported by the server (if each server did
this in their own way, that'd be fine as long as it was supported). Or was it both?
If it was just ensuring people could call EJBs over some form of HTTP, we also support that in TomEE/OpenEJB and I'd be surprised if we were both the only ones.
-David
why not think about standardizing this implementation present in wildfly?and like this:
Hi Angelo and Tomasz,
We would need to focus on the goal vs the proposed solution. If the goal is protocol interoperability between different server implementations we would need to all agree that this goal is worth it. From an EJB spec perspective we just removed EJB protocol
interoperability gradually between Jakarta EE 9.1 and 10, so I don't imagine there is much support.
If we did agree that we do want to all invest in EJB interoperability, the conversation would be open for anyone to propose a protocol and could even involve creating a protocol using everyone's input. All of us have different protocols, most of which
we also made and fit our servers intimately. OpenEJB has EJBd which can layer over HTTP. Weblogic has T3. OpenLiberty uses CORBA (already a standard). There have been other's to suggest we should all support Google's Protocol Buffers.
Would the Wildfly team still be willing to pursue interoperability if it meant not using your existing protocol and implementing a protocol decided by the spec group? If the goal is not interoperability, can you clarify the intent?
-David
--
Regards,
Tomek
|