With Microsoft's .NET marketing campaign in full swing, Sun announced its Sun ONE (Open Net Environment) initiative in October of 2001. While J2EE provides a robust, scalable, and portable enterprise platform, until then it had been sorely lacking in the area of standardized support for Web services. As a part of the Sun ONE initiative, Sun has since released the Java XML Pack, a suite of Java APIs for working with XML.

Java XML Pack Basics
So what exactly is the Java XML Pack? From a Web services perspective, the Java XML Pack facilitates the development, publishing, locating, and invocation of XML services via the Java 2 Platform.

The Java XML Pack provides a truly extensible and flexible interface for deploying enterprise-services architectures and is designed to provide a core set of standardized Java APIs for building, deploying, and accessing XML applications - and, specifically, dynamic XML-enabled Web services. The Java XML Pack APIs constitute a standard set of abstract APIs that aren't tied to a particular implementation technology. Thus, as is true with the rest of the Java 2 Platform, developers can code their application to an API, and easily adapt to changes in the industry without the need to rework or recompile their application code. Developers are free to use any JAXP-compliant XML parser, JAXB-compliant schema mechanism, JAXM-compliant messaging provider, JAXR-compliant registry service, or JAX-RPC-compliant invocation mechanism.

Additionally, although SOAP, WSDL, and UDDI are the current technologies du jour, the industry landscape may very well shift to other technologies such as XP (the W3C spec) and ebXML. When this happens, a Java XML Pack-compliant implementation can be plugged into an existing Java XML Packenabled architecture, and your applications will instantly leverage the new technologies to accomplish the same business services as before. Let's see your .NET technology do that!

Architecture Overview
The JAX Pack technologies can be divided into two broad categories: those that deal with an XML document holistically, and those that deal with it from a procedural perspective.

Document-centric

• Java API for XML Processing (JAXP) - processes XML documents using a JAXP-compliant XML parser
• Java Architecture for XML Binding (JAXB) - provides a mapping between XML document elements and Java classes, allowing XML documents to be treated as native Java objects

Procedure-centric

• Java API for XML Messaging (JAXM) - facilitates XML-based messaging via the Java programming language
• Java API for XML Registries (JAXR) - offers a uniform mechanism for accessing business registries through Java
• Java API for XML-based RPC (JAX-RPC) - facilitates XML-based RPC over the Internet, allowing XML-formatted parameters to be passed to remote services, and XML-formatted values returned

This combination of APIs capable of dealing with an XML document as a whole, and providing support for invoking procedures with XML, constitutes a powerful services framework for the Java platform.

Drilling Down
Now let's look at each of these five APIs in a little more detail:

1. JAXP - Processing XML
The Java API for XML Processing (JAXP) predates the rest of the Java XML Pack. It provides basic XML capabilities for the Java platform through a flexible, standards-based API. JAXP is namespace aware and provides support for parsing XML documents, as well as transforming them into other formats. From an architectural perspective, JAXP is designed from the ground up to provide optimum flexibility. It employs a pluggability layer allowing compliant XML parsers and XML processors to be substituted at runtime, as well as supporting multiple parsing paradigms.

When parsing an XML document, developers can use the JAXP API in conjunction with any JAXP-compliant parser to consume XML documents and extract the data inside them. Both SAX-based (event model) parsing, as well as DOM-based (tree model) parsing are supported. This allows developers to utilize whichever parsing paradigm best suits a particular application's requirements. The Simple API for XML (SAX) defines an event-based API that navigates element by element through an XML document, signaling events as particular XML constructs are identified. The Document Object Model (DOM) defines a set of interfaces for constructing an object representation of the parsed XML document, based on a tree data structure. With DOM, the entire document is parsed and the tree structure is stored in memory, allowing repeated, random access to the XML document data. With SAX, the XML data is only accessible when the parser reaches a given element; once it moves on to another element, knowledge of the previous element is lost. These differing parsing styles allow developers to select whichever method best meets the application's requirements. Should the application need to evolve and support a different style, such a change is streamlined via JAXP.

When transforming an XML document, developers can use the JAXP API in conjunction with any JAXP-compliant processor to consume the XML document and transform the data into the desired format (HTML, WML, XSL, or some other flavor of XML). Currently, the only transformation technology supported by JAXP is the eXtensible Stylesheet Language Transformations (XSLT). XSLT allows the definition of XSL stylesheets capable of transforming an XML document into any other textual format, markup language, or even foreign language, based upon template definitions.

The JAXP 1.2 reference implementation ships with two open-source components. The Crimson XML parser (which supports SAX and DOM) and the Xalan XSLT processor, both jointly developed by Sun and the Apache Software Foundation.

2. JAXB - XML Object Binding
The Java Architecture for XML Binding (JAXB) defines an XML-to-Java mapping architecture. It's a fast, efficient means of creating a two-way mapping between the elements in an XML document and Java classes. Given a DTD that defines the schema for the XML document, and a binding schema that defines how to bind the schema to classes, the JAXB compiler will generate a set of Java classes containing all the necessary code to parse XML documents based on the schema. These classes can be used to build a Java object tree representing an XML document that's valid for the schema. This object tree can be constructed by parsing an XML document, or by directly instantiating objects from the generated classes. JAXB can also be used to dynamically modify the element contents of the object tree, and it can marshal the object representation into an XML document based on the mapping defined within the binding schema. In this way, JAXB defines an architecture that provides a convenient, two-way mapping between Java and XML.

At first glance, it would appear that with the JAXB architecture there's no need for the JAXP API. Although there are some areas in which they overlap, they each have distinct features that make them more or less useful for certain tasks.

Table 1 summarizes the differences between the two technologies. For starters, JAXP provides a one-stop shop for parsing, processing, and transforming XML documents. You can select SAX for high-performance, one-time processing, or when you only want a portion of a very large document. You can select DOM when you need to maintain an in-memory representation of an XML document. The DOM API will even allow you to modify the structure and content of an object tree. JAXP also provides a transformer API to convert a document from one format to another. From a validation perspective, JAXP can use a previously known schema, or accept a new one dynamically at runtime. This validation paradigm, although a bit costly, is incredibly flexible.

JAXP provides all these features from the convenience of a single API. JAXB provides some similar features and some unique features. JAXB uses a custom parsing mechanism that builds an in-memory object representation like DOM, but is about as fast as SAX parsing. This is because the generated classes contain all the necessary DTD logic, whereas SAX parsers must accommodate a dynamic validation check against a schema. Additionally, the in-memory object tree created and maintained by a JAXB application has a considerably smaller footprint, because, unlike JAXP, it doesn't contain tree manipulation logic. Developers can certainly modify the object properties (which correspond to element values in XML), but JAXB doesn't facilitate the manipulation of the structure of the object tree (adding and removing elements). One additional aspect of JAXB is that a schema is required and only valid XML will be processed by the application. Whether this is a restriction or a feature depends entirely on your application's requirements.

JAXB provides a bridge between the language-neutral world of XML and the platform-neutral world of Java. In the same way that an XML document is an instance of aschema, a Java object is an instance of a class. As Sun's whitepaper, Web Services Made Easier explains it: "Thus, JAXB allows you to create Java objects at the same conceptual level as the XML data." Java developers are comfortable with object-based relationships, encapsulation, and the level of granularity that objects provide. JAXB provides a fast, convenient mechanism to access XML in this same manner.

3. JAXM - XML Messaging
The Java API for XML Messaging (JAXM), is a full-featured asynchronous messaging technology, representing a standard way to send messages across a network from the Java platform. It's decoupled from the underlying protocol(s) being used, affording developers a standardized messaging API that won't have to be changed to accommodate a different underlying protocol. JAXM is currently based on the SOAP 1.1 and SOAP with Attachments specifications, but it can be extended to work with higher level protocols such as ebXML or bizTalk, or any other protocol that the industry - or a particular business partner - chooses to embrace at a later time.

JAXM messaging requires the use of a messaging provider service, which handles the transportation, routing, marshalling and unmarshalling work that goes on under the hood. The JAXM API shields developers from such details, and provides a clean and simple interface for sending messages, receiving messages, or simply taking part in the processing of a portion of a message (serving as a message intermediate). The messaging provider can offer additional functionality, such as guaranteed messaging, event logging and auditing, message threading, and even security. All such activity is shielded from the sender, receiver, or any participant in a messaging exchange. All that's required is that the JAXM client make method calls against the API. This decoupling allows messaging providers to offer value-added features and allows application developers the freedom to select the provider that best meets their needs. It may be helpful to think of JAXM in the messaging space as being equivalent to what JDBC provides in the database access space. In this analogy, a messaging provider serves a similar purpose as a JDBC driver. Developers write their application code to the API, and vendors develop software components that provide concrete implementations of the API. The primary difference here is that, while JDBC requires that you use a driver that is compatible with the database being used, the messages sent from a JAXM messaging provider conform to industry standards, and can be consumed by any recipient that understands those standards. The JAXM reference implementation uses SOAP 1.1, thus any SOAP-enabled recipient would be able to unmarshal a message sent from it

JAXM is a robust messaging technology supporting a wide-variety of messaging paradigms, including point-to-point messaging, publish-subscribe messaging, intermediate point-to-point, request-response, and even a process-workflow messaging model. (That's not a comprehensive list by any means.) Which specific messaging paradigms are available is entirely dependent on the messaging provider used, but JAXM provides a standard means of defining how a message should be sent and what auxiliary information may need to be passed in order to process the message properly.

In many ways, JAXM is very similar to the Java Messaging Service (JMS). They both provide an abstract messaging API that's decoupled from the back end implementation, and they both require a messaging provider to implement the API. In fact, the current JMS-compliant messaging providers are likely to be the first vendors to incorporate support for JAXM into their tools. The difference, then, between JAXM and JMS, is that JMS ultimately produces a Java-centric message. Whereas JAXM messages comply with industry-standard formats such as SOAP and ebXML.

4. JAXR - Registering/Locating XML Services
The Java API for XML Registries (JAXR) provides a registry independent API for accessing XML-based registries. A registry is very much like the yellow pages, or the listings maintained by a search engine. It provides a convenient means to browse available services, gather information regarding those services and then select the desired service. Like search engines, registries support the ability to return a list of search results based upon specified criteria. Like the yellow pages, registries categorize their contents and allow clients to browse by category. In addition to providing the ability to search such registries and retrieve details about available XML services, JAXR enables developers to publish new services to the registry and even to manage the registry data itself (assuming that proper authentication is provided first).

Although the majority of the literature talking about service registries discuss as the concept of global public registries like Xmethods.com, UDDI.org, and the registries of IBM, Microsoft, and HP a far more immediate use for service registries can be found in intranet and extranet registries. It's unlikely, any time in the near future, that consumers will query public registries trying to find the best deal on their auto insurance, or that businesses will start browsing public registries looking for a service to fill a mission critical need. A much more likely scenario is that businesses may set up private registries to serve as a single point of reference for their various enterprise services. Rather than an application developer combing through outdated documentation, or waiting for a response to a request they sent to management regarding a particular service they need to access, they can simply browse the company's internal registry looking for the service. If they can't find one, the developer can be reasonably sure that one doesn't exist. This tremendously increases the productivity of that developer and of everyone else that might have occasion to locate and/or access the available enterprise services. A similar need can be met with registries in a B2B extranet scenario. A business can expose a private registry to its business partners, providing them with a comprehensive, standards-based mechanism for searching, locating, inquiring about, and binding to whatever services the business has made available. The business could even allow the partner to register new services that would now become available for the business to access.

There are currently two primary specifications for XML registries:

• The ebXML Registry and Repository standard being jointly developed by OASIS and the UN
• The Universal Description, Discovery, and Integration (UDDI) specification being developed by a consortium of over 100 companies.

As is the case with the other Java XML Pack technologies, JAXR represents a flexible mechanism that's not tied to any particular implementation. Thus the same application code can be used for accessing first a UDDI registry, then an ebXML registry. The JAXR 1.0 Early Access Reference Implementation supports both the ebXML registry and the UDDI Registry v2.0 specification. Sun intends to incorporate support for ebXML as that standard is finalized.

5. JAX-RPC - XML-based RPC
The Java API for XML-based RPC (JAX-RPC) gives Java developers a simple, convenient mechanism for invoking remote procedures in a neutral, standards-based way. JAX-RPC is a synchronous, pure Java, RPC-invocation mechanism that leverages standard XML protocols such as SOAP. It's pure Java in that it doesn't require the existence of an XML schema or a messaging provider in order to make a remote call.

JAX-RPC provides a simple, object-oriented mechanism for specifying the service location, parameter types and values for a service. As with other RPC mechanisms, a JAX-RPC client simply creates a local object, propagates it with the necessary information, then invokes methods directly on the local object. When the call is made, JAX-RPC marshals the call across the network (as a SOAP message), and unmarshals the response (converts the SOAP response to a Java object). The details of the mapping and reverse mapping of data types and other XML element constructs are abstracted away from the JAX-RPC application developer. Thus, it provides a simple, straightforward mechanism for accessing RPC-style Web services from the Java platform.

As with any RPC mechanism, an interface for the remote procedure needs to be generated, along with stubs and ties. The JAX-RPC reference implementation accordingly ships with a stub and tie generation tool, xrpcc. Given an appropriate interface, the xrpcc tool generates stubs, ties, and a server configuration file. The tool supports both standard Java RMI interfaces and WSDL documents. In addition to generating the appropriate files to set up the RPC-runtime, the tool can also convert a set of Java RMI interfaces into a WSDL document and vice versa.

Like JAXM, JAX-RPC is a tremendous client technology for accessing Web services. Not only does it leverage Java's platform independency, allowing the client to be run on any Java 2 platform, but the ac-cess mechanism used by JAX-RPC is SOAP, an inherently language and plat-form neutral communication protocol. This provides the optimum in RPC-flexibility and portability.

Conclusion
The Java APIs and architectures for XML provide a comprehensive suite of XML APIs for the Java platform. JAXP allows developers a flexible means to parse, process and transform XML documents; JAXB defines a two-way mapping architecture between XML and Java; JAXM is a robust asynchronous messaging technology; JAXR provides standardized access to XML registries, and JAX-RPC enables RPC-style invocation of XML Web services.

Just as JDBC has become an expected acronym to see on a Java developer's resumé, the JAX technologies are sure to become a required part of any Web or enterprise developer's toolkit.

Exploring Further
You can download the pack from Sun's Web site at http://java.sun.com/xml/javaxmlpack.html and take it for a spin. Sun recently released the Java XML Pack as a part of the Java Web Services Developer Pack (Java WSDP) which is available for download at http://java.sun.com/webservices/webservicespack.html A tutorial for the WSDP is available at http://java.sun.com/webservices/docs/ea1/tutorial/index.html

Author Bio
Kyle Gabhart, director of the Java division of Objective Solutions (www.objectsoln.com), is a prolific writer with more than a dozen technical articles and books to his name. Objective Solutions is a leading provider of Java and Web services mentoring and training. java@objectsoln.com.