EJB Under the Spotlight

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
  management.

• 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
  problems.

• 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
  failed.

• 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.