In this example we will examine a Web service that is implemented with a synchronous messaging pattern that exceeds a maximum response time threshold service-level agreement requirement.
To illustrate this use case, let's consider a hypothetical Web service that implements an operation that services a request by performing some business logic and then writes the results to a file:
<portType name="exampleServicePortType"> <operation name="writeToFile"> <input message="tns:writeToFileRequest" /> </operation> </portType>
As defined in the above WSDL excerpt, the writeToFile operation is an ideal candidate to be implemented with an asynchronous messaging pattern for two reasons:
Implementing an asynchronous messaging pattern where requests are asynchronously executed can mitigate this performance issue. With an asynchronous messaging pattern, the service consumer's request will be queued for later execution and will immediately return, thereby ensuring the Web service is able to meet the required response time SLA.
The implementation of an asynchronous messaging pattern in a non-ESB Web service environment would require the service implementation layer at a minimum to include logic that manages the queuing and asynchronous execution of service requests. A more robust implementation would need to provide additional functionality along the lines of that typically provided by message-oriented middleware including persistence, monitoring, and management. If left solely to the service implementation layer, these concerns will greatly increase the complexity of the service implementation and deployment. By implementing an asynchronous messaging pattern at the ESB level, the Web service can meet its required SLA without adding complexity to the service implementation layer.
ALSB can be configured to provide an asynchronous messaging pattern on a previously synchronous Web service implementation by queuing incoming service requests in a JMS queue and dispatching the messages to the synchronous service implementation.
Figure 3. Asynchronous Message Pattern implemented using ALSB
The use of JMS as the underlying infrastructure of the asynchronous messaging brings a number of side benefits, such as persistence, monitoring, management, and the ability to distribute and scale the application to additional nodes should the application require additional throughput.
The high-level steps to implement this solution are described below. If you wish to view the completed configuration in full detail, import use-case-2.jar into your ALSB domain and view the configuration through the service bus console. Note: For the import to be successful, it is necessary to create the JMS Queue (WriteToFileQueue) and the JMS Connection Factory (WriteToFileCF) prior to executing the import.
The configuration is summarized in Figure 4 and Figure 5.
Figure 4. The Write To File Service Message Flow
Figure 5. The Write To File JMS Consumer Message Flow