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

Well, it does seem a bit like a very elaborate and subtle way of giving
up on the idea of defining synchronous and asynchronous.  If we accept
this approach, that might suggest eliminating these words from the
glossary entirely.  I believe, however, that this would be undesirable
and possibly even cruel, since the terms are liberally used in various
documents and we have definitely proved that different people in the WG
understand the words to mean different things.  I think, under those
circumstances, the words either need to be rooted out of all documents
or put in the glossary.  I suppose, however, that the glossary can
simply refer to the discussion of MEP's, which then sort of says that
synchronous and asynchronous are to be understood loosely, perhaps as
meta-concepts or poetic constructions I suppose.

Somehow this whole approach strikes me as less than optimal, but I
certainly am willing to accept less-than-optimal solutions in the
pragmatic name of getting-on-with-it.  And I must admit that for a
less-than-optimal solution this one is certainly implemented in a fine
style.

-----Original Message-----
From: Geoff Arnold [mailto:Geoff.Arnold@sun.com] 
Sent: Thursday, May 01, 2003 12:30 PM
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:50:15 UTC