Re: Solicit-Response MEP (abstract output-input MEP)

Jean-Jacques,

The referred-to message is a framework for constructing abstract MEPs, it does not contain any.  In coordination with Don, my procedure in defining the abstract MEP for output-input was as follows:

1. grab the SOAP Request/Response MEP
2. remove references to SOAP
3. change the "state" descriptions, since the ones in SOAP R/R are ridiculous (IMO)
4. modify for output-input instead of input-output

Don's abstract MEP for Request/Response is expected to follow steps 1 to 3.

In fact, the SOAP MEPs are largely abstract, except that they say "SOAP" where they could say something more general.  So it doesn't take much to make them abstract.  There's a large overlap, of course, but that implies that the abstracts should carry the weight, and the SOAP MEPs be defined in terms of the abstracts, not that the abstracts should carry less information.  Or so I believe.

Hope that helps explain.

Amy!
On Mon, 20 Jan 2003 13:06:44 +0100
"Jean-Jacques Moreau" <jean-jacques.moreau@crf.canon.fr> wrote:

> Amy,
> 
> In some sense, a quick glimpse at this gives me the impression 
> that your MEP is actually less "abstract" than any of the SOAP 
> MEPs. Do we really need the extra states (idle, constructing, 
> parsing, fault, error) and properties? Personnally, I'd have gone 
> for a description similar to Don's[1]; but maybe I am missing 
> something?
> 
> Jean-Jacques.
> 
> [1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0022.html
> 
> Amelia A. Lewis wrote:
> > 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 Monday, 20 January 2003 09:46:12 UTC