Providers

Conceptually, JAXM is based around the notion of providers, which is analogous to MOM. As Figure 11.18 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.

The concept of the provider has its roots in JMS. Like JMS, JAXM sits on top of a provider implementation. Figure 11.19 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 application uses a provider, all messages go via the provider. When a JAXM application 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 application code. A provider will typically use the services of a J2EE container, because the container requires

• An interface to interact with the outside world. This is provided by servlets or message-driven EJBs.

• A mechanism to be administered by the environment. This involves setting up administered objects in JNDI, factories, and so on (just like the JMS-administered objects).

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.

JAXM API

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 applications 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.

Profiles

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 applications, 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:

• Addressing. Parties must agree on a standard addressing scheme and provide a mechanism to correlate a request to a response-that is, the "from-to correlation."

• Content processing. Parties must know what the message is in the context of their business. For example, a purchase order must conform to particular set of rules, and both parties must understand the schema for the document.

• Header processing. Both parties must be able of examining the SOAP header fields of incoming messages to process some metacontent and metadata about the message.

• Security checks and encryption/decryption. Parties should be able to examine the message to determine that the message is from an authenticated sender who is authorized to perform the task and that the data in the message is securely encrypted.

• Error and exception handling. Parties must be able to ensure that senders receive appropriate faults when the incoming messages does not contain sufficient or accurate information.

• Routing. Parties must be able to route the message, meaning they must be capable of handling the branching logic that determines the intended recipients of the message and deliver the message in the order it was intended to be delivered to those recipients.

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 Figure 11.20 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 application 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.

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.