JDO Architecture
In this chapter we discuss the JDO architecture. An understanding of the architectural points raised here is necessary to facilitate your correct use of JDO and your understanding of the more advanced topics covered later.
3.1 JDO implementations and vendors
The JDO package javax.jdo, which is freely available from Sun Microsystems, is largely made up of interface definitions. It also contains a few concrete classes, notably JDOHelper and the JDO exception classes. It is through these interfaces that applications have access to the functionality of object persistence. The most important one is PersistenceManager, through which transient instances can be made persistent, persistent instances deleted, and so on. However, we have already used two others, namely Transaction and Extent.
These standard interfaces, although a comprehensive description of persistence functionality, are not in themselves sufficient to actually implement persistence. What is needed is a set of concrete classes implementing the respective interface definitions, which will undertake persistence operations when invoked to do so. A set of such classes is known as a JDO implementation.
JDO implementations are data store-specific. Some work against any JDBC-compliant database. Others may work with only a specific relational database in order to exploit potential optimizations. Still others work with certain object databases, file system formats, or provide integration to specific enterprise applications. In some cases a spread of implementations for different data stores may be grouped together under a single product name.
A company that markets a JDO implementation is known as a JDO vendor. A selection of commercial and non-commercial JDO vendors and their JDO implementations is given in Chapter 12. I maintain and regularly update an online list of vendors and implementations on the Ogilvie Partners website, http://www.OgilviePartners.com. Another good source of information is http://www.JDOcentral.com.
Most JDO implementations are shipped with an enhancement tool. Technically this is unnecessary as the binary compatibility specified in the JDO specification allows any class that correctly implements PersistenceCapable (whether by hand or by enhancement) to be manipulated by any compliant JDO implementation. Therefore it should be sufficient to use the reference enhancement tool in all cases. However, each vendor tends to add value to the enhancement process through the use of <extension> tags in the descriptor, and the generation of DDL scripts to define the requisite storage in the target data store. Such scripts are extremely useful, and as a result it is common practice to use the vendor-provided enhancement tool.