- From: Assaf Arkin <arkin@intalio.com>
- Date: Wed, 26 Feb 2003 15:42:25 -0800
- To: "bhaugen" <linkage@interaccess.com>, <public-ws-chor@w3.org>
> -----Original Message----- > From: bhaugen [mailto:linkage@interaccess.com] > Sent: Wednesday, February 26, 2003 2:30 PM > To: Assaf Arkin; public-ws-chor@w3.org > Subject: Re: Dubray paper comments + questions > > > 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. I have not read those with detail. At some point I had a hundred or so bookmarks to different models and tons of printed stuff, so I decided to borrow from Google's page rank system. The models that were referenced the most had the higher rank, the more obscure or less used one were removed. I also removed anything that was too specific, e.g. only good for document workflow, only good for real-time, only good for mobile phones, etc. Anyway, is there a definition of state-alighment there that we could borrow? > Documentary Petri Nets (somewhat of a combination). Indeed Petri nets has a different style, but I don't understand how it relates. Are you saying that the state-alignment is the transition? How is that different from expressing a Petri net in terms of input and output of transitions (e.g. NETC)? More interesting would be to look at Mobile Petri net [1][2] which is an extension of Petri net to support mobility, being able to describe such interactions as exist on the Web, and borrowing from the ideas introduced in join calculus. > Consensus protocols. Most concensus protocols I have seen are expressed in terms of CSP and similar algebra, e.g. Paxos or Chandra-Toueg. In Paxos you have send/receive which are used to reach concensus by performing several rounds and each state machine is described as a communicating agent (aka I/O automata). To tolerate failure the communication is intentionally asynchronous send/receive, which seems to go against state-alignment, though invariable this use of the CSP model does result in perfect state alighment even in the face of failure ;-) Distributed Algorithms (Nancy A. Lynch) provides a coverage of many protocols not just for concensus. All the algorithms there are listed in terms of communicating agents. I haven't read all the concensus protocols in existence, only a few, but from the few I've read I could conclude that we made a wise decision in basing the WSCI/BPML process model on the same one used in these concensus algorithms. It makes it easier to express exactly how concensus is reached. Of course, in a higher level language I would not care about the details. I would just say 'reach state alignment regarding purchase order, use whatever service you see fit'. But when I talk about services I do end up caring about these details. One could say that I have a service-level problem to solve which would allow such high-level languages to exist. > 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. I agree. But when it boils down to a service oriented architecture, are these not differences that can be abstracted and managed at a different level, e.g. WS-Policy? At least in my mind, the service choreography could be expressed in generic terms, after all it does not understand the different between a company domain and a department domain, it only understands a generic notion of a domain. A B2B collaboration would like to use policies that relate to company domains. So when you write a B2B collaboration using the service choreography you would elect that one set of policies. An A2A collaboration would like to use policies that relate to department domains. So when you write an A2A collaboration using the service choreography you would elect to use department policies. It all boils down to deciding which service is exposed to which set of participants, and just like you apply access control and PKI you can apply domain-specific policies. You then decide which service to publish where, privately in your internal UDDI, or publicly in some public UDDI, etc. A clear level of separation between the generics of a SOA-based choreography, a generic framework for supporting domains, and a concrete set of specifications for specific domains and a reuse of all three in different enviroments. arkin [1] High-Level Petri Nets as Type Theories in the Join Calculus Grazia Buscemi, Maria and Sassone, Vladimiro, Universita di Catania, 2001 http://tosca.dmi.unict.it/tosca/html/tasks/CalcoliOggetti/papers.xml [2] Mobile Petri Nets Asperti, Andrea and Busi, Nadia, University of Bolonga, 1996 ftp://ftp.cs.unibo.it/pub/techreports/96-10.ps.gz > > -Bob Haugen
Received on Wednesday, 26 February 2003 18:43:59 UTC