- From: Assaf Arkin <arkin@intalio.com>
- Date: Fri, 21 Feb 2003 09:49:11 -0800
- To: "Martin Chapman" <martin.chapman@oracle.com>, "'David Booth'" <dbooth@w3.org>, "'Hugo Haas'" <hugo@w3.org>, <www-ws-arch@w3.org>
> hmmm don't like the defn of synchronous: > > > >10. synchronous > >[[ > >Property of an interaction whose results are directly following the > >interaction. > >]] > >I suggest adding: > >[[ > >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. > >]] > > who/what is doing the blocking? This makes no senese in a context where > we don't talk about programming languages, middleware, OSs etc. > Properties of synchronous communications we can convey inthis space are > direct communication (i.e. not through store and forward) and > the fact that the reply (if any) comes back on the same communication > channel as the request. An operation involving an initiator and a respondent is synchronous if the operation involves the initiator and respondent at the same time. In other words, if I sends request to R (input of operation) and I receives response from R (output of same operation), I can tell when R performed the operation. I know of at least two client libraries in which the initiator application does not have to block waiting for the response. Although HTTP 1.1 will send the request and response on the same communication channel, other protocols may send the request and response on separate communication channels. arkin > > Martin.
Received on Friday, 21 February 2003 12:50:54 UTC