[Zope3-dev] Workflow

[Shane Hathaway]

Florent Guillaume wrote:
> As a prelude to the work on workflow that will take place at the
> Sprintathon, and before we hash out the needed interfaces and concepts,
> I've written a document where I try to explain the different workflow
> paradigms and look at them with an eye to finding a common ground.
> 
> It's at:
> 
> http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TryingToUnifiyWorkflowConcepts
> 
> Please comment.

Several comments have been posted now, but now something is wrong with 
the wrapping on the page, making it difficult to read.

So I'd like to express my POV again, perhaps a little better this time. 
I think there are really two independent concepts being sorted out, and 
once you separate them, the solution is clearer.  The term 
"activity-based workflow" refers to usage of UML activity diagrams.  The 
term "entity-based workflow" refers to operating on a single object at a 
time.  These two concepts are not in competition with each other at all. 
  I think we should abandon them.

For the purpose of this discussion, I want to introduce the terms 
"object centric" and "application centric" workflow.  Object centric 
workflow assumes that the user first finds an object (a noun) then 
chooses what to do with it (a verb). DCWorkflow behaves this way. 
Application centric workflow assumes the user first chooses what to do 
(a verb) then the application figures out which objects to operate upon 
(nouns).  OpenFlow does this.  Object centric workflow is meant to be 
integrated into existing applications, while application centric 
workflow is the probably the main focus of the application.

DCWorkflow is object centric and uses state diagrams with no 
concurrency.  OpenFlow is application centric and uses activity 
diagrams.  If we wanted to, we could upgrade DCWorkflow to use activity 
diagrams (or state diagrams with concurrency), but remain object 
centric.  Or we could instead choose to move to an application centric 
model while retaining state diagrams.  These two choices are really 
independent.

In my comment I suggested a new kind of object called diagrams.  But 
maybe that's not quite general enough.  What we really want is multiple 
types of process definitions.  OpenFlow only allows one kind of process 
definition based on an activity diagram.  But a state machine, a petri 
net, or a pile of Python code can also be a process definition.  So we 
need to define the interface that process definitions support, and it 
must be simple enough to implement in a short Python module.

Then we should build a simple workflow engine that uses any kind of 
process definitions.  The responsibilities of the workflow engine are to 
store process instances, subscribe to the events that active process 
definitions are interested in, and invoke processing when events occur.

Then the difference between object-centric and application-centric 
workflow is simple: in an object-centric workflow, there is a mapping 
from object to process instance, while in an application-centric 
workflow there is a mapping from user (or role) to process instance. 
Stated differently, in an object-centric workflow you make the user find 
an object and then invoke some workflow action on it; in an 
application-centric workflow you present the user with a list of all 
tasks they are supposed to complete (and the user may never visit 
"objects").  In reality, you can combine both views into one system, 
which I expect most people want to do.  DCWorkflow tries to combine the 
two with "worklists", but is only partly successful.

There is an interface in CMFCore called WorkflowDefinition.  It is 
similar in spirit to what I am proposing for the interface of process 
definitions, but the methods are too numerous and have the wrong names. 
  It's still a start.

Anyone see it differently?

Shane