Re: On the desirable characteristics of standards.

Walden Mathews wrote:

>>In my opinion for the semantic of WSDL operations to become 
>>"future-proof" they must be independent from any particular choice of 
>>SOAP MEPs used to implement them, including the best practices of today. 
>>In other words, the function synchronous(WSDL_MEP) should not be defined 
>>in terms of synchronous(SOAP_MEP), but defined on its own.
>>    
>>
>
>Assaf,
>
>I'm just wondering about the formality: 'synchronous(WSDL_MEP)'
>and how it plays in terms of process algebras you might imagine, or
>doesn't.  I guess what I'm asking is, is this a formality that can be
>plugged in to some formula and used to derive a truth about some
>WS composition, or is it just a formal-looking notation for what will
>remain a somewhat informal notion?
>  
>
Process algebra tends to be more low-level than WS, and not by itself a 
useful language. Generally speaking it will either propose that all 
operations are synchronous or asynchronous and you build applicable MEPs 
on top of that.

In WS choreography we don't want to describe these MEPs, rather we want 
to refer to WSDL operations that already describe these MEPs, and we 
want to let the messaging layer handle the protocol specific MEPs as it 
sees applicable. So on the one hand we don't want to describe every 
interaction down to the level of actual messages that have to be 
sent/received including those that are of no interest to the 
choreography (like ack/nack, commit/abort, challange/response, etc).

On the other hand, we don't want to lose the distinction between 
synchronous and asynchronous, by making an arbitrary decision that all 
WSDL operations are either one or the other. And we want to describe a 
choreography based on the interface so we can use any number of services 
and any combination of protocols. So we need some definition that is 
independent of the protocol.

So that is definitely a way to "derive a truth about some WS composition".

If I have an activity that performs a synchronous operation that begins 
by sending a message and I know a response is expected I would not 
conclude the activity after sending the message. I would wait for the 
response to arrive before deciding on the outcome of the activity. If 
I'm coordinating using some coordination protocol I can also expect the 
outcome to take into account both activities (i.e. the requester and 
provider).

On the other hand if I have an activity that performs an asynchronous 
operation then I can complete that activity after sending the message. 
At this point I don't know what the outcome of processing that message 
is, I need to perform another activity to receive a response, which of 
course means the previous activity has to complete for me to get to the 
point where I receive the response. If there is some outcome that 
results from coordinating activities it is typically not limited to the 
first pair of activities (i.e. requester and provider) but applicable to 
a larger scope which may include multiple asynchronous activities.

arkin

>WS Arch Group (in general),
>
>I think Extreme Programming would circumvent this boondoggle
>over the "right" definition for synchronous and asynchronous by
>simply having each author of a section of the document who would
>use that term go instead to the next level of detail and inline the
>intended attributes right into the text.  So, if you were talking about
>time dependency, you'd simply describe that.  If you were talking
>about "channels", you'd say that.  And so on.
>
>When the document is finished, you may have an opportunity to
>factor out attributes and actually have consensus on these terms,
>or you may not.  In the process, you have expressed with precision
>and gotten on with it.
>
>One thing is sure: when you're done writing the arch document,
>you are certain of the scope in which the definitions have to operate,
>something which cannot be achieved until that time.
>
>W.r.t. this problem, what is the "simplest thing that could possibly
>work"?  I submit the above for your serious consideration.
>
>Thanks,
>Walden
>  
>


-- 
"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 Monday, 5 May 2003 15:36:28 UTC