[javaee-spec users] Re: [jsr366-experts] Proposed Optionality of CORBA / IIOP interop

From: arjan tijms <>
Date: Fri, 9 Oct 2015 13:28:33 +0200


On Mon, Oct 5, 2015 at 11:12 PM, Linda DeMichiel
<> wrote:
> Thanks, Jason.
> I'd really like to hear from others regarding the points
> made here as well.

I agree with Jason's point that remote EJBs can not just be replaced
by JAX-RS. Some use cases where previously remote EJBs were used can
be replaced for sure, but not all.

As I mentioned in my comment here:
transaction and security context propagation are still strong features
that don't have any reasonable replacement.

> Just a point on clarification on this. The EJB spec has never
> required transaction interoperability between vendors' products:
> it has always been optional

As I mentioned in the same comment linked above:

" 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)."

Especially the required client library (e.g. jboss-client.jar) has
been a problem in the past for interoperability between products. Even
communication between two (slightly) different versions of JBoss was
never really possible, since the client library would always clash
with the classes the client server already had.

But lookup has been problematic too. The defacto standard of creating
an initial context that pointed to a remote server and then looking up
a bean in JNDI via their global name (but without the java: prefix)
was broken by I think JBoss as well when they moved from JBoss AS 6 to
JBoss AS 7 and went on to do things differently. Suddenly instead of a
set of properties passed to InitialContext, a file needed to be present on the class
path (which made switching between remote servers at runtime quite
difficult, and all existing "general" EJB remote code had to be
specifically adjusted for JBoss).

If I'm not mistaken the justification given back then for breaking
this defacto standard was because it was never a standard to begin

Kind regards,
Arjan Tijms