[Zope3-dev] Workflow

[kapil thangavelu]

On Wednesday 06 November 2002 12:56 pm, Shane Hathaway wrote:
> 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/TryingTo
> >UnifiyWorkflowConcepts
> >
> > 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.

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.

an excellent intro doc to workflows (discusses mapping petri net 
implementation onto wfmc model) is

http://wwwis.win.tue.nl/~wsinwa/jcsc/jcsc.html

that paper is the basis for the workflow engine in openacs, which maps the 
petri net model onto oracle/pg. also, the author of that engine expressed 
some concerns with his implementation which i think are also relevant 
(keeping in mind this is for a completely different system than zope).

"""

# It's too restrictive. In most knowledge worker use cases, you want to be 
able to let your employees override the process and do something else when 
they need to. Or you can make a mistake and close out a task too early or 
take the wrong turn somewhere. You have to be able to go back and change 
those things. In some situations you even want to be able to redefine the 
process on the fly. The current workflow doesn't allow for any such 
flexibility.

# The UI sucks, and it's really hard to use workflow without using the 
interface. There should be a clean API that you can use if that's all you 
want, and then a clean interface built on top of that, which you can use or 
not use as you please.

# Petri net is just too complicated in many cases. There are two possible 
approaches: Make pluggable models, so you can use the model of your choice 
directly. I think this is the preferred method. The alternative is to have 
Petri Net as the solid foundation, and implement the others as two-way 
translations between petri nets and the other model. The advantage here is 
that your process analysis tools can stay the same, but since we don't really 
have any of those, anyway, it's not much use.

"""

basically the things i take away from it are that their should really be some 
default wf policies that map onto common needs so we don't overburden 
users/developers with complexity and 'confusing jargon'. 

full doc at
 http://openacs.org/projects/openacs/proposals/workflow-spec

the docs on their implementation are here (some good general wf discussion as 
well) 
 http://openacs.org/doc/acs-workflow/

> 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...

> 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.

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. 

-kapil