W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

RE: pi-calculus ...

From: Jean-Jacques Dubray <jjd@eigner.com>
Date: Wed, 7 May 2003 07:35:03 -0400
To: "'Nickolas Kavantzas'" <nickolas.kavantzas@oracle.com>
Cc: "'Steve Ross-Talbot'" <steve@enigmatec.net>, <public-ws-chor@w3.org>
Message-ID: <006401c3148c$c6d17aa0$1a78050a@JJD>


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

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, ... 



>>-----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
>>> 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
>>> sugar also helps reducing the need for PhD to write
>>The WS-CHOR metamodel/XML-language is what we SHOULD define based on
>>formal model.
>>Pi-c or a flavour of that, is a good candidate for the base of our
>>because it allows one with very few fundamental constructs to describe
>>programs can work together in parallel by just sending and receiving
>>(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
>>compuational model is functions, a construct very fundamental in
>>computing. Pi-c does not have the notion of functions as part of the
>>fundemental constructs but it has being shown how one can code
>>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,
>>once, only fresh channels can be passed around, etc.), should also be
>>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
>>> requirements, that might help people formulate more requirements
>>> 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
>>WSCI first.
>>Then, it would be nice to understand how we can bridge the gap between
>>WSCI global model and ebXML*BPSS and also how to restrict WSCI in a
>>that helps us make validations of implementations with their
>>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
>>> >>
>>> >>
>>> >>Jon Dart wrote:
>>> >>
>>> >>>
>>> >>>
>>> >>> Assaf Arkin wrote:
>>> >>>
>>> >>> > To make it absolutely clear, in my opinion the choreography
>>> at
>>> >>> > the minimum be able to express the WS interactions with the
>>> >>> > capabilities presented in WSBPEL.
>>> >>>
>>> >>> Does this entail duplicating what the "external" portion of
>>> >>> 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
>>> meet
>>> >>>> the minimum list of CSFs and to leverage WSDL 1.2 and then
>>> it
>>> >>>> with the other features we deem necessary.
>>> >>>
>>> >>>
>>> >>> WSCI does need to be considered at some point, although we may
>>> it
>>> >>> does not meet all identified requirements.
>>> >>
>>> >>Absolutely. This is just my opinion that it's close enough to what
>>> need.
>>> >>
>>> >>arkin
>>> >>
>>> >>>
>>> >>> --Jon
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >>--
>>> >>"Those who can, do; those who can't, make screenshots"
>>> >>
>>> >>Assaf Arkin
>>> >>Intalio Inc.
>>> >>The Business Process Management Company                 (650) 577
>>> >>
>>> >>
>>> >>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
>>> >>in error, please erase all copies of the message and its
>>> >>and notify us immediately.
>>> >>
Received on Wednesday, 7 May 2003 07:41:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:04 UTC