Re: Why workflow is NOT just a Pi-process

I really don't think that this debate is going anywhere.

I could say that everything can be represented as assembler but does 
that help me in any way?
I could say that everything can be modeled in logic but does that help?

Alas saying that workflow is just a pi-process is not helpful.

The pi-calculus (and higher order forms of process algebra) can be used 
to model many things,
including workflow. After all the pi-calculus is turing complete and 
has (as Greg Meredith has oft
stated) a number of interesting properties that allow us to reason 
effectively about pi-calculus
models.

I understand Howard's attraction to a simple unifying model of 
computation, of which the pi-calculus
is a candidate. So Howard is correct in asserting that workflow is a 
pi-process but it's just not a useful
thing to say for most people.

On the other hand JJ suggests that you cannot represent workflow as a 
pi-process because it lacks
the higher level semantics (roles etc). Just because it doesn't support 
them as syntactic sugar doesn't
mean that you cannot do so.

The fact that the pi-calculus unifies the notion of data and process is 
not a bad thing. It is a good thing. It
has a use in that you can model interaction with data and with 
classical notions of process using the same
underlying model. This in turn allows you to reason about the systems 
that you model more fully.

JJ also suggests that the pi-calculus works well for low levels of 
nesting. I'm not quite sure I understand what
is meant by "levels of nesting". But if this is to include or be 
equivalent to recursive composition then the pi-calculus
is scale invariant with respect to composition. It doesn't change and 
so is well suited to as many levels as you
want to go to. So, unless I misunderstand, the assertion is incorrect.

On the other hand JJ's point does beg the question "is it useful to 
model workflow using the pi-calculus?.
To answer this (and I don't intend to at this point) we have to ask 
another question, namely "what is it we
want to know about a workflow that we can only understand by leveraging 
the pi-calculus?".
If the answer is nothing then it is not useful to say "workflow is just 
a pi-process". If there is something
then clearly it is useful to say "workflow is just a pi-process".

If it turns out that it is useful then we will be able to understand in 
what context a workflow should be modeled
in this way (is it just the execution platform or the language that 
described the workflow?).

Perhaps better minds that mine could provide a single paragraph on why 
the pi-calculus is useful in this regard.

Cheers

Steve T



On 3 Dec 2003, at 02:16, Jean-Jacques Dubray wrote:

> 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, 
> BPML/BPEL
> 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

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.

Received on Wednesday, 3 December 2003 04:33:10 UTC