Asynchronous Web services programming

The development of Web services depends on several protocols. SOAP over HTTP is the messaging protocol predominantly used at the present time, and synchronous RPC is the predominant messaging pattern. This article presents core mechanisms for performing asynchronous messaging using current Web services technologies.

SOAP over HTTP
The SOAP protocol fills the role of the messaging protocol for Web services, defining both the serialized representation of objects passed between servers or SOAP nodes and the behavior patterns expected from each node in processing and forwarding messages. Although both of these aspects are important in order to achieve interoperability between Web service endpoints that are implemented based on different underlying technologies, the primary focus of current development has been on SOAP message serialization and deserialization. This has been a necessary first step, which involves language mappings for XML Schema constructs, as well as for the constructs defined in the SOAP specification itself (SOAP encoding and SOAP-RPC).

The behavior patterns of nodes participating in messaging are specified by the SOAP messaging framework, which forms an abstract basis for communication within a distributed application. This framework focuses on the behavior expected of a single node along a message path, and, in doing so, bases the behavioral rules on a one-way message. The rules fall into two primary categories:

1. How to determine the responsibility the node has in processing message parts
2. The proper behavior in case of error conditions

The SOAP message is transferred between servers using an extension to the framework, referred to as a transport binding; the only one currently specified is the HTTP binding. Therefore, although the SOAP messaging framework is based on a one-way messaging model, in the context of the HTTP binding, the combined protocol inherits the request-response semantics of the underlying HTTP transaction, making it an inherently synchronous two-way protocol. Because the two-way nature is a property of the HTTP binding, rules concerning the proper behavior of a node within the request-response messaging pattern can only be defined within this extension.

One of the most common examples of the use of the synchronous RPC communication model in SOAP over HTTP is that of the stock quote. The request contains the ticker symbol, and the response is the current stock price. An example of how such a request message might appear is presented in Listing A.

Listing B shows how the corresponding response may appear.

Asynchronous distributed applications
In general, any application participating in a Web service interaction is playing a role in a distributed application. As such, it will benefit if it’s designed to run asynchronously from other components in the distributed system. The client will tend to gain performance, the server will be more easily scalable, and the overall application will obtain improved reliability. Within the arena of Web services, where the underlying messaging protocol is SOAP, you can most directly approach the process of application development (in which current technologies are applied to their fullest, whereas emerging technologies will be easily adapted) by designing applications that can operate asynchronously now and then adapting the applications to new underlying mechanisms as they become available.
This approach is not new for Web services. Consider the use of the session id, for example, within a Web application based on JSP. The session id provides a mechanism by which you can associate a new transaction with a previous one, allowing the use of an information set from a previous transaction (or sequence of transactions) with the Web application server. The value of the session id is realized within the Web application by the client and server components’ being part of the same overall application. The client components in these cases are most often user interfaces intended for human interaction with the application. Within a Web service, on the other hand, the client component will typically be another computer system, which may also expose its functionality via a human interface (as a Web application) or another machine interface (as a Web service).
You can thus view a Web services network as a distributed system; it is possible that each server machine in the network and each application is developed and operated independently of the others. Asynchronous communication will most likely be not only valuable but also necessary for the longer-term development of Web services intended to play a part in larger communication patterns than simple request-response. The challenge presented by the current state of protocol definition and toolkit implementation is that true asynchronous messaging is not yet cleanly exposed. Some toolkits are making up for this lack by providing asynchronous access to synchronous messaging, in which a single synchronous operation is exposed for access via begin and end methods. This is an important tool to use in preparation for full asynchronous messaging; it forces the internal application logic to deal with the asynchronous communication issues.
A closer approximation of asynchronous communication, which may even be achieved in the current HTTP binding to SOAP 1.1, is to split the request and response segments of the HTTP transaction so they’re in different HTTP transactions. This, too, is not a new technique, having a parallel to sessions within Web applications, but where the session extends across only two HTTP transactions. In addition, some Web service network providers, such as Grand Central Communications, already provide such a mechanism.
If a session-type mechanism is adopted under the current technologies, you should carefully consider the choice of where the session id is generated. This caution is due to the current direction of the SOAP specification process. In the HTTP binding in SOAP 1.2, a more extensive use of HTTP status codes indicates messaging expectations—especially 202, which indicates that a response may not be included in the HTTP response, and 204, which indicates that the HTTP response will be empty. These new definitions will make it possible to have truly one-way messaging under the HTTP binding, which will induce asynchronous communication whenever they are used in combination with request-response message patterns (the receiving node has no pathway in which to pass a session id back to the client within the same HTTP transaction).
In addition to the HTTP binding, the SOAP 1.2 specification provides a more complete binding framework, meant to guide the defining of other transport bindings to SOAP. One of the most likely candidates is SMTP, which, if implemented, presents no inherent pathway for application data to be passed in the response. If a session id mechanism is used under the current SOAP 1.1 protocol, the session id must be generated by either the client or the server. If the server generates the session id and sends it to the client in the HTTP response, asynchronous messaging in the SOAP 1.2 protocol would have to rely on the full request-response semantic of the HTTP transaction without the ability to perform pure asynchronous communication, as would likely be imposed by an SMTP binding.
To extend the previous example of a stock quote query, the asynchronous messaging model is appropriate for trade orders, themselves. For example, if a limit order is placed with a 30-day expiration, it is not practical to expect the final transaction response to arrive in the same HTTP connection. Rather, a mechanism must be available to allow for subsequent action related to the same initial message. The initial order may be appear like the request and response messages in Listing C and Listing D.
At some future time, the results of the order may be retrieved, as shown in Listing E and Listing F.

Conclusion
Simple mechanisms that support asynchronous communication patterns can be constructed using current technologies available for Web services development. These mechanisms are nearly identical to those already used for Web applications, as demonstrated in the simple examples presented in this article.
It is important to note in the examples that the basic correlation mechanism (Confirmation in the listings) must, at present, be managed by application logic. One of the primary issues to be resolved in the ongoing effort of defining the protocol standards for communication between Web services will be that of standardized session maintenance mechanisms in the SOAP protocol. The importance of such mechanisms is easily seen in the arena of Web applications, with the prolific reliance on HTTP cookies for session maintenance. For the SOAP specification, this issue may be more complex, especially in the case of a pure one-way message exchange pattern, as would be the case with a binding to SMTP. As you can see from the example, the correlation mechanism would have difficulties functioning under such a protocol binding, because the service would have no synchronous response pathway by which to return the correlation identifier.
By using some of the techniques presented in this article, you can make your Web service applications implement logic needed for an asynchronous communication model, and ease your future migration pathway to standards-based asynchronous messaging constructs when they become available.