Reusability and modularity in transactional workflows

lflformar;on Sy.wm Vol. 22.No. 2/3.pp. 101-120, 1997 ^; 1997Elsevier Science Ltd. All rights reserved

Pergamon

Printed in Great Britain 0306-4379/97$17.00+ 0.00

PII: s0306-4379(97)OuOo7-0

REUSABILITY AND MODULARITY JUHA PUUSTJ;~RVI~,

IN TRANSACTIONAL

WORKFLOWS

and JARI VEIJALAINEN~

HENRY TIRRI’

‘Department of Computer Science, P. 0. Box 26 (Teollisuuskatu 23), FIN-00014 University of Helsinki, Finland “Department of Computer Science and Information Systems, University of Jyvkkyl& P.O. Box 35, FIN-40351 Jyvbkyll (Received

, Finland

14 October 1996; in final revised form 4 April 1997)

Abstract Workflow management techniques have become an intensive area of research in information systems. In large scale workflow systems modularity and reusability of existing task structures with context dependent (parameterized) task execution are essential components of a successful application. In this paper we study the issues related to management of modular transactional workflows, i.e., workflows that reuse component tasks and thus avoid redundancy in design. The notion of parameterized transactional properties of workflow tasks is introduced and analyzed, and the underlying architectural issues are discussed. 8 1997 Elsevier Science Ltd Key words: Transactional

Workflows, Reusability,

Modularity,

ECA Rules

1. INTRODUCTION

The development of workflow management systems has become one of the most exciting areas of research in information systems. The underlying concepts have been around in various forms for a long time, however, only recently the know how to implement commercial systems has been available. Modern business applications are usually composed of independently designed components can be seen as which are accessed concurrently by a large set of users. Workflow management central techniques to coordinate and streamline business processes, which themselves are represented as worlcfEows. On the other hand current organizational investments into data processing equipment and software are significant, and there is a growing interest to benefit as long as possible systems are used from the existing “legacy systems”. In addition very large workflow management in organizations where the number of users may be in the tens of thousands at thousands of sites, and process instances in the hundreds of thousands, all distributed over wide geographical areas [2, 25, I]. In these systems modularity of design, reusability of existing task structures and context dependent (parameterized) task execution are essential components of a successful application. It is within this framework of efficient business process re-engineering that our research is inscribed. Mohan et elJ31] listed several key aspects in large scale workflow management design: failure handling, availability, navigational flexibility, replication and distributed coordination. Such aspects are clearly in the realm of transactional workflows where the application execution has to conform to a set of correctness constraints derived from the application domain. Since workflow management systems have become the top layer in the corporate information system architecture, we would like to add to this list of issues modularity and task reusability and focus here on mechanisms achieving these goals. Workflow task reusability is an essential feature of real life workflow systems, and should be Reusability allows one to avoid taken into account also in the development of such systems. redundant design, which is an important aspect as large workflow applications are typically defined by combining existing applications. Consequently management of shared workflows, i.e., workflows that share one or more tasks, is an important topic to be addressed in transactional workflows. The advantages of modeling transactions as extended transactions ensures correctness and executions of workflows). In practice, however, reliability of workflow instances (i.e., individual transactional workflows can cause a considerable decrease in the system performance due to holding of data. This problem is particularly apparent for long lasting workflows, which tend to be the

101

102

JUHA PUUSTJ~RVIet al.

This is due to the fact that many workflow most common ones in many application domains. procedures involve human decision making, sometimes even committee decisions, and thus operate on a different time-scale than traditional transactions, e.g., airline reservation processing or bank account update applications. Following the argumentation presented in [3] we adopt the viewpoint that workflow systems address a wider range of requirements than the currently proposed advanced transaction models. In this paper we will study the design of transactional workflows and workflow management systems that support modular, shared workflows. In order to achieve these goals we introduce task execution modes and the notion of task integration, i.e., we rely on context-dependent, parameterized transactional properties of the workflow tasks. By using different execution modes it is possible to combine tasks located at different sites to compose appropriate transactional units. Using our approach, the tasks can also be run in different modes according to the user category who started the workflow instance (cf. [3] point 3.3). In addition, by task integration we can bind together tasks executed at the same site to comprise In this way we incorporate workflow notions similar appropriate units of atomicity or isolation. and workflow system throughput. As far to multilevel atomicity [30], and increase task reusability as we are aware of, this notion of parameterized transactional properties to increase reusability of tasks has not been addressed before. The mechanisms to implement workflow specific isolation constraints are based on Event/Condition/Action rules (ECA rules) [9, 261 which are defined on In [26] the ECA rules are used to describe the global workflow schema (i.e., task parameters). the control flow (i.e., execution structure) between the object instances in diverse object classes forming the workflow application. Our use of ECA rules is different, they are used to specify which synchronization operations are needed between workflow instances. Such rules are given as part of the workflow specification, and used by the global level workflow manager modules during the execution phase. The remainder of this paper is organized as follows. In Section 2 we first discuss the related work in the literature for advanced transaction models. In Section 3 we will introduce the components of workflow specification, and describe the underlying architectural assumptions. Section 4 demonstrates our concepts through an illustrative example by considering five workflows in a banking domain. These workflows are used throughout the paper as an example to demonstrate our approach. Section 5 discusses the management of concurrent execution of interfering workflow tasks with ECA rules. The use of parameterized transactional properties for task execution modes and task integration issues are introduced in Section 6. Finally, the concluding remarks are given in Section 7.

2. RELATED

WORK

Workflow management research is clearly related to the work performed for developing advanced transaction models. Cooperative transaction models have been discussed in [23, 24, 36, 34, 20, 331 in the centralized case, and in order to better match the requirements of various modern database applications, more general transaction frameworks are developed in [13, 32, 501. These advanced transactions differ from traditional (flat) transactions in structuring the transaction as a set of subtransactions, thus forming a transaction tree. Tree structured transactions exhibit two important properties. First, they allow designers to specify appropriate execution structures: subtransactions can be executed in parallel or in a predefined order. Second, tree structure allows finer specification of isolation and atomicity: the unit of atomicity as well as the unit of isolation may concern the whole transaction or only it’s subtransactions. The advanced transaction models can be classified for example according to isolation requirements, failure atomicity and execution dependencies. In an ideal case, the more relaxed isolation requirement the model provides, the more concurrency is achieved. Similarly the finer failure atomicity the model provides, the more expressive the “language” of the model is. Nested transactions introduced by Moss [32] provide full isolation and atomicity with respect to the whole transaction, but internally they provide finer control over failures. For the recovery of subtransaction failures the model provides four alternatives: one can attempt the re-execution

Reusability and Modularity in Transactional Workflows

103

of the failed subtransaction, the whole transaction can be aborted, the failure can he ignored, or another subtransaction may be initiated, i.e., the subtransaction is considered as a contingency subtransaction. The so-called Open nested transactions [50, 481 relax this isolation of the subtransactions. Ideally, an uncommitted open nested transaction allows other transactions to access the results of its committed subtransaction if the access do not exclude the possibility to abort the nested transaction. This is the case if the committed subtransaction and the subtransaction accessing the data are commutative, i.e., the final state of the database is independent of their execution order. Multilevel transactions [47, 491 relax the isolation requirement even further by not requiring commutativity. Its subtransactions can commit and release their resources before the whole transaction commits. If the whole transaction (root) aborts, the (semantic) atomicity is ensured by executing compensating transactions which semantically nullifies the effect of committed subtransactions. In addition to the nested models described above, both Sagas [16] and flexible transactions [8, 13, 28, 401 relax strict atomicity by introducing compensating transactions. The flex transaction model also incorporates the notion of contingency transactions. In addition the designer can specify the acceptable termination states for flex transactions. With Sagas the application programmer defines a linear execution sequence of the subtransactions consisting of traditional flat transactions, and if the execution of a subtransaction fails then the executed subtransactions are compensated in the inverse order. Nested sagas (151, descriptive to their labeling, allow nesting structures within a Saga. By modeling a workflow as an advanced transaction the isolation and atomicity properties can be attached to workflows. Without such properties the execution of workflows may result in anomalies including lost update, dirty read and inconsistent retrieval. This has been the starting point of the proposals of many advanced transaction models for modeling workflows, e.g., the nested approaches discussed above [7, 11, lo]. Basically, modeling a workflow as an extended transaction means that the subtransactions correspond to workflow tasks and the execution structure of the extended transaction corresponds the control flow of the workflow. Due to the limited control flow specification capabilities, advanced transactions are in many cases augmented with control flow specification features (see e.g., the approach presented in [7]). Most known transactional dependencies can be presented by a small set of dependencies concerning the abortion and commitment of transactions [27]. However, a fundamental problem in modeling workflows as advanced transactions is the fact that the approach is rather restrictive, since transactional models provides a predefined set of properties which are not necessary for all workflow applications [3]. The ASSET system [6] provides transaction primitives for the specification of advanced transaction models. This flexibility is also one motivation for introducing a framework called DOM systems that allows “tailoring” of appropriate advanced transaction models for workflows [7, 181. This approach is further developed in [17]. In DOM systems the idea is to support definition of advanced transaction models and the corresponding transaction management mechanisms, as well as specification of individual transactions complying with the advanced transaction models in question. The runtime support of a particular model is generated by directing suitable configuration instructions to a programmable transaction management mechanism, which then generates the runtime environment corresponding to the transaction model. The specification of an advanced transaction model defines the intra-transaction and inter-transaction dependencies to which all instances have to conform. Comparing the DOM approach to our approach, we can see that the approaches are similar in the sense that both use ECA rules. The difference is that in [17] the ECA rules are used to enforce intra-transaction dependencies, whereas in our approach inter-transaction dependencies. Our approach is more dynamic as the transactional properties of a task can be dynamically chosen during run-time. On the other hand, the approach in [17] is broader in the sense that the set of specifiable inter-transaction dependencies, including variety of serializability versions, is broader. In addition, the scheduler can be tailored to use different kind of policies while enforcing the dependencies. The term transactional worl@ow is used to emphasize the relevance of transactional properties

104

JUHA PUUSTJ~~VI et al.

for workflows. Generally, a transaction workflow involves the coordinated execution of tasks which may require the access of heterogeneous and autonomous database systems. The coordination requirements are expressed by control flow dependencies, which specify a precondition for the execution of each task. Due to the expressional power of control flow dependencies, the semantics of workflow models are richer than the advanced transaction models. Hence workflow systems can be used to implement advanced transactions. For example, the workflow model FlowMark [31] has been used in implementing Sagas and Flexible Transactions. Workflow models are not, however, general frameworks to program advanced transaction models, as they have to be complemented by many aspects (e.g., interaction with manual activities) which make them more suitable for building applications. In this paper our focus is in transactional workflows rather than developing advanced transaction models suitable for workflows. Our main contribution here is the task reusability in transactional workflows. To our knowledge, this has not been addressed earlier in the particular setting discussed heret. The Contract model [45, 461 provides task reusability and allows to combine task to comprise ACID-properties, but does not allow to separate the units of atomic&y and isolation. In addition the Contract model allows to specify workflow specific isolation constraints by invariant predicates. Our proposed ECA rule mechanism behaves equally as the invariant predicts, but our approach is restricted to predefined rules in order to ease their implementation. Task reusability in the workflow community is being intensively developed by the Workflow Management Coalition [29], which is a non-profit, international organization of workflow vendors, users and analysts founded in 1993. Its mission is to promote the use of workflow through the establishment of standards for software terminology, interoperability and connectivity between workflow products, and the coalition has specified a reference architecture for workflow technology. Two of the five specified standard interfaces are of special relevance here, namely interface 1 and interface 4. Interface 1 (Workflow Definition Interchange) is aimed at supporting the exchange of process definitions, between process definition tools and run-time environment. Interface 4 (Interoperability) deals with interoperability of two or more different workflow engines while they coordinate and execute workflow instances across those engines. Both interfaces make use of standard process definition facilities. The process definition standard is based on a meta-model which contains the necessary concepts to describe the process definitions and standard (linear) representations for the concepts. Thus, the process definitions expressed with this standard formalism are reusable and modular. Unfortunately, the current version of the process definition standard does not directly support transactional workflows, but the necessary constructs could rather easily be incorporated into the process definition standard. 3. ARCHITECTURAL 3.1.

Workjlow

Specification

ISSUES

FOR MODULAR

AND REUSABLE

and Task Variations

Full specification of a workflow (scenario) is a complex task. specification components that are needed for our purposes: l

The tasks Z’i involved

l

The transactional

l

The data flow between

l

The execution

in a particular

requirements

structure

WORKFLOWS

Here we list only those workflow

workflow.

of the workflow.

the workflow tasks. of the workflow.

In this paper we focus on the first, two aspects since they are directly related to task reusability in the sense discussed above. Data flow between tasks is determined by specifying the data connectors between input and output containers of different, tasks. Following the approach in [3] these containers contain the typed variables and data structures in which the input and output data of the task instances are tFor some related discussions

see the preliminary

work in [38, 391.

Reusability

WORKFLOWLEVEL

FJ

and Modularity

in Transactional

Workflows

105

jl

COMPONENT LEVEL

Fig. 1: Component

Structure

of Workflow Specifications

stored. In the simplest case such a container is specified by a list of typed parameters of a task. During run-time the data flow corresponding to a data connector is in this case realized by passing the parameter list from one task to another. From reusability point of view the input and output container specifications of the tasks can be modified as long as data connectors between them can be realized. For legacy systems this requires often filters to be specified which transform the data in an output container of one task to a format required by the input container of the other task. In this paper, we assume that the data flow can be realized in spite of the task variations (see discussion below). The specifics of these data flow problems caused by reusability are outside the scope of this paper. The execution structure of a workflow specifies the ordering constraints for the executions of the tasks, e.g., a task may not begin before a particular previously started task commits. Such constraints can be specified e.g., by triggers [ll, lo] of which the ECA rules are a special case, by Petri nets [21] or by finite state automaton [4]. In the following, we will make no assumptions of the method the execution structure is specified with. For a detailed discussion on inter-task dependency enforcement in workflow context see [41]. In our terminology a task defines some unit of work to be done, which can also be shared by several different workflow specifications (it should be noticed that the workflows sharing a task specification do not share the corresponding instances during run-time, but rather each workflow instance has a task instance of its own for the shared task specification). A single task may be specified in various ways. Abstractly, a task specification consists of an interface specification and an algorithm. The former consists of the type specification of the input and output container variables and of the control information, like pre- and post-conditions (cf. FlowMark [3]), transactional parameters, user parameters, etc. The algorithm transforms the input data in the input container to output data in the output container, guided by the control information. In practice, this transformation of data can be implemented in different ways. In our environment it is important to include the local databases into the data flows as persistent storage of the (sub)flows. At the highest specification level this means that persistent input and output variables have to be declared and the database where they are stored has to be specified, together with the access method for the data in those variables. How the access happens and how it must be described depends largely on what kind of access the local database offers to the global level workflow system (see the discussion in Section 3.3). We model here mainly the aspects which are relevant from task’s reusability point of view. In order to maximize task reusability a task is allowed to have several task variations. Task reusability and task variations can be illustrated by the component structure given in Figure 1. The component structure consists of the two levels: workjlow specification level and component specification level. The shared task specifications (boxes) in the component set represent the variations of tasks. The tasks of a workflow specification comprise a subset of the overall component set. In our approach we make the distinction between a basic tasks can be used by the workflow designer to integrate tasks transactional units (e.g., for atomicity or isolation). This issue Section 6.1. A task variation is a modification of a task which

task and task variations. Basic in order to compose appropriate will be discussed more detail in matches better the requirements

106

JUHA PUUSTJ~RVI et al.

of a particular

workflow. Task variation can be seen as a logical concept in the sense that the variation is specified as a parameter in the task call itself. In principle a task variation can be understood as workflow’s view of the basic task. In the sense of the above abstract specification the task variations of the same task have the same (or at least “compatible enough”, see above) interface specification, but they behave differently depending on the control information. Thus, the algorithm above behaves differently with different parameter values. A typical example of such a behavior is a task which can have different access rights towards the local database system depending on the user who invoked it as part of a workflow. In addition task variations can also be used to compose appropriate units of atomicity or isolation. As an example consider a case where two tasks located at different sites will be integrated to compose a unit of atomicity. In such situation one uses task variations that provide the prepared state as an external state. We will return to these execution mode issues in Section 6.2. 3.2. Architectural

Considerations

Our architectural views for the workflow environment are influenced by the general reference architecture under development in the l?ansCoop project [12]. The ‘DansCoop architecture is intended to provide a platform for transaction management support for cooperative applications in general, not only for workflow applications. The architecture consists of both a specification environment (TSE) and a run-time environment (TRE) which both use the services of an object server (TOS). Since we are concerned with a particular application domain, workflow management, the architecture presented is more specific than the original generic architecture. The overall modified architecture is illustrated in Figure 2. We assume that the workflow environment consists of a global and a local level. The global level supports the shared workflows whereas the local level supports existing legacy applications and databases. Here we focus on the global level workflows only, and discuss briefly those architectural issues that are related to the topic of the paper, specification and execution of concurrent shared workflows. For more detailed discussion on the architectural issues related to cooperative applications see [12]. A workflow designer specifies system supported workflows as well as the consistency constraints of the system. The Workjlow Specification Environment (WSE) analyzes the specifications to determine whether such a workflow can be implemented based on existing task specifications and the global/local interface properties. For example, if the specification includes a reusable task but such a task is not found from the Workj-Zow specification dictionary stored in the TOS object server, then the mismatch is reported to the workflow designer. Also the parameter values for the transactional properties are checked against the local/global interface specification. Such mismatches can be illustrated by the following example. Let us assume that a task could be run in a 2-phase mode in a workflow, and that the task updates the local database which offers only a l-phase interface upwards (see Section 3.3), this requires from the global level components (CM, TTMMS) that they are able to restore the local subtransaction in case the local DBS aborts the original one(s). If this is impossible for the global level then a mismatch is reported. If there are no mismatches the specification is stored in the Workjlow Specification Dictionary. In addition to the individual workflow specifications a workflow designer can specify consistency constraints of the system. To enforce such a constraint WSE compiles the necessary set of Event/Condition/Action (ECA) rules which are stored in the ECA rule base in the object server. In a distributed case the ECA rules (and the possible related locking data structures) are stored at the sites where the tasks in question are executed. For specifying the tasks, designer gives the data container specifications and identifies the persistent data parts. These are compared with the characteristics of the global/local interface and it is determined, whether the necessary accesses are viable. If this is not the case, either the global/local interface or the persistent data descriptions in the containers need to be changed. When the task specification is compatible with the global/local interface one can check the ECA rule base, and look for rules that relate this task to the other tasks. For each rule type a suitable event hook is generated into the code of the task that signals the rule manager within Cooperation

Reusability

and Modularity

in Transactional

Workflows

107

Tr;mXOOp

nt

Runtime Environment (TRE) Wtnrktlow Specification

Cwpratwn

Manager (CM)

Envtronment (WSE)

Support System (lTMSS) 1

Fig. 2: Workflow System Architecture

Manager to perform a rule evaluation. All the rule specification information is processed and the executable code of the task is generated by a compiler (possibly semiautomatically). This code contains access commands towards the local DBS, necessary event hooks and other parts needed in order to perform the data manipulation in the containers. The code, along the interface is stored into TOS. The User Agent (UA) module provides the interface between the users and the system. A user may be a human, an application program or a remote workflow or task request. When it receives a workflow call, it generates an instance of a workjlow specification based on the Workflow Specification Dictionary. Then it sends non-local task requests to the UA’s of the appropriate sites via the Remote Execution Agent (REA). Local workflow specifications are passed to the Cooperation Manager (CM), which is responsible that the execution is compatible with its specification. CM uses the services of the TransCoop fiansaction Management Support System (TTMSS). It can enforce correct sequencing of the tasks. To ensure correct interleaving of concurrent workflows and that predefined constraints are not violated, the Cooperation Manager uses the ECA-rule base generated in the specification phase. If CM will not delay the operation or a task the necessary operations will be performed by the TTMSS. The application calls ACi(pl, . ..pn) : retl, .., ret, themselves can be used to deduce event hooks for the workflow synchronization and other purposes, if an application interface is supported by the local/global interface. In this case, the event-part in the corresponding ECA rule contains the application call type [ACJ or its return value [ACi : ret]. Whenever the clause ACi(pl, . ..p.) : retl, .., retn[ACi] is then executed, the rules with ACi in the event part are fired. If the data manipulation operations towards the local DBS are static, and can be generated during compile time, then the event hooks are also generated during compile time. For each event hook one checks, which variables X,Y,. . . the DML command updates and looks up in the dictionary, whether some of the variables X,Y,. . . are controlled ones. If this is the case then a corresponding The resulting clause within the task event hooks [opX][opY]. . . are attached to the command. code is then of form DML-operation[opX][opY]. . ,which, if executed fires the rules with events [opX] [opY] . . . . The situation is more complex if the workflow system supports dynamic DML-level interface. In this case the DML commands are not known at compile-time, and a general DML event hook IS

mm-c

JIJHAPIJUSTJ;~RVI et al.

108

[gdmleh] must be connected to it. Whenever such a command which contains a dynamically created DML command (e.g., an SQL command such as UPDATE X SET X=X+W WHERE X= 50)occurs, the rule with event part [gdmleh] fires and checks the command. During the check the system determines, whether the command accesses such persistent local variables which have restrictions imposed on their behavior. If this is not the case, the command is passed to the global/local interface for execution. If X is a controlled variable (in the example case a column name) then the event hook [gdmleh] is replaced by [updatex] and the update command is feeded into the system. Rules with updateX event now fire.

3.3.

Properties of the Global/Local Interface

In this paper we are mainly interested in the global level issues. The environment, however, is assumed to contain local DBS which host the persistent data. Therefore, the properties of the local DBS are of importance to the global level. We list below the properties which are reflected into the specification of the tasks, as well as their transactional properties. We can differentiate between 1. b-phase DML -level interface, which means that local DBS offers to the workflow system all DML commands, including commit, abort and prepare commands. Using these the task performed at the global level can freely compose the DML commands belonging to a local subtransaction and determine dynamically the transaction border of the local subtransaction. With the DML commands it can manipulate the local database within the limits determined by the access rights. 2. l-phase DML -level interface, which is defined as above, with the exception that the prepare command is not offered upwards. In this case the global level task can compose the DML commands freely into a local subtransaction, and it can always abort the local subtransaction. However, the local DBS does not necessarily commit the local subtransaction at request and it can also abort the local subtransaction at any time. 3. explicit l(2)-phase application interface. In this case the local DBS offers to the global level workflow tasks a set of application interfaces of the local applications in the global format. In this case the data types usable in the container variables are those offered at global/local interface (called OSIM interface in Figure 2). Abort and commit commands are offered in the l-phase case,and additionally a prepare command in the 2-phase case. Here the global task cannot compose freely the DML commands belonging to the local subtransaction, but it can freely compose the local subtransaction of one or several local existing applications executions. Otherwise for DML commands the case is analogous to the l-phase and 2-phase cases. 4. implicit l-phase application interface. In this case the local DBS does not offer prepare, commit or abort operations upwards, but only interfaces of the local application in the global format. Thus the global level task can only access the persistent data by invoking appropriate applications running at the local DBS. The data types usable in the container variables are as above in the explicit case. Local DBS decides independently, whether to commit or abort a local application invocation. The local subtransaction border is determined by the application. As opposed to the case above, for this alternative global level task cannot combine several applications to form one local subtransaction. There are several alternatives for the relationship between a task instance and the local subtransactions executing it. This mapping can be be one-to-many, one-to-one or many-to-one. In the first case, the task initiates more than one local subtransaction within the local DBS. In such a case the atomicity of the task might be jeopardized, if the global/local interface is not 2-phase. There might also be local direct or indirect Read/Write-conflicts between the different local subtransactions, which cause task-internal cycles to appear.

Reusability

and Modularity

in %msactional

Workflows

109

I

I I

CLIENT CREDIBILITY

I

I

~p-&&$$q contacts

.

I

I

Fig. 3: Execution

Precedence

Graph for the Workflow Client

Credibility

The one-to-one case is the simplest one. In this case there is one local subtransaction at the local site, and the transaction border is correspondingly simple. In the 1 or 2-phase case the task sets it, in the implicit case the local application or the local DBS sets it. The final case where several tasks have one common local subtransaction is the one that is the most difficult to manage. This case is only possible for l- or 2-phase interfaces, because one cannot think of several tasks invoking the same application. The global workflow manager level must decide, when to issue the prepare (commit/abort) command to the global/local interface in order to move the common local subtransaction to the prepared (committed/aborted) state. Depending on the characteristics above, a task can have atomicity problems or global Read/Writeserializability problems. The characteristics also influence the way tasks can be integrated into larger units in order to achieve isolation or atomicity.

4. AN EXAMPLE

OF A SET OF SHARED

WORKFLOWS

As an illustrative example we will consider the following five workflows in a banking environment: Client Credibility, Credit Account Request, Credit Card Request, Loan Request and Bill request. In the figures describing these workflows we have denoted subworkflows (i.e., the tasks which may also be executed as an independent workflow) by double outlines, and shared tasks by rounded rectangles (i.e., tasks that can be included as components in more than one workflow). The workflow Client Credibility can be executed as an independent workflow or as a subworkflow in other workflows. Its modular task structure and task execution ordering constraints are presented in Figure 3. The task Enter client information accepts the information of the client. Based on this information the task Client’s data access retrieves from the bank’s database the relevant client information. This information includes the amount of the loan the client has in the bank, the names of the subsidiaries and the holding companies where the client has liabilities. If such liabilities exist the subsidiaries or holding companies are contacted to get their assessment of the client. These are performed by the tasks Subsidiaries contacts and Holding companies’ contacts. The task Client’s credit evaluation decides the credibility of the client. The workflows Credit account request in Figure 4 and Credit card request in Figure 5 have the subworkflow Client Credibility as a second task, and share the last task Client data update which updates client’s data by the given limit if the request has been accepted. In practice, however, these workflows are quite different in nature as the task Enter credit account decision is processed by the bank while the task Enter credit card decision is processed by the credit company. Hence, the former is typically a short duration activity, while the latter tends to become a long lasting workflow. The workflow Loan request processing is presented in Figure 6. The first task Enter loan request accepts the amount and the information of the client. Based on the client information the subworkflow Client Credibility is processed which gives input for the task Risk evaluation. The risk evaluation task computes the interest for the loan request based on the amount of the loan and client credibility. The task Enter loan decision makes the decision to either grant or refuse the loan request. Before the loan can be granted the task Bank’s liability update checks that the

JUHA PUUSTJA;RVIet al.

110

CREDIT ACCOUNT

REQUEST I Enter credit account decision l-

Fig. 4: Execution

Fig. 5: Execution

Precedence

Precedence

Graph for the Workflow Credit Account

Request

Graph for the Workflow Credit Card Request

bank does not exceed its liability limit, and if the limit will not be exceeded, bank’s total liability will be increased by the amount of the loan. If the loan is granted the task Client’s data update adds the information of the granted loan to client’s data, and if the loan request is refused the task Bank’s liability decrement compensates the increment of bank’s total liability. A bill is a special type of loan which differs from other loans in that the capital involved is usually smaller, and no pledges are used. The task Bank’s liability update is shared by both the workflow Bill request (Figure 7) and the workflow Loan request. In these workflows, however, the task has different execution requirements: in the former it is executed as a traditional ACID transaction and in the latter as a semantically atomic transaction, i.e., it can be compensated by the task Bank’s liability decrement if necessary. The simplified example above was chosen only for illustrative purposes as the application examples studied in [42] are too complex to be analyzed within the present space limitations . In our analysis of real workflow processes, one example being Telecom Finland, we have encountered many examples of shared workflows. From these studies it is evident that there are tasks which can be used as part of different workflows. For example the customer credibility check can be used in several different service workflows, whenever a new customer is added into the set of serviced customers (a new mobile unit, a new “101-service” etc.). In principle the same task can be used, but the credibility requirements might differ due to the differences in tariffs. The same holds for the customer billing base creation. In such a case different type of tasks or task variation is needed, because mobile customer records and practices differ from those of a 101 customer. Otherwise, the LOAN REQUEST

-

Enter loan request

Fig. 6: Execution

Precedence

Graph for the Workflow Loan Request

Processing

Reusability

BILL

Fig. 7: Execution

and Modularity

in Transactional

Workflows

111

REQUEST

Precedence

Graph for the Workflow Bill Request Processing

overall process specifications of customer insertion into these service processes are different and non-shared (in fact they are handled by separate units). The reusability of the tasks is naturally closely linked to their definition. It is evident that the processes supported by workflows are changing. Consequently the tasks and their signatures change according to the changing functions of the organization. Methodically, whenever a new workflow specification is being developed, the existing tasks are checked and compared against the emerging needs, and the new workflow is based on a modification of existing ones, assuming that close enough match can be found. This way the best fitting set of tasks for the organizational needs will be adopted. 5. MANAGING SHARED CONCURRENT 5.1. Event/Condition/Action

WORKFLOWS

Rules and Markers

When several related workflows are executed concurrently, the interference of their tasks has to be controlled. The problem is naturally related to traditional transaction concurrency control [5]. However, workflow application domains have several features that make straightforward transaction approaches very hard to apply. First, the workflows are prime examples of long lasting activities which cannot be handled using traditional concurrency control methods without heavy penalties to the overall system performance. For example, if straightforward locking is used for concurrency control, the task Client credibility would lock client’s data until the end of the workflow. Such a lock would then hold for many days preventing client’s data to be updated, which clearly is not an acceptable alternative. Second, the global level is not always capable of dictating the local subtransaction borders (cf. the classification of global/local interfaces in Section 3, case implicit l-phase application interface) in such a way that global RW-serializability could be guaranteed. This leads to RW-serializability class locally serializable schedules (LSR). The s-transaction model [44] and the Sagas [IS], are in this class, where the local subtransactions (including the compensation transactions) are run in a locally RW-serializable manner together with other subtransactions and local transactions, without global level restrictions on the order of the subtransactions (for more discussion on the topic see [43]). Notice that for s-transactions even atomicity, i.e. that a transaction is run into a successful or non-successful completion, cannot be guaranteed due to extreme local execution autonomy of sites. It is generally known that relaxing overall RW-serializability can cause diverse problems with respect to the database state and the view the transactions get from the database. Our examples in the preceding section have illustrated that workflow applications also suffer from these problems. We therefore have to influence the local serializability order of local subtransactions in order to prevent such phenomena to occur. Thus, we try to find a semantically feasible subclass of the LSR schedules. In principle, we do this based on the semantical pre-analysis of the workflows and their undesirable concurrent exchange/modification of persistent data (we assume that different workflow instances only exchange data through persistent data stored at a local DBS and that this exchange happens through local subtransactions). We use EGA rules [22, 261 and markers as mechanisms to control the interference caused by several tasks (from different workflows) executing concurrently. ECA rules with the related marker conditions are defined at the global schema level, since in the general case i.e,. in context of the

112

JUHA PUUSTJ~VI

et al.

application interfaces of Section 3, it is not possible to control even the data modification at the could be underlying “legacy system level”. Second problem is that even if the data modifications controlled, in case the DML-interfaces in Section 3 are offered upwards, the RW-serializability order of local subtransactions executing on behalf of the tasks cannot be still controlled from the global level in general case (if the local DBS only allows rigorous RW-schedules, then this is possible, though). Our idea is to use ECA rules to capture the problematic situations. They are defined based on the semantical pre-analysis. As was discussed in Section 3, the semantical pre-analysis is recorded in event hooks in task codes and in the corresponding ECA rule base. During run-time, a rule instance is activated, if a command with a compatible event hook is executed in the task code. The rule examines the situation and decides whether the task should be suspended. By suspending the task the execution order of application calls/DML commands and the resulting RW-serializability order within the local system is influenced. The execution of the task is resumed (see RESUME) when another task performs an application call/DML command which indicates that the other task can continue without danger that the undesirable interaction between workflows would happen. This is controlled by another rule. Assuming that the task codes are not parallel, i.e. each call towards the global/local interface is synchronous, the suspending a task task can be performed by simply placing the application/DML command invoked into a queue, along the information to what marker oid the command is attached. Resuming it can be done by taking the command from the queue, based on the marker oid and restarting its execution from the beginning. Time-outs of the tasks can be also controlled by this mechanism. In this case the time-out rule fires, examines the condition and performs the necessary steps in the action part, e.g. removes the command from the queue. Notice that with the above assumption a task can only wait at most for one marker at any time. Notice that the above mechanism is actually a scheduler, which is controlled by rules. It has of course the problems any scheduler has, i.e. it should guarantee fairness etc. The tasks can also deadlock as they might wait for different markers in a circular manner. F’urther, the ECA-rules controlling the functioning might be incomplete and thus cause a deadlock (no task causes the resume-command). We do not handle these problems here further. Our ECA rule mechanism is similar to, but more general than predicate locking [14] or escrow locking [35]. Unlike these locking methods our ECA rules are based on a predefined set of markers. In principle, the more marker types we have, the more application semantics we can utilize in our workflow concurrency control. An additional benefit in using ECA rules is that they conform nicely to the work done in active database area, and can reuse (at least part of) the implementation mechanisms available [9]. In general, an ECA rule is of the following form: DEFINE RULE CALLED BY IF THEN EXECUTE ELSE EXECUTE ACTIVATED FOR For our purposesthe ECA rules can be viewed as predicates that should be satisfied by the system in order to guarantee that the workflows work correctly. It should be pointed out that ECA rules (unlike P-phase locking) do not aim at ensuring that the execution history will be serializable. In managing concurrent workflows ECA rules are activated by event hooks in the tasks. Therefore the workflow designer determines the constraints that the tasks have to follow in order to ensure that the workflow behaves correctly. We assume that the markers are objects with an interface allowing the necessary operations. They can be executed based on the event hooks. Each marker has a unique oid. Below, the markers have one attribute to store the value and mod(ify), inc(rease) and dec(rease) it. The actual values are taken from the activated for-clause event hook. In our example bank application case the following ECA rules are introduced:

Reusability

and Modularity

in lhnsactional

Workflows

113

DEFINE RULE upperlimit(x,l) CALLED BY tctask_id> IF value(x) > 1 THEN EXECUTE suspend(ctask_id)ELSE EXECUTE inc(x,y) ACTIVATED FOR DEFINE RULE release_for_upperlimit(x,l) CALLED BY tctask_id> if value(x) < 1 THEN EXECUTE resume_tasks_on(oid(x)) ACTIVATED FOR DEFINE RULE bottomlimit(x,l) CALLED BY cctask_id> IF value(x) < 1 THEN EXECUTE suspend(ctask_id)ELSE EXECUTE dec(x,y) ACTIVATED FOR cworkflow_id,task_id,command,dec(x,y)> DEFINE RULE release_for_bottomlimit(x,l) CALLED BY cctask_id> if value(x) > 1 THEN EXECUTE resume_tasks_on(oid(x)) ACTIVATED FOR DEFINE RULE value(x,S) CALLED BY cctask_id> IF value(x) NOT IN S THEN EXECUTE suspend(ctask_id) ACTIVATED FOR cworkflow_id,task_id,command,mod(x)> DEFINE RULE release_for_value(x,S) CALLED BY if value(x) IN S THEN EXECUTE resume_tasks_on(oid(x)) ACTIVATED FOR DEFINE RULE variation(x,S) CALLED BY IF value(x) NOT IN [x-s,x+s], s IN S THEN EXECUTE suspend(ctask_id)ELSE EXECUTE mod(x) ACTIVATED FOR DEFINE RULE release_for_variation(x,S) CALLED BY if value(x) IN S THEN EXECUTE resume_tasks_on(oid(x)) ACTIVATED FOR The ECA ruleupperlimit(x,l) prevents otherworkflowsfromupdatingadataobjectx suchthat thenew valuewouldbe greater than 1. Respectively bottomlimit(x,l) prevents otherworkflows of updating xin sucha waythatthe new valuewouldbe smaller than 1. The corresponding release-rules arefired, whenever the values aremoved to a direction, where

114

JUHAPUUSTJ~~FLVI et al.

the suspended tasks could again be tested for eligibility. resume_tasks_on(oid(x)) suspended for marker with aid(x) and starts them.

scans all tasks

A value (x, s) prevents other workflows from updating the data object x in such a way that the new value would not be included in the value set S. The value set may be an interval or a finite set of values. Setting a value lock does not require that the current value of x is included in the value set. This is necessary if value rules are used as dynamic consistency constraints. A related rule type is variat ion(x ,s), which allows other workflows to update x only if the new value of x deviates from its old value by the value which is an item of the set S. In all these ECA rules the execution condition “suspend” implies that the task attempting to violate the constraint is suspended to wait the removal of the activation of the rule. This corresponds to traditional locking. ECA rules offer also other possibilities, for example the execution of the calling task can be continued with a notification that the attempted modification of the data object was not allowed. As an example of the use of an ECA rule consider the workflow Client credibility of Figure 3. The correctness of the workflow requires that data on which the evaluation is based on should be valid at the end of the execution of the workflow. For example, the loans the client has should not have essential increments during the process. Minor increments could be allowed as they may be resulted from interest additions. Such a constraint can be forced by activating in the task Client’s data access the rule upperlimit (clientloan, 11, where the value of 1 is e.g., five percent greater than the value of client’s current loan. The rule may be deactivated at the end of the workflow or at the end of the workflow which called Client credibility as a subworkflow. In general, the moment when the rules are deactivated may be a parameter of the task or a workflow call.

5.2. Managing Static Consistency Constraints As an example of the use of the upperlimit ECA rule to maintain a consistency constraint assume that there is a consistency constraint stating that a fixed limit maxliability exists for the bank’s liability. To ensure this consistency constraint the workflow designer defines the ECA rule upperlimit (bank’s liability, maxliability >, after which workflows can be processed concurrently as long as the validity of the constraint is not challenged. Evidently this is a more liberal approach than testing the validity of the consistency constraint in each transaction program updating bank’s liability and setting a traditional “data lock” on bank’s liability. It should be observed that activating an upperlimit rule does not require reading the state of the object x itself. This is important as the workflow management system is a global system constructed on top of possibly autonomous applications, and thus has no way of controlling the modification of the data objects used by the applications.

5.3. Managing Dynamic Consistency Constraints By activating more than one ECA rule on a single data object it is possible to utilize more application semantics in the synchronization. For example, by activating rules upperlimit (x , 10) and variation (x, 1) we can enforce that data item x can only grow in increments of one from it’s current value up to value 10. By allowing ECA rules to invoke other ECA rules we can also support dynamic consistency constraints. To illustrate this assume that the workflow system supports the states (hand-in, in-processing, granted, re jetted) of the“request” workflows such that the state transitions have dynamic consistency constraints (Figure 8). For example assume that the marker object is loan-request-status having the value hand-in. Then the ECA rule value with the value set S = {in-processing} would only allow the modification hand-in + in-processing. If such a modification activates a value rule with the value set consisting of the items granted and rejected, the dynamic consistency constraint stating the intended legal state transitions is enforced.

Reusability

Fig. 8: A Graphical

5.4.

Ensuring

and Modularity

Presentation

in Transactional

of a Dynamic

Workflows

Consistency

115

Constraint

Compensations

The use of the traditional transaction models would require that a whole workflow or a workflow task constitutes an atomic unit. In fact we argue that atomicity, i.e., a workflow being always run into a successful or a non-successful completion, is in many cases a useful transactional property for users. Unfortunately, if “too much” autonomy is left for the local legacy systems, atomicity cannot be fully guaranteed. Some tasks do not, even in principle, have a compensating task, and even if they had, the compensating task cannot always be completed without violating the local database consistency. This can easily be illustrated by a simple example. Let us assume that a task transferring an amount consists of an action which performs a withdraw on bank account account9 and an action which deposits into account account-1 the same amount. Assume now that the withdrawal fails and the deposit succeeds, and immediately after the successful deposit an action succeeds to withdraw the whole account account_l. As a result the compensation, i.e., the withdrawal from account account_1 will not succeed anymore. To prevent the above described situations from happening, we can use previously described ECA rules. For example, one only needs to activate a rule which prevents withdrawals in the above example case. However, this is overly conservative as withdrawals have to be prevented only if the balance of the account is less than the amount to be withdrawn. This can be enforced by activating a rule bottomlimit (account-l, amount) in the withdrawing task.

6. COMBINING

TRANSACTIONAL

TASKS

We have already argued above that workflow task reusability is an essential feature of real life workflow systems. However, task reusability introduces the problem that the task variations appearing in different workflows may require different transactional properties (e.g., isolation or atomicity requirements). This leads us to consider parameterized transactional properties which reflect the application dependent variations in the workflow tasks. Analogously to the correctness of transaction processing systems, which is based on the assumption that each individual transaction is correct, we assume that each workflow instance behaves correctly when executed alone in the absence of failures. We are interested how the correctness of a workflow instance may be violated as a result of other concurrent activities, i.e., other concurrent workflow instances and transactions. This suggests that a natural starting point is to isolate a workflow instance against other workflow instances and transactions. However, evidently various different degrees of isolation are needed. instances are not needed to isolate against existing local applications if same data. On the other hand, within a workflow a particular task or require a different level of isolation from other tasks. Furthermore, in instance may not actually require isolation at all, but only a “guarantee” item values remain in a prespecified value domains.

For example, workflow they do not access the task combination may many cases a workflow that the a set of data

These observations together with the efforts to utilize modularity and reusability have prompted us to introduce two new approaches to transactional workflows: local task integration (Section 6.2) and execution mode based task binding (Section 6.3).

116

JUHA PUUSTJ~VI

6.1.

Integration

et al.

of Tasks

In practical application environments locking protocols and the SQL-languages are very commonly used. We now consider how these features can be utilized in integrating transactional local tasks. In general locking mechanisms are very suitable for providing less restrictive properties than ACID ones. For example, the traditionally used consistency degrees [19] from degree 0 to degree 3 provide various atomicity and isolation levels, and for each of the levels there is a corresponding locking protocol, which deviate in the way they obtain and release locks. Particularly degree 3 provides serializable and recoverable histories while the other levels weaken these criteria. These four isolation levels are common in many systems as the SQL2 standard defines these levels. Another approach, called multilevel atomicity [30], weakens the usual notion of serializability by permitting controlled interleaving among transactions. It is based on the observation that there are distinct purposes for grouping the steps into transactions. For example, the steps may be grouped together as they form a unit or as they comprise a unit of serializability. Applying this principle requires that the workflow designer can set lock and unlock commands in the transaction programs. We will adapt the notion of multilevel atomicity and locking protocols in grouping tasks together in order to create appropriate units of atomicity or isolation. For example, let us assume that the tasks Tl and Tz are ACID transactions and we want to combine them to a transaction having appropriate transactional properties. Then the transaction programs of TI and T2 are included between the markers “Begin transaction” and “End transaction”. This ensures that the combined execution is atomic. Then the isolation requirements can be relaxed by defining transactions isolation level (0,1,2 or 3), or by tailoring the isolation requirements by explicitly setting lock and unlock commands. The three most straight-forward task integration choices can be specified e.g., by the following specification primitives, which differ in that whether the execution is atomic, serializable or both: . .. . T,)

l

DEFINE task-atomicity(Ti,

l

DEFINE task-serializability(Tl,..., T,)

l

DEFINE task-transaction(Tl,..., T,) (corresponding to degree 3 consistency)

Naturally this set of task integration primitives is open in the sense that new primitives can be introduced if needed, e.g., the integration primitives corresponding degree 1 and degree 2 consistency could be introduced. 6.2. Execution Mode Based Task Binding Returning to our example, we have seen that the task Bank’s liability update is included in the worktlows Loan request and Bill request. In the former it can be compensated by the task Bank’s liability decrement if necessary. In the latter it is not executed until the bill is granted, and thus its execution requirement matches more to the traditional transaction without any requirement for compensation. This example suggests that analogously to the different isolation modes discussed earlier, a task may also require various modes for atomicity. This situation is analogous with nested transactions [32, 15,161where typically subtransactions havetosatisfy the ACID properties when executed alone, but the nested transaction does not necessary have to be fully isolated. To capture the facility of varying execution requirements of a task we introduce the following execution modes: l

DEFINE acid-modeCT)

l

DEFINE prepare-mode(T)

l

DEFINE compensation-mode(T)

l

DEFINE independent-mode(T)

Reusability

and Modularity

in Transactional

Workflows

117

The first mode listed is the strictest way to execute a task. A task is in a acid mode if it is in a prepared mode [19] and it has not released any locks. If the task provides acid mode as an external state, then by the 2PC-protocol [5] task can be combined to one transaction while the prepare mode ensures only the atomicity of the combined tasks. A more liberal way to execute a task is to use application semantics and execute a task in a compensation mode , i.e., to enforce semantic atomicity. Compensation mode is particularly useful for executing distributed workflows while preserving the autonomy of local systems. Executing a task in an independent mode means that no assurance of ACID properties of a task execution is needed, e.g., if the workflow itself restarts the failed task. For example assume that task 2’1 (withdrawing an account) and TZ (deposit of an account) are ACID transactions, and we then want to form task T (transfer of money) by combining TI and T2. Now depending on the application requirements on the transfer, we can use the following modes: l

l

l

Acid mode, meaning only on one account.

that

a user (another

transaction)

Prepare mode, a user may also see the money on both accounts. Compensation mode, meaning that ensured by compensating actions.

if either

may see the money

to be transfered

withdrawing

on neither

or deposit

to be transfered

of the accounts

fails, then

atomicity

or

is

The above choices are analogous to the related issues in heterogeneous distributed database systems, where we can support different atomicity and serializability requirements (serializability of local transactions, serializability of distributed transactions or serializability of all transactions) by replacing the prepared state of the 2PC-protocol by other states having stricter semantics than the prepared state has [37]. 7. CONCLUSIONS Modern business applications are usually composed of independently designed components Workflow techniques can be seen as which are accessed concurrently by a large set of users. techniques to coordinate and streamline such business processes. We have discussed here several key aspects in the development of large scale workflow management systems based on the notion of transactional workflows, where the application execution has to conform to a set of correctness constraints derived from the application domain. One salient feature of a real, large scale workflow system is its dynamicity. New workflow definitions and the modifications of existing workflow specifications occur frequently. We argue that to avoid redundant design and maintenance it should be possible to produce new specifications by using existing specifications, i.e., workflow task reusability should be possible. Consequently management of shared workflows, i.e., workflows that share one or more tasks in their specification, is an important issue in transactional workflows. The basic idea is that the workflow designer designs individual tasks, and composes different Thus, the same task specification can occur in sevworkflows using the tasks as components. eral workflow specifications. Further, because the needs of different workflows might be slightly different, we assume that there exist slightly different versions of the same task, which we call task variations. These task variations can behave in a different manner if run as part of different workflows. The key idea in this context is that a task instance can have context-dependent transactional properties. The work presented in this paper relies on the observation that there is no reason to bind the specification of a task to any particular set of transactional properties (atomicity and isolation requirements) since these requirements may vary in different workflows. Consequently in our approach transactional properties are not fixed until a specification is linked to a workflow. This happens by setting the corresponding parameter value during run-time. Our goal has been to address issues related to concurrent execution of shared workflows, and to provide concepts for managing tasks with transactional properties in such contexts. In particular

JUHA PUUSTJ~~FLVI et al.

118

we have introduced the novel idea of parameterized transactional properties of task specifications with the related notions of task integration and task execution modes. Unfortunately, the autonomy properties of the local system, reflected at the global/local interface, and the capabilities of the global level workflow management software might delimit possibilities of achieving the strongest transactional properties in the above setting. We have thus investigated also the mechanisms one could use to restrict the concurrency anomalies of parallel workflows with shared tasks. The solution advocated in this paper is that we can use the same mechanism to support both the task integration and the prevention from concurrency anomalies. Technically, our approach was based on the use of the ECA rule mechanism at the global schema level in the TransCoop architectural framework described in Section 3. The rule mechanism can thus be used for different purposes in the context of reusable transactional workflows. As the control flow has already earlier been modeled by ECA-rules, this seems to be an interesting approach to support workflow technologies. In this paper we have omitted many technical issues that certainly require much more attention. For instance, we have not addressed properly the task code generation from the specification. Another issue is how one is able to check that the ECA rules used to guide diverse issues in the system behave together, whether the execution can for example deadlock etc. Thirdly the scalability of the solution has to be investigated. If thousands of rules are needed, how should they be managed, and which components in the architecture are responsible for the rules, etc. The latter issue is of prime importance especially in large scale (distributed) workflow systems with perhaps thousands of sites. Further evident topics for future work are twofold: formalization of the concepts introduced, so that their properties can be proven, and application of the techniques in real life pilots. Acknowledgements This work was partly supported by ESPRIT LTR project TransCoop (EP8012), which was partially funded by the European Commission. The partners of TransCoop are GMD (Germany), University of Twente (The Netherlands), and VTT (Finland).

REFERENCES

Ill

G. Alonso, D. Agrawal, A. El Abbadi and C. Mohan. Functionalities and limitations management systems. IEEE Expert (Special Issue on Cooperative Information Systems)

PI

G. Alonso, M. Kamath, D. Agrawal, A. El Abbadi, R. Giinthiir and C. Mohan. Failure handling in large scael workflow management systems. Technical Report RJ9913, IBM Almaden Research Center (1994).

of current (1997).

workflow

I31 G. Alonso, M. Kamath, D. Agrawal, A. El Abbadi, R. Giinthar and C. Mohan. Advanced transaction in workflow contexts. In Proc. 12th IEEE Conference on Data Engineering. (1996).

models

[41 M. Attie, M. Singh, A. Sheth and M. Rusinkiewicz. 19th International Conference on VLDB (1993).

In The

[51 P. Bernstein,

V. Hadailacos (1987).

Addison-Wesley

and N. Goodman.

Specifying and enforcing intertask Concurrency

Control

PI A. Biliris, S. Dar, N. Gehani H. Jagadish and K. Ramamritham. transactions.

SIGMOD

VI Y. Breitbart, approaches

Record,

Asset:

in Database

Systems.

A system for supporting

extended

(1994).

23(2)

A. Deacon, H.-J. Schek, A. Sheth and G. Weikum. Merging application-centric and data-centric to support transaction-oriented multi-system workflows. Sigmod Record, 22(3) (1993).

PI 0. Bukhres, A. Elmagarmid neering

and Recovery

dependencies.

Bulletin,

16(2)

and E. Kuhn.

Implementation

of the flex transaction

model.

IEEE

Data

Engi-

(1993).

PI C. Bussler and S. Jablonski. database

systems.

Engineering:

Implementing agent coordination for workflow management systems using active In S. Chakravarthy and S. Urban, editors, IEEE Proceedings Research Interests in Data

Active

Database

Systems

(RIDE’SI)

PO1 U. Dayal, M. Hsu and R. Ladin. Conference on VLDB (1991).

A transaction

WI U. Dayl, M. Hsu and R. Ladin.

Organizing

SIGMOD

International

Conference

(1994).

model for long-running

long-running

on Management

activities

activities.

In The 17th International

with triggers and transactions.

In ACM

of Data (1990).

WI R. de By, A. Lehtola, 0. Pihlajamaa, transaction

processing

1131 A. Elmagarmid, 16th International

systems.

J. Veijalainen and J. W&.ch. A reference architecture for cooperative Technical Report 1694, Technical Research Centre of Finland (1995).

Y. Leu, W. Litwin and M. Rusinkiewicz. International

Conference

on VLDB

A multibase transaction (1990).

model for interbase.

In The

Reusability

and Modularity

in Transactional

[14] K.P. Eswaran, J.N. Gray, P.A. Lorie and I.L. Traiger. database system. Communications of the ACM, 19(11) [15] H. Garcia-Molina, D. Gawlick, sagas. IEEE Data Engineering [16] H. Garcia-Molina (1987).

Workflows

The notions (1976).

of consistency

J. Klein, K. Kleissner and K. Salem. Bulletin, 14(l) (1991).

and K. Salem.

Sagas.

In ACM

SIGMOD

119

Modeling

International

and

long-running

Conference

[17] D. Georgakopoulos, M. Hornick and F. Manola. Customizing transaction grammable environment supporting reliable workflow automation. IEEE gineering (1996).

predicate

locks

activities

in a

as nested

on Management

of Data

models and mechanisms in a protins. on Knowledge and Data En-

[18] D. Georgakopoulos, M. Hornick, F. Manola, M. Brodie, S. Heiler, F. Nayeri and B. Hurwitz. An extended transaction environment for workflows in distributed object computing. IEEE Data Engineering Bulletin, 16(2) (1993). [19] J. Gray

Z’ransaction Processing:

and A. Renter.

Concepts

and Techniques.

[20] W. Harrison, H. Ossher and P. Sweeney. Coordinating concurrent ence on Computer-Supported Cooperative Work (1990). [21] K. Jensen.

Colored

[22] S. Joosten. Challenges,

Petri

Nets.

Springer-Verlag

model

analysis.

for software

[24] G. Kaiser and C. Pu. Dynamic restructuring Models for Advanced Applications, chapter

In Proceedings

engineering.

of CON’g4:

In Proceedings

[27] J. Klein.

Advanced

rule driven

[29] P. Lawrence,

editor.

Workflow

and W. Retschizegger. Workflow Committee on Data Engineering,

transaction

management.

In IEEE

Handbook

1997. John

[31] C. Mohan, G. Alonso, R. Giinthijr and M. Kamath. systems. Bulletin of the IEEE Technical Committee An Approach

[34] M. Nodine, S. Ramaswamy and S. Zdonik. Elmagarmid, editor, Database ‘Transaction Publishers (1992). The escrow

transactional

Wiley

Database

nansaction

based (1995).

on objects,

Split transactions

[37] J. Puustjlrvi. 31(3) (1991).

management

(1991).

for database

concurrency

Distributed

Computing.

ACM

ACM for open

Transactions ended

of transactions

on Database

activities.

Massachusetts

development.

Systems,

distributed

ll(4)

(1986).

database

Conference systems.

control for overlapping and cooperative and Application environments (TCOS),

[39] .J. Puustj;irvi, H. Tirri and J. Veijalainen. Managing overlapping transactional tional Conference on Advanced Information Systems Engineering (CAiSE’g6) Extending

workflows. (1996).

the transaction

ii.2. Technical

Report

BIT,

workflows. i3( 1) (1996).

In The 8th Intema-

model

to capture

[41] J. Tang and J. Veijalainen. Enforcing inter-task dependencies in transactional workflows. In Proceedings the Third International Conference on Cooperative Information Systems (CoopIS-g5) (1995). deliverable

In

for design databases. In A.K. chapter 3, Morgan Kaufmann

In The 14th International

in heterogeneous

W. Litwin.

software

fians-

management

PhD thesis,

for cooperative Work (1992).

A cooperative transaction model Models for Advanced Applications,

[40] M. Rusinkiewicz, A. Elmagarmid, Y. Leu and meaning. SIGMOD Record, 19(l)(1990).

control.

Exotica: A research perspective on workflow on Data Engineering, 18(l) (1995).

Concurrency [38] J. Puustjirvi, H. Tirri and J. Veijalainen. Bulletin of the Technical Committee on Operating Systems

[42] T. Tesch and P. Verkoulen. Transcoop Basic Research Action 8012 (1995).

rules

& Sons (1997).

criteria

to Reliable

method.

[36] C. Pu and N. Hutchinson. on VLDB (1988). Distributed

Conference

in very large workflow manTechnology, Avignon, March.

management 18(1):11-18

COMPCON

“Lazy” consistency: A basis [33] K. Narayanaswamy and K. Goldman. Proceedings of the Conference on Computer-Supported Cooperative

[35] P.E. O’Neil.

Management,

Multidatabase transaction and query processing in logic. In A.K. Models for Advanced Applications, chapter 9, Morgan Kaufmann

[30] N.A. Lynch. Multilevel atomicity - a new correctness actions on Database Systems, 8(4) (1983).

[32] J.E.B. Moss. Nested Transactions: Institute of Technology (1985).

Workflow

of transactions. In A.K. Elmagarmid, editor, 8. Morgan Kaufmann Publishers (1992).

[28] E. Kuhn, F. Puntigam and A. Elmagarmid. Elmagarmid, editor, Database Transaction Publishers (1992).

(1993). of the Confer-

of Sixth International

[25] M. Kamath, G. Alonso, R. Giinthijr and C. Mohan. Providing high availability agement systems. In Proc. 5th International Conference on Extending Database Also available as IBM Research Report RJ9967 (1996). [26] G. Kappel, P. Lang, S. Rausch-Schott and roles. Bulletin of IEEE Technical

Kaufmann

In Proceedings

(1991).

Trigger modeling for workflow Paradigms and Products (1994).

[23] G. Kaiser. Flexible transaction on Data Engineering (1990).

Morgan

development.

TC/REP/GMD/D2-2/207,

more of the

ESPRIT

JUHA PUUSTJ~~RVIet al.

120 [43] J. Veijalainen. Heterogeneous of the DEXA ‘93 (1993).

multilevel transaction

management

with multiple subtransactions.

In Proceedings

[44] J. Veijalainen, F. Elisssen and B. Holtkamp. The s-transaction model. In A.K. Elmagarmid, editor, Database lhnsaction Models for Advanced Applications, chapter 12, Morgan Kaufmann Publishers (1992). [45] W. WEhter.

Contracts:

A means for improving

reliability in distributed

computing.

In IEEE COMPCON

(1991).

[46] H. WHhter and A. Reuter. The contract model. In A.K. Elmagarmid, editor, Database Zhnsaction Advanced Applications, chapter 7, Morgan Kaufmann Publishers (1992). [47] G. Weikum. Principles and realization strategies Database Systems, 16( 1) (1991).

of multilevel transaction

management.

[48] G. Weikum, A. Deacon, W. Schaad and H. Schek. Open nested transactions IEEE Data Engineeting Bulletin, 16(2) (1993). (491 G. Weikum and H. Schek. Bulletin (1991).

Multi-level

transactions

and open nested

ACM Zhnsactions

in federated

transactions.

Models for

database

on

systems.

IEEE Data Engineering

[50] G. Weikum and H. Schek. Concepts and applications of multilevel transactions and open nested transactions. In A.K. Elmagarmid, editor, Database ‘2Yansoction Models for Advanced Applications, chapter 13, Morgan Kaufmann Publishers (1992).