When errors are detected during the default message processing
flow, the Access Gateway invokes
certain mediation primitives in a set sequence.
Upon completion of the default message flow, the response object
is returned through the SCA export invocation, as the Web service
response. If a failure occurs during the execution of the request
portion of the flow, then fault handling segment of the flow is invoked.
When handling a Web service response, the response is always returned
to the requester despite faults within the flow. This ensures consistency
with the backend system. Errors during a request flow are signified
by the output of the mediation primitive being placed on its fault
terminal. This fault terminal will be wired to the fault processing
segment of the flow, which returns the error response to the requester.
The
Access Gateway performs
a transformation step, in order to convert a fault to a WSDL defined
error type in a fault situation. This step is performed just prior
to returning the error response to the Web service client, and it
matches the client expected output from the WSDL interface.
Figure 1. Access
Gateway Fault Flow
The default handling flow segment executes the following mediation
primitives in sequence for a request flow. In a response flow, only
the highlighted mediation primitives are included.
- The Network Statistics mediation primitive is called to log statistics
about the fault event.
- If message capture is enabled by policy, the Message Interceptor
mediation primitive logs the actual fault object being returned to
the requester.
- The JMX Notification mediation primitive emits a JMX notification,
which contains information about the fault.
- If there is a policy specifying that a common base event should
be emitted, the CEI event emitter mediation primitive emits the common
base event. This enables the fault information to be picked up by
external security or monitoring systems, such as Tivoli products.
- An XSLT transformation is performed to create an appropriate WSDL-default
fault from the SMO. This provides an appropriate fault response for
the caller. The XSLT transformation mediation primitive is provided
with the WebSphere® ESB platform.
Note: The
XSLT transform file has changed in WebSphere ESB,
which allows necessary porting to account for the change in the runtime.
Any
outgoing requests that originate from within a service implementation–for
example, Web service notifications– must also pass through the TWSS Access Gateway.
The request is subject to standard message processing logic. This
allows for logging, calculation of network statistics, and other policy-driven
actions. You can also choose to create a custom flow, which is slimmed
down for outbound requests. The requests should indicate, within the
SOAP header, that the Access Gateway is
to perform as a Web service intermediary but not as a final destination
for the request.