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

RE: Draft language on MEPs, synchronous, and asynchronous.

From: Damodaran, Suresh <Suresh_Damodaran@stercomm.com>
Date: Mon, 5 May 2003 15:42:51 -0500
Message-ID: <D0E281E7D3C7164399488D7AD8BEEFEB011FAB4A@scidalmsg02.csg.stercomm.com>
To: "'Martin Chapman'" <martin.chapman@oracle.com>, "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>, Geoff Arnold <Geoff.Arnold@sun.com>, "Champion, Mike" <Mike.Champion@softwareag-usa.com>
Cc: www-ws-arch@w3.org

May be we are divided by the same words.

Try the following experiment.

Type in a URL in a browser (lets say the page the page takes some time to
appear)
Before the page apperas type in the same URL, and press return.

Now, what happened to the first connection? Is it being multiplexed? Will
you see two pages? Of course, you won't - because the first page invocation
was aborted.
This behavior, to me, is an attribute of synchrnous invocation of the page. 

You may type in the same URL on a different browser window. In this case,
there are two 
communication channels, because the sender of the message is different. Will
you be able
to see the same page in two browsers? Yes.
Does it mean the page invocation is not synchrnous? No.

BTW, try defining "multiplexing:-)"

Regards, 
-Suresh 
Sterling Commerce (on loan to RosettaNet) 
469 524 2676 (O), 469 323 0234 (Cell) 



-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Monday, May 05, 2003 3:03 PM
To: Damodaran, Suresh; Cutler, Roger (RogerCutler); Geoff Arnold;
Champion, Mike
Cc: www-ws-arch@w3.org
Subject: RE: Draft language on MEPs, synchronous, and asynchronous.


I thought I had. It is possible in synchronous systems for A to send a
request to B even if a response to a previous request from A to B has not
yet been received; it's called multiplexing.

Martin.

> -----Original Message-----
> From: Damodaran, Suresh [mailto:Suresh_Damodaran@stercomm.com]
> Sent: Monday, May 05, 2003 12:39 PM
> To: 'Martin Chapman'; Cutler, Roger (RogerCutler); Geoff Arnold;
> Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
>
>
> Please explain teh exact situation in which this definition is wrong
>
> Regards,
> -Suresh
> Sterling Commerce (on loan to RosettaNet)
> 469 524 2676 (O), 469 323 0234 (Cell)
>
>
>
> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Monday, May 05, 2003 11:39 AM
> To: Cutler, Roger (RogerCutler); Geoff Arnold; Champion, Mike
> Cc: www-ws-arch@w3.org; Damodaran, Suresh
> Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
>
>
> The sync/async differentiation below is technically wrong.
> It is entirety possible that a client may have two requests
> outstanding and
> for both of them
> to be synchronous, so this implied serialization is just not accurate. I
> suggest we
> stick with Geoff's proposal and not waste anymore time on this.
>
>
> Martin.
>
> > -----Original Message-----
> > From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> > Behalf Of Cutler, Roger (RogerCutler)
> > Sent: Sunday, May 04, 2003 11:30 AM
> > To: Geoff Arnold; Champion, Mike
> > Cc: www-ws-arch@w3.org; Suresh_Damodaran@stercomm.com
> > Subject: RE: Draft language on MEPs, synchronous, and asynchronous.
> >
> >
> >
> > I would have thought that email is, by its essence, always asynchronous,
> > that most MOM systems have well-defined synchronous and asynchronous
> > modes, and that the last example is a "scheduled asynchronous
> > communication" and clearly asynchronous.  I do not think that
> > "synchronous" is in any way synonymous with "scheduled" and I don't
> > think I can recall any candidate definitions in which that was the case.
> >
> > I'm sorry, I still think this is just giving up and that in fact the
> > terms have a domain of validity in which they can be rigorously defined.
> > It seems to me that doing so, and if possible defining some domain where
> > they are not meaningful (although I really haven't personally understood
> > why there would be such a domain or seen it described in a way that I
> > understand) would be more productive.
> >
> > I think that Suresh's definition, which I had not seen before, is pretty
> > good.  The one thing that might be questionable is that it uses the word
> > "channel".  I do not really know what a channel is.  Possibly
> > understanding that would help to define the domain in which
> > synch/asynch has meaning.  However, if "synchronous" depends on having a
> > channel, I don't exactly see the problem with using the term
> > "asynchronous" for situations where the concept of channel is somehow
> > not relevant.
> >
> > For convenience, here is Suresh's definition again.  Note that it rather
> > explicitly defines its domain of applicability with the phrasee "over a
> > communication channel" (whatever that means).
> >
> > Synchronous: An entity A  communicates with entity B  synchronously over
> > a communication channel if and only if A requires a response back from B
> > and A does not initiate another communication to B using the same
> > communication channel before it receives that response.
> >
> > Asynchronous: When A communicates with B  asynchronously, A does not
> > always require a response back from B. Irrespective of whether A
> > requires a response or not, A may initiate another communication to B on
> > the same communication channel.
> >
> > *"communication" can be a message or a signal.
> >
> > Here is a version that I have word-smithed a bit.
> >
> > Synchronous: An entity A communicates with entity B synchronously over a
> > communication channel if and only if A requires a response back from B
> > and A does not initiate another communication to B using the same
> > communication channel before it receives that response or the
> > communication has failed.  Entity A may consider the communication to
> > have failed if it does not receive a response back in some length of
> > time.
> >
> > Asynchronous: When A communicates with B  asynchronously, A may not
> > require a response back from B. Whether A  requires a response or not, A
> > may initiate another communication to B on the same communication
> > channel at any time.
> >
> >
> >
> > -----Original Message-----
> > From: Geoff Arnold [mailto:Geoff.Arnold@sun.com]
> > Sent: Saturday, May 03, 2003 6:02 PM
> > To: Champion, Mike
> > Cc: www-ws-arch@w3.org
> > Subject: Re: Draft language on MEPs, synchronous, and asynchronous.
> >
> >
> >
> > > I for one would be happy to substitute something like:
> > >
> > > MEP's involving that require a response from the responder back to the
> >
> > > initiator before the initator can initiate another communication that
> > > responder using the same communication  channel are frequently
> > > referred to a "synchronous."
> > >
> > > I see that as a friendly amendment that defines "closely coupled in
> > > time"
> > > more rigorously.
> >
> > I actually see this as an excellent argument *against* trying to get
> > more rigorous. First, the "same communication channel" is hopelessly
> > transport-specific. (Try that over MOM or SMTP!) Second, a MEP that
> > requires me to send you a message on the third Tuesday of every month is
> > perfectly *synchronous*. "Closeness" of coupling is a relative thing.
> >
> > Used informally, the terms can be usefully descriptive. Let's leave it
> > at that.
> >
> >
> >
> >
> >
>
Received on Monday, 5 May 2003 16:43:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:18 GMT