[Zope3-dev] Re: A possible component architecture interpretation of workflow

[Jim Fulton]

A few weeks ago I sent a note with some ideas for modeling workflow in
Zope 3.

   http://mail.zope.org/pipermail/zope3-dev/2004-September/011954.html

My motivation was:

 > A while ago, I was introduced to the Plone/CMF Form Controller.
 > CMF Form Controller provides a way to separate form display,
 > validation, and navigation.

...

 > I think this capability has a lot of value.  We've seen a need for a
 > better separation of display, logic, and navigation in Zope 3 view
 > implementations.  I've been pondering how to fold this sort of thing
 > into Zope 3's presentation architecture.
 >
 > To me, this feels very similar to workflow.  In workflow, you have a
 > collection of activities tied together by transitions.  Rules
 > determine when transitions fire and the processing associated with
 > them.  A form controller expresses the rules for performing processing
 > on pages and the transitions between them.  This observation made me
 > start to wonder if perhaps workflow might have a far more central role
 > in Zope 3 user-interface design than I had previously considered.

I went on to suggest some ways to think about workflow in terms of the
component architecture.  I got a lot of good feedback and also had
more time to think about this.

Here's an update on my thoughts, FWIW, based on the feedback I
recieved and the thinking I've done since writing the original
note. I'll start with what I think I got wrong:

- My understanding of activity-based workflow was findamentally
   flawed.  Ulrich Eck, Tres Searver and Ben Saller did a good job of
   setting me straight (at least AFAIK ;) at the castle sprint.
   "States" and activity-based workflow go together like oil and water.
   Activity-based workflow models are *not* state based and trying to
   think about activity-based workflow in terms of states is mostly
   counter productive.  I had a negative reaction to activity-based
   workflow models because they seemed not to be object-oriented. I was
   wrong. They are object oriented, but the objects of interest are the
   tasks that need to be done.  FWIW, it helps me to think of
   activity-based workflow systems as advanced task-management systems.

- I was thinking of workflow as an application of models of dynamic
   object behavior.  When thinking about object states, I assumed that
   the states are intrinsic and model the bahavior of the object.  This
   is not consistent with most applications of DC Workflow.  In most DC
   Workflow applications, the states are states of the *process* not
   the object.  A single process (e.g. publishing) is used with many
   different content types.  The states (e.g. author, review, publish)
   don't represent object behaviors, but rather the way that the object
   is being managed by a process over time.  In other words, the states
   used in DC Workflow are extrinsic, rather than intrinsic.

- I missunderstood an important requirement.  I thought it was a
   requirement that the behavior of an object should change as it
   changed state.  That is, that behaviors, including views and
   adapters shoud be present or absent based on the state.  The *real*
   requirement is more subtle than that. The real requirements is that
   access-control decisions should be affected by state changes.  For
   example, when an object is in a review state, we might want to
   disallow authors from changing it, but we might still want to allow
   site managers to change it. In other words, we don't want to add or
   remove functionality as states change, we want to change the access
   rules.

   I think that being able to have state-dependent access rules for
   objects is useful for entity-based (DC-Workflow-like) workflow,
   activity-based workflow, DAV locking and probably other applications
   as well.

   I'll have more to say on this in a later note.

So what did I get right?

- I think the greatest similarity between CMF Form Controller, DC
   Workflow and activity-based workflow (e.g. OpenFlow) is that they
   all deal with rule-based transitions.  I think the event system
   provides a good basis for implementing rule-based transitions,
   whether they are transitions between pages, activities, or states.

- I think there *is* utility in using interfaces to represent states.
   This makes it easier to provide state-dependent user-interfaces and
   applications.  If we have to store state information on an object
   (for example, if we are using entity-based workflow), using the existing
   interface-declaration architecture seems as good an approach as
   any.  Finally, representing states as interfaces makes it easier to
   bring the event system, which is based on adapters, to bear.

Implementation status

- Ulrich Eck created a prototype implementatio of entity-based
   workflow at the Castle sprint:

     http://svn.zope.org/Zope3/branches/jack-e_interfacebased_workflow/

   This showed that it does in fact work to represent DC-Workflow-like
   states as interfaces.  This work builds on the entity-based workflow
   implementation already in Zope 3.

- At the ISAR sprint, Julien Anguenot built on Ulrich's prototype,
   adding more UI and adding DC-Workflow-like logic for changing
   role-permissio mappings on transitions.

   http://zope.org/Wikis/DevSite/Projects/ComponentArchitecture/IsarSprint#ebw

- Also at the ISAR sprint, Thomas Foerster created an interesting
   exploratory prototype to look at implementing activity-based
   workflow using fairly simple Python code and event subscribers:

   http://svn.zope.org/eventworkflow/trunk/

   A goal of this prototype, at least for me, was to explore how simple
   an implementation we can create.  This is in contrast to a
   WFMC-compatable implementation suggested by the interfaces in:

   http://svn.zope.org/Zope3/trunk/src/zope/app/workflow/interfaces/wfmc.py?view=markup

   Note that the WFMC model is very geared toward expressing processes
   as data (e.g. XML) and then providing interpreters that execute the
   processes. I think that there is value in that and that this is
   something we want eventually, but, at least for myself, I'd like to
   have a simpler Python-based model that I and others can get our
   heads around.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org