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

I agree and disagree. I think the One True meaning for synch is "at the 
same time". More specific definitions also exist but they are specific 
to the scope in which they are defined, and you pretty much have as many 
definitions as you have scopes.

I'm not sure if the WSD people are listening, but being in the world 
outside of WSD I would find it very useful to distinguish between 
synch/asynch operations. That would allow me to decide which SOAP MEP to 
use, devise other relevant protocols (e.g. to address reliability, 
multicast, etc), and to build other languages on top of WSDL. It becomes 
an easier job if there is one definition that is specific to the scope 
of WSDL and there can be one because the scope is inheritly limited. 
SOAP and other specifications can have their own definitions that are 
applicable to these scopes.

The WSA may want to offer a very broad definition that is applicable to 
a wide variety of scopes, or it may not touch this issue and let the 
SOAP and WSDL specifications provide their own definition. But I think 
it's a mistake if the WSA document has a definition that is applicable 
to a SOAP MEP and says nothing about a WSDL operation or vice versa, 
unless we conclude that each WSDL operation is forever married to the 
same set of SOAP MEPs.

arkin


Geoff Arnold wrote:

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



-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Tuesday, 6 May 2003 15:56:06 UTC