RE: Revised: Draft language on MEPs, synchronous, and asynchronou s.

I like the definition of MEP. I don't understand what the reference to "life
cycle" means, though.

The descriptions of synchronous  and asynchronous are, however, vague. 
They certainly do not qualify as definitions.

I do appreciate your effort in considering all possibilities, and play nice
to all nuances. There is another obvious way.

The concept of a message and a communication channel to send the message
are fundamental to web and web services (and any distributed environment).
The synch/asynch descriptions could be made a lot more tighter, and actually
be made
definitions by using these concepts.


Regards, 
-Suresh 
Sterling Commerce (on loan to RosettaNet) 
469 524 2676 (O), 469 323 0234 (Cell) 



-----Original Message-----
From: Geoff Arnold [mailto:Geoff.Arnold@sun.com]
Sent: Friday, May 02, 2003 7:49 PM
To: www-ws-arch@w3.org
Subject: Revised: Draft language on MEPs, synchronous, and asynchronous.



The following is a redraft of the language that I sent out on May 1.
I have made the following changes:

(1) I've included Mike Champion's suggestion.
(2) I've added the note that (per Ugo) the terms "synchronous"
     and "asynchronous" are sometimes perfectly precise, but that
     such precision does not map well into the Web Services domain.
(3) I have added the warning about not relying on these terms in
     any normative specifications.
(4) I have "refactored" the content, so that the MEP entry is not
     dominated by the sync/async discussion.

Just to be clear: the intent is that the following three blocks of
text are to be XMLized as necessary and inserted into the glossary
as three distinct entries: "Asynchronous", Message Exchange Pattern",
and "Synchronous". All appropriate hyperlink q.v's should be
inserted.


----------------------------------------------------------------------

Asynchronous

In the context of Web Services, the term "asynchronous" is used
informally to describe certain Message Exchange Patterns.
See Synchronous for a more detailed treatment of this topic.


-------------------------------------------------

Message Exchange Pattern (MEP)
[EDITORS NOTE: 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.

[EDITORS NOTE: New language, not found in SOAP 1.2]

The terms "synchronous" and "asynchronous" are sometimes used to
characterize MEPs. Such usage is informal, and it is recommended that
W3 recommendations should not rely on these terms. See Synchronous
for a more detailed discussion of this.

-------------------------------------------------

Synchronous
In the context of Web Services, the term "synchronous" is used
informally to describe certain Message Exchange Patterns.

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 temporally 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.

It is also worth noting that in some computing platforms or message
transport systems the terms "synchronous" and "asynchronous" are
perfectly well defined.  For example many APIs include "asynchronous
I/O" support, and certain message-oriented middleware systems
offer synchronous and asynchronous notification and delivery
modes. However, web services are defined as platform- and transport-
independent, and relying on implementation-specific terms is
likely to result in confusion.

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" are sometimes used to indicate 
the
type of informal pattern being used. They may indicate whether
or not coordination and synchronization techniques such as correlation
data and particular transport bindings are to be used.

In view of the informal way that the terms are used, it is recommended 
that
W3 documents should not rely upon the use of "synchronous" or 
"asynchronous"
in any normative specification.

Received on Sunday, 4 May 2003 08:20:54 UTC