Message handlers in a pipeline process request and response messages.
The behavior of the handlers is governed by a set of protocols which describe
what actions the message handlers can take in a given situation.
Each non-terminal message handler in a pipeline is invoked
twice:
- The first time, it is driven to process a request (an inbound request
for a service provider pipeline, an outbound request for a service requester)
- The second time, it is driven for one of three reasons:
- to process a response (an outbound response for a service provider pipeline,
an inbound response for a service requester)
- to perform recovery following an error elsewhere in the pipeline
- to perform any further processing that is required when there is no response.
The terminal message handler in a service provider pipeline is invoked
once, to process a request.
Message handlers may be provided in a pipeline for a variety of reasons,
and the processing that each handler performs may be very different. In particular:
- Some message handlers do not change the message contents, nor do they
change the normal processing sequence of a pipeline
- Some message handlers change the message contents, but do not change the
normal processing sequence of a pipeline
- Some message handlers change the processing sequence of a pipeline.
Each handler has a choice of actions that it can perform. The choice
depends upon:
- whether the handler is invoked in a service provider or a service requester
- in a service provider, whether the handler is a terminal handler or not
- whether the handler is invoked for a request or a response message.
Terminal handler protocols
- Normal request and response
- This is the normal protocol for a terminal handler. The handler is invoked
for a request message, and constructs a response.
In order to construct the response,
a typical terminal handler will link to the target application program, but
this is not mandatory.
- Normal request, with no response
- This is another common protocol for a terminal handler.
This protocol is usually
encountered when the target application determines that there should be no
response to the request (although the decision may also be made in the terminal
handler).
Non-terminal handler protocols
- Normal request and response
- This is the usual protocol for a non-terminal handler. The handler is
invoked for a request message, and again for the response message. In each
case, the handler processes the message, and passes it to the next handler
in the pipeline.
- Normal request, no response
- This is another common protocol for a non-terminal handler. The handler
is invoked for a request message, and after processing it, passes to the next
handler in the pipeline. The target application (or another handler) determines
that there should be no response. When the handler is invoked for the second
time, there is no response message to process.
- Handler creates the response
- This protocol is typically used in abnormal situations, because the non-terminal
handler does not pass the request to the next handler. Instead it constructs
a response, and returns it to the pipeline.
This protocol could be used when
the handler determines that the request is in some way invalid, and that no
further processing of the request should be attempted. In this situation,
the handler is not invoked a second time.
- Handler suppresses the response
- This is another protocol that is typically used in abnormal situations,
because the non-terminal handler does not pass the request to the next handler.
In this protocol, the handler determines that there should be no response
to the request.
This protocol could be used
when no response is expected to the original request, and, because the request
is in some way invalid, no further processing of the request should be attempted.