he integration of heterogeneous software systems often requires disparate clients to share data seamlessly in real time. Two technologies that have eased this data flow are XML and Web services, which use SOAP to make the integration more seamless.

One way to handle data exchange within a Web service application is to publish an XSD (XML Schema Definition) that requires all client applications to send XML data that’s compliant with the published XSD. As long as you maintain a single XSD and all your clients’ XML complies with it, your Web service will run with no problems. However, life in the software industry is seldom smooth. The software requirements involved in systems integration change frequently and you need to accommodate them. However, once you’ve published an XSD that all clients use, modifying it becomes complicated since any changes affect all the clients as well. Alternatively, you could publish multiple versions of the XSD and process different incoming XML versions in your application.

This article examines the problem of version management in an integrated application and demonstrates how to handle it with XMLBeans, the latest addition to the Java family of parsers.

Introduction to XMLBeans
XMLBeans is a Java-XML binding tool that enables you to access the full power of XML in a Java-friendly way. With XMLBeans, you get a familiar Java object-based view of XML data without losing the richness of the native XML structure and schema.

The starting point for XMLBeans is XML schema. A schema (contained in an XSD file) is an XML document that defines a set of rules to which other XML documents must conform.

You compile the schema (XSD) file to generate a set of Java interfaces that mirror the schema. With these compiled classes, you process XML instance documents that conform to the schema. You bind an XML instance document to the compiled classes; changes made through the Java interface change the underlying XML representation.

XML programming interfaces (such as DOM or SAX) or an XML marshalling/binding tool (such as JAXB) lacks strong schema-oriented typing. Navigation in a DOM-oriented model is “space inefficient” for large documents, and JAXB provides support for the XML but does not support all its features such as namespace binding. XMLBeans is fast, space efficient, rich in functionality, and easy to use.

Real World Example: Purchase Order Application
The sample codedemonstrates a purchase order (PO) processing application. This application takes XML file references, but you can modify the code with server-side EJBs to process incoming XML. For this example, you published PO.xsd and all the client applications send their purchase orders in an XML format compliant to the published XSD. In the initial version, customer name and order date constitute the key to uniquely identifying each PO:

                  maxOccurs="unbounded"/>      

XMLBeans provides a batch file (scomp) to compile the XSD files. In this example, all the compiled classes have the package name openuri.org.v1.easypo. This name corresponds to the targetNamespace in the published XSD. Here is a simple PO XML that is compliant with the published XSD:

   Foo Bar  Anytown, PA  2004-11-05     Software testing tool   5   1000.00   2           ZipShip    1  

The server-side code uses XMLBeans to parse the incoming XML. The MultiVersion.jar contains all the XMLBean classes generated when the XSD is compiled. XMLBeans provides a factory class to parse the XML and create an instance of the PurchaseOrderDocument class:

org.openuri.v1.easypo.PurchaseOrderDocument poDoc =   org.openuri.v1.easypo.PurchaseOrderDocument.Factory.parse(File po);

All the data elements will be extracted from the PurchaseOrderDocument instance. The sample application prints all the extracted data elements.

Modify Purchase Order XSD
For faster searches, you decide to add a PO number to uniquely identify each purchase order. Requesting all clients to modify their software to accommodate this change would be difficult. You would have to publish both versions of the XSD and process both XML versions transparently in your application. Handling multiple XML versions will result in messy code. If the design is not simple, further enhancements will be hindered. XMLBeans comes in very handy here.

The first step is to create a new version of the XSD with a new element poID:

	                                                                                                                        maxOccurs="unbounded"/>                                            

The target namespace is modified to include the version number. As mentioned earlier, when the XSD is compiled, XMLBeans generates the same class PurchaseOrderDocument but with a different package name. This provides a separate class for each version, which is very useful. This is the revised XML:

     100025    Foo Bar  Anytown, PA  2004-11-05     Software testing tool   5   1000.00   2           ZipShip    1  

Each PurchaseOrderDocument class generated by XMLBeans can parse only one particular version of XML. It throws an exception when you try to parse a different version of XML. This makes it easy to identify the version of the incoming XML:

try{   org.openuri.v1.easypo.PurchaseOrderDocument poDoc_v1 =  
	org.openuri.v1.easypo.PurchaseOrderDocument.Factory.parse(po);  }catch(Exception e) {   org.openuri.v2.easypo.PurchaseOrderDocument poDoc_v2 =	
	org.openuri.v2.easypo.PurchaseOrderDocument.Factory.parse(po); }

Once the Purchase Order version is identified, the rest of the logic remains the same. Since XMLBeans provides a flexible way to convert XML-java-XML, the backend code can be simplified to handle multiple versions of XML.

Make Your Clients Happy
When you handle multiple versions of XML with XMLBeans, you will not only have a lot of happy clients talking to your application but your managers will praise you for your smarts.