EJB Backlash

EJB Backlash: A Developer's Story

By Mitch Stuart
Copyright © 2005 FullSpan Software - Usage subject to license
Document Version: $Revision: 1.5 $, $Date: 2005/11/28 02:21:26 $

Introduction

Following the launch of the Java 2 Platform, Enterprise Edition (J2EE), Enterprise JavaBeans (EJB) was considered an essential component of the architecture. In fact, if you developed an application without EJBs, many people would say it was not a "real" J2EE application.

However, in the past couple of years, there has been a significant and growing backlash against EJB. Among other things, we now see:

Books about non-EJB-based development, like Expert One-on-One J2EE Development without EJB and Better, Faster, Lighter Java.
Successful lightweight frameworks like Spring and PicoContainer.
Successful data management libraries like Hibernate.
The EJB 3.0 draft specification taking into account many of the complaints against earlier versions.

My reaction to all of this is: it's about time. In this article, I recount my personal backlash against EJBs, which started in the late 1990s. There were probably others who fought the same battle as me, but we were far outnumbered by all those jumping on the EJB buzzword bandwagon. During those days, I endured skepticism sometimes verging on ridicule when I argued against using EJBs. Now it's my turn to vent.

Note: there are several types of EJBs, including Session Beans, Entity Beans, and later, Message-Driven Beans. This article focuses entirely on Entity Beans, which are used to represent application data, typically stored in a relational database.

In part, this article discusses my experiences with particular projects in jobs that I have held. I've disguised the names of my employers by calling them Able, Baker, etc. (But since my resume is posted publicly, it would not be difficult to figure out which companies I'm talking about.)

The Able Company

At the Able company, I was one of the first developers hired, so we could build the data and object layers using whatever technology worked best. At that time, EJB was a "hot" technology, so we did some research and prototyping with EJBs. I believe that the EJB specification during this time was at version 1.1.

My impressions of EJB were:

Complex and tedious to develop; would not scale well from a time-to-market perspective. At that time there were few if any tools to assist with developing the boilerplate code and deployment descriptors.
Very much focused on "distributed objects", with "object persistence" as just one of several high-level features. There should have been a much stronger focus on persistence. Distributed objects is a specialized feature that should be optional, and not part of the core operating model.
The threading and concurrency limitations were troubling. Multiple threads were not allowed to concurrently access a bean, and developers were not supposed to launch their own threads.
The specification left a lot of things up to the EJB container vendors. It's fine to leave implementation details to the vendors, but it seemed that there was too much latitude for important semantics to differ, or to simply be undocumented. For example, I remember spending a long time researching the interaction between HTTP session lifetime, object reachability, garbage collection, and EJB passivation. It seemed to me that the spec should have been more clear.

To summarize, I felt strongly that EJBs did not offer sufficent "bang for the buck", particularly for a typical enterprise application that would already be hosted in a deployment environment such as a servlet container. Certainly some features were very nice, such as declarative transaction scope. But these benefits were not worth the pain and drawbacks of the overall EJB model.

At Able, we ended up using servlets, JavaServer Pages (JSPs), and the TopLink object/relational mapping layer. At the time, TopLink was the product of a small software company, but it has been through two acquisitions and is now owned by Oracle (there is an interesting history here). This approach turned out to be very productive and stable.

The Baker Company

When I joined the Baker company, the 1.0 Beta version of their product had just been released. This version used EJBs for the backend persistence. I was not happy about that, but what could I do - I was a new employee, not in any position to get on my anti-EJB soapbox. I believe that the EJB specification during this time was at version 2.0.

One of my first tasks was to improve the performance (end-user response time) of the application. One technique that I used was to convert the front-end-to-back-end communication from fine-grained to coarse-grained. Instead of making a round-trip to the EJB for each property access, I created a "summary object" that would be populated and passed back and forth. This (and other changes including tuning the bean-managed SQL) resulted in performance gains from 70% to 200%.

Despite the performance gains, we were still suffering from EJB performance issues. First, we had heavy concurrent access to the same data, and because of EJB's restriction on multiple-thread access, we were experiencing blockage of our servlet threads that were waiting for the EJB to become available. As far as I know, this was an implicit architectural feature of EJBs, and could not be solved cleanly at the application level. We ended up introducing our own caching layer, but this just seemed ridiculous to me - isn't this what the infrastructure should provide for us?

The second continuing problem is that we could not figure out why the EJB plumbing seemed to introduce so much overhead. We were using a well-known commercial application server. Because our front-end (servlet/JSP) and back-end (EJB) were running in the same JVM, we determined that the RMI plumbing was short-circuited in this in-process case, and simple object references were being passed around (as opposed to proxies and marshalled objects). We determined this from talking from to the application vendor support staff and from our own empirical testing. This was shocking to me in two ways:

This seemed to break the isolation contract expected by EJB developers. For example, depending on the deployment scenario, the EJB might either get a direct reference or a marshalled clone of an argument. Thus, the behavior of an application could differ significantly depending on its deployment. An example would be developing in a self-contained EJB engine, and then deploying in a distributed engine.
Even within a single JVM, the EJB plumbing seemed to add significant overhead. We were never able to understand why, either by talking to the application server vendor or from our own profiling.

After the initial tuning and profiling efforts were complete, development split into two parallel tracks. I started to work on 2.0, and another team started to work on 1.x maintenance releases. For the 1.x team, I provided them with some prototype code to continue with the coarse granularity property access approach, which they expanded on and put into production (they called them "page objects"). Versions from 1.2 to 1.5 used EJB as the underlying persistence mechanism, with some home-grown additions such as page objects.

EJBs on the Scrap Heap

For the 2.0 release, I completely eliminated EJBs from the product. My goals were:

Streamline the development process for faster time to market. This is what I call "development scalability" (as opposed to "runtime scalability"). Previously we had dedicated front-end and back-end teams. With 2.0 and beyond, we switched to a vertical "feature oriented" team approach, where a given team or individual would own the entire implementation of a feature, from GUI to database and everything in between. Certainly we all had specialties that were called upon from time to time (we had JavaScript gurus, SQL gurus, etc.), but the general approach was to instill pride (and responsibility) of ownership.
Eliminate the performance and concurrency problems we were experiencing in the persistence layer.

In retrospect, it is amazing to me that I had the guts to pursue this approach. After all, this was yanking out a major infrastructure component (EJB) that was functionally working, and replacing it with a home-grown layer. I am usually quite conservative when making major design changes. I was just so frustrated with EJBs that I was willing to do a lot of work (and take a lot of risk) to eliminate that frustration. Some of this was also due to my natural skepticism. EJBs were all the rage, they were implicitly part of every J2EE application, and yet I wasn't hearing a lot of success stories or justification for all the effort and drawbacks associated with EJBs. I felt that I had to stand up and say "the emperor has no clothes".

As I remember it, I did some prototype code, and wrote up a brief design document for the new persistence layer, and the rest of the team said, in effect, "if you feel good about it, go for it". Thanks to everyone who gave me support in those days.

The persistence layer that I designed was a thin layer around JDBC. No attempt was made to do object/relational mapping or to hide the fact that we were using SQL and a relational database. The design centered around my custom implementation of Sun's CachedRowSet. A CachedRowSet (unlike a normal JDBC ResultSet or RowSet) allows the data to be used even after the underlying database connection is closed, so it is well suited to passing around the various layers of an application. An example would be saving one or more business objects in the HTTP session of a servlet container, in between HTTP requests. Even though each HTTP request gets a new database connection from the pool, the saved objects in the session are valid regardless of the database connection state.

Baker's persistence layer turned out to be extremely successful. It was very fast and robust. After some tuning, my CachedRowSet implementation was measured as 2x faster and 30% more memory-efficient than the Beta implementation released by Sun. Later, I added object caching (with coherence across the app server cluster), which improved data access response time dramatically.

The persistence layer achieved its goals of development scalability and runtime performance and robustness. On the downside, the layer required too much knowledge of the data model by the staff. It should not be expected or required that every developer is a data modeling and SQL expert. Also, the very "thin-ness" of the layer did not lend itself to promoting the best object oriented practices in client code. It would be better to keep the lightweight nature of the persistence layer, but with less "leakage" into other layers of the application. This is the technique that I'm using in the Charlie project, discussed later.

EJBs on Developer Resumes

During the good old days of the Baker company's heyday, we were interviewing lots of software developers. I had an amazing number of conversations that went like this:

Candidate: Do you use J2EE?
Me: Yes. We use Servlets, JSPs, JDBC. We're not using EJB though.
Candidate: Why not?
Me: [Here I would give a condensed description of the issues mentioned above.]
Candidate: Oh.

We had candidates that would actually decline to continue with the interview process because we were not using EJBs. I can understand that a developer would not want to throw away whatever investment they had made in learning to develop EJBs. But the bandwagon effect was so strong, I felt that the candidates were acting without considering the actual logic of their position.

EJB Suitability to Task

A common statement in the pro-EJB camp was "You need to know when to use EJBs and when not to. You should only use them for the parts of your application that make sense." I rememember hearing this in a JavaOne EJB presentation, and several other places. My reaction to this was: you have to be kidding me. It just seems bizarre to invest in all the learning and infrastructure to make your application EJB-based, and then to say, oh for these parts over here we're going to use direct JDBC.

The Charlie Project

In the Charlie project that I am working on now, I am using Hibernate for persistence, with a small utility class to manage the Hibernate sessions (i.e., the database connections/transactions). I have a servlet filter to control the transaction scope, although it can also be controlled manually for finer control (or for running outside the servlet container, such as with unit tests or other standalone applications). This is working great, and it seems to be a good compromise between object oriented "purity" and the practical considerations for a productive, robust, and well-performing persistence layer.

The Future of EJB

Sun and the other stakeholders in the EJB world have not ignored the criticisms of earlier EJB releases. They have published a draft of the EJB 3.0 specification, with the stated goal of "improv[ing] the EJB architecture by reducing its complexity from the developer's point of view".

Gavin King, founder of the successful Hibernate object/relational persistence library, is a major contributor to the EJB 3.0 design. It is interesting to read his thoughts on Entity Beans in EJB3 [PDF file] and why EJB 3.0 may be the new JavaBeans.

A couple of years from now, I may have to forget everything I used to hate about EJBs and try them in a new project.