Open alternatives to Windows Workflow

Kinlan picture Kinlan · Jul 2, 2009 · Viewed 13k times · Source

Pre-warning: There are some other questions similar to this but don't quite answer the question (these include: Alternatives to Windows Workflow Foundation?, Can anyone recommend a .Net open source alternative to Windows Workflow?)

We are developing a system that is an event based state machine, currently we are investigating windows workflow, our system needs to be low latency in its response to events from a multitude of sources (xmpp, http, sms, phone call, email etc etc) coming into the system, scalable and resilient and most importantly customisable. For a variety of reasons (and due diligence) I am looking for open workflow engines that support functions similar to Windows Workflow Foundation (and more - if possible), mainly (but it doesn't matter too much if there are engines that don't support some features):

  1. Persistence of long running tasks, and resumption of tasks on external events
  2. High performance, low latency
  3. Ability to develop custom actions
  4. The ability to specify workflows dynamically
  5. Tracking and tracing

I am not constrained to platform or language, and I would love some help and tips from you guys so that I can start to investigate the engines more closely and any experiences you had with the engines.

Paul.

Answer

David Robbins picture David Robbins · Jul 10, 2009

I invite you to examine Stateless further, as suggested in the answer to my SO question can-anyone-recommend-a-net-open-source-alternative-to-windows-workflow. to achieve the goal of a long running state machine is very simple in that you can store the current state of your state in a database and re-sync the state machine when needed. Consider the following code from the stateless site:

Stateless has been designed with encapsulation within an ORM-ed domain model in mind. Some ORMs place requirements upon where mapped data may be stored. To this end, the StateMachine constructor can accept function arguments that will be used to read and write the state values:

var stateMachine = new StateMachine<State, Trigger>(
    () => myState.Value,
    s => myState.Value = s);

With very little effort you can persist your state, then retrieve that state easily later on.


In respect updating the workflow dynamically, if you configure a state machine such as

var stateMachine = new StateMachine<string, int>();

and maintain a separate file of states and triggers in XML, you can perform a configuration at runtime by looping through the string int value pairs.