Prune CORBA interoperability

[glassfishrobot]

Although CORBA support in EJB was important once, CORBA usage has dropped precipitously in the past years in favor of REST and SOAP. Current CORBA use is so small that it makes the most sense to prune CORBA support going forward and significantly simplify EJB remoting.

[glassfishrobot]

Reported by reza_rahman

[glassfishrobot]

Issue-Links:
blocks
EJB_SPEC-17

[glassfishrobot]

mvatkina said:
This request needs to be resolved at the Platform level

[glassfishrobot]

darious3 said:
While I'm all for pruning compatibility with CORBA, I hope this doesn't mean that (EJB) remoting will only have REST and SOAP as options.

Ideally, CORBA interoperability is dropped, and some new more efficient and capable binary protocol introduced for standard @Remote beans.

[glassfishrobot]

@bshannon said:
It's very unlikely that we would introduce a new, standard, binary protocol
just for remote EJBs.

The choices seem to be:

1. Remove the requirement for CORBA interoperability while retaining
the requirement for remote EJB access. Implementations could meet
the requirement using a standard protocol such as CORBA or a
proprietary protocol.

2. Remove the requirement for CORBA interoperability and remove the
requirement for remote EJB access. Implementations need not support
remote EJBs at all, but if they did they could use CORBA or some
other protocol.

As mentioned above, we expect that most remote access to EJBs is moving
to ReST using JAX-RS or SOAP using JAX-WS.

We understand the difficulty that removing any of these capabilities presents
to existing applications that depend on them, but we'd be very interested in
hearing of functionality required by new applications that is not provided
by JAX-WS or JAX-RS and would require new applications to choose the existing
remote EJB capability.

[glassfishrobot]

arjan_t said:

It's very unlikely that we would introduce a new, standard, binary protocol
just for remote EJBs.

Wouldn't JRMP be an option here?

we'd be very interested in hearing of functionality required by new applications that is not provided
by JAX-WS or JAX-RS and would require new applications to choose the existing
remote EJB capability.

What about the ease of use with which a remote bean can join a distributed transaction and propagate an established security context?

The first one is a real issue that we encountered in production when doing two calls to a JAX-RS based service that should either both take effect or none at all.

For SOAP there's WS-AT, but last time I looked it was quite a hassle to get this to work (maybe things have changed lately?).

A binary protocol may also have the potential for better performance. In case the spec leaves the protocol open to the implementation, then there's still room for that. However, EJB remote communication between different application servers is already difficult or impossible. Instead of improving this, leaving even the protocol to the discretion of the vendor would completely destroy any interoperability.

Ideally we would like to see a standardized method to lookup remote EJBs, some standardized notion of what many implementations now call a 'client lib' and a common protocol (e.g. JRMP, which is already available in the JDK).

[glassfishrobot]

@bshannon said:
Some products use JRMP or a variant of JRMP, but we're unlikely to require
use of a Java-specific protocol as an interoperability protocol.

Getting things like distributed transactions working between vendors
continues to be a challenge. The feedback we're getting is that most
people are taking a different approach when they need to interoperate
between different products.

The existing capabilities will be around in products for years to come,
but it doesn't seem like improving them is as important as the many
other things developers are requesting.

Thanks for your feedback.

Note that detailed discussion of issues and requirements is probably
better done on the users@javaee-spec.java.net mailing list.

[glassfishrobot]

braghest said:
We would prefer it if the requirement for remote EJB access stayed. We can live very well without specifying a remote wire protocol. The simplest possible implementation could use Java Serialization over HTTP, vendors would be fee to implement something more efficient. We feel that something like this would have a very low complexity budget while still satisfying a real need.

We have a current application that is implemented using EJB remoting. We feel it would be hard to implement using either JAX-WS or JAX-RS with the same development and runtime efficiency.

We have a rich client application that uses EJB remoting to communicate with the server. The client is tightly coupled to the server, they are build, released and versioned together. Tight coupling allows us to build service methods tailored for each GUI use case. As we have just one client that is released together with the server the downsides of tight coupling don’t apply to us.
The result is both highly productive (we can use a service interface proxy on the client) and highly performant.

We don’t know how common such applications are but we feel that outside of web applications this is a common, efficient and effective architecture.

We don’t feel that we could implement this efficiently and with a high developer productivity using either JAX-WS or JAX-RS. As the application is build on remoting / RPC JAX-RS is a bad fit conceptually. We could build something using JAX-RS but the result would not be RESTful but just “stuff over HTTP”. On the positive side would allow us to use Java Serialization.
We don’t feel that JAX-WS would give us the same performance and ease of use for a developer. We often send hundreds if not thousands of complex objects to the client in a single remote call. Using Java Serialization and a few strategically places serialization proxies we can do this with great performance, low latency and low GC pressure. As JAX-WS / SOAP would force us to use XML we are not confident we would be able to achieve the same performance.

If the remote EJB functionality was dropped the closed thing to satisfying our requirements would be Spring Remoting.

[glassfishrobot]

reza_rahman said:
I agree the EJB remoting feature (sans CORBA interoperability) is still very valuable. Indeed, it could benefit from portability improvements on the injection side if the protocol could be simplified.

[glassfishrobot]

angelorubini said:
Can you see this issue:https://java.net/jira/browse/EJB_SPEC-132?

[glassfishrobot]

This issue was imported from java.net JIRA JAVAEE_SPEC-16

[AngeloRubens]

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 era with RMI/IIOP over HTIOP?
Http2 has more fearture like Corba TCP Connection(Single Connection,Multiplezing, priority,Binary Stream).
The good base of RMI-IIOP based to OMG Corba(IDL+IIOP/GIOP Message with HTIOP) have most power.
With EJb Ecosystem if i want invoke method over http with binary protocol i'dont have a good choice.
gRPC, Finangle or zeroICE sponsored 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 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 example see payara/Payara#1406