Re: pi-calculus ...

Jean-Jacques Dubray wrote:

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

Restriction on channels help you achieve this. Function application/abstraction is another convinient way to achieve this.

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

What the pi-c model gives us is precise semantics on how to carry out the computation. That is its value.

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

So, what is the parallel composition of pi-c? Is it a neutral or independent view of the choreography?

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

Pi-c is a gereric model for expressing ANY kind of computation. And since it is not
a language I am sure that there are many constructs above the core fundamental
constructs that I discussed earlier that need to be constructed.

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

MEPs as defined by WSDL 1.2, are 8 patterns of message exchanges between
two or more entities. Interestingly enough, there is a task force in the WSD group that tries to debate the
value of MEPs and I/Os. I/Os specify the abilities of one entity instead.

So, while a pre-cooked set of MEPs is important to have (and this is what I meant with my earlier comment about
defining function application/abstraction above pi-c) the real problem is how ANY kind of MEP can be constructed.

This is I believe the basis of a Choreography language.

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

That is way I proposed to start with WSCI, which has captured most of these notions.

>
>
> 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 13:58:58 UTC