Well put.đź’Ż
Hi, I’d just like to chime in as a long-time Java EE / Jakarta EE user. Our organization has a large, critical application that has used remote EJBs for many years, even as we changed implementations (WebLogic, JBoss). I agree with the ease-of-use of remote EJBs, particularly for internal applications where we control the client and server, and have had similar thoughts about the future of Jakarta EE and EJB. We could move these services to HTTP REST on top of JAX-RS. But the simplicity of declaring a Java interface of methods and programming the client and server directly to it has been fairly productive for our developers, and would be missed if we used REST as the replacement. I’ve been wondering whether there would be a successor to remote EJB functionality, since it’s been said that remoting is not a goal of CDI. Thanks, Jim Doyle From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of lenny--- via jakartaee-platform-dev
Sent: Friday, July 21, 2023 11:42 PM
Subject: Re: [jakartaee-platform-dev] Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI? What I am specifically talking about is RPC as implemented by Remote EJB part of the spec. I remember those days very fondly where you can just call remote methods with two annotations, and it actually worked and was easy!
Java EE includes a XMLRPC before SOAP, personally I do not think RPC should be back again. --- Regards, Hantsy Bai Self-employed consultant, fullstack developer, agile coach, freelancer/remote worker Doesnt RPC means nothing? Some will say GraphQL (others will hate it), some will say gRPC (same), others will say JSON-RPC, others will just bring back SOAP to life. RPC is likely a synonym to "single endpoint for multiple handlers" but without a format (JSON in EE for ex to stay consistent) and a transport it is undefined and hard to integrate (as were remote EJB between services when not the same vendor and version). So on EE side the one making the most sense is likely JSON-RPC since it will enable to be interoperable and optimized but guess it can start a lot of debates we should maybe avoid to work on a stronger and lighter platform instead?
Yes, Payara has EJB over HTTP and gRPC currently, but that’s proprietary. I think there should be some kind of RPC plan post-EJB on the spec level.  Just out of curiosity, is EJB-deprecation-in-favor-of-CDI going to contain RPC of some kind?
EJB Lite would not, as Remote Beans are only in EJB Full. EJB Full is way too complex I think to ever rebase on CDI without making it a totally different spec. Listening to the industry “weak signals” it sounds like RPC is coming back into fashion. Would hate to miss that hype, especially that remote EJB-type RPC already exists and well-understood and tested… Bring back remote EJBs? in CDI form?
I did something in Payara that approximated this. There were plans to take that even further, but you know how these things go.
|
