Like most of my colleagues, I was excited by the promise
of EJB when it first appeared. I believed it was the way forward for
enterprise middleware. However, I've since revised my opinions, in the light
of my experiences and those of many colleagues.
Much has changed since the EJB specification was conceived:
Parts of the specification's design now seem dated.
For example, dynamic proxies, introduced in J2SE 1.3, call into question the
container code generation envisaged in the EJB specification and the
multiple source files needed to implement every EJB.
The traditional link between EJB and RMI remoting is
looking dated, because of the emergence of web services and the recognition
that EJBs sometimes need only local interfaces. EJB is a heavyweight model
for objects that don't need to offer remote access.
This is a special case of the fact that basing typical
applications around distributed business objects-the architectural choice
EJB implements best-has proved problematic.
Usage of EJB indicates its strengths and weaknesses.
Most developers and architects have restricted their use of EJB to stateless
session beans and (if asynchronous calls are needed) message-driven beans.
The relative simplicity of the services provided by the EJB container to
support SLSBs means that the overhead of an EJB container is hard to justify
in such applications.
Although EJB has been around for five years, and its
use is a given in many J2EE projects, it has become apparent that its
complexity means that many developers still don't understand it. For
example, many developer candidates I interview can't correctly describe how
EJB containers handle exceptions and how this relates to transaction
The EJB specification is becoming more and more
complex in an attempt to address problems with EJB. It's now so long and
complex that few developers or architects will have time to read and
understand it. With specifications, as with applications, the need for
continual workarounds and constantly growing complexity suggests fundamental
The complexity of EJB means that productivity in EJB
applications is relatively poor. A number of tools try to address this, from
'Enterprise' IDEs to XDoclet and other code generation tools, but the
complexity still lurks under the surface and imposes ongoing costs.
Rigorous unit testing and test driven
development have become increasingly, and deservedly, popular. It's
become clear that applications making heavy use of EJB are hard to test.
Developing EJB applications test first requires a lot of
fancy footwork; essentially, minimization of the dependence of application
code on the EJB container.
The emergence of Aspect Oriented
Programming (AOP) points the way to more powerful-yet potentially
simpler-approaches to the middleware problems addressed by EJB. AOP can be
viewed in part as a more general application of the central EJB concepts,
although of course it's much more than a potential replacement to EJB.
Source level metadata attributes, as used in .NET,
suggest a superior alternative in many cases to the verbose XML-based
deployment descriptors used since EJB 1.1. EJB 3.0 looks like it's heading
down that road as well, but it's a way off and will carry a lot of baggage.
Experience has also shown EJB to incur greater cost and
deliver fewer benefits than were initially predicted. Developers have
encountered intractable problems that weren't apparent when EJB first
appeared. Experience has shown that EJB fails to deliver in several areas:
It doesn't necessarily reduce complexity. It
introduces a lot of complexity.
The entity bean experiment for persistence has largely
Applications using EJB tend to be less portable
between application servers than applications using other J2EE technologies,
such as servlets.
Despite the promises that EJB would prove the key to
scalability, EJB systems often perform poorly and don't necessarily scale up
well. Although statistics are hard to come by, anecdotal evidence suggests
that the overhead of excessive use of EJB necessitates re-architecture or
causes outright failure in a significant number of projects.
EJB can make simple things hard. For example, the
Singleton design pattern (or alternatives) is hard to implement in EJB.
All of these issues suggest that it's wise to analyze exactly
what the value proposition is before using EJB. I hope to equip you with the
tools to do this effectively and dispassionately.