Practical Enterprise Service Bus Use Cases for SOA
Pages: 1, 2, 3

Use Case: Handling messages throughput service-level agreements

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:

1. The Web service is defined as a one-way service and therefore does not define a response message to be sent to the calling application. Therefore it is not required to implement an asynchronous callback for this service.
2. The service implementation requires writing to a file. Under load, the Web service's performance could become bound by a server's file I/O throughput. With a synchronous messaging pattern, this would manifest itself as a performance bottleneck as execute threads would be forced to block until a file resource becomes available. Under this scenario, the service consumers would be blocked as well while the service implementation waits for file resources to become available.

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.

1. Add a JMS queue with a JNDI name of WriteToFileQueue to the WebLogic domain configuration
2. Add a JMS Connection Factory with a JNDI name of WriteToFileCF to the WebLogic domain configuration
3. Configure a Business Service reference to the JMS queue named Write To File JMS Queue
4. Configure a Proxy Service that will consume off the WriteToFileQueue named Write To File JMS Queue Consumer
5. Upload the Write To File Service WSDL document
6. Configure a Business Service reference named Write To File Service Implementation to the service implementation. Note: This Business Service does not actually exist; the dummy reference is required by this example to fully illustrate the routing.
7. Configure the Write To File JMS Queue Consumer to route request messages to the Write To File Service Implementation Business Service
8. Configure a Proxy Service named Write To File Service
9. Configure the Write To File Service to route request messages to the Write To File JMS Queue Business Service

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