RE: pi-calculus ...

Nickolas:
 
Thanks for your answers.

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


[JJ] You'll have to explain. I actually thought that scopes could be
used to specify MEPs.

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


[JJ] What computation? Why do you think that ws-chor is tantamount to a
computation? IMHO, a choreography state advances merely because the
agent processes that participate in the choreography are changing
states, the choreography itself does not have any run-time to rely on or
compute anything. Each agent could have a boundary layer to verify that
the message exchange complies to the choreography specification but I
don't consider that the run-time of the choreography. When I look at
pi-calculus, I actually just see that picture (agents collaborating and
their message exchange could be expressed via a choreography
definition).

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


[JJ] It does not give you a neutral view of the choreography since it is
precisely the views of each process which is represented or expressed.
This is very clear in WSCI for instance.

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

[JJ] Yes, there is a need for choreography language at this level too. I
think we already started to talk about that.

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


[JJ] So are other specifications like BPSS. It is important to use WSCI
as an input but I am not sure about using it as an output ;-).

I will construct the WSCI metamodel, unless someone else has this
information handy. As far as I can remember it is very close to the BPML
0.4 metamodel so I should be able to construct it quickly.

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 15:41:16 UTC