Ideas and opinions

March 2004 Johan posted 'Experience with workflow', to the Cocoon developer list. The response to this post was overwhelming. The interest in workflow applications is enormous. Below is a summary of the information in the post and its responses.


In the discussion there were a lot of different views of what workflow encompasses. The requirements will differ depending on the scope which is chosen. This must be kept in mind while evaluating and comparing workflow solutions. Below is a summary of different areas for which the scope levels differed. Although the summary presents two scope levels for each area, it's not black and white and more scope levels are possible.

One of the first things in software engineering is to determine the end users of the software. In the discussion people clearly had different views on this subject. One group would like the developers to implement the workflow specified by the users, and another group would like a tool for end users with which they can define the workflow.

People were also applying workflow to different-sized problems. There is interest in a generalized workflow engine capable of building complete processes, and interest in remembering state for a single object only (object lifecycle).

What is clear from the discussion is that a workflow must not be attached to a particular type of object (documents for example), but that the workflow framework must be flexible enough to be able to attach a workflow to any object.


Before workflow can be implemented a number of requirements must be met:

A workflow solution must be able:

If workflow is implemented using state machines, the state machines must support (depends on final set of valid use cases):


A number of implementations were suggested. And each implementation had its share of proponents. To come to a good evaluation of the implementations it was suggested to build one or more WorkflowUseCases in each implementation, and compare the results. Some of the criteria to consider are:

Existing frameworks

Existing frameworks, preferably based on standards, must be evaluated (licensing must be considered also). It is useless to reinvent the wheel. OSWorkflow and Lenya are frameworks with which people already have experience. These two are not based on standards however.

Finite state machines

OSWorkflow and Lenya are based on finite state machines (FSM). If their implementation would turn out not to be powerful enough, an implementation on the same principal of FSMs could be build. There are a number of ways in which FSMs can be implemented:

Flow with continuations

Another implementation a lot of people were interested in was using flow with continuations. This can be implemented in a number of ways too:

Rule based

The last implementation uses rule evaluation (could somebody with a better understanding than I add some more information? Johan Stuyts). Possible ways to implement this:

Design issues

In the thread a number of design issues were pointed out.


Authorization when using workflow is usually very fine grained: it is only possible to create a document in this folder if you are a member of department X. These authorization rules can be seen as a special type of conditions which are used to whether an action on a worfklow is valid. But this mixes concerns: authorization and logic. There must be locations at which:

Workflow interface

Workflow uses multiple aspects of objects, its properties, its current state and authorization information, at the same time. All these are needed to be able to use queries like: find all news items for which user X is the editor, and which are waiting for review for at least an hour.

The properties of an object, the state of an object, and the authorization information are stored in different locations which should not query each other directly most of the time. It is undesirable to let the client of these different locations collect and merge this information. A separate component (using an existing interface) must hande this task.

Next steps

The first thing to do is to determine the scope of the needed workflow. If the scope it chosen too wide, the workflow implementation will be so big that a project separate from Cocoon is probably justifiable.

After the scope is clear existing workflow implementations can be used to implement a number of WorkflowUseCases. After the evaluation of the results a decision can be made about whether an existing implementation suffices (or it is doable to modify it to make it suffice), or that a new product must be developed.

See also


Workflow (last edited 2009-09-20 23:39:44 by localhost)