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

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

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

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

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

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

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 and wfmc]