Why Enterprise Java Beans?

I've worked with Enterprise Java Beans (EJBs) for a long time. They are the main building-blocks of Java -based web-applications. Yet I never spent much time thinking about why they were needed. Maybe because it seemed difficult enough just to understand how to use them.

An obvious alternative to EJBs is direct SQL-calls to the database, via JDBC drivers. On the legacy system I was working on some programmers had used direct JDBC calls, some used EJBs. What was the benefit of each approach? It seemed the benefit of using JDBC was simplicity. What was it for EJBs?

I.  HOW I CAME HERE

We started a project to upgrade an application from JBoss-4 to a newer version. But rather soon this started to seem  a bigger project that we had hoped for, because of the difference in XML-dialects which define the EJBs on JBoss-4, vs. later versions.

The XML-definitions should have been backwards compatible of course, but were not. Even though there is an evolving standard for Java EE, all application-servers add their own XML definitions for server-specific configuration of them and EJBs that run on them. The standard itself may have evolved in incompatible ways. Or perhaps a newer JBoss version is enforcing it more strictly. This seemed to be the disadvantage of EJBs.

Trying to start the new JBoss with the old application gave obscure error-messages we couldn't make sense of. Remedies for some errors were found on the web, but other errors remained. And new ones seemed to emerge every time one was solved.

It was unclear not only how to get rid of the error-messages, but also how much time it would take to get rid of all of them. And it is bad to start a project whose duration you can't estimate.


A JBoss installation has two main parts: A web-server which on JBoss-4 is Tomcat, and the "JBoss proper". Both of these are large systems on their own. To understand and tune the whole system you also need to understand how they work together.

Would it be possible to run the system JUST on Tomcat? That would cut (at least) in half the area of expertise needed to maintain and port the system from one platform-version to the next, now and in future.

But if we used only Tomcat we couldn't use EJBs. They only run on 'true application servers', like JBoss, WebSphere, GlassFish, etc. They do not run on 'mere web-servers' like Tomcat.

Did we really need the EJBs? They were used heavily by the application in question, about 100 EJBs in total. Would it be possible to get rid of them and replace them with something simpler?

And only then, after working with EJBs so long I started to see their value. But I also started to see they could be replaced with Plain Old Java Objects (POJOs) - IF we understand why EJBs are needed in the first place. So, after this lengthy but necessary introduction let me try to answer that question.

II. WHAT EJBs DO

There are three main types of EJBs:  1) Session Beans,  2) Entity Beans  3) Message Beans. Rather than describe each on its own, it helps if we can first see what they all have in common, before looking at their differences.

What is common to all bean-types?  That is the discussion I haven't found in any book or article so far. Which is perhaps the reason it took me so long to understand what they all are about.

Clearly they are all part of the same standard. That is one thing they have in common. They are all programmed in Java AND XML, or alternatively in Java and Java annotations.

But they seem very different in purpose. Session Beans help you deal with user-sessions on the web. Entity Beans help you deal with database interactions. Message Beans help you deal with batch-processing jobs. Is there really any common purpose to them?  Were they grouped together simply because we like the word "bean" so much?

Here's the one thing in common about their purpose:  All EJBs help implement persistence.

Entity Beans persist your data in the database. Session Beans persist the memory of user actions during a web-session. Message Beans persist tasks the user may initiate during the session, so they can be performed later.

The REASON we need help in persisting things is that web is a stateless protocol. It is just a set of requests and responses. Enterprise Java Beans allow you to implement (the three types of) state on top of the HTTP -protocol.


Example: You read the user's name from the database when they log in. You may need this info several times during the user's session. But you don't want to query the database every time you need it.  Entity Beans cache the information in memory when it is first read from the database. The database is queried only once. That allows your application serve a much larger number of simultaneous users than it could otherwise.

Session Beans persist information that can be forgotten after the user-session is over, or that is perhaps saved into the database (via an Entity Bean) once the user commits to their purpose.

Message Beans persist information about what tasks need to be performed later. For instance large numbers of users might input a lot of data into the system, which we want to analyze later when the system is less busy. We may want to run the report-generator once a night.

III.  IS THERE A BETTER WAY?

As described in the introduction we had a large number of EJBs in the legacy application, and they seemed to make it practically impossible to port the application to the latest JBoss version.

The system contained large number of interactions with these EJB classes, which could not be ported to Tomcat, because the EJB-classes are dynamically generated by JBoss. The exact XML-instructions for generating such 'Proxy classes' were only understood by JBoss-4, not by later versions of it.

But after analyzing how this particular application used EJBs, we realized it was relatively straightforward, although still tedious, to write our own Java classes which would replicate the functions of the EJBs.

Difference was that instead of writing XML to tell JBoss how to create the bean-classes we wrote the bean-classes ourselves. Which made it trivial to understand what they do, how they talk to the database, and how they persist data during the session to avoid unnecessary querying of the database.

The alternative mentioned in the beginning, direct JDBC calls, is still a possibility.  But it doesn't take care of the caching aspect. That might mean every programmer takes care of caching in their own way.  If instead we give them a common set of POJO-EJB classes  (PJBs?)  all team-members can take advantage of caching that comes with them. They don't need to know about SQL or the database-schema, they just need to be aware of the PJB -classes provided.

The system now runs on plain Tomcat, and we hope it will perform better because of it. At least Tomcat starts much faster than JBoss. If there are issues, we can always dive deep into the code to see where it could be optimized. It is much simpler to maintain and debug.

IV. SOME ADVICE

My intention here is not to bash EJBs or "app-servers" but to explain what they do. But once you understand what they do it is relatively easy to write something similar yourself, with Plain Old Java Objects (POJOs).

Newer versions of the EJB standard allow you to replace XML with Java's @-annotations. If you do that it is more likely your system will run also with future versions of different application servers. You get to keep the Java-code and annotations in the same source-file which makes it easier to understand how they work together.

But annotations are still much like XML. You can only assume their effect is what you think. Is it the same on every app-server (-version)?  You can't be 100% sure.  Whereas if you write plain Java code yourself, you can always read it and debug it, and SEE what it does.

Avoid using any features specific to your application server, even though that might be tempting at times. It would make it difficult to port to a different but better platform in the future. If you are a project manager it may be hard to control what your programmers do, how tightly they get coupled to a specific app-server. That is one reason to mandate the use of a simpler platform, a plain web-server like Tomcat.

If you opt for a full application server instead, consider compiling the app-server from the source. Then you can at least debug what it's doing, and possibly even fix some bugs yourself.

But be prepared for complexity overload. Application Servers are powerful, complicated, dangerous beasts. It takes a long time to tame your specific tiger. Choosing one over another is a long-term investment which requires continual re-education from you and your team.

 © 2014 Panu Viljamaa. All rights reserved