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). It
>does not have also the notion of exception. 
>  
>
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. 
Each MEP is expressable as pi-calculus process, and the choreography is 
expressable as MEP, and you simply use macro expanstion to get a 
pi-calculus (or CCS) definition from the WSDL-based choreography (if you 
haven't used languages with macros think C++ pre-processor or templates).

>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.
>  
>
I think we discussed the P = Q | R before. Every other process is not 
reducible, so it actually forces you to look at the larger view, the 
global model if you will, though it lets you build it by composing 
smaller particles which can be reused in other contexts. That's the 
value for me.


>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, ... 
>  
>
My view as well.

arkin


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

Received on Wednesday, 7 May 2003 16:13:28 UTC