Re: Internal processes and/or external choreographies (was RE: Ev ents and States ...

Burdett, David wrote:

> Assaf
>
> I totally agree with you that we need to work out the basis for what 
> we are going to - is pi-calculus or something different and having 
> read your response.
>
> I also agree, especially after reading your response, that it would be 
> a good idea for us to explore pi-calculus further.
>
> Right now I am totally open-minded as to what approach we should 
> follow and really find this discussion useful.
>
> A few minor comments (no questions) inline.
>
> Thanks
>
> David
>
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Sunday, April 13, 2003 6:07 PM
> To: Burdett, David
> Cc: 'Martin Chapman'; 'Cummins, Fred A'; jdart@tibco.com;
> public-ws-chor@w3.org
> Subject: Re: Internal processes and/or external choreographies (was RE:
> Ev ents and States ...
>
>
> David,
>
> Before answering your question we need to decide on what path to follow.
>
> The example I have given is loosely based on the pi-calculus model but
> using a more friendly syntax. Inventing yet another process calculus
> language is not interesting and not what we're here to do. We want to
> define a language for WS choreography and that means we need to look at
> more specific issues regarding Web services and how we plan to use them.
> <DB>Agreed</DB>
>
> Having said that, we need to decide where to take that discussion. Let's
> assume for a second that pi-c is an interesting model we want to use. So
> the next question is: how do we make a language out of it that deals
> with WS. We will definitely need a construct called choreography that is
> different from a construct expressing a role's play in the choreography
> (both of which are called a process in pi-c). We will need to talk about
> WSDL operations and services (end-points) instead of just channels.
>

> <DB>I also agree, it's just that the idea of two or more co-operating 
> processes is the what makes a choreography different as there can be 
> no central "engine" that controls the whole process.</DB>
>
Now, this is an interesting point that I think we should pick on.

At the pi-c level this is in fact the only type of processes you have: 
they all co-operate with each other without the benefit of a central 
engine. So if you took some executable process and wrote it down using 
pi-c, you end up with a set of co-operating processes that do not 
require a central engine.

But, some of the things you want to do in a higher language like 
BPEL/BPML is handle state variables, loops, etc. When you reduce it to 
pi-c it ends up as being independent cooperating processes. But to make 
the language more usable, it proposes some constructs like properties, 
exception handlers, loops, etc. These all require some cooperating 
processes that the engine creates for you, and by doing so requires you 
to have an engine in there, but also simplifies the language.

If you look at the until loop example I gave in response to Ricky's 
e-mail, it contains two processes. You can write it as such with no 
central engine, or you can ask the engine to provide one of these 
processes for you using some high-level until construct, in which case 
you become dependent on an engine. A language like BPEL/BPML is simply a 
combination of your processes and some engine processes that co-operate 
hence requiring an engine to exist.

In the case of choreography, there as some places where you can assume 
an engine (e.g. two activities performed by the same service) and others 
where you cannot (two activities performed by two different services). 
So in the second case you would combine these activities using some 
construct that is entirely a pi-c composition, say a 'choreography' 
construct. In the first case you would combine these activities using 
some engine construct which forces them to be located within the same 
engine, e.g. in WSCI you would express that using the 'all' construct 
and in BPEL using the 'flow' construct.

> <DB>Part of my confusion with your earlier email was that when yous 
> wrote "Send Order" I assumed that order was a message whhen in fact it 
> was a channel.</DB>
>
There are two ends of the spectrum here. The pi-c model is very 
low-level and it doesn't care much about reuse, so you need a lot of 
channels, too many to make it practical. There is no notion of service 
end-points that can support multiple operations, or message families. At 
the language level we do care about reuse so we do want to introduce the 
ability to multiplex channels over a single end-point and we do want to 
use message families. So one way to do that is by creating more suitable 
higher-level constructs that can map to the lower-level model but give 
you that level of reuse and flexibility.

>
> <DB>Interesting! I see what you are getting at. Can you point a 
> suitable reference so that I can better understand pi-calculs 
> principles and grammars</DB>
>
Some references to pi-calculus and related material available at:

http://www.wisdom.weizmann.ac.il/~aviv/pi_links.htm
http://lamp.epfl.ch/mobility/

Two books you will see some of us carrying around (and pretending to 
understand) are:*

*The Pi Calculus, Davide Sangiorgi, David Walker
Communicating and Mobile Systems: the Pi-Calculus, Robin Milner

If you don't so much care about the theory and the math and just assume 
it works, but want to understand some of the principles I recommend 
reading the join-calculus reference:
http://join.inria.fr/

Join-calculus is a low-level programming language not a formal model, so 
it's easier for us techies to read. It also contains a lot of nifty 
tricks for handling shared variables, buffers, loops, etc using nothing 
but concurrent processes.

arkin

Received on Monday, 14 April 2003 15:29:01 UTC