Tiny Workflow in the workflow engine world

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

Activity Flow versus State Machine

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:

  • The boxes in the Activity Flow represent an action transforming the system; they are represented by transitions (arrows) in the State Machine.
  • The arrows in the Activity Flow just indicate the chaining of the activities; this chaining is given by the combination of states and transitions in the State Machine.
  • The state of the system is not shown in Activity Flow so states boxes must be added in the State Machine.
  • The decision points remain the same.

    Here is a simple workflow expressed as 'Activity Flow' and 'State Machine'

    <i>Activity Flow to State Machine</i>

    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:

    <i>State Machine with added transitions</i>

    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.

WfMC or WS-BPEL compliant workflows

  • WfMC is Workflow Management Coalition (http://www.wfmc.org/)
  • WS-BPEL is Web Services Business Process Execution Language (http://www.oasis-open.org/)

    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:

    • They are activity flows (because the engine manage services, not objects)
    • They are by nature distributed.
    • They have complex management interface because the components can be upgraded at any time while the engine is still running.
    • The engine must provide persistency for data (state) passed along the services.

    On the opposite, TinyWorkflow is

    • A finite state machine
    • A non-distributed POJO core (Plain Old Java Object)
    • Intended to be used inside a single application (though it provides a Stateless EJB interface as extension).
    • TinyWorkflow interact with java objects (instead of abstract services)

    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

Finite state machine compilers

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:

  • Persistence
  • History
  • Conditions / permissions
  • Extensions (EJB, Struts ...)

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.