Using the Java Persistence API with Spring 2.0

Abstract

The Java Persistence API (JPA) and the version 2.0 release of the Spring Framework have been creating a lot of interest among developers. This article looks at how Spring 2.0 and JPA can be used with BEA WebLogic Server. In particular, we describe an updated version of WebLogic Server's medical records sample application that uses Spring and JPA. The article shows how Spring and JPA form a powerful combination that is the cornerstone of a simplified POJO-based application architecture. The major technologies used include WebLogic Server 9.1, Spring 2.0, and Kodo JPA.

Introduction

The Medical Records sample application (MedRec) is a comprehensive application that demonstrates how a number of technologies are used in WebLogic Server. These include open-source technologies such as Spring and Struts, as well as technologies native to WebLogic Server, such as Web services, JSPs, message-driven beans, and JDBC.

This article describes how the Java Persistence API (JPA) has been used in conjunction with the Spring Framework in an updated version of MedRec. An important goal is to show developers how Spring 2.0, WebLogic Server 9.1, and Kodo 4.0 can be used together. By reading this article developers will get a good introduction to using JPA as well as the new support for JPA that is in the Spring 2.0 release. The article also discusses the challenges that can arise when JavaBeans (POJOs) are reused in multiple tiers of an enterprise application. It is this reuse that is one of the key benefits of an application architecture based on Spring and JPA.

For those of you unfamiliar with the Java Persistence API, JPA is a new simplified API that specifies how Java objects can be stored in a database. JPA is being developed as part of EJB 3.0 ( JSR 220), since it will replace EJB 2.x entity beans, but it can be used in both J2EE and J2SE applications. One of the great things about JPA is that it is POJO-based. JPA also uses Java 5.0 annotations to simplify the way that the mapping from Java objects to a relational database is specified. BEA has announced the formation of OpenJPA, an open-source project based on Kodo that will be available soon, but you can get started right now using the Kodo 4.0 early access release.

The article begins by taking a general look at POJOs and data access in Spring. The next section gives an overview of the architecture of MedRec followed by a more detailed description of MedRec's data access layer. Then we take a detailed look at JPA persistent classes and discuss the design patterns that they are expected to follow. Finally, to tie everything together, we cover the XML configuration of Spring and Kodo JPA. Complete source code for MedRec is available for download with this article.

POJOs and Data Access in Spring

The Spring Framework is perhaps best known for having simplified the development of business components. Those familiar with Spring know that through the use of Inversion of Control (IoC) and aspect oriented programming (AOP), Spring allows developers to write powerful business components that are still regular JavaBeans, or POJOs (Plain Old Java Objects), as they are also often called.

For enterprise applications that need to access a database, Spring also provides a framework that simplifies the creation of data access objects (DAOs) that encapsulate access to persistent data. Spring's POJO theme carries over to the data access area as well, as both data access objects and the domain model objects that they query and modify can be POJOs.

Spring's use of the POJO pattern has some important practical advantages. First, as with business components, POJOs reduce the work that a developer must do to implement the application. Not only are fewer lines of code involved, but also the code tends to be simpler since it is just standard Java. Second, using POJOs means that the rest of the application code—the code that invokes the data access objects—doesn't have any dependencies on a particular persistence technology. If, for example, your application is using raw JDBC or JDO, using POJOs makes it relatively easy to switch to using JPA as the persistence solution.

A third advantage relates to the domain model objects themselves, which in MedRec are the objects that represent entities such as patients, physicians, and prescriptions. Because these classes are POJOs and are not tied to a particular persistence environment (as EJB 2.x entity beans traditionally have been), the classes can be reused across multiple tiers, wherever application code needs access to the domain model. In the case of MedRec this includes the Web tier, where the domain model objects are used by JSPs to render the user interface, as well as the Web services tier which uses the domain model classes as parameter and return types to Web services methods.

MedRec Overview

Readers who would like a comprehensive overview of the architecture of the MedRec application and how it uses Spring should read Spring Integration with WebLogic Server (dev2dev, September 2005). This is an earlier article that does a nice job describing general integration between Spring and WebLogic Server. We shall briefly discuss MedRec architecture here, however, so that it is clear how JPA fits into the MedRec picture.

Figure 1 illustrates the overall architecture of MedRec. At the highest level MedRec is actually two separate J2EE applications (EAR files): the MedRec application and the Physician application. All data access is done by the MedRec piece, so we shall focus our attention there.

Figure 1: MedRec application architecture

As Figure 1 shows, the MedRec application is structured into several tiers: a presentation tier that includes Web services, a services tier, an integration tier that includes data access, and the database tier. The Spring data access objects (DAOs) that are part of the integration tier are invoked primarily by business objects in the services tier. Both DAO and service objects are Spring beans that are configured by a Spring application context. The service objects control transactions using Spring's declarative transaction support.