- From: bhaugen <linkage@interaccess.com>
- Date: Wed, 26 Feb 2003 16:30:00 -0600
- To: Assaf Arkin <arkin@intalio.com>, public-ws-chor@w3.org
Combining comments from a couple of messages: Assaf Arkin wrote: > It is common to define protocols in terms of communicating agents, and this > goes back to the days of CSP and later refined in various forms of process > calculus, most interesting being pi-calculus and action calculus. The TCP > yields well to that formalism (in fact requires it), so does the Web > (links=passing channels by names) and the manner in which an application > protocol can be described using WSDL in combination with WSCI or a similar > specification. > > It is also possible to pull that information together into a central > definition, hence the choice to use the term 'centralized', or as you call > it state-alignment protocol. I am not aware of any formal models that > describe communicating processes in that way, is there some better lingua > franca we could use? Conversational workflow models: Winograd, Action Workflow, Dooley Graphs. Documentary Petri Nets (somewhat of a combination). Consensus protocols. I think there are others. > From my perspective if you have worked to define all the participants prior > to engaging in any interaction, both models are identical and I do not have > preference for one or the other. On the other hand, if you prefer the > flexibily inherit in the Web model, being able to pass communication links > in messages and being able to cover discovery of services in the > choreography, then the formal process model is preferrable. For that problem I prefer speech acts and REST. > > > In all cases, the goal is more or less to achieve state alignment > > > between collaborating parties. > > > > Is it? Are the internal activities really aimed at state alignment > > between collaborating parties? > > No. But where do you read about 'internal activities'? There are very different forces operating on state alignment between different administrative domains, and procedural workflow operating under one administrative domain and especially one workflow engine. Combine the technical forces in the infamous Waldo paper with the trust forces between two businesses. If we separate the problems, we can have better + simpler solutions for both. -Bob Haugen
Received on Wednesday, 26 February 2003 17:34:12 UTC