W3C home > Mailing lists > Public > public-ws-chor@w3.org > February 2003

RE: Dubray paper comments + questions

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>
Message-ID: <IGEJLEPAJBPHKACOOKHNIEDODEAA.arkin@intalio.com>



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:29:54 UTC