Each Spring bean definition includes a name, an implementation class, and one or more dependencies, which are supplied by either constructor or setter injection. When the presentation tier asks the bean factory to create a MoneyTransferService, first it will instantiate an AccountDAOHibernateImpl, which is the Hibernate implementation of the AccountDAO interface. The bean factory will then instantiate the MoneyTransferServiceImpl passing the AccountDAOHibernateImpl to its constructor.

Spring provides an extremely flexible dependency injection mechanism. It can inject aribitrary POJOs in POJOs. Spring can even, for example, do a JNDI lookup to get an object and inject it into a POJO.

EJB 3 Dependency Injection
In comparison, EJB 3 dependency injection is limited to injecting values from JNDI into either session beans or message-driven beans. You can configure field or setter injection using either XML or annotations. Listing 2 shows how you could inject an AccountDAO into a MoneyTransferServiceImpl using an annotation.

In this example, the @EJB annotation specifies that when the EJB 3 container instantiates a MoneyTransferServiceImpl it must initialize the accountDAO field with a reference to an AccountDAO. Behind the scenes, the EJB 3 container does a JNDI lookup of the AccountDAO, which is also implemented as a session bean. If the MoneyTransferServiceImpl called the EJB 3 persistence APIs directly then you'd simply inject the EJB 3 EntityManager directly.

Dependency injection is one of the cornerstones of POJO development. Another one is the ability to persist POJOs with an object/relational mapping (ORM) framework.

Persisting POJOs
POJOs often have to be persisted in a relational database. For example, the Money Transfer application must store Account objects in the ACCOUNT table. It could, of course, access the database using JDBC or iBATIS. Sometimes this is the right approach. But unless you have a really simple object model, it can be a lot of work to develop and maintain the Data Access Objects (DAOs) and the SQL needed to transfer objects to and from the database. It's usually a lot easier to use an ORM framework.

An Overview of ORM
When using an ORM framework you declaratively specify how your object model maps to the database schema. You specify how classes map to tables; fields map to columns, and relationships map to either foreign keys or join tables. The ORM framework then generates the SQL statements to create, find, update, and delete persistent objects. It also keeps track of which objects have changed and automatically writes them back to the database. As a result, you have to write a lot less code. Moreover, it's usually a lot easier to switch databases because the ORM framework is generating the SQL for you.

EJB 2 CMP provides a primitive form of ORM. However, it requires your classes to implement or extend EJB interfaces. In comparison, modern ORM frameworks such as Hibernate, JDO, and EJB 3 provide what's termed transparent persistence. Apart from perhaps having to add a field to store the primary key, the code for the objects shows no sign that they are persistent. The only classes that are dependent on the ORM framework are classes such as DAOs that create, find, and delete persistent objects. Let's look at an example.

Declarative Mapping
When using an ORM framework you define the mapping using either XML or Java 5 annotations. Table 1 shows how you map the Account class to the ACCOUNT table using EJB 3 annotations and a Hibernate 3 XML mapping document.

In each example, the Account class is mapped to the ACCOUNT table; the id field that stores the primary key is mapped to the ACCOUNT_ID column; and the balance field is mapped to the BALANCE column.

AccountDAOHibernateImpl
Once you've defined the mapping you can use the ORM framework's API for creating, finding, and deleting persistent objects. The APIs provided by each of the ORM frameworks are pretty similar. Here's an example of a DAO that uses a Spring HibernateTemplate, which is an ease-of-use wrapper around the Hibernate APIs:

public class AccountDAOHibernateImpl
   implements AccountDAO {
     private HibernateTemplate hibernateTemplate;
     public AccountDAOHibernateImpl(HibernateTemplatetemplate) {
     hibernateTemplate = template;
   }
     public Account findAccount(String accountId) {
     return (Account) hibernateTemplate.get(new Integer(accountId));
   }
...
}

The HibernateTemplate is passed to the AccountDAOHibernateImpl using constructor injection. The findAccount() method loads an account by calling HibernateTemplate.get(). When get() is called, Hibernate generates and executes a SELECT to load the corresponding row from the ACCOUNT table. If the Account object is then modified by the application, Hibernate will execute an UPDATE statement to save the changes in the database. An EJB 3 DAO would work the same way. It would call the EJB 3 EntityManager to create, find, and delete persistent objects.

But There Are Also Some Drawbacks and Limitations
When used appropriately ORM is an extremely powerful tool that can significantly increase development productivity while providing excellent performance. But like every tool, it has its limitations. For example, an ORM framework might not be a good choice in the following situations:

• Your application accesses a denormalized legacy schema
• Your DBA insists on inspecting your SQL statements
• Your DBA requires all database accesses to go through stored procedures.
• Your application must perform bulk updates or inserts.

Making POJOs Transactional
Transactions are an essential part of the Enterprise Java application. Without them we risk corrupting data. Consider, for example, the MoneyTransferService shown earlier in Listing 2. It's vital that when the transfer() method executes in a transaction that you ensure that updates are made atomically. Otherwise, if the application crashes after debiting one account but before crediting the other account the money could disappear into the ether.

One of the nice features of EJB2 session beans is its support for container-managed transactions, which are a form of declarative transaction management. They simplify the application and make it more reliable by eliminating error-prone transaction management code. In a POJO application, the two main ways to implement declarative transaction management are to use either the Spring framework or EJB 3. Both frameworks use either Java 5 annotations or XML to specify the transactional attributes of a POJO.

Spring Transaction Management
The Spring bean factory does more than simply instantiate objects. It can also wrap the objects that it creates with interceptors (a k a proxies). These interceptors are how Spring provides a simple, yet effective Aspect-Oriented programming (AOP) implementation. AOP is the foundation of Spring transaction management. To make a POJO transactional you configure the bean factory to wrap it with TransactionInterceptor, which executes method calls within a transaction.

Spring provides a couple of ways to configure the bean factory to apply the TransactionInterceptor. One option is to use the @Transactional annotation on the interface, implementation class, or individual methods. For example:

@Transactional interface MoneyTransferService {...}

The @Transactional specifies that when the Spring bean factory instantiates the MoneyTransferServiceImpl that implements the interface, it must apply TransactionInterceptor.

Another option is to write XML bean definitions that explicitly apply the TransactionInterceptor to the POJO. Here's an example bean definition that uses the Spring BeanNameAutoProxyCreator to apply a TransactionInterceptor to the MoneyTransferService.

<bean id="transactionProxyCreator"
class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator"
   <property name="beanNames">
    <list>
   <idref bean="moneyTransferService" />
    </list>
</property>
<property name="interceptorNames">
    <list>
     <idref bean="transactionInterceptor" />
    </list>
</property>
</bean>

The XML is more verbose than the annotation but has the advantage of leaving the source code unchanged. It also works with older JDKs that don't support annotations.

Spring doesn't implement transactions itself but is, instead, a wrapper around other transaction management APIs. Unlike EJB 3, it gives you the flexibility of using either JTA (as provided by an application server) or the transaction management APIs provided by ORM frameworks such as Hibernate and JDO.