TriGS,, Active Object-Oriented Workflow ... - Semantic Scholar

Proceedingsof the 28th Annual Hawaii International Confkrenceon SystemSciences- 1995

TriGS,, Active Object-Oriented Workflow Management G. Kappel, B. Prdl, 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

(I) Object-oriented Paradigm: The object-oriented paradigm supports among others the modeling of structure and behavior of problem domain objects which may be reused for building different worktlow systems [Enge94]. Problem domain objects represent real world objects and concepts of a problem domain, such as student and scholarship of a scholarship application system. Besides the issue of reusability the object-oriented paradigm provides an open environment necessary to adapt to changing requirements of the application domain [Kappgl].

We present the multi-paradigm architecture TriGSflO, for a workflow management system. TriGS’, is based on an active extension of the commercial object-oriented database system GemStoneTM. TriGSp,,,, takesfill advantage of the capabilities of the underlying database system such as reliability, recovery, transaction management, ana’ authorization. At the current stage of implementation the novel features of TriGSpow are the seamless integration of ECA rules into an object-oriented model, theflexibility of worwow specification due to rule modeling, and the integration of external applications as part of workflow processing.

(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 conditions evaluate to true [Beer91]. This system behavior is especially useful in the area of complex business processes in order to express an event-driven and constraintdriven system environment [Yang89]. By incorporating rules the flexibility of a WFh4S 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.

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-lasting business processes that typically involve multiple activities and multiple collaborating persons in a distributed environement. WFMSs originate from the office automation efforts in the late 1970s and early 198Os, and from the imaging-based systems in the 198Os, both of which aimed at automating office paper processing [Hsu93]. Today, WFMSs are becoming increasingly visible as a means for improving the productivity and competitive 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 WFh4S consisting of the following basic concepts:

(3) Transaction Paradigm: Business processes need correctness, reliability, and failure criteria to be enforced similar to transaction systems. They consist of interrelated activities with data flow constraints and control flow constraints, again similar to transaction systems. However, due to their long-lasting asynchronous nature business processes require extended transaction models incorporating long transactions and multi-level transactions [Geor93, Shet93]. Concerning the latter, multi-level transactions are necessary since there are at least three levels of dependencies which have to be distinguished in a full-fledged WFMS. These three levels are:

TM GemStone is a registered trademark of Scrvio Corporation

1060-3425/95$4.00@1995IEEE

127

Proceedings of the 28th Hawaii International Conference on System Sciences (HICSS'95) 1060-3425/95 $10.00 © 1995 IEEE

Proceedingsof the 28th Annual Hawaii International Conferenceon SystemSciences- 19% Intra-Activity: A workflow consists of a series of activities, each activity being a transaction. Some activity may need cooperative multi-user interaction, thus, traditional transaction models have to be extended to support these needs.

base system Gemstone [Kapp94a, Buttgl]. 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.

Inter-Activity Zntra- 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 feasible approach will be to start with the nested transaction model and extend the correctness model on the basis of the above mentioned dependencies.

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 illustrated in Figure 1. The class hierarchy represents the inheritance (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.

Inter-Workflow: Similar to the previous point there exist several dependencies between workflows of the same or of different kinds within a multiworkflow management system. These dependencies have to be addressed within an advanced transaction model for workflow systems, too. In addition to the above mentioned transaction requirements execution correctness requirements such as failure atomicity and execution atomicity also have to be addressed. [DayagO, Garc94, McCa931.

2.1 Agents and activities

(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 distributed information sources have to comply with a common protocol OMGs CORBA protocol [Desh93] will become very important.

A workfow type represents a certain kind of business process, e.g., an application for scholarship (cf. class BusinessProcess and its instance WF-Type in Figure 1). It is defined by a number of various activities (Activity) representing subtasks of the business process. An Agent (Agent) is able to perform different activities, 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 synchronization policy [BuB194], e.g., agents on holidays are not allowed to be selected. For sake of simplicity the discussion 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 communicating 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 enterprise. 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 executed either without any computer support, or it may be executed by an application, e.g, a text processing system,

(5) Integration Paradigm: Business processes have to integrate external isolated applications with new applications 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 applications. 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 workflow model incorporating object-oriented, active and integration concepts. The model is based on existing work in this area [Rein93, B&194, Jasp94] yet incorporates extensions based on the object-oriented paradigm and the flexible 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 extension of the commercially available object-oriented data728


Proceedingsof the 28th Annual Hawaii International Conferenceon SystemSciences- 1995 Petri nets [Pete811 in the sense that inclusive OR forking and inclusive OR joining are also explicitly supported in TriGSJo,

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 perform their activities without user interaction. Consequently, 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.

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-Alternative (cf. Figure 2a), i.e,. a subset of the specified successors is chosen. If two or more parallel branches have the same successor activity a joining activity has to be supplied. 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 activities 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-

Agents cooperate with each other in order to realize the business process. This cooperation is achieved by specifying both a certain control Jrow between activities on the basis of an activity net (cf. Section 2.2), and a workjlow 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, Sche94J. The semantics of these control structures extend those of BusinessProcess

4 I

AgentSpec Order 1 -folder

-pgent

A

-

AutoAgent v

A

ExternalApp (-1

Legend:

+

Inte&alAppClass

J

HumanAgent j-&E-y

I-data

~r;~ist,~l*activity

InternalAppObject 1 *objectID

1

---t)

. .. has-component (single-valued) . . . has-components (multi-valued)

---+

. . . instance-of

A

. . . is-a

E

object class ::: instance of an object class

Figure 1. Class hierarchy and class composition hierarchy of TriGSp,, 729


1

Proceedingsof the 28th Annual Hawaii International Conferenceon SystemSciences- 1995 sion of folders see section 2.3) which are still residing in one or several of the parallel branches but will not be used any more for further processing.

(cf. instance variable StartActivity in Figure 1) - a new folder is created. The flow of this folder from one agent‘s worklist to another‘s which is controlled by the activity net is called a workflow and represents the execution of a certain workflow type. In case of alternative branching, the decision which activities to actually perform is made on the basis of folder contents and further 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 reference to the folder is transferred to each responsible agent. Concurrent folder access of concurrently working agents is handled by the transaction mechanism of the underlying object-oriented database system. Note, that duplicating folders for concurrent access might also be useful in some cases. However, duplication of folders involves version management which will not be treated in this paper.

(1) Sequence:

activity

(ta) inOR-Alternative:

activity 3

(2b) Concurrency:

activity 3

(2c) exOR-Alternative:

activity 3

1

activitj

2

(3a) inOR- Join:

4

activity 6

activity 5

(3b) AND-Join:

2.4 Integration

aspects

TriGSJc,w allows to integrate both internal applications implemented within the same object-oriented environment 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 “f axApp < fax-no> “