RE: pi-calculus ...

Sorry for the late reply - playing catch up, but I completely agree with JJ
that it is important that we provide a solution that enables a "neutral
view" as in ...

"The other thing I like is that it [BPSS] offers a neutral view. That is
really useful for standard committees like RosettaNet, STAR, OAGIS, and the
several hundred others that need to define industry wide choreographies.
This view lands itself relatively well in an architecture that requires
"agreements" between partners, whether they are statically specified or
dynamically calculated as partners engage in a business relationship."

If we don't develop a choreography  spec that can be used by these types of
standards groups then we can, IMHO, say goodbye to low cost ubiquitous
eCommerce and in that I case I think we would have failed.

So how about as a requirement ...

"The choreography specification must provide a method of defining the rules
and sequence for exchanging messages between two or more roles (e.g. buyer,
seller, etc) that:
a) Provides a single choreography definition that covers all the behaviors
of all of the roles
b) Treats each role equally
c) Specifies messages in an abstract way, i.e. independent of the precise
data structures and transport binding."

David
-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Thursday, May 08, 2003 9:50 AM
To: 'Assaf Arkin'; 'Jean-Jacques Dubray'
Cc: 'Nickolas Kavantzas'; 'Steve Ross-Talbot'; public-ws-chor@w3.org
Subject: RE: pi-calculus ...




>>Are we building a new language for pi-calculus or a language for WS
>>Choreography?
>>
>>If we're building a new language for pi-calculus we don't care if it
has
>>request/response. If we're building a language for WS Choreography we
>>should be using WSDL 1.2. Then the problem becomes, does the model
still
>>work? Judging by all the existing WSDL 1.2 MEPs it works quite nicely.

[JJ] As I said, I am not debating if this mapping can work, to me it is
almost automatic as long as all you are using is message exchanges
between agents (represented by roles), because this is what pi-calc is
about. There are 4 major concepts in pi-calc that I could count that are
of interest to us, the question is to me, do we adopt them as is (for
whatever reason, technical, marketing, ...) or do we need more, or do we
other concepts?

a) Activities (process, scope, port activity, terminate)
b) Operations (Sequence, Alternate, Restriction, Prefix, Replicate)
c) Port (Input, Output, Virtual Port)
d) Process (Process composition)

From this theory I see three possibilities to express a choreography:
1) process composition (two processes interacted one with another), WSCI
has mapped this approach first. This model works well in Multi-party
collaboration
2) use an abstract process (this specifies the message exchange from the
point of view of one participant). This is the approach of BPEL. This
model does not work well in complex multi-party collaborations since it
assumes that one role has the control.
3) a neutral view of the choreography, specifying the choreography of
any type and number of message exchange patterns between any number of
roles. This is the approach of BPSS. 

I am completely convinced that all 3 views are compatible with the
pi-calc and almost isomorphic. It is just our interpretation of what we
think the pi-calc gives us that is different. I am also convinced that
1) is superior to 2). This leaves the choice between 1) and 3). 

What I like about 3) is really that the notion of MEP is part of the
metamodel (BPSS has only a few MEP but the model would work with any
type of MEP). The other thing I like is that it offers a neutral view.
That is really useful for standard committees like RosettaNet, STAR,
OAGIS, and the several hundred others that need to define industry wide
choreographies. This view lands itself relatively well in an
architecture that requires "agreements" between partners, whether they
are statically specified or dynamically calculated as partners engage in
a business relationship.

I don't see all these characteristics in WSCI. Now don't get me wrong, I
am not suggesting to start or adopt BPSS. I am just pointing out some
benefits of the spec. BPSS was designed within an architecture with some
requirements. I believe that this group works in a relatively different
context.

Ultimately there should be a requirement that help us differentiate from
1) 2) or 3). 

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