Design enterprise applications with JPA for EJB 3.0

This article describes a design approach to Java platform,enterprise Edition (Java EE 5) that leverages the Enterprise JavaBeans (EJB) 3.0 new Java Persistence API (JPA). JPA provides a standard object-relational mapping solution that avoids reliance on third-party frameworks such as Hibernate. You will see the details of the sample application, which validates the method and clarifies the key design decisions.

The long-awaited next version of Java EE 5 is about to be released. Java EE 5 Many new features include a patched EJB architecture, one of the salient features of which is JPA. With container and container persistence options, JPA brings a whole range of new design choices to the Java EE architect. This article focuses on the design of applications in containers that rely on EJB containers to provide enterprise services, such as transaction processing and security.

I will test with your familiar Petstore application to demonstrate the capabilities of JPA and how it challenges the traditional Java EE design patterns. This application is trivial, so it does not provide detailed implementation details. I'll use a code excerpt to illustrate the design considerations. This article assumes that you are familiar with the basic concepts of EJB 3.0 and the basic concepts of Object Relational (OR) mapping.

Design Overview

The example Petstore application is a web-based electronic transaction application that implements the following use cases:

Browse Products

Find Products

Maintenance Account

Maintain Shopping Cart

Create order

This application is designed as a multi-tier Java EE application with three primary logical tiers:

The presentation layer (not the focus of this article) uses the Struts framework.

The service layer is a simple service façade that delegates all the work to its collaborators. The purpose of the service layer is to separate the service supply from the service implementation.

The data access layer is a series of coarse-grained data access Objects (DAO) implementations that are implemented as stateless session beans. They all depend on the Java persistence entity manager for their persistence needs.

The application domain model is represented by an EJB 3.0 entity bean and used for communication between tiers. When a domain object leaves the data access layer, it is detached from the entity manager. When you re-enter the data access layer, it needs to reconnect to the entity manager.

Annotations seem to be a widely used feature of Java 5, and JPA is no exception. Annotations can be used to specify or mappings--you can often see them in DW Documents and tutorials--and Petstore applications use them for the same purpose. It is worth mentioning, however, that you can also specify or map by mapping files. The or mapping section later in this article explores and compares these two options.

I develop and deploy Petstore applications in the JBoss application server (see Resources). I use a commercial database to do most of the development work and porting the backend of the application to the PostgreSQL database (or mapping section contains a discussion about the potential impact of the database migration you should know when using JPA).

One of the purposes of this case analysis is to meet design standards and allow highly testable implementations. As seen in the test section, you can use a series of test techniques to test your Petstore application.

The Petstore application leverages the fact that it is a regular Web application. The main advantage is that all layers are capable of running in the same JVM, eliminating the need for component distribution. The remoting section of this article provides a brief overview of how to add remoting functionality to your application.