Java and XML complement each other perfectly. "Portable Code, Portable Data," is Sun's tagline for describing how Java and XML work together, and it's right on the money. One of the best reasons for using Java is its portability; you write for the Java Virtual Machine (JVM), not a specific platform. Your application will run on any platform that has a JVM. Java supports Unicode from the ground up, so you have internationalization built right into your application; localization, of course, is another issue. It is a clean, easy-to-use object-oriented language that has gained widespread use and acceptance.
Java and XML complement each other perfectly. “Portable Code, Portable Data,” is Sun’s tagline for describing how Java and XML work together, and it’s right on the money. One of the best reasons for using Java is its portability; you write for the Java Virtual Machine (JVM), not a specific platform. Your application will run on any platform that has a JVM. Java supports Unicode from the ground up, so you have internationalization built right into your application; localization, of course, is another issue. It is a clean, easy-to-use object-oriented language that has gained widespread use and acceptance.
There are many reasons why XML has achieved the same widespread use and acceptance that Java has. First, XML is a standard that defines a language to create markup languages. This standard is maintained by the World Wide Web Consortium (W3C), not any particular company. So, you don’t have to worry about different “flavors” of XML causing incompatibilities across platforms. And since there is only one standard, every XML parser will parse valid XML. There are numerous free XML parsers and APIs with years of development and use available instantly. You don’t have to write your own parser for your customized data format — a potentially lengthy and costly endeavor. XML documents have an intrinsically hierarchical structure, which makes it easy to build hierarchies of objects in your application. Finally, processing international documents is much simpler since XML parsers must support Unicode encoded files.
In previous issues, Norm Walsh explained the basics of XML documents (XML Basics, July 2001, http://www.linux-mag.com/2001-07/xmlintro_01.html) and followed up by showing how to get information out of XML documents (DOM-inating with XML, October 2001, http://www.linux-mag.com/2001-10/xmldom_01.html).
When reading about XML, it can seem as though you are drowning in letters. The following table lists a few of the most common abbreviations (in alphabetical order), their definitions, and where you can find more information about them.
Put Java and XML together and you have a highly portable language with highly portable data. What more could you ask for? How about support for XML built right into the Java 2 Platform? Starting in the Java 2 Platform, Standard Edition 1.4, an XML parser and XSLT transformer will be built into the platform and be accessible through the Java APIs for XML Processing (JAXP). JAXP is a well known and established API that is currently available as an optional package that simplifies accessing pluggable XML parsers.
Now creating a DOM document from your XML file is as simple as what you see in Listing One. Recognizing its utility in long-term data storage, Sun has added a feature whereby XML documents are used to make JavaBeans persistent.
Listing One: Creating a DOM Document
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder docBuilder = factory.newDocumentBuilder();
Document domDocument = docBuilder.parse( xmlFile );
Using the public members of the JavaBean, you can create an XML document that describes the Bean and all its constituent elements. This lets you persist your JavaBeans for storage, allowing them to survive changes to their internal structure. But as long as your Bean’s public interface remains unchanged, you can successfully decode them.
To save your JavaBeans to XML all you need to do is execute something like you see in Listing Two.
Listing Two: Saving JavaBeans to XML
XMLEncoder encoder = new XMLEncoder(
new FileOutputStream( “encoded_bean.xml” )));
encoder.writeObject( yourBean );
Restoring your Beans is equally straightforward:
XMLDecoder decoder = new XMLDecoder(
new FileInputStream( “encoded_bean.xml” )));
YourBeanClass theBean = (YourBeanClass)decoder.readObject();
Sun plans to incorporate a number of core XML-based APIs into the Java 2 Platform as optional packages, including Java APIs for XML Messaging (JAXM), Java API for XML-based RPC (JAX-RPC), the Java Architecture for XML Binding (JAXB), and Java APIs for XML Registries (JAXR).
The Java Architecture for XML Binding will enable you to construct object hierarchies from XML files. JAXB converts an XML schema that describes the structure of the document into Java classes that can read and validate it. The classes enforce all of the constraints described in the schema, which can be difficult to do with SAX or DOM. Currently, the only type of XML schema JAXB understands is a DTD, but it will support other schema types in future releases. (For more on XML schemas, see XML Schema Languages: Why and How to Validate your XML Documents, pg. 26.)
The Java APIs for XML Messaging provide an abstraction for exchanging XML documents in a Business-to-Business (B2B) style environment. The JAXM model is based on the use of clients and providers. The client is typically a business application that needs to exchange information with another business application, usually through a JAXM provider. That information is often an XML document, but it doesn’t have to be.
Providers are the server side of the equation, providing for reliable communication between other providers. A provider is required to use the SOAP 1.1 and SOAP With Attachments specifications as the underlying infrastructure for exchanging messages. However, these specifications provide only a very basic packaging model, without any of them addressing schemes or message structure. A JAXM profile is capable of specifying what the message structure and SOAP header values have to be.
While JAXM focuses on delivering messages with SOAP as the relatively hidden infrastructure, JAX-RPC focuses on creating and accessing Web Services as Java objects with SOAP in a more direct manner. (Despite its name, JAX-RPC doesn’t actually use Remote Procedure Calls such as those that were envisioned in XML-RPC. The JAX-RPC API, however, does not preclude the use of protocols other than SOAP, so we might eventually see an XML-RPC implementation.)
The Java APIs for XML Registries are intended to provide a uniform and standard API for accessing a business registry. Typically, a registry is used to advertise Web Services to the larger business community. There are a large number of overlapping registry specifications (such as OASIS, ebXML, and UDDI) requiring different methods for obtaining information. JAXR hides the implementation details of communicating with a registry and lets the application do what it really wants to do: get information about services from the registry.
A Bright Future
From long-term persistence of your JavaBeans to simplified access to Web Services, XML is becoming a pervasive and influential part of the Java 2 Platform from Sun. More and more Java APIs use XML in one fashion or another; we’ve barely scratched the surface here.
Next month, we’ll explore how to use JAXB to create custom Java classes that can parse and validate your XML documents, creating an object hierarchy you can immediately use in your applications.
Many of the new XML-based APIs for Java have their basis in Web Services, which are being hailed as the next revolution in Business-to-Business, so a brief explanation is probably in order. At its simplest, a Web Service is an application that can be invoked over the Web to perform a service. This service can be as simple or as complex as required, from looking up a stock value to reserving a hotel room. An application most commonly invokes a Web Service using a protocol known as SOAP. For more on SOAP and developing SOAP applications, see “Cleaning Up with SOAP” in the October 2001 issue of Linux Magazine (http://www.linux-mag.com/2001-10/soap_01.html).
The definition of the service is usually provided as a WSDL document, and both the definition document and the service itself are located by querying a registry. There are registry specifications, but the most common being UDDI and ebXML.
Sun’s main XML Web site http://java.sun.com/xml
The W3C Web site
The W3C is a consortium of over 500 member companies that helps define and promote common standards for the Web by promoting interoperability and encouraging open discussion. http://www.w3c.org
Glenn McAllister is a part-time committer on the Jakarta Ant project. He can be reached at email@example.com.