W3C home > Mailing lists > Public > public-ws-chor@w3.org > June 2003

RE: Why event calculus might be the right model

From: Jean-Jacques Dubray <jjd@eigner.com>
Date: Fri, 20 Jun 2003 08:31:35 -0400
To: "'Steve'" <steve@enigmatec.net>, "'Jean-Jacques Dubray'" <jjd@eigner.com>
Cc: <public-ws-chor@w3.org>, "'Martin Chapman'" <martin.chapman@oracle.com>
Message-ID: <000301c33727$e6406d20$2278050a@JJD>


As I said, I was not completely sure. I would also concur that a
combined approach could prove best suited to model the use cases
(elegance/simplicity of block structured combined with the efficiency of
events). I can take the action item to make a proposal in that sense. 

Note that BPEL also resulted to a combined approach (pi + state /
transition) since there seem to be no way to express "synchronization"
in pi. But again, I am no specialist.


>>-----Original Message-----
>>From: Steve [mailto:steve@enigmatec.net]
>>Sent: Donnerstag, 19. Juni 2003 20:26
>>To: Jean-Jacques Dubray
>>Cc: public-ws-chor@w3.org; 'Martin Chapman'
>>Subject: Re: Why event calculus might be the right model
>>pi-calculus can incorporate or be used to describe behaviour of
>>that are both deterministic and non-deterministic. While I appreciate
>>your arguments in favour of event calculus I do not think that the
>>arguments used against pi are correct.
>>Personally I am in favour of exploring some combination of the two.
>>Using pi for the basic structural semantics and eventg calculus for
>>higher level declarative semantics. So I do not see an either/or
>>a complementary approach, which is what Frank suggested in his slides
>>earlier yesterday.
>>Steve T
>>On Friday, June 20, 2003, at 06:46 AM, Jean-Jacques Dubray wrote:
>>> Martin:
>>> I wanted to emphasize on one point. Choreographies are a very
>>> piece of software engineering because they can be
>>> In other words, it is very common that in a choreography you define
>>> series of possible MEPs, of which only one of them will occur during
>>> any
>>> given instance, but you cannot express which one will happen (the
>>> to select the one is of course outside the choreography definition,
>>> the overall system is deterministic, but not this subsystem). This
>>> typically what I label a "XOR-split". Another non-deterministic
>>> is the "recursivity" I was talking about.
>>> An orchestration process is deterministic and so is pi-calculus (I
>>> think).
>>> I am not a specialist, but I am under the impression that each time
>>> have to express the behavior of such non-deterministic system,
>>> are the way to go. This formalism let you describe all the
>>> possibilities
>>> (hanging off a given event) without assuming anything about how the
>>> event is generated.
>>> In any case, my recommendation is that we check any formalism to see
>>> how
>>> this non-deterministic case can be handled, and also how
>>> can be dealt with (i.e. a message can be sent any number of time,
>>> during
>>> a certain period or until another message "disables" this
>>> Cheers,
>>> Jean-Jacques
>>>>> -----Original Message-----
>>>>> From: Jean-Jacques Dubray [mailto:Jean-Jacques.Dubray@eigner.com]
>>>>> Sent: Freitag, 20. Juni 2003 07:30
>>>>> To: 'Ugo Corda'; 'Jean-Jacques Dubray'; public-ws-chor@w3.org
>>>>> Subject: RE: BPSS_f2f_june03.ppt
>>>>> Ugo:
>>>>> Basically a choreography protocol is needed to ensure that each
>>> in
>>>>> the choreography has the same view of the state in which the
>>>>> choreography instance is. Imagine a situation, where you send me a
>>>>> and I am not supposed to respond until the goods are shipped and I
>>> will
>>>>> respond by sending you an invoice. So you send me a PO and the RM
>>> tells
>>>>> you "I got it" (just like a fax). The next thing that should
>>> then
>>>>> is you receive the goods and later on an invoice. If there was a
>>>>> human
>>>>> behind a fax machine, and the order was garbled he could call and
>>> figure
>>>>> out the right information. In this case, the sender things the
>>>>> choreography is going ok. The responder on the contrary thinks
>>> the
>>>>> collaboration is terminated on an error. This is why you need a
>>>>> protocol: to tell you that no exception occurred, each party has
>>>>> same view of the state of the choreography.
>>>>> If you take a "highly-connected" system that has several hundred /
>>>>> thousands participants (not all participating in the same
>>>>> choreography
>>>>> instance but rather having 2 by 2 conversations). You cannot
>>> that
>>>>> every message that will be exchanged in this setting would be of
>>>>> quality (the structure may be old or wrong, the content may be
>>>>> incoherent making the processing of the message impossible, i.e. a
>>>>> response cannot be created because the message could not get into
>>>>> system that was supposed to create the response).
>>>>> At this point, you can say I don't need/want a protocol. That
>>> that
>>>>> when a choreography is designed, the designers must account for
>>>>> possible (yet common) errors. They will create specific messages
>>> say
>>>>> "could not process your orders, it contains errors", and make
>>>>> messages part of the choreography.
>>>>> On the other hand if you had a protocol, you would have a standard
>>>>> set
>>>>> of exceptions (common to all message exchanges) and materialized
>>> a
>>>>> set of standard messages. You could then express the choreography
>>> paths
>>>>> based on these error conditions (if success ... if failure ... if
>>>>> timeout ... if structure invalid ... if content invalid ...) with
>>>>> implicit message exchange. The simplest set of exception for me
>>>>> message did not get there on time, message could not be processed
>>>>> system/service of record.
>>>>> Again, all this has nothing to do with RM. The problem here is not
>>> that
>>>>> your message did not get to the recipient, it is rather that the
>>>>> recipient got a message that he could not process, hence
>>>>> the choreography instance. A protocol would help you cover 80/90%
>>> the
>>>>> common exceptions. Others can be dealt with at the design level.
>>>>> Cheers,
>>>>> Jean-Jacques Dubray____________________
>>>>> Chief Architect
>>>>> Eigner  Precision Lifecycle Management
>>>>> 200 Fifth Avenue
>>>>> Waltham, MA 02451
>>>>> 781-472-6317
>>>>> jjd@eigner.com
>>>>> www.eigner.com
>>>>>>> -----Original Message-----
>>>>>>> From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
>>>>>>> Sent: Donnerstag, 19. Juni 2003 22:14
>>>>>>> To: Jean-Jacques Dubray; public-ws-chor@w3.org
>>>>>>> Subject: RE: BPSS_f2f_june03.ppt
>>>>>>> Jean-Jacques,
>>>>>>> I did not have a chance to listen to your presentation, so you
>>>>>>> might
>>>>> have
>>>>>>> already explained this. In your slides you talk about a
>>> "choreography
>>>>>>> protocol", and I am not sure whether it is just regular messages
>>> plus
>>>>> an
>>>>>>> instance ID (as you mentioned in a previous message to the list)
>>> it
>>>>> is
>>>>>>> more than that.
>>>>>>> Thank you,
>>>>>>> Ugo
>>>>>>>> -----Original Message-----
>>>>>>>> From: Martin Chapman [mailto:martin.chapman@oracle.com]
>>>>>>>> Sent: Thursday, June 19, 2003 12:18 PM
>>>>>>>> To: public-ws-chor@w3.org
>>>>>>>> Subject: FW: BPSS_f2f_june03.ppt
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
>>>>>>>> Sent: Thursday, June 19, 2003 10:23 AM
>>>>>>>> To: 'Martin Chapman'; 'Steve Ross-Talbot';
>>>>> Daniel_Austin@grainger.com
>>>>>>>> Subject: BPSS_f2f_june03.ppt
>>>>>>>> Martin et al:
>>>>>>>> This is my presentation for this afternoon. Please let me
>>>>>>>> know what time
>>>>>>>> and which number to call.
>>>>>>>> Best regards,
>>>>>>>> JJ-
>>>>>>>> 781-472-6317
>>> This email is confidential and may be protected by legal privilege.
>>> you are not the intended recipient,  please do not copy or disclose
>>> its content but  delete the email and contact the sender
>>> Whilst we run antivirus software on all internet emails we are not
>>> liable for any loss or damage. The recipient is advised to run their
>>> own antivirus software.
Received on Friday, 20 June 2003 08:32:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:59 UTC