Re: Why event calculus might be the right model

JJ,

pi-calculus can incorporate or be used to describe behaviour of systems 
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 the 
higher level declarative semantics. So I do not see an either/or rather 
a complementary approach, which is what Frank suggested in his slides 
earlier yesterday.

Cheers

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 peculiar
> piece of software engineering because they can be non-derterministic.
>
> In other words, it is very common that in a choreography you define a
> 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 logic
> to select the one is of course outside the choreography definition, so
> the overall system is deterministic, but not this subsystem). This is
> typically what I label a "XOR-split". Another non-deterministic aspect
> 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 you
> have to express the behavior of such non-deterministic system, events
> 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 "recursivity"
> 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 possibility).
>
> 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 peer
> in
>>> the choreography has the same view of the state in which the
>>> choreography instance is. Imagine a situation, where you send me a PO
>>> 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 happen
> 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 that
> the
>>> collaboration is terminated on an error. This is why you need a
>>> protocol: to tell you that no exception occurred, each party has the
>>> 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 expect
> that
>>> every message that will be exchanged in this setting would be of high
>>> 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 the
>>> system that was supposed to create the response).
>>>
>>> At this point, you can say I don't need/want a protocol. That means
> that
>>> when a choreography is designed, the designers must account for these
>>> possible (yet common) errors. They will create specific messages to
> say
>>> "could not process your orders, it contains errors", and make these
>>> 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 with
> 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 an
>>> implicit message exchange. The simplest set of exception for me are:
>>> message did not get there on time, message could not be processed by
>>> 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 interrupting
>>> the choreography instance. A protocol would help you cover 80/90% of
> 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) or
> 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. If 
> you are not the intended recipient,  please do not copy or disclose 
> its content but  delete the email and contact the sender immediately. 
> 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:24:03 UTC