Practical Enterprise Service Bus Use Cases for SOA

by Kenny Shin
07/19/2006

Abstract

The Enterprise Service Bus (ESB) is still a relatively loosely defined concept in the context of a Service-Oriented Architecture (SOA). As with any other enterprise software technology, the role of an ESB will become more clearly defined as common use cases, best practices, and design patterns emerge. This article presents the use of the BEA AquaLogic Service Bus (ALSB) through practical examples encountered by the author, and by doing so provides the reader an improved understanding of the role and value of an ESB in a SOA implementation.

Introduction

As enterprise service bus products mature and gain acceptance in organizations that have decided to adopt a service-oriented architecture IT strategy, developers and enterprise architects face the question of how to best utilize an ESB in the context of a SOA implementation. Since the SOA ESB is a new technology, different interpretations of the true architectural role of an ESB exist. Consequently, the focus of current ESB products as well as the features they provide vary widely across products. As with any other enterprise software technology, the role of an ESB will become more defined as common use cases, best practices, and design patterns emerge as ESB products become widely used by developers and successfully deployed in production systems.

This article attempts to frame the role of AquaLogic Service Bus (ALSB) in a SOA/Web service environment by detailing practical examples encountered by the author and how these were addressed using ALSB. The cases in this article address aspects of Web services including security, performance, and data validation. After reading these cases, hopefully the reader will gain a clearer understanding of the role of an ESB in a SOA implementation.

ALSB Configuration Import

To illustrate the examples described below, this article utilizes the ALSB configuration import feature. In the ALSB console, under the System Administration menu, you'll find an Import Resources option. This option allows for full or partial ALSB configurations (including resources such as WSDL and XML Schema) to be imported into a domain. Each example in this article includes a downloadable jar file containing the stored ALSB configuration. Readers should be able to import this jar file into their own ALSB domains and recreate the ALSB configuration in full detail without having to follow step-by-step instructions.

Use Case: Different transport-level security requirements for a Web Service's operations

In this use case we'll consider a Web service consisting of operations that have different transport-level security requirements.

To illustrate this example, we'll consider a hypothetical bookstore Web service that defines two operations:

  1. SearchByAuthor - This is a publicly available and unsecured search operation intended to be invoked by any client application over HTTP.
  2. PurchaseBook - This purchasing operation will include the exchange of credit card information and requires the request and response messages to be encrypted using HTTPS.

For the sake of this article, let's also assume there is a single database where the purchasing information is stored alongside the index for the book search. From a purely implementation-focused perspective, it may make sense to implement the two operations as a single Web service as they both access a common data source. Therefore, a single implementation would be able to reuse common data access components across the implementations of the two operations. Unfortunately, the different transport-level security requirements of the two operations make a single implementation and deployment of this service problematic as it is difficult to enforce transport-level security for a Web service at an operation granularity level. The difficulty lies in the fact that servlet containers can be configured to enforce transport-level security only at a port level or URL level. Since a Web service's operations are bound to a single URL, it is not possible to enforce transport-level security at an operation granularity level through conventional configuration.

Therefore, to fulfill this security requirement in a Web service implementation architecture where service consumers bind directly to service implementations (that is, an architecture without an ESB), it would be necessary to create two separate Web service definitions and service implementations. By creating separate implementations it will be relatively straightforward to apply and enforce different transport-level security to meet the aforementioned functional requirements. The tradeoff with this approach is that there would be an additional application to develop, deploy, and maintain for no reason other than an inability to easily configure and enforce transport-level security at a Web service operation-level granularity.

ALSB provides an elegant solution to address this use case by being able to decompose a single Web service into two "logical" instances of the service, one containing the SearchByAuthor operation bound to an HTTP endpoint and the other containing the PurchaseBook operation bound to an HTTPS endpoint. By "logically" decomposing the service rather than actually creating separate implementations, the two operations can be configured easily with different transport-level security while maintaining a single application deployment, thereby satisfying both functional and implementation considerations.

The decomposition of the Bookstore Service is accomplished by the ALSB through the configuration of two Proxy Services that route requests to the service implementation. To recreate the completed configuration, import use-case-1.jar into your ALSB domain.. Note: For the import to be successful you must enable the SSL listen port on the ALSB domain.

  1. Upload the Bookstore Service XML schema that contains the input and output messages for the bookstore Web service. Implementation note: Importing the messages into a WSDL document from a schema rather than embedding the schema within the WSDL document allows the bookstore service to be decomposed into logical services without duplicating the definitions of the input and output messages.
  2. Upload the WSDL document that defines the service implementation, BookStoreService.wsdl.
  3. Upload the WSDL document that defines the search service, SearchBookStoreService.wsdl.
  4. Upload the WSDL document that defines the purchasing service, PurchaseBookStoreService.wsdl.
  5. Configure a Business Service to provide a reference to the BookStoreService.
  6. Configure a Proxy Service to provide an interface for the SearchBookStoreService.
  7. Configure the SearchBookStoreService Proxy Service to use the HTTP protocol.
  8. Configure the routing of the service to route requests to the BookStoreService Business Service.
  9. Configure a Proxy Service to provide an interface for the BookPurchasingService.
  10. Configure the service to use the HTTPS protocol.
  11. Configure the routing of the service to route requests to the BookStoreService Business Service.

By configuring ALSB with "logical" endpoints for the SearchBookStoreService and the BookPurchasingService, the functional requirements for transport-level security are fulfilled without affecting or adding complexity to the service implementation. This is illustrated in Figure 1 and Figure 2.

Figure 1
Figure 1. Search Bookstore Service Message Flow

Figure 2
Figure 2. Purchase Bookstore Service Message Flow

Pages: 1, 2, 3

Next Page ยป