The Java Persistence API (JPA), a part of the EJB3 specifications, is gradually finding its way into the major open-source enterprise frameworks. Spring 2's support of JPA is one example of that trend.

In a detailed IBM DeveloperWorks tutorial, Introduction to Spring 2 and JPA (free registration required), Sing Li walks through a complete Spring 2 application that relies on JPA for its persistence:

JPA persistence is part of EJB 3.0, which in turn is part of the Java EE 5 specification, implying that all compatible Java EE 5 servers (commercial, open source, or otherwise) will have compliant implementations. This practically guarantees the availability of robust, high-quality JPA implementations in the near future... Although Spring 2 leverages JPA persistence from the EJB 3.0 specification, users of Spring 2 are under no further obligation to employ any other elements of the EJB 3.0 or Java EE 5 specifications.

Li points out that "in addition to JPA, Spring also supports other ORM technologies such as JDO, Hibernate, iBATIS SQL Maps, and Apache OJB." And Spring 2 adds a few features to JPA, too:

In addition to transparent database operations, Spring 2's JPA support also converts a potpourri of database-vendor-specific exceptions to a set of well-defined exceptions to make exception-handling code a lot simpler

Li's article starts out with a complete domain model analysis, and then turns to the task of persisting that model through Spring's DAO API:

Spring DAO implements the well-known DAO design pattern [that] provides a consistent facade for access to data. Data fetch and modification are performed through a transfer object. The DAO encapsulates the actual data source and provides methods to work with the transfer object.

Architecturally, the DAO APIs shield you from the complexity of working with actual data persistence API calls... The Spring DAO API also provides support classes that you can readily extend... These classes encapsulate the connection and transaction-management code that is often found intermixed with application logic.

In the case of JPA support classes, the use of a JPA entity manager is completely encapsulated within the support class, freeing you from the concern of working with entity managers and an entity manager factory.

The remainder of Li's article focuses on Spring 2's dependency injection and MVC features, and how these help shield a developer even from the rather simple JPA persistence API. Instead, developers mostly interact with a domain model in Spring 2.

If you have an existing enterprise application that uses one of the popular frameworks, such as Spring, are you planning on switching to JPA from another persistence framework? If so, why?