RE: Sync Definition #2 (corrected)

Appologies if these definitions have not already been proposed, the thread 
is simply too long for
me to catch up:)

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.

I believe that we could extend these definitions to whole conversations as 
well.

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624



"David Orchard" <dorchard@bea.com> 
Sent by: www-ws-arch-request@w3.org
02/27/2003 11:41 AM

To
<www-ws-arch@w3.org>
cc

Subject
RE: Sync Definition #2 (corrected)






What classifies as "wait for a response"?  I typically think of a 
synchronous definition as "a programmatic flow of control on the sender 
effectively does nothing but wait for a response after sending it's 
request".  And before everybody goes gaga over showing edge cases that are 
asynch that have flow of control, or multiple flows of control that are 
synch, that's not the real issue.  The point is that synchronicity 
typically has the notion of *something* blocking and waiting for the 
response. 
 
Another approach is to couple synchronicity with connections.  So 
synchronous is where the request and response flow forwards and backwards 
over the same virtual connection between the sender and receiver.  Of 
course, it's possible to have synch interactions over non-synch 
connections, which is why I think that synchronicity is more of a feature 
of program logic than bits on the wire.
 
Hey look, textual suggestion and only 8 sentences of prose.
 
Cheers,
Dave
-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On 
Behalf Of Assaf Arkin
Sent: Wednesday, February 26, 2003 10:42 PM
To: Walden Mathews; Ugo Corda; www-ws-arch@w3.org
Subject: RE: Sync Definition #2 (corrected)

I just love permutations ;-)
 
Seriously. In order to say that something is synchronous you need to say 
what it is that's synchronous.
 
The definition given below only describes a synchronous (request/response) 
operation but doesn't describe an asynchronous (input-only or output-only) 
operation, so it's only half way there. We still need to describe 
asynchronous operations.
 
And it describes the operation based on how the protocol works, which is 
interesting and important, but still says nothing about the operation 
itself. 
 
arkin
 
 -----Original Message-----
From: Walden Mathews [mailto:waldenm@optonline.net]
Sent: Wednesday, February 26, 2003 7:29 PM
To: Assaf Arkin; Ugo Corda; www-ws-arch@w3.org
Subject: Re: Sync Definition #2 (corrected)

Arkin,
 
I don't understand where your fascination with these permutations
is coming from.  I thought the goal was to define the two terms, one
definition each, and let it go at that (if possible).
 
Walden
----- Original Message ----- 
From: Assaf Arkin 
To: Ugo Corda ; www-ws-arch@w3.org 
Sent: Wednesday, February 26, 2003 3:51 PM
Subject: RE: Sync Definition #2 (corrected)

Actually, yours can be easily phrased in terms of mine:
 
A synchronous interaction (= reqeust/response) is communicated 
asynchronously when the request and response are chronologically 
decoupled. In other words ...
 
A synchronous interaction is communicated synchronoulsy if the reverse 
could be said.
 
Which of course begs the question, what about an asynchronous interaction. 
Say I just send a message but don't expect a response?
 
An asynchronous interaction (= send or receive) is communicated 
asynchronoulsy when the sender does not have to wait for the receiver to 
receive the message.
 
An asynchronous interaction is communicated synchronoulsy if the reverse 
could be said.
 
arkin
-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Wednesday, February 26, 2003 12:46 PM
To: Assaf Arkin; www-ws-arch@w3.org
Subject: RE: Sync Definition #2 (corrected)

Well, it's a matter of definitions, and evidently yours does not 
correspond to mine. I hope people will vote soon so that we can put this 
issue behind ...
 
Ugo
-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Wednesday, February 26, 2003 12:15 PM
To: Ugo Corda; www-ws-arch@w3.org
Subject: RE: Sync Definition #2 (corrected)

I think you have just defined a synchronous interaction (request/response, 
see formal definition) in terms of an asynchronous transport (i.e. one 
that does send and receive actions independently).
 
arkin
-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On 
Behalf Of Ugo Corda
Sent: Wednesday, February 26, 2003 7:36 AM
To: Ugo Corda; www-ws-arch@w3.org
Subject: RE: Sync Definition #2 (corrected)

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.