Feature

Java and XML are perfectly married. Java represents a technology evolution for platform-independent development and deployment, and an effective mechanism for achieving distributed computing. XML, a very simple concept, has taken the industry by storm and is revolutionizing how data is represented and exchanged within a company and between enterprises. In a nutshell, Java represents portable code and XML represents portable data - a perfect marriage.

In an effort to fuel this marriage, Sun has launched a set of technologies collectively known as the JAX Pack. JAX Pack - essentially a bundled set of Java technologies for XML - consists of JAXP (XML Processing), JAXB (XML Binding), JAXM (XML Messaging), JAX-RPC (XML-based RPC), and JAXR (XML Registries).

These technologies for XML are available as separate specifications, APIs, and reference implementations (some specs/implementations are generally available; others are works in progress). However, JAX Pack is also available as a combined set of all the JAX technologies in a single download. The standards/specifications representing the various Java technologies for XML have been developed collaboratively with the Java Community Process (JCP; see sidebar).

The objective of this article is to walk through these APIs, review their functionality, and, using code examples, illustrate how they can be used within applications.

JAXP
Fundamental to the fusion of Java and XML technologies, the Java API for XML Processing provides a set of APIs for parsing, creating, and transforming XML documents. JAXP supports both the memory-based DOM2 (Document Object Model) and the event-based SAX2 APIs for XML parsing (Simple API for XML). With the 1.1 release JAXP also supports XSLT-based transformations, a critical component that adds a new level of abstraction and ease to transforming XML documents into other XML vocabularies, plaintext, and even print media (using XSL Formatting Objects).

Given this introduction to JAXP, you may wonder why, since a large number of companies have built their own XML parsers and XSLT processors, we need another one.

The answer is simple: JAXP isn't just another XML parser. Instead, what JAXP APIs and the reference implementation provide is a standard set of Java APIs that define a factory-based pluggable framework for XML parsers and XSLT processors (as illustrated in Figure 1).

The reference implementation of JAXP uses the newly released Apache Crimson (http://xml.apache.org/crimson/) as the XML parser and Apache Xalan (http://xml.apache.org/xalan-j/index.html) as the default XSLT processor, but it's really a matter of calling some APIs and setting some system properties if you'd like to use your favorite parser/processor.

A key component missing from the JAXP API set is the support for XML Schemas, expected in future releases. JAXP does support document type definition (DTD) based XML validation and using a third-party parser such as Apache Xerces (http://xml.apache.org/xerces-j/index.html) or Apache Xerces2 (http://xml.apache.org/xerces2-j/index.html). Setting a couple of attributes to indicate that your application needs XML Schema validation is what's required.

JAXP has been a popular API; it's been incorporated in the newly released J2EE v1.3 specification to provide XML parsing/processing capability to server-based enterprise applications. It's also been incorporated by a large number of third-party application servers and other products. As another endorsement of this key API, JAXP 1.1 has been included as a core aspect of the new version of the Java platform (J2SE v1.4).

A simple code snippet is worth a thousand words. Following is a sample XML document (Order.xml) defined by a DTD - Order.dtd. I'll show how this document can be processed and transformed using the JAXP API set, and will use the same example in later sections to demonstrate how the various Java technologies for XML work together.

11-12-2001
Silverline Technologies

Following is the XML structure - Order.dtd:

id CDATA #REQUIRED>

Now let's use the JAXP API set to create a simple Java application to parse the XML document. In this scenario I'll use the DOM API to parse the various elements and attributes of the Order.xml structure:

import javax.xml.parsers.*;
import org.w3c.dom.*;
...
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder();
Document doc = db.parse(new File("Order.xml"));
Element root = doc.getDocumentElement();
System.out.println("Order Id:"+root.getAttribute("id"));
NodeList nl = root.getChildNodes();
for (int i=0;i ... // Process other nodes
}
}

SAX and DOM provide the basic low-level generic API to parse and validate an XML document. Earlier we introduced XSLT, an XML standard that can be used to transform an XML document/stream into another XML, HTML, WML, or any other format.

Let's use the other key component of the JAXP API, stylesheets, to transform an XML document. Note the abstraction and ease of use XSLT provides us. The following example uses XSLT to create HTML on the fly as a Java application, but this same functionality can also be used to create a full-fledged content management application using J2EE APIs such as Java servlets and JavaServer Pages.

import javax.xml.transform.*;
import javax.xml.transform.stream.*;
...
TransformerFactory tFactory =
TransformerFactory.newInstance();
Transformer transformer = tFactory.newTransformer(
new StreamSource("Order.xsl"));
transformer.transform(new StreamSource("Order.xml"),
new StreamResult(System.out));
...

Transformation of XML documents using XSLT requires the creation of an XSLT-based stylesheet. Following is the simple stylesheet that converts the Order.xml into HTML:

xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">



Order Id:

Date:

Company:

JAXB
Whereas JAXP provides the basic/core API for processing XML, there are really two kinds of implementations for an XML parser that supports the JAXP APIs. On the one hand we have DOM, which provides a tree-based generic navigation for an XML document; on the other we have SAX, a fast, event-based, but very low level API. The two have often been compared on the basis of speed, resource requirements, and ease of use, but as illustrated previously, even by using the higher level DOM interface, the simplest Java application for processing the basic Order.xml document requires a certain amount of coding (we didn't really account for any error handling and processing logic).

In a nutshell, there's a need for a seamless interface that provides an easy-to-use programmatic interface for Java developers to parse, manipulate, and create XML documents.

JAXB - Java Architecture for XML Binding (previously known as Project Adelard) - fills this gap by providing performance-centric bidirectional mapping between Java objects and XML documents. Whereas a JAXB implementation may use JAXP-based XML core parsers underneath, when compared to DOM and SAX, JAXB truly provides an easy-to-use alternative mechanism for processing XML documents.

JAXB is divided into two components: a schema compiler and a binding framework. The XML-based binding schema is used to bind the XML DTD with Java-based artifacts such as the primitive and complex type mapping, customization of the generated classes (packages, class names, method names, constructors, etc.), and so on.

A schema compiler, illustrated in Figure 2, then creates a set of predefined Java classes that build a Java object tree corresponding to the validated XML document supported by the mapped schema rules. Instances of the Java classes, which use the JAXB runtime, can then be used to process and manipulate XML content from within the known Java environment. Even though JAXB-based Java classes do store the resulting mapped XML in memory, the memory overhead typically caused by the generic XML parser is significantly reduced, with the added benefit that you can strictly validate XML documents.

A current limitation of the JAXB specification is that it addresses only DTD-based XML definitions. We can expect future releases to provide an implementation on top of the prevalent XML metadata standards, such as XML Schema.

JAXB Example Scenario
Using a simple scenario, let's explore the JAXB API and its benefit for binding XML documents to Java objects. First we need to create an XML Java Binding Specification file to map the various datatypes with the DTD. We'll again build on top of the Order example used previously (Order.xjs):

Executing the XML Java schema compiler, xjc (java com.sun.tools. xjc.Main Order.dtd Order.xjs), creates Order.java. This class file can be used by any Java application to bind XML documents to Java objects. Following is the example application (ReadOrder.java):

import javax.xml.bind.*;
import javax.xml.marshal.*;
...
Dispatcher d = Order.newDispatcher();
File orderFile = new File("Order.xml");
FileInputStream fis = new FileInputStream(orderFile);
Order order = (Order) (d.unmarshal(fis));
System.out.println("Order Id: "+order.getId());
System.out.println("Company: "+order.getCompany());
System.out.println("Date: "+order.getDate());
...

Running the Read Order Application would result in printing the order ID, company name, and order date.

JAXM
Java API for XML Messaging (JAXM, earlier known as the M Project), as the name suggests, provides a lightweight API for XML-based messaging based on SOAP 1.1 (including attachments support). The advent of the B2B integration model has made the synchronous request/reply model using HTTP/SOAP-based connectivity predominant. JAXM is primarily focused on creating and sending/receiving SOAP-based messages. As a basic API, JAXM is pretty lightweight in messaging, but allows flexibility for implementation to JAXM providers through the concept of profiles.

A highlight of the current release of JAXM and the reference implementation is the ebXML profile, which supports the asynchronous messaging model based on the ebXML Messaging Specification. This model is critical in high-volume and loosely coupled scenarios, in which as a Web services client you'd like a "fire and forget" messaging scenario - send the message through a messaging layer and let the consumers of the message worry about when to process it.

Apart from the loose-coupling benefit, a key aspect of the asynchronous messaging models is the inherent service-level guarantees you can achieve. For instance, achieving features such as guaranteed delivery in a typical request/response interaction can be a daunting task, one that typically requires an implementation to implement substantial error-handling functionality. On the other hand, guaranteed delivery is one of the highlights of a loosely coupled messaging model.

Asynchronous communication isn't new to the IT industry; messaging systems such as MQSeries, TIBCO, and MSMQ have been the foundation for integrating disparate systems for a large number of organizations. Java Message Service (JMS), another specification from Sun Microsystems, takes a messaging vendor-independent, provider-based approach (similar to JDBC) to provide a baseline API for messaging systems. JAXM takes this one step further; using a concept of profiles, it bridges the interaction of standards-based Web services with the JMS-based pluggable messaging infrastructure.

JAXM defines the interactions between two entities, a JAXM client and a JAXM provider. JAXM clients use the API to create/send messages, whereas JAXM providers implement the API to support the actual transmission and reception of SOAP messages, as illustrated in Figure 3.

To uncover the details of how the JAXM API works, I'll create a simple JAXM client that calls a SOAP service that an external vendor/customer can use to get the current order status for a particular order (see Listing 1).

JAX-RPC
Remote Procedure Call (RPC), a mechanism that enables a remote machine (typically the server) to call a procedure, isn't new to the Java platform. Remote Method Invocation (RMI) has been a fundamental component of the Java platform and the basis of key enterprise Java technologies such as Enterprise JavaBeans (EJB). CORBA, another step toward the evolution of RPC, has provided a platform- and programming language-independent mechanism for calling remote procedures. Various implementations of RPC, including RMI and CORBA, have been key components in the design and development of distributed Java technologies.

It's always been a challenge when the "remote server" is located in another company; this is known as being outside the firewall. Even though there are vendor solutions for tunneling RPC calls within ubiquitous Internet communication standards such as HTTP/HTTPS, setting up a distributed, loosely coupled B2B architecture between enterprises has always been challenging. This has led to the development of standards such as SOAP, a specification that defines an XML-based protocol for representing loosely coupled distributed remote procedure calls. W3C has recognized SOAP and has initiated a working group for the development of the next generation of XML-based messaging, XML Protocol (XMLP).

Continuing with the philosophy of standards-based access, the Java API for XML-based RPC (JAX-RPC) defines a set of APIs for facilitating XML-based RPC communication with the Java platform. The initial release of JAX-RPC (1.0), currently in community draft stage, requires implementations to support SOAP 1.1 on top of HTTP 1.1 communications. However, the whole JAX-RPC initiative has paved the way for supporting other protocols such as XMLP and communication mechanisms such as HTTPS. Fundamental to JAX-RPC is the type mapping between Java and XML datatypes and a programming model. The JAX-RPC runtime can be implemented as a client component, building on top of J2SE, or an enterprise/server-based component leveraging either a Servlets 2.3-based model or the fullblown capability of J2EE 1.3-based application servers.

Web Service Description Language (WSDL) has been used by JAX-RPC as the standard for specifying JAX-RPC-based services; the specification defines a bidirectional mapping between WSDL and Java. Implementations can support multiple interaction modes, including synchronous request/response, one-way RPC, and nonblocking RPC invocation.

To understand how JAX-RPC works, let's look at the various steps involved in developing, deploying, and using an XML-RPC-based service. Developers familiar with the Java RMI/CORBA programming model would find this very similar, as illustrated in Figure 4.

• Service definition: Define the service using the familiar Java RMI definition syntax:

  public interface OrderStatusProvider extends java.rmi.Remote {
  public String getOrderStatus(String orderId)
  throws java.rmi.RemoteException;
  }
  

• Service implementation: Implement the service. Depending on the type of JAX-RPC container implementation, the service can be implemented through a J2SE container (by extending the PortableRemoteObject class) or by using a J2EE component model such as session EJB.
• Service deployment: Deploy the service on a server-side JAX-RPC-based container. This step also creates and activates the associated bindings such as SOAP/HTTP, depending on the protocols supported and the deployment configuration.
• The deployment tool: This tool exports the service definition as WSDL.
• Service invocation: From a client's perspective, a client uses a WSDL-to-Java compiler to generate the necessary stubs to invoke the service.
• The stub can then be used by client programs.
• Alternatively, the client may also use a Dynamic Invocation Interface (DII) to bind to the service without the stub generation process.

JAXR
Java API for XML Registries is a standard programming API for interfacing with business registries (think of a registry as a bulletin board, a set of yellow pages for Web services) of Web services providers. These registries can be owned privately by an organization or can be a collaborative exchange-based effort fueled by a specific vertical group (such as a chemical or automotive exchange). An important component in the evolution of Web services, we've already seen efforts such as UDDI (Universal Description, Discovery, and Integration), OASIS, eCo Framework, and ebXML lead the development of such registries. JAXR is an attempt to provide a common abstraction for multiple registry standards.

JAXR defines the concept of a capability profile, which allows registry providers to classify themselves based on the level of support. Currently two profiles - Level 0 Profile and Level 1 Profile - have been defined. As the nomenclature probably suggests, Level 0 is a baseline profile that defines a business-level API; registry providers of a Level 1 Profile can optionally support a generic API for flexibility and advanced registry capabilities.

JAXR builds on top of other JAX technologies, leveraging JAXP/JAXB for processing XML, JAX-RPC for communication, and JAXM for XML-based messaging. At the time this article was written, JAXR was in the early phase of its development, with only a draft version of the specification available. The specification did, however, define how JAXR APIs map to ebXML and UDDI. Based on the specification, the code snippet in Listing 2 shows a possible use of the JAXR APIs - to connect with an internal UDDI registry service.

From a business perspective, to understand how JAXR and the overall business registry concept works, consider a business scenario in which a computer manufacturing company, A, wants to order some raw materials. A queries the public UDDI registry, hosted by a vertical exchange, C, and through that is able to locate a wholesale supplier, B, that provides the appropriate raw materials. Through well-defined services, an integration workflow is then able to call an order entry system of that supplier, order goods.

The whole B2B interaction can happen in an automated, seamless fashion. JAXR will be a significant component in implementing the scenario in which JAXR APIs will be used by A to query the registry and possibly by exchange with C to implement the registry itself. One reason why JAXR would be significant is that multiple registry standards are evolving and, through various factors such as evolution, market pressure, and customer requirements, companies and vendors would potentially be required to support multiple registry formats and exchanges (see Figure 5).

Availability
Table 1 summarizes the availability and high points of the different Java technologies for XML. At the time of this writing, two technologies, JAXP 1.1.3 and JAXM 1.0, were available as part of the fall 2001 JAX Pack. An early-access implementation of JAXB was also available. However, JAX-RPC and JAXR are still developing technologies and reference implementations were not available.

Conclusion
I think it's safe to assume that Java technology is here to stay. Portable code executing on multiple platforms has turned out to be a great value proposition, at least for the server. An important participant in server-based interactions, specifically with B2B relationships, is XML. The JAX Pack provides a good combination of a wide range of Java technologies that would largely simplify developing applications around XML, whether it's parsing XML, transforming XML, writing Web services, or communicating synchronously/asynchronously using SOAP.

Also, as we've seen, most of these APIs are written using a driver/ provider philosophy that makes the API more generic than the individual protocols themselves. As seen in Table 1, a lot of progress has occurred in the Java community to support the various XML technologies as part of the Java platform; some work still needs to be done - reference implementations need to be generally available, with vendor-specific enhancements and suites soon to follow. In a number of initiatives, we've already seen JAXP included as a core API; it's part of the J2EE 1.3 and J2SE 1.4 specifications. Overall, we can expect the JAX Pack to establish a set of baseline technologies for bridging the gap between the various components of the Java platform and the XML-based standards, thus building on the destined marriage between Java and XML technologies.

References
Following are some Web sites for you to look at while implementing and developing these technologies:

• Java Community Process (JCP): http://www.jcp.org
• Java technology for XML: http://java.sun.com/xml
• Java XML Pack: http://java.sun.com/xml/javaxmlpack.html
• Java API for XML Parsing: http://java.sun.com/xml/jaxp/index.html
• Java Architecture for XML Binding: http://java.sun.com/xml/jaxb/index.html
• Java API for XML Messaging: http://java.sun.com/xml/jaxm/index.html
• Java API for XML-based RPC: http://java.sun.com/xml/jaxrpc/index.html
• Java API for XML Registries: http://java.sun.com/xml/jaxr/index.html

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...