Re: Why workflow is NOT just a Pi-process

Folks,

This is to let you know that Wil and I are in discussion over this topic. What will come out of that 
I'm not clear yet, but we'll keep the group informed. What I can say at this point is the following:

1. I believe that it is not possible to analyze BPML against Wil's workflow patterns without taking
into account the capabilities of the technology (process virtual machine) that is intended to go
along side the specification. This would also be true of any significant BPEL runtime. Having
spoken to vendors intending to develop BPEL runtimes, they would also plan to implement
workflow patterns, and workflow engine functionality, using BPEL patterns at a lower level, 
just as we shown is possible with BPML in our paper and through reference to Intalio's work
with BPMI.org. Thus, I do think Wil's paper has to be read in that light. It was to bring to light
another way of looking at things that we wrote the paper. I can assure you that all of Wil's
patterns are quite easy to do in BPML. Of course, building up an end to end process using
these patterns is not how business and technical architects actually work when using a BPMS
like Intalio n3. They just model-away using BPML in a natural kind of fashion. Some of Wil's
patterns will appear in that, but often not explicitly. However, from Wil's perspective, the patterns
exist and can be supported, as reusable process idioms. Idioms is a word we may hear
about more in the future in the concept of process reuse.

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

After all, this process data unification lies at the heart of why we want BPMS.

The fact that we focussed on workflow for this article was simply because there were outstanding
items to discuss between WfMC and BPMI with respect to our joint work. In fact, Computer Sciences
has also used BPML to model ERP, B2B, EAI to show it can be done. In some cases the BPML
stands alone, in other cases it proxies for technology integrated to BPMS via projection and turns
services into processes, federating computation into existing technologies where clients wish
to reuse those.

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).
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 Tuesday, 2 December 2003 06:47:40 UTC