Preface – EJB 3 in Action


In its early days, EJB was inspired by the distributed computing ideas of technologies such as CORBA and was intended to add scalability to server-side applications. EJB and J2EE enjoyed some of the greatest buzz in the industry during the boom.

The initial goal for EJB was to provide a simpler alternative to CORBA through components and framework benefits—but the component benefits were oversold. By the time EJB 2 was released, it became apparent that EJB could be used as a framework to make server-side development easier—but it was complicated. It became a heavy framework that provided features such as remoting, transaction management, security, state maintenance, persistence, and web services. It was loaded with more features with each release, and while the development tools matured, its inventors failed to address the growing complexity.

As the community became disenchanted with the limitations of EJB 2, innovative open source tools like Spring and Hibernate emerged. They, along with the creeping dominance of Microsoft.NET and the rise of scripting frameworks like Ruby on Rails, were signs of the increasing discontent with the complexities of Java. It was time for JCP and expert groups to work on the simplification of Java development. That was the sole motivation behind Java EE 5 and the goal of the EJB 3 Expert through Group.

For a technology with a wide deployment base, the changes to EJB 3 are nothing short of stunning. EJB 3 successfully melds innovative techniques to make component development as easy as possible. These techniques include Java 5 annotations, metadata programming, dependency injection, AspectJ-like interceptors, as well as intelligent defaulting. The heavyweight inheritance-based programming model was abandoned in favor of POJO programming and the verbose XML descriptor was now out of the developer’s way.

The changes to the persistence model were particularly dramatic. EJB 3 leaves behind the flawed Entity Beans model in favor of the lightweight Java Persistence API (JPA). Unlike Entity Beans, JPA is not container-based. It has more in common with Object Relational Mapping tools such as Hibernate, Oracle TopLink, and JDO than it does with EJB2 CMP Entity Beans. It can be used either inside or outside the container and aims to become the de-facto persistence standard for Java. Its Java Persistence Query Language (JPQL) standardizes object relational queries and supports native SQL queries.

We liked the changes made in EJB 3. The simplification of the EJB 3 specification has been well received in the Java community. Even the competing Spring framework has integrated with JPA and is implementing some features of EJB 3.

Since EJB is POJO-based, every Java developer can easily become an EJB developer! We felt the need for an EJB 3 book that presents the technology with a fresh approach without too much legacy EJB 2. Together, the three of us have significant experience using EJB 3, ORM, and lightweight frameworks like Spring. We have strived to keep our book different from other books on EJB 2 and EJB 3 by providing practical examples, best practices, and tips for performance tuning. We do not overlook the case made for competing frameworks such as Spring and do not hesitate to recommend them when these frameworks make sense. In fact, we have dedicated a complete chapter on the interoperability of Spring with EJB 3.

We hope that you can use this book to quickly learn how to use EJB 3 effectively in your next enterprise applications.