W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

Re: Draft language on MEPs, synchronous, and asynchronous.

From: Geoff Arnold <Geoff.Arnold@Sun.COM>
Date: Sat, 03 May 2003 19:27:59 -0400
To: Assaf Arkin <arkin@intalio.com>
Cc: www-ws-arch@w3.org
Message-id: <E0A41096-7DBE-11D7-95E2-000393C53568@sun.com>

> For example, a MEP that involves sending one message is inherintly 
> asynchronous. The sender may complete it's activity (sending) much 
> earlier than the receiver completes its activity (receiving). In 
> practice some protocol may force both activities to happen 
> concurrently, but at the higher protocol-independent level this cannot 
> be assumed. So the assumption must be made that the MEP is 
> asynchronous.
>
> The language proposed here allows us to conclude whether a MEP is 
> synchronous or asynchronous by looking at the MEP alone without being 
> too dependent on the actual protocols that are being used.
>

Assaf: I would really love it if it were this easy. But I don't think 
it is. I've read the SOAP 1.2
sections on MEPs backwards and forwards (metaphorically only ;-) and I 
can't see how to
do what you say. We would need a formal representation of the 
distributed state
machine that corresponds to each MEP. These representations would have 
to
be composable or else things will break down when we get to 
choreography. Don't
forget that this should still work with multiparty interactions as 
well. And
them we'd need to figure out how to define the predicate
                            synchronous(MEPStateMachineRep)
Not only am I convinced that we we cannot do this today; I am quite 
sure that,
if we *could* do this, the result would *not* be well aligned with 
informal notions
of "synchronous" and "asynchronous".

Normally in forums such as this I'm the one arguing for tight, 
unambiguous
language. In this case, the more I've read and the more you all have 
said, the
more convinced I am that rigor is unattainable and probably 
undesirable!!

Geoff
Received on Sunday, 4 May 2003 07:29:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:18 GMT