ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button

Web Services Messaging with Apache Axis2: Concepts and Techniques
Pages: 1, 2, 3, 4

Synchronous/Asynchronous Behavior of the Client API

Synchronous/asynchronous (or blocking/nonblocking) behavior is based on the thread that handles the web service invocation. A synchronous service will block, and wait for related messages to arrive. On the other hand, an asynchronous invocation will just return, and waiting for related messages will be done by a different thread that runs in the background.



Both approaches have strong use cases. Consider a bank transaction that needs a number of messages to fly back and forth: the bank transaction is sequential by nature, as results are required to arrive before execution goes to the next step, so synchronously waiting for the results make sense. On the other hand, consider a flight reservation program that needs to collect data from many sources, and match based on the results. In this case, the asynchronous approach would work, since the program can submit all of the requests and work on the data as they arrive. Considering network latency, the asynchronous approach would yield much better results.

The synchronous invocations are simple: the invocations wait for the related messages to arrive, and can be coded like any local procedure call. But the correlation of the asynchronous messages is complex, and the client has to work to handle the complexities. Still, there are cases where doing extra work to handle the complexity can be justified.

Behavior of the Transport Layer

The behavior of the transport layer is a critical factor that decides how web service messaging takes place. Transports are categorized as one-way or two-way, according to their behavior.

One-way transports reduce the complexity of web service messaging, as the related message must come from a separate channel. On the other hand, if the transport is two-way, messaging has a choice of using transport as one-way or two way. For an example, when the transport is HTTP, the related message may come from the return path of the HTTP connection, or the web service provider might write HTTP 200 to indicate that there is no response coming on the same connection, in which case the response is sent over a separate HTTP connection.

The Role of Web Service Addressing

Web service addressing (also called WS-addressing) lays the framework for the information exchange between different parties that takes place in a web service interaction. The following five parameters define an interaction.

  1. Message exchange pattern
  2. Transport with which the service can be accessed
  3. Transport used by the related messages
  4. Behavior of the transport
  5. Synchronous/asynchronous behavior of the client API

The service provider declares the first two, and the client is free to define the other parameters. The client-level synchronous/asynchronous behavior is completely transparent to the service provider, and the client uses WS-addressing to explain the web service messaging.

Among many other constructs, WS-addressing defines four headers: To, ReplyTo, RelatesTo, FaultTo, and a special address that is called the Anonymous address. When a service provider receives a SOAP message, it finds the target service based on the To address and invokes the service. The results, if there are any, are sent to the ReplyTo address, and any error is sent to the FaultTo address. If any of the above headers are not specified or have the value Anonymous, the result is sent via the return path of a two-way transport (since Anonymous always resolves to the return path of a two-way transport).

Transports, together with WS-addressing, define a mechanism to find interrelated messages. Messages are related either because they share the same transport channel, or because they all share common information that links them to each other. The RelateTo header of the web service addressing provides precisely this relationship.

The following table shows different values of the addressing headers for a few well-defined message interactions.

MEP Sync/Async Transport Behavior Message To ReplyTo RelatesTo
In-Only NA One-way IN Optional Optional NA
In-Out Sync One IN Optional Anonymous NA
OUT Anonymous Optional IN-Message
In-Out Async One IN Optional Anonymous NA
OUT Anonymous Optional IN-Message
In-Out Async two IN Required Required NA
OUT Required Optional IN-Message

Pages: 1, 2, 3, 4

Next Pagearrow