Hangin' with the JAX Pack, Part 2: JAXM

by Al Saganich
11/28/2001

This is the second of a three-part series on the "JAX Pack," Sun's Java APIs for XML. In the first article, I introduced the Java API for XML Processessing (JAXP) and the Java API for XML Binding (JAXB). These two mechanisms provide the underlying framework to access XML data and encapsulate that XML data within Java objects. Let's move on and examine the Java API for XML Messaging (JAXM) and see how it provides underlying support for accessing various messaging formats.

JAXM

JAXM (JSR67) is currently at version 0.93 (public review) with early access reference implementation version 2. JAXM is expected to be an optional part of J2SE and a standard part of J2EE.

JAXP and JAXB help us access XML data, but how does XML actually get between two cooperating applications? JAXM provides a specialized API for just this purpose. Effectively, JAXM is a specification for a Service Provicer Interface (SPI) to access standard XML messaging protocols, such as SOAP. JAXM allows for the transfer of complete business-level documents between two separate Web services. What JAXM does not do is attempt to define messaging standards of the so-called vertical markets; instead, it allows direct access to the various fields without regard to payload type. JAXM looks to provide an infrastructure for supporting whatever standard emerges, whether it be SOAP, ebXML or something else.

As I discussed in my article on Java and Web services, Simple Object Access Protocol (SOAP) actually describes the underlying format of messages transfered between applications. It's a reasonable enough task to write a SOAP- based servlet that uses JAXP to access the various parts of a message and work with it. This begs the question, why do we need JAXM at all? The problem with what I've proposed is the level of complexity and understanding that a developer requires to actually process and manipulate a SOAP message.

As much as I hate to admit it, I programmed long ago using raw Unix socket calls. At first it was really cool, but as we developed FTP and SMTP clients, the coding became tedious and error-prone. We went through a similar growth period as people developed the first Web sites. We are now seeing those same issues with Web services. JAXM is designed to be a lightweight API that abstracts away the underlying messaging infrastructure. In theory, we should be able to develop JAXMServlets, extending HttpServlets, which allow us to access SOAP (or whatever protocol follows SOAP) messages quickly and easily. Figure 1 below shows just such a conceptual picture.

Figure 1. SOAP- and JAXM-Based applications.

Before we move on, a word of caution. JAXM is in reality a fairly low-level or SPI-level interface. Effectively, JAXM is an optional J2EE package supporting the sending and receiving of XML messages using a pure Java API. JAXM allows developers to focus on the processing aspects of their applications rather than on issues associated with composing and decomposing XML messages using SOAP, ebXML, or something else.

JAXM version 1.0 is targeted at providing support for:

• Industry-standard message envelope, header, and routing information as found in SOAP today.
• Support for reliable message delivery.
• Support for a variety of message types and payloads (for example, SOAP with attachments).
• Support for security, including messasge integrity, authentication and non-repudiation of messages and audit trails.

JAXM applications fall into two major catagories: synchronous and asynchronous, each taking advantage of various capabilities, as shown above. JAXM, in fact, supports five major catagories of client-client interactions.

Asynchronous

A client sends a message that must be processed, to which a reply must ultimately be generated. The reply could take days to generate; the client is free to do other things while waiting for reply.

Asynchronous with acknowledgement

A client sends a message that must be acknowledged with a specific message. The acknowledgement format and correlation between messages is not specified by JAXM. The client is free to do other things while awaiting the "ack."

Synchronous

A client sends a message and waits for a reply. The reply is informational only, and not required. The client does nothing else while waiting.

Synchronous with acknowledgement

A client sends a message and waits for the acknowledgement.

Fire and forget

A client sends a message and goes on. No "ack" or response expected.

A fair amount of SOAP knowledge is implied in processing a SOAP message. Developers with absolutely no SOAP knowledge are advised to poke around in the SOAP areas of W3C. For those who simply need a SOAP refresher, Figure 2 shows the JAXM SOAP packaging conceptual model.

Figure 2. JAXM SOAP Packaging conceptual model.

JAXM is, for the most part, concentrated on accessing the various parts of a SOAP 1.1 packet today, although provisions exist for other messaging styles. JAXM base applications come in one of two flavors: message consumers or message producers. Rather than go into any more detail, lets look at a JAXM message consumer example.

Pages: 1, 2, 3, 4

Next Page