Sync Definition #1

Based on the attached mesage, I would like to propose the following
definition for synchronous.  IMHO it is the best I have seen and is
close to capturing the spirit of, if not the specifics, of a lot that
has been said in this massive thread.
 
Synchronous: a request/response exchange that is correlated by virtue of
a serialized, sequenced exchange of messages between requestor and
respondant, typically over the same socket or stream.
 
And for asysnchronous,
 
Asynchronous: a request/response exchange that is not synchronous,
typically relying on some mechanism such as Message-ID within the
messages to correlate the request and response messages.
 
Note that if we were to use the expanded verbiage below I think that we
would not want to use the word "euphemism", which means, "substitution
of an inoffensive or mild expression for one that may offend or suggest
something unpleasant".  Probably the word "synonym" or "word" would
serve, depending on context, or the sentences could be reworked to avoid
a verb altogether.
 
-----Original Message-----
From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
Sent: Tuesday, February 25, 2003 2:58 PM
To: www-ws-arch@w3.org
Subject: Re: Snapshot of Web Services Glossary



I have read through and thought about the issues related to this
discussion, and the more 
I think about the way and context within which the term is being used
(typically an HTTP 
request/response pair), I think that what people mean by "synchronous" 
has really nothing at all to do with timing (although, the particulars
of the HTTP protocol 
implementation does impose some timing constraints). Rather, I think
that the 
term has been used as a euphamism for a request/response exchange that 
is correlated by virtue of a serialized, sequenced exchange of messages
between 
requestor and respondant, typically over the same socket or stream. 

The interesting characteristic that distinguishes a "synchronous" versus
an 
"asynchronous" exchange is the absence or presence of correlation
information 
in the message. We have used the euphamism "synchronous" to mean that we

make a request in the anticipation of a response that is correlated by
virtue of 
the fact that the request and response message share the same connection

stream and are serialized such that the response message for each
request 
message is sent to the client in the order in which the request messages
over that 
same connection were received (and hence, the order in which the
requests 
were made). 

With an "asynchronous" protocol, we typically rely on some mechanism
within the messages 
to correlate the request and response messages such as a Message-Id. 

Cheers, 

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624 

www-ws-arch-request@w3.org wrote on 02/24/2003 02:23:55 PM:

> 
> A useful exercise might be to try rewriting everything you said
> below without resort to "synchronous" or "asynchronous".  The problem,
> as I now see it, is that these terms are too overloaded for a single,
> sharp definition to work.  The same might also be a useful exercise
> in the improvement of the scenarios.  At least it would help clarify
> where delineation is still needed.
> 
> I think the words "blocking", "polling" and "interrupt" are better
> terms for describing what happens at the programming language
> level.  Likewise, "solicited" and "unsolicited" are better for
describing
> the expected state on the other end of the link.  Synchronous,
> then, can be reserved to describe shared time dependencies or
> expectations.
> 
> On a side issue, I don't think "relatively short time" is a workable
> component in the definition of synchronous.  This goes to an
> understanding of the meaning of "real-time", which as they said at the
> SEI, is not the same thing as "real fast".  It's just about how
deadlines
> are managed.
> 
> What next?
> 
> Walden
> 
> ----- Original Message -----
> From: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>
> To: "Walden Mathews" <waldenm@optonline.net>; "Francis McCabe"
> <fgm@fla.fujitsu.com>
> Cc: <www-ws-arch@w3.org>
> Sent: Monday, February 24, 2003 1:30 PM
> Subject: RE: Snapshot of Web Services Glossary
> 
> 
> > I personally thought your "rough attempt" was pretty darn good at
> > sorting out some of the issues and providing a basis for a common
> > understanding of the terms.  It seems to me, however, that we have a
> > real difference in mindset involving the issue you raise here:  If
one
> > thinks of synchronous as having to do with blocking it makes sense
to
> > say that one writes code that does something synchronously or
> > asynchronously -- independent of what goes on at the other end.  If
it
> > describes a communication relationship I don't think that makes
sense.
> > If, however, it is a communication relationship, which seems to me
to
> > involve some sort of prior agreement between the parties about what
is
> > happening, I don't understand how this relates to late-bound
> > interactions.
> >
> > 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.  That is, as I understand it a TCP/IP
> > communication can be viewed as synchronous by the application using
the
> > service, but under the covers it is composed of a conversation of
> > asynchronous messages.  This seems to say that whether something is
> > synchronous or asynchronous depends on how you are viewing it.  That
is,
> > the observer is part of the system somehow here.
> >
> > At the last F2F I got so confused about what "synchronous" really
means
> > that I claimed the only interaction that I was SURE was synchronous
> > would be if I punched you in the nose -- but then somebody told me
that
> > at the neural level this interaction is not really synchronous.
Again,
> > it seems that in order to tell whether something is synchronous or
not
> > you need to consider not only what is happening with the sender and
> > receiver, but also the observer.
> >
> > -----Original Message-----
> > From: Walden Mathews [mailto:waldenm@optonline.net]
> > Sent: Monday, February 24, 2003 12:10 PM
> > To: Cutler, Roger (RogerCutler); Francis McCabe
> > Cc: www-ws-arch@w3.org
> > Subject: Re: Snapshot of Web Services Glossary
> >
> >
> > Roger,
> >
> > I agree with you (this time in public).  While the group complains
that
> > "blocking" is implementation detail and therefore technically an
> > inaccurate description of synchrony, I think the reality is that the
> > readership of the architecture document and glossary will tend to be
> > programmers and IT people who will best understand in terms of
blocking
> > threads or processes.  It's going to be a little hard to bridge
between
> > common imprecise understandings and more esoteric ones based on
deeper
> > analysis, like the one Frank offered.  See my rough attempt at [1].
> >
> > In reading through the scenarios, I noticed some strange usage of
the
> > terms in question, like "send an asynchronous message".  As I
understand
> > it, synchrony is a property of a communication relationship, and so
has
> > no meaning when applied to a single message.  Here, it could mean
the
> > sender doesn't expect a reply at any particular time.  It could also
> > mean the equivalent of "unsolicited".  Then there's a reference to a
> > "synchronous HTTP POST".  Not sure if "synchronous" adds any meaning
> > there.  I can visualize a task to clean up the usage of "synch" and
> > "asynch" in the scenarios document.  Part of that could be through
> > refinement of their respective definitions, but some of it is in
> > scrutinizing their application, too.  Perhaps this is a candidate
issue.
> >
> > Thanks,
> >
> > Walden
> >
> > [1]
http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0283.html
> >
> > ----- Original Message -----
> > From: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>
> > To: "Francis McCabe" <fgm@fla.fujitsu.com>
> > Cc: "Assaf Arkin" <arkin@intalio.com>; "David Booth"
<dbooth@w3.org>;
> > "Martin Chapman" <martin.chapman@oracle.com>; <www-ws-arch@w3.org>;
> > "Hugo Haas" <hugo@w3.org>
> > Sent: Monday, February 24, 2003 11:29 AM
> > Subject: RE: Snapshot of Web Services Glossary
> >
> >
> > >
> > > Sort of sounds to me like this definition would shrink the
effective
> > > scope of "synchronous" essentially to zero, at least as far as
matter
> > > that concern this WG.  I do not think that this would be useful.
> > >
> > > -----Original Message-----
> > > From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> > > Sent: Sunday, February 23, 2003 5:20 PM
> > > To: Cutler, Roger (RogerCutler)
> > > Cc: Assaf Arkin; David Booth; Martin Chapman; www-ws-arch@w3.org;
Hugo
> >
> > > Haas
> > > Subject: Re: Snapshot of Web Services Glossary
> > >
> > >
> > >
> > > here is a very straightforward definition of synchronous:
> > >
> > > A rendezvous of two activities is synchronous if they complete
> > > simultaneously.
> > >
> > > The language, if not the definition, comes from Communicating
> > > Sequential Processes.
> > >
> > > One might try to sharpen this up by defining simultaneously in
terms
> > > of clocks etc. But that is not necessary; because an alternative
view
> > > of this definition is:
> > >
> > > An activity involved in a synchronous rendezvous may assume that
the
> > > rendezvous is complete for both sides if it 's side completes.
> > >
> > > Frank
> > >
> > >
> > >
> > > On Saturday, February 22, 2003, at 12:10  PM, Cutler, Roger
> > > (RogerCutler) wrote:
> > >
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
>