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 13:29:35 UTC