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

Jean-Jacques,

I believe the issue here is to define the choreography at an
appropriate level of abstraction.  That level should be at
the level of exchange of information that has business impact,
as opposed to the exchanges of packets that may be necessary
to achieve reliable delivery of messages.  

The message exchange protocol should not matter.  It should be
possible to comply with the choreography whether using ebXML
reliable messaging, a message broker (e.g., MQ Series), or FTP.

If we focus on the right level of abstraction, then the 
choreography will only be as complex as required by the business
transactions.

Fred

> -----Original Message-----
> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
> Sent: Friday, April 11, 2003 1:37 PM
> To: 'Assaf Arkin'; '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 ...
> 
> 
> 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 19:18:00 UTC