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

Re: Terminology - What is a process? Was: Internal processes and/or external choreographies (was RE: Ev ents and States ...

From: Howard N Smith <howard.smith@ontology.org>
Date: Tue, 15 Apr 2003 22:03:41 +0100
Message-Id: <>
To: Steve Ross-Talbot <steve@enigmatec.net>
Cc: "Jean-Jacques Dubray" <jjd@eigner.com>, <public-ws-chor@w3.org>

At 20:59 15/04/2003 +0100, Steve Ross-Talbot wrote:
> >Whilst we could send such a question to Prof Milner he is pretty pressed 
> for time. Lucian is a better bet because he understand the Web Services 
> architecture and certainly has >Prof Milner's blessing. He is also busy 
> but I am happy to
> >pass on the request if you wish me to do so.

Having had limited interaction with Robin, it is certainly the case that he 
is not in a position to get directly involved in W3C work.
I think Lucian and Assaf can easily handle this request, and I think the 
two of them should take a look at it.

> >My own observations suggest that pi and/or higher order pi is rich 
> enough and appropriate to use as a basis for expressing choreographies.

I concur.


>Steve T
>On Tuesday, April 15, 2003, at 07:06  pm, Jean-Jacques Dubray wrote:
>>Following your comment that "everything" is a process, shouldn't we
>>expect that any 100% pi-c based solution will follow the same fate of
>>other "uni-cratic" systems like Java, C, SQL, COBOL, ... i.e. severe
>>limitations/complexities outside the realm of applications for which
>>they were designed (e.g. EJBs versus Classes).
>> From what I can see the web-service architecture has a rich set of
>>constructs that can only be diluated if everything becomes a "process".
>>The way I understand the role of ws-chor is to provide a metamodel with
>>which one can model "choreographies" message exchange between web
>>services. If there is a requirement for this metamodel to be as simple
>>as possible, there is also a requirement that this metamodel must be
>>rich enough such that expressing choreographies does not become "heary".
>>Of course we can always talk about tool(s) breaking that hearyness, but
>>then the babel effect comes into place where each tool coming with its
>>"features" will in essence create semantic island which will make
>>comparing choreography specifications difficult at best.
>>With respect to pi-c no matter how I stear at it I don't see an explicit
>>choreography specification. All I see is the specification of the
>>behavior of agents which are capable of communicating which each other.
>>If you take the example: _xy.0 | x(u)._uv.0 | _xz.0, it expresses the
>>behavior of each agent and the composition "point" but by no means the
>>"choreography" is "visible" there. Furthermore, pi-calculus seem to be
>>limited to request/response message exchange patterns (I'd be curious to
>>know how one would model complex MEPs).
>>Ultimately, a ws-choreography can and should be expressed in abstraction
>>of the agents that will implement this choreography and how they will
>>implement it.
>>Respectfully, I would be very interested to know the opinion of Prof.
>>Milner about whether a choreography specification is already present in
>>the theory or not, and its relevance with respect to the design and
>>binding of collaborating agents. Milner took the perspective of
>>autonomous agent that need to communicate with each other via very
>>simple protocols, he has not necessarily addressed the problem of
>>expressing choreographies for which agent will be designed (or
>>configured). Of course the problem are intimately related but aren't we
>>looking at the specification (ws-chor) and the implementation (pi-calc)?
>>Overall what is needed is an appropriate metamodel for web service
>>choreographies. We should leave the implementation details to the
>>vendors where some could decide that the best way to implement a given
>>"side" of the choreography is to use a pi-c interpreter, hence compiling
>>the choreography into a process definition.
>>Jean-Jacques Dubray____________________
>>Chief Architect
>>Eigner  Precision Lifecycle Management
>>200 Fifth Avenue
>>Waltham, MA 02451
>>>>-----Original Message-----
>>>>From: public-ws-chor-request@w3.org
>>>>On Behalf Of Howard N Smith
>>>>Sent: Monday, April 14, 2003 10:07 AM
>>>>To: public-ws-chor@w3.org
>>>>Subject: Terminology - What is a process? Was: Internal processes
>>>>external choreographies (was RE: Ev ents and States ...
>>>>You made a couple of remark which I'd like to comment upon:
>>>>You said:
>>>>>1. I don't think I would call it "process buyerSeller" as buyer and
>>>>seller are roles and they can have more than one choreography between
>>>>I also like the word Choreography >rather than process (as you
>>>>so perhaps a better name would be something like "Choreography
>>>>>2. Following on in the same theme, using "process seller" and
>>>>buyer" is ambiguous as you will have more than one process at the
>>>>seller. So how about "process >acceptOrder" and "process placeOrder"
>>>>each has a property that identifies the role which performs the
>>>>giving you: "process acceptOrder, role seller" and "proccess
>>>>role buyer".
>>>>For the "process calculus people" in the group, everything is a
>>>>even the humble integer. (I think that was what Assaf just naturally
>>>>In the pi-calculus,
>>>>everything is a process - formally. This group, and the industry at
>>>>may have started to use the word "choreography" but the term has no
>>>>in any
>>>>previously published theory, and hence, everyone is using it and
>>>>it differently. Similarly, to process calculus people, the seller and
>>>>buyer are
>>>>also processes. In BPM as used in CSC, processes participate in
>>>>The result is also a process.
>>>>This "everything is a process" position that process calculus people
>>>>is in fact quite real. It is the same position taken by object people
>>>>object systems.
>>>>CSC defines BPM as really a new technology, based on processes. It
>>>>upon implementations, which we call process virtual machines. The
>>>>language we used in our book, BPM: The Third Wave, to explain this to
>>>>world at large is to talk about "first class citizens" in computing.
>>>>has a conceptual center, sometimes defined very formally and sometimes
>>>>so. To see what I mean here are a few first class citizens:
>>>>- COBOL, the report
>>>>- C, the pointer, function
>>>>- Java, the object
>>>>- EDI, the business element
>>>>- XML, the tag
>>>>- RDBMS, SQL, tuple, key
>>>>- EAI, application interface
>>>>- workflow, resource, task, case
>>>>etc etc ... realise this is rough, but you get the idea ...
>>>>The reason we identify the process as a new "first class citizen" is
>>>>because in BPM process is not a byproduct of another stack of
>>>>but the central entity around which all computation and communication
>>>>occurs. This is what gives BPM its ability to manipulate process, as
>>>>does relational data. It is what gives BPM its expressiveness in
>>>>sophisticated meta-process models that adhere to other process
>>>>for example:
>>>>- project plans, schedules
>>>>- B2B PIPs
>>>>- workflow patterns, task allocation
>>>>- collaboration patterns (votes, polls, committments etc)
>>>>- supply chain models
>>>>- other process languages
>>>>It is what gives BPM it's completeness. What we have been looking for
>>>>BPMI.org and CSC, is a new first class citizen that can express
>>>>many of the others, so that we can manage them as processes. A
>>>>that comes to my mind is:
>>>>- Is there anything in this abstract "choregraphy" space that is NOT a
>>>>process, that cannot be "described" using process calculus?
>>>>New Book - Business Process Management: The Third Wave
>>>>Howard Smith/CSC/BPMI.org
>>>>cell             +44 7711 594 494 (worldwide)
>>>>home office +44 20 8660 1963
>>This email is confidential and may be protected by legal privilege. If 
>>you are not the intended recipient,  please do not copy or disclose its 
>>content but  delete the email and contact the sender immediately. Whilst 
>>we run antivirus software on all internet emails we are not liable for 
>>any loss or damage. The recipient is advised to run their own antivirus 
>This email is confidential and may be protected by legal privilege. If you 
>are not the intended recipient,  please do not copy or disclose its 
>content but  delete the email and contact the sender immediately. Whilst 
>we run antivirus software on all internet emails we are not liable for any 
>loss or damage. The recipient is advised to run their own antivirus software.


New Book - Business Process Management: The Third Wave

Howard Smith/CSC/BPMI.org
cell             +44 7711 594 494 (worldwide)
home office +44 20 8660 1963
Received on Tuesday, 15 April 2003 17:04:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC