Focusing on open APIs for enterprise applications

Open Web Magazine

Subscribe to Open Web Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Open Web Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Open Web Authors: Bob Gourley, Kevin Benedict, Pat Romanski, PR.com Newswire, RealWire News Distribution

Related Topics: Java EE Journal, Apache Web Server Journal, Java Developer Magazine, Open Web Magazine

J2EE Journal: Article

Java Feature — Using the Java Persistence API (JPA) with Spring 2.0

How to use JPA in new or existing Spring applications to achieve standardized persistence

The EJB 3.0 Java Persistence API (JPA) was released in May 2006 as part of the Java Enterprise Edition 5 (Java EE) platform, and it has already garnered a great deal of attention and praise. What began as merely an easier-to-use successor to the much-maligned container-managed persistence (CMP) portion of the EJB component standard soon evolved into a full-blown incorporation of the existing best practices of the most prominent and popular object-relational (O-R) persistence products in use. The result is that applications now have a modern standard for lightweight enterprise Java persistence that they can use in any compliant Java EE 5 application server, or in Java Standard Edition (SE) applications.

The Spring application framework has been in existence for four years, and it has become a popular choice both in an application server context and standalone. Like JPA, Spring is a technology designed to allow applications to be built from POJOs. The Spring Framework runs within whatever runtime context an application requires, and it supports applications by providing a wide range of services. Some of these services are abstractions over existing container-level services, whereas others add value to the Java EE container. The persistence access layer, which is particularly popular with the Spring community, is nicely integrated with whatever persistence runtime is being used and facilitates a sound testable architectural approach to working with persistent objects. Spring 1.x included support for a variety of open source and commercial persistence implementations such as TopLink, Hibernate, iBATIS, and JDO, as well as the standard Java database connectivity (JDBC) API that's part of the Java runtime. Spring 2.0 was a major milestone and introduced additional integrated support for JPA. In this article we'll discuss how to use Spring and JPA together and highlight some of the benefits that this architecture can bring to an application.

Spring as a JPA Container
The Java Persistence API was architected so it could be used both inside and outside a Java EE 5 container. When there's no container to manage JPA entity managers and transactions, the application must bear more of the management burden. When running in a JPA container the user experience is more hospitable.

One goal of the JPA specification was to make the technology pluggable. To enable this, the roles of container provider (the container or the side that has control of the runtime threads and transactions), and persistence provider (the provider or the part that implements the persistence API and manages the persistent entities) were defined, and a service provider interface (SPI) binds the two at deployment and runtime. A compliant JPA host container correctly implements this SPI from the container perspective. A compliant JPA persistence provider implements the SPI from the provider perspective. If both sides follow the rules, a compliant container should be able to run any compliant persistence provider implementation, and similarly, a provider should plug into any container.

Although Spring is neither an application server nor a Java EE 5 container, it does enhance, augment, and sometimes implement many of the services used in application servers. Spring 2.0 implements the container portion of the JPA SPI so it can be viewed as a JPA container. As such, it provides the class-loading and weaving support that JPA providers use to help manage the entities at runtime. Users benefit from an environment in which the runtime container and the JPA persistence provider are tightly integrated, but not necessarily in a Java EE 5 context. This provides many of the benefits of Java EE persistence without requiring a Java EE container.

Defining Entities
The most basic part of using JPA is to design and create the entities to be persisted. For the purposes of this article, we will use an extremely simplified library book inventory system with a single entity to illustrate the concepts concretely in Java code.

We'll create a simple Book entity by defining the class and annotating it with an @Entity annotation. The table that stores book instances will default to BOOK, which is exactly what we want. The primary key identifier is the isbn field, so we annotate that field with @Id. Because the title and author fields are basic mappings from the object fields to columns of the same name in the database table, we don't have to do anything to them. We want the genre field to map to a database column named CATEGORY, so we give it a @Column annotation. The resulting Book entity class is shown below.

package org.bookguru;

import javax.persistence.*;
@Entity
public class Book {

    @Id private int isbn;

    private String title;

    private String author;

    @Column(name="CATEGORY")
    private Genre genre;

    // Constructors, getters and setters, etc.
}

Of course a real application would have many entities, but because we want to focus on the use of JPA in Spring, we won't explain how to define and map JPA entities. For more information on defining JPA entities see Pro EJB 3: Java Persistence API.

Using JPA Entities in Spring
The primary way to operate on entities is by using an entity manager. The EntityManager API is the main gateway into JPA and supports basic create/read/update/delete (CRUD) operations. It acts as both a manager of all loaded entities and a factory for queries that enable more entities to be loaded. An entity manager is analogous to an Oracle TopLink session, Hibernate session or an equivalent interface provided by many O-R mapping frameworks.

For example, to create a new persistent entity we would simply create a new Java object of the correct entity type, invoke the persist() method on the entity manager, and pass the new entity as a parameter. Assuming we have access to an entity manager, the code to create a new book is simple.

    Book book = new Book(12769356, "War and Peace", "Leo Tolstoy", Genre.FICTION);
    entityManager.persist(book);

Using JPA and the entity manager in Spring is very simple. In most cases it's simply a matter of annotating a field or method of a Spring bean with @PersistenceContext, which causes an entity manager to be injected. Then invoke the entity manager in the context of a container transaction. Note that @PersistenceContext is a standard JPA annotation and not specific to Spring.


More Stories By Mike Keith

Mike Keith has more than 15 years of teaching, research and practical experience in object-oriented and distributed systems, specializing in object persistence. He was the co-specification lead for EJB 3.0 (JSR 220), a member of the Java EE 5 expert group (JSR 244) and co-authored the premier JPA reference book Pro EJB 3: Java Persistence API. Mike is currently a persistence architect for Oracle and a popular speaker at numerous conferences and events around the world.

More Stories By Rod Johnson

Rod Johnson is the senior vice president of the Application Platform Division at VMware with more than 12 years of technology and management experience. Founder of the Spring Framework, he continues to guide the direction of Spring and is a member of the Java Community Process Executive Committee.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
GIUSEPPE SCHIAVO 11/09/07 05:04:51 PM EST

Very disappointing. I though Rod Johnson would have done much better than this.
There is no link to download a working example plus there is at least one error. The bean definition below, which is included in the article, violates the schema definition because the attribute class cannot be defined in a property element. :(

http://java.sys-con.com/read/36

Rob Bygrave 04/29/07 06:56:41 AM EDT

In regards this point:
>>
The Java Persistence API was architected so it could be used both inside and outside a Java EE 5 container. When there's no container to manage JPA entity managers and transactions, the application must bear more of the management burden.
<<
Is there any plan to have JPA provide a "Stateless" or "Sessionless" architecture - where there would be no requirement to manage EntityManager's?

(and would make using JPA outside a container much simpler)