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

But I'm not DEAD yet!!!

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

www-ws-arch-request@w3.org wrote on 05/06/2003 01:34:55 AM:

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