- From: Howard N Smith <howard.smith@ontology.org>
- Date: Tue, 15 Apr 2003 22:03:41 +0100
- 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. Howard >Cheers > >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 >>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 >> >> >>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. > >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 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 17:04:25 UTC