EJB was once hailed as the core of J2EE. Like most Java architects and developers, I was initially excited by EJB, and believed that it offered the best solution to many enterprise problems.
Unfortunately, the experience of the last five years has taken a lot of the gloss off EJB. I now think of EJB more as a transitional technology that popularized many worthwhile ideas, than as the best choice for most new applications.
In this chapter we'll look at the lessons from EJB, and how I believe that we can enjoy many of its valuable ideas without accepting the significant disadvantages of EJB.
EJB was intended to simplify enterprise development. The EJB 1.0 specification promised that:
Enterprise JavaBeans will make it easy to write applications. Application developers will not have to understand low-level transaction and state management details; multi-threading; resource pooling; and other complex low-level APIs.
Instead of concerning themselves with system-level issues, application developers would be able to concentrate on their domain and on writing business logic.
The EJB specification also promised portability of EJBs and EJB-based applications between application servers:
Enterprise JavaBeans will follow the "write-once, run anywhere" philosophy of the Java programming language. An enterprise Bean can be developed once, and then deployed on multiple platforms without recompilation or source code modification.
Have these expectations been ...