Re: Issue: Synch/Asynch Web services

+1

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

www-ws-arch-request@w3.org wrote on 08/12/2003 08:30:48 AM:

> 
> 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:40:36 UTC