1.5 Roles and Responsibilities

From the preceding discussion, it is clear that there are different roles (developer, JDO speciation, vendor, etc) and each has responsibilities that it must fulfill in order for the application to work as designed. This section looks at these in detail.

1.5.1 JDO specifications

The JDO specifications, besides being a community standard, have five concrete responsibilities:

1. They define the standard for building object persistence.

2. The specifications define the standard API that developers can use in their applications for transparent persistence.

3. The specifications also define a second API “ called the Service Provider Interface (SPI) and illustrated in Figure 1-9 “ that JDO vendors must implement, which constitutes the JDO environment in a virtual machine. This is a typical design that many Java standards have adopted. For example, JDBC defines the API that developers use and another that the JDBC driver provider must implement; JMS defines an API that developers use and another that the vendor providing the messaging server must implement. JNDI and EJB are other examples that follow the same SPI design.

   Figure 1-9. JDO API.

   

4. The specifications provide a Reference Implementation of the JDO standard for developers to use and develop applications in.

5. The specifications provide a Technology Compatibility Kit (TCK) that can be used by vendors to test compliance with the JDO standards.

1.5.2 The developer's responsibilities

A developer is responsible for the following:

1. Determining which objects in the object model need to be persisted and writing their Java classes.

2. Marking these classes as persistence capable or having the ability to be stored by JDO. The developer can do this

   • Explicitly by having the class implement an interface defined by the JDO specification ”the javax.jdo.PersistenceCapable

   • Implicitly by using a tool provided by the vendor that takes the compiled Java class code and marks it as being persistence capable. This tool is called a byte code enhancer , and we see more about this in Chapter 5. Keep in mind that the developer has the option to not implement any special API or persistence- related logic in the objects themselves and to write the usual Java code. The concept of a byte code enhancer or preprocessor is not new to JDO. As mentioned earlier, this was proposed in the 1980s and brought to the forefront for Java by the JSPIN research project. ^[5]

     ^[5] Toward Class Evolution in Persistent Java. Ridgway & Wileden. The Third International Workshop on Persistence and Java-1998, available at http://research.sun.com/forest/com.sun.labs.pjw3.9_pdf.pdf.

   Are persistence-capable instances persistent?

   Just because a class is persistence-capable does not automatically mean that all instances are persistent. It means only that when JDO code is invoked to persist an instance of the class, it will be persisted to the datastore.

   
   

3. Using the JDO API as defined in the JDO specifications to persist instances of these classes, as illustrated in Figure 1-10.

   Figure 1-10. Developer responsibilities.

   

1.5.3 The vendor's responsibilities

The JDO vendor plays an important role by providing the JDO implementation. The primary responsibility of the vendor is to implement the JDO-defined SPI and the JDO specifications. The JDO vendor must also pass the technology compatibility kit (TCK) that is provided by the JDO specifications.

Until now, we have used the term vendor as though it referred to a single company. In reality, several different vendors will be involved, including the following:

1. A vendor that provides the JDO implementation. A list of JDO vendors is contained Appendix E.

2. A vendor that provides the JCA resource adaptor or JDBC driver to connect to the underlying datastore.

3. A vendor that provides the underlying datastore. Because JDO vendors are free to use any underlying storage mechanism, the underlying store depends on what the JDO vendor supports and uses. It could be a relational database from another vendor, an object database from the JDO vendor itself, a file database, a hierarchical database, an EIS system, etc.

4. If a managed environment is used, a J2EE vendor must provide the J2EE application server. For example, JDO may be used for bean-managed persistence in EJBs, in which case the EJB must be deployed in an EJB container provided by a J2EE server. The relationship between JDO and EJBs is covered in Chapter 9.

These logical roles can be fulfilled by a single vendor. In reality, there are two categories of JDO vendors:

1. Vendors that provide a JDO implementation using some form of file-based persistence or relational database and third-party JDBC drivers for that database.

2. Data storage (usually relational or object) vendors that augment their product offering by providing a JDO implementation. Until recently, these implementations have been provided by existing object-database vendors (e.g., Versant) and vendors of object-relational mapping products (e.g., SignSoft). It is possible that, in the future, relational database vendors may also augment their offerings by providing JDO implementations along with their servers.

It is also typical for JDO vendors to provide implementations that come in two different flavors:

• A standalone implementation that can be used in a non-managed environment

• A more expensive version that integrates with J2EE servers from other vendors using JCA technology