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

RE: Why workflow is NOT just a Pi-process

From: Andrew Berry <andyb@whyanbeel.net>
Date: Wed, 03 Dec 2003 17:44:09 +1000
To: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com>, public-ws-chor@w3.org
Cc: "Greg Meredith" <gregmer@microsoft.com>, "'Haugen Robert'" <Robert.Haugen@choreology.com>
Message-Id: <20031203074409.36E007E4AF@server2.messagingengine.com>

+1 to Jean-Jacques' comments and a slightly more formal addition ...

The key problem with pi calculus is that its operational semantics
assumes a global namespace and arbitrary synchronisation on names shared
by processes.  While you can create a modelling layer above this that
uses conventions to provide partitioned namespaces (e.g. ensuring that
names are not shared by distributed processes), any semantic analysis of
such models you make based on the pi operational semantics is potentially
invalid.  Basic semantic properties like composability and deferred
choice are also broken unless the "conventions" are applied to their use.
 To formalise the conventions, you have to modify some of the core
operational semantics of pi calculus.  If you don't formalise the
conventions, then you might as well be using UML or some other modelling
notation with a less formal but more widely-recognised semantic model.  

Personally, I would approach the modification of the core operational
semantics of pi calculus with considerable caution.  The need for
semantic concepts reflecting time, causality and locus of control
(autonomy) just add to the semantic modelling burden.  I'm not saying it
can't be done, but I am asserting that vanilla pi calculus cannot
accurately model distributed workflow processes amongst autonomous
participants.  Or in other words, workflow is not just a pi process.



On Tue, 2 Dec 2003 18:16:59 -0800 , "Jean-Jacques Dubray"
<jeanjadu@Attachmate.com> said:
> We may also want to keep Phil Wainewright in the loop, he is keeping
> track
> of the debate and already wrote a very good summary:
> http://www.looselycoupled.com/blog/2003_11_23_lc.htm#107015401001130588
> This article could also be titled: "why pi does not matter..." 
> 2. I think what we meant to imply by using the title "Workflow is just a
> Pi
> process" is that there is something foundational about the Pi concepts
> that
> allow us to model higher level processes, including workflow-like
> processes.
> We could have equally written papers with the following
> titles:
> ERP is just a Pi process
> SCM is just a Pi process
> B2B is just a Pi process
> Adding Up is just a Pi process
> Managing A List is just a Pi process
> EAI is just a Pi process
> Data is just a Pi process
> etc
> <JJ>I think we should define what "models" means. If it means express all
> the semantics of the things listed above as a pi-process, Intalio's N3
> designer tool might be falling a bit short.
> For instance, I understand that a PO business object can be modeled as a
> process, actually it will require that all instance variable of this
> object
> be a pi-process itself, not to mention the database in which it is
> stored,
> and so on...
> I am wondering why SAP and PeopleSoft have not yet released a pi-version
> of
> their ERP system?
> </JJ>
> Just to clarify. If you look at some of the swimlane diagrams in the
> paper,
> each swimlane is a BPML process in its own right (the XML form and
> notational form being just alternate notations).
> <JJ>I think you just touched the fundamental issue I have with pi,
> and Intalio's product
> As I understand it, Pi and Intalio's product do not allow for role
> separation (since a role IS A process). Since everything is a process,
> there
> is no way to introduce the notion of domain of control or independent
> role,
> everything is capable of exchanging messaging with everything at all
> levels
> (that looks pretty evil to me, though Howard seems to argue that this is
> great in the paragraphs below),
> I can easily conceive that choreography is not not needed as long as you
> have process composition, but what choreography buys you is precisely
> this
> notion of domain of control that does not seem to exist in what I have
> seen
> so far. Pi works wonders in a wireless system where the levels of nesting
> of
> pi-processes are relatively low. However, I cannot imagine the disaster
> for
> an ERP system or a workflow where the level of nesting could reach
> infinity
> (in computers terms). 
> This is precisely because this notion of domain of control does not exist
> that BPEL/BPML are going through excruciating pain to create the concept
> of
> an abstract process, to precisely define the boundaries that do no exist
> in
> the theory. As a matter of fact, pi just by itself, cannot cross company
> boundaries. I think that this is what howards says in the next two
> paragraphs.
> Maybe there is a business opportunity to run Intalio's Process Virtual
> Machine in an ASP model, running all pi-processes in the world. Then the
> problem will be solved.
> </JJ>
> The process virtual machine within the BPMS creates end to end processes
> out
> of piecemeal processes at all levels. This is where the Pi concepts come
> in,
> since the interaction between swimlanes is of course mobile behavior as
> defined by Milner. We chose email as an example as it is a recusive
> process
> with this characteristic. We have found similar characteristics with
> change
> management processes, record keeping processes etc. We see no
> correspondence
> between these and typical workflow processes as WFMS have been typically
> applied in business. 
> It feels very different to me in practice.
> I believe that the significance of choreography lies at the heart of
> this,
> which is kind of why a subset of BPMI.org members submitted WSCI, based
> on
> BPML, to this group, as a first step towards unification. After all, it
> is
> WSCI-territory that allows multiple technologies from existing players
> (even
> if they have no intention to build a BPMS) to be used in conjunction with
> each other. 
> Howard
Received on Wednesday, 3 December 2003 02:46:37 UTC

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