[Zope3-dev] Workflow

[Shane Hathaway]

kapil thangavelu wrote:
> On Wednesday 06 November 2002 12:56 pm, Shane Hathaway wrote:
>>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.
> 
> 
> i agree, let abandon them. i'm not sure why there is this discussion about 
> unifying different implementation paradigms?. the real issue imo, is mapping 
> the wfmc semantic model onto the workflow interfaces, to allow for pluggable 
> implementations, an engine service that proxies to an implementation and 
> providing a default implementation for z3. am i missing something?
> 
> the wfmc model provides the experience of many real world implementations and 
> the possibility of interop with other systems.

The wfmc model should be the basis for one kind of process definition. 
Another kind of process definition will be a state diagram, which is 
easier for non-geeks.  Yet another kind of process definition will be 
pure Python code, which is easier for geeks.  Note that the process 
definition varies independently of the workflow engine.

>>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.
>>
> 
> 
> this is a really good point/idea...

Thanks.  I really believe this is the right way to move forward on workflow.

>>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.
> 
> 
> but architecturally this is overly constraining, imo. for example, i'd really 
> like to store my process instances in an rdb.

I didn't specify *where* the process instances are stored--in fact, I 
had RDBMS in mind when I said that. :-)  As it turns out, when you put 
content staging in the mix, you really can't store process instances as 
attributes of the content objects, since workflow status should not be 
reverted when a content object is reverted to an earlier revision.  So 
CMFStaging stores DCWorkflow process instances separately from the 
content, solving a potentially nasty issue.

> what about a workflow engine/service subscribe to wf events and provide 
> interface implementation that proxies/delegates to registered workflow 
> implementations that have the freedom to implement interfaces as they wish. 

That sounds right!  I hope I understand correctly, though. :-)

Shane