The Prototype Wits Enterprise Workflow Engine (WEWE)

5.1 Introduction

This chapter presents the design and implementation details of the prototype. WEWE was designed and developed to verify if the blackboard paradigm can be used to implement a workflow engine. To simplify the design process, it was split into four stages. In the first three stages the three main components of the blackboard paradigm were designed starting with the blackboard, specialists and ending with the orchestrator/controller. The last stage involved the design of the ancillary components (WF client apps, WF agents, logger, communication layer etc) which fall outside the blackboard paradigm but are necessary to render the workflow engine application operational. Each blackboard system component was designed in accordance with the guidelines and stipulations laid out in [16].

5.2 The Blackboard

The blackboard is a global data-structure. Every component inside the blackboard system (orchestrator/controller and specialists) needs to interact with the blackboard (global data-structure). The design of the blackboard component is critical since it affects all other components within the system. Careful consideration had to be given as to how the specialists would efficiently monitor (performance) and interact with the blackboard. The blackboard also needed to be structured to allow workflows to be easily executed.

5.2.1 Overall Structure

Generally, workflow engines allow the creation of a workflow definition which is the description of some business process with enough information (tasks and control flow description) to be able to be executed by a WFMS. An executing instance of this workflow definition is called a ‘workflow process instance’ or a ‘case’ [20]. At any one time there can be multiple workflow process instances concurrently running but which are completely independent from each other. For instance, consider the example in Section 2.7 of a workflow for an employee submitting a

leave application. In a workflow engine, this workflow for employee leave applications will be saved in the workflow entity that houses all the workflows within the workflow engine. Any leave applications that are received will create a new instance of the workflow that will be encapsulated as a workflow process instance. It is clear that there exists a one-to-many relationship between a workflow and its associated instances. This fundamental relationship in WFMSs, shown in Figure 22, formed the basis on which the blackboard’s structure was designed.

Figure 22 : A UML diagram of the fundamental relationship between workflows and process instances.

It is stipulated in [16] that the blackboard should have objects that are hierarchically organized. These objects can be organized into zones on the blackboard with which specialists can interact. The relationship in Figure 22 assisted in organizing the blackboard hierarchically. Firstly, a ‘workflow process instance’ object was created containing all process and control data of a single process instance. Functionality that can be used by specialists and the controller/orchestrator for retrieving information, editing, deleting and adding data was also added to this object. A ‘workflow’ object was created to contain all the workflow process instance objects. To state it plainly, the ‘workflow’ object is used for grouping workflow process instances of the same type of workflow. These workflow objects containing their WF process instances can be placed on the blackboard. Thus, a simple and intuitive object hierarchy of two levels was used to structure the blackboard shown in Figure 23.

It can be seen from Figure 23 that the blackboard is split into zones for each workflow process instance. This is beneficial as a set of specialists for a specific workflow process instance can specifically monitor information pertinent to that WF process instance instead of arbitrarily scanning large irrelevant portions of the blackboard to find information of relevance. The staging zone is completely separate from the WF and WF process instance zones. It is used by the orchestrator/controller to prepare new workflow processes. Once the new WF processes are setup, the orchestrator transfers these new workflow process instances into their relevant WF zones.

Workflow

Workflow Process Instance (Case)

1

Figure 23: The conceptual structure of WEWE’s blackboard.

5.2.2 Implementation

Implementation details of how the blackboard component is built are contained in Appendix A. It is recommended that the reader read through this section to gain a better appreciation and understanding of this component. Remember that a shared memory blackboard (SMBB) approach is taken to build the workflow engine. With the SMBB approach, multiple specialists are allowed to access the blackboard at the same time. In the context of a single workflow process instance, multiple specialists should be able to gain direct access to the workflow process instance zone. A locking strategy is employed that prevents many specialists writing to a single piece of WF process data within the WF process instance zone at the same time while allowing multiple specialists to read any piece of data concurrently.

A blackboard of this nature using this locking strategy was easily implementable using Java’s map data structures specifically the concurrent hash map data structure [96]. The blackboard was designed to essentially consist of a concurrent hash map of workflow objects and these workflow objects further consist of a concurrent hash map of WF process instances as shown in Figure 24. Specialists that want to monitor and interact with a particular workflow process instance (a zone) can hash the blackboard by simply using the ID of the workflow and the ID of the WF process instance to retrieve the required WF process instance object. If a new WF process is spawned, the

Blackboard

Workflow 1 Zone

WF Process Instance 1 Zone

WF Process Instance 2 Zone

WF Process Instance 3 Zone

WF Process Instance N Zone

Workflow 2 Zone

WF Process Instance 1 Zone

WF Process Instance 2 Zone

WF Process Instance 3 Zone

WF Process Instance N Zone