Solicit-Response MEP (abstract output-input MEP)

Dear listies,

Here's the promised output-input MEP.  It follows, more or less, the form of description adopted in section 6.2 of the SOAP 1.2 specification, part two.  Except that it's less formal, and is in text only format, instead of HTML.

This description applies to output-input in which there are zero or more responses.  It is asserted that 1,1 (synchronous or asynchronous) is merely a special case of 1,* (albeit with special, and simpler, termination conditions).

The author notes that a set of standardized features would have been awfully useful, since they could be referenced where needed for things like message identification and correlation, message addressing, and so on.

Amy!
This document defines the message exchange pattern (MEP) called
"Solicit-Response".  The description is an abstract presentation of the
operation of this MEP.

1. MEP identification

This message exchange pattern is identified by the URI:

    "http://www.w3.org/2003/01/wsdl/mep/solicit-response/"

[Note: it would be preferred if this were in the web services architecture
namespace, but I'm not on that working group]

2. Description

    The Solicit-Response MEP defines a pattern for the exchange of a single
message acting as a solicitation, followed by zero or more messages acting as
responses.  In the absence of failure in the underlying protocol, this MEP
consists of at least one message, but usually consists of more.

In the normal operation of a message exchange conforming to the
Solicit-Response MEP, a solicitation is first transferred from the
soliciting node to the responding node(s).  Following the successful
processing of the solicitation by each responding node, a response message
is transferred from the responding node to the soliciting node.  Because
multiple responses may be received, over a period of time, specializations
of the MEP may include termination conditions.  Responses received after
termination are to be treated as failures, which might mean that they are
silently discarded, or that they generate a fault.

Abnormal operation during a Solicit-Response message exchange might be
caused by a failure to transfer the solicitation message, a failure at one
or more responding nodes to process the solicitation message, or a failure
to transfer one or more response messages.  Such failures might be silent at
either or both of the soliciting and responding nodes involved, or might
result in the generation of a fault.  Also, during abnormal operation each
node involved in the message exchange might differ in its determination of
the successful completion of the message exchange.

The scope of a Solicit-Response MEP is limited to the exchange of a
solicitation message and zero or more response messages between one
soliciting and zero or more responding nodes.  This pattern does not mandate
any correlation between multiple solicitations nor specific timing for
multiple solicitations.  Implementations MAY NOT choose to support multiple
ongoing solicitations (and associated response processing at the same time,
and MAY choose to implement a shoe-shine module.

3. State Machine Description

Note that in the following description, there is no indication of a state
for "success" and "failure."  A responding node may reasonably consider
itself to have succeeded when it transmits a response and does not
immediately receive a fault.  A soliciting node, on the other hand, has
complex state to represent success or failure, since it may receive response
messages and faults, and may successfully process some response messages
while faulting on others.  It is more reasonably to speak of the exchange
being terminated than it is to speak of the success or failure of the
exchange.

3.1 Properties

[Note: the following properties ought to be given either URIs or QNames as
names.  Realizing that entire days can be spent in arguing over the proper
form of naming, I've sidestepped the issue here, which has the additional
benefit of increasing readability]

Pattern Name: the name of the pattern.  URI.  See section 1.
Message: the "current message".  A message.
Trigger Message: the message for which the current message is a response.  A
message.
Message Identification: a unique (in application-defined scope, default
global) identifier for the current message.  Type application-defined.
Message Reference: the identifier of the trigger message for the current
message.  Type same as Message Identification.
Destination Address: the address to which the message is sent.  Protocol
defined, but typically a URI.
Reply-To Address: the address to which a response to the message should be
sent.  Protocol defined, but typically a URI.
Failure Reason: the reason that the exchange (or some portion of the
exchange) terminated abnormally.
Role: the role played by the node in this exchange.  One of "Soliciting
node" or "Responding node".
State: the current state of the participating node.  One of "Initializing,
Idle, Listening, Constructing message, Sending, Receiving,
Parsing/Processing, Error, Fault".
Termination Condition: the conditions under which further response messages
received will be considered errors, rather than responses.

3.2.insertWithoutRenumbering States

This description attempts to use a set of states that should be more or less
universal for processors involved in network interactions.  The following
list explains these states.

Initializing: the processor is starting up, and can't do anything else
useful.  This state is prerequisite to most interactions.

Idle: the processor is idle with respect to the exchange being described; it
is not actively doing anything at all (but it may be waiting for a state
change that will cause it to initiate an exchange).

Listening: the processor is actively listening for messages.  With respect
to the solicit-response exchange pattern, this means that a subscriber is
listening for a solicitation, or a soliciting node is waiting for responses.

Constructing message: the processor is creating a message, from a received
message or from other information.

Sending: the processor is sending a message.

Receiving: the processor is receiving a message.

Parsing/Processing: the processor is either examining the message, or has
passed it on to some application logic that will do so.

Fault: an error has occurred which someone else needs to know about, since
it represents abnormal termination of the exchange when multiple parties are
already involved.

Error: an error has occurred which effectively prevents the processor from
joining the exchange, or that removes it from the exchange gracelessly, with
no chance of alerting partners in the exchange (if any such exist).

3.2 Initial State, Soliciting Node

The soliciting node is required to have completed initialization.  In its
initial state, the soliciting node is idle, monitoring (in some fashion)
internal state changes which will cause a solicitation to be sent (this may
be as simple as monitoring the keyboard, or very complex).

When an external stimulus initiates a new message exchange, the soliciting
node enters the Constructing message state.

3.3 Initial State, Responding Node

The responding node is required to have completed initialization.  It will
also have performed protocol- or application-defined semantics which may be
loosely described as 'subscription' (mailing list subscription, newsgroup
'subscription', multicast group membership, and so on).  It is then said to
be listening for solicitation messages which will start an exchange.

When the responding node receives a message, it enters the receiving state,
logically.  Note, though, that some implementations will pass messages
belonging to different exchanges, and even to different services, across the
same shared address space, so a responding node may not actually know
whether it is going to respond to a given message until it processes the
message to the point of identifying its role.

3.4 State Transitions, Soliciting Node

Constructing message
 - Sending, if message construction completes normally
 - Error, if it does not

Sending
 - Listening, if transmission completes normally
 - Error, if it does not

Listening
 - Receiving, for each response received
 - Idle, if Termination Condition is fulfilled
 - Error, if errors occur

Receiving
 - Processing, for each response or fault received normally
 - Idle, if Termination Condition is fulfilled
 - Fault, if a response cannot be received normally
 - Error, if errors occur

Processing
 - Listening, if processing is successful and Termination Condition is
unfulfilled
 - Idle, if Termination Condition is fulfilled
 - Fault, if a response cannot be processed
 - Error, if errors occur

Fault
 - Listening, if Termination Condition is unfulfilled
 - Idle, if Termination condition is fulfilled

Error
 - Idle, if the processor is still operable
 - Initializing, otherwise

3.5 State Transitions, Responding Node

Listening
 - Receiving, when a solicitation message is received
 - Error, if errors occur

Receiving
 - Processing, if the solicitation message is received normally
 - Fault, if it is not
 - Error, if errors occur

Processing
 - Constructing message, if processing of the solicitation message is
successful and a response is to be returned
 - Listening, if processing of the solicitation message is successful, but
no response is to be returned
 - Fault, if processing of the solicitation message is unsuccessful
 - Error, if errors occur

Constructing message
 - Sending, if message construction is successful
 - Fault, if it is not
 - Error, if errors occur

Sending
 - Listening, if message transmission is successful
 - Fault, if it is not
 - Error, if errors occur

Fault
 - Listening

Error
 - Listening, if processor is still operable
 - Initializing, otherwise

4. Fault Handling

During the operation of the Solicit-Response MEP, the participating nodes
may encounter errors or generate application-level faults.

If an error occurs which should not or cannot be communicated to partners in
the exchange, it is considered an error, and is not reported.  It should be
communicated to the administrator of the processor.

If an error occurs which ought to be communicated with a partner in the
exchange, it is considered a fault, and use should be made of protocol-level
or application-level facilities to report it.  If the fault is protocol
related, then protocol-level facilities should be used.  If the fault is
application related, then application-level facilities should be used (if
they exist), but protocol-level facilities may be used if no
application-level facilities are defined (almost all protocols define fault
handling).

A fault is always sent only to a single other node.  If a soliciting node
faults while processing the response from a particular responding node, the
fault should be dispatched to the appropriate responding node.  If a
responding node faults while processing the solicitation message, it should
send the fault to the soliciting node.

Fault generation actually involves the states "Constructing message" (where
the message is a fault, but may not be an application-level message) and
"Sending".  State transitions demonstrate the next step after successful
transmission of the fault message.  If an error or fault occurs during the
construction or transmission of the fault message, it must not be reported;
instead, the fault message is silently discarded and the processor moves to
its next state.


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Friday, 17 January 2003 15:03:51 UTC