A Case Against EJBby 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.
RemotabilityThis 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
book). Therefore, it is questionable how useful the distributed nature of EJBs
SecurityI 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
SiteMinder for security.
PersistenceDoes 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.
CachingI 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.
ScalabilityTo 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.
MessagingOne 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.
TransactioningPlain 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.
ConclusionSo 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.