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

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

From: Howard N Smith <howard.smith@ontology.org>
Date: Mon, 14 Apr 2003 18:47:02 +0100
Message-Id: <>
To: "Burdett, David" <david.burdett@commerceone.com>
Cc: public-ws-chor@w3.org

At 09:43 14/04/2003 -0700, Burdett, David wrote:
> >You make very good points that I just about completely agree with. However,
> >at the end you ask ...
> >>>Is there anything in this abstract "choregraphy" space that is NOT a
> >>>process, that cannot be "described" using process calculus?<<<
> >I think that the answer to your question is quite possibly "no" and that a
> >pi-calculus approach would deliver the results we need. The way I think we
> >determine the answer to this question is by checking how well and *simply*
> >pi-calculus can meet the requirements.

I agree. And I think that Assaf should inform us of any other mandatory
"process calculi" concepts we are going to need, based on his work at
BPMI.org developing BPML, and it's practical implementation in n3.

> >This makes me think that perhaps we are getting a bit too far ahead of
> >ourselves and we should focus on the requirements of the solution and in
> >parallel give some of us folks who do not understand pi-calculus very well,
> >an opportunity to catch up.

It is absolutely right to identify the problem first of course. Steve, am I 
right that the
primary interest from a W3C perspective is to further the goal of 
distributed computing
on the web. Choregraphy was seen as a key step, not only because it was 
coming up
in other W3C work (arch), but because the B2B community were using that 
term and it
appeared in various specs and papers surrounding BPM standards, such as BPML,
WSCI, WSCL,  BPEL4WS, WSFL, XLANG, BPSS ... The time was right.

The language in the charter speaks of adding precision to WSDL natural language
supplements, and also to support business process integration. It does not 
speak of
BPM or BPMS. May I offer this suggestion, especially since BPEL4WS has not yet
been submitted to this group, and may be submitted elsewhere. Surely, the group
should split into a couple of activities:

1. To look at ALL related specs in the field, and make a compendium of all 
the constructs
they use to support this "choreography". Work should be done to identify 
differences, etc, and to look for the powerful mechanisms that are the 
you are looking for.

2. Separately, another group make a use case list, as is being done, to 
the expected applications. This is quite hard, because the expected 
applications are
only the ones we can think of, and this will be dominated by the difficulty 
people have
had being B2B, BPI etc. There are of course a host of "BPM" applications 
that might
fall outside because when a breakthrough like BPM happens, we just dont 
know what
clients will do. I wonder whether Codd and Date could have predicted ERP. 
such a use case list has to be done. The trouble is, its endless. There are 
a myriad
"choreographies". So we are going to need advice on how to bottom this out, 
the p-c theorists. Isn't it something about types, not of values, but of 

3. So we need a 3rd group, a theory group, a group to look at pi-c and 
other process-c
stuff, and to document the experience of groups such as BPMI.org and 
Microsoft, who
have looked into this.

Group 1 can get started right away. They should be people not involved in the
development of the specs, but they need access to the primary spec author in
order to clarify the purpose of the spec.

Group 2 is already started, and I recommend including Customers in this group.
Formally. This would add considerable weight to the W3C effort.

Group 3 is a small group of people already into this p-c stuff. Their job is to
educate the group, succintly, and therefore are really consultants to the 
This would include Assaf, Lucian, Greg Meredith etc.

I see us going forward only in terms of a plan like this. The mailing list 
right full is full of
posts and responses, and this helps, but its not going to get to a result 
very quickly.
Really, I suggest time boxing with a plan and deliverables from the three 

Just my suggestions.


>-----Original Message-----
>From: Howard N Smith [mailto:howard.smith@ontology.org]
>Sent: Monday, April 14, 2003 7:07 AM
>To: public-ws-chor@w3.org
>Subject: Terminology - What is a process? Was: Internal processes and/or
>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 them.
>I also like the word Choreography >rather than process (as you describe),
>so perhaps a better name would be something like "Choreography
>  >2. Following on in the same theme, using "process seller" and "process
>buyer" is ambiguous as you will have more than one process at the buyer and
>seller. So how about "process >acceptOrder" and "process placeOrder" where
>each has a property that identifies the role which performs the process
>giving you: "process acceptOrder, role seller" and "proccess placeOrder,
>role buyer".
>For the "process calculus people" in the group, everything is a process,
>even the humble integer. (I think that was what Assaf just naturally did).
>In the pi-calculus,
>everything is a process - formally. This group, and the industry at large,
>may have started to use the word "choreography" but the term has no basis
>in any
>previously published theory, and hence, everyone is using it and defining
>it differently. Similarly, to process calculus people, the seller and the
>buyer are
>also processes. In BPM as used in CSC, processes participate in processes.
>The result is also a process.
>This "everything is a process" position that process calculus people take
>is in fact quite real. It is the same position taken by object people in
>object systems.
>CSC defines BPM as really a new technology, based on processes. It depends
>upon implementations, which we call process virtual machines. The
>language we used in our book, BPM: The Third Wave, to explain this to the
>world at large is to talk about "first class citizens" in computing. Every
>has a conceptual center, sometimes defined very formally and sometimes less
>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 technology,
>but the central entity around which all computation and communication
>occurs. This is what gives BPM its ability to manipulate process, as RDBMS
>does relational data. It is what gives BPM its expressiveness in defining
>sophisticated meta-process models that adhere to other process semantics,
>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 at
>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 question
>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


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 Monday, 14 April 2003 13:47:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:01 UTC