Marcin

D¹browski

Micha³

Drabik

Piotr

Habela

Kazimierz

Subieta

 

Object-Oriented Declarative Workflow Management System

 

 

Institute of Computer Science

Polish Academy of Sciences

 

Warszawa 2009

 

 

Content

 

Abstract 7

1      Introduction. 9

2      Genericity and Architecture of Workflow Processing. 15

2.1        Genericity of Workflows. 15

2.2        Architecture of a Declarative Workflow Management System.. 19

3      Technical Assumptions of Active Objects. 23

4      Creating and Removing Active Objects. 37

4.1        Typing Constraints and Business Logic Constraints. 38

4.2        Dealing with Types. 39

5      Definitions of Processes and Process Instantiations. 43

5.1        Macro-Oriented Approach. 43

5.2        Classes of Active Objects. 43

5.3        Procedure-Oriented Approach. 44

5.4        Languages for Workflow Definitions. 45

5.5        Features of Languages. 49

6      Parallel Processing Monitor 53

6.1        Parallel Active Objects on Many Machines. 54

6.2        Splits and Joins through Fireconditions and Endconditions. 57

6.3        Declarative Workflow Patterns. 58

7      Topics Related to the Idea of Declarative Workflows. 63

7.1        Workflow Change Management 63

7.2        Grouping and Ungrouping of Processes and Tasks. 64

7.3        Tasks Shared among Many Processes. 69

7.4        Communication Between Process Instances. 71

7.5        Transactions. 72

7.6        Time, Resource, Document and Application Management 78

7.7        Metamodel and Reflexive Capabilities. 83

7.8        Interoperation with Client Applications. 85

8      Example of a Declarative Workflow.. 87

8.1        Description of a Workflow.. 87

8.2        Database Schema. 91

8.3        Schema of Active Objects. 91

8.4        Pseudo-Code of Active Objects. 92

8.5        Examples of Workflow Instance Change. 95

8.6        Extended Functionality in the Presented Example. 98

Conclusion. 103

Appendix 1: Stack-Based Architecture and Stack-Based Query Language. 105

Appendix 2: Overview of ODRA.. 129

Appendix 3: Prototype of OO Declarative WfMS. 147

References. 167

Abstract

This book presents the motivations and technical assumptions for the idea of the object-oriented declarative workflow management system that is currently under construction at the Polish-Japanese Institute of Information Technology in Warsaw. The concept assumes a totally novel attitude to the data structures that the workflow operates on, to the control flow assumed in workflow processes, and to the parallelism of processes and methods of their synchronization. While in the traditional workflow processes the control flow is determined statically within the process definitions, in the declarative workflow processes the control flow is dynamic, determined by the conditions that occur in the workflow data and the service environment. The workflow environment consists of so-called active objects, which play a double role. On the one hand, active objects are persistent data structures that can be queried and managed according to the syntax and semantics of an ordinary query language. On the other hand, active objects possess active parts that are executable. We distinguish four such active parts: firecondition, execution code, endcondition and endcode. An active object waits for execution until the time when its firecondition becomes true. After that, the object’s execution code is executed, and all its active sub-objects are put into the waiting-for-execution state (and perhaps executed if their fireconditions become true). The execution of the execution code of a given active object is terminated when either all the actions are completed (including active sub-objects) or its endcondition becomes true. As after fulfillment of the endcondition some actions might be necessary (e.g. aborting transactions), an optional endcode can be executed too.

In principle, all active objects are executed in parallel, which amounts to a fundamentally different attitude to the control flow of the workflow. The flow is not determined explicitly (e.g. as a graph a a Petri net). Instead, the flow is determined dynamically using only fireconditions and endconditions that depend on the workflow environment state, the database state, the machine state (e.g. clocks), etc. This idea extends the classical (control-flow-oriented) view on workflows: it allows one for determining the sequence of actions by setting the states of some tasks that are used by a fireconditions of other tasks. However, it also allows for many new features of workflows that are  unattainable in the classical approaches. In this approach, the workflow graph remains a PERT (Program Evaluation and Review Technique) network rather than a Petri net.

There are several big advantages of this approach to the workflow. Firstly, parallel execution of many processes and their synchronization are not constrained. Secondly, the workflow environment can be subject to ad hoc changes in the running and waiting processes, according to the current business needs. The main motivation for this research is flexibility of workflow change - in particular, grouping and ungrouping of the processes, dynamic changes in their structures, dynamic insertion of new tasks into running workflow instances, etc. This report presents in some detail the major consequences and technical issues related to the above idea, which has been already implemented within ODRA, a prototype object-oriented database management system. As the workflow programming language we use SBQL, the object-oriented database query and programming language implemented in ODRA. The current prototype implementation of the idea will be extended in an essential way.

Keywords

workflow, workflow management system, object-oriented, declarative, query language, workflow programming language, active object, control flow, firecondition, endcondition, PERT, mass parallelism, dynamic workflow change, grouping of processes, ungrouping of processes, workflow resource management, ODRA, SBQL, strong type checking, transaction processing, distributed processing, programming through reflection