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

Re: Second STRAW POLL on Synchronous/Asynchronous

From: David Booth <dbooth@w3.org>
Date: Tue, 18 Mar 2003 21:18:24 -0500
Message-Id: <5.1.0.14.2.20030318211431.02dc2fe8@localhost>
To: www-ws-arch@w3.org

Oops, I didn't have the "Reply-to" field set properly when I sent that 
out.  It should be correct on this one, but please verify it: 
member-wsa-ballots@w3.org.  Thanks.

At 04:19 PM 3/18/2003 -0500, you wrote:

>SECOND STRAW POLL ON SYNCHRONOUS/ASYNCHRONOUS
>
>The purpose of this straw poll is to help the working group converge
>on definitions for "synchronous" and "asynchronous".  Again, this is
>a straw poll, so the results are merely informative -- not binding.
>Any decision will be made by the group as a whole.
>
>This poll includes 3 new proposed wordings extracted from the mailing
>list, along with the top 3 definitions from the previous poll -- 6 choices
>in all.  It also includes a "cannot live with" voting option.
>
>DEADLINE
>Ballots must be submitted by Thursday March 20 at 23:00 EST (UTC-5) (
>http://www.timeanddate.com/worldclock/fixedtime.html?day=20&month=3&year=2003&hour=23&min=0&sec=0&p1=43 
>)
>
>HOW TO VOTE
>Erase everything above the top "-=-=-=-" line and erase everything
>below the bottom "-=-=-=-" line.  Do not erase anything between these
>lines.
>
>Indicate your top three choices.
>In the brackets next to your most preferred choice, place a 1.  Place
>a 2 in the brackets next to your next choice.  Continue till
>you use 3 for your last choice.  Leave other choices
>blank.  Start with 1, don't skip any numbers, don't repeat.
>
>If you CANNOT LIVE WITH a particular choice, place a -1 in the brackets.
>You may indicate -1 for as many choices as necessary.
>
>Then mail the ballot to: member-wsa-ballots@w3.org .  DO NOT SEND YOUR
>BALLOT TO THE PUBLIC LIST.  Just Replying to this
>message should work, but check the "To:" line.  Don't worry about spacing
>of the columns or any quote characters (">") that your reply inserts.
>
>-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
>synchronous Ballot    <FB-sync2> (Don't remove this marker)
>
>[1-3]  Choice
>-----------------------------------------------------------------------
>[   ] anne-1    (see definition below)
>[   ] mikec-2   (see definition below)
>[   ] walden-2  (see definition below)
>[   ] geoff-1   (see definition below)
>[   ] ugo-2c    (see definition below)
>[   ] ferris-1  (see definition below)
>-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
>
>Anything else may be rejected by the vote counting program.
>You should see your vote in 
>http://lists.w3.org/Archives/Member/member-wsa-ballots/
>Only one vote per person.
>
>
>==================================================================
>=====================  Candidate Definitions =====================
>==================================================================
>
>Definition anne-1
>http//lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0134.html
>Synchronous
>An interaction (one-way, two-way, or multi-way) is synchronous if the 
>sender and receiver must communicate at the same time (the receiver 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).
>
>--------
>Definition mikec-2
>http//lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0146.html
>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 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.
>]]
>
>--------
>Definition walden-2
>http//lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0114.html
>Synchronous
>A request/response interaction is said to be synchronous when the request 
>and response are chronologically coupled. In other words, the client agent 
>has to "wait" for the response once it issues the initial request. The 
>exact meaning of "wait" depends on the characteristics of the client agent 
>(including the transfer protocol it uses). Examples include waiting for 
>the response in a different thread, on a different socket or end-point, or 
>by polling the server.
>
>Asynchronous
>A request/response interaction that does not meet the constraints of a 
>synchronous interaction (above) is said to be asynchronous.
>
>--------
>Definition geoff-1
>http://lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0029.html
>Synchronous
>A message exchange pattern (MEP) is a formal description of how messages
>are exchanged between two or more parties in support of some application
>purpose. The pattern may define a single message sequence, or may
>correspond to a "family" of sequences by including repeated or nested
>sequences. An MEP is synchronous if the specification of the message
>sequence(s) includes elements in which the transmission of a message
>is dependent on either (a) the reception of some other message(s), or
>(b) coordination based on a common clock. An MEP is asynchronous if it
>includes no such dependencies.
>
>--------
>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 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.
>
>
>[End]
>
>
>
>--
>David Booth
>W3C Fellow / Hewlett-Packard
>Telephone: +1.617.253.1273

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Tuesday, 18 March 2003 21:18:46 GMT

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