IBM SOA Foundation product integration: A complete ESB Gateway solution featuring WebSphere DataPower, Tivoli Access Manager, and WebSphere Service Registry and Repository

Leveraging the concept of a service-oriented architecture usually brings with it the ability to connect an increasing number of systems within an enterprise -- but also across enterprises. While enabling a higher degree of automation and reduced processing time, this also leads to growing concern about managing and securing the underlying connections between heterogeneous IT systems.

This article describes how to address these concerns by implementing an ESB gateway using three of the products within the IBM® SOA Foundation platform, beginning with integrating a IBM WebSphere® DataPower® SOA Appliance with IBM Tivoli® Access Manager for security, and then adding IBM WebSphere Service Registry and Repository for endpoint address management. This content is part of the IBM WebSphere Developer Technical Journal.


Héctor García Tellado, IT Specialist , IBM

Author photoHé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, Senior Technical Staff Member, IBM

Andre TostAndre 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.

10 December 2008

Also available in Chinese


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.

The ESB Gateway pattern

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
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
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.

In this article, we are not addressing any specific version of the named products. The screen capture examples provided are based on a recent version of the DataPower appliance. However, we expect that the introduced concepts will be equally applicable to future releases.

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
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
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
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
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
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
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.

Configuring WSRR Server

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
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
Figure 9. 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.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

Zone=WebSphere, SOA and web services, Tivoli
ArticleTitle=IBM SOA Foundation product integration: A complete ESB Gateway solution featuring WebSphere DataPower, Tivoli Access Manager, and WebSphere Service Registry and Repository