email article printer friendly

Select the Best Persistence Architecture
Discover how to select the most appropriate persistence architecture for your J2EE application development
by Doug Clarke

December 22, 2004

One of the most time-consuming and underestimated aspects of designing, developing, and maintaining J2EE applications is the challenge of persistence: How will your application retrieve, manipulate, and write data? Data, which is typically maintained in a relational database, has very different semantics than a Java-based application.

There is a range of persistence architecture options. At one end is low-level Java Database Connectivity (JDBC). At the other end is high-level abstraction and integration with the Enterprise JavaBeans (EJB) Container Managed Persistence (CMP) implementation. Understanding these options—as well as the popular choices in between—is the first step in reducing and managing the risk factors (performance, project delays, increased maintenance costs) associated with persistence in J2EE applications.

The application development style you use—data-centric or object-centric—has a significant impact on the types of persistence architectures available to you. Data-centric applications are driven from the relational schema, with the application logic often driven primarily by the database through stored procedures. Data-centric applications are basically window-on-data, where little or no business logic is maintained in the middle tier. Often, these applications are data-centric based on their origins—for instance, they were previously accessed through a Rapid Application Development tool or similar technology—and developer skill sets. Applications that are data-centric should focus on implementations based on JDBC and frameworks that maintain the relational model all the way through to the presentation layer.

Here, we'll focus mainly on persistence architectures for object-centric applications. In this development style, application logic is usually built and maintained within the J2EE middle tier and involves introducing a persistence layer into the application that will convert between the object model of the application and the relational schema of the database or databases (see Figure 1).

Solution Options
The object-relational mapping (ORM) persistence layer handles the impedance mismatch between the relational and object domains. This layer can be addressed with either a custom framework or a third-party solution. The most commonly used solutions include:

• Plain Old Java Objects (POJO) Persistence – hand-coded, commercial (Oracle TopLink, Solarmetric Kodo), or open source (JBoss Hibernate) solutions
• EJB Bean Managed Persistence (BMP) – hand-coded or generated JDBC access or third-party frameworks that support BMP
• EJB Container Managed Persistence (CMP) – Native support of the J2EE application server or third-party integrated CMP solutions

The POJO Persistence category of solutions is the most frequently discussed persistence solution today. Long-standing POJO solutions such as Oracle TopLink, the growing interest in open source projects such as Hibernate, and the evolution of the Java Data Objects specification have all been big news in developer forums. POJO Persistence offers a viable alternative for those who need persistence capabilities but don't need the full set of benefits—and/or don't want the associated costs—that CMP and BMP entity beans provide.