TinyWorkflow versus OSWorkflow
TinyWorkflow is a brand new implementation of ideas/concepts of the OSWorkflow open source workflow engine from OpenSymphony (http://www.opensymphony.com/osworkflow/).
The first developments of our company were first based on OSWorkflow. After a while the requirements of our application implied some modifications of the workflow engine that were not compatible with the existing codebase. So we decide to rewrite the engine to better fit our needs. As the original project we learned from was open source, it is natural to also publish this new project as open source (though the code base is totally new).
We still believe that OSWorkflow is a good workflow engine and hope that this implementation will bring mutual enrichment of the two engines.
This document describes the goals of the TinyWorkflow implementation and how it differs from OSWorkflow.
Each workflow is associated to a java object
The workflows represent the state of a java object (called Workflow Peer). This object is supposed to store the specific data needed by a workflow instance and to provide the method to manipulate this data (OO basics ;-). We want to avoid the kind of programs where everything is scripted and no business functionality is coded in java. We believe that the java code is the good place to put most of the business logic. Only the workflow-related part has to be taken out and scripted in XML.
Tiny workflow improve modularity and interoperability between workflows
Rationale: Our vision is to model a big and complex business process with a lot of little (tiny) workflows. Common behavior can be factored out in a separate workflow used by other workflows. This will improve modularity and maintainability of the workflows.
Technical changes supporting this vision:
- String ids: as a workflow (or a piece of code) must be able to reference a state or a transition of another workflow, it's better to have string ids for the states/transitions. Workflows themselves also have a unique (string) id.
- Versioning: If we want references to a state or transition inside a workflow we must have the version of this workflow (as the state/transition) can be not present in another version). The aim of versioning mechanism is to be as much transparent as possible and to allow automatic migration of running workflows to new versions.
- No split: The split/join of workflows is replaced by a parent-child relationship. The workflow implementation is then simplified (be cause a workflow has then one and only one state) but the functionality is quite the same: rather than splitting you can start several child workflows and wait for them to finish.
- Allow inheritance between workflows
Tiny workflow improve extensibility
The point here is to allow customization of the workflow XML definition. This extensibility is already used for pre-defined components (like functions, conditions ...) each of them can be defined with most appropriate XML syntax.
The extensibility allows you to add in the XML workflow definition your own elements with arbitrary syntax.
Clarify the design
- TinyWorkflow tries to stick to standard naming of workflow world. So, it uses the vocabulary of Finite State Machines: 'state' and 'transition' instead of the 'step' and 'action' used by OSWorkflow.
- In OSWorkflow the workflow instance is hidden (it is in fact the WorkflowEntry interface), there is no direct access to it. The 'Workflow' class is a stateless (session bean) facade. For tiny workflow, the 'Workflow' class is the workflow instance and it's a simple POJO. A stateless J2EE session bean facade is provided as extension.
- In OSWorkflow the history of workflow is a list of states identical to the current state. In tiny workflow the history is a set of historical transitions each linked to a 'fromState' and a 'toState'
- The 'status' attribute of OSWorkflow allowing to have sub-state inside a state of the state machine is removed. In TinyWorkflow if you want a sub-workflow inside a state, you have to explicitly fire a child workflow. TinyWorkflow only retain the idea of workflow ownership (the workflow can have an owner) associated to the 'status' of OSWorkflow (usually 'Queued' when there is no owner and 'Locked' when there is an owner).
- Parameter descriptions: rather than 'validators' tiny workflow use parameter description. So when parameters are requested for a transition, you can describe them. This allows clearer documentation of the needed parameters and it allows also building automatically a GUI for entering them.
- Multi-lingual support: In addition to ids you can provide names and description for workflows/states/transitions in all the supported languages.
- Workflow documentation generation (TODO: for future version). The TinyWorkflow definitions accept a visitor. Some provided visitor implementation allows generating a HTML documentation of the workflow definitions.
OSWorkflow is an older and more mature workflow engine than tiny workflow. It provides more features and pluggable persistence scheme than TinyWorkflow (like Spring support, OFBiz persistence ...). This will improve after time.
Some of the features of OSWorkflow are intentionally missing because they are not compatible with the philosophy of TinyWorkflow.
- Request API: As each workflow instance of tiny workflow is linked to a java object holding important business data, it is useless to select/search workflow instances solely based on the TinyWorkflow tables. In most of the case, you want to join them with the application-specific tables. TinyWorkflow engine cannot provide such search API. For the time being we recommend to directly use hibernate HQL to search workflow instances.
- Split/join is replaced by workflow parent/child relationship.