- From: Assaf Arkin <arkin@intalio.com>
- Date: Thu, 27 Feb 2003 14:26:08 -0800
- To: "David Orchard" <dorchard@bea.com>, <www-ws-arch@w3.org>
- Message-ID: <IGEJLEPAJBPHKACOOKHNMEFMDEAA.arkin@intalio.com>
RE: Sync Definition #2 (corrected) -----Original Message----- From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On Behalf Of David Orchard Sent: Thursday, February 27, 2003 8:42 AM To: www-ws-arch@w3.org 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. What's wrong with this definition? Let's say I have a flow of control that begins by sending a request and ends by sending a response. That flow of control is synchronous, it would wait for the response. My implementation can do multiple flows of control in parallel talking to different services (or even the same one) at the same time. But each flow that starts with a request and ends with a response will synchronize with some other flow that also starts with the request and ends with a response (though one is send/receive and one is receive/send). A flow that is described by an input and an output derived from the operation definition is after all doing nothing but waiting for the response. Says nothing about other flows going on in parallel, even as part of a larger parent flow. arkin 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.
Received on Thursday, 27 February 2003 17:27:54 UTC