RE: Why event calculus might be the right model

Steve:

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.

JJ- 
 
 

>>-----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
>>
>>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:32:02 UTC