Concurrent WorkFlows

Code for the following example can be found at SimpleConcurrentWorkflow

Consider the following simple workflow:

Such a workflow can be expressed using the following code:

void beginWork() {
    taskAOutput = taskA();
    taskBOutput = taskB(taskAReturnValue);
    taskCOutput = taskC(taskAReturnValue);
    taskD(taskBOutput,taskCOutput);
}

The above workflow is interpreted as follows:

• Task A will be the first task to be executed since it does not need any inputs to be run
• Task B & Task C can be executed only once Task A is completed. This is specified by adding the output of taskA as inputs to tasks B & C
• Task D can be executed only once Task B & C are completed.

A unit test written for the above code will execute sequentially, completing tasks A, B, C & D sequentially.

The same code, when deployed to Production using Flux will be executed as follows

• Once beginWork() is called, the Flux Client intercepts the call & submits a Flux state machine to the Flux runtime.
• The flux runtime will invoke taskA and wait for it to complete
• Then, task B & C will get invoked parallely
• Once both are completed, task D will get invoked
• Tasks A, B, C & D can (and mostly will) get invoked on different JVMs that may even reside on different VMs. Thus, this gives the developers flexibility to scale each component differently. If Task A is largely i/o bound, code capable of executing Task A can be deployed on fewer machines than code running Task B & C which may be compute bound.