Choose the Right Object Persistence
Making a choice among JDBC, CMP, and JDO can be critical in enterprise application design
By Dr. Wilson Cheng and Dr. Pinaki Poddar

Choosing the right object persistence technology for your enterprise application—how business domain objects are created, retrieved, updated, and deleted in a data store while preserving transaction integrity—is critical in Java application design. Here we'll give you guidelines and a method for choosing among three leading object persistence technologies: JDBC, CMP, and JDO. We present six dimensions that characterize object persistence issues for any enterprise application. We also provide generalizations about JDBC, CMP, and JDO to aid you in your decision-making (see the sidebar, "Object Persistence Technologies").

Because choosing the right object persistence technology is a multidimensional problem, you should select a technology for its overall suitability to the primary requirements of your enterprise application. All issues of object persistence can be grouped into six dimensions. These six dimensions or generic requirements are inherent in the design of any enterprise application regardless of its particular business domain:

1. Transformation of domain object model to data store representation
2. Query mechanism to retrieve objects from the data store
3. Transaction state management
4. Scalability and performance features, such as caching and fetch on demand
5. Portability across changes in data store schema, data store technology, or vendor
6. Mechanics such as ease of development, deployment configuration, and testing

First, we present a summary scoring of JDBC, CMP, and JDO object persistence service for each of these six dimensions and a visual representation of that scoring. Then we present the rationale for the summary scoring by addressing JDBC, CMP, and JDO point by point in light of the six dimensions. Table 1 summarizes the suitability of JDBC, CMP, and JDO support for enterprise application requirements by way of the six dimensions of object persistence. We use a three-point scale: good support is given a numeric score of 3; moderate support is given a numeric score of 2; and negative or no support is given a numeric score of 1.

The total scores of the three services are presented only as indicators to their overall efficacy. They should not be taken as the absolute criteria for judgment because of the multidimensional nature of these services. As we will see in a subsequent discussion, each technology has its strength in certain dimensions; for example, JDBC has the most powerful query expression despite having the lowest overall score (see Table 1). Perhaps a better way to see the multidimensionality of JDBC, CMP, and JDO support for the six dimensions of object persistence is shown in Figure 1. The adequacy of each technology is graphed on a hexagon where each vertex represents one of the dimensions. An ideal object persistence technology would cover the hexagon entirely.

The primary object persistence issue is the transformation or mapping between a domain object model and its data store representation. We are all familiar with the table-column representation of RDBMSs. However, OODBMS, file systems, and proprietary storage systems are also used in enterprise data management. With the notable exception of OODBMS, all storage mechanisms represent data differently than the object-oriented representation.

Mapping Support
Despite its position as the most widely used object persistence technique, JDBC offers no solution for mapping between objects and the database. Transformation is left completely to the developer. In principle, given expert architects and developers, with SQL you can implement any mapping between objects and database records. Because most JDBC drivers supply metadata information about tables and columns in the database, you could construct a generic, configurable mapping. In practice, however, the complexity of explicit mapping limits your choice of JDBC for data-oriented applications, where domain objects closely resemble relational database records.

Both CMP and JDO support mapping of domain objects to a data store. However, the process of incorporating the mapping in run-time behavior of the domain objects is significantly different. CMP uses code generation while JDO uses enhancement. In CMP, the mapping is specified in deployment descriptor of the entity bean. The EJB compiler generates a concrete class definition from the abstract CMP bean defined by the developer. The mapping specification manifests in the generated code to transform the bean field values to data store—for example, columns of a particular table.

On the other hand, JDO requires a metadata XML file (with JDO extension) that describes the persistence properties for pure Java classes representing the domain objects. The JDO Enhancer—a post-compilation process—modifies the original Java class to implement the contract of the javax.jdo.PersistenceCapable interface. This PersistenceCapable contract ensures that field access to enhanced domain objects is mediated through the JDO driver. At run time, the JDO driver must also access the metadata that contains the mapping specification to read or write values from the data store.

The scope of mapping in both CMP and JDO is nonstandard. Neither the CMP nor JDO specification defines the scope of transforming objects to data store and, hence, is left to the service provider. In practice, mapping for RDBMS (object-oriented databases do not require mapping) is typically limited to aliasing a field name to a column name. Complex mapping, such as changing the directionality of a relationship or flattening an inheritance hierarchy to a single table, is not always supported. If an application must be built with an existing persistent schema (which is usually the case), mapping capability can limit the complexity of the object model.

Domain Models
The domain model in CMP becomes fairly restrictive while utilizing the benefit of declarative mapping. The class representing the domain objects must conform to the CMP design paradigm that does not allow classes to be inherited. (For background, see www.onjava.com/pub/a/onjava/2002/09/04/ejbinherit.html.) The relationship to other domain objects (beans) cannot be polymorphic. For example, Customer might have a SavingsAccount or CheckingAccount or both. A polymorphic relationship would represent this as a single Customer.getAccount() method that returns either a SavingsAccount or CheckingAccount. However, if these domain objects are modeled as CMP beans, then two explicit methods are required on CustomerBean-getSavingsAccount() and getCheckingAccount()-rather than the single, polymorphic getAccount().The 1:n or n:n relationships among beans are expressed with Collection or Set, but other common collections or maps, such as LinkedList or HashMap, are not supported.

A JDO application, on the other hand, imposes minimal restrictions on the domain model. Pure Java objects can be used to represent the domain model without extension or implementation of any JDO-specific class or interface; however, the original objects must be modified by enhancement to implement javax.jdo.PersistenceCapable interface. The domain objects can use any abstractions allowed in Java, such as inheritance and polymorphism. JDO even allows a persistent class to be derived from a nonpersistent class. Relationships are expressed as fields of all collection or map types supported in java.util.* package, such as LinkedList, ArrayList, and HashTable.

Future postings will discuss object query mechanisms, transaction state management, performance and scalability, portability, mechanics, and how to choose the technology best for your needs.

About the Author
Dr. Wilson Cheng, vice president engineering, directs product development strategies and initiatives at Versant Corporation; has led interdisciplinary, intercompany teams to improve cross-platform e-business solutions at Oracle; and was the chief architect for the object replication project for Jasmine at Fujitsu. Cheng published more than 20 technical articles in various international conferences and was the program chair for the sixth annual Australian Conference on Parallel and Real-Time Systems. Dr. Pinaki Poddar, principal software engineer for Versant Corporation, works in the area of object persistence and J2EE integration. He designed enterprise applications for the health care and finance industries and developed a Hindi speech recognition system in his past life. He is also a contributor to www.openadaptor.org, an open source project for enterprise application integration. Reach Wilson at , and reach Pinaki at .