Re: Issue: Synch/Asynch Web services

Hi,

I am a bit confused about the relation of an MEP to the protocol exposed 
by a service provider for a prospective requestor? Can this protocol be 
thought of as some sequence of MEPs?

Thanks,
Kiran.


Geoff Arnold wrote:

>
> 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 Wednesday, 13 August 2003 07:21:16 UTC