- From: Martin Chapman <martin.chapman@oracle.com>
- Date: Mon, 24 Feb 2003 11:06:43 -0800
- To: "'David Orchard'" <dorchard@bea.com>, <www-ws-arch@w3.org>
David, I certainly this a while ago and concluded that it didn't help much. What does "A sender sends a message asynchronously to a receiver expecting some response at a later time" mean. Doesn't really define asynchronous does it! Waiting for "some reponse at a later point in time" is true for all request/response interactions. Martin. > -----Original Message----- > From: www-ws-arch-request@w3.org > [mailto:www-ws-arch-request@w3.org] On Behalf Of David Orchard > Sent: Saturday, February 22, 2003 10:26 PM > To: 'Walden Mathews'; www-ws-arch@w3.org > Subject: RE: Snapshot of Web Services Glossary > > > > Perhaps you should READ the W3C Web services architecture > Usage Scenarios document? Scenario S070 is asynchronous > messaging [1]. This is used by the Use Case #2 [2]. > > Cheers, > Dave > > [1] http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/#S070 > [2] http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/#edi > > > > > -----Original Message----- > > From: www-ws-arch-request@w3.org > [mailto:www-ws-arch-request@w3.org]On > > Behalf Of Walden Mathews > > Sent: Saturday, February 22, 2003 4:38 PM > > To: Ugo Corda; Cutler, Roger (RogerCutler); www-ws-arch@w3.org > > Subject: Re: Snapshot of Web Services Glossary > > > > > > > > Sounds like what you really want is a definition of 'asynchronous', > > since that's the attribute sought, and then perhaps define > > 'synchronous' as the > > negation of the other. > > > > I'm not sure, though. What other "use cases" do we have > for the term > > 'synchronous'? How did the term get on the glossary list? > > > > Walden > > > > ----- Original Message ----- > > From: "Ugo Corda" <UCorda@SeeBeyond.com> > > To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>; > > <www-ws-arch@w3.org> > > Sent: Saturday, February 22, 2003 12:31 PM > > Subject: RE: Snapshot of Web Services Glossary > > > > > > > > > > The way I have seen the concept of asynchronous Web services being > > understood most of the times is in term of client expectations > > regarding the interaction with a particular Web service. The > > expectations are such that > > the client can feel free to issue a request to the service at > > any time, > > regardless of whether the server is busy, is down at the > > present time, etc. > > After sending the request, the client can go about its other > > business, can > > go off line, can crash, etc. Still the client is confident > > that, some time > > after the server has been able to examine the client's > > request and send a > > response back, it will be able to get the server's response > > (assuming it - > > the client - is back online). Exactly how the underlying > > framework satisfies > > these expectations is implementation dependent (multiple threads, > > store-and-forward, queuing, etc.). > > > > > > Synchronous is any client-server interaction that cannot > fulfill the > > expectations mentioned before. > > > > > > Ugo > > > > > > > -----Original Message----- > > > > From: Cutler, Roger (RogerCutler) > > > > [mailto:RogerCutler@chevrontexaco.com] > > > > Sent: Friday, February 21, 2003 7:10 PM > > > > To: Cutler, Roger (RogerCutler); Assaf Arkin; David > Booth; Martin > > > > Chapman; www-ws-arch@w3.org > > > > Cc: Hugo Haas > > > > Subject: RE: Snapshot of Web Services Glossary > > > > > > > > > > > > > > > > Oh, perhaps I should express an opinion about the > > alternatives. My > > > > druthers, for what they are worth, is that the "blocking" > > > > definition is the least desirable. I base this on two factors: > > > > 1)I don't really know > > > > what it means in a world where applications can easily > > have multiple > > > > threads; 2)It does not seem to have any aspect of > timeliness, or > > > > shortness of time, in it -- and my intuitive understanding of > > > > synchronous is that it has something to do with things > > happening in a > > > > timely manner. I personally like the ones that are based > > on how fast > > > > things happen the best. > > > > > > > > That's my opinion, but I am MORE than willing to accept > any of the > > > > approaches to the concept, as long as it is just one definition. > > > > > > > > -----Original Message----- > > > > From: Cutler, Roger (RogerCutler) > > > > Sent: Friday, February 21, 2003 9:05 PM > > > > To: 'Assaf Arkin'; David Booth; Martin Chapman; > www-ws-arch@w3.org > > > > Cc: 'Hugo Haas' > > > > Subject: RE: Snapshot of Web Services Glossary > > > > > > > > > > > > Yeah, this is the approach to synchronous that I recall > impressed > > > > me as being MOST different from the others. I recall > that there > > > > was a considerably more formal definition along these lines > > some months ago. > > > > Well, if not more formal at least longer, but along the > same lines > > > > with the concept of agreeing about the time of day being the > > key factor. > > > > > > > > OK, there is the "blocking" thing, as in David's > > definition, there is > > > > this thing with agreeing about timing of clocks, and > > there have also > > > > been other definitions that were pretty formal but which > > ran along the > > > > lines of "how soon" things happen. > > > > > > > > IMHO there are at least three completely different > > understandings of > > > > what synchronous means floating around. They all sound > > really good to > > > > me, but they are not the same. I would REALLY like it > if we could > > > > agree on one of them and make sure that when we use the word we > > > > agree that we > > > > are using the word in that sense. Or, perhaps we could > > subset them > > > > somehow, as in synchronous(1) ... Synchronous(N). > > > > > > > > -----Original Message----- > > > > From: Assaf Arkin [mailto:arkin@intalio.com] > > > > Sent: Friday, February 21, 2003 12:26 PM > > > > To: David Booth; Martin Chapman; www-ws-arch@w3.org > > > > Cc: 'Hugo Haas' > > > > Subject: RE: Snapshot of Web Services Glossary > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: www-ws-arch-request@w3.org > > > > [mailto:www-ws-arch-request@w3.org]On > > > > > Behalf Of David Booth > > > > > Sent: Friday, February 21, 2003 10:09 AM > > > > > To: Martin Chapman; www-ws-arch@w3.org > > > > > Cc: 'Hugo Haas' > > > > > Subject: RE: Snapshot of Web Services Glossary > > > > > > > > > > > > > > > > > > > > At 04:35 PM 2/20/2003 -0800, Martin Chapman wrote: > > > > > >hmmm don't like the defn of synchronous: > > > > > > > > > > I struggled with this one, and I'm not sure my proposed > > wording is > > > > > ideal, but what I was trying to do was more clearly > > differentiate > > > > between > > > > > synchronous and asynchronous. The old definition was > > very vague. > > > > > > > > > > Somehow we need to convey the idea that with "synchronous" > > > > > interactions the parties are synchronized in some way. > > (!) This > > > > > could mean "at the same time", but in the case of two > > communicating > > > > > parties it generally means the > > > > > sending party waits for the receiving party to do something > > > > before the > > > > > sending party continues. Thus, they are "synchronized". I > > > > > couldn't figure out any better way to precisely > capture this. > > > > > Any ideas? > > > > > > > > Define that operation involves sending/receiving at initiator > > > > site, and receiving/sending at respondent site. Define > "time" to > > > > be > > bound by T1 > > > > (lower) and T2 (upper). I assume we can all agree to that. > > > > > > > > Given just sending and receiving primitives (e.g. TCP > > > > send()/receive()), initiator and respondent can agree on T1/T2 > > > > after concluding operation. > > > > With just these two communication primitives they can > > > > synchronize their > > > > clock within some resolution (but don't look for atomic > > clock type of > > > > synchronization here). > > > > > > > > > > > > > I agree that store-and-forward would NOT be > > synchronous, but I don't > > > > > see store-and-forward as the opposite of direct > communication. > > > > > Communication can certainly be indirect (i.e., go through > > > > > intermediaries) but still be synchronous. So although > > synchronous > > > > > communication is often direct, I don't see that as a > > distinguishing > > > > > characteristic. > > > > > > > > An interaction can be synchronous even if it uses some > > > > store-and-forward mechanism, even if both request and > response are > > > > stored > > and forwarded. > > > > > > > > Test for synchronisity of interaction is something like that: > > > > > > > > If initiator sent request at time T1 then it can conclude that > > > > respondent did not start performing interaction before > time T1 If > > > > initiator received request at time T2 then it can conclude that > > > > respondent did not continue performing interaction after > > time T2 (and > > > > vice versa) > > > > > > > > You can clearly see this is not true for asynchronous > interaction. > > > > > > > > arkin > > > > > > > > > > > > > > >and > > > > > >the fact that the reply (if any) comes back on the same > > > > communication > > > > > >channel as the request. > > > > > > > > > > Interesting thought. Must that always be true? I > > could certainly > > > > > imagine an input-output operation in which the input uses one > > > > > communication channel and the output uses another. > So again, I > > > > > don't see this as a distinguishing characteristic of > synchronous > > > > > communication. > > > > > > > > > > Anyone else have other suggestions for this definition? > > > > > > > > > > > > > > > -- > > > > > David Booth > > > > > W3C Fellow / Hewlett-Packard > > > > > Telephone: +1.617.253.1273 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Received on Monday, 24 February 2003 14:07:11 UTC