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 Saturday, 22 February 2003 19:38:17 UTC