A Case Against EJB

by Chris Mathews

These days, it is becoming harder and harder for me to find cases where I think EJB is appropriate. However, that says as much or more about my personal changes in thinking and development practices as it does about EJB. This article will explore the reasons that are most often cited for using EJBs and discuss how practical they are in real-world solutions.

Remotability

This one is fairly easy to understand. However, most pragmatic developers now try to stay away from large distributed systems unless it is absolutely necessary. The reason is that they don't usually pay off. The perceived decoupling advantage never really pulls it weight and these systems always seem to perform like dogs. Martin Fowler had a nice article (requires registration) describing the evils of unnecessarily distributed systems in Software Development Magazine last year (from content in his PEAA book). Therefore, it is questionable how useful the distributed nature of EJBs actually is.

Security

I don't know about you but I have never really considered J2EE Security a proper solution. There are huge gaps missing from the J2EE Specification for things such as user management and Single Sign-On (SSO). This all adds up to the fact that it is hard to pull off using J2EE Security for real-world solutions without pervasive use of vendor extensions. I thought the whole reason for including security in the spec was to allow for a portable solution. Unfortunately, reality tells a different story and, for that reason, most projects that I have ever worked on have relied third-party solutions such as Netegrity SiteMinder for security.

Persistence

Does anybody actually like working with CMP Beans? I certainly do not. They are hard to develop (almost bearable if you are using XDoclet), hard to test (in-Container testing is the only option here), and not very flexible. Luckily, there are many other persistence options that are more than a match for CMP. My current favorite is Hibernate. This tool just rocks! It supports everything that was good about CMP and has none of the ugly warts that make using CMP such a pain. Sure you still have configuration files, but only one and it is easily managed. You can even use XDoclet to generate your Hibernate configuration file if you want. The best thing about Hibernate (and JDO for that matter) is that it works off of Plain Old Java Objects (POJOs) which make development and testing very easy.

Caching

I actually think this one is a bit of a red herring, always tossed in by the big players to throw us off their trail. While some form of caching is implemented in any decent EJB Container... none of the major EJB Containers support a truly distributed cache out-of-the-box. Therefore, in a clustered environment, which is the norm for large EJB projects, a third-party solution is still required for good caching. Also consider that any good persistence tool supports some form caching as well, so EJBs still don't bring anything additional to the table. For example, Hibernate and most commercial JDO implementations also support distributed caching thru the use of third-party products such as Jakarta JCS, Tangosol Coherence, and EHCache. Whenever the JCache Specification is finally released (hurry up Cameron!) then I am sure that most will add support for that as well.

Scalability

To many people, EJB is synonymous with scalability. I am here to tell you that they are wrong! There is nothing about EJB that is inherently more scalable then any other technology. The real secret to scalability is that good software scales well and bad software scales poorly. This is universally true regardless of the technology that is used. An EJB Container can achieve scalability based on its ability to be clustered and load balanced. However, the same is true of most standard Servlet/JSP Containers and most other web technologies (Perl, PHP, and ASP) as well. Therefore, once again, EJB offers nothing in terms of scalability that cannot be achieved with a simpler solution. In fact, it is my experience that simpler solutions such as Servlet/JSP applications are much easier and cheaper to scale than full blown EJB applications. Remember, scalability is never free; you pay for it in the cost of designing good software.

So far things aren't looking very good for our old friend EJB... but we now come to the light at the end of the tunnel: Messaging and Transactioning.

Messaging

One of the very good things to come out of the EJB 2.0 Specification was the addition of Message Driven Beans. MDBs are quite simply fantastic. This is one area of the specification that they really nailed! MDBs are easy to use, develop, and test (in this case they are easy to mock out). I don't think I ever want to work on a large-scale messaging project without the use of MDBs.

Transactioning

Plain and simple - demarcating transactions in EJB is dead-easy. Using Two-Phase Commit in EJB is dead-easy. These two things hold a lot a weight for systems that have large-scale transactional requirements. In these cases using EJB makes a whole lot of sense, especially if you ever have to deal with 2PC and multiple transactional resources. I know that I am not about to try to reinvent the Transaction Manager wheel on any of my projects, it is just too risky. However, it is important to note that lightweight Frameworks such as Spring and even JBoss's Aspect Oriented Middleware are now showing up with transactional support similar to EJB that can be demarcated on POJOs. In these cases all you need is a JTA implementation and you are good to go. I don't think that this type of solution is quite ready for prime time in a high transactional volume system today but I have no doubt that at some point in the near future they will be. At that point, EJBs will lose their number one advantage.

Conclusion

So to recap... unless your project is making heavy use of transactions, messaging, or both then I think choosing EJB is a mistake. There are too many good alternatives out there to ignore. Even if EJB is chosen, I recommend keeping its use to a very limited capacity. Business logic should be encapsulated in POJOs and the persistence layer should be strictly decoupled from EJB (please no CMP). All of the above benefits of EJBs (with the exception of persistence and caching) can be easily achieved by using EJBs as a thin Decorator on top of POJOs. This type of architecture is easy to develop and test and takes full advantage of the services provided by EJB Containers.

In its current form it looks to me that EJB is on its way out (except in a legacy capacity), though I admit that it is still too early to tell for sure. I guess we will just have to wait and see what is in store for us with EJB 3.0. Suffice it to say, the Expert Group has a lot of catching up to do and I just hope they have the vision and desire to do bring EJB back to the promised land.