email article printer friendly

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.