JDBC, CMP, or JDO?
Summarize the multidimensionality of object persistence technologies to help you make the right decision for your enterprise application
by Dr. Wilson Cheng and Dr. Pinaki Poddar

The first three installments of this discussion covered a range of factors you must consider in choosing an object persistence technology for your enterprise applications. Namely, the previous postings discussed mapping support and domain models of JDBC, CMP, and JDO; object query mechanisms; transaction state management; performance and scalability; and portability. (See "Choose the Right Object Persistence" (Java Pro online, July 16, 2003); "More Object Persistence Choice Factors" (Java Pro online, July 23, 2003); and Factor In Performance and Portability" (Java Pro online, July 30, 2003.) In this final installment, we'll look at one additional factor, mechanics, and then summarize object persistence match-ups with application types to help you make the choice that is right for you.

Mechanics
Mechanics covers the practical aspects of demands on human and technical resources required for application development using an object persistence service, typically called the develop-deploy-run-test-debug cycle.

JDBC is low cost for relational applications. JDBC development is simple as long as mapping of a domain object to a data store is straightforward and no performance optimization is required. JDBC applications have a moderate development cycle because JDBC drivers are easy to install. No intermediate step such as EJB compilation or JDO enhancement is needed, no separate mapping specification is required, and JDBC applications do not require an application server.

However, JDBC's complete dependence on SQL can cause unsafe programming. SQL statements are specified as String arguments to the JDBC API, which means a Java compiler cannot verify the correctness of these statements. Many syntactic and semantic problems in SQL commands (such as misspelling a table name) are thus discovered only at run time. JDBC development contradicts the type safety of object languages for detecting errors at compilation.

CMP development is costly because domain objects must conform to Enterprise JavaBean (EJB) design. Bean development is highly nonlinear. A bean specification is widely distributed in its home interface (how to create it); remote interface (how to interact with it); implementation; deployment descriptor (how to configure it); and, especially for CMP, in its mapping specification (how to map it to the data store).

All specifications must be compatible. Some specifications are verified at compilation—for example, whether a business method in a remote interface is implemented in the bean implementation class. Others are used only at deployment—for example, whether the mapped column name exists in the data store. An error discovered in deployment can trigger a new develop-deploy-run-test-debug cycle. And because CMP requires an application server, the application server usually must be restarted.

JDO is inexpensive. Of the three technologies, JDO applications offer the most development ease. Application code is simpler because the JDO driver handles automatic persistence of new objects, mapping to the data store, and identification of objects committed in a transaction. Effectively, a developer needs to code only the business logic of the domain objects; the interaction of domain objects with the data store is almost transparent to the application.

Defining the domain model with JDO is more straightforward than with CMP. A developer does not have to specify any special interface or inherit from any class to enable the JDO driver to manage a domain object. All that is needed is to specify the mapping configuration and run the enhancement process. Similarly, testing can be done in an inexpensive, nonmanaged environment without an application server.

Choose Your Technology
The multidimensionality of object persistence technologies can make choosing the right one for your enterprise application a complicated task. Consider some generalizations about JDBC, CMP, and JDO that can help you make a decision. We pair the technologies with three types of enterprise applications: RDBMS-centric applications, application-server-centric applications, and object-centric applications. Our pairing of technologies to their most suitable types of application does not imply that the given technology is not suitable or does not work well with other types of applications. For example, you can use JDO with session beans to gain the advantages of JDO and at the same time take advantage of J2EE application server infrastructure.

JDBC is RDBMS-centric. JDBC is suitable for RDBMS-centric applications. RDBMS-centric applications are those where the design of the domain object model is primarily driven by relational database schema. Many applications are of this type because RDBMS is the most common data store.

JDBC is preferred if you need to maximize RDBMS computational power, such as aggregational queries. Because JDBC is tightly coupled with the database schema, you might prefer JDBC if application portability is not an issue, if the schema is fairly stable, and there is no requirement to interact with non-RDBMS data stores. JDBC is also suitable when transaction semantics are simple, primarily read-only, do not require a high degree of configurability, and commit closure is easily identifiable, because a JDBC application has to explicitly synchronize the states of transaction entities to the data store.

JDBC is popular for Web-based, user-view-centric applications, and reporting applications based on existing RDBMS. These kinds of applications are primarily read-only and require rapid development. Their domain object models are usually in close correspondence with the RDBMS schema. Finally, JDBC's lack of client caching makes it less desirable for applications that need to scale.

CMP is application-server-centric. CMP is centered on the power of a J2EE application server. Application-server-centric applications rely on the infrastructure services of J2EE. CMP is only one of many J2EE services. Other features of EJB applications include load balancing across application server clusters, declarative control of transaction semantics, deployment-time security to control access, remote access using many different protocols, and support for messaging. You might choose to use CMP and EJBs if these general features of application servers are of primary importance. EJB development is costly, but J2EE services can justify the cost if business requirements demand the features of an application server. CMP object persistence alone is not usually a sufficient reason for choosing EJB and application servers for your enterprise application.

JDO is object-centric. JDO is the technology of choice for object-centric applications. Object-centric applications are those where the domain object model requires advanced object modeling concepts, data store access is primarily navigational, and computational logic is expressed by behavioral Java methods of objects, not SQL statements of an RDBMS. JDO has sophisticated object management and transaction state management. Object-centric applications are easy to develop and highly portable despite schema or data store technology changes. You should consider JDO if your application must work with multiple types of data stores.

Many business domains, such as telecommunication routing, financial data modeling, and VLSI design, use graph and tree as the primary metaphor for their object models. These applications also need sophisticated algorithms that require navigational access over a graph of interconnected objects. For example, finding routes in a map, executing a flowchart in a rule engine, or exchanging exotic financial instruments all are graph-and-tree problems. Unique JDO features such as persistence-by-reachability, which detects the closure of a graph of objects, or implicit fetching of objects from a data store by navigation can be extremely useful for such applications.

About the Authors
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 Dr. Cheng at , and reach Dr. Poddar at .