W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

RE: Snapshot of Web Services Glossary

From: Cutler, Roger (RogerCutler) <RogerCutler@chevrontexaco.com>
Date: Mon, 24 Feb 2003 15:31:10 -0600
Message-ID: <7FCB5A9F010AAE419A79A54B44F3718E01817D15@bocnte2k3.boc.chevrontexaco.net>
To: "Assaf Arkin" <arkin@intalio.com>, "Walden Mathews" <waldenm@optonline.net>, "Ugo Corda" <UCorda@SeeBeyond.com>, www-ws-arch@w3.org

OK, I think I get it.  Thanks.  It seems that the scope (if that is the
correct word) that one is considering is really important.

It looks to me like a relatively large number of people on this thread
are pretty much on the same page.  So can somebody suggest specific,
simple entries to put in the Glossary for "synchronous" and
"asynchronous" -- and whatever other terms might seem required?  And/or
some discussion for the document itself?

It doesn't seem to me that we can, in practice, avoid using these terms,
and given the complexity of this discussion it seems pretty clear to me
that we'd best not just use the terms without explanation.

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Monday, February 24, 2003 3:14 PM
To: Cutler, Roger (RogerCutler); Walden Mathews; Ugo Corda;
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 Cutler, Roger (RogerCutler)
> Sent: Monday, February 24, 2003 12:25 PM
> To: Walden Mathews; Ugo Corda; www-ws-arch@w3.org
> Subject: RE: Snapshot of Web Services Glossary
> That's a really good idea.  Using your suggestions from
> http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0300.html:
> If synchronous means "blocking", then it you block you block -- you 
> cannot create an unblocked interaction out of blocking interactions --

> so under that meaning you can't build an asynch out of synch's.
> If synchronous means solicited, then again I don't see how one can 
> combine solicited messages to create an unsolicited one.

It all depends on what you mean by interaction. Is interaction the
operation involving input-block-output? Then if it's synchronous, it's

But what if the interaction involves multiple operations over a period
of time. The interaction starts with the request operation and ends with
the response operation. So the interaction is synchronous. The first
operation may involve the request being sent but what you solicit is
just 'I've received it', and similarly for the second operation.

> If, however, synchronous means "relatively short time" (which most 
> people on this thread seem to think is not a good idea), then I guess 
> you can put together a bunch of messages that take a short time into a

> whole that takes a long time.  This seems, however, relatively trivial

> and maybe it illustrates why people don't seem to like the "short 
> time" approach.

Let's say node X sends two messages to node Y over a short period of
time. Is that a synchronous interaction?

> Even if you go to Mr. Arkin's rather formal definition which, if I 
> understand it, says that a message is synchronous if it is possible 
> for people on the two ends to agree what time it is -- it still seems 
> to me that if you compose a message out of a bunch of messages where 
> you know what time it is, in the composite it still should be possible

> to figure out what time it is.

Actually, just sending or receiving a message is insufficient. The whole
'what time is it?' is introduced to prove that it's insufficient to
synchronize by just sending one message. What you need are two messages
traveling in opposite directions one after the other. If you have two
messages travelling in opposite directions then they can both tell the
same time.

> Sooooo -- I am really wondering how one can make an asynchronous 
> message out of synchronous components.

By deciding what is the request and what is the response.

Let's say I have two operations:

op1 - request m1, response m2
op2 - request m3, response m4

Operation op1 is synchronous, you send a request and you receive a
response. Similar for operation op2.

Now let's three additional interactions:

in1 - request m1
in2 - response m3
in3 - request m1, response m3 (in1->in2)

Interaction in3 is synchronous: you send a request and you receive a
response. Perhaps you implement it using op1 and op2. In op1 you send
the request you value (m1) and you get some response (m2) that has no
meaning in that scope ('ok, I got it, I'll process it later').

You then wait to receive the response (m3) which you care about and send
back some other response (m4) that has no meaning ('thanks, I got it').

So in the context of that interaction, in1/op1 and in2/op2 are
asynchronous. But viewed in their own scope, op1 and op2 are still


> -----Original Message-----
> From: Walden Mathews [mailto:waldenm@optonline.net]
> Sent: Monday, February 24, 2003 1:48 PM
> To: Ugo Corda; Cutler, Roger (RogerCutler); www-ws-arch@w3.org
> Subject: Re: Snapshot of Web Services Glossary
> Er, especially if no one agrees on what these terms actually mean.  
> Ugo, would it be possible for you to restate what you said below 
> without using either 'synch' term?  Maybe if each of us tried that 
> once or twice we might get to a better place?
> WM
> ----- Original Message -----
> From: "Ugo Corda" <UCorda@SeeBeyond.com>
> To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>; 
> <www-ws-arch@w3.org>
> Sent: Monday, February 24, 2003 1:38 PM
> Subject: RE: Snapshot of Web Services Glossary
> >
> > >Incidentally, in one of the earlier go-arounds on this subject I 
> > >believe that it was pointed out that one can build a synchronous 
> > >interaction out of asynchronous components.
> >
> > And vice-versa, one could build an asynchronous interaction out of
> synchronous components.
> >
> > Ugo
> >
> >
> >
Received on Monday, 24 February 2003 16:39:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:03 UTC