8.2 IBM Web Services Gateway

< Day Day Up >

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.

click to expand
Figure 8-1: IBM Web Services Gateway

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:

The SOAP message arrives at the gateway and the channel listener accepts the message.
The channel converts the SOAP message into a WSIF message format.
Elements within the message are used to locate the appropriate target service, which is bound to the channel within the gateway.
The target WSDL associated with the gateway service is then processed by WSIF.
WSIF dynamically generates a Java proxy class.
The target Web service is called.

Figure 8-2: WSIF transformation

Refer to the following IBM developerWorks articles for further details:

Applying the Web services invocation framework

http://www.ibm.com/developerworks/webservices/library/ws-appwsif.html
An introduction to Web Services Gateway

http://www.ibm.com/developerworks/webservices/library/ws-gateway/
Business process integration with IBM CrossWorlds, Part 3: Automatically externalize Web services with WebSphere Business Connection

http://www.ibm.com/developerworks/ibm/library/i-cross3

< Day Day Up >