Due to the growing complexity of Enterprise Java Beans and their close ties to relational databases, in 2002 Sun Microsystems proposed JSR-000012 [Russel 02] which put forward the idea of Java Data Objects (JDO). The aim of this was to provide a set of simple, storage-independent interfaces for persisting Java objects between JVM executions. This would allow developers to add persistence to their applications with minimal changes to the code and also allow for change between storage methods such as file I/O, relational databases and object-oriented databases without the need to recompile.
Business Objects Transient Objects Persistence Manager JDO Objects (implement PersistenceCapable) Query Transaction Application Data Store JDO/Class MetaData describes
Figure 2-28 JDO Architecture, courtesy of [Mahmoud 05]
One of the main criticisms of the EJB 2 specification was that too many restrictions were places on persistable entity bean classes, severely restricting their usage as normal Java objects. Java Data Objects aimed to correct this by allowing developers to persist plain old Java objects, so that there was no difference between persistable and transient classes. However, to successfully persist these classes, additional information was required in the form of an XML descriptor file which allowed developers to specify metadata such as primary key fields, identity types3 and relationships for each class. An external tool, called the JDO Enhancer, would then read the descriptor file, alter the persistable classes so that they implement the PersistenceCapable interface and provide the necessary methods for storing instances of themselves.
___________________________________________________________________________________
3
The identity type of a class refers to how the equivalence of two instances is determined. In JDO, this can be controlled by the data store, the application or each object can be seen as unique.
34
Enhancer Input
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE jdo SYSTEM "...">
<jdo>
<package name="uk.ac.ic.students">
<class name="Student" identity-type="application"> <field name="name" primary-key="true"/> </class> </package> </jdo> Student.jdo Student.class Student -name: String -course: String -year: int +toString(): String ...getters and setters...
JDO Enhancer Enhancer Output PersistenceCapable +jdoGetPersistenceManager():PersistenceManager +jdoReplaceStateManager(sm:StateManager):void +jdoProvideField(fieldNumber:int):void +jdoProvideFields(fieldNumbers:int[]):void ... +READ_WRITE_OK:byte +LOAD_REQUIRED:byte +READ_OK:byte ... Student -name: String -course: String -year: int +toString(): String ...getters and setters...
Figure 2-29 Enhancing a class using an XML descriptor and the JDO Enhancer tool
In the application code, the JDO library provides a set of interfaces for persisting objects, retrieving objects and handling transactions. It is still up to the developer to decorate existing application code with calls to a transaction manager in order to ensure that the data store is not left in an inconsistent state. PersistenceManagerFactory persistenceManagerFactory = new PersistenceManagerFactoryImpl(); PersistenceManager persistenceManager = persistenceManagerFactory.getPersistenceManager();
Transaction transaction = persistenceManager.currentTransaction();
// Create Student as normal, transient object
Student student = new Student(); student.setName("Marc Hull");
student.setCourse("Computing MEng"); student.setYear(4);
// Make student persistent by registering it with persistenceManager
transaction.begin();
persistenceManager.makePersistent(student); transaction.commit();
Figure 2-30 Persisting an enhanced class using Java Data Objects
One of the big selling points of JDO is its ability to remove the need for SQL-like querying when retrieving persisted objects. This is done through extents, which provide a method for iterating through every instance of a particular class and its subclasses. However, this method on its own provides no means of filtering, ordering or aggregating the data, and implementing those tasks in the Java domain by iterating through the entire collection can be incredibly inefficient. Instead, for anything more than listing all instances of a certain class, a custom query language called JDOQL should be used. This
35 takes an extent and provides a set of methods for filtering down its contents in the domain of the data store.
t.begin();
// Get the extent of the Student class
Extent extent = persistenceManager.getExtent(Student.class, false);
// Iterate over the objects and display them
Iterator i = extent.iterator(); while (i.hasNext()) {
Student student = (Student)i.next(); System.out.println(
"Student "+student.getName()+ ": "+student.getCourse()+ " (Year "+student.getYear()+")"
); }
// Do some cleanup
extent.close(i);
t.commit();
Figure 2-31 Printing out a student listing using extents
The JDO Query Language contains a mixture of standard Java method calls and String expressions for filtering out the required objects. Unfortunately, since the filter expression itself is encoded as a String, there is no static type checking despite the fact that all the type information for the objects involved is readily available in their class definitions. There are also methods for moving variables from the Java domain into the query as parameters, however again their usage is not statically type checked.
t.begin();
// Begin with the extent, which will fetch every student
Extent extent = persistenceManager.getExtent(Student.class, false);
// Define a filter String which will return all students who are on // the courses in a courses list and in a year greater than
// minimumYear
String filter = "courses.contains(course) & year >= minimumYear"; Query query = persistenceManager.newQuery(extent, filter);
// Declare the variables we're going to feed in from the Java // domain
String params = "List courses, Integer minimumYear";
q.declareParameters (params);
// Create our parameter objects
List courses = Arrays.asList( new String[] { "Computing MEng", "Computing BEng", "ISE MEng" } );
Integer minimumYear = new Integer(2);
// Execute the query with the parameter objects
Collection emps = (Collection) q.execute(courses, minimumYear);
t.commit();
36
Advantages:
• Near-orthogonal persistence; there is little difference between transient and persisted objects. • Application code is independent of data store used.
• Developers can specify queries in Java code rather than SQL.
Disadvantages:
• Efficient queries still need to resort to a separate query language (JDOQL) which is not statically type checked
• An XML descriptor file is needed to add extra information to persistable classes.
• An enhancement step must be run on persistable classes between compilation and runtime.