|
|
Java API for XML Binding (JAXB) is the much-anticipated Java API designed to provide a programmatic association between XML and Java. Like much of the other JAX APIs, JAXB is designed to provide an abstraction layer at the Java code level, insulating developers from dealing with building, reading, and processing the underlying XML constructs. In general, binding provides developers with a programming-language-centric view of the underlying XML. Though binding developers deal only with objects and classes in their Java code, these objects and classes correspond to underlying XML constructs.
 |
At the time of writing this book, the JAXB specifications were public draft version 0.75 and Reference Implementation 1.0. We do not anticipate significant changes between these and the FCS.
|
In Chapter 9, we introduced the concept of parsing XML using SAX and DOM. However, we also mentioned that this would not be necessary, because developers will work with JAXB. Let us now expand on this.
The traditional design approach when dealing with XML in application code has centered around retrieval and parsing of XML, using XML parsers and API (such as JAXP and SAX/DOM) and manipulating the result of that parsing exercise. For example, with SAX, developers run though an XML file in a serial manner, access data, and use its programmatic representation—their own Java objects. Alternatively, developers parse the XML using a tree-based approach and create object tree representations in memory, using a model defined by some other party (e.g., the W3C DOM) or JDOM. In either case, there is a disconnect between the XML data definitions.
For example, the purchase order used in Listing 11.5 is represented by an XML schema shown in Listing 13.1. The schema was not listed earlier for brevity but is included with the example code.
|
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.flutebank.com/schema" xmlns:xsd="http://
www.w3.org/2001/XMLSchema" xmlns="http://www.flutebank.com/schema" elementFormDefault=
"qualified">
<xsd:element name="billingaddress">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="name"/>
<xsd:element ref="street"/>
<xsd:element ref="city"/>
<xsd:element ref="state"/>
<xsd:element ref="zip"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="date" type="xsd:string"/>
<xsd:element name="description" type="xsd:string"/>
<xsd:element name="identifier" type="xsd:string"/>
<xsd:element name="item">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="quantity"/>
<xsd:element ref="productnumber"/>
<xsd:element ref="description"/>
<xsd:element ref="unitcost"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="items">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="item" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="name" type="xsd:string"/>
<xsd:element name="productnumber" type="xsd:string"/>
<xsd:element name="purchaseorder">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="identifier"/>
<xsd:element ref="date"/>
<xsd:element ref="billingaddress"/>
<xsd:element ref="items"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="quantity" type="xsd:int"/>
<xsd:element name="state" type="xsd:string"/>
<xsd:element name="street" type="xsd:string"/>
<xsd:element name="unitcost" type="xsd:decimal"/>
<xsd:element name="zip" type="xsd:string"/>
</xsd:schema>
|
To pass this logical collection of data around in their code, developers often define a Java class that wraps the data into a JavaBean-type construct, with get/set methods or the attributes. However, the class is developer-designed and -defined and is therefore based on the developer's interpretation of the XML schema. For example, based on the schema in Listing 13.1, a developer may create an Item bean as follows:
package com.jwsa.mybeans;
public class Item {
private String Quantity;
private String Productnumber;
private String Description;
private String Unitcost;
public String getQuantity() {
return Quantity;
}
public void setQuantity(String quantity) {
Quantity = quantity;
}
public String getProductnumber() {
return Productnumber;
}
public void setProductnumber(String productnumber) {
Productnumber = productnumber;
}
public String getDescription() {
return Description;
}
public void setDescription(String description) {
Description = description;
}
public String getUnitcost() {
return Unitcost;
}
public void setUnitcost(String unitcost) {
Unitcost = unitcost;
}
}
Another developer may create another class with a completely different representation or even a different hierarchy. Both would parse the corresponding XML, validate it against the schema, populate their Item bean (or whatever other representation they define), and use it in the code. This approach has issues.
It requires manual effort and extra coding.
Any change in the schema requires changes to Java code, reducing the inherent flexibility of using XML in an application.
It produces code that may vary from developer to developer.
The programmatic representation may be inaccurate.
The code is not portable, because of developer interpretation. Two applications using the same XML schema may end up using completely different PurchaseOrder objects that are mutually incompatible.
To generate the XML representation back from the object representation, developers have to write extra code. For example, developers frequently include a toString() method in their objects (e.g., PurchaseOrder) that creates an XML string conformant to the schema based on the object properties.
JAXB aims at resolving these issues by giving developers a standard API to program to and automating the Java-XML marshalling and XML-Java unmarshalling with round-trip support between XML and Java.
|
Recall from Chapter 10 that marshalling is the process of creating the XML representation from Java objects—that is, Java-XML—and the reverse process is called unmarshalling.
|
|
|