Hi,
On Mon, Oct 5, 2015 at 11:12 PM, Linda DeMichiel
<linda.demichiel_at_oracle.com> 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:
https://java.net/jira/browse/JAVAEE_SPEC-16?focusedCommentId=352923&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-352923
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
jboss-ejb-client.properties 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
with.
Kind regards,
Arjan Tijms