[Zope3-dev] Workflow

[sean.upton@uniontrib.com]

Forgive me for speaking abstractly...

I might add that relationship management services (like Gary's proposed
RelationshipManager service) might buy you the infrastructure needed to
group entities into activities, treat activities as entities in-and-of
themselves, and construct/compose activities from simple components
representing either other activities or artifacts of those activities.

Such a concept might provide an answer of how to do project management and
workflow for an activity that involves a content creator, a
design/template/view person, and a software person.  A software system
managing business process might include information on projects and
assignment for those projects/activities, it might also include assets
created.

Workflow obviously most important for:
	- Project management applications
	- Digital Asset Management applications
	- Knowledge-management/Doc Mgmt applications
	- Web content management applications

Given these constraints, for all of the above, relationship management is
also important.  And for all of the above, relating activities to artifacts
is important.

Suppose a company has a knowledge management system that also manages
business process and project tracking.  Suppose a marketing team at such a
company is tasked with market research and creation of some specific
materials and strategies in relationship to a company project.  They would
likely need a place to do knowledge-management (store the information assets
from the project, data, charts, documents, graphics), and various tasks and
requests sent out from management related to this.  Such an application
could certainly use
workflow-via-composition-and-relationship-of-activities-and-assets and
present an entire map of these processes and products for project managers
and executive summaries.  And such a system could manage a consistent set of
rules (transitions/guards/states/etc) for each activity or asset.

The same patterns definitely ring true from my experience with media systems
as well.  I think they are generally applicable.

Just a thought.

Sean

-----Original Message-----
From: Shane Hathaway [mailto:shane@zope.com]
Sent: Wednesday, November 06, 2002 12:56 PM
To: Florent Guillaume
Cc: zope3-dev@zope.org
Subject: Re: [Zope3-dev] Workflow


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/TryingToUni
fiyWorkflowConcepts
> 
> 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


_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
http://lists.zope.org/mailman/listinfo/zope3-dev