by Kenny Shin
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.
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.
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.
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:
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.
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. Search Bookstore Service Message Flow
Figure 2. Purchase Bookstore Service Message Flow