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.

Ease of development, flexibility, and the ability to build applications with ordinary Java objects have made POJO solutions popular, as has its widespread availability among commercial and open source solutions. Developers can build and test their persistent models outside of the J2EE container, which speeds development time, reduces application server dependencies, and makes it easier to switch server vendors or use the same application logic in a model outside of the J2EE container. Also, using POJO solutions within a J2EE server either in the Web tier or EJB tier (wrapped by Session Beans) is a completely standards-compliant J2EE application solution, although not yet specified in itself. Using POJO persistence with Enterprise JavaBeans is currently being developed in the EJB 3.0 specification, where Oracle is playing a significant role in defining the new model. However, JSR 220 (EJB 3.0) is still in the early stages, making it subject to change; it is not expected to be complete until some time in 2006.

The BMP solution, though far less popular, should not be simply ignored. BMP developers create entity beans—integrated J2EE components—that are managed by the J2EE container, but defers its persistence operations to the bean author. Although this puts the responsibility back on the developer, it does offer an EJB entity bean solution that enables portability across multiple application server vendors.

BMP is typically implemented through hand-coded JDBC interaction that must be developed and maintained at great cost. But it's not the only way to address BMP. Many commercially available persistence layers address BMP either through code generation or, more ideally, though an ORM solution. If you want the benefits of entity beans and don't mind writing the persistence code yourself, or require the application server portability, consider BMP.

Despite its negative, and sometimes unfair, publicity the CMP solution remains popular with some developers. The EJB 2.1 specification addressed a number of the persistence-related limitations that plagued the initial versions. These changes have allowed application server vendors to produce full-featured persistence layers and allowed developers choosing this approach to function within the specification—something that simply was not possible for applications of any complexity prior to EJB 2.1.

Some CMP solutions today provide very sophisticated persistence support. Many of these features, including caching, database locking, query extensions, and optimized SQL generation go beyond what is in the EJB 2 specification. In most cases the improved performance and functionality far outweigh the decreased flexibility introduced through these vendor-specific dependencies.

Meeting of the Minds
An EJB entity bean using CMP has more run-time and developer overhead than its equivalent POJO. However, it also offers more than just persistence: It provides benefits such as security, instance pooling/management, remote access, load balancing, and failover. If you need these extra features, or if working within proven and widely adopted standards is important to you, CMP entity beans may be a good choice. Its additional development costs and issues are being addressed by richer development environments and planned enhancements to the standard.

There is a growing division between those in the Java community who support and are successful with CMP entity beans and those supporting POJO style solutions. We will see a convergence between the ORM persistence offered by CMP and POJO with the upcoming changes proposed in EJB 3.0. This solution combines the best of both approaches that will simplify the challenge and the solution fragmentation we're seeing today. We will look at EJB 3.0 in more depth in a future article.

When you're evaluating persistence solutions, and the vendors that provide them, there are a number of selection criteria to consider (see Table 1). Often the corporate culture and vendor commitment determines the selected solution. What's important to know is how to build and prioritize your shopping list of features and requirements when tasked with selecting an ORM solution.

POJO is the simplest usage model while providing a great deal of flexibility. It has the largest number of third-party commercial and open source solutions available. Vendor stability is a key decision criterion. Selecting a POJO solution can also be very strategic, as it will provide a natural migration path to EJB 3.0 if the vendor you select is working toward this target. However, EJB 3.0 is also expected to provide a good migration path for those using today's CMP solutions.

BMP is useful for EJB entity beans solutions that need application server portability but use a persistence layer in conjunction with this approach. If you do not use a persistence layer, you'll be forced to deal with all of the development and maintenance costs of a data-centric JDBC solution, as well as that of EJB development.

CMP offers more than just persistence. You can be successful with it; although, using some advanced persistence features may go beyond the specification and couple you to the target application server and its vendor.

Different projects often have unique requirements in the area of persistence. Selecting a solution and vendor that can support multiple architectures and provides a migration path to support future specifications is the best way to leverage your investment across your current and future projects.

About the Author
Doug Clarke is principal product manager for Oracle TopLink and has a background in development and professional services with a focus on interfacing object-oriented applications with relational databases. Contact Doug at .