RE: pi-calculus ...

Nickolas:

To the best of my knowledge, pi-calculus does not seem to have the
concepts of "correlated" messages such request/response (a.k.a. MEP). It
does not have also the notion of exception. 

I remain convinced that the ws-chor metamodel will be, we should be able
to map it to pi-calc concepts because precisely the theory deals with
simple message exchanges and everything in a choreography boils down to
a message exchange between ports. 

Another big hurdle I see, is that the pi-calc metamodel forces us to
"see" the choreography only via the processes that implement it, it does
not offer a neutral or independent view of the choreography. I feel that
these two views are complementary (neutral and process) and almost
always isomorphic but I steel prefer to offer designers the neutral
view.

Now, what does it mean to define ws-chor metamodel based on a formal
model (is it equivalent to say it can be mapped to a formal model)?
Ultimately we have a set of requirements. When the pi-calculus (or any
other formal model), it is likely that only a fraction of these
requirements were taken into consideration when the model was developed.

If you look at the pi-calc metamodel I published (I don't claim it is
complete - http://www.ebpml.org/metamodel.htm), then one could say, yes
any choreography specification should have operators (the ones of
pi-calc may not be enough), similarly it may have activities (the ones
of pi-calc sound good), but then I would argue that the notion of port
makes it more difficult to define complex MEPs. If you adopt the neutral
point of view you look at message flow, and a message flows between an
output port in one process to an input port into another process. These
two ports are typically redundant, a message and a direction between 2
roles is typically enough, actually, it is even better if you consider
MEPs, because you just specify the MEP and the role which initiates the
MEP, then all messages exchanged as part of the MEP are defined. You
save a lot of definitions by doing so. In a way, I am pretty sure that
one could turn around pi-calculus and replace the notion of "port" by
MEP and "process" by choreography and use pretty much the same
formalism. Unfortunately I am either not smart enough and/or don't have
the time to prove it.

Ultimately, it is not this basic metamodel (based on a formal model)
that will establish the value of ws-chor it is rather our understanding
(translated as semantics of the metamodel) of notions such as
role/binding, exception handling, types of MEPs, ... 


Jean-Jacques 

 

>>-----Original Message-----
>>From: Nickolas Kavantzas [mailto:nickolas.kavantzas@oracle.com]
>>Sent: Tuesday, May 06, 2003 8:08 PM
>>To: Jean-Jacques Dubray
>>Cc: 'Steve Ross-Talbot'; public-ws-chor@w3.org
>>Subject: Re: pi-calculus ...
>>
>>
>>Jean-Jacques Dubray wrote:
>>
>>> Two more points from the discussion.
>>> 1) ultimately, I think that it will be possible to map the ws-chor
>>> metamodel to the pi-calculus metamodel (since pretty much all
message
>>> exchange can be modeled with pi). As a result, one can view ws-chor
>>> metamodel as syntactic sugar as it was expressed in the call, but
this
>>> sugar also helps reducing the need for PhD to write
chor-definitions.
>>>
>>
>>The WS-CHOR metamodel/XML-language is what we SHOULD define based on
some
>>formal model.
>>
>>Pi-c or a flavour of that, is a good candidate for the base of our
work
>>because it allows one with very few fundamental constructs to describe
how
>>programs can work together in parallel by just sending and receiving
names
>>(values & references). These constructs are Interaction Channels, send
>>operation, receive operation, compose operation, restrict operation,
>>replicate operation, send/receive-guards continuations.
>>
>>As an example of why we have to define our own language above this
core
>>compuational model is functions, a construct very fundamental in
todays
>>computing. Pi-c does not have the notion of functions as part of the
core
>>fundemental constructs but it has being shown how one can code
functions
>>using the core pi-c very easily. So, function abstraction and function
>>application should be part of our language in addition to the core
>>fundamental constructs.
>>Usage of the Interaction Channels (used only for sends or receives,
only
>>once, only fresh channels can be passed around, etc.), should also be
part
>>of our language. Roles, is another good candidate.
>>
>>>
>>> 2) Would it be a good time to start collecting ws-chor metamodel
>>> elements (e.g. role, MEPs, ...). I know we are not done yet through
the
>>> requirements, that might help people formulate more requirements
(e.g.
>>> if we have role, we need to define a binding one way or another,
...) I
>>> could volunteer for that task.
>>>
>>
>>With WSCI being one of our inputs, I would like to see the metamodel
of
>>WSCI first.
>>
>>Then, it would be nice to understand how we can bridge the gap between
the
>>WSCI global model and ebXML*BPSS and also how to restrict WSCI in a
way
>>that helps us make validations of implementations with their
observable
>>behavior contracts in a tractable way.
>>
>>
>>>
>>> Cheers,
>>>
>>> Jean-Jacques
>>>
>>>
>>>
>>> >>-----Original Message-----
>>> >>From: public-ws-chor-request@w3.org
>>> [mailto:public-ws-chor-request@w3.org]
>>> >>On Behalf Of Assaf Arkin
>>> >>Sent: Tuesday, May 06, 2003 4:14 PM
>>> >>To: jdart@tibco.com
>>> >>Cc: Steve Ross-Talbot; public-ws-chor@w3.org
>>> >>Subject: Re: CSF's and choreography - at least it alludes to
some.....
>>> >>
>>> >>
>>> >>Jon Dart wrote:
>>> >>
>>> >>>
>>> >>>
>>> >>> Assaf Arkin wrote:
>>> >>>
>>> >>> > To make it absolutely clear, in my opinion the choreography
should
>>> at
>>> >>> > the minimum be able to express the WS interactions with the
same
>>> >>> > capabilities presented in WSBPEL.
>>> >>>
>>> >>> Does this entail duplicating what the "external" portion of
WSBPEL
>>> >>> does? (and if not what other things does it do)?
>>> >>
>>> >>Yep.
>>> >>
>>> >>>> It's much better to start
>>> >>>> with something we already have, for example WSCI: refactor it
to
>>> meet
>>> >>>> the minimum list of CSFs and to leverage WSDL 1.2 and then
extend
>>> it
>>> >>>> with the other features we deem necessary.
>>> >>>
>>> >>>
>>> >>> WSCI does need to be considered at some point, although we may
find
>>> it
>>> >>> does not meet all identified requirements.
>>> >>
>>> >>Absolutely. This is just my opinion that it's close enough to what
we
>>> need.
>>> >>
>>> >>arkin
>>> >>
>>> >>>
>>> >>> --Jon
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>--
>>> >>"Those who can, do; those who can't, make screenshots"
>>> >>
>>>
>>----------------------------------------------------------------------
>>> >>Assaf Arkin
arkin@intalio.com
>>> >>Intalio Inc.
www.intalio.com
>>> >>The Business Process Management Company                 (650) 577
4700
>>> >>
>>> >>
>>> >>This message is intended only for the use of the Addressee and
>>> >>may contain information that is PRIVILEGED and CONFIDENTIAL.
>>> >>If you are not the intended recipient, dissemination of this
>>> >>communication is prohibited. If you have received this
communication
>>> >>in error, please erase all copies of the message and its
attachments
>>> >>and notify us immediately.
>>> >>

Received on Wednesday, 7 May 2003 07:41:10 UTC