JAXM Architecture

We have looked at some messaging options in Java, such as JMS and JavaMail, and how they can be leveraged to send SOAP messages. Let us now look at JAXM, its architecture, and how it can be used for XML messaging.


Conceptually, JAXM is based around the notion of providers, which is analogous to MOM. As Screenshot shows, a provider is a simplified message broker that sits in the middle of the two messaging points. A provider supplies the services necessary for persisting and forwarding messages, reliability, routing, and additional infrastructure-related features to improve quality of service, such as scalability, availability, and security. The chief requirement for a JAXM provider is that it must support HTTP and SOAP with Attachments.

Java Click To expand
Screenshot: Conceptual model for JAXM

The concept of the provider has its roots in JMS. Like JMS, JAXM sits on top of a provider implementation. Screenshot shows the architectural stack for JAXM and the provider's relative position in it. The provider plays a proxying role, in the sense that when the app uses a provider, all messages go via the provider. When a JAXM app sends a message, it actually sends it to the provider, which then handles transmission to the final destination(s). Similarly, when a JAXM consumer receives a message, the underlying provider has actually received the message and then forwarded it to the app code. A provider will typically use the services of a J2EE container, because the container requires

Java Click To expand
Screenshot: Architectural stack for JAXM

Conceptually, a JAXM provider sits somewhere between an email server and a MOM broker. However all of the discussion about MOMs in this chapter so far is valid for JAXM providers (e.g., topologies) as well.


Earlier in the chapter, we talked about MOMs and how the JMS API provides a standard Java-based interface to the messaging services of a MOM or a messaging broker. The JAXM API takes on the task of providing a standard Java interface for apps to use the services of a provider capable of XML messaging with SOAP. The API itself is divided into two parts:

  1. javax.xml.soap. Implementation of the SAAJ specification. Initially, this was a part of the JAXM specification, but because of reuse across other APIs, such as JAX-RPC, it was moved to an independent specification. SAAJ deals with creating, manipulating, sending, and receiving SOAP messages (without a provider).

  2. javax.xml.messaging: Defines the core of the JAXM specification and the interactions with the messaging provider.

    Subsequent sections of this chapter cover the API in further detail.


Like JMS, JAXM API provides only the lightweight mechanism for connecting and communicating with a provider and requires nothing of the message content except that it must meet the SOAP standard. Real-world business apps, however, often need to control and agree on what kind of information and in what structure it is being passed. The SOAP 1.1 and SOAP with Attachments standards provide a basic packaging model. All they require is that a message sent from point A to point B be composed of an outer envelope that can contain a header and a body. This falls short on many fronts. For example, to successfully implement XML messaging, parties to the communication must be capable of performing tasks such as the following:

Java Start Sidebar

JAXM requires support for SOAP 1.1 with Attachments. The attachments are important, because choreographed messaging with compound messages (i.e., SOAP messages with a body and one more attachments that contain the message content) dictates slightly different semantics than traditional request-response-based SOAP communication.

Java End Sidebar

JAXM does not describe the semantics that address the above requirements and govern the SOAP/XML message exchange protocol. They are described by the common XML protocol defined by a profile and XML schemas associated with that profile. The profile layer in Screenshot refers to the implementation of a specific message-exchange protocol based on SOAP 1.1 with Attachments. A profile is really an industry standard, such as the ebXML Message Handling Service defined by OASIS or the W3C's XMLP. The latter defines well-established rules for message processing and represents a higher level of abstraction on top of SOAP that governs how business partners can leverage XML messaging. By layering a profile on JAXM, the app uses the profile-specific API and not JAXM directly. So, for example, an ebXML profile from a vendor may use a specialized subclass com.myprovider.EbxmlMessage object instead of the javax.xmk.soap.SOAPMessage object.

Java Click To expand
Screenshot: SOAP message structure with a profile

A profile may not even be built on top of JAXM and may be supplied by a vendor directly. In either case, the output on the wire is the same SOAP message, conforming to the ebXML Message Service Specification. Profiles are closely tied to SOAP headers. In fact, a profile can be thought of as a specific usage of a SOAP header, because the headers contain most of the profile-specific information. The payload or business content of the message would remain the same, no matter what message exchange protocol was used. In short, the profile and the schemas associated with that profile describe the set of rules and procedures all parties must understand and agree upon for effective XML messaging.

Java Start Sidebar

ebXML The ebXML initiative by UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) and OASIS (Organization for the Advancement of Structured Information Standards) is a set of specifications for message formatting, business processes, and registry services, among others. ebXML concepts were covered in . ebXML Messaging In ebXML, an entire message is called a message package. A message package has one header container and zero or more payload containers. Most of the messaging-specific XML elements reside in the header container and describe the messaging routing, operations performed, the unique identifier for the message, and so on. The payload containers hold the message content, which can be anything from XML documents, such as purchase orders and invoices, to scanned x-ray images. Some ebXML SOAP Headers

Java End Sidebar