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 08:30:05 UTC