| eZ Components - Workflow - Theoretical Background |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| |
| .. contents:: Table of Contents |
| |
| Introduction |
| ============ |
| |
| This document contains theoretical background information on the Workflow |
| engine. It is an excerpt from Sebastian Bergmann's `diploma thesis`__. |
| |
| __ http://sebastian-bergmann.de/publications/bergmann-WorkflowEngine-DiplomaThesis.pdf |
| |
| Workflow Patterns |
| ================= |
| |
| In Chapter 3 of his `PhD thesis`__, Kiepuszewski lists *requirements for |
| workflow languages through workflow patterns*. |
| |
| __ http://is.tm.tue.nl/research/patterns/download/phd_bartek.pdf |
| |
| Much like the `software design patterns`__, these workflow patterns describe |
| recurring solutions to common problems. They are relevant to both the |
| implementor and the user of a workflow management system. The former uses the |
| workflow patterns as a common vocabulary for workflow description language |
| constructs and to define the semantics of a workflow model whereas the latter |
| uses them as a guide while formulating his workflow in the workflow system's |
| description language. The workflow patterns also faciliate the comparison with |
| other workflow systems with regard to expressiveness and power. |
| |
| __ http://en.wikipedia.org/wiki/Design_Patterns |
| |
| In Chapter 4 of his `PhD thesis`__, Kiepuszewski maps the workflow patterns that |
| he identified to Petri nets to provide a formal foundation for this more |
| pragmatic approach to defining workflow semantics. |
| |
| __ http://is.tm.tue.nl/research/patterns/download/phd_bartek.pdf |
| |
| In this section we discuss the subset of the workflow patterns identified by |
| Kiepuszewski that is directly supported by the Workflow component. |
| |
| Basic Control Flow Patterns |
| --------------------------- |
| |
| The workflow patterns for basic control flow *capture elementary aspects of |
| process control* and *closely match the definitions of elementary |
| control flow concepts* provided by the Workflow Management Coalition in |
| [`WfMC95`__, `WfMC99`__]. |
| |
| __ http://www.wfmc.org/standards/docs/tc003v11.pdf |
| __ http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf |
| |
| |
| Sequence |
| ^^^^^^^^ |
| |
| The Sequence workflow pattern represents linear execution of workflow |
| steps: one action of a workflow is activated unconditionally (for example |
| *B* the figure below) after another (for example *A* in the figure below) |
| finished executing. |
| |
| .. figure:: img/sequence.png |
| |
| The Sequence workflow pattern |
| |
| **Use Case Example:** After an order is placed, the credit card specified by the |
| customer is charged. |
| |
| Parallel Split (AND-Split) |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| The Parallel Split workflow pattern divides one thread of execution (for example |
| the one that activates *A* in the figure below) unconditionally into multiple |
| parallel threads of execution (for example the ones that start in *B*, *C*, and |
| *D* in the figure below). |
| |
| .. figure:: img/parallel_split.png |
| |
| The Parallel Split workflow pattern |
| |
| **Use Case Example:** After the credit card specified by the customer has been |
| successfully charged, the activities of sending a confirmation email and |
| starting the shipping process can be executed in parallel. |
| |
| Synchronization (AND-Join) |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| The Synchronization workflow pattern synchronizes multiple parallel threads of |
| execution (for example the ones that end in *B*, *C*, and *D* in the figure |
| below) into a single thread of execution (for example the one that starts in *E* |
| in the figure below). |
| |
| Workflow execution continues once all threads of execution that are to be |
| synchronized have finished executing (exactly once). |
| |
| .. figure:: img/synchronization.png |
| |
| The Synchronization workflow pattern |
| |
| **Use Case Example:** After the confirmation email has been sent and |
| the shipping process has been completed, the order can be archived. |
| |
| The workflow patterns that have been discussed so far handle the |
| *unconditional routing* of control flow. We will now take a look at the |
| workflow patterns for *conditional routing*. |
| |
| Exclusive Choice (XOR-Split) |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| The Exclusive Choice workflow pattern defines multiple possible paths |
| (for example the ones that start in *B*, *C*, and *D* in the figure below) for |
| the workflow of which exactly one is chosen (for example the one that starts in |
| *C* in the figure below). |
| |
| .. figure:: img/exclusive_choice.png |
| |
| The Exclusive Choice workflow pattern |
| |
| **Use Case Example:** After an order has been received, the payment can |
| be performed by either credit card or bank transfer. |
| |
| Simple Merge (XOR-Join) |
| ^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| The Simple Merge workflow pattern is to be used to merge the possible paths that |
| are defined by a preceding Exclusive Choice. It is assumed that of these |
| possible paths exactly one is taken (for example *C* in the figure below) and no |
| synchronization takes place. |
| |
| .. figure:: img/simple_merge.png |
| |
| The Simple Merge workflow pattern |
| |
| **Use Case Example:** After the payment has been performed by either |
| credit card or bank transfer, the order can be processed further. |
| |
| Advanced Branching and Synchronization |
| -------------------------------------- |
| |
| The workflow patterns for advanced branching and synchronization *do not have |
| straightforward support in most [of the] workflow engines [that |
| Kiepuszewski evaluated]*. *Nevertheless, they are quite common in real-life |
| business scenarios*. |
| |
| Multi-Choice (OR-Split) |
| ^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| The Multi-Choice workflow pattern defines multiple possible paths (for example |
| the ones that start in *B*, *C*, and *D* in the figure below) for the workflow |
| of which one or more are chosen (for example the ones that start in *B* and *D* |
| in the figure below). It is a generalization of the Parallel Split and Exclusive |
| Choice workflow patterns. |
| |
| .. figure:: img/multi_choice.png |
| |
| The Multi-Choice workflow pattern |
| |
| Synchronizing Merge |
| ^^^^^^^^^^^^^^^^^^^ |
| |
| The Synchronizing Merge workflow pattern is to be used to synchronize multiple |
| parallel threads of execution that are activated by a preceding Multi-Choice |
| (for example the ones that end in *B* and *D* in the figure below). |
| |
| .. figure:: img/synchronizing_merge.png |
| |
| The Synchronizing Merge workflow pattern |
| |
| Discriminator |
| ^^^^^^^^^^^^^ |
| |
| The Discriminator workflow pattern can be applied when the assumption we made |
| for the Simple Merge workflow pattern does not hold. It can deal with merge |
| situations where multiple incoming branches may run in parallel. |
| |
| It activates its outgoing node after being activated by the first incoming |
| branch and then waits for all remaining branches to complete before it resets |
| itself. After the reset the Discriminator can be triggered again. |
| |
| **Use Case Example:** To improve response time, an action is delegated to |
| several distributed servers. The first response proceeds the flow, the other |
| responses are ignored. |
| |
| Structural Patterns |
| ------------------- |
| |
| The structural workflow patterns deal with restrictions that different workflow |
| models can impose. |
| |
| Arbitrary Cycles |
| ^^^^^^^^^^^^^^^^ |
| |
| A common restriction workflow models impose is that arbitrary cycles, ie. one |
| or more activities are done repeatedly, are not supported. As an alternative, |
| special loop constructs that mark the start and end point of a structured cycle |
| are offered. |
| |
| Implicit Termination |
| ^^^^^^^^^^^^^^^^^^^^ |
| |
| The execution of the workflow is (successfully) terminated when there are no |
| activated activities left and no other activity can be activated. This implicit |
| termination of workflow execution can be used in addition to explicit end |
| activities. |
| |
| Cancellation Patterns |
| --------------------- |
| |
| Cancel Case |
| ^^^^^^^^^^^ |
| |
| The execution of a workflow instance is cancelled. |
| |
| **Use Case Example:** An order is cancelled. |
| |
| Workflow Model |
| ============== |
| |
| Activities and Transitions |
| -------------------------- |
| |
| The workflow model is activity-based. The activities that are to be completed |
| throughout the workflow and the transitions between them are mapped to the |
| nodes and edges of a directed graph. This choice was made to faciliate the |
| application of the Graph-Oriented Programming paradigm for the implementation |
| of the Workflow component. Using a directed graph as the foundation for the |
| workflow model makes it possible to define the syntax of the workflow |
| description language using the formalism of graph grammars. |
| |
| Graph Traversal and Execution Strategy |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| The execution of a workflow starts with the graph's only *Start* node. A |
| graph may have one or more *End* nodes that explicitly terminate the |
| workflow execution. |
| |
| After a node has finished executing, it can activate one or more of its |
| possible outgoing nodes. Activation adds a node to a set of nodes that |
| are waiting for execution. During each execution step, a node from this set |
| is executed. When the execution of a node has been completed, the node is |
| removed from the set. |
| |
| The workflow execution is implicitly terminated when no nodes are activated |
| and no more nodes can be activated (see the *Implicit Termination* workflow |
| pattern that was discussed above). |
| |
| State and Workflow Variables |
| ---------------------------- |
| |
| The workflow model supports state through the concept of workflow variables. |
| Such a variable can either be requested as user input (from an *Input* node) or |
| be set and manipulated through the *VariableSet*, *VariableAdd*, *VariableSub*, |
| *VariableMul*, *VariableDiv*, *VariableIncrement*, and *VariableDecrement* nodes. |
| |
| While a *VariableSet* node may set the value of a workflow variable to any type |
| that is supported by the underlying programming language, the other variable |
| manipulation nodes only operate on numbers. |
| |
| Variables are bound to the scope of the thread in which they were defined. This |
| allows parallel threads of execution to use variables of the same name without |
| side effects. |
| |
| Wait States |
| ^^^^^^^^^^^ |
| |
| When the execution of a workflow reaches an *Input* node (see above), the |
| execution is suspended until such time when the user input has been provided and |
| the execution can be resumed. |
| |
| Control Flow |
| ------------ |
| |
| The control flow semantics of the workflow model draws upon the workflow |
| patterns that were discussed above. The *Sequence*, *Parallel Split*, |
| *Synchronization*, *Exclusive Choice*, *Simple Merge*, *Multi-Choice*, |
| *Synchronizing Merge*, *Discriminator*, and *Cancel Case* workflow patterns are |
| all directly supported by the workflow model. |
| |
| *Exclusive Choice* and *Multi-Choice* nodes have branching conditions attached |
| to them that operate on workflow variables to make their control flow decisions. |
| A special node, named *Loop*, to conveniently express loops is also available. |
| |
| Action Nodes and Service Objects |
| -------------------------------- |
| |
| So far we have only discussed nodes that control the flow and that can |
| manipulate workflow variables. We are still missing a type of nodes that |
| actually performs an activity. This is where the *Action* node comes |
| into play. |
| |
| When the execution of a workflow reaches an *Action* node, the business logic of |
| the attached *Service Object* is executed. Service Objects "live" in the domain |
| of the application into which the workflow engine is embedded. They have read |
| and write access to the workflow variables to interact with the rest of the |
| workflow. |
| |
| Sub-Workflows |
| ------------- |
| |
| The workflow model supports sub-workflows to break down a complex workflow |
| into parts that are easier to conceive, understand, maintain, and which can |
| be reused. |
| |
| A sub-workflow is started when the respective *Sub-Workflow* node is reached |
| during workflow execution. The execution of the parent workflow is suspended |
| while the sub-workflow is executing. It is resumed once the execution of the |
| sub-workflow has ended. |
| |
| Design and Implementation |
| ========================= |
| |
| This section discusses the design and implementation of the Workflow component. |
| |
| Architecture |
| ------------ |
| |
| The Workflow engine has been designed and implemented as four loosely coupled |
| components. The **Workflow** component provides an object-oriented framework to |
| define workflows and an execution engine to execute them. The |
| **WorkflowDatabaseTiein** and **WorkflowEventLogTiein** components tie the |
| **Database** and **EventLog** components into the main Workflow component for |
| persistence and monitoring, respectively. The **WorkflowSignalSlotTiein** |
| component leverages the **SignalSlot** component for the **Workflow** |
| component's plugin system. |
| |
| A workflow can be defined programmatically by creating and connecting objects |
| that represent control flow constructs. The classes for these objects are |
| provided by the *Workflow Definition API*. This API also provides the |
| functionality to save workflow definitions (ie. object graphs) to and load |
| workflow definitions from a data storage. Two data storage backends have been |
| implemented, one for relational database systems and another for XML files. |
| Through the *Workflow Execution API* the execution of a workflow definition can |
| be started, resumed, and cancelled. The figure below shows the conceptual |
| architecture for the workflow engine. |
| |
| .. figure:: img/architecture.png |
| |
| Workflow component architecture |
| |
| The idea that a workflow system should be comprised of loosely coupled |
| components is discussed, for instance, in [`DAM01`__, `DG95`__, `PM99`__]. |
| Manolescu states that *an object-oriented workflow architecture must provide |
| abstractions that enable software developers to define and enact how the work |
| flows through the system* [`DAM01`__]. |
| |
| __ http://historical.ncstrl.org/tr/pdf/uiuc_cs/UIUCDCS-R-2000-2186.pdf |
| __ http://citeseer.ist.psu.edu/georgakopoulos95overview.html |
| __ http://citeseer.ist.psu.edu/muth99integrating.html |
| __ http://historical.ncstrl.org/tr/pdf/uiuc_cs/UIUCDCS-R-2000-2186.pdf |
| |
| The component-based workflow architecture Micro-Workflow *encapsulates |
| workflow features in separate components*. This architecture follows the |
| *Microkernel* pattern which *applies to software systems that must be able to |
| adapt to changing system requirements. It separates a minimal functional core |
| from extended functionality and customer-specific parts. The microkernel also |
| serves as a socket for plugging in these extensions and coordinating their |
| collaboration* [`FB96`__]. |
| |
| __ http://en.wikipedia.org/wiki/Special:BookSources/0471958697 |
| |
| Workflow Virtual Machine |
| ------------------------ |
| |
| This section proposes a so-called *workflow virtual machine* as the executing |
| component of a component-based workflow architecture. |
| |
| Given the fact that *standardization efforts, e.g. XPDL* [`WfMC05`__] *proposed by |
| the WfMC, have essentially failed to gain universal acceptance* [`WA04`__], the |
| *problem of developing a [workflow system] that supports |
| changes in the [workflow description language]* needs to be addressed. |
| |
| __ http://www.wfmc.org/standards/docs/TC-1025_xpdl_2_2005-09-07_xpdl_2.pdf |
| __ http://www.yawlfoundation.org/documents/yawls.pdf |
| |
| Fernandes et. al. propose to *split the [workflow system] into two layers: (1) a |
| layer implementing a* Workflow Virtual Machine, *which is responsible for most |
| of the [workflow system] activities; and (2) a layer where the different |
| [workflow description languages] are handled, which is responsible for making |
| the mapping between each [workflow description language] and the Workflow |
| Virtual Machine* [`SF04`__]. |
| |
| __ http://www.esw.inesc.pt/~ars/ps/sofsem2004.pdf |
| |
| A workflow virtual machine isolates the executing part of a workflow management |
| system, the *backend*, from the parts that users interact with, the *frontend*. |
| This isolation allows for the definition of a *backend language* to describe |
| exactly the workflows that are supported by the executer and its underlying |
| workflow model. This backend language is not the workflow description language |
| users use to define their workflows. They use *frontend languages* that can be |
| mapped to the system's backend language. |
| |
| Graph-Oriented Programming |
| -------------------------- |
| |
| The manual of JBoss jBPM [`JBOSS`__], a platform for multiple process languages |
| supporting workflow, business process management, and process orchestration, |
| introduces *Graph-Oriented Programming [as a] new implementation technique that |
| serves as a basis for all graph-based process languages*. |
| |
| __ http://docs.jboss.com/jbpm/v3/userguide/graphorientedprogramming.html |
| |
| Graph-Oriented Programming implements the *graphical representation* and the |
| *wait states* of a process language in an object-oriented programming language. |
| The former can be achieved by providing a framework of node classes. Objects of |
| these classes represent the nodes in the process graph, relations between these |
| objects represent the edges. Such an object graph can then be traversed for |
| execution. These executions need to be persistable, for instance in a relational |
| database, to support the wait states. |
| |
| The aforementioned node classes implement the `Command design pattern`__ and |
| encapsulate an action and its parameters. |
| |
| __ http://en.wikipedia.org/wiki/Command_pattern |
| |
| The executing part of the workflow engine is implemented in an Execution class. |
| An object of this class represents a workflow in execution. The execution object |
| has a reference to the current node. When the execution of a workflow is started, |
| a new execution object is created and the current node is set to the workflow's |
| start node. The execute() method that is to be provided by the node classes is |
| not only responsible for executing the node's action, but also for propagating |
| the execution: *a node can pass the execution that arrived in the node [to] one |
| of its leaving transitions to the next node*. |
| |
| Like Fowler in [`MF05`__], the authors of the JBoss jBPM manual acknowledge the |
| fact that *current software development relies more and more on domain specific |
| languages*. They see Graph-Oriented Programming as a means to implement domain |
| specific languages *that describe how graphs can be defined and executed* on top |
| of an object-oriented programming language. |
| |
| __ http://martinfowler.com/articles/languageWorkbench.html |
| |
| In this context, a process language (such as a workflow description language) is |
| *nothing more than a set of Node implementations*. The semantics of each node |
| are defined by the implementation of the execute() method in the respective node |
| class. This language can be used as the backend language of a Workflow Virtual |
| Machine (see above). In this lanugage, the workflow is represented as a graph of |
| command objects. The workflow patterns (see above) make up the requirements for |
| and can be mapped to the respective classes. |
| |
| One of the advantages of using a domain specific language that Fowler gives in |
| [`MF05`__] regards the *involvement of lay programmers: domain experts who are not |
| professional programmers but program in domain specific languages as part of the |
| development effort*. In essence this means that a software system that provides |
| a domain specific language can be customized and extended without knowledge of |
| the underlying programming language that was used to implement it. |
| |
| __ http://martinfowler.com/articles/languageWorkbench.html |
| |