Re: [jakartaee-platform-dev] Should we consider rebasing Enterprise Bean

[Romain Manni-Bucau <rmannibucau@xxxxxxxxx>]

Le ven. 21 juil. 2023 à 20:16, <lenny@xxxxxxxxxxxxx> a écrit :

Not even thinking transport, just Java API (at least for now)

Currently we have Remote EJB as RPC mechanism,

but when that “goes away” Jakarta will have nothing, unless there is a plan to have a “better RPC” API based on CDI or something.

I would like something similar to remote EJB because it’s super easy to use.

Yes, you heard me right! remote EJB is super easy to use :)

When you have a single vendor, in all other cases it is not. So if it is what you are aiming for it can stay a vendor thing else you need to solve transport and format and there, there is no standard or mainstream solution. Supporting the four major rpc spec sounds overkill and the last two have major drawbacks...

That said a good news is that it is already built-in in ee, just do a switch is a doPost in a servlet and you have a rpc solution so maybe defining what it is will help to see why it is almost born dead _today_.

On Jul 21, 2023, at 11:37 AM, Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:

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?

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book

Le ven. 21 juil. 2023 à 17:54, Lenny Primak via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :

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. 

On Jul 21, 2023, at 10:41 AM, Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:



Hi,

On Fri, 21 Jul 2023 at 01:14, <lenny@xxxxxxxxxxxxx> wrote:

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.

See https://blog.payara.fish/remote-ejb-via-http

Kind regards,

Arjan Tijms

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev