This document tries to describe the place of TinyWorkflow in the (open source) workflow world.
'Workflow' is word mapped to different concepts depending of the context. In this document we will describe some families of workflow API and then explain the differences/common points with TinyWorkflow.
Note: you can find open-source workflow references in java-source.net: http://java-source.net/open-source/workflow-engines
Most of the 'workflows' used in analysis phases of a software project are 'Activity Flows' (also called 'Action Flow', 'Activity Diagrams') while, in TinyWorkflow, the 'workflows' used are (Finite) State Machines (also called 'state-transition diagrams').
The same workflow can be expressed in one form or the other. The rules to move between the two are quite simple:
Here is a simple workflow expressed as 'Activity Flow' and 'State Machine'
State machines are more suited to be attached to objects than activity flows. This is mainly because they express state (and an object is usually stateful).
State machines also allow adding transitions that don't change the state. This is very useful to implement some behavior of the System. For example, in the example above, if you want to add the possibility to change the document name (only before the document is signed) and to add a 'note' to this document. It is simply expressed as:
This transformation is very difficult to retrofit to the original 'Activity Flow' because the added transitions don't change the state of the workflow. So they can be combined in any order. In fact, such 'actions' are usually not represented in activity flow and must thus be specified (and implemented) elsewhere.
So to implement workflows at the level of java objects, State Machines are better suited and finer grained than Activity Flows.
When you have a set of software components with remote interface (typically web-services) available and you want to use them to perform you business, you need something to make the glue. As the component have self-describing XML interface that can evolve at any time, you don't want your glue application to be hardcoded java. Then you need something more flexible and configurable. Here come the WfMC or WS-BPEL workflow engines.
Characteristics of these engines:
On the opposite, TinyWorkflow is
So it's clear that the aims of those workflow engines are totally different.
If you want a light workflow engine that can be embedded in a single java application (be it a J2EE application), TinyWorkflow is better for you. On the other hand, if you need a workflow to glue several distributed (web-) services, WfMC or WS-BPEL will better fit your needs.
OSWorkflow is an open-source workflow engine from OpenSymphony (http://www.opensymphony.com/osworkflow/).
TinyWorkflow is a new implementation of the OSWorkflow ideas. In general, the behaviour of the two workflow engine is similar. Tiny workflow intention is to be more modular and extensible.
See specific document for comparison: Differences between TinyWorkflow and OSWorkflow
Those workflow engines are similar to TinyWorkflow in the sense that they use a finite state machine.
In general those compilers produce java code that can be integrated to a java class. The state machine can hold state and perform transitions but it is only an implementation of the 'state' pattern. It is not business-oriented in the sense that it does not offer:
As those engines provide compiled code, they will be more efficient for just managing a state on the other hand they are less flexible than interpreted XML. They are usually more focused on algorithmic problems or GUI flow while TinyWorkflow is more about business process.
See: