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 13:28:02 -0400
To: "'Assaf Arkin'" <arkin@intalio.com>, "'Jean-Jacques Dubray'" <jjd@eigner.com>
Cc: <public-ws-chor@w3.org>, "'Martin Chapman'" <martin.chapman@oracle.com>
Message-ID: <002301c33751$4e9c7160$2278050a@JJD>

So using some of the standard pi-calc notation would the example look
like this?

For the buyer, the process is:
ChangePo = _changePo.ChangePO
Purchase(po, changePo, cancelPo,invoice)
=_po.((ChangePo + _cancelPo.0).invoice)+invoice.0

(assuming all messages don't need a response).

I am trying to express that when a PO is sent, it can be followed by any
number of changePo (for a certain duration?) or by a cancelPO, if the
cancelPO happens the process stops right there, otherwise, an invoice is
sent. How do we express that changePO or cancelPO may not happen at all?
Is it like I did above with the +invoice? 

How would you add business logic like if PO accepted then (ChangePO +
_cancelPO) can happen? Maybe it is not part of the notation.


>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
>>On Behalf Of Assaf Arkin
>>Sent: Freitag, 20. Juni 2003 11:53
>>To: Jean-Jacques Dubray
>>Cc: public-ws-chor@w3.org; 'Martin Chapman'
>>Subject: Re: Why event calculus might be the right model
>>Just a small reminder. There is indeed a species of process calculus
>>that is deterministic. The type of process calculus models we are
>>talking about (pi-calculus and friends) definitely supports
>>non-determinism. If it didn't support any of the following, we
>>be able to use it even for the trivial case:
>>- X or Y (or Z or ...) (conditional)
>>- X followed by X or Y (iterative)
>>- zero or more X until Y (recursive)
>>where X, Y, etc can be messages, time events, faults, etc.
>>Jean-Jacques Dubray wrote:
>>>I wanted to emphasize on one point. Choreographies are a very
>>>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
>>>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 is
>>>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
>>>I am not a specialist, but I am under the impression that each time
>>>have to express the behavior of such non-deterministic system, events
>>>are the way to go. This formalism let you describe all the
>>>(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
>>>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,
>>>a certain period or until another message "disables" this
Received on Friday, 20 June 2003 13:28:41 UTC

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