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: