Considerations

Runtime data isolation

Graph oriented programming clearly separates the definition data (nodes, transitions and actions) from the runtime data (execution).

So instead of just propagating the execution that entered the node, any node implementation can decide to rearrange the whole runtime data that represents the execution. This creates a lot of flexibility for implementing different flavours of fork.split and join/merge behaviour.

Also, the definition information is static and never changes. This is important for all kinds of performance optimizations.

GOP compared to other techniques

In this section we describe how graph oriented programming compares to other implementation techniques used for graph based execution languages.

In MOM based execution engines, an execution is represented by a message that travels along message queues. Each node in a process graph is represented by a message queue in the system. Actually, graph oriented programming is a superset of MOM based execution. In GOP, by default, the calculation to move an execution from one wait state to another is done synchronously. Later in this paper, we’ll cover the asynchronous continuations extension that explains how MOM can be used to make one step in the process asynchronous. So MOM based execution is similar to graph oriented programming where all the nodes are executed asynchronously.

Another technique used to implement workflow, BPM and orchestration systems is code generation. In that approach, the graph based process is translated into imperative programming logic like Java. The generated programming logic has a method for each external trigger that can be given after a wait state. Those methods will calculate the transition to a new wait state. This technique is limitated in process versioning capabilities and in practice, the code generation has proven to be impractical and a bottleneck in the software development process.

GOP compared to petri nets

The academic world, for a long time, has focussed on petri nets for workflow and business process modelling, mainly because petri nets was the only mathematically defined model that supports concurrent paths of execution. Because of the mathematical foundations, many interesting algorithms for validation and completeness could be defined.

The biggest difference between petri nets and graph oriented programming is their nature. Petri nets is a mathematical model, while graph oriented programming is an implementation technique or a design pattern.

Graph oriented programming can be used to implement petri nets. Petri net places and petri net transitions can be implemented as two different node types. Petri net arcs correspond to GOP transitions. A petri net token corresponds to a GOP execution.

The higher level extensions that have been defined on top of petri nets can also be defined in terms of graph oriented programming.

Graph oriented programming on itself doesn’t support analytical algorithms as they are defined on petri nets. That is because grpah oriented programming doesn’t have a concrete interpretation. Analythical algorithms can only be defined on models that have a deterministic design time interpretation. Graph oriented programming on the other hand also supports nodes that have an undeterministic design time interpretation. GOP node implementations can potentially do any type of calculation at runtime and decide only then how the execution is propagated. Analytical algorithms can only be defined on concrete process languages, for which the nodes implementations give a deterministic design-time interpretation to the node types.