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.

Jean-Jacques 
 
 

>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
[mailto: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
wouldn't
>>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.
>>
>>arkin
>>
>>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
>>>
>>>
Received on Friday, 20 June 2003 13:28:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:21 GMT