Re: Internal processes and/or external choreographies (was RE: Ev ents and States ...

I didn't say "express the choreography at the event level". That would 
diffuse the value in using WSDL 1.2. I firmly believe the choreography 
should be expressed in terms of WSDL 1.2 abstract operations and that 
has tremendous value and benefit.

The discussion about events started in order to clarify the role that 
time-out plays in here, where a time constraint may be expressed across 
multiple MEPs, not just the fact that a single MEP did not complete 
(something WSDL can address). To understand the roles the time-out plays 
and how to manage interaction including both messages and time-outs, one 
has to understand the primary building blocks: events and causal order.

Understanding the primary model allows you to build a better language. 
It's benefical to understand events, causal order, concurrency, 
pi-calculus, etc. But it doesn't mean you want to write a language in 
terms of low-order events and pi-calculus symbols. You definitely want a 
language that is higher form, that takes advantage of the framework you 
already have in place, such as WSDL.

You just need to understand the underlying model to make sure that in 
creating a higher level language you don't lose track of formalism and 
end up with less capabilities.

arkin

Jean-Jacques Dubray wrote:

>Then I would claim that this proposal seem to be in opposition to the
>direction taken by WSDL 1.2 with the concept of Message Exchange
>Patterns. I contend that if you express a choreography at the event
>level (which is the lowest level you express it at) it will lead to
>unnecessary complexity. I remain convinced that the most efficient model
>is to express choreography between message exchange patterns and of
>course use the state of the resulting message exchange pattern to
>constrain the choreography path (if this response type came back then
>expect this, otherwise expect this other MEP to happen).
>
>JJ- 
> 
> 
>
>  
>
>>>-----Original Message-----
>>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>>Sent: Friday, April 11, 2003 1:28 PM
>>>To: Jean-Jacques Dubray
>>>Cc: steve@enigmatec.net; 'Cummins, Fred A'; 'Burdett, David';
>>>jdart@tibco.com; public-ws-chor@w3.org
>>>Subject: Re: Internal processes and/or external choreographies (was
>>>      
>>>
>RE: Ev
>  
>
>>>ents and States ...
>>>
>>>These are the examples I have given, not a full authorative list of
>>>      
>>>
>all
>  
>
>>>possible examples. What I have ommitted is not excluded. A request is
>>>also an event.
>>>
>>>In fact, sending a message, receiving a message, or a time instant are
>>>three types of events.
>>>
>>>Sending a message is an event. Receiving a message is an event.
>>>      
>>>
>There's
>  
>
>>>a causal dependency - receiving message event occurs after sending
>>>message event (for same message). There may also be more elaborate
>>>causal dependencies - receiving a response following a previously sent
>>>request. In fact, every pattern you could come up with is expressible
>>>using these very simple terms.
>>>
>>>And if you look at everything from the perspective of events and
>>>      
>>>
>causal
>  
>
>>>dependencies you can use other formalisms, e.g. Lamport clocks, to
>>>      
>>>
>model
>  
>
>>>and prove synchronization even in the most demanding of environment,
>>>even when you have to deal with Byzantine failures (also a Lamport
>>>concept).
>>>
>>>The formalism accounts for multiple types of events. The primary ones
>>>are send, receive and with patterns you get one-way, request-response,
>>>etc. There are also chaostic events, which allow you to deal with
>>>time-outs and more general failure detection. This model is at the
>>>      
>>>
>core
>  
>
>>>of distributed algorithms, failure detection and mobile process
>>>      
>>>
>calculus.
>  
>
>>>It is used to describe high-level protocols such as the Web, low-level
>>>protocols such as cell phones, and even the way we communicate and
>>>conduct business in the offline world. That's what makes it such an
>>>appealing model.
>>>
>>>arkin
>>>
>>>Jean-Jacques Dubray wrote:
>>>
>>>      
>>>
>>>>Assaf:
>>>>
>>>>I am not sure I understand you argument about event. All the examples
>>>>that you give for an event seem to b e responses to a request, but
>>>>        
>>>>
>how
>  
>
>>>>do you model the request itself as a message event? In my opinion, it
>>>>        
>>>>
>is
>  
>
>>>>really the completion of a message exchange pattern that constitutes
>>>>        
>>>>
>an
>  
>
>>>>event.
>>>>
>>>>JJ-
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>
>  
>


-- 
"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 Friday, 11 April 2003 13:49:52 UTC