Implementing POJOs with EJB 3 - POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks - page 361

Most of this topic has focused on implementing POJO business logic using the
lightweight alternatives to EJB : Spring, Hibernate, and JDO . So why discuss EJB s?
After all, an EJB as defined by the EJB 2 specification is the ultimate anti- POJO . It
is a heavyweight object that implements special interfaces and can only run
inside the EJB container. To use the valuable features of EJB , which include stan-
dardized declarative transaction management, distributed transactions, and per-
sistence, developers had to struggle with excessive complexity and long edit-
compile-debug cycles.
However, all of this has changed with EJB 3 , which embraces POJO s and is a rad-
ical improvement over its predecessor. EJB 3 session beans, entity beans, and mes-
sage-driven beans are POJO s and do not implement any special interfaces.
Deployment and configuration is considerably simpler. In addition, even though
entity beans are defined by the EJB expert group, they are intended to be the stan-
dard persistence framework for both J2EE and J2SE . As a result, EJB 3 provides the
valuable features of EJB 2 but with less complexity and pain. It is destined to be
both an important and an effective technology for developing enterprise Java
applications. Let's see how EJB 3 works.
10.1 Overview of EJB 3
EJB is intended to be the standard component architecture for building Java busi-
ness applications. The primary goal of EJB 3 , which is part of Java Enterprise Edi-
tion 5 ( JEE 5 ), is to make EJB easier to use, and it incorporates some of the
lightweight concepts that you encountered earlier in this topic. EJB 3 still provides
session, message-driven, and entity beans, but how you write them and configure
them is very different and a lot simpler. EJB 3 Enterprise JavaBeans are POJO s,
which makes them easier to write. You have the choice of using either Java 5 anno-
tations or an XML deployment descriptor to configure an EJB. EJB 3 has sensible
defaults for many bean attributes, such as the JNDI name and transactional behav-
ior, which means that you do not have to explicitly specify every aspect of the
bean. In addition, session and message-driven beans can use dependency injec-
tion instead of JNDI calls to access other beans and resources, which simplifies the
code and further decouples it from the EJB container. EJB 3 has a powerful ORM
mechanism that incorporates many of the ideas from Hibernate, JDO , and Oracle
TopLink. What's more, EJB 3 entity beans can run outside the container, which
makes testing much easier.
EJB 3 as defined by the June 2005 public draft [ EJB 3 June 2005] also has some
significant limitations. The O/R mapping lacks necessary features such as collec-
tions of primitive types. Dependency injection only supports injecting JNDI objects