- Why JAXM?
- What's In a SOAP Message?
- Synchronous and Asynchronous Messaging
- Are Message Providers Necessary?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Synchronous and Asynchronous Messaging
In addition to providing support for structuring SOAP messages, JAXM also plays an important role in specifying the messaging behavior of transmissions. Because JAXM sits between an asynchronous Web and a tightly coupled synchronous server environment, it must be able to handle both synchronous and asynchronous messaging. Asynchronous messaging is that in which a client sends a message and does not wait for a reply. Synchronous messaging, on the other hand, involves sending a message and waiting for a reply before proceeding.
JAXM Connections
Central to the way JAXM handles messaging is the concept of connections. If you are familiar with the JDBC API for database connectivity, you'll recognize a familiar pattern of communication build around a connection abstraction. In JAXM, all messages are sent and received over a connection class. A connection can be established with a particular destination in mind or routed to a messaging provider that adds routing and reliability guarantees to the transmission.
In practice, JAXM supports two connection types:
SOAPConnection: A connection from the sender directly to the receiver (a point-to-point connection)
ProviderConnection: A connection to a messaging provider that serves as a proxy for message senders and receivers.
Let's take a look at each.
SOAPConnection
The SOAPConnection class represents a simple point-to-point connection between sender and receiver. Like many other Java APIs, JAXM uses a factory class to instantiate suitable connection objects. As illustrated in the following code, a JAXM ConnectionFactory is used to return a new SOAPConnection object that is responsible for sending a SOAP message. We also need a MessageFactory to give us a SOAPMessage that we can populate and send over the SOAPConnection. Once that is done, the SOAP message is sent by passing it as a parameter to the call method.
// create a SOAP connection between sender and receiver
SOAPConnectionFactory factory = SOAPConnectionFactory.newInstance();
SOAPConnection mySOAPConnection = factory.createConnection();
// create a messageFactory so we can create SOAP messages (empty)
MessageFactory messageFactory = MessageFactory.newInstance();
// ask the messageFactory to create an empty SOAP message
SOAPMessage msg = messageFactory.createMessage();
// add content to a SOAPMessage – options include adding data to
// the SOAPHeader, the SOAPBody or SOAP AttachmentPart
......
// ask the Connection to make the call and await a respone
SOAPMessage response = mySOAPConnection.call(msg, endpoint);
When using a SOAPConnection object, the caller waits for a response message as a return value. This type of messaging, referred to as request-response, is used for synchronous messaging over SOAP. However, it's also possible to communicate asynchronously using JAXM. For this though, we need a ProviderConnection.
ProviderConnection
A ProviderConnection object represents a connection to a messaging provider. When a message is sent via a ProviderConnection object, the messaging provider forwards the message until the message arrives at its ultimate destination. However, for the sender, the method call returns immediately, without blocking until it gets a response. It's the job of the messaging provider that receives the message to forward it to the intended destination, and return any responses at a later time. How long response notification takes is open-ended: It may be seconds or several days. With this style of asynchronous messaging, the original message and any replies are delivered as one-way messages.
Profiles
Although JAXM supports both regular SOAP and SOAP with attachments, it's also possible to build more complex sets of interactions on top of SOAP. JAXM supports this through the use of profiles—SOAP header information that may be used to coordinate more complex SOAP-based interactions. Currently, there are profiles available for doing SOAP-based remote procedure calls; and for ebXML routing, transport, and packaging. This is where JAXM utilizes the factory pattern because, depending on the profile, a new SOAPMessage object will be delivered from the factory with profile-specific headers already set.
SOAP Actors and Intermediate Destinations
The SOAP specification also specifies rules for handling SOAP messages by SOAP intermediaries along a path to a final destination. This opens up options for using SOAP in pipe and filter architectures in which information flows along a path and is processed along the way before reaching a final destination. SOAP uses the term actor to describe the role of a SOAP handler, and uses a message's SOAPHeader to specify actor roles. Technically, the SOAP specification defines an actor attribute that is used in a SOAPHeader to indicate that the recipient is intended as an intermediate SOAP node.
For example, as a SOAP-packaged purchase order works its way though an organization, it might be routed to an order confirmation desk, a shipping desk, and the billing department. Each of these destinations can be configured as actors that take some application-specific action, remove the header information relevant to it, and then send the message on to the next actor. SOAP uses the term default actor to indicate the final destination. This means that if no actors are specified, the message is routed to the final recipient.
Related to actors and intermediaries, SOAP also includes a mustUnderstand attribute, which may also occur in a header. When the mustUnderstand attribute is true, an actor must understand what is expected of it and carry out its task successfully or return a SOAPException. Within JAXM, a SOAPHeader object uses the method addAttribute to add these attributes, whereas the SOAPHeaderElement interface includes methods for setting and getting the values of these attributes.