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.
- Message exchange pattern
- Transport with which the service can be accessed
- Transport used by the related messages
- Behavior of the transport
- 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 |
