RE: Issue: Synch/Asynch Web services

Is the classic Request/Response always synchronous?  I thought that
there were two possibilities here:

1 - The one that's like a browser -- the requestor spins a clock until
the response gets back or gives up.  Two messages, one possible
ordering.  Synchronous.

2 - The one that's not like a browser -- the requestor sends off a
message with an ID, then goes about other business.  Some time, maybe a
long time later, the response comes back, the requestor looks at the ID,
correlates it with the request, and the transaction is done.  Same
number of messages, same ordering.  Asynchronous.

I think we'd better agree about whether number 2 is synchronous or
asynchronous.  I think that it is asynchronous.  The distinctions that I
think are meaningful in practice -- the necessity of an ID to match in
one, the limited timing on the other -- are all present.  I believe that
MANY descriptions of how to implement asynchronous versions of Web
services look like 2.  If we say it is synchronous I think that we are
going to confuse a lot of people.

-----Original Message-----
From: Geoff Arnold [mailto:Geoff.Arnold@Sun.COM] 
Sent: Tuesday, August 12, 2003 7:31 AM
To: Cutler, Roger (RogerCutler)
Cc: www-ws-arch@w3.org
Subject: Re: Issue: Synch/Asynch Web services


Here's another stab at the sync/async conundrum. I'm "thinking out loud"
here, and I've only had one coffee this morning, so if I've missed
something obvious please be kind... ;-)

I start from the point that "synchronous" and "asynchronous" are
adjectives that we apply to message exchange patterns. (W3C has no
business specifying how things are actually implemented.) We can
describe an MEP in terms of a finite state machine, augmented to include
timeouts. Given a sequence of messages between two or more agents, we
can determine whether the sequence represents a legal instance of the
MEP by "running" the FSM.

If for a given set of messages there is only one ordering that is legal,
the MEP is synchronous. If multiple permutations are legal, the MEP is
asynchronous.

Consider a hypothetical MEP "delayed-response":

        Agent A                           Agent B

            ----->Request------------------->
            <------------Ack-Request<--------
            <------------Response<-----------
            ---------->Ack-Response--------->


Without actually drawing out the FSM, we can ask: is the following
sequence of messages legal?

        Agent A                           Agent B

            ----->Request------------------->
            <------------Response<-----------
            <------------Ack-Request<--------
            ---------->Ack-Response--------->

How about:

        Agent A                           Agent B

            ----->Request------------------->
            <------------Response<-----------
            ---------->Ack-Response--------->
            <------------Ack-Request<--------

If only the first message sequence is valid, the MEP is synchronous. If
multiple sequences are valid, the MEP is asynchronous.

It's tempting to consider that the synchronous nature
arises from some implementation property, such as
the use of a remote procedure call API in which
agent A invokes a procedure with "in" parameters
corresponding to the Request message and "out"
parameters corresponding to Ack-Request. On this view,
the second of the sequences shown "doesn't work"
because the Response message can't supply the "out"
parameters for the procedure call. This seems to
me to be sloppy thinking, because coding up Agent A
in this way violates Fallacy #1 (see
http://java.sun.com/people/jag/Fallacies.html ). However specifying that
an MEP is synchronous certainly allows for a simple-minded
implementation (and validation) approach in which there is only one
correct sequence and all deviations represent errors which are usually
dealt with by some kind of Big Reset Button.

Note that in the example we don't insist that
asynchronous means unordered. That is to say, just because
we accept several sequences we're not required to
allow absurdities like:

        Agent A                           Agent B

            <------------Ack-Request<--------
            ---------->Ack-Response--------->
            ----->Request------------------->
            <------------Response<-----------

In other words, synchronous denotes the particular case that only one
ordering is legal; asynchronous covers all other cases. This, trivially,
means that our classic two-party request/response pattern is
synchronous, since

        Agent A                           Agent B

            ----->Request------------------->
            <------------Response<-----------

is the only legal sequence.

What I like about this approach is that is extends
naturally to multiple parties and composition (if we
get the FSM representation right). It also aids in
observable conformance, which seems to me to be a
critical issue in dynamically-assembled web service interactions.

Received on Tuesday, 12 August 2003 11:04:01 UTC