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:04:48 UTC