![[Note]](images.admon/note.gif) | |
| |
Refactoring Synchronous to Asynchronous Interactions
Sometimes your application requires an asynchronous Web Service interaction. Web Services that use asynchronous interactions tend to be more responsive and scale better. However, Web Services provide only a synchronous mode of operation, especially when using the HTTP protocol. In your application you can convert this synchronous interaction to an asynchronous request and reply. You may be able to refactor some of the synchronous interactions of a Web Service application to asynchronous interactions.
Figure below illustrates a synchronous interaction. Notice how the client must suspend its processing until the service completes processing of the request and returns a response.
On the other hand, with the asynchronous interaction, the client continues its processing without waiting for the service. In both the synchronous and asynchronous communication figures, the vertical lines represent the passage of time, from top to bottom. The vertical rectangular boxes indicate when the entity (client or service) is busy processing the request or waiting for the other entity to complete processing. In figure below, the open arrowhead indicates asynchronous communication and the dashed vertical line indicates that the entity is free to work on other things while a request is being processed.
When a component makes a synchronous call to another component, the calling component must wait for the receiving component to finish its processing. If the calling component instead makes the call asynchronously, the caller can proceed with its own work without waiting for the receiving component to do its job.
Below is the list of steps which need to be done to convert a synchronous endpoint to an asynchronous endpoint:
Change a synchronous request/reply interaction into a request that returns void as the immediate reply.
Change the client code to send the message request and immediately return.
Have the client establish a reply address for receiving the response and include this reply address in the request. By including a reply address, the service knows where to send the response message.
A correlation identifier needs to be established between the request message and the service response message. Both the client and the service use this identifier to associate the request and the reply.
Refactor the server endpoint to accept the request, send it to a JMS queue for processing later, and immediately return an acknowledgement to the client. The service retains the correlation identifier.
Have the service processing layer use a message-driven bean to process the received request. When a response is ready, the service sends the response to the reply address. In addition to the results, the response message contains the same correlation identifier so that the service requestor can identify the request to which this response relates.
Have the client accept the response at a Web Service that it establishes at the reply address.
The JMS queue stores the messages until the message-driven beans are ready to process them, thereby controlling the rate of delivery. Thus, the component can process the messages without being overwhelmed, which helps the service to scale better.
