![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
The Enterprise Service Bus (ESB) as an architectural pattern has long been used to describe key infrastructure level capabilities of a service-oriented architecture. The ESB provides connectivity between service consumers and service providers, by offering virtual service interfaces to the consumer and mediating the interactions between the two. This decouples consumers and providers, resulting in a more flexible solution that supports interactions between a wide variety of run time platforms, protocols, and message formats.
A significant number of resources exist -- on IBM developerWorks and elsewhere -- that describes more detail about the ESB pattern and its various forms of implementation, mapping to products and usage in concrete use case scenarios. Those will not be repeated here. Instead, this article focuses on a subcomponent within the ESB that becomes relevant as the service interactions reach out beyond internally available networks and services, to connect enterprises with each other, or to connect domains within an enterprise. We call this component the ESB Gateway, and delegate some of the functionality to it that is typically included in the ESB as a whole.
After this component and its included capability have been introduced, we’ll look at a set of products that can be used to implement the ESB Gateway, together with some information about how they can easily be integrated.
By now, you will have noticed that the concept of patterns is often used to provide an abstract view of a proposed solution, which you can then link with a specific implementation. This facilitates starting out with a common and consistent way of naming and relating the various elements of the solution, without any dependency on a particular technology or platform. Applying detailed functional and non-functional requirements to the pattern can then be used to select the appropriate product set for concrete implementation.
Figure 1 shows the Enterprise Service Bus as a run time pattern, which is included in the IBM Patterns for e-business.
Figure 1. The ESB runtime pattern
As mentioned earlier, this pattern can be refined by decomposing the hub into a number of subcomponents, one of which is the ESB Gateway, as shown in Figure 2.
Figure 2. The exposed ESB Gateway composite pattern
Notice that Connector components have been added, which enable connectivity with services that use possibly proprietary platforms and protocols. Moreover, a Service Registry has been introduced that is positioned outside of, but closely linked with the ESB. A Demilitarized Zone enables further protection from malicious or unauthorized access attempts from outside the Enterprise Secure Zone.
The IBM Patterns for e-business glossary offers the following definition of the ESB Gateway component, which clarifies its functional scope:
| "An ESB Gateway at a minimum provides service address translation between the ESB and the external consumers/providers. In practice the ESB Gateway will often provide additional services such as security, message transformation and Partner data management." |
In other words, the gateway is responsible for offering services in a secure and consistent fashion so that requests coming from a wide variety of sources can all be treated the same way, with respect to security and overall governance.
Putting out this functionality into a separate gateway component supports further separation of concern when it comes to implementing a concrete solution. For example, you will see later in this article that some of the capability of the DataPower appliance is directly geared toward being used as such a gateway.
Moreover, the gateway can also be moved into the Demilitarized Zone for further security and scalability. And, as has been mentioned before, this is not limited to use with external partners, but can also be leveraged to connect otherwise disconnected domains within one large enterprise.
Returning to the definition of the ESB Gateway above, you can isolate the following set of capabilities that you look for in a product that you can use to implement the pattern:
- Service address translation
- Security
- Message transformation
- Partner data management.
WebSphere DataPower as an ESB Gateway
Taking into account the expected capabilities from the ESB gateway pattern as described above, the WebSphere DataPower appliance (for example, the XI50 model) is a great candidate for being exposed as the main entrance for all the incoming service requests and its respective responses. Using DataPower as an ESB Gateway enables you to leverage capabilities that directly reflect the gateway capabilities introduced in the previous section, such as:
- Service virtualization: Providing true loose coupling between service providers and service consumers, at different levels (message and transport), by intercepting (and mediating) all interactions between the two.
-
Service security:
- Acting as a Policy Enforcement Point, to protect against unauthorized access.
- Standardizing user identity formats within the enterprise with the token transformation service.
- Auditing and logging indicators like requests per amount of time, denials of access, profiling of service consumers, and so on.
- Protocol transformation: Standardizing the used network protocols within the enterprise.
Figure 3 shows the ESB Gateway with the DataPower appliance added to it.
Figure 3. WebSphere DataPower as an ESB Gateway
Notice that in this example, the gateway is moved into the Demilitarized Zone for additional security. However, to fully utilize the appliance within a complete solution, you have to add further support for security and governance aspects by using IBM Tivoli Access Manager and WebSphere Service Registry and Repository, each integrated with DataPower.
The actual Enterprise Service Bus shown in the figure can be implemented with a variety of products; for example, with IBM WebSphere ESB, IBM WebSphere Message Broker or with a separate instance of WebSphere DataPower. This article focuses solely on the gateway part and does not cover the ESB part any further.
Adding security: Tivoli Access Manager
When acting together with IBM Tivoli Access Manager (hereafter referred to as Access Manager), DataPower can provide a full security solution. From an architectural standpoint, DataPower acts as a Policy Enforcement Point; that is, the entity that every request has to go through in order to access the appropriate back end service. Access Manager, on the other hand, acts as a Policy Decision Point and Identity Provider; that is, the entity that evaluates a particular security policy for a specific user, providing authentication and authorization decisions. Therefore, the following capabilities are added to the gateway solution:
- Integration with a policy decision point.
- Integration with an identity provider.
- “Security as a service:†Tivoli Access Manager acts as the focal point for credentials and resources throughout the entire environment, specifically providing the ESB Gateway all the security information it needs to be a trusted entry point.
Figure 4 shows Tivoli Access Manager integrated with the ESB Gateway.
Figure 4. ESB Gateway with Tivoli Access Manager
The figure shows how Access Manager is connected to both the ESB Gateway and the actual ESB, offering security services to both as needed.
To configure Tivoli Access Manager integration with the DataPower device, only a few steps need to be done. DataPower acts as an Access Manager client, which requires that specific configuration files be created. This can easily be done from within the DataPower admin console, as shown in Figure 5.
Figure 5. Configuring Tivoli Access Manager integration in DataPower
The screen capture in Figure 6 shows an example for the parameters that have to be entered for the configuration. Typically, this data can be retrieved from the Access Manager administrator.
Figure 6. Access Manager client configuration parameters
The next and final step is configuring the so-called “Authorization server replicas.†This parameter indicates the network location of the remote Access Manager server when authorizing users at run time. Figure 7 shows an example for what this might look like.
Figure 7. Creating the authorization server replica
The DataPower appliance defines an action called AAA (for Authenticate, Authorize, Audit) that can be applied to all incoming requests. This is the action where all the authentication and authorization steps for any particular request are performed.
After completing the steps described above, you are ready to include all authentication and authorization activities through the configured Access Manager client in any AAA action.
Service endpoint management: WebSphere Services Registry and Repository
To achieve run time governance over services, you now add WebSphere Service Registry and Repository (hereafter referred to as Service Registry), which is used to store WSDL service contracts, including the endpoint address of the service provider, as well as schema files describing the supported message formats.
Using Service Registry in combination with WebSphere DataPower provides service virtualization both at the message and the transport layers. This is how it works:
- DataPower and Service Registry are linked via a “WSRR subscription†that is defined in DataPower.
- After creating such a subscription, WSDL definitions are retrieved from the
Service Registry automatically (within a polling interval), so that any change
to a WSDL is propagated to DataPower at run time, including endpoint and binding
definitions. This adds these capabilities:
- Dynamic endpoint-look up from within the ESB Gateway for incoming service requests, at run time.
- Centralized management of WSDL and associated metadata in an external registry, enabling the establishment of overall SOA governance.
Figure 8 shows how the Service Registry is added to the solution.
Figure 8. ESB Gateway with Access Manager and Service Registry
In order to achieve connectivity between DataPower and the Service Registry, two configuration objects need to be set and enabled: a physical connection from DataPower to Service Registry, called “WSRR Server,†and information about the meta data we want to subscribe to, which is captured in the “WSRR Subscription†configuration object.
The element called “WSRR server†is the DataPower object that is needed to physically establish the connection between itself and the Service Registry. Within the WSRR Server panel, there are several values that need to be entered:
- SOAPURL is the URL used to communicate with the Service Registry via the WSRR SOAP API.
- If security is enabled on the Service Registry (and typically it is), a username and password that has appropriate access to the registry has to be configured. Moreover, secure access to the Service Registry requires configuration of an SSL connection.
Figure 9 shows an example of how to create the WSRR Server object in the DataPower admin console.
Figure 9. Configuring a WSRR Server in DataPower
Configuring WSRR Subscriptions
The “WSRR subscription†object is meant to provide data about the target resource (in this case, a WSDL file) that is retrieved from the WSRR Server. Resources that are stored on the WSRR Server are uniquely identified by a namespace and a name, both of which are assigned when the resource is added to the registry.
Configuration of a WSRR Subscription object also specifies the method to use to ensure that the local copy of the resource is periodically synchronized with the Service Registry copy.
Assume that you have defined a service called “Audit Echo Service,†which is represented by a WSDL file that has been loaded into the Service Registry. To create a subscription object for this service, you can fill in parameters as shown in Figure 10.
Figure 10. Configuring a WSRR Server in DataPower
The example shows that you define the WSRR Server object to be used, the namespace and name of the target WSDL definition in the registry, as well as the way in which this information will be synchronized.
After this configuration, the integration with Service Registry will be ready to be used in a WS-Proxy service, which is how mediations for Web services are named in DataPower.
This article described the ESB Gateway as a key component within the overall ESB architectural pattern, which enables secure and consistent interactions between internal and external service consumers and service providers.
Utilizing the WebSphere DataPower SOA appliance lays the foundation for the ESB Gateway implementation with its support for service virtualization and security. You then added Tivoli Access Manager to facilitate the concept of “Security as a Service,†providing centralized handling of authentication and authorization requests from the gateway. This enables using the gateway as a “Policy Enforcement Point†and Access Manager as a “Policy Decision Pointâ€. Finally, the WebSphere Service Registry and Repository serves as an enabler for SOA governance, specifically by storing endpoint addresses and other service meta data, which are then retrieved and used by the gateway at run time.
One last thing. All of the products mentioned here possess functionality that goes well above and beyond that which is used in an ESB Gateway solution! For the sole purpose of this article, we have deliberately narrowed our focus specifically on the ESB Gateway and its related capabilities.
-
IBM
WebSphere DataPower SOA Appliances product information
-
IBM
Tivoli Access Manager for e-business product information
-
IBM WebSphere Service
Registry and Repository product information
-
IBM Patterns for e-business
- Redbook:
Patterns: SOA Design Using WebSphere Message Broker and WebSphere ESB
- Redbook:
Patterns: SOA with an Enterprise Service Bus in WebSphere Application Server V6
- Redpaper:
IBM WebSphere DataPower SOA Appliances Part II: Authentication and Authorization
-
Managing services dynamically using WebSphere DataPower SOA Appliances with WebSphere Service Registry and Repository
-
Using DataPower SOA Appliances to query WebSphere Service Registry and Repository
-
SOA authorization using Tivoli Federated Identity Manager and WebSphere Service Registry and Repository
Héctor García Tellado works as an IT Specialist in the IBM Software Services for WebSphere organization, mainly focusing on DataPower and the ESB layer of the Service Oriented Architecture. He was selected for IBM Spain as part of a Graduate program and has been involved in several DataPower and SOA engagements since then. Originally from Galicia, he is now based in Madrid. In his free time, he likes playing electric guitar, listening to music and going out with friends.
Andre Tost works as a Senior Technical Staff Member in the IBM Software Services for WebSphere organization, where he helps IBM customers establishing Service-Oriented Architectures. His special focus is on Web services and Enterprise Service Bus technology. Before his current assignment, he spent ten years in various partner enablement, development and architecture roles in IBM software development, most recently for the WebSphere Business Development group. Originally from Germany, Andre now lives and works in Rochester, Minnesota. In his spare time, he likes to spend time with his family and play and watch soccer whenever possible.
