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 21:26:29 +0100
Message-Id: <5.0.2.1.2.20030415205702.0373a320@pop3.demon.co.uk>
To: jjd@eigner.com
Cc: <public-ws-chor@w3.org>

At 14:06 15/04/2003 -0400, 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).


I was making the point that in the computer science around the area
spearheded by Milner et al, everything IS a process, literally, and therefore
sometimes people from that world tend to use the term process to refer
to things that other people would not refer to as a process.

I dont think it is possible to cast Milner's work into the uni-cratic
systems you refer to, since he work, and that continues today, continues
to show how more and more things out there can be regarded as processes.
However, when I make that point, I am not urging that to be THE foundation
for everything here at ws chor. Having said that, in respect of BPMS as
defined by some of the BPMI.org co-founders, the BPMS is certainly
NOT a silver bullet. It is in fact a pragmatic next step which takes a
certain class of problems outside of the rhelm of "software" and into
the world of process data. BPMS is not a panecea solution, nor is it
intended to be. Similarly, RDBMS was not a panecea solution, dealing only
with the data model.

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

I think we are not yet at the point where such judgements can be made.

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

No one is saying pi-c = ws chor spec JJ. No one is telling anyone to
implement whatever ws chor comes up with using pi-c. pi-c is a body
of work from which this group can draw, either in developing the ideas
for the eventual spec, or in the development of products.

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

MEP = message exchange protocol? Or something else? Example?

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

I'm not sure at this point what you mean by a choreography specification
JJ. Happy to discuss in voice then report back to group.

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

I dont think so. I think the pi-c and the numerous other threads and types
of process calculi "out there" are really just "on the table" for this group.
They come from good names.

Milner took more than that perspective I think. For example, it should
be possible to communicate about a communication. Look, this is not
a "pi-c rules the world" issue. It's a "pi-c has illuminated the world" issue.
Really, I dont want to be dogmatic and I dont want you to react to every
message I send as if it is. It isnt. It is of course quite the case that
higher level semantics for communication can be developed, for example,
I had experience with KQML some years ago. It was quite wonderful, but
ultimately did not work out for me, because while it provided some really
neat semantics (which had to be implemented in the agents .... and believe
me they were really neat ... stuff like agents asking agents if they know
of agents that can solve problems on behalf of other agents, where the problem
was expressed in KIF ....) the set of KQML primatives, while interesting,
entensible, flexible etc, turned out not to be scaleable. So one of the things
we tried to do in BPMI.org was find some low level stuff which could be used
to implement higher level stuff. A low level machine, able to implement
high level business processes.

Late here in UK, rambling. Over and out. See my suggestion for spliting
out 3 sub-groups (cases, specs and theory).

Howard


>Jean-Jacques Dubray____________________
>Chief Architect
>Eigner  Precision Lifecycle Management
>200 Fifth Avenue
>Waltham, MA 02451
>781-472-6317
>jjd@eigner.com
>www.eigner.com
>
>
>
> >>-----Original Message-----
> >>From: public-ws-chor-request@w3.org
>[mailto: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
>and/or
> >>external choreographies (was RE: Ev ents and States ...
> >>
> >>
> >>David,
> >>
> >>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
> >>orderManagement".
> >>
> >>and:
> >> >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
> >>commonplace
> >>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
> >>technology
> >>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?
> >>
> >>Thoughts?
> >>
> >>Howard
> >>
> >>
> >>---
> >>
> >>New Book - Business Process Management: The Third Wave
> >>www.bpm3.com
> >>
> >>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
www.bpm3.com

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

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