Two foundation technologies, Java and XML, represent the marriage of portable code and data. A key ingredient of a successful marriage is compatibility. XML and a number of XML-based vocabularies are being used extensively as the standard data-exchange mechanism (and beyond) by both stand-alone Java 2, Standard Edition (J2SE) applications and server-based Java 2, Enterprise Edition (J2EE) enterprise applications.

A basic requirement in a number of these programmatic scenarios is the mapping of XML data as Java objects and/or vice versa (converting Java objects into XML). Although there exists a core set of APIs for processing XML, particularly the Java API for XML Processing, which includes basic DOM/SAX-based XML parsing capabilities, object-oriented Java programmers have always needed to consume, manipulate, and generate XML in a more object-oriented fashion through a standardized API set and utilities. The requirement is similar to those presented in scenarios where relational data must be mixed with Java objects, which has resulted in a number of object-relational mapping mechanisms.

Also highlighting the need for an efficient XML binding mechanism are the two extremely different mechanisms that SAX and DOM present for efficiently processing XML. Whereas SAX (Simple API for XML) represents a very efficient, albeit low-level, event-based XML processing engine, DOM (Document Object Model) provides a much easier generic in-memory, tree-based navigation structure. In a nutshell, choosing DOM over SAX may result in significant memory impact, and choosing SAX may present significant programmatic complexity.

JAXB
Java Architecture for XML Binding (JAXB, also known as Project Adelard by Java developers who have been following this project for some time) provides an efficient bidirectional mapping between Java objects and XML documents. Compared to SAX, JAXB provides ease of programming, utilizing a standardized Java objects-based binding framework and a set of tools that can convert existing XML Schemas to JAXB binding classes. However, JAXB-generated Java classes aren't generic parsers that consume any type of XML, but a specific set of XML documents as represented by the underlying XML Schema. This results in a highly efficient mechanism, since the resulting content tree doesn't have the overhead of generic tree-manipulation logic. Figure 1 shows the basic architecture of the JAXB programming model.

JAXB is particularly useful when the processing process is aware of the various XML Schema structures (for known XML documents). Typical uses include manipulating XML-based configuration files, traversing large XML feeds without DOM-based memory overhead, validating user-input data, and so on.

Typical usage of the JAXB framework requires that the developer take an existing XML Schema-based data definition and then, using a schema compiler utility, convert it to a set of Java classes that represent the schema. JAXB, now in its Public Draft 2 status, provides an automated document-type mapping for a subset of XML Schema-based definitions. The implementation can be used to map both simple and complex XML Schemas. Table 1 shows the primitive data-type mapping between XML data and the resulting Java data types.

Key Highlights
Technically speaking, JAXB represents a set of technologies that provide the capability to:

• Generate Java classes from XML Schemas
• Unmarshal XML documents into native Java objects
• Marshal Java objects into XML documents
• Provide optional on-demand validation of XML documents

Key highlights of the JAXB framework are that it:

• Is easy to use
• Is customizable through the addition of xsd:annotation elements in XML Schema
• Hides the complexity of DOM/SAX APIs
• Uses W3C XML Schemas as the definition format (through a defined subset)
• Doesn't support DTDs directly
• Is portable (A JAXB application should be able to utilize different JAXB implementations by just regenerating the schema classes and doesn't require change to the actual application code.)

Availability
At the time of this writing, the JAXB specification was available in Public Draft 2 (released on Oct 4, 2002). A 1.0 beta implementation of JAXB is also available from http://java.sun.com/xml/jaxb. This public draft and 1.0 beta implementation have been used as the basis for this article. JAXB has changed considerably since it was first conceived, the primary change being that JAXB-based binding frameworks can now generate Java classes directly from XML Schemas, eliminating the need to create custom binding schema files. According to Sun's Web site, a final version of the JAXB reference implementation and specification is expected to be available by Q1/2003.

Using JAXB, Step by Step
To explore the functionality of the JAXB API, let's take a hands-on approach and look at how the API can be used to bind XML Schemas to Java objects. For starters, we'll take a simple XML Schema, Message.xsd (see Listing 1). It represents the schema of a simple application-to-application message (see Figure 2).

Executing the XML Java schema compiler (xjc) automatically creates a set of Java classes that represents the Message Schema. The JAXB implementation provides a predefined Ant task (xjc), which can be used to map XML Schemas into a corresponding set of Java classes (as shown in Ant build file [see Listing 2]; if you're new to Ant, it is one of the most popular and powerful XML-based next-generation application build toolsets). Ant can be used to compile the set of generated classes as well. Figure 3 shows a UML class diagram of the generated classes.

The resulting set of Java classes can be used by an application to interpret the XML documents representing the Message Schema (ReadMessage.java, Listing 3) or to create them (CreateMessage.java, Listing 4). As is probably clear from the Java source code, the ReadMessage application parses an input XML document and generates a simple representation of the XML Message. On the other hand, the Create Message application creates an XML-based message from the dynamic values.

JAXB Customization - Binding Declarations
One objective of the current public draft release of the JAXB specification is a seamless schema-generation capability through predefined W3C XML Schemas, which (in many cases) does not require the developer to make any changes to the structure. However, the framework does provide the flexibility for use cases that require doing so. In some scenarios, schema customization is required to resolve conflict during class generation. For example, if your input XML Schema had an element named "class", the resulting getClass() method would conflict with the already present getClass() method for java.lang.Object. To explore schema customization further, let's look at another example. Listing 5 (the corresponding schema is also shown in Figure 4) shows the usage of jxb:property and jxb:javaType tags under the lineNo element. These tags force the schema compiler to override the defaults provided by the XML Schema and use (in this scenario) the property name and the Java type specified. Similarly, the JAXB specification documents a number of such customizations that can be applied to XML Schemas to fine-tune the generation of Java classes. Schema customization enables the developer to control the generated Java classes: package names, names of derived interfaces, the names and types of methods, attribute name/type binding, and so on.

Similar to our previous example, Ant and the xjc schema compiler can be used to create the Java classes from the schema. Figure 5 shows a UML class diagram of the basic interfaces generated through the process.

Listing 6 shows how the generated schema classes can be used to perform computations on the input XML. Listing 7 shows a scenario where the Java application is manipulating the Java content tree, in this case adding a new element called "comment".

Conclusion
The development and evolution of the JAXB programming model isn't far from the issues. The JSR-31 expert group has taken quite a while to put the specification together; in fact, we are still waiting for the final specification release. One probable reason for the delay of JSR-31 is the significant time that it took for XML Schema itself to be endorsed as a W3C Recommendation. Also, the current version of the JAXB specification doesn't completely map XML Schemas into Java classes. The specification identifies several scenarios as not in scope for the current version, including substitution group support, wildcard schema component, notation declarations, identity constraint definitions, and so on.

However, the ease of use that has been highlighted by the specification and reference implementation still makes JAXB a significant benefit to developers using Java and XML technologies together. Overall, we can expect that the JAXB specification/implementation will mark the beginning of standardized, automated, round-trip Java-XML binding capabilities.

As B2B interactions are automated and standardized, an efficient mechanism to generate and consume XML documents becomes more important than ever. With the emergence of Web services, this is likely to be further signified; developers will be receiving complex XML documents through SOAP-based Web services invocations. JAXB provides a much-needed Java-XML binding combination.

References

Java Technology for XML: http://java.sun.com/xml

Java Architecture for XML Binding: http://java.sun.com/xml/jaxb/index.html

JSR-31: www.jcp.org/jsr/detail/31.jsp

JAXB Downloads & Specification: http://java.sun.com/xml/downloads/jaxb.html

• Figure 1
• Figure 2
• Figure 3
• Figure 4
• Figure 5
• Source Code
• Figure 6