Object-Oriented Declarative Workflow

 

 

by Kazimierz Subieta

Polish-Japanese Institute of Information Technology

Chair of Software Engineering

May 2009

 

 

This page presents initial assumptions of  the project “Workflow Systems with Extended Functionality” (Systemy przepływu prac o rozszerzonej funkcjonalności), supported by the Polish Ministry of Science and Higher Education (Ministerstwo Nauki i Szkolnictwa Wyższego) by the grant N N516 3755 34. The projects lasts since 14 April 2008 till 13 April 2010.

The main idea of the project assumes a totally different attitude to data structures that workflow operates on, to control flow assumed in workflow processes and to parallelism of processes and methods of their synchronization. While in traditional workflow processes the control flow is determined first of all, in the declarative workflow the control flow is dynamic, determined by conditions that appear in the workflow data and service environment.

The workflow environment consists of so-called active objects that have double roles. On one side active objects are data structures that can be queries and managed according to the ordinary query syntax and semantics. On the other hand, active objects possess active parts that are executable. We distinguish four such active parts: fire condition, execution code, end condition and end code. An active object is waiting for execution up to the time when its fire condition becomes true. After that the object execution code is executed and all its active sub-objects are set into the waiting-for-execution state (and perhaps executed if their fire conditions become true). The execution of the execution code of a given active object is terminated when all actions are done or its end condition becomes true. It is possible that after end condition some actions would be necessary (e.g. aborting transactions), hence an optional end code can be executed.

In principle, all active objects are executed in parallel, which means a fundamentally different attitude to workflow control flow. The flow is not determined explicitly (e.g. as a graph a la Petri net), but the flow is determined only by fire conditions and end conditions that depend on a workflow environment state, a database state, a machine state (e.g. clocks), etc. This idea makes it possible to make the sequence of some actions only by setting a state of a task A that is used by a fire condition of  a task B. In this way the workflow graph remains a PERT network rather than Petri net.

There are several big advantages of this approach to workflow. Firstly, the parallel execution of many processes and their synchronization is not constrained. Secondly, the workflow environment can be the subject of ad hoc changes of running and waiting processes, according to the current business needs. Workflow change flexibility, in particular, grouping and ungrouping of processes, dynamic changes of their structures, dynamic inserting new tasks to running workflow instances, etc. is the main motivation for this research.

The idea is already implemented within ODRA, a prototype object-oriented database management system. As a workflow programming language we use SBQL, an object-oriented database query and programming language implemented in ODRA. The current prototype implementation of the idea will be essentially extended.

Keywords: workflow, workflow management system, object-oriented, declarative, query language, workflow programming language, active object, control flow, fire condition, end condition, PERT, mass parallelism, dynamic workflow change, grouping of processes, ungrouping of processes, workflow resource management, ODRA, SBQL, strong type checking, transaction, distributed processing, programming through reflexion

Last modified: May 29, 2009