Using JAXB in Enterprise J2EE Applications
By Tilak Mitra
It has been well proven over the past few years that the best form of information exchange (in a typical B2B and B2C environment) is through XML. There are various XML-based standards (schema) for both the horizontal and vertical market sectors and there are ongoing efforts to move toward a standardized format in the various industry sectors.
With the proliferation of an XML-based information exchange, the industry is bound to write lots of Java code to consume XML Schema-based documents. Java Architecture for XML Binding (JAXB) provides a convenient way to bind an XML Schema to a representation in Java code, making it easy for developers to incorporate XML data and processing functions in applications based on Java technology without having to know much about the details of XML parsing.
How It Works
The JAXB (binding) compiler creates a set of classes and interfaces from the XML Schema (see Figure 1). These sets of classes and interfaces are referenced and used in the application. The application developer has a rich set of JAXB APIs that he or she uses to convert a Java object tree/ structure (made up of the instances of classes generated by the binding compiler) to an XML document (that conforms to the XML Schema). The process of converting an XML document into a Java object tree is as seamless and easy as the former and the beauty of it all is that the developer does not have to write a single line of XML parsing routines in either of the conversion processes.
The process of converting a Java Object Tree to an XML document is known as marshalling, whereas the reverse process of converting an XML document to a Java Object Tree is called unmarshalling.
The process of creating the classes and interfaces from the XML Schema utilizes the JAXB binding compiler (xjc.bat or xjc.sh) that's included with the installation (see Resources section).
xjc.bat -p <package name> -d <working directory>
The -p option specifies the Java package for the generated classes and interfaces while the -d option specifies the working directory.
Once the classes and interfaces are generated, they can be used in the enterprise application. There are two typical usage scenarios.
1. Unmarshal an XML document to a Java object tree
JAXBContext jContext = JAXBContext.newInstance("<package name>") ;
where package name contains the JAXB generated classes.
Unmarshaller unmarshaller = jContext.createUnmarshaller() ;
* The XML document is read in and a handle to the root Java object in the XML document is obtained:
Library library = (Library)unmarshaller.unmarshal(new
library.xml is an example XML document that conforms to the schema file from which the JAXB-generated Java classes and interfaces are created, and Library is the root object in the XML document.
Once a handle to the Library object instance is obtained, we're in the Java universe! The developer can use the power of Java to traverse through the object tree and use the same in the application, as required.
2. Marshal a Java object tree to an XML document
Consider a small example in which a Library contains a list of Books in which
each book has a title and a price field. The steps to create an XML document
from the Java object tree are as follows:
ObjectFactory factory = new ObjectFactory() ;
* Create class instances:
Library library = factory.createLibrary() ;
* Create an instance of the Marshaller object (from JAXBContext object instance as in scenario 1):
Marshaller marshaller = jContext.createMarshaller() ;
* Marshal the Java object tree to an XML document:
marshaller.marshal(library, new FileOutputStream("library.xml")) ;
Customization has four scopes:
Although a detailed discussion about customization is beyond the scope of this article, it's worthwhile mentioning a few customization artifacts that are used more frequently in a typical JAXB usage scenario.
Customization bindings can be made at a global level of declaration that applies to all the defined elements in the XML Schema. Listing 1 provides a typical global customization binding.
Notice how in the listing defining the collectionType attribute tells the compiler that the type of collection used in the generated classes is of type ArrayList. The <xjc: serializable> element ensures that all the generated classes implement the Java Serializable marker interface. The <jxb: package> element's name attribute denotes the Java package in which the generated classes and interfaces are created.
All these elements' attributes can be tuned and configured to suit the requirements of the application.
Customization of the default binding can also be made at the element and its attribute's level. For example, an element can be adorned with its Javadoc by using annotations. Custom property names can also be specified that when defined, generate getter and setter methods for the property. This is illustrated in Listing 2. (Listing 2 can be downloaded from www.sys-con.com/java/sourcec.cfm.)
Notice how in the listing the <jxb: javadoc> element is used to create the documentation for the generated class. The <jxb:property> element is used to name an instance variable inside the generated class (Library class in this case) and generate its getter and setter methods. The generated class hence will have two methods: getBookList() and setBookList(...).
A detailed explanation of these bindings can be found in the Resources section (JAXB User's Guide).
Thinking in Terms of JAXB
Part 2 will take a concrete example of an XML Schema and discuss the process of generating the classes and interfaces from a valid XML document and also the reverse process of creating an XML document from a Java object tree. Stay tuned!
(Note: The Reference Implementa-tion of JAXB comes packaged inside the Java Web Services Developer's Pack [JWSDP]. Once this is installed, the JAXB compile time and runtime libraries are available in the <install-root>\jaxb directory).Copyright ©1994-2005 SYS-CON Publications, Inc.
Questions or problems regarding this web site should be directed to email@example.com.
Copyright © 2008 Art Beckman. All rights reserved.
Last Modified: March 9, 2008