RE: Friendly amendment to friendly amendment (was RE: Friendly amendment #2c [Re: Straw poll on "synchronous" definitions]

Mike,
This sounds good to me. At least good enough that we can put this issue behind for a while (not for good, probably, because this seems to have all the characteristics of a permathread).
 
(By the way, this type of threads remind me a little bit of the medieval philosophers who spent inordinate amounts of time discussing how many angels could fit on top of a pin). 
 
I also find pretty amazing that so far over this weekend the number of messages dedicated to this subject (which has already been discussed for weeks) is actually higher than the number of messages about the Reliability issue. In other words, a glossary definition still gets more attention than yet another macroscopic example of industry divergence (which, in my view, further undermines the whole basic idea behind Web services, i.e. industry unification). Thinking about it, this approach could actually help solve the glossary issue once for all in a reasonable amount of time, in the sense that while these permathreads go on the industry can get so badly fragmented that people will drop the whole Web services idea and move on to the next big thing promising once again industry unification (hence getting rid of the need to define synchronous and asynchronous Web services).
 
Ugo

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@softwareag-usa.com]
Sent: Sunday, March 16, 2003 8:18 AM
To: www-ws-arch@w3.org
Subject: Friendly amendment to friendly amendment (was RE: Friendly amendm ent #2c [Re: Straw poll on "synchronous" definitions]


 

-----Original Message-----
From: Anne Thomas Manes [mailto:anne@manes.net]
Sent: Saturday, March 15, 2003 6:12 PM
To: Walden Mathews; Christopher B Ferris; www-ws-arch@w3.org
Subject: RE: Friendly amendment #2c [Re: Straw poll on "synchronous" definitions]


The biggest issue I have with Ugo's definition (and all the others) is that they tie synchrony with blocking versus non-blocking. Synchronous means "at the same time". Asynchronous means "not at the same time". Whether or not the sender has to wait idly for a response is a separate issue. 
 
An interaction (one-way, two-way, or multi-way) is synchronous if the sender and receiver must communicate at the same time (the reciever must be available to receive the message when the sender sends it). A one-way message is asynchronous if the sender and receiver do not need to communicate at the same time (the message may be stored and delivered at a later time).  

I must say that I like Anne's wording that synchronous means that "the receiver must be available to receive the message"  better than notions of blocking or simultaneity.  What about changing Ugo's suggestion to:
 
Asynchronous: A request/response interaction is said to be asynchronous
when the request and response are chronologically and procedurally decoupled. In other
words, the client agent can process the response at some indeterminate point in the future when its existence is discovered, for example, by polling, notification by receipt of another message, etc. 
 
Synchronous:  A request/response interaction is said to be synchronous when the client agent must be available to receive and process the response message from the time it issues
it issues the initial request until it is actually received or some failure condition is determined. The exact meaning of "available to receive the message" depends on the characteristics of the client agent (including the transfer protocol it uses); it may, but does not necessarily, imply tight time synchronization, blocking a thread, etc.