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

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

Received on Friday, 11 April 2003 13:41:06 UTC