- 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
> 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 UTC