- From: Jean-Jacques Dubray <jjd@eigner.com>
- Date: Tue, 15 Apr 2003 14:06:20 -0400
- To: "'Howard N Smith'" <howard.smith@ontology.org>, <public-ws-chor@w3.org>
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 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
Received on Tuesday, 15 April 2003 14:09:03 UTC