asynchronous operations and Web services, part 2nd: Programming Patterns for building asynchronous Web services

In the first article in this series, I discussed the nature of asynchronous operations and how they apply to WEB services. In some cases, the response to a WEB service request is not provided immediately, but at some point after the initial request transaction completes. WEB Service specifications and standards do not explicitly support this asynchronous operation (asynchronous operation), but those standards do contain the infrastructure and mechanisms that can be used as the basis for asynchronous operations. With the first part of this series, you should already know how to use an existing infrastructure to support asynchronous behavior, and if you haven't read that article, I strongly recommend that you take a look, because the information there will help you understand this part of the present.

In this article, I'll discuss several design patterns for asynchronous WEB services. These patterns will help developers of client and service provider applications to design their code to support asynchronous behavior, taking into account the complexity of the code, the use of a given transmission, and the need for explicit acknowledgement. You might also be interested in looking at another package that supports asynchronous behavior in WEB services.

WEB Services Asynchronous mode and basic transport type

As defined in version 1.1 of the Web Service Description Language (Services Description LANGUAGE,WSDL) specification, the four patterns discussed here that support asynchronous WEB service operations are based on four basic transport types that the endpoint can support:

One-way (one-way): The endpoint receives a message.

Request/Response (Request/response): The endpoint receives a message and sends a corresponding message.

Solicit/Response (Solicit/response): The endpoint sends a message and receives a corresponding message.

Notification (Notification): The endpoint sends a message.

IBM's Web service invocation framework and asynchronous operations

The Web Services invocation framework (Web service invocation framework,wsif) provides the ability to use different transports based on the calling context for the client API that is used to invoke the Web service asynchronously using a local proxy (for example, a stub). Many of the patterns discussed in this article can be supported by the WSIF component, which allows for the true support of asynchronous WEB service operations.

We should note that the number of basic transport types discussed in this article is completely unrelated to the number of patterns.

Each pattern introduces a correlator (Correlator) that is exchanged between the client and the service provider to associate the response with the request. The correlator can be provided by either end that participates in the exchange, and its creator can be determined based on the underlying transmission. For example, when using HTTPR and JMS, the message source provides the Correlator: a transaction identifier or a combination of Jmsmessageid and Jmscorrelationid.

For a single direction operation, if you are using HTTP or HTTPS, and the reception of the service invocation needs to be confirmed by the client, the client's HTTP protocol handler should block the call when it waits for an HTTP response (for example, a 200 status code) to make sure that the HTTP listener of the service provider is requested to Work to receive. Any error state associated with a request should cause the exception to be thrown when the client uses the service proxy. It is important to model the interface of a Service Broker so that its models match the WSDL operations defined by the service provider. For example, if a client invokes a one-way operation, the agent will never return a parameter to the client (for example, a status code). This exchange effectively makes the operation a request/reply operation, and the reply information is not from the service provider.

It is expected that the WSDL workgroup of the consortium can extend the asynchronous operation support of the language by providing the ability to formally define the callback mechanism (for example, the reply address) within the WSDL. At the same time, the four basic types listed above can be used to support asynchronous operations. However, the IDE and other WEB service tools currently available to automate the client-side Service Broker generation process typically support only the request/response model.

Mode 1: One-way and notification actions

In this pattern, the request and response are two messages defined within a separate WSDL operation. The request is modeled as an inbound one-way operation, and the response is modeled as an outbound notification operation. Each message is sent as a separate transport layer.

This pattern (see Figure 1) provides a high-level separation between the client and the service provider because it supports exchanging between the two sides using two datagrams, one for the request and one for the response.

Figure 1. One-way and notification actions