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

Re: pi-calculus ...

From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
Date: Tue, 06 May 2003 17:08:21 -0700
Message-ID: <3EB84E75.80F66DCB@oracle.com>
To: Jean-Jacques Dubray <jjd@eigner.com>
CC: "'Steve Ross-Talbot'" <steve@enigmatec.net>, public-ws-chor@w3.org


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 Tuesday, 6 May 2003 20:08:56 GMT

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