RE: Snapshot of Web Services Glossary

If the current documents for use cases and scenarios are not sufficiently
motivating, perhaps you could suggest some text for the documents?  I know
that you have been actively involved in writing use case documents, and have
experience in writing about asynchrony, so it shouldn't be hard..

Cheers,
Dave

> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Monday, February 24, 2003 11:07 AM
> To: 'David Orchard'; www-ws-arch@w3.org
> Subject: RE: Snapshot of Web Services Glossary
>
>
> 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 Wednesday, 26 February 2003 11:52:54 UTC