Thursday, January 13, 2005

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

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

No comments: