Patterns: Broker Interactions for Intra- and Inter-enterprise

Chapter 8. Router solutions using Web Services Gateway 151

8.2 IBM Web Services Gateway

The IBM Web Services Gateway is a runtime component that provides

configurable mapping between Web service providers and requesters. Services

defined with WSDL can be mapped to available transport channels. The Web

Services Gateway is included with the IBM WebSphere Application Server

Network Deployment and Enterprise packages.

These are the basic gateway components:

򐂰 Channels that define the entry-points into the gateway and carry the Web

service request and response through the gateway.

򐂰 Filters that are used to intercept service invocations which come into the

gateway and act upon the services.

򐂰 Services that are described with the help of a Web Services Description

Language (WSDL) document.

򐂰 UDDI references to manage the publishing of an exposed Web service to a

private or public UDDI registry.

Figure 8-1 shows the relationship between the first three components. The entry

point to the gateway is defined by a channel. A channel is a piece of software that

defines the protocol you can use to access the gateway. The incoming message

is assessed on arrival through the channel to determine which service is

required. Each service (defined in a WSDL document) has to be bound to one or

more channels. One or more filters can be bound to a service for manipulating

both request and response messages. The WSDL service definition specifies the

provider service interface and implementation used to access the target service.

Figure 8-1 IBM Web Services Gateway

IBM Web Services Gateway

Filter

Filter

Target

Application

Channel ProviderService

Source

Application

152 Broker Interactions for Intra- and Inter-enterprise

A request to the Web Services Gateway arrives through a channel and is

translated into an internal representation of the service. With the help of filters for

the request, a request can be logged, intercepted, or generally manipulated.

After filtering the request, an appropriate provider is used to communicate with

the target service. The provider in the gateway acts as a client for the target Web

service.

The response from the target service flows along the exact same path back to

the provider. There is no extra channel for an immediate response. In this sense

the layout of the gateway is asymmetric. However, one or more response filters

can be deployed independently of the request filters.

The process of deploying a target service into a gateway channel generates two

different

external WSDL files; an implementation definition and an interface

definition. These new WSDL files can be exported for use by client applications,

and are the externalization of the service capabilities offered by the

internal

target service. The implementation WSDL definition is used to simplify the

connection process for a client, particularly when dynamic invocation is being

used. Having obtained the implementation definition, the client can then access

the WSDL interface definition produced by gateway, which provides full

information about the target service (as presented externally by the gateway).

The Web Services Gateway uses the Web Services Invocation Framework

(WSIF) API from Apache to decouple invocation from deployment within the

gateway. Over time, the location of the Web service target application and the

bindings may change, but these details are handled by the gateway. The Web

Services Gateway separates the actual implementation of a service from how it

is accessed by another service for:

򐂰 Inbound requests: To Web services created and deployed within the

organization.

򐂰 Outbound requests: To Web services created and deployed outside the

organization.

򐂰 Process abstraction: The service invocation approach must be flexible

enough to cope with events such as switching frequently between external

providers of a similar service without requiring changes to the application.

򐂰 Flexibility: As a service provider, you need the flexibility to change your

deployment infrastructure without notifying all the service requestors. For

example, consider a Web service deployed in a machine that later fails during

operation. There needs to be a process to route the invocations to an

alternate service in your infrastructure.

WSIF is used within Web Services Gateway as shown in Figure 8-2. It

demonstrates the WSIF transformation from a SOAP message to a target

service: