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 12:40:34 UTC