Paris sprint day #1

Stateful workflows / activity based workflows : from CPS3 workflow
system to Zope3.

I'm going to focus on workflow application during the Zope3 Paris sprint
since it's one of the key architecture pieces of a content management
framework and thus more than necesary if we want to start modelizing complex
workflow applications such as the ones we are currently designing with CPS3
for our customers. And I've to say I'm pretty in a hurry to start building
applications on the Z3 framework in Nuxeo's project ;)  Furthermore,
I'm sensitive to the problem since I've been working on CPSWorkfow and other
customer specific workflow related issues in the past quite

Currently, CPS3 has a stateful workfow engine implementation : CPSWorkflow
which is a set of extensions of DCWorkflow.

DCWorkflow is a stateful workflow engine with what you can easily modelized
generic reusable workflow definitions that you may apply globally on objects
(content_type in CMF). A workflow definition in DCWorkflow is composed of
states, transitions, variables and roles - permissions maps (the workflow
itself takes care of roles - permissions. updates while entering state) It
is a "document centric approach" that adresses the basic issues we could be
faced to within a content management scope (like basics review / publication
workflows). The workflow relevant data (variables in DCWorkflow) are hooked
on the objects themselves since the workflow definitions are generic.
Furthermore, it has a pretty nice end-user interface that make the
modelization of workflow definitions really trivial within a CMF portal for
non CS people.

CPSWorkflow is a set of extensions of DCWorkflow, heart of the CPS3
architecture, with some really nice add-ons such as placeful workflows,
enhanced transitions, proxy knowledge for versionning, security
orirentation, event service use and a more recent add-on that is just
reaching a stable state wich is the workflow stack support basically for
dynamique workflow chain delegation and validation of people in a
collaborative and hierarchical scope.

We started reaching the limits of the stateful engine at this point since
we needed to hook application logic and objects on the workflow definition
that may interact with other workflows or objects during the document life

I'm of course talking about designing a generic reusable framework in here.
It's always possible to reinvent the wheel and generate specific Python code
on every customer projects. I know it's the point of view of some
persons...(Feel free to use the traceback if you want to comment on this.)

Zope3 has a pretty basic stateful workfow engine within the trunk. It's a
pretty old implementation that lacks features for advanced workflows
implementation. It's seems to be enough for pretty simple workflows

Ulrich implemented a more Zope3'ish stateful workflow engine based on
interface and adapters. I've been working on this too during the last Zope3
sprint in Munich. I's been a good accasion for me to try stuffs on Z3, learn
how the framework is working and if this interfaced based workflow approach
is working. It actually does work and I think it could be possible to
implement a DCWorkflow like workflow that would work well with Z3 this

Jim recently checked in an interesting implementation of the wfmc
specifications. This is an activity based model such as openflow from
reflabs for Z2. (I've to say I don't know much about it since I've never had
the occasion to implement customer specifications with it)

This is not document centric at all. The document is simply the result of
the process in this case.

The advantages of this implementation are :

  •    Standard implementation (wfmc specifications and xpdl (XML
    process definition language))

  •   Activity based workflows are more suitable for business
    applications and complex processes modelizations.
  • Make the forward of CPSWorkflow stacks much more easily with this

The disatvantages I can see so far are :

 - It's not document centric and thus less convenient (and / or
natural) in a content management scope. (especially coming from the dc wf
world I agree)

 - I don't like the idea of having a persistent activity instance.
What needs to be persistent is the workflow relevant data and the state

I could choose a pragmatic approach saying that it would be nice to have
something that can work like DCWorkflow using the interface based workflow
and thus being able to work with Zope3 much more sooner as the interfaced
based model seems to work ;). But when I'm thinking about the stack
workflows forward on Z3 framework I know that it's going to be much more
convenient with the activity based workflow model. Or still the ability to
design much more complex applications with lots more workflow processes
involved. (I kind of like the idea as well :))

I think both model do have interests but on the other hand it should be
possible to design an application miming the stateful model with an activity
based one.

Thus I'm gonna jump into the activity based model by trying to implement a
higher workflow component at the content management level using Jim's
activity based workfow engine.

[You may ask google for terms that are not explained such as xpdl

(Post originally written by Julien Anguenot on the old Nuxeo blogs.)