The future of JavaEE. Will EJB remote access disappear?

[alexander.beening]

Good morning,

One week ago, I downloaded the new JBoss AS 7.0.0 release to start exploring this new server as an evolution from JBoss AS5, currently in use with success in applications of our company's R&D department.

We use JBoss AS as the business logic platform in our applications, clearly separated from the "presentation" logic, which are either web applications, using JSF-2 or web services, using AXIS-2. These applications run in a stand-alone Tomcat-6 server. We use EJB remote access to session beans, using EJB client jars. As well, I teach this approach at the University of Andorra as "best practice" to create open enterprise applications.

As of today, JBoss AS-7.0 does not support remote EJB access. Some of the community members already expressed their dissatisfaction about this missing feature in a GA-release. My first reaction was also in this category. What was the final reason to not implement remote EJB access in JBoss AS-7.0?

Exploring the examples in the JBoss as quickstarts, I notice, that they are based on another architecture which I would describe as "all-in-one applications with outlets to clients by means of RESTful web-services". CDI seams to be the key-technology to "stitch" together the business logic and the presentation layer.

Said all this, I would formulate the following questions:

- Is remote EJB access a good practice in the JavaEE future?

- Should we continue separate rigorously the business logic layer from the presentation layer?

- Is the framework, proposed in the JBoss AS quickstarts the best practice for JavaEE 6 or is it just a JBoss proposal to create applications with JBoss AS7?

- Will Remote access to Session beans/interfaces disappear in the future and be replaced by consuming (RESTful) web-services?

Of course, I would express my compliments for the great work in JBoss AS-7.0!

Thank you for giving me feedback on this issue. Sorry about the long message to read.

All the best,

Alexander

[fabrizio.benedetti]

Alexander,

even in my actual department we use JBoss AS5 and we separate presentation logic from business logic, with remote calls to SessionBeans (jnp://...).

- Is remote EJB access a good practice in the JavaEE future?

I think so, only when it has sense (remote calls are slower than local ones).

- Should we continue separate rigorously the business logic layer from the presentation layer?

I think so, also locally.

- Is the framework, proposed in the JBoss AS quickstarts the best practice for JavaEE 6 or is it just a JBoss proposal to create applications with JBoss AS7?

Remote EJB calls will be available in AS7.1, so I don't think this is a proposal to create applications with AS7.

Simply we have to wait...

- Will Remote access to Session beans/interfaces disappear in the future and be replaced by consuming (RESTful) web-services?

RESTful is a good thing, but I think developers will continue to write remote EJB, because they are simple, it is a consolidated technology, transactions/security propagation, and RMI/IIOP is faster than HTTP.

Of course these are my opinions.

Regards,

Fabrizio

[kabirkhan]

If you have a client application needing remote access to EJBs on a server, you can try this temporary workaround http://community.jboss.org/wiki/RemoteEJBLookupAndInvocationInJBossAS700

[henk53]

Fabrizio Benedetti wrote:

RESTful is a good thing, but I think developers will continue to write remote EJB, because they are simple, it is a consolidated technology, transactions/security propagation, and RMI/IIOP is faster than HTTP.

I agree with Fabrizio here. There are basically 4 levels where one can put the (EJB based) business logic now:

1. Inside the war (new in Java EE 6)
2. Inside an EJB module co-located within the same EAR as the WAR that has the presentation logic
3. Inside a remote EJB module with communication happening via RMI/IIOP (binary)
4. Inside a remote EJB module with communication happening via JAX-RS (http/text based)

Each of those actually has their value. Option 1. seems anti best practice, but for small applications a simple "business" package can be enough 'isolation'.

Especially option 2 has a lot of value I think. Especially for beans where the state of the instance doesn't matter (true for many stateless beans), this can actually be a best practice for many systems. As Fabrizio mentions, these calls are a very large factor faster. I would go as far to saying that making everything automatically remote out of some false sense of 'purity' is perhaps an anti-pattern. If not taken care of the interaction patterns (which should be course-grained for remote access) a system can be taken down because of too much remote traffic going on.

If it has been decided that remote communication is needed (perhaps because the remote server has a very large JPA 2nd level cache), then RMI/IIOP is the fastest way too communicate. Compared to local communication, there is always a cost associated with serializing and de-serializing objects, but it's most efficiently done using a binary protocol.

A downside to using binary communication is that the entire concept of the necessary "client drivers" for the remote server has been severely neglected in Java EE. Basically it works between two application servers that are the exact same brand and version (e.g. JBoss AS 5.1 to JBoss AS 5.1) and between a Java SE client and an application server (Tomcat more or less counts as Java SE as well). All other bets are off. Forget about letting JBoss AS 5.1 communicate to JBoss AS 6.0. It doesn't work. It can not work, and almost certainly will never work. You need to go to extremes with special isolating class loaders, but that's only a concept that sadly doesn't actually work.

Needless to say that binary communication also doesn't work between different languages* and is often difficult to use if there's a firewall (especially because RMI/IIOP connects back to the client using a random port).

So finally, there's option 4 where we communicate via JAX-RS. This doesn't require special client drivers and works between different platforms (thus also between two different versions of JBoss AS) and firewalls, at the cost of a much higher overhead in both processing power (serializing to the typically used XML of JSON is slower than binary) and in programming complexity (JAX-RS isn't as transparent as remote interfaces and requires additional annotations and explicit paths to be defined).

To sum up, I would suggest to go for local communication first if that's possible, then go for RMI/IIOP if you really need remote semantics and only if that isn't an option go for JAX-RS.

*)

Theoretically, IIOP being a CORBA protocol actual does work between different languages, but in practice this is not really trivial.

[alexander.beening]

Good morning!

First of all, thank you very much for the replies, Fabrizio, Kabir and Henk. Your explanations are very helpful in this discussion.

Using the member's explanations, our own experiences and the tests we performed, I could at least determine how to proceed in the future. This is, in global what I think, the best way to continue:

• Continuing using EJB access from remote clients like Tomcat, daemons and rich clients, using RMI/IIOP as we did in the past with JBoss-5.0.0.GA. This works fine and is fast enough for our prototypes.
• Giving RESTful web services a try as information providers for various (mobile) clients. Implementation should take place in the business logic layer (so JBoss AS).
• Waiting for JBoss 7.1. We have time, so changing to version 7 is not critical for us.
• If, for whatever reason, JBoss 7.1 will not be released before end of 2011, I would try Kabir's option to remotely access EJBs.

I hope this roadmap is the right one. Replies are welcome.

Thanks again for the feedback and I'll inform the community about our experiences with JavaEE-6 and JBoss AS 7.

All the best,

Alexander