Java Data Objects (JDO) enables Java developers to perform database transactions from within Java objects without writing database (SQL)- or JDBC-specific code. Java Architecture for XML Binding (JAXB) and JDO provide great APIs for performing complex XML- and database-oriented tasks. But what about using the two in tandem? This article is about combining these technologies to solve the complex tasks of data access and data persistence.

Java classes can be generated by compiling XML Schemas using JAXB technology. As long as a schema is a well-formed XML document with a definition of simple or complex types, JAXB can generate Java interfaces and classes for each data type defined in the schema. JAXB also provides methods to unmarshall an XML instance document into a Java content object tree. The reverse process is also supported by JAXB. It allows you to marshall the Java content tree back to the XML instance document. This article focuses on the unmarshalling techniques of JAXB.

The JDO API is a standard interface-based Java model abstraction of persistence. Java developers use JDO to store Java objects that hold data (they resemble JavaBeans) into the persistent store (database). When you use JDO, you just need to know Java - no other programming language is required.

This article shows you how to build a simple application that reads customer data from an XML file. We'll deploy JAXB to create a customer Java object model and will also use JDO to store these objects in the database. The example included here uses only the reference implementation released by JavaSoft and its partners.

The JAXB specifications and documentation can be downloaded from http://java.sun.com/xml/jaxb, and JDO specifications and documentation can be downloaded from http://java.sun.com/products/jdo. (You will need the latest version of JDO 1.0.1 to run the example http://access1.sun.com/jdo/private/index.html). Also, the example uses JAXB bundled with the Java Web Services Developer Pack (http://java.sun.com/webservices/downloads/ webservicespack.html). Complete installation steps are explained in the readme.txt.

Why JAXB and JDO?
Although a lot of work must done to explore the use of these two technologies working in tandem, because the JAXB generates Java objects that can be persisted using JDO they seem to complement one another. JDO imposes no constraints on the Java objects in processing them using JDO APIs. They don't need to have any prior knowledge of JDO-specific interfaces (such as PersistenceManager, Transaction, and Extent). Note: Care must be taken to ensure that the data types in the JAXB-generated classes fall within the data types defined by the JDO specification.

JAXB Architecture
JAXB enables developers to achieve a two-way data transformation in a platform-neutral fashion, without having to deal with or even know XML programming techniques. Moreover, developers can take advantage of XML strengths without having to rely on heavyweight, complex XML processing models like SAX or DOM. JAXB hides the details and gets rid of the extraneous relationships in SAX and DOM. From the developer's perspective, only the most useful relationships defined by the source schemas are transformed in the Java object model. The result is highly portable XML data joined with highly portable Java code that can be used to create flexible, lightweight applications. Since the Java object tree is based on the input XML Schema and auto-generated by the JAXB Binding Compiler, the tedious task of mapping XML elements to Java objects is completely automated and remains error free. Typically, developers have relied on standard programming techniques such as the Data Access Object (DAO) pattern to access data from the databases or XML instance documents. The development and the maintenance phases of the project where the schemas tend to change require minimal programming effort to keep up with the changes.

JDO Architecture
The two main goals of the JDO architecture are to provide developers with a transparent, Java-centric view of persistent information, such as enterprise data and locally stored data, and to enable pluggable implementations of data stores in application servers. The data stored in data stores is presented as instances of the persistence-capable classes. Such data objects are generally represented with getter and setter methods, although JDO doesn't enforce the existence of such methods in the data objects, and the properties defined in the data objects can be declared as private. I found an excellent read on JDO - Java Data Objects by David Jordan and Craig Russell (www.oreilly.com/catalog/jvadtaobj). I recommend that you go through at least the first three chapters of this book before deploying JDO. There are various other techniques, such as direct file I/O, serialization, JDBC, and Enterprise JavaBeans (EJB), to persist data but benefits such as portability (JDO is as portable as Java), database independence, ease of use (no need to worry about field-by-field storage of objects), and high performance make a compelling case for JDO.

Figure 1 shows specific components of JAXB and JDO used in building the example.

The process of transforming XML data into content object trees and persisting content objects in the database can be divided into roughly four steps:
1. Compile schema to generate Java classes (JAXB task)
2. Enhance classes (JDO task)
3. Build content objects (JAXB task)
4. Persist content objects (JDO task)

Compile schema
When a schema is compiled to generate Java classes, JAXB generates interfaces for global elements and complex types. For details on how JAXB generates interfaces for complex types and complex types that use other complex types, see the user guide included with the JAXB distribution package. JAXB also generates concrete implementation of the interfaces it generates for the complex types. JAXB does not promote direct instantiation of such classes; rather, it provides an ObjectFactory to get instances of these classes.

Enhance classes
Before a JDO persistence manager can process any of the content classes, the classes must be enhanced. Enhancement of a class is a unique step required by the JDO. It processes the class files (overwrites) and adds JDO-specific code to them (you can explore what is modified by the enhancer by reading the log included in readme.txt). The JDO reference implementation comes with the Enhancer com.sun.jdori.enhancer. Main, which reads JDO metadata for each class that must be run within the JDO environment. In our architecture, this step is a main connection between JAXB and JDO.

Build content objects
Generally, when JAXB is used independently, content objects can be built using JAXB-generated implementations of interfaces. This step is also called "unmarshalling." When you need to process these classes using JDO, you use the class files that are enhanced in the previous step. To build the content tree, first create a new instance of JAXBContext by providing a contextPath parameter that contains a list of Java package names that contain schema-derived interfaces, specifically the interfaces generated by the JAXBbinding compiler (in this case it is just the "customer"), then create an unmarshaller using JAXBContext; finally, you get a root content object (based on the XML tree) using the unmarshaller by passing it an input instance XML document. After that, you can simply navigate the content object tree using various accessor methods.

Persist content objects
There are various architectures proposed by JDO to persist content objects in the data store (please refer to the previously mentioned book on JDO). The example presented here uses the simplest model for using single PersistenceManager. To be able to persist content objects, you also need to build the JDO-aware classes that make direct use of the JDO API, generally called transient classes. In our example, DBManager, CreateCustomer, and PrintCustomer are JDO-aware classes. On the other hand, CustomerTypeImpl is a JDO-transparent class that makes no direct references to the JDO API. That's where JDO is much more powerful than other technologies such as JDBC.

This discussion can be a bit overwhelming initially, but once you work through the example code it should be much easier to comprehend. The example will show you that most of the code is generated using JAXB and JDO and not much is being built manually.

Example
Let's take a look at a very simple application based on the above architecture. We start with customer information presented in an XML file. An associated schema is also built for the XML data file to be able to generate the class files. From this point on we really don't have to build any Java code to represent the data in a Java content object tree. The only code we'll build will process these objects to store them in the database and fetch them from the database. JDO-aware classes will be used to perform these operations.

The example comprises the following files (code listings can be found at www.sys-con.com/xml/sourcec.cfm):

Java Data Objects (O'Reilly): www.oreilly.com/catalog/jvadtaobj/

Published Aug. 27, 2003— Reads 14,603 — Feedback 6
Copyright © 2003 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.

Related Links

▪ Source Code

About Rajesh Zade
Rajesh Zade has more than 13 years of experience in the computing field and has been working in various Java and e-Commerce technologies since 1996. He is currently chief technical architect for NetCliff, Inc., based in Santa Clara, CA.