TriGSflow
Active Object-Oriented Workflow Management
G. Kappel, B. Pröll, S. Rausch-Schott, W. Retschitzegger
Institute of Computer Science, Department of Information Systems
University of Linz, AUSTRIA
email: {gerti, birgit, stefan, werner}@ifs.uni-linz.ac.at
Abstract
We present the multi-paradigm architecture TriGSflow
for a workflow management system. TriGSflow is based on
an active extension of the commercial object-oriented
database system GemStoneTM. TriGSflow takes full advan-
tage of the capabilities of the underlying database system
such as reliability, recovery, transaction management, and
authorization. At the current stage of implementation the
novel features of TriGSflow are the seamless integration of
ECA rules into an object-oriented model, the flexibility of
workflow specification due to rule modeling, and the inte-
gration of external applications as part of workflow pro-
cessing.
Keywords: workflow model based on ECA rules, active
object-oriented database
1. Introduction
A workflow management system (WFMS) supports the
design, execution and monitoring of in general long-last-
ing business processes that typically involve multiple
activities and multiple collaborating persons in a distrib-
uted environement. WFMSs originate from the office
automation efforts in the late 1970s and early 1980s, and
from the imaging-based systems in the 1980s, both of
which aimed at automating office paper processing
[Hsu93]. Today, WFMSs are becoming increasingly visi-
ble as a means for improving the productivity and compet-
itive edge of an organization via reengineering and
automation of business processes. Due to the complex
nature of WFMSs we suggest a multi-paradigm approach
for implementing a WFMS consisting of the following
basic concepts:
TM GemStone is a registered trademark of Servio Corporation
(1) Object-oriented Paradigm: The object-oriented para-
digm supports among others the modeling of structure and
behavior of problem domain objects which may be reused
for building different workflow systems [Enge94]. Prob-
lem domain objects represent real world objects and con-
cepts of a problem domain, such as student and
scholarship of a scholarship application system. Besides
the issue of reusability the object-oriented paradigm pro-
vides an open environment necessary to adapt to changing
requirements of the application domain [Kapp91].
(2) Rule-based Paradigm: The rule-based paradigm
allows to specify certain system behavior in addition to
local object behavior. Whereas the latter is expressed in
terms of methods invoked on single objects the former is
specified in terms of Event/Condition/Action triplets
(ECA rules) [Daya88]. These so-called active concepts
allow the system to monitor the situation represented by
an event and by one or more conditions and to execute the
corresponding actions when the event occurs and the con-
ditions evaluate to true [Beer91]. This system behavior is
especially useful in the area of complex business pro-
cesses in order to express an event-driven and constraint-
driven system environment [Yang89]. By incorporating
rules the flexibility of a WFMS is increased. For example,
which person should perform a certain activity does not
have to be hard-coded but is defined in terms of a rule
which is dynamically evaluated.
(3) Transaction Paradigm: Business processes need cor-
rectness, reliability, and failure criteria to be enforced sim-
ilar to transaction systems. They consist of interrelated
activities with data flow constraints and control flow con-
straints, again similar to transaction systems. However,
due to their long-lasting asynchronous nature business
processes require extended transaction models incorporat-
ing long transactions and multi-level transactions [Geor93,
Shet93]. Concerning the latter, multi-level transactions are
necessary since there are at least three levels of dependen-
cies which have to be distinguished in a full-fledged
WFMS. These three levels are:
• Intra-Activity: A workflow consists of a series of activ-
ities, each activity being a transaction. Some activity
may need cooperative multi-user interaction, thus, tra-
ditional transaction models have to be extended to sup-
port these needs.
• Inter-Activity Intra-Workflow: There exist several
dependencies between activities such as temporal
dependencies, data dependencies, and termination
dependencies. The traditional correctness criterion for
transaction systems, serializability, is not sufficient to
cope with these inter-transaction dependencies. A feasi-
ble approach will be to start with the nested transaction
model and extend the correctness model on the basis of
the above mentioned dependencies.
• Inter-Workflow: Similar to the previous point there
exist several dependencies between workflows of the
same or of different kinds within a multiworkflow man-
agement system. These dependencies have to be
addressed within an advanced transaction model for
workflow systems, too.
In addition to the above mentioned transaction require-
ments execution correctness requirements such as failure
atomicity and execution atomicity also have to be
addressed. [Daya90, Garc94, McCa93].
(4) Distribution Paradigm: The distribution paradigm
comes up with the need to access distributed information
sources [Rein93]. These information sources will not only
supply passive data but also applications and potentially
other WFMSs which have to interoperate. Since these dis-
tributed information sources have to comply with a com-
mon protocol OMGs CORBA protocol [Desh93] will
become very important.
(5) Integration Paradigm: Business processes have to
integrate external isolated applications with new applica-
tions already built into the system. A convenient approach
of doing this is in terms of wrapper objects, which provide
a homogeneous interface to heterogeneous external appli-
cations. In addition, wrapper objects backed by database
systems provide transaction capabilities to otherwise
transaction-less applications.
The main contribution of this paper is to devise a work-
flow model incorporating object-oriented, active and inte-
gration concepts. The model is based on existing work in
this area [Rein93, Bußl94, Jasp94] yet incorporates exten-
sions based on the object-oriented paradigm and the flexi-
ble integration of the object-oriented and the rule-based
paradigm. The transaction paradigm and the distribution
paradigm are not dealt with in this paper but are subject of
ongoing research. A first prototype of the workflow model
has been implemented on top of TriGS, an active exten-
sion of the commercially available object-oriented data-
base system GemStone [Kapp94a, Butt91].
The paper is organized as follows: Section 2 introduces
the object-oriented workflow model as well as integration
aspects. Section 3 incorporates rule modeling and Section
4 points to ongoing research.
2. Object-oriented workflow model
In the following we describe our workflow model
which is based on the object-oriented paradigm. The
workflow model is generic in the sense that different kinds
of business processes such as application for scholarship,
reimbursement of business trips, and reordering of goods
are modeled as instances of the corresponding classes of
the workflow model. The class hierarchy and the class
composition hierarchy of the workflow model are illus-
trated in Figure 1. The class hierarchy represents the inher-
itance (is-a) relationship between an object class called
subclass and another object class called superclass. The
class composition hierarchy represents the has-component
relationship between an object class called complex object
class and another object class called component object
class.
2.1 Agents and activities
A workflow type represents a certain kind of business
process, e.g., an application for scholarship (cf. class
BusinessProcess and its instance WF_Type in Fig-
ure 1). It is defined by a number of various activities
(Activity) representing subtasks of the business pro-
cess. An Agent (Agent) is able to perform different activ-
ities, and a specific activity can be performed by different
agents called relevant agents. Consequently, one or more
appropriate agents called actual agents, which actually
perform the activity, have to be selected at runtime. This
selection process can be done on basis of a specific syn-
chronization policy [Bußl94], e.g., agents on holidays are
not allowed to be selected. For sake of simplicity the dis-
cussion in this paper is focused on a single actual agent.
Thus, the selection process based on a set of relevant
agents always returns a single actual agent. Agents are
autonomous. They are modeled by autonomous objects
which are implemented as independent processes commu-
nicating via message passing. Agents are classified into
automatic agents (AutoAgent), e.g., a machine, and
human agents (HumanAgent). The latter ones represent
users belonging to the organizational structure of an enter-
prise. In case of a human agent, the activity prints some
instruction on the screen and waits until the user signals
that the job has been finished. The activity may be exe-
cuted either without any computer support, or it may be
executed by an application, e.g, a text processing system,
in interaction with the human agent. In the latter case, the
human agent is responsible for starting the application. In
contrast to human agents, automatic agents are able to per-
form their activities without user interaction. Conse-
quently, these activities can be triggered automatically. For
an in-depth discussion of the execution of activities by
automatic agents we refer to Section 2.4.
Agents cooperate with each other in order to realize the
business process. This cooperation is achieved by specify-
ing both a certain control flow between activities on the
basis of an activity net (cf. Section 2.2), and a workflow on
the basis of orders (cf. Section 2.3).
2.2 Control flow
The execution order of activities is determined by their
relationships within an activity net. These relationships
comprise basic control structures, namely sequencing,
branching, and joining (cf. Figure 2) [DeAn81, Sche94].
The semantics of these control structures extend those of
Petri nets [Pete81] in the sense that inclusive OR forking
and inclusive OR joining are also explicitly supported in
TriGSflow.
We distinguish three different kinds of branching,
namely, exOR-Alternative (cf. Figure 2c), i.e., only one of
the specified successor activities may be triggered by the
predecessor activity, concurrency (cf. Figure 2b), i.e., all
of the specified successors are triggered, and inOR-Alter-
native (cf. Figure 2a), i.e,. a subset of the specified succes-
sors is chosen. If two or more parallel branches have the
same successor activity a joining activity has to be sup-
plied. An AND-Join specifies that the common successor
cannot be performed until all predecessor activities have
been finished. In contrast, an exOR-Join specifies that the
successor activity can be performed as soon as one of the
predecessors has been finished. Last but not least, an
inOR-Join specifies that a subset of the predecessor activi-
ties has to be finished before the successor activity is
enabled. Note, that in case of inOR-join and exOR-join it
might be necessary to garbage collect folders (for a discus-

BusinessProcess
•name
•folders
•initAgent
•startActivity
•stateOfWF AgentSpec
•name
Folder
Order •bp
WF_Type Activity •folder •data
•name Worklist •activity
•relevantAgents •orders
•actualAgents

Agent InternalAppClass
•worklist •className
•methodSignature

HumanAgent AutoAgent
•userID
•passwd
ExternalApp InternalAppObject
•startingCommand •objectID

Legend: ... has-component (single-valued) ... instance-of

... has-components (multi-valued) ... object class
... is-a ... instance of an object class

Figure 1. Class hierarchy and class composition hierarchy of TriGSflow

sion of folders see section 2.3) which are still residing in (cf. instance variable startActivity in Figure 1) - a
one or several of the parallel branches but will not be used new folder is created. The flow of this folder from one
any more for further processing. agent‘s worklist to another‘s which is controlled by the
activity net is called a workflow and represents the execu-
(1) Sequence: tion of a certain workflow type. In case of alternative
branching, the decision which activities to actually per-
form is made on the basis of folder contents and further
activity 1 activity 2
information concerning the workflow up to that point, e.g.,
which agent(s) performed former activities. If more than
one successor activity is performed concurrently a refer-
(2a) inOR-Alternative: (3a) inOR-Join: ence to the folder is transferred to each responsible agent.
Concurrent folder access of concurrently working agents
activity 2 activity 4 is handled by the transaction mechanism of the underlying
∨ ∨ object-oriented database system. Note, that duplicating
activity 1 activity 6
folders for concurrent access might also be useful in some
activity 3 activity 5 cases. However, duplication of folders involves version
management which will not be treated in this paper.

(2b) Concurrency: (3b) AND-Join: 2.4 Integration aspects

activity 4 TriGSflow allows to integrate both internal applications

∧
activity 2
activity 1
activity 3 activity 5
(2c) exOR-Alternative: (3c) exOR-Join:
activity 4
x
activity 2
activity 1
activity 3
activity 5
Figure 2. Basic Control Structures
More complex control structures, e.g., iteration can be
built by combining these basic control structures.
2.3 Workflow
Besides the specification of the execution order, data
exchange between agents is necessary for realizing coop-
eration. Agents constitute separate processes and commu-
nicate asynchronously in order to exchange data. In our
model asynchronous communication between agents is
realized by worklists (Worklist) associated with agents.
If an agent is requested to perform one of the activities an
order (Order) is inserted into its worklist specifying the
requested activity and including the data (within a folder -
Folder) necessary for performing the activity.
On every start of a business process - which can be
done by any agent capable of performing the start activity
∧ implemented within the same object-oriented environment
activity 6 as the workflow model and external applications such as a
spreadsheet application. Sometimes different applications
are able to realize an activity. For example, the activity
”send order“ (cf. Figure 6) can be realized by the external
applications “faxApp <fax-no> <order form>“
or ”mail <email-adr> <subject> <order
form>“. External applications are started by a shell com-
mand of the underlying operating system. In our model for
x
each external application which should perform an activity
activity 6
in some workflow an instance of class ExternalApp is
created and initialized with the starting command of the
application. When performing an activity which is realized
via an external application, i.e., when sending the message
perform to a respective instance of class Activity, a
wrapper method of class ExternalApp starts the exter-
nal application by sending the starting command to the
operating system shell. In addition, it coordinates data
flow to and from the external application according to its
requirements, e.g., get fax-no of desired supplier, and
waits until the application has finished. Occasionally,
resulting data has to be transfered back in order to be
accessed by the successor activities.
The integration of internal object-oriented applications
promotes the reusability of classes of the problem domain
to which the business process belongs. In object-oriented
applications behavior is realized by methods associated to
classes. In TriGSflow these methods are reused for the
implementation of activities. Analogous to external appli-
cations, for each class-method combination which is used
to realize one or more activities an instance of class
InternalAppClass is created and initialized with the
class name and the method signature. At runtime, as soon
as an instance of the specified class is selected the first
time in order to perform some activity (cf. Section 3.2 on
agent selection), a corresponding instance of class
InternalAppObject is created and initialized with a
reference to the selected agent object.
WFMS
∧
activity 2
∨ supports message events, that is any message sent to an
activity 1 activity 4
activity 3
Class A
•m1
•m2
Class B Class C
•m3 •m5
•m4 External
Internal Application
Application
ooDBS
Figure 3. Integration of internal and external applications
When executing a certain workflow every agent object
corresponds to a single process. Since TriGSflow is based
on a database system, integration on data level is simply
done by shared database objects. Note, that the class
AgentSpec is abstract, i.e., no instances of this class
may be created. Figure 3 illustrates the integration of the
internal methods m1 and m2 of class A, which are used to
perform activity1 and activity2, respectively, and
of method m5 of class C, which realizes activity3. In
addition, the external application printtool is used to
perform activity4.
Note that at present our model of integrating internal
applications and external applications does support the
integration of legacy systems to the extent that wrapper
objects hide the peculiarities of those systems and provide
the necessary transformation to and from those systems.
Real interoperability between TriGSflow and other (legacy)
systems, e.g., in terms of multiworkflow models, is subject
to ongoing research.
3. Rule model of TriGSflow
3.1 Basic concepts of TriGS
TriGS [Kapp94a, Kapp94b] is an active extension to
the commercial object-oriented database system Gem-
Stone and has been developed as part of a larger EC
ESPRIT project aiming at the development of next-gener-
ation production scheduling and control systems. TriGS is
based on the ECA paradigm [Daya88]. An Event-Condi-
tion-Action triplet is denoted as rule. The event part of a
rule is represented by a rule event selector determining the
event(s) which is (are) able to trigger the rule. Events rep-
resent real-world situations (e.g. a machine breakdown)
that form the basis for subsequent rule execution. TriGS
object may be associated with a message event, and time
events (e.g., every day or at 9 p.m.) as proposed in
SAMOS [Gatz92]. The condition part of a rule is specified
by a condition event selector, which defines when to eval-
uate the condition, and a Boolean expression (e.g., is the
machine available?), possibly based on the result of a data-
base query (e.g., select all orders that are scheduled on the
damaged machine). The action part (e.g., schedule the
next operation) is specified by an action event selector,
which defines when to execute the action, and a sequence
of arbitrary messages. Figure 4 defines the syntax of a rule
specification (note that only the major parts are specified)
using the Backus-Naur Form (BNF). The symbols ::= |
[ ] { } * are meta symbols belonging to the BNF for-
malism.
The specification of a rule responsible for fetching the
next operation from a machine's buffer and scheduling it
each time this machine becomes available is shown in the
following example:
DEFINE RULE MachineRule_1
ON POST (Machine, changeState: newState) DO
ON POST (rule_trgO, changeState: newState)
IF newState = 'available' THEN
ON POST (rule_trgO, changeState: newState)
EXECUTE rule_trgO schedule: (rule_trgO
getBuffer nextOperation).
The rule is triggered after execution (cf. keyword
POST) of the method changeState of class Machine.
Both, condition evaluation and action execution are done
immediately after triggering the rule since they are trig-
gered after executing the same method on the same object
(cf. keyword rule_trgO which stands for rule trigger-
ing object).
To obtain tight integration with the underlying data
model as well as for the purpose of dynamic rule definition
and manipulation, the three components of the rule as well
as the rule itself are first class objects. That is, new rules
are defined by creating new instances of predefined object
classes representing the rule and its components and
equipping them with appropriate values.
 <rule_definition>
<rule_event_selector>
<cond_event_selector>
<act_event_selector>
<path_expr>
<set_of_instances>
<transaction_mode>
::= DEFINE [VARIANT | INVARIANT] RULE <rule_name>
ON <rule_event_selector> DO /*event part*/
ON <cond_event_selector>
IF <boolean_expr> THEN /*condition part*/
ON <act_event_selector>
EXECUTE <action> /*action part*/
[WITH PRIORITY <number>]
[ACTIVATED [FOR <set_of_instances>] |
DEACTIVATED [FOR <set_of_instances>] ]
[TRANSACTION (<transaction_mode>,<transaction_mode>)].
::= <time_event> |
{PRE|POST} ([<class_name>,]
[CLASS_METHOD|INSTANCE_METHOD] <method_signature>)
::= <rule_event_selector> |
{PRE|POST} (rule_trgO[.<path_expr>],<method_signature>)
::= <cond_event_selector> |
{PRE|POST} (cond_trgO[.<path_expr>],<method_signature>)
::= <instance_var>{.<path_expr>}*
::= ({<instance_ref>|<expr>} {,<instance_ref>|<expr>}*)
::= SERIAL | PARALLEL

Figure 4. BNF of rule specification

Considering rules in the context of the class hierarchy
of an object-oriented database schema they may be
attached to a specific class or defined apart from any class.
According to this distinction TriGS supports two catego-
ries of rules, called local rules and global rules. A local
rule allows to monitor specific behavior of certain classes.
Thus the event selector of a local rule consists of a trigger-
ing class in addition to a triggering method. The triggering
class denotes the class which the rule is attached to. The
triggering method denotes, in terms of GemStone, a class
method or an instance method (default) which raises the
event before or after its execution (cf. keywords
CLASS_METHOD/INSTANCE_METHOD and PRE/POST
in Figure 4). Since a local rule is attached to a specific
class it is subject to inheritance. This implies that a local
rule is triggered not only by invoking the triggering
method on any object of the triggering class but also by
invoking this method on any object of its subclasses. Fur-
thermore, TriGS allows to override inherited rules in sub-
classes [Kapp94a].
In contrast to a local rule, a global rule allows to moni-
tor specific behavior of arbitrary classes. Thus the event
selector of a global rule consists of a triggering method
only. Consequently, a global rule monitors all classes
which know the triggering method. Since a global rule is
attached to a specific method only, it is neither subject to
inheritance nor overriding. Both local and global rules
may be (de-)activated at different levels of granularity
ranging from object level to class level (cf. keywords
ACTIVATED and DEACTIVATED in Figure 4). Class
level granularity implies (de-)activating a rule for all
instances within its scope. Object level granularity allows
(de-)activating a rule for specific instances thus supporting
a powerful exception handling mechanism.
3.2 Incorporating rules into the object-oriented
workflow model
In our workflow model TriGSflow ECA rules are
applied in three different areas, which are illustrated in
Figure 5, namely activity ordering, agent selection, and
worklist management. The different kinds of rules are
orthogonal to each other. In the following we discuss the
use of ECA rules for TriGSflow in detail. All examples
given are taken from a simple reordering system. Part of
the activity net of the reordering system is depicted in Fig-
ure 6. The workflow is started every time the need to reor-
der a certain item is indicated. In most examples, the
coupling modes between event and condition as well as
between condition and action are immediate according to
the notion in [Kapp94b] resulting in identical event selec-
tors. To increase readability condition event selectors and/
or action event selectors are omitted in those cases.
 ECA rules for Worklist Management
Worklist Agent Worklist Agent
ECA rules for
Agent Selection
∧ ∧
Activity 1 Activity 2
ECA rules for
Activity Ordering
Figure 5. Application areas for ECA rules
Activity ordering: The relationships between activities,
i.e., the activity net, can be realized by using ECA rules,
thus specifying a certain workflow type. Concerning the
mapping of relationships to rules we can identify six cases
according to the basic control structures:
• a relationship representing a sequence is mapped to a
single rule
• each relationship taking part in an OR-Alternative
(exclusive OR or inclusive OR) is mapped to a single
rule
• all relationships taking part in a concurrent fork are
mapped to a single rule
• each relationship taking part in an exOR-Join is
mapped to a single rule
• all relationships taking part in an inOR-Join are
mapped to one or more rules depending on the desired
semantics
• all relationships taking part in an AND-Join are
mapped to a single rule
The event of an activity ordering rule always consti-
tutes the end of the preceding activity or - in case of an
AND-Join or of an inOR-Join - of all participating preced-
ing activities, respectively. The condition checks whether
the succeeding activity has to be performed or not. This is
done by evaluating queries against the actual folder and/or
other data concerning the actual workflow, e.g., if a certain
date is expired the activity is not performed. In case of an
inOR-Alternative the result sets of the conditions may
overlap, whereas an exOR-Alternative is reflected by
mutual exclusive conditions. Note, that an exception han-
dling mechanism [Aura89] has to handle the case that all
conditions evaluate to false, i.e., no succeeding activity
Worklist Agent Worklist Agent Worklist Agent Worklist Agent
Activity 3 Activity 5
Activity 7
Activity 4 Activity 6
would be executed. Exception handling will not be treated
further in this paper. The action of an activity ordering rule
has to notify the agent responsible for performing the suc-
ceeding activity. The method notifyAgent puts a cor-
responding order for the successor activity into the
worklist of the agent chosen to perform this activity (for
selecting agents see next section). The method perform
starts the execution of the activity no matter whether a
human agent or an automatic agent is engaged. In case of a
human agent it waits until the human agent signals the end
of the execution. Every rule responsible for activity order-
ing contains the methods perform and notifyAgent
in its event part and action part, respectively.
Consider the activity net in Figure 6. Furthermore, con-
sider the following rules realizing an exOR-Alternative
between executing the activity “get offers“ and executing
no activity at all, and equivalently realizing an exOR-Join
between the activity “get offers“ and no activity. This par-
ticular situation of exOR-joining with “no activity” is han-
dled in such a way that the activity “create order form”
triggers either “get offers” or “select supplier”.
get
offers
x x ...
create select send
order form supplier order
Figure 6. Part of an Activity Net
The first two rules named R_GetOffers and
R_SelectSupplier1 are activated for the same
instance of class Activity, namely
a_create_order_form. That is, after the method
perform has been executed on that instance (denoted by
the keyword POST), both rules are triggered. The condi-
tion of the rule named R_GetOffers checks if offers are
needed that are missing or that are no longer up-to-date. If
the condition evaluates to true the action is executed by
sending the message notifyAgent to the instance
a_get_offers of class Activity representing one of
the mutual exclusive successors of the activity
a_create_order_form within the activity net (cf.
Figure 6).
DEFINE RULE R_GetOffers
ON POST (Activity, perform) DO
IF Offers notUpToDateFor: ((rule_trgO
getFolder at:’Order’)
positions) THEN
EXECUTE a_get_offers notifyAgent
ACTIVATED FOR (a_create_order_form).
The condition of the rule named
R_SelectSupplier1 is complementary to the condi-
tion of R_GetOffers. If it evaluates to true no more
offers are required and therefore the supplier can be
selected immediately by sending the message notify-
Agent to the instance a_select_supplier of class
Activity representing the other successor of the activ-
ity a_create_order_form.
DEFINE RULE R_SelectSupplier1
ON POST (Activity, perform) DO
IF Offers areUpToDateFor: ((rule_trgO
getFolder at: ’Order’)
positions) THEN
EXECUTE a_select_supplier notifyAgent
ACTIVATED FOR (a_create_order_form).
The third rule named R_SelectSupplier2 is acti-
vated for the instance a_get_offers of class Activ-
ity. The condition is set to be always true denoting that
all offers are available now and that the action which noti-
fies the agent(s) responsible for selecting a supplier is exe-
cuted in any case.
DEFINE RULE R_SelectSupplier2
ON POST (Activity, perform) DO
IF true THEN
EXECUTE a_select_supplier notifyAgent
ACTIVATED FOR (a_get_offers).
Agent selection: The process of selecting one or more
agents performing a certain activity consists of three steps.
Below, these steps are explained for internal application
agents. They apply equally for external application agents
and human agents.
(1) Implicit definition of possible agents: By mapping an
activity to a certain method of an internal application,
the set of classes able to respond to the corresponding
message is implicitly defined. It comprises all classes
where the method has been originally defined and all
direct or indirect subclasses of those classes.
(2) Explicit definition of relevant agents: At definition
time it is useful to reduce the set of possible agents to
agents which are relevant for the particular workflow
type, thus incorporating more semantics into the
model. This can be done by collecting the set of rele-
vant agents as instances of class InternalApp-
class (cf. Figure 1). The relevant agents of a specific
activity are referenced via its instance variable rel-
evantAgents.
(3) Selection of actual agents: For a specific workflow the
set of relevant agents may be again reduced to a set of
actual agents on the basis of actual data by using ECA
rules. In contrast to the first two steps where agent
selection is done at class level, the selection of actual
agents is done at instance level. Applying rules for
actual agent selection provides the possibility to react
immediately to state changes of some relevant agent,
e.g., a machine breakdown. Furthermore, it is possible
to implement different selection policies and to switch
between them dynamically by simply activating and
deactivating the corresponding rule at activity instance
level. Note, only one specific selection rule can be
active for a certain activity at one point in time. Con-
cerning the integration of internal application classes,
if an instance of an internal application class is
selected as actual agent a corresponding instance of
class InternalAppObject is created if it does not
already exist.
The following rule named R_MinWorkload realizes
the selection of actual agents on the basis of a minimal
workload policy.
DEFINE RULE R_MinWorkload
ON PRE (Activity, notifyAgent) DO
IF (rule_trgO relevantAgents)
selMinWorkload THEN
EXECUTE (rule_trgO actualAgents)
removeAll; add: QUERY_RESULT
ACTIVATED FOR (a_select_supplier).
The event is signaled before the method notify-
Agent of class Activity is executed (denoted by the
keyword PRE). The condition determines the set of actual
agents according to a specific selection policy, e.g., select-
ing the agent with the lowest workload (selMinWork-
load). Analogous to the condition of activity ordering
rules this is done by means of queries against the actual
folder and/or other data concerning the actual workflow.
The selected agent is passed to the action of the rule (cf.
keyword QUERY_RESULT). The action of the rule assigns
the query result to the instance variable actualAgents
of the triggering object.
Worklist management: ECA rules are also applied to
coordinate the processing of orders waiting inside the
worklist of a specific agent. They monitor the worklists of
automatic agents and start processing the next order every
time an automatic agent becomes inactive. This state is
indicated after an order is removed from the worklist. The
following rule named R_StartOnRemove is triggered
every time the message remove is sent to an instance of
class Worklist that belongs to an automatic agent (cf.
ACTIVATED FOR clause). The condition checks
whether there are remaining orders to be processed. If the
worklist is not empty, i.e., there are remaining orders, the
action selects the next order in turn (method nex-
tOrder) and sends the message perform to the corre-
sponding activity.
DEFINE RULE R_StartOnRemove
ON POST (Worklist, remove) DO
IF rule_trgO isEmpty isFalse THEN
EXECUTE ((rule_trgO nextOrder)
activity) perform
ACTIVATED FOR (AutoAgent collect:
[:x|x worklist]).
The execution of an order which is inserted into an
empty worklist is triggered by another rule, named
R_StartOnInsert, where the event part is defined on
the insertion of that order. Note that condition event selec-
tor and action event selector are different. Thus, before the
message insert is sent to an instance of class
Worklist, the rule is triggered and its condition is
checked immediately. If the actual worklist is empty
before the insert operation takes place the action of this
rule, which is executed after the insert operation, starts
processing of the next order analogous to rule
R_StartOnRemove.
DEFINE RULE R_StartOnInsert
ON PRE (Worklist, insert) DO
IF rule_trgO isEmpty THEN
ON POST (ruleTrgO, insert)
EXECUTE ((rule_trgO nextOrder)
activity) perform
ACTIVATED FOR (AutoAgent collect:
[:x|x worklist]).
4. Ongoing research
A first prototype of TriGSflow implementing activity
ordering and agent selection is operational. Ongoing
research comprises the following issues. Detailed seman-
tics of the various control structure primitives including
iteration in terms of ECA rules have to be defined. The
integration of external applications is already possible,
however detailed synchronization mechanisms are still
missing. The organization hierarchy together with a com-
petence hierarchy, also called role hierarchy in the work-
flow literature, has to be incorporated into our agent
selection strategy. A multi-level transaction model includ-
ing intra-workflow transactions and inter-workflow trans-
actions will be defined to provide for flexible yet stable
workflow management. TriGSflow has been applied to tra-
ditional office automation environments so far. However,
if workflow systems want to gain leverage on a broader
scope they have to support the whole production process
in addition to administrative processes. The applicability
of TriGSflow for implementing a production planning and
control system is currently evaluated in a case study. Last
but not least, tools for designing workflow applications
based on active object-oriented database systems are still
missing. There is a growing awareness of the problem of
designing active object-oriented database applications
[Bich94], and there are several graphical workflow model-
ing tools on the market. However, the integration of these
two vivid research areas taking into account the ideosyn-
cracies of a high-level design environment for workflow
applications incorporating rules has to be further explored.
Acknowledgement:
The authors are grateful to P. Lang for his valuable help in
implementing the TriGSflow prototype.
References
[Aura89] E. Auramäki, M. Leppänen, Exceptions and
Office Information Systems, Office Information
Systems: The Design Process, B. Pernici and
A.A. Verrijn-Stuart (eds.), North Holland, 1989
[Bich94] P. Bichler, M. Schrefl, Active Object-Oriented
Database Design Using Active Object/Behavior
Diagrams, Proc. of the IEEE Fourth Int. Work-
shop on Research Issues in Data Engineering
(RIDE), Houston, 1994
[Beer91] C. Beeri, T. Milo, A Model for Active Object
Oriented Database, Proc. of the 17th Int. Confer-
ence on VLDB, Barcelona, 1991
[Bußl94] C. Bußler, S. Jablonski, Implementing Agent
Coordination for Workflow Management Sys-
tems Using Active Database Systems, Proc. of
the IEEE Fourth Int. Workshop on Research
Issues in Data Engineering (RIDE), Houston,
1994
[Butt91] P. Butterworth, A. Otis, J. Stein, The GemStone
Object Database Management System, Commu-
nications of the ACM, Vol. 34, No. 10, pp. 64-
77, October 1991
[Daya88] U. Dayal, Active Database Management Sys-
tems, Proc. of the 3rd Int. Conference on Data
and Knowledge Bases, Jerusalem, 1988
[Daya90] U. Dayal, M. Hsu, R. Ladin, Organizing Long-
Running Activities with Triggers and Transac-
tions, Proc. of the 1990 ACM SIGMOD Int.
Conference on Management of Data , Atlantic
City, NJ, 1990
[DeAn81] V. De Antonellis V., B. Zonta, Modelling Events
in Data Base Applications Design, Proc. VLDB
1981.
[Desh93] S. Deshpande, Developing Distributed Object-
Oriented Applications Using the CORBA, The
Seventh European Conference on Object-Ori-
ented Programming (ECOOP‘93), Tutorial
Notes, Kaiserslautern, July 1993
[Enge94] G. Engels, G. Kappel, Object-Oriented Systems
Development: Will the New Approach Solve Old
Problems?, Proceedings of the IFIP94 World
Congress, Vol.III, K. Duncan and K. Krueger
(eds.), North-Holland, September 1994
[Gatz92] S. Gatziu, K.R. Dittrich, SAMOS: an Active
Object-Oriented Database System, IEEE Bulle-
tin of the Technical Commitee on Data
Enginieering, Vol. 15, No. 1-4, December 1992
[Garc94] H. Garcia-Molina, K. Salem, Services for a
Workflow Management System, IEEE Bulletin of
the Technical Committee on Data Engineering,
Vol. 17, No. 1, March, 1994
[Geor93] D. Georgakopoulos, et al., An Extended Transac-
tion Environment for Workflows in Distributed
Object Computing, IEEE Bulletin of the Techni-
cal Committee on Data Engineering, Vol. 16,
No. 2, June, 1993
[Hsu93] M. Hsu, R. Obermarck, R. Vuurboom, Integra-
tion and Interoperability of a Multimedia Work-
flow Model and Execution, IEEE Bulletin of the
Technical Committee on Data Engineering, Vol.
16, No. 2, June, 1993
[Jasp94] H. Jasper, Active Databases for Active Reposito-
ries, Proc. of the IEEE 10th Int. Conf. on Data
Engineering, Houston, 1994
[Kapp91] G. Kappel. Reorganizing Object Behavior by
Behavior Composition - Coping with Evolving
Requirements in Office Systems, Datenbanksys-
teme in Büro, Technik und Wissenschaft (BTW),
H.-J. Appelrath (ed.), Springer, 1991
[Kapp94a] G. Kappel, S. Rausch-Schott, W. Retschitzegger,
S. Vieweg, TriGS - Making a Passive Object-
Oriented Database System Active, Journal of
Object-Oriented Programming (JOOP), July-
August, 1994
[Kapp94b] G. Kappel, S. Rausch-Schott, W. Retschitzegger,
Beyond Coupling Modes - Implementing Active
Concepts on Top of a Commercial ooDBMS, Int.
Symposium on Object-Oriented Methodologies
and Systems (ISOOMS), Palermo, September
1994
[McCa93] D. R. McCarthy, S. K. Sarin, Workflow and
Transactions in InConcert, IEEE Bulletin of the
Technical Committee on Data Engineering, Vol.
16, No. 2, June, 1993
[Pete81] J. L. Peterson, Petri net theory and the modelling
of systems, Prentice Hall, 1981
[Rein93] B. Reinwald, Workflow Management in Distrib-
uted Systems, Teubner, Stuttgart-Leipzig, 1993
(in german)
[Sche94] A.-W. Scheer, Wirtschaftsinformatik - Referenz-
modelle für industrielle Geschäftsprozesse, 4.
Auflage, Springer, 1994 (in german)
[Shet93] A. Sheth, M. Rusinkiewicz, On Transactional
Workflows, IEEE Bulletin of the Technical Com-
mittee on Data Engineering, Vol. 16, No. 2,
June, 1993
[Yang89] J. Yang, A Proposal For Incorporating Rules In
ODA-Documents, Office Information Systems:
The Design Process, B. Pernici and A.A. Verrijn-
Stuart (eds.), North Holland, 1989