Practical Enterprise Service Bus Use Cases for SOA

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

Use Case 3: Handling complex and dynamic Web service data validation requirements

In a non-ESB Web service environment, validation of incoming SOAP requests must be included in the service implementation layer either as part of a handler chain or embedded within the service itself. Here are some things to consider with these approaches:

• Since service consumers directly bind to the service layer, all requests, whether valid or invalid, will invoke the actual service implementation.
• Implementing data validation as part of the incoming request handler chain provides a separation of the validation logic from the business logic but tightly couples the application to a particular SOAP stack because of the lack of portability of Web service handlers.
• Including data validation within the service implementation is not desirable because it unnecessarily increases the complexity of the application by embedding the validation logic with the business logic. Since the validation rules are dynamic and expected to change, it would be necessary in this scenario to redeploy a new version of the application to affect the changes to validation rules.
• If data validation is deployed at the service implementation layer, it is difficult to reuse the data validation components without duplicating source code and/or a deployment. Since the ubiquitous nature of XML Schema lends itself toward reuse, it is logical for data validation to be developed as a decoupled and reusable application component.

With an ESB Web service environment, it is possible to perform data validation at the ESB layer; by doing so, validation logic is separated from business logic and the service implementation is insulated from dynamically changing validation requirements. From a deployment perspective the use of an ESB has the added benefit of being able to reject invalid requests without invoking the actual service implementation. Therefore, the service implementation layer will not be forced to handle the load of invalid requests.

For the sake of this example, let's assume the validation requirements include a number of validation rules that cannot be expressed simply with XML Schema and it is expected that the validation rules will need to be updated at a higher frequency than the application. Let's consider a Web service request and response messages that are defined by the XML schema elements below:

<xs:element name="purchaseLoanRequest">

  <xs:complexType>

    <xs:sequence>

      <xs:element name="loanAmount" 

      type="xs:decimal" />

      <xs:element name="interestRate" 

      type="xs:decimal" />

    </xs:sequence>

  </xs:complexType>

</xs:element>

<xs:element name="purchaseLoanResponse" 

type="xs:anyType" />

<xs:element name="validationResponse">

  <xs:complexType>

    <xs:sequence>

      <xs:element name="passedValidation" 

      type="xs:boolean" />

      <xs:element name="validationErrors" 

      type="tns:validationErrorType" />

    </xs:sequence>

  </xs:complexType>

</xs:element>

<xs:complexType name="validationErrorType">

  <xs:sequence>

    <xs:element name="message" type="xs:string" />

    <xs:element name="targetElement" 

    type="xs:string" />

  </xs:sequence>

</xs:complexType>

In the above XML schema snippet, you'll notice there are request and response messages defined for the purchaseLoan operation. Notice the response is defined as an xs:anyType and there is a definition for a validationResponse. This response type will be returned if incoming data fails validation.

For the purposes of this example, let's consider a validation rule that states if the loanAmount is less than $250,000, then the interestRate of the loan must be greater than 5%.

This business rule can be implemented by configuring the Message Flow of a Proxy Service. 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-3.jar into your ALSB domain and view the configuration through the service bus console.

1. Upload the Loan Service WSDL document.
2. Create a Proxy Service based on the Loan Service WSDL definition.
3. Configure the Message Flow of the Loan Service as follows:
   1. Add a Pipeline Pair and add a Stage to the Request Pipeline
   2. In the new Request Stage, create an If-Then action with the following XQuery condition:
      Copy

      
      
      $body/loan:purchaseLoanRequest/loan:loanAmount < 250000 
      
      and 
      
      $body/loan:purchaseLoanRequest/loan:interestRate <= 5
      
      

   3. In the Then execution block, add an Assign action that assigns

      <passedValidation>false</passedValidation>

      to variable passedValidation.
   4. In the Then execution block, add an Assign action that assigns
      Copy

      
      
      <loan:validationResponse>
      
          <loan:passedValidation>false</loan:passedValidation>
      
          <loan:validationErrors>
      
          <loan:message>
      
             Interest Rate must be higher than 
      
             5% for loans less than 250,000
      
          </loan:message>
      
          <loan:targetElement>
      
             {fn:node-name($body/loan:validationRequest/loan:interestRate)}
      
          </loan:targetElement>
      
          </loan:validationErrors>
      
      </loan:validationResponse>
      
      

      to variable validationError.
   5. Create a Branch Node that follows the Pipeline Pair.
   6. Add a path named Failed Validation to the Branch Node by associating it with the condition.

      passedValidation = "false"

4. Edit the newly created Failed Validation path.
   1. Add a Pipeline Pair.
   2. On the Response Pipeline, add a Stage called Generate Validation Error Response.
   3. Within the new Stage, add a Replace Action defined as: Replace node contents of . in variable body with $validationError.

Figure 6. The Loan Service Message Flow

Figure 7. The Failed Validation Branch Node Message Flow

Figure 6 and Figure 7 show the implementation of a simple business rule in the ESB layer. This is a viable strategy for handling simple Boolean comparisons through XQuery expressions. If a more complex business rules implementation is necessary, the ESB layer can be configured to perform a Web service callout to an external business rules implementation and handle the routing of the rules evaluation results in a similar fashion.

Summary

After gaining some experience with ALSB through the use cases and the solutions discussed in this article, the ALSB interpretation of an ESB becomes apparent. Each of the use cases described in the article involves the ALSB providing, though configuration, an "aspect" of a web service in a similar way that aspects are defined in Aspect-Oriented Programming:

• Use Case 1 - Transport Security
• Use Case 2 - Messaging Pattern
• Use Case 3 - Data Validation

In addition to the aspects discussed in this article, an ESB could certainly handle other aspects such as monitoring, message-level security, data mediation, and transactions.

By utilizing an ESB to provide and implement these aspects, the Web service implementation layer can be enriched with a great deal of functionality with a minimal amount of development effort. The abstraction of these Web service aspects at the ESB layer allows for a Web service implementation to focus solely on implementing business logic, greatly simplifying the complexity of the implementation. As additional Web service standards become finalized, ESB products will be able to provide support for a larger set of Web service aspects, thereby increasing the overall value of an ESB in an enterprise.

Kenny Shin is an independent consultant based in the Washington, DC metro area.