# Introduction to Asynchronous Interfaces

Web applications, including web services, typically use the Hypertext Transport Protocol (HTTP) to provide communication between a client and a server (the application). HTTP is a request-response protocol. In a request-response protocol, each operation consists of a request message sent from the client to a server followed by a response message returned from the server to the client. The server must always send a response for the operation to complete successfully. Such requests are called synchronous because during the request the client is synchronized with the server; the client cannot continue processing until the server responds or the request times out (the client may time out if a response is not received within a specific period of time).

In a web application, some of the operations the application performs may be long-running. If an operation involves human interaction such as approval by a loan officer of a bank, the operation could take days to complete. It would be a poor design if individual request-response cycles were allowed to span days; such requests would unnecessarily engage resources on both the client and server hosts.

With WebLogic Workshop, you can design your application to be asynchronous, which means that the application notifies the client when the response is ready. This allows the client to continue performing other work while the application completes the requested operation. It also keeps each request-response interaction between the client and application as short as possible.

To create an asynchronous web service, you provide one or more methods that accept requests from clients that begin an operation but do not wait for the operation to complete. Such methods typically return immediately, supplying the response portion of the initial request-response interaction but not supplying the actual result of the requested operation. In an asynchronous interface, you also provide a mechanism for the client to obtain the results of the long-running operation when the results are ready. There are two ways to accomplish this:

- Implement methods that initiate requests and define callbacks to send results.
- Implement methods that initiate requests, methods that return request status (for example, "pending" or "complete") and methods the return results. This approach is referred to as a polling interface.

## Using Callbacks

When you define a callback for a web service, you are defining a message for the web service to send to the client that notifies the client of an event that has occurred in your web service. In this design, the client first calls the web service with a request. This request call typically returns immediately (completing the first request-response interaction), meaning that the client does not have to wait for the operation to be completed. The client can now continue doing other tasks. When the web service or Java control has finished processing the client's request, it sends a callback, that is, it sends a message back to the client notifying it that the request has been processed and/or providing the results. Note that a callback constitutes a second request-response interaction in which the request (not the response) is sent to the client. To learn more about the callback mechanism, see Using Callbacks to Notify Clients of Events.

To use a callback, two requirements must be met. First, if a web service defines a callback the web service must be conversational. Conversational web services keep track of the originator of a request and can therefore send the callback to the appropriate caller. Secondly, the client must be capable of receiving and interpreting the callback. If the callback is defined by a web service, then in essence the client must itself be a web service since it must be capable of receiving messages. It must also be capable of correlating an incoming message with a previous request that it initiated. To learn more about conversations, see Designing Conversational Web Services.

## Using Polling

When the client of a web service or Java control is not conversational, as is the case for web pages and non-conversational web services, callbacks cannot be used to notify the client of request completion. In addition, if the client of your web service resides on a host that rejects unsolicited incoming traffic or is protected by firewalls, the host will reject callbacks because callbacks are, by nature, unsolicited, and the client will not receive the callback. To handle these scenarios, web services and Java controls must provide a polling interface. In a polling interface, the client first calls the web service or Java control to that an operation be initiated. This request call is synchronous but typically returns immediately, meaning that the client does not have to wait for the operation to be completed. The client can now continue doing other tasks, but must periodically call the web service or Java control to check the status of its pending request. When a periodic check shows that the request has been completed, the client then calls the web service or Java control to obtain the result. To learn more about implementing a polling interface, see Using Polling as an Alternative to Callbacks.

Polling and callbacks are two different mechanisms to achieve asynchrony. Unless you are absolutely certain that the clients of your web service or Java control will always require only one of these mechanisms, you may want to implement both approaches in order to handle all situations. Doing so provides the convenience of callbacks to those clients who can handle them, and a polling interface for clients who cannot accept callbacks. For more information, see Best Practices for Designing Asynchronous Interfaces.

## Buffered Methods and Callbacks

When a conversational web service's request method is called by multiple clients at the same time, a client might have to wait until its call, however short, has been processed by the web service. In addition, when a web service has completed processing multiple requests and needs to send multiple callback messages, it must wait for a message to be processed by the client before it can send the next callback. For a conversational web service, and especially for a web service receiving high-volume traffic, it is recommended to always add buffers to the web service's methods and callbacks. When clients call a buffered method, the call is stored in a buffer and the client does not have to wait for the web service to handle the call. When a web service sends a callback, the message is stored in a buffer and the web service does not have to wait until the client processes the callback. To learn more about asynchronous methods and callbacks, see Using Buffering to Create Asynchronous Methods and Callbacks.

It's important to distinguish between an asynchronous web service and an asynchronous method. A web service can be designed to be asynchronous without using asynchronous methods. For example, a web service can provide a synchronous request operation that returns an acknowledgement but not the result, and later calls a synchronous callback that sends the result and receives an acknowledgement from the client. Both the method and the callback are synchronous, but the web service is asynchronous.

Related Topics

Building Web Services with WebLogic Workshop