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.

Providers

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.

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

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

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

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

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.

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.

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

• To and From. URIs that identify the sender and receiver.

• CPAId. Based on the Collaboration Protocol Profile and Collaboration Protocol Agreement specifications, the messaging parties agree on the interaction semantics. This results in an XML document describing the business process and messaging interaction. The CPAId header refers to an ID defined according to this agreement.
• ConversationId. Uniquely identifies a set of related message exchanges that constitute a conversation between messaging parties.
• Service. Denotes the service that processes the message at the destination(the To element).
• Action. Specifies the action the receiving service should take on the message.
• MessageId. Uniquely identifies the message.
• Timestamp. Specifies the time the message was created.