RE: Issue: Synch/Asynch Web services

Thank you.

I do have a sort of dyslexic problem confusing Lamport and Lamprey.  I
seem to use the words interchangeably. The man should certainly not be
confused with a parasitic fish!!

I understand what you object to, but I think the problem is fairly
easily addressed, if desired, by cleaning up the verbiage a bit.  If one
wants to look at things a bit more cleanly I think that one needs to
address:

1 - Understand the context. [Synchronization looks different in geology,
astronomy, particle physics and IT distributed systems, and probably
there is some bifurcation in the IT systems].

2 - What events are being synchronized?  [e.g. the sending and reception
of a message].

3 - What accuracy does the context admit for this synchronization?  This
may often be understood, or even replaced by, a discussion of the
mechanism.  [e.g. the sender blocks until he/she gets tired of waiting
for a response].

I think that the aspects of current definitions that look a bit oddly
specific are actually trying to look at 3).  Frankly, I think that
several of the definition candidates are "good enough" or can be made so
fairly easily.  I think it is more important to "move forward" on
addressing the important issues of asynchronous and synchronous Web
services in the architecture than it is to get the definitions
absolutely pristine.

-----Original Message-----
From: Geoff Arnold [mailto:Geoff.Arnold@Sun.COM] 
Sent: Monday, August 04, 2003 10:02 AM
To: Cutler, Roger (RogerCutler)
Cc: www-ws-arch@w3.org; www-wsa-comments@w3.org
Subject: Re: Issue: Synch/Asynch Web services


Excellent analysis, Roger.  But I guess you'd expect me to say that, 
since I was
the one pushing for a definition of sync/async based on common clocks.
I'd forgotten the Lamport (not "Lamprey"!) paper, but I agree that it's
seminal - even more so than Waldo et al's "A Note on Distributed 
Computing".

I plead guilty, and unrepentantly so, to the "refusal to define". It was
born not out of fatigue but with a principled objection to the idea of
including language based on wholly irrelevant implementation issues.
Synchronous and asynchronous interactions should not depend on whether
processes are running and ready or activated as needed: we don't make
these distinctions in the SOAP spec.

It's worth mentioning that in Lamport's paper a "process" is simply an
abstraction capable of emitting and receiving events. There are no
particular implementation characteristics implied.....

Received on Monday, 4 August 2003 11:14:43 UTC