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

On Monday, May 5, 2003, at 07:15  PM, Damodaran, Suresh wrote:
> I know this group has tried again and again to nail down some of these
> concepts,
> and many WSA members are at "whatever" point.
> However, other communities look towards W3C and WSA to tackle such hard
> issues, and provide definitions and directions.
> Fudging in this responsibility would be another sure fire way to make 
> WSA
> irrelevant
> to real world. I apologize if this sounds like a sermon. I have no 
> desire to
> increase the frustration and stress on the well meaning folks. Just 
> pointing
> out a reality.
>

I'm sorry: this is nonsense. The "real world" is looking to WSA to see 
if it can
articulate an architecture which ties together a variety of W3C (and
possibly non-W3C) standards in a coherent fashion. The "real world" is
not looking to us to come up with the One True Meaning of
"synchronous".

The terms under discussion are used all over the software engineering, 
networking,
electrical engineering, and process control domains. You, Suresh, want 
to
adopt a channel-based definition. Wonderful - except that this is going 
to
be inconsistent with a bunch of other usages. Look back through the WSA
archives, and you will see literally dozens of proposals based on MEPs,
process dispatching, common clocks, properties of distributed finite
state machines, re-use of low level communications artifacts,  MOM
semantics.... There is no single definition that will satisfy all of 
these,
and no reasonable basis for preferring one over the others.

Furthermore, cui bono? What benefit do we derive from nailing
down The One True Meaning? Architecturally, we tend to
drive for such unambiguous definitions in the cases where the
terminology serves an important organizing principle, cleaving the
design space into two parts each of which has clearly differentiated
properties. (Think of the clear differentiation in TCP/IP or ISO between
stream and datagram services.) But the terms under discussion do not 
serve
this purpose. Given the requirements of platform- and message-
transport-independence, the core of our work must revolve around SOAP
and MEPs. However we cannot even make the terms work here!

As I indicated yesterday, we do not have the technology today to
formally describe MEPs in a fashion that would support robust
characterizations of this kind. Indeed a reading of SOAP 1.2
makes very clear that the best we can do is to arbitrarily assign
informal properties to MEPs. (It would be helpful if the authors had
actually indicated a methodology for formally defining a new MEP.)
Obviously this offers no promise whatsoever for coping with
composition or multiparty patterns in a principled fashion.

The audience for SOAP, REST, and so forth needs to know
how to implement MEP state machines in an interoperable
fashion. The labels "synchronous" and "asynchronous" do not
help in this; on the contrary, they are likely to induce error by
implying (incorrectly) a normative semantics related to some
other technology with which the reader is familiar.

As Chris said, let's stick a fork in this trout. We have more
important things to do.

Geoff

Received on Tuesday, 6 May 2003 01:34:49 UTC