Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] R: Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?
Think we are already covered with websockets which are a good replacement (likely better today than http2 based protocol which are still highly attacked) and using a binary protocol and light client wrapper you get at least an as good solution than EJB but more portable by design and proxy friendly.
That said, RMI based solution were often slow due to the classloading involved (so don't think remote ejb are really a pro when based on it) and even HTTP 1/1 did very good progress using pooling (compared to original times) and this also makes almost all the http binary optim pointless (thinking to ajp which is not really needed today for perf in practise).

So think this can be a more emotional thread than technical.

Technically the only pro would be portability - vendor specific things can always be done and don't need to hit the spec.
gRPC or graphql portability are almost a joke due to the related stacks and choices so think focusing on what is widely used like websockets and preparing http2 maturity is way sufficient at jakarta level.

At abstraction level not sure much can be done cause any infra requirements would bother some vendor or be overkill if not used so probably best to boot a library project than a platform solution IMHO.

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


Le mar. 1 août 2023 à 09:04, Angelo Rubini via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :

Hi All, 
it is important to preserve functionality such as ejb remoting. 
Many business applications use ejb remoting to communicate in their backends, for best perfomance vs soap/rest protocol.

In the EJB 1.1 Specification, Sun Microsystem in according to OMG integrate RMI over CORBA IIOP(Standard deFacto and more use in the years 80/90).

Most corba client invoke Ejb method from c++, ada etc by Corba Client.

Why not reproduce same scenario for HTTP2/gRPC herea?

Http2 has more fearture like Corba TCP Connection(Single Connection,Multiplezing, priority).

The good base of RMI-IIOP based to OMG Corba(IDL+IIOP/GIOP Message) have most power.

gRPC promote an rpc over http2(only efficient alternative for REST JSON+HTTP), but there are more work for developer.

  • generate proto interface(on java there is java interface by OMG IDL ),

  • generate and populate stub code(on Ejb this is gratis with Runtime Stub Generation/Downloading feature).

  • generate and populate skeleton code(on Ejb this is gratis with Runtime Skeleton Generation feature).

  • for a server-to-server communication is a good choice ejb-to-ejb communication, and support distributed transaction managed by conintainer.

  • The EJB CMT Feature (EJB container managed transaction inbound outbound) is power feature.

An interesting project is jakarta-RPC but in this moment is very distance from Remote EJB.


Best regards
Angelo Rubini

Da: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> per conto di Steve Millidge (Payara) via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Inviato: venerdì 28 luglio 2023 19:26
A: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx>
Oggetto: Re: [jakartaee-platform-dev] Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?
 
Agree it is also used by a lot of Payara customers.


Sent from Outlook for Android
From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> on behalf of Brian Stansberry via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>
Sent: Friday, July 28, 2023 6:17:47 PM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Brian Stansberry <brian.stansberry@xxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Should we consider rebasing Enterprise Beans Lite to a mapping/extension on top of CDI?
 
Agreed. The WildFly and EAP implementation of remote EJB is very heavily used.

On Mon, Jul 24, 2023 at 10:15 PM David Blevins via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
I also know quite a lot of people using remote EJBs in their backend architecture.  It’s a perfectly valid usage.

Reminder to everyone as well, remote EJBs != binary protocol.  Implementations can use any protocol they want (REST included).

I know we have a ton of features in OpenEJB's protocol around optionally layering over http, client-side load-balancing, dynamic client/server discovery over UDP or TCP, sending updated lists of available servers to clients as part of routine responses, robust failover options, security features, observable events for all internal activity, metrics built into the protocol that allow for end-to-end awareness of serialization time vs invocation time vs network time.

Definitely I’d use Jakarta REST for anything a 3rd party would invoke, but for internal communication you can get some amazing features out of remote EJBs.


-- 
David Blevins

On Jul 24, 2023, at 11:43 AM, lenny--- via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Well put.
💯

On Jul 24, 2023, at 1:41 PM, Doyle, James, K via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

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!
 


On Jul 21, 2023, at 8:51 PM, hantsy bai via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
 
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
 
 
On Sat, Jul 22, 2023 at 12:37 AM Romain Manni-Bucau via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> 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.
 
 
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
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
 
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

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

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


--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top