[Zope-CMF] Project-style workflows, DCWorkflow, SQL, etc.

[Phillip J. Eby]

At 05:36 AM 10/13/01 +0000, Kent Polk wrote:
>Shane Hathaway wrote:
>
> > - How do you implement subflows?  With DCWorkflow and the portal_types
> > tool, you can set up objects that get stored in workflowed containers.
> > The contained objects can have partially dependent workflows.
>
>This is (IMO) the big difference between entity based and activity
>based workflow. With activity based, you don't need to create some
>Item to have a workflow, and indeed, much workflow doesn't revolve
>around creating items, but mainly passing information around, often
>resulting at different points in creating both temporary as well
>as permanent informational items.
>
>Activity-based subworkflows are not (necessarily?) related to a
>created item, but to a request that someone or something is waiting
>on or for.

I'm not sure that this is really a meaningful distinction.  Why can't a 
request *be* a created item?  It's going to be an object, no matter what 
approach you take.  It might as well be a content object.

I can't say that I'm an expert on workflow systems, but I've studied the 
formal and informal metamodels of a lot of different systems (about a 
dozen), both academic and commercial (including a lot of OMG/WFMC stuff), 
and as far as I can tell they are all essentially isomorphic.  Some people 
prefer to use a Petri-net modelling approach where tokens move like race 
cars around a flowchart, others prefer to view the state machine as being 
contained within an object.  Some systems use special restrictions on 
composition of flows in order to achieve certain desired properties, such 
as provable termination, or the ability to specify most things as a 
hierarchy of operations.  Some systems make distinctions between tasks, 
assignments, and workflow instances, and others use fewer distinctions and 
combine concepts.

I have occasionally seen "entity-oriented" workflows that are tied to work 
product and are not really generic workflow tools like DCWorkflow is.  But 
as far as I can tell, DCWorkflow is "computationally complete" where 
workflow is concerned.  The only thing it "lacks", if you can really say 
that, is tools for managing inter-task communication and 
synchronization.  However, this is not due to a lack of expressivity in the 
model used by DCWorkflow.