Java Data Objects -An Alternative to Bean-Managed Persistence

Java Data Objects An Alternative to Bean-Managed Persistence

Entity beans are the solution for object-to-relational mapping from the J2EE stable. But the technology behind entity beans has run into a lot of performance problems right from its introduction. You have already studied these issues and their resolutions (to a certain extent) in the new EJB 2.0 specification.

The core issue is not entity beans (using either CMP or BMP) themselves but the mismatch between the object world of objects and relational world of database tables. There exists a hierarchical relationship or association between objects. This means that when an object contains other objects, which in turn may contain other objects, the entire association is one of a hierarchical tree of objects. Database tables, on the other hand, have a relational (one-to-one, one-to-many, or many-to-many relationship) association with other database tables. Hence, persisting data contained in object instances to relational database tables is like fitting a square peg in a round hole.

A lot of different techniques have been tried out to get around this, from having objects directly persist their data using simple embedded JDBC statements to well-designed persistence layers to entity beans using CMP even to object databases!

Entity beans, to a certain extent, address this mismatch using CMP and the EJB Query Language. CMP tools generate the code that persists the entity beans data to the relational database table or tables. But complex data structures and relationships still cannot be mapped properly. This is where Java Data Objects (JDO) come into the picture. JDO is a recently introduced specification from Sun. JDO defines the standard for transparently persisting object data to a relational database.

Components of JDO

To build a JDO application, in addition to the objects to be persisted, you need to write an XML metadata mapping file and then recompile your JDO application using the JDO Enhancer. In addition, JDO provides a meta query language that can be used for writing queries to retrieve data as objects. You will now take a brief look at each of these:

• XML metadata mapping file The XML metadata mapping file is used to define the mapping information of the classes whose data needs to be persisted. This mapping file is used by the Enhancer to generate the final JDO enhanced classes.

• Enhancer The Enhancer is the critical component in building a JDO application. The Enhancer takes the compiled files of the objects to be persisted and the XML metadata mapping file and manipulates the Java byte code to insert the byte code required to make the compiled class implement the PersistentCapable interface. Hence, your classes that require persistence do not need to explicitly implement any interfaces, thus isolating them from any proprietary persistence solutions.

• JDO QL The question that arises is this: If EJB 2.0 has a well-defined query language, the EJB QL, why does JDO have its own query language, the JDO QL? The answer lies in what the languages aim to do. EJB QL has a limited set of query language clauses that can be used. Moreover, EJB QL is more or less based on SQL, which makes it closer to the relational world than to the object world. JDO QL, on the other hand, supports manipulation and querying of objects using pure Java expressions and is not based on relational SQL. Hence, it is far easier and more intuitive to use JDO QL than EJB QL in JDO.

JDO Classes and Interfaces

JDO is considered an intrusive technique, because during the development of a JDO application, JDO inserts additional code into the .class file of a Java application that needs to use JDO.

Application developers can use the following classes and interfaces of JDO in their applications:

• PersistenceManagerFactory This is a factory interface that is used by a JDO application to obtain instances of PersistenceManager objects.

• PersistenceManager The PersistenceManager interface contains the actual methods to perform persistence. It represents a logical connection with a Datasource.

• Transaction Enables use of transactions in JDO applications.

• Query Enables use of the JDO query language to retrieve objects from a Datasource.

• JDOException Exception class for JDO operations.

You will now look at the steps you would take to write an application that uses JDO.

Writing a Sample JDO Application

Figure 13.2 shows the entire development cycle for building a Java application that uses JDO.

Figure 13.2. Development cycle of a Java application that uses JDO.

To develop a Java application that uses JDO, first you need to define the domain object that requires persistence. For example, if you need to persist the ItemBean data to the database, you will define an ItemBean class, but without having the class inherit from any other persistence class hierarchy or implement any special persistence-related interfaces. The ItemBean class for a JDO application will contain only the member variables required to hold data and get/set methods to access these variables.

In addition to this, you will need another class that manages the persistence of the ItemBean class. You should call this class ItemBeanFactory because the ItemBeanFactory class is responsible for the persistence of the ItemBean class. The ItemBeanFactory class obtains the javax.jdo.PersistenceManagerFactory object of JDO using the getPersistenceManagerFactory() method of the JDOHelper class. The setConnectionFactory() method of the PersistenceManagerFactory object can be used to set any factory object created from a ManagedConnectionFactoryImpl object using the createConnectionFactory() method. A code snippet is given here:

 // get the PersistenceManagerFactory  PersistenceManagerFactory myPMF = JDOHelper.getPersistenceManagerFactory(); // get the ManagedConnectionFactoryImpl object ManagedConnectionFactoryImpl myMCFImpl = new ManagedConnectionFactoryImpl(); myPMF.setConnectionFactory(myMCFImpl.createConnectionFactory()); 

For persisting data contained in objects, you need to construct the PersistenceManager object. The PersistenceManager object can be constructed by invoking the getPersistenceManager() method of the PersistenceManagerFactory object. After obtaining the PersistenceManager object, you can begin persisting the ItemBean objects to the database. To do this, the PersistenceManager interface provides methods like makePersistent(), makePersistentAll(), makeTransient(), makeTransientAll(), deletePersistent(), deletePersistentAll(), and so on. A code snippet is as follows:

 // get the PersistenceManager  PersistenceManager myPM = myPMF.getPersistenceManager(); // initialize the ItemBean object ItemBean myItemBean = new ItemBean(1, "Hot", "Apple Pie", "Sweet",         "Apple, Sugar, All Purpose Flour, Eggs, Butter", "Standard"); // persist the ItemBean myPM.makePersistent(myItemBean); 

After an object is persisted using JDO, it is assigned a unique identity. This identity of a persisted ItemBean object can be obtained by invoking the getObjectID() method on the PersistenceManager object. The getObjectID() method takes the persisted object as a parameter and returns the JDO object ID. The JDO object ID can now be used as a reference for the different ItemBean objects that were persisted using the PersistenceManager of JDO. A code snippet is given here:

 // retrieve the object id of the persisted ItemBean  Object myItemObjID = myPM.getObjectId(myItemBean); 

To retrieve the persisted ItemBean objects, you can use the getObjectById() method of the PersistenceManager object:

 // retrieve the ItemBean from the JDO object id  ItemBean myItemBean2 = myPM.getObjectById(myItemObjeID); // now you can modify the contents of the ItemBean myItemBean2 myItemBean2.setServingSize("Super Size"); ... 

After writing the ItemBean and the ItemBeanFactory classes, you need to write the XML metadata mapping file that contains the information of the classes to be persisted.

Finally, you should run the Enhancer on the compiled class and the XML metadata mapping file to generate the final classes that will use JDP for persisting the data of the ItemBean.

You will now take a brief look at how JDO and EJB fit together.

JDO and EJB

EJB is part of the J2EE specification. JDO, on the other hand, is not yet a part of the J2EE specification but may become part of the J2EE specification at a later time. JDO is a complementary technology to EJB. Because JDO solves the problem of object-relational mismatch, you could very easily use JDO in, say, your session beans to perform persistence. Similarly, if you are using BMP for your entity beans, JDO would be a natural and simpler choice.

But JDO is not for developers only. JDO can also be used by application server vendors to implement CMP using JDO.

The primary advantage of JDO vis-à-vis BMP is that in BMP your entity bean is loaded with JDBC-specific code. JDO provides a cleaner and more elegant solution than BMP with absolutely no JDBC-specific code embedded.

Finally, take a look at a tool provided with WebLogic Server to generate JSP tag libraries from Java archive files of EJBs.