W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2003

RE: Compendium of "synchronous" definitions

From: Cutler, Roger (RogerCutler) <RogerCutler@ChevronTexaco.com>
Date: Mon, 3 Mar 2003 14:25:42 -0600
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E01817D45@bocnte2k3.boc.chevrontexaco.net>
To: "David Booth" <dbooth@w3.org>, "Francis McCabe" <fgm@fla.fujitsu.com>
cc: www-ws-arch@w3.org

Frank-2 is extremely interesting.  It seems to me that if it is true,
and I am by no means convinced that everybody would agree on that -- but
in the unlikely event that everybody DID agree it seems to me that it
could be appended to almost any other definition and might end up more
useful than the definition itself.

I guess that comment makes it clear that I don't really think that
Frank-2 is actually an adequate definition on its own.

The more I think about Frank-2 the more interested I get.  Note that it
says "may assume".  That doesn't say that what it is assuming need be
true.  Only that the rules of the game are sort of that it says up
front, "If this happens, I'm going to conclude that.  Ball's in your
court if you don't like that."  At least, that's my understanding.

As a physicist (and I am) I object to Frank-1.  "Simultaneous" is a
difficult concept and I see no reason to mess around with that
particular trout.  I think that Frank-1 is clearly a definition that is
appropriate in a different setting.

-----Original Message-----
From: David Booth [mailto:dbooth@w3.org] 
Sent: Monday, March 03, 2003 12:48 PM
To: Francis McCabe
Cc: www-ws-arch@w3.org
Subject: Re: Compendium of "synchronous" definitions



And let's call your second definition "frank-2":

Definition frank-2
http://lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0023.html
Synchronous activity
An activity involved in a synchronous rendezvous may assume that the 
rendezvous is complete for both sides if it 's side completes.



At 09:10 AM 3/3/2003 -0800, Francis McCabe wrote:
>David:
>   I would appreciate it if you could add mine to the long list:
>
>a straightforward definition of synchronous:
>
>A rendezvous of two activities is synchronous if they complete 
>simultaneously.
>
>The language, if not the definition, comes from Communicating 
>Sequential
>Processes.
>
>One might try to sharpen this up by defining simultaneously in terms of
>clocks etc. But that is not necessary; because an alternative view of
this 
>definition is:
>
>An activity involved in a synchronous rendezvous may assume that the
>rendezvous is complete for both sides if it 's side completes.
>
>Frank
>
>
>On Thursday, February 27, 2003, at 04:58  PM, David Booth wrote:
>
>>
>>Here are the proposed definitions of "synchronous" that I've collected
>>from the list.  If I've missed any, it was only due to volume of
messages 
>>I was trying to sort through -- not due to any desire to slight anyone
-- 
>>so please accept my apology.  If that happened, and you do feel that 
>>(yet) another definition should be considered, please re-submit it to
the 
>>list by reply message and give it a unique name as I've done with the 
>>others below, so that we can be clear when in referring to them.
>>
>>          ==============================================
>>
>>Definition dbooth-2
>>[This is my attempt at combining the main concepts I've seen in 
>>others.] Synchronous interaction An interaction is synchronous if the 
>>parties are involved in the interaction at the same time and the 
>>interaction carries an expectation of immediate processing.  A one-way

>>interaction is synchronous if successful message delivery implies that

>>the message either has been processed by the receiver or is actively 
>>being processed.  A round-trip or more complex interaction is 
>>synchronous if the initiator pauses some of its processing to wait for

>>the interaction's constituent messages to be processed.  In a 
>>round-trip interaction, the request and response are often sent over 
>>the same communication channel.
>>
>>----
>>Definition dbooth-1 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0222.html
>>Property of an interaction whose results are directly following the
>>interaction. An interaction between an initiator and a respondent is 
>>synchronous if the initiator blocks some further processing while it 
>>waits for a corresponding action, response or acknowledgement from the

>>respondent.
>>
>>----
>>Definition ugo-2c 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0386.html
>>Asynchronous: A request/response interaction is said to be 
>>asynchronous
>>when the request and response are chronologically decoupled. In other 
>>words, the client agent does not have to "wait" for the response once
it 
>>issues the initial request. The exact meaning of "not having to wait" 
>>depends on the characteristics of the client agent (including the 
>>transfer protocol it uses). Examples include receiving the response on
a 
>>different thread, on a different socket, on a different end-point, by 
>>polling the server, etc.
>>
>>Synchronous: The opposite of asynchronous.
>>
>>----
>>Definition daveo-1 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0432.html
>>synchronous
>>a programmatic flow of control on the sender effectively does nothing 
>>but
>>wait for a response after sending it's request
>>
>>----
>>Definition daveo-2 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0432.html
>>synchronous
>>the request and response flow forwards and backwards over the same
>>virtual connection between the sender and receiver.
>>
>>----
>>Definition moberg-1 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0343.html
>>A web service response is said to be synchronous iff it is returned 
>>using
>>the same network connection used in sending the request to which it is
a 
>>response. (This implies that only one URL would be needed for 
>>request-response MEP when the response is synchronous and uses a
transfer 
>>protocol that has URLs. It also implies that the request and response 
>>occur within the interval of time that the network connection exists. 
>>Also, there is overhead in setting up only one TCP connection when TCP
is 
>>used, and since we are talking about IP _connections_ that will be
almost 
>>always the case.)
>>
>>A web service response is said to asynchronous iff it is returned 
>>using a
>>network connection that is distinct from that used for sending the 
>>request to which it is a response. (Implications: Two URLs are needed
to 
>>configure a request-response MEP when the response is ==>asynchronous.

>>The response connection may occur while the request connection is
still 
>>open or after it is closed. For TCP-based transfer protocols, two 
>>connection setups will be needed.)
>>
>>----
>>Definition assaf-3 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0354.html
>>A transport is synchronous iff the request is returned using the same
>>network connection.
>>
>>----
>>Definition cutler-1 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0358.html
>>Synchronous: a request/response exchange that is correlated by virtue 
>>of
>>a serialized, sequenced exchange of messages between requestor and 
>>respondant, typically over the same socket or stream.
>>
>>Asynchronous: a request/response exchange that is not synchronous,
>>typically relying on some mechanism such as Message-ID within the 
>>messages to correlate the request and response messages.
>>
>>----
>>Definition ferris-1 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0437.html
>>synchronous message exchange (applies to oneway as well as
>>request/response) requires that both sender and receiver, or initiator

>>and respondant, processes are running/active at the same time as the 
>>exchange takes place. In the case of request/response, the exchange is

>>synchronous if both sender and receiver remain in the running/active 
>>state for both the request and response.
>>
>>asynchronous message exchange (also applies to oneway or request
>>response) does not require, but does not preclude, that both sender
and 
>>receiver, or initiator and respondant, processes are running/active at

>>the same time as the exchange takes place. It typcally requires some
form 
>>of mediation between the sender and receiver such as a message queue.
>>
>>----
>>Definition mikec-1 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0318.html
>>(Taken from
>>http://whatis.techtarget.com/definition/0,,sid9_gci213080,00.html ?)
>>In program-to-program communication, synchronous communication
requires 
>>that each end of an exchange of communication respond in turn without 
>>initiating a new communication. A typical activity that might use a 
>>synchronous protocol would be a transmission of files from one point
to 
>>another. As each transmission is received, a response is returned 
>>indicating success or the need to resend. Each successive transmission
of 
>>data requires a response to the previous transmission before a new one

>>can be initiated. Synchronous program communication is contrasted with

>>asynchronous program communication.
>>
>>----
>>Definition walden-1 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0326.html
>>Synchronous, then, places a constraint on a response such that the
>>response must be received within a strictly or loosely defined time 
>>quantum (strict vs lax synchrony), or else the exchange fails.
>>Asynchronous differs in that no amount of elapsed time signals the 
>>failure of the exchange.
>>
>>----
>>Definition assaf-1 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0321.html
>>An operation is synchronous if both service requester and service 
>>provider engage will always engage in that operation at the same time.
>>
>>----
>>Definition assaf-2 
>>http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0321.html
>>An interaction is synchronous if activities demarcated by that 
>>interaction will always be performed at the same time.
>>
>>
>>
>>
>>--
>>David Booth
>>W3C Fellow / Hewlett-Packard
>>Telephone: +1.617.253.1273
>
>--
>David Booth
>W3C Fellow / Hewlett-Packard
>Telephone: +1.617.253.1273
Received on Monday, 3 March 2003 15:34:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:16 GMT