The asynchronous messaging and reliable delivery features of JAXM are implemented by a messaging provider. The specification itself says very little about the provider, other than to describe the API needed to access it, leaving the details to be determined by
When a message provider is in use, the logical flow of a message is still directly from the sender to the receiver, but the actual flow is somewhat different, as shown in Figure 4-4.
In order to send messages, the sender first connects to the local provider and determines whether it supports the messaging profile that it wants to use; if so, it obtains a
for that profile. Each message is then handled as
The sender creates a SOAP message using the SAAJ API with the MessageFactory for the selected messaging profile.
The message is sent to the local provider. This operation returns control to the caller as soon as the provider receives the message, and the sender is free to continue with other processing.
The provider stores the message in its outgoing queue.
A separate thread handles queued messages, dispatching each of them in
The remote provider (eventually) receives the message and stores it in its dispatching queue.
If the message receiver is active, the message is delivered to it. Otherwise, it is held in the dispatching queue until it can be delivered, or until the
The receiver processes the message.
It is important to note that the message flow is entirely asynchronous to the sender: once the message is delivered to the local provider, its eventual transmission is scheduled separately (and, in the reference implementation, in a separate thread). Similarly, when the message is received by the remote provider, it is simply written to a queue and dispatched at a later time to the intended recipient. The asynchronous nature of the message flow and the fact that it involves intermediaries is in sharp contrast to the direct connection used by SAAJ applications. The message flow is
You will notice that the diagrams in this chapter use the terms "sender" and "receiver" instead of "client" and "service," since we are focusing on the messaging aspects rather than on the roles of the sender and receiver in the web service. It is important to keep these separate. Although the client is the sender and the service is the receiver when the service is first invoked, the roles are
The arrangement shown in Figure 4-4 is fine when both the sender and the receiver are implemented using JAXM, but this is not the most general case. In the real world, one party may not be associated with a messaging provider, an obvious example of which is a JAXM client accessing a web service running on the Microsoft .NET platform or vice versa. As far as the client or service implementation is
In Chapter 3, you saw an example SAAJ application in which the service was implemented as a servlet in the Tomcat web container and the client was a freestanding Java application. Both JAX-RPC and SAAJ allow the client either to be an application or to reside in a container. However, all JAXM applications (including the part you would naturally think of as the "client") must be hosted in a web container or an EJB container. At the time of this writing, the JAXM reference implementation supports only deployment of JAXM applications as servlets within a web container, so the examples used in this chapter are all hosted by servlets. In the future, it is expected that JAXM will also be supported by EJB containers in the form of Message Driven Beans.
The API provided by JAXM resides in the javax.xml.messaging package. In order to compile a JAXM client, you need to have the JAR files jaxm-api.jar and jaxm-runtime.jar on your CLASSPATH , together with saaj-api.jar for access to the javax.xml.soap package. At runtime, you additionally need access to all of the JAR files listed in Table 3-1. Inclusion of these JAR files is usually automatic, however, since the client is actually deployed in a web container in which JAXM and SAAJ should already have been installed.
The messaging provider that is provided with the JAXM reference implementation is implemented as a servlet that resides at the URL http://localhost:8081/jaxm-provider in the default deployment. There is also a web application at the URL http://localhost:8081/jaxm-provideradmin that can be used to configure the provider. Further information on the provider and its configuration are found later in this chapter.