Bringing in a third-party workflow engine would allow us to:
There is not a wealth of complex workflows in Sakai right now, but there has been an expressed need for some time (see ), and a few projects are on the cusp of requiring a workflow engine. Bringing in a workflow engine or two at this point would not allow the excising of a large quantity of existing code (as the JCR work would), but it would allow us to get ahead of "workflow creep" of tools developing more elaborate and brittle logic in the absence of an engine available to satisfy their use cases.
There is a need for two kinds of workflow engine:
We would need to integrate through adapters into the core of the Sakai framework so that workflow implemented processes can manipulate the datamodel and services that form Sakai while maintaining an internal record of workflow state.
For Sakai, IMHO, we need to abstract the workflow engine and its integration points behind some simple interfaces that may be both java interfaces or communication standards (eg data over http, xml documents, etc). Then we need to start expressing our workflows in a standard language, I would strongly suggest BPEL + XPDL, stored as documents in JCR. There should be 2 workflow engines, one for each type of workflow, but no more than one per type, the BPEL workflow might even come as part of an ESB connector Once we have this infrastructure in place we should look at migrating existing 'workflow' oriented operations into definitions to reduce the complexity and range of workflow implementations within Sakai.
1. A set of functional and technical requirements are identified for short- and medium-term needs.
2. A technical approach is defined, preferring a standards-based approach when feasible
3. If the agreed-upon approach is standards-based, then an existing open source implementation that is compatible from both technical and licensing perspectives is preferred as the default implementation
4. When resources permit, testing against non-default implementations (both open and proprietary) is encouraged to ensure both robust standards compatibility and a wider range of choices for community members