Web Services is a backbone technology of Service Oriented Architectures that offers us the benefits of designing highly distributed applications. They play a major role in many of todays' B2B and B2C applications.
Web Services gained success because of its support for SOAP/HTTP (read SOAP over HTTP). Although SOAP/HTTP isn't the only type of web service communication, it enabled businesses to communicate with each other using these standardized protocols (Example, Amazon and PayPal). B2B applications existed even before SOAP/HTTP, but special provisions had to be made for access to services from external organizations. SOAP/HTTP only eased this type of communication and hence we witness trending interest in web service applications.
The notion of web service as a synchronous (request-response) model has been reformed into a larger family of communication models, by enabling them with support for asynchronous type of web service design. In this paper we will focus on the design considerations for asynchronous web services, their types, advantages they offer and also cover their inherent limitations.
Asynchronous Web Services
Asynchronous web services are suitable when the clients (service consumers) cannot afford to wait until the processing is done by the server (service provider). The client may need to continue with other processing tasks and better utilize its local resources rather than merely waiting for a response from the server. This scenario is often termed as "non-blocking" from the client's perspective.
Asynchrony can be achieved by various mechanisms. We will focus here how asynchronous client-server interactions can be achieved in Axis2 implementations. There are multiple ways that can be used to induce asynchrony in web services [3]. From an architectural perspective, this asynchrony can be configured or programmed either on the server or the client.
Callbacks using onMessage()
When asynchrony is to be programmed at the client, axis2 provides a non-blocking API to the client. The SOAP messages generated on the client application are processed by the SOAP engine and sent to the server. The client resources are released so that it may continue performing other tasks. In this web service call, the client also passes a callback handle to the SOAP engine. The callback interface is used by the SOAP engine to notify the client when the response arrives from the server's SOAP engine.
The callback interface has two methods which aide the invocation of actions when SOAP response arrives.
Polling - Callbacks using isComplete()
Clients can be configured to poll for a response by invoking isComplete() method in a loop. This method is useful when more than one callback handles are waiting for responses.
Asynchrony at Transport Level
Asynchrony can also be achieved at transport level. A one-way (SMTP) or two way (HTTP) transport can be camouflaged by asynchronous behavior. A client may use an HTTP channel to send the request. Since it is a two way transport, the client closes the connection (anticipating that response on this connection is likely to take longer time). The client then sets up a different HTTP channel to receive the response. Axis2 provides WS-Addressing mechanism for mapping responses to requests.
Asynchrony at the server
On the server, the same thread that receives the request usually processes the response. In some cases, where an extended amount of time is required to pack the response, the client's transport channel might time out. Axis2 provides a facility where the server may immediately (only) notify the receipt of request to the client without sending the processed response. Then, once the processing is done after a stipulated amount of time, it can reply on a separate transport. This mechanism too exploits the features of WS-Addressing for mapping requests to responses. In this case, the client must also mention a valid replyTo endpoint for the server to send the response back.
The selection of appropriate client API (async-polling or otherwise) and the transport, thus play a crucial role in achieving the asynchronous behavior in web services. Also, the message exchange patterns (MEP), which we discuss in the next section, equip us with techniques to mock behaviors (sync or async).
MEP and the transport to consume the web service is advertised by the service provider, while the behavior of transport and the sync/ async behavior of the client using the client API is in the control of the service requestor (client).
Message Exchange Patterns
The SOAP envelope can be exchanged between the web service client and the provider in different ways. These 'ways' are technically termed as message exchange patterns or mep."Web Services Description Language (WSDL) message exchange patterns define the sequence and cardinality of abstract messages listed in an operation" [1].
The most commonly adopted meps include in-out type and in-only type. In the former case, the client sends a SOAP message to the server, which processes the message and sends a response back. In the latter case, the client sends a message to the server and does not wait for a response.
Let's take a look at two patterns that may find applications in many scenarios. The "IN-ONLY" mep is commonly known as "Fire and Forget" mechanism. In this, the client fires (sends) a message to the server and 'forgets' about it, or does not expect a response. The "IN-OUT" mechanism, on the other hand, does wait for a response when a request is fired.
MEPs allow us to design client-server applications which are blocking or non-blocking in nature. The following table illustrates the different ways in which the asynchronous behavior can be achieved:
MEP
Sync/Async
Transport Behavior
In-Only
Async
One-way
In-Out
Sync
Two-way
In-Out
Async
One-way
In-Out
Async
Two Way
Table 1. MEP for async/ sync behaviors [2]
The IN-ONLY mep is likely to be useful where a response is not expected by the requestor. An example of this is generating logs or sending an acknowledgement. The fire-and-forget however may not be suitable in interactive applications or where the next action is based on the successful completion of execution of the current action or set of actions.
In IN-OUT type, the client can be designed for either type of behavior (sync/async). When a non-blocking client is to be designed for a service that identifies itself as in-out type, it may pass on either the callback address to the server or may use polling mechanism with callbacks till it receives the response. This is irrespective of the transport mechanism.
Limitations of asynchronous web services
When using a single transport for reply and response, web service invocations that take longer execution time or use one-way transports, the non-blocking API cannot be directly used. This requires request and response be sent on separate connections.
A robust correlation mechanism may need to be employed to map requests to responses. This is required because either the threads processing the request or the transport used for sending the response may be different. Hence, there is a need to keep track of responses and their corresponding requests. Web Service addressing provides a solution to this problem to a great extent. The correlation process, however, in bulk processing time-critical applications may hit the performance of the system.
Asynchronous Web Services may not be suitable in real time voice/ video applications because such applications are latency intolerant.
Case Study: Asynchronous Web Service
Let us consider an example of an online air travel reservation system using synchronous/ asynchronous web services. This reservation system is nowadays integrated with other online services such as hotel bookings, taxi reservations, payment gateways (PayPal/ IPX, etc.) and so on. Web services provide a technological solution to expose business operations for consumption by customers and business partners. For the end user, however, these interactions between multiple parties are usually transparent.
Such a system can be designed using multiple tiers of web service interactions which may be synchronous, asynchronous or a combination of the two. End users await a response for their online reservation. While the airline service finds the cheapest fares for airlines requested by the client, another asynchronous web service call may be initiated to find the nearby hotels at the destination airport over the web service that exposes business functions to search and make hotel reservations.
Now, a mix and match approach may be adopted while designing the system such that synchronous and asynchronous services are in play from the moment the request is received on the service end point.
If this design were to be inclusive of purely synchronous web services, the behavior of the system would be sequential in nature. This scenario would be altered, if some of the service calls could be made asynchronous using asynchronous web services. This can be done only for those operations when the processing of certain business functions is not directly dependent on completion of execution of other operations of other web service calls. Thus, some amount of parallelism can be achieved for achieving efficient solutions. Without digressing to another topic, business process execution language is a form of orchestration mechanism, which allows designing the flow of data made between inter-component calls (web services or otherwise), where a combination of synchronous and asynchronous behaviors can be combined.
Conclusion
Asynchronous web services offer advantages over their synchronous counterparts in many real time scenarios. However, it is not obvious that it is the only solution to the shortcomings of synchronous ones. Many business cases often employ a middle approach in selection of design of web service based applications.
Axis2 implementation provides various ways to achieve asynchrony in web services. In combination with mechanisms like WS-addressing and the selection of appropriate asynchronous web service types, the development of asynchronous web applications is becoming a common industrial practice.
