Most of today's business applications have to deal with automated workflows. In this paper, we argue that the blackboard pattern can be used to create an architecture for the development of such workflows. We illustrate how the fundamental building parts of a workflow are addressed in such an architecture. The development of a prototypical group calendaring application verified the proposed architecture. It also served as a basis for contrasting the approach with commonly used workflow control constructs.
The work presented in this paper is motivated by the need for architectural guidance in workflow development. We aim to provide a workflow architecture with focus on the following aspects.
Workflow management systems often come in an all or nothing fashion with
a variety of features [
The concept of a workflow commonly fits a model that consists of two tiers
[
Coordination and execution of activities is a responsibility of the flow tier. The proposed workflow architecture must provide a solution for the implementation of these two tiers.
A workflow can be described from different perspectives [
The blackboard model emerged in the domain of artificial intelligence [
The blackboard is a shared repository containing the data from various
problem solving states [
The domain knowledge is partitioned into knowledge sources which read
data from and write data to a blackboard. Knowledge sources are independent
because they don’t communicate with each other directly or know what other
sources are present [
The control is the component that rules the system. Depending on the situation on the blackboard, it selects appropriate actions and executes them. In a workflow architecture, the control corresponds to the flow tier. It inspects the blackboard and decides which activities have to be executed. For each activity, a corresponding action is selected and executed.
A major issue of the control component, as it is suggested by the blackboard
pattern, is the intermixing of two tasks: selection of actions and tracking the flow.
The blackboard based control plan [
To verify the proposed architecture, a prototypical system has been implemented. The system can be considered to be part of a fictitious larger groupware system that provides a calendaring functionality. The scenario we have implemented covers scheduling of meetings among a number of participants. In particular, it provides a sophisticated conflict resolution strategy that applies in situations, where a meeting is scheduled and one or more participants are not available at the proposed date.
The scheduling workflow was implemented with the blackboard architecture
as described in the previous section. For the control plan, we chose a rule-based
implementation. Each step in a plan is associated with a rule that is evaluated
against the data on a blackboard. If a rule evaluates to true, it is desirable
to perform the corresponding step. To map actions to steps, the control uses a
creditability value that expresses the ability of an action to complete a particular
step [
The OpenBBS framework [
In section 2, support for commonly used control flow patterns has been defined as
one goal for our approach. Based on the experiences with the group calendaring
system, we evaluated if and how the five basic control flow patterns [
Sequence: Add a step for each activity to the control plan and implement/assign an action for each step. Associate the rule for a step S2 that follows a step S1 with the existence of the output data of S1 on the blackboard. The action that performs step S1 must write the required output data to the blackboard.
Exclusive Choice: One of several possible branches is chosen. For every branch, add a step to the control plan. The rule for each step must check the condition for the branch in such a way that no or only one step is possible for a given situation on the blackboard.
Parallel Split: Multiple activities or sequences of activities have to be performed in parallel. Define a separate control plan for each sequence. Associate a rule with the initial steps for each plan. The rule evaluates to true if the data that has to be processed in parallel is written to the blackboard. For true concurrent execution, each control plan has to be executed by a dedicated control instance in its own thread. If concurrent execution is not required, a single control instance that executes all plans in the same thread is an alternative.
Synchronization: An activity must not be performed before multiple parallel activities or sequences of activities are completed. Add a step S to the control plan that represents the depending activity. The rule for S must not evaluate to true before the steps which represent the parallel activities did complete. Assuming that each of this steps writes a result to the blackboard, the rule that is associated with S has to check for the existence of all results.
Simple Merge: An activity is performed after one of multiple possible branches has been executed. It is assumed that none of the alternative branches is ever executed in parallel. The implementation in the control plan is similar to synchronization. Define a step S for the depending activity. Associate a rule with S that evaluates to true if the result from at least one of the branches is present on the blackboard. 6
In this paper, we introduced a blackboard architecture for the development of workflows. We have shown how work- and flow-tier are addressed in this approach. Practicability has been verified through the prototypical implementation of a group calendaring system. Based on the experiences with this system, we evaluated the implementation of commonly used workflow control flow constructs with the proposed architecture. A complete evaluation of the full set of control patterns remains to be done. Such a study should investigate whether the blackboard approach is not only valuable as an architecture for the custom development of workflows but can also serve as a foundation for the implementation of extensible and customizable workflow management systems.