The Advantages of JDO

The programmer's toolbox contains many tools that can be used to store and retrieve an object's state. Java serialization saves an object graph and restores it across space and time. An object's state can be written to XML text streams or stored in custom file formats. Object-oriented database management systems (ODBMS) and object-to-relational (O/R) mapping software can be used to store the object's state in a database. JDBC provides a universal API to relational databases and is currently the principle way to store persistent state. Many of these alternatives offer the advantages of being widely available, widely used, and well understood. What advantages does JDO hold over them?

JDO Compared to Serialization, XML, and Custom File Formats

Serialization is simple to use, and the serialization mechanisms are largely transparent to the application's code. It is the persistence mechanism of choice in a large number of cases. Where there is one-to-one communication between peers or between a client and service, serialization is often an excellent choice for copying objects from one JVM to another. It is also a reasonable choice for an application that needs to store or read infrequently a small amount of persistent state. For example, a text editor or Web browser might serialize the configuration object for its user. Nevertheless, serialization has several deficiencies when used for general-purpose persistence. Serialization loads into memory the entire graph of objects at once, and therefore it is slow and memory consuming when the purpose is to view a small part of a large object graph. Serialization has no transactional mechanisms and therefore it does not support concurrent updates to the serialized objects. It also lacks a query mechanism. Finally, serialization must store the entire graph of objects if any object in the graph has changed.

Although XML and custom file formats have their strengths, they suffer from many of the same disadvantages as serialization and have other disadvantages of their own. Unlike serialization, XML and custom file formats require a fair amount of code to move the persistent state in and out of the object. In addition, the application becomes responsible for managing object references. If A refers to B and C refers to B, how does the shared use of B become represented in the file format? The application must make the decision and implement it.

In contrast to serialization, XML, and custom file formats, JDO provides a transactional service that permits and regulates concurrent access to the same underlying persistent state. JDO loads the object graph lazily. As the application uses the references to persistent objects, JDO loads the objects into memory. JDO stores the persistent state for only the objects that have changed within the transaction. It has a query mechanism, and it manages object references. For these reasons, JDO offers significant advantages in many cases.

JDO Compared to ODBMS and O/R Mapping

Because JDO sprang from concepts pioneered in the development of object-oriented database management systems, JDO retains similarities to object databases. However, the interface to each vendor's ODBMS is distinct from the interface offered by the next vendor. Although the Object Data Management Group (ODMG) specified a standard interface, the standard has not been widely adopted by vendors or application developers. JDO provides a single service that can access all object databases for which a JDO implementation is built.

Several object-to-relational mapping products already provide a persistence service for Java applications. Unfortunately, each of these products uses a product-specific interface to access the functionality of the persistence service. JDO offers the hope that all O/R mapping vendors will come to support a common interface.

JDO Compared to EJBs with CMP

In EJB containers, container-managed persistence (CMP) maps entity EJBs to their persistent state. JDO may displace, but it does not replace, CMP. For application developers who are looking for more flexibility than the current CMP provides, JDO offers a simpler way to write EJBs that use bean-managed persistence. For vendors who are looking for a more flexible way to implement CMP in their EJB containers, JDO offers a way to plug in a variety of datastore architectures to their CMP mechanisms.

JDO Compared to JDBC

Relational database management systems are the workhorses of data storage, and JDBC is the primary interface Java programs use to access them. Although successful, JDBC requires a fair amount of glue code to manage persistence. Sometimes application programmers write an entire persistence service, but more often, the glue code is written on a class-by-class basis.

Application programmers will find that JDO offers several advantages over JDBC. To begin with, storing and retrieving object state requires much less code. JDO encapsulates entirely the object construction and deconstruction steps found everywhere in the code that uses JDBC. Because the application programmer no longer writes the code to move persistent state in and out of objects, less code is written. Because JDO transparently provides lazy loading, change tracking, and storage of modified state, the application data classes remain largely ignorant of persistence mechanisms. As a result, these classes are not complicated by a need to explicitly interact with a persistence service.

As another advantage, JDO reduces the amount of skill needed to map an object model to a relational model. Depending on the tools provided by the JDO implementation, the object model of the persistent objects and the relational model can come together in one of three ways. Either the object model can be constructed with the tools deriving the relational model, or the relational model can be constructed with the tools deriving the object model. In some cases, the tools allow programmers to work iteratively from both models to a meeting in the middle. In the typical development effort using JDO, either the relational model or the object model is the driving consideration, and the other is derived by tools.

JDO offers one more significant advantage over JDBC. Only the object model needs to be considered when constructing queries. For the application programmer using JDO, there is no relational model. Likewise, during query coding, column and table names in the database are not used. To determine whether a query can be constructed for some set of objects, it is only necessary to examine whether the objects, fields, and relationships needed are present in the object model. If so, then the query can be constructed from this information. As a result, the application programmer does not need to understand SQL. The JDO implementations for relational databases map JDO queries to SQL transparently.

Some will question whether it is truly an advantage to remove the application programmer from the construction of SQL. It is commonplace to tune some SQL statements in an application in order to achieve higher performance. In addition, stored procedures are often used for the same purpose. By removing SQL from the application programmer's domain, doesn't JDO take a step backwards in terms of performance? The answer has two parts. First, it is quite reasonable for a JDO implementation to provide these features, even though they are not specified by JDO. Current JDO implementations are already addressing these features, and it can be expected that future versions will concentrate more and more on enhancing performance. Second, application programmers are by nature jacks-of-all-trades. They do what needs to be done to get the application running. Often they are not expert SQL coders. This lack of expertise is part of the reason why the SQL statements in applications need to be tuned in the first place. It is quite possible that the typical application would benefit from using persistence software whose specific concern is to make efficient use of the relational database.

Compared to JDBC, JDO provides the application programmer with a high-level persistence service. JDO encapsulates all the details of how persistence is accomplished. The application programmer must decide only a small number of high-level issues. He must decide what classes of objects and which particular objects of those classes need to be persisted. Within those classes, he must decide which fields need to be persistent. Finally, he must decide where to draw the transactional boundaries. These are high-level issues of persistence that JDO does not encapsulate. By exposing the irreducible issues of persistence and encapsulating everything else, JDO gives the application programmer a powerful conceptual and executable framework that allows him to build more robust applications in a shorter period of time.

JDO Has the Potential to Become Ubiquitous

Because of the advantages that JDO offers in encapsulation, uniformity, transparency, and portability, the creators of this standard hope that it will become ubiquitous, in the same way that JavaServer Pages, Java servlets, Enterprise JavaBeans, and JDBC have become ubiquitous for the Java platform. By using JDO instead of the existing alternatives, application developers have greater flexibility to choose the datastore appropriate for the application, more choice among competing implementations, greater flexibility to choose the deployment environment, greater power to build a robust design, and speedier development. If, as the creators hope, JDO becomes ubiquitous, then all application developers will become more productive and valuable as they acquire the skills to use another powerful tool in the Java toolbox.