RE: Draft language on MEPs, synchronous, and asynchronous.

Geoff,

Your "definition" of synchronous/asynchronous is generic enough that should accommodate most interpretations (which is a positive, given the difficulties we had before coming to a common agreement).

The only part that concerns me is the statement "Other MEPs allow messages to be sent without precise sequencing, and these are described as "asynchronous"".
The statement seems to exclude important cases where messages are exchanged using a precise sequencing (e.g. request-response) but in such a way that the receiver does not have to be up at the time the submitter sends the message, or the submitter does not have to wait until the receiver has a response ready and can just collect the response later (cases that are usually classified as asynchronous).

In any case, I would rather go ahead with your proposed solution rather than spending other weeks debating the issue. Someway I have the feeling that Web services users will happily do their synchronous and asynchronous exchanges without waiting for our Glossary definition first ...

Ugo

> -----Original Message-----
> From: Geoff Arnold [mailto:Geoff.Arnold@Sun.COM]
> Sent: Thursday, May 01, 2003 10:30 AM
> To: www-ws-arch@w3.org
> Subject: Draft language on MEPs, synchronous, and asynchronous.
> 
> 
> 
> Apologies for the delays: clearly the result of an asynchronous
> message pattern!
> 
> 
> 
> Draft language for the WSA Glossary on Message Exchange
> Patterns, Synchronous MEPs, and Asynchronous MEPs.
> 
> In general, my objective is to beef up the MEP concept, to tie
> "synchronous" and "asynchronous" to MEPs, and to note that
> they are really just informally descriptive terms. I've incorporated
> comments from Chris Ferris and others, but any problems are due to me.
> ----------------------------------------------------------------------
> 
> Asynchronous Message Exchange Pattern
> See discussion under Message Exchange Pattern
> 
> -------------------------------------------------
> 
> Synchronous Message Exchange Pattern
> See discussion under Message Exchange Pattern
> 
> -------------------------------------------------
> 
> Message Exchange Pattern (MEP)
> [Derived from 
> http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soapmep ]
> A MEP is a template that establishes a pattern for the exchange of 
> messages
> between SOAP nodes. A MEP MAY be supported by one or more underlying 
> protocol
> binding instances.
> 
> This section is a logical description of the operation of a 
> MEP. It is 
> not
> intended to describe a real implementation or to imply that a real
> implementation needs to be similarly structured.
> 
> In general the definition of a message exchange pattern:
>    * Is named by a URI.
>    * Describes the life cycle of a message exchange conforming to the 
> pattern.
>    * Describes the temporal/causal relationships of multiple messages 
> exchanged
>      in conformance with the pattern.
>    * Describes the normal and abnormal termination of a 
> message exchange
>      conforming to the pattern.
> 
> Underlying protocol binding specifications can declare their support 
> for one or
> more named MEPs.
> 
> [New language]
> In principle, MEPs may be arbitrarily complex, and may include various
> temporal relationships between messages.  In practice, there 
> is a small 
> number
> of patterns for which the temporal relationships are well (if 
> informally)
> understood. MEPs which describe closely coupled, or lock-step 
> interactions
> are frequently referred to as "synchronous". Examples include 
> RPC-style
> request-response interactions and some kinds of transactional 
> exchanges.
> Other MEPs allow messages to be sent without precise sequencing, and 
> these
> are described as "asynchronous". Examples include a flow of 
> sensor event
> messages which need not be individually acknowledged, and an 
> auction in 
> which
> parties may submit bids at any time during the auction.
> 
> The terms "synchronous" and "asynchronous" are descriptive, and do
> not correspond precisely to properties of MEPs. Occasionally the
> terms may be associated with particular message transport features,
> such as the re-use of a session. While specific implementations may
> support such notions, a dependency on such a feature would violate
> protocol independence, and therefore be problematic.
> 
> Many (most?) web services do not use published MEP's, but instead rely
> on more or less informal patterns and techniques. In such cases, the
> terms "synchronous" and "asynchronous" may be used to indicate the
> type of informal pattern being used. They may also indicate whether
> or not coordination and synchronization techniques such as correlation
> data and particular transport bindings are to be used.
> 
>

Received on Thursday, 1 May 2003 14:31:20 UTC