Management of business process constraints using BPTrigger

Computers in Industry 55 (2004) 29–51

Management of business process constraints using BPTrigger Chulsoon Park1, Injun Choi* Department of Industrial Engineering, Pohang University of Science and Technology, Pohang 790-784, South Korea Received 22 January 2003; accepted 29 November 2003 Available online 10 May 2004

Abstract This paper proposes a new mechanism, called BPTrigger, which can overcome limitations of current Database (DB) Triggers. DB Triggers are used to enforce integrity constraints related to data stored in databases. They are not adequate, however, for complex business constraints that must be applied to several business processes or activities, hence, involving many data items. Further, DB Triggers does not properly support distributed and heterogeneous environments and may incur serious performance degradation including non-termination. BPTrigger enables representation and flexible enforcement of complex business process constraints in a distributed and heterogeneous environment. Unlike a DB Trigger that must be defined on each data item participating in a constraint and must be checked every time the data item is updated, BPTrigger allows a constraint to be defined only once on a business process and enforces the constraint once at the time of execution of the process. To provide comprehensive support, the paper identifies all possible constraints related to business processes based on literature survey and classifies them into four types: entry, exit, running, and invariant, according to the time of enforcement. Reflecting the requirements suggested by the classification, the syntax of BPTrigger is defined. An additional construct is proposed to enable flexible management of invariants. The paper also introduces a prototype system for BPTrigger along with an extended example to demonstrate its feasibility and to provide a performance comparison with typical DB Triggers. # 2004 Elsevier B.V. All rights reserved. Keywords: Business process; Constraint management; Trigger; Workflow management

1. Introduction Database (DB) Triggers were introduced to enforce integrity constraints related to data stored in databases. They are not adequate, however, for complex business constraints that must be applied to several business processes or activities, hence, involving many data items. To illustrate the problem, consider *

Corresponding author. Tel.: þ82-54-279-2205; fax: þ82-54-279-2870. E-mail address: [email protected] (I. Choi). 1 Present address: Industrial and Systems Engineering, Changwon National University, Changwon 641-773, South Korea.

the following inventory control policy of a company. A company has an inventory policy such that the projected inventory level should be enough to satisfy the confirmed order quantity. The projected inventory level is the sum of current stock, projected receipts (to inventory), and outstanding purchase order amount minus the total demand quantity. Such a policy may be enforced with a typical DB Trigger shown in Fig. 1 (the trigger literally reiterates the above inventory policy as an MS SQL Trigger). To properly enforce the above inventory policy for all possible business activities affecting inventory, DB Triggers similar to the above trigger must be defined on all tables participating in the constraint

0166-3615/$ – see front matter # 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.compind.2003.11.003

30

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

CREATE TRIGGER inventory_policy ON dbo.Ordering FOR INSERT, UPDATE, DELETE AS DECLARE @current_stock int, @projected_receipt int, @outstanding_purchase_order int, @total_demand int, @total_order_qty int, @inventory_level int SELECT @total_order_qty = SUM(ASCII(O.quantity)) FROM Ordering O , inserted S WHERE O.productID= S.productID GROUP BY O.productID SELECT @current_stock =ASCII(I.quantity), @projected_receipt =ASCII(T.quantity), @outstanding_purchase_order =ASCII( P.quantity), @total_demand = ASCII(D.quantity) FROM Ordering O INNER JOIN inserted S ON O.productID = S.productID INNER JOIN Inventory I ON S.productID = I.productID INNER JOIN Projected_Receipt T ON I.productID =T.productID INNER JOIN Purchase_Order P ON T.productID = P.productID INNER JOIN Demand D ON P.productID = D.productID WHERE O.productID=S.productID SET @inventory_level = @current_stock + @projected_receipt + @outstanding_purchase_order - @total_demand IF (@inventory_level < @total_order_qty) BEGIN RAISERROR ('Inventory_Level_Error',16,1) ROLLBACK TRANSACTION END

Fig. 1. Database trigger example.

such as tables for current stock, projected receipts, etc. This can cause several problems. First, the above constraint may not be enforced if the related tables are stored on distributed and heterogeneous databases. Second, there will be a serious overhead since a DB Trigger will be invoked every time there is a database update on one of the participating tables. Further, a certain trigger may cause other triggers to be invoked, degrading the system performance even more. There are more fundamental problems when using DB Triggers for business constraints related to complex business processes. For the above inventory policy example, consider the following scenario the company wants to implement. The company checks and enforces the policy when it performs the production order generation activity or when damaged inventory items are found. If the policy is found to be violated when the production order generation activity is performed, the company generates more production orders to satisfy the policy. If the policy is found to be violated when damaged inventory items are counted, the company issues purchase orders since its production lead time is not enough to fulfill confirmed orders. DB Triggers are invoked when update operations performed on databases (insert and delete operations are also included to be more precise). Further, the

action associated with a DB Trigger can only abort the update operation if the constraint is violated, or send a certain message at best. The above scenario suggests that there is a gap between the time when a DB Trigger is invoked and the time when a business constraint is actually checked and enforced. It also suggests that DB Triggers are not flexible enough to handle actual business process logic, especially, performed by humans. A more serious drawback of a DB Trigger is that it cannot specify the business process/activity to be performed when a constraint is violated. In the above scenario, another process of issuing purchase orders must be started when damaged inventory items are found. Even active object-oriented database systems, which allow user-defined methods in the action part of a DB Trigger, cannot properly provide such a capability since starting a business process/activity is far more involved than invoking a method or sending a message in an information system. Therefore, a new enforcement mechanism is required for business process constraints. Workflow management systems (WfMSs) are a candidate for enforcing complex constraints related to business processes. They are mainly focused, however, on constraints related to the control of processes such as branching conditions among alternative successor processes/activities or process time constraints.

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

Transactional workflow deals with more general conditions related to execution of business processes [19,36,37]. They are mainly focused, however, on erroneous conditions rather than general rules or policy related to business processes. Rule-based approaches such as IBM BRML are another candidate for maintaining business process constraints [29]. While they offer inference capabilities, especially for new unstated rules, business rule systems do not provide enforcement mechanisms, specially associated data repositories used for day-to-day business transactions. This paper proposes a new mechanism, called BPTrigger, which enables representation and flexible enforcement of complex business process constraints in a distributed and heterogeneous environment. First, the paper identifies all possible constraints related to business processes to provide comprehensive support. Next, they are divided into four types: entry, exit, running, and invariant according to the time of enforcement. The paper defines BPTrigger by extending ECA model [15,24] from the business process perspective and provides its syntax. Unlike DB Triggers that are invoked when the database system performs update operations and simply aborts the update operation if the constraint is violated or sends a certain message, BPTrigger supports actions with different semantics such as invocation of business processes/ activities for compensation, rework, or exception handling adopted and extended from transactional workflow approaches [19,37]. For invariants that must be always satisfied and hence requires prohibitive cost to maintain them, this paper provides an additional construct for definition of invariants. With this construct, invariants can be flexibly enforced by checking them only for the declared activities, not all the time throughout the execution of the entire range of business processes. The definition of invariant is translated to a BPTrigger for each declared activity and enforced as a regular BPTrigger. Finally, the paper describes a prototype system for BPTrigger along with a business process example that will demonstrate how complex business process constraints can be effectively managed. For a performance comparison between a typical DB Trigger and a BPTrigger, a benchmarking test is performed and its results are described. The remainder of the paper is organized as follows. In Section 2, related research is discussed including

31

constraint enforcement approaches using database triggers and active object-oriented databases, business process constraints, transactional workflow concepts, and business process management. Section 3 presents a comprehensive classification of business process constraints and proposes BPTrigger along with its syntax. An additional construct for invariants is also proposed. Section 4 introduces a prototype system that manages BPTriggers in XML DTD along with an extended example. Benchmarking test results and termination issue of BPTrigger are also described. Finally, Section 5 concludes the paper along with discussion of further research directions.

2. Related work As diverse business applications and entities participate in the business process in an enterprise, the constraints between them also tend to compound existing problems. Business process constraints that are considered in business process modeling include structural and action assertions which represent a description of the business structure, and actions that take place in business [12], global integrity rules [57], and internal and external integration requirements [8]. Weiden [62] also proposed a more refined categorization of business rules, classifying them into structural, behavioral, and managerial rules. Such business process constraints, however, mainly focus on the activity coordination and condition check for routing. Business process constraints must assure that the actions by the performer conform to the work manual or company policy, and provide the functionality for supporting the performer in activity execution. Workflow management has been adopted as one of the major information technologies for managing business processes. Especially, much work has been devoted to transactional workflow areas [19,36]. Kamath and Ramamritham [37] used the notion of compensation for error handling and proposed a novel approach called opportunistic compensation and re-execution for error handling. There were projects such as Exotica and Meteor to build largescale WfMSs with transactional support [46,66]. More comprehensive technology for business process management is business process management

32

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

system (BPMS) [20,56]. Business Process Management Initiative (BPMI), an international organization setting standards on BPMS, is devoted to the development of open specifications for the management of e-Business processes that span multiple applications, corporate departments, and business partners over the Internet. Related to the business process management, a number of languages for process specification and design have been proposed. Most notable ones are Process Interchange Format (PIF) [42], WfMC’s Workflow Process Definition Language (WPDL) [63], and NIST’s Process Specification Language (PSL) to establish a standard process definition language [51] (PIF project was merged with the PSL project). Recent research activities were focused on using XML to specify and exchange process definitions. They include mapping of PSL into XML to exchange process information [45], translation of each WfMC Interface into XML [64,65], BPML which is an XML-based process definition language [33], and XRL (eXchangeable Routing Language) which translates inter-organizational workflow definition into XML [1]. A core feature of XRL is that it provides a mechanism to describe process at an instance level. Further, the semantics of XRL is expressed in terms of Petri Nets for which powerful analysis techniques are available. There were also a lot of researches in that they adopt XML for process definition and Petri Net for process simulation [2,3]. XML-net is an XMLbased specification language directly executable by its workflow engine [43]. WfMC published the draft version of XML Process Definition Language (XPDL) [65]. They also established an interoperability WfXML binding designed to model the data transfer requirements set forth in the WfMC’s Interoperability Abstract specification [64]. The XML-based process definition languages mentioned above, however, are mainly designed for exchangeability, that is, to exchange process definitions between two different systems. Recently, Web Services technologies are beginning to emerge as a standard for integrating distributed applications and processes using open, XML-based standards. Web Services are seen as an important infrastructure to foster business processes by composing individual Web Services to represent complex processes, which can even span multiple organiza-

tions. This requires a single standard that can manage both EAI and B2B interactions involving Web Services. Web Services composition languages such as BPEL4WS, BPML, WSCI, XLNAG, and WSFL can be used to integrate services defined using WSDL together [4]. The composition languages such as BPEL4WS [5,44], WSCI [6] and BPML [55] are proposed as a standard to orchestrate Web Services. The business process constraints are related to several business processes or activities, hence, involving many data items. Therefore, managing business process constraints can be regarded as managing the integrity consistency of related data. Much work has been devoted to this problem [27] and most commercial DBMSs include tools to maintain consistency. For example, the error handling in WIDE project is based on active database technology to provide advanced and efficient support for transaction management and for exception management in the WfMS [13]. Several studies were conducted in the multidatabase area to achieve integrity consistency in distributed environments. Integrity control in tightly coupled federations was studied by Conrad et al. [23]. The proposed concept requires integration by schema translation. In a loosely coupled case, Norrie et al. [48] pioneered the integration of integrity control. Their approach also considers local systems that do not provide DBMS functionality. Grefen and Widom [28] presented another approach for maintaining integrity in a loosely coupled federation. Chawathe et al. [18] proposed a similar approach. Specifically, active databases have provided a suitable framework to automatically enforce integrity with triggers as part of DBMS [14,16,26,52,61]. Traditional ECA-based active mechanisms, however, were designed for centralized systems and are monolithic, thus making it difficult to extend or adapt them [22]. Even simple integrity constraints can be violated while updating multiple tables related to the constraints, hence, causing a multitude of repair actions that may cause disastrous results. Furthermore, checking all related constraints after each transaction (even when it is not used) is prohibitively expensive. To reduce the overhead of monolithic runtime tests, it is suggested to prove at compile-time the fact that transactions respect integrity constraints [9,10,52].

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

Maintaining consistency in multidatabase systems, however, has raised new problems. As data are stored on several sites, it is essential to determine where each constraint must be defined, stored, and checked. Some works have studied the problem of constraint checking in federated databases [31], distributed databases [31], and multidatabase systems [30]. Sheth et al. [53] presented a framework to manage consistency among interdependent data in a multidatabase environment. Doucet et al. [25] presented a solution to check global integrity constraints (which involve data on several sites) for nested transactions in multidatabase systems. Recently, the object-oriented paradigm has provided many features which help describing business process behavior in a DB Trigger definition [17,34,35,38–40,49,58,59]. Active object-oriented database systems with basic mechanism of ECA rules are considered to be a promising technology to cope with such requirements as flexible coordination in workflow applications. An essential strength of this approach is that application specific business processes and rules are declaratively represented as data (i.e., object instance) and not code. This means that business process constraints are defined and maintained separately from the application code. Recent research efforts to represent business rules include IBM’s BRML [29] and OMG’s OCL [60]. BRML is a markup language to represent and exchange business rules related to E-Commerce contract. Its inference mechanism is implemented with Java API called CommonRules. OCL is a pure modeling language designed to strengthen the UML model and does not consider runtime issues. Therefore, a new approach is required for modeling and enforcing business process constraints in a manner familiar to the user while considering performance requirements at the same time. There were projects such as METEOR and WIDE, which are proposing an error handling in the workflow management area [13,41,66]. The current error handling framework in METEOR is limited to the context of workflow enactment services. One of the areas that remain to be addressed is providing better support for dealing with organizational errors (e.g., role-errors, security errors, etc). The error handling in WIDE project is based on active database technology to provide advanced and efficient support for transaction

33

management and for exception management in the WfMS. In other words, basic exception handling and condition monitoring mechanisms are provided by triggers defined in the Oracle DBMS.

3. BPTrigger for enforcement of business process constraints This section proposes a comprehensive classification of business process constraints. Then, the syntax of BPTrigger is defined to reflect the requirements suggested by the classification. An additional construct for invariants is introduced, which are constraints that must be always satisfied. 3.1. Business process constraints There have been several efforts to identify and classify business rules [8,12,62]. Especially, Weiden suggested that business rules should be classified into three categories: structural, behavioral, and managerial. The structural category includes static rule types such as business objects, relationships between them, and organizational structure. The behavioral category includes dynamic rule types such as information/control flow, pre- and post-condition. The managerial category includes organizational policy and goal. In this paper, all possible business process constraints are identified and grouped into six categories: object, behavior, execution, integration, translation, and managerial as shown in Table 1 by extending previous research results with further refinement of constraints for management of business processes in the information system context. The constraints in the object category describe restrictions on business object or their relationships in business process. The constraints in the behavior category describe how the activities in a business process should be related to each other. The constraints in the execution category describe the rules directly related to process execution. The constraints in the integration category describe requirements to support transactional and middleware functionality for process execution in a distributed and heterogeneous environment. The constraints in the translation category are special type of constraints that must be satisfied when translating a format or type to another. The constraints in the managerial category describe

34

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

Table 1 Description of business process constraints Category

Sub-category

Description

Object

Object structure

Restriction on the relationships between business objects. It also determines relationships between roles, and unit hierarchy Restriction on an object’s value or status on its lifetime Rules that determine how long information gathered in a process should be kept available during process execution Rules that determine how many instances of an object can exist at the same time or in the relation with another object or attribute Rules that describe the authority for creation, deletion, or modification of business object

Domain Persistency Occurrence Ownership Behavior

Decomposition Information flow Frequency Concurrency

Execution

Iteration Dependency And/or split And/or join Starting time Duration Deadline Sequence

Integration

Rules that describe what sub-activities should be performed to complete an activity Rules to restrict information flow between activities (sub-activities). That is, it describes the relationships between information producer and consumer activities Rules that describe the frequency of an activity Rules that describe the concurrency between activities or sub-activities Rules that describe how many times an activity or task should be repeated, or how many repetitions they are allowed Rules that describe the execution sequence or concurrent execution of activities such as forward, backward or mutual exclusion dependency Rules that describe the split condition of the process Rules that describe the join condition of the process Rules that describe how early or lately an activity should be started Rules that describe the duration of an activity Rules that describe how early or lately an activity should be finished Restriction on selecting a following activity at the time of enactment of the process. It describes the possible sequence between activities or sub-activities in a process

Resource management Application Long-duration control Legacy control Mobility

Rules that control the availability of resources for work assignment. It controls resources with access control list (ACL) or role, and describes the role authority of the performer Rules that describe the conditions for application invocation during integration process execution Rules that control the long-duration process

Translation

Type Feature

Description of translation between types Description of selecting features for translation

Managerial

Policy Regulation

Description of a set of ideas or plans that is used as a basis for making decision in enterprises Restrictions by a government or other authority in order to control the way something is done or the way people behave Description of a level of quality or achievement

Standard

Rules that control legacy applications Rules that describe conditions for mobile execution environment such as Web or e-mail

conditions that must be preserved by all business processes in the organization. Table 1 provides detailed description of each category. The constraints in Table 1 are classified into four types: entry, exit, running, and invariant as shown in Table 2 according to the time to enforce constraints when a business process is performed. The constraints of the entry type describe the conditions that must be checked before the target process or activity is

performed. The constraints of the exit type describe the conditions that must be checked when the target process or activity is completed. The constraints of the running type specify the conditions that must be checked while the target process or activity is executed. Finally, the constraints of the invariant type specify the conditions that should be satisfied all the time throughout the execution of the entire business processes.

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

35

Table 2 Business process constraints classification Category

Type Entry

Exit

Running a

a

Invariant a

Object

Object structure

Persistency , occurrence

Domain , ownership

Behavior Execution

Decomposition Split, sequence, deadline, duration Mobility

Concurrency Iteration, durationb

Integration

Information flow, frequency Dependency, starting time, join Resource management

Translation Managerial

Type N/A

Feature Policya, regulationa, standarda

Application integration, long-duration control, legacy control N/A N/A

Object structure, domain, persistency, occurrence, ownership N/A N/A N/A

N/A Policya, regulation, standard

a The sub-categories denote the constraints that may be checked at entry, exit or running for performance or convenience even though they should be classified as invariant type. b The sub-categories denote the constraints that may be checked at entry, exit or running for performance or convenience even though they should be classified as exit type.

3.2. BPTrigger: a process-oriented trigger BPTrigger is proposed by extending ECA model from the business process perspective. Unlike other active systems based on ECA model, BPTrigger makes explicit use of business process management concepts to enforce constraints when business processes are performed [20,55]. It enables the user to define a constraint on related business processes or activities (not on related data items) and to cope with constraint violations or exceptional situations at the process level. That is, the event specified by a BPTrigger is

a business process or activity and the associated action is also a process/activity for compensation, rework, or exceptions for the process. Fig. 2 shows the top-level structure for specifying constraints in BPTrigger in the extended BNF notation. BPTrigger has the following components: (1) Administrative information: For now, this component is used to uniquely identify BPTrigger. (2) Triggering event: .

= DEFINE BPTrigger AS [ BEFORE | AFTER | WHEN ] CONDITION ACTION EXCEPTION PRIORITY ; = | | ; = | | ; = | | | ; = | [, ]; = | [, ] ; = letter, {letter | decimal digit }; = letter, {letter | decimal digit }; = letter, {letter | decimal digit }; Fig. 2. Top-level structure of BPTrigger.

36

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

This component specifies the event that triggers the related BPTrigger and the time to enforce it. Unlike DB Triggers, the event described by includes the process, activity, or process/activity instance against which the constraint is enforced, specified by . When contains a particular instance identifier, the defined BPTrigger is applied only to that instance. When it contains a process or activity identifier, however, the defined BPTrigger is applied to every instance of the process or activity. Other event types such as activity initiation or completion messages, user defined messages, and temporal events can be specified for . The specifies the point of time to enforce constraint. The meaning of each alternative is as follows:  BEFORE specifies that the constraint is enforced before the related process or activity execution is initiated.  AFTER specifies that the constraint is enforced after the related process or activity execution is completed.  WHEN specifies that the constraint is enforced at an arbitrary time during the execution of an action. (3) Trigger condition: CONDITION . This component specifies the condition to be evaluated for the defined BPTrigger. It may contain a relational expression or and/or combination relational expressions. Relational expression may contain additive, multiplicative, set, or literal expressions. It can include reference pointers for the business process instance data that are used for the condition evaluation. That is, database table names, attribute names, and key values for the instance data are stored in a reference table. With this information, the instance data can be referenced at run time. (4) Triggered action: ACTION . This component specifies the actions to be performed when the condition is evaluated as true. In BPTrigger, the action is a process/activity that will compensate the process/activity or redo it. It will be inserted into a proper performer’s worklist (of the business process management

system). The action can also be notified to the performer by using option of e-mail or message. (5) Triggered exception handler: EXCEPTION . This component specifies the exception handling activity. When an exception happens during BPTrigger enforcement, the related activity for exception handling is assigned to a proper performer. It can be also notified to the performer by using the option of e-mail or message. (6) Trigger priority: PRIORITY . This component specifies the priority order of the defined BPTrigger as a non-negative integer. It is defined such that any BPTrigger with a smaller priority value has a higher priority. If the priority values of multiple BPTriggers are the same, the order is determined by the arrival time of the events. A BPTrigger is defined on a business process or activity. Several BPTriggers may be defined for the same process or activity. When an event is signaled, all BPTriggers which are related to the event are activated. When more than one BPTrigger is activated at the same time, the evaluation order is determined by the user-specified priority order. The activation time (BEFORE, AFTER or WHEN) determines when BPTrigger condition is evaluated. Especially, ‘WHEN’ enables to check the constraint while the process/ activity is executing. For example, the constraint that is enforced at the time of an activity completion such as duration check can be enforced while the activity is still executing for the purpose of performance or to expedite the activity if it is behind the schedule. If the condition is evaluated as true, the action specified in BPTrigger is immediately executed. That is, the related activity specified in BPTrigger action component is inserted into a proper performer’s worklist. If exceptions happen while BPTrigger is processing, the action specified in BPTrigger exception component is executed. That is, the activity for exception handling is inserted into a proper performer’s worklist. 3.3. Construct for invariants In his position paper, Sheth [54] suggested that for less than perfect real-world information systems, the

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

37

= DEFINE Invariant AS CHECK_POINTS CONDITION ACTION EXCEPTION PRIORITY ; = {([ BEFORE | AFTER | WHEN ] ) }; = | | ; = | | ; = | | | ; = | [, ]; = | [, ] ; = letter, {letter | decimal digit }; = letter, {letter | decimal digit }; = letter, {letter | decimal digit };

Fig. 3. Syntax of invariant construct.

standard notions of data correctness or integrity used in research literature are inappropriate and inadequate. Neither the full correctness with respect to the part of the real world modeled by the database nor the completeness of the facts stored in the database are ensured. Full integrity can only be achieved with human supervision, because the system cannot determine if a fact is true or false, and it cannot detect changes in the Universe of Discourse [27,47]. Sheth called upon the researchers and practitioners to pay more attention to developing the solutions that reflect different degrees of consistency rather than pure timeinvariant consistency. Reflecting the above arguments, this paper proposes an additional construct for invariants that are assumed

to be always satisfied (but costly to maintain them practically). Fig. 3 shows its syntax in extended BNF notation. The CHECK_POINTS component specifies the processes/activities against which the invariant is to be checked and their activation time points. An invariant defined by the construct will be translated to BPTriggers for the activities specified in this component. Other components of the construct have the same meaning as the corresponding components of BPTrigger. Fig. 4 illustrates how an invariant definition is translated to the corresponding BPTriggers. Fig. 4a shows an example of invariant definition. The CHECK_POINTS component indicates that the invariant is to be enforced on three activities: BEFORE

Fig. 4. Translation of an invariant to BPTriggers.

38

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

activity A1, AFTER A2 and WHEN A3. Fig. 4b–d shows the resulting BPTriggers for each activity translated from the definition of the invariant. If an invariant requires different actions against its violation or exception handling measures depending upon the processes/activities against which it is checked, they need to be defined separately. This may seem redundant, but each different action or exception handling against an invariant violation is also an important business logic that must be separately managed. With the proposed invariant construct, invariants can be flexibly maintained by checking them only for the declared activities in the construct, not all the time throughout the execution of the entire business processes. This construct strongly demonstrates the strategy of the proposed approach. In the real world, invariants are often checked and enforced only when they are necessary, not always. Invariants are usually checked when related business processes or activities are performed, not when related data items are updated as dictated by DB Triggers. Moreover, checking points of invariants may change for economic reasons or depending upon the availability of personnel and equipment. DB systems allow deactivating individual triggers. Unless all triggers are turned off, however, the overhead caused by a small number of triggers that remain active can still degrade the system performance.

4. Implementation of prototype system for BPTrigger This section describes a prototype system for BPTrigger to demonstrate its feasibility and provide a performance comparison with a typical DB Trigger. In the prototype system, the defined BPTriggers are translated to XML, which enables exchange and management of BPTriggers in heterogeneous and distributed environments. The section first presents an example of business process constraint and shows how it is defined as a BPTrigger. Next, it introduces the XML DTD for the manipulation of BPTrigger in the prototype and shows how the example constraint is represented in XML. Then, the section discusses the prototype system for BPTrigger along with the results of performance comparison tests.

4.1. Extended example The inventory control policy introduced in Section 1 is extended to demonstrate the feasibility of BPTrigger as follows: A company has an inventory policy such that the projected inventory level should be enough to satisfy the confirmed order quantity. The projected inventory level is the sum of current stock, projected receipts (to inventory), and outstanding purchase order amount minus the total demand quantity. The company checks the policy before it performs the production order generation activity or after inventory counting activity. If the policy is found to be violated when the production order generation activity is performed, the company issues emergency production orders to satisfy the policy. If the policy is found to be violated and no damaged inventory is found after inventory counting, then the same process of generating emergency production order is initiated. If the inventory policy is violated and damaged inventory is found after inventory counting, however, then the company issues purchase orders since its production lead time is not enough to fulfill confirmed orders. Fig. 5 shows the invariant definition for the above constraint. Notice that the CHECK_POINTS component of the invariant definition has (BEFORE production order generation activity) and (AFTER inventory counting activity), as stated in the above example. The ACTION component specifies the emergency production order activity required when the policy is violated for both specified activities. Fig. 6 shows BPTriggers generated from the above invariant definition. An additional BPTrigger is needed to specify the action required when the constraint is violated and damaged inventory items are

DEFINE Invariant Inventory_Level AS CHECK_POINTS BEFORE production order generation AFTER inventory counting CONDITION ((current stock + receipts + purchase_order) LT total_demand_qty) ACTION emergency production order Notify= [email protected] EXCEPTION check inventory level [email protected] PRIORITY 2;

Fig. 5. Invariant definition for the inventory policy.

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51 DEFINE BPTrigger Inventory_Level01 AS BEFORE production order generation CONDITION ((current stock + receipts + purchase_order) LT total_demand_qty) ACTION emergency production order Notify= [email protected] EXCEPTION check inventory level [email protected] PRIORITY 2; a) Before performing production order generation activity DEFINE BPTrigger Inventory_Level02 AS AFTER inventory counting CONDITION ((current stock + receipts + purchase_order) LT total_demand_qty) ACTION emergency production order Notify= [email protected] EXCEPTION check inventory level [email protected] PRIORITY 2; b) After performing inventory counting with result of no damaged stock

Fig. 6. BPTriggers for the inventory policy.

counted, as depicted in Fig. 7. Notice that two BPTriggers are defined on the inventory counting activity. The BPTrigger shown in Fig. 7 will be enforced ahead of the BPTrigger shown in Fig. 6b, however, because the priority of the former is higher than the priority of the latter. 4.2. XML DTD for BPTrigger In the prototype system, the defined BPTriggers are translated to and manipulated in XML. It enables easy implementation and provides interoperability among underlying DBMSs and/or BPMSs utilizing validity checking and interoperability features of XML. It will also enable definition and exchange of business process constraints in various formats on various platforms. Fig. 8 shows the top-level

DEFINE BPTrigger Inventory_Level03 AS AFTER inventory counting CONDITION ((current stock + receipts + purchase_order) LT total_demand_qty) AND (damaged_stock GT 0 ) ACTION special purchase order Notify= [email protected] EXCEPTION check inventory level [email protected] PRIORITY 1;

Fig. 7. Additional BPTrigger for the inventory counting activity.

39

structure of the XML DTD for BPTrigger (In this paper, the XML DTD is adopted instead of XML Schema for the purpose of easy translation from BNF notation.) The triggering event component of BPTrigger defined in Section 3.2 is split into three elements of BPT_context, BPT_event, and BPT_pot. The BPT_context element is used to identify the process, activity, or process/activity instance to which the constraint is defined. The BPT_event element is used for determining the constraints to be activated. Note that when a process or activity is designated as BPT_event, both BPT_context and BPT_event indicate the same process or activity. The BPT_pot element represents activation time. The triggering condition component of BPTrigger is represented by the BPT_condition element. The triggered action component of BPTrigger is represented by BPT_action. The triggered exception handler is represented by BPT_exception. Finally, BPTrigger name and priority ordering are represented as attributes of BPTrigger element. Appendix contains complete definition of BPTrigger in XML DTD. Fig. 9 shows the XML representation for BPTrigger example shown in Fig. 6a. BPTriggers in XML can be easily exchanged between organizations or transformed into various formats according to user requirements, which will facilitate implementation in distributed and heterogeneous environments using eXtensible Stylesheet Transformation (XSLT) and Simple Object Access Protocol (SOAP). Further, using XML can provide additional implementation advantages. XML documents can be retrieved or modified dynamically using DOM. 4.3. Prototype system The prototype system is developed to demonstrate the feasibility of the proposed approach and to provide performance comparison with a typical DB Trigger. The prototype system is implemented with MicroSoft1 Visual Cþþ 6.0 and MicroSoft1 SQL Server. For manipulation of BPTriggers in XML, it uses XML Spy1 for manual validity checking, MSXML Document Object Model (DOM) for parsing, and SQLXML for receiving the query result as an XML document in SQL Server environment. Since SQL Server cannot

40

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

Fig. 8. Top-level structure of XML DTD for BPTrigger.

store XML document directly, the XML documents are stored in relational format at database tables and recomposed for the manipulation or exchange. Fig. 10 shows the architecture of the prototype system for BPTrigger management. BPTriggers are defined on the basis of business process definitions. Defined BPTriggers are stored in BPTrigger repository for enforcement. When the user events such as activity initiation or completion are received, BPTrigger is activated and evaluated. The result action is then initiated according to evaluation result.

In this paper, the prototype for BPTrigger is built on top of ProcessWare, a business process management system, as its constraint management module to demonstrate the feasibility of the proposed architecture [21]. Fig. 11 shows a screen displaying the process to be executed. After the order is approved, the standard production order is generated. Before performing this activity, the BPTrigger for inventory level control, which is defined at precondition of production order generation activity, is activated. Fig. 12 shows a snapshot that is displaying evaluation of BPTrigger for the constraint introduced in

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

Fig. 9. XML representation of BPTrigger for the example inventory policy.

Fig. 10. Architecture of prototype system for BPTrigger management.

41

42

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

Fig. 11. A snapshot of selected business process.

Section 4.1. This figure shows that BPTrigger is evaluated as true. That is, the inventory level constraint is violated. Therefore, BPTrigger activated the emergency production order as an action. Fig. 13 shows that an emergency production order, which is not defined in the original order fulfillment process but is defined as a BPTrigger action, is activated by BPTrigger. 4.4. Performance comparison This section presents results of a performance comparison test performed using the prototype system

described in the previous section. The test was performed by comparing the elapsed time of a part of an example business process transaction in two cases: with a DB Trigger and with a BPTrigger. The test scheme is as follows. Orders from customers are assumed and the update operations on the order table are performed. Tests were performed using the data set in Oracle9i Database and MicroSoft1 SQL Server 2000, respectively. Therefore, the results of tests are applicable only to the Oracle9i and SQL Server environments. Furthermore, since the test application accesses DBMSs through an ODBC connection, there may be an inevitable overload caused by the ODBC

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

43

Fig. 12. A snapshot of example BPTrigger evaluation.

connection itself. For the transactions with the DB Trigger, the elapsed time is measured in such a way that the elapsed time required for the DB Trigger processing is measured excluding the updating operation. The DB Trigger has a simple notification as its action. For the transactions with BPTrigger, the elapsed time is measured from the point of the event arrival time to the time of the action notification time to a performer. To make the same measuring condition in the DB Trigger case, the relevant information for BPTrigger is retrieved from database tables at the point of BPTrigger evaluation time, not from the computer memory.

The benchmarking scenario is based on the inventory level constraint described in Section 1. Inventory LevelðNet Stockð¼ Current Stock  DamageÞ þ Projected Receipt to Inventory þ Outstanding Purchase OrderÞ must be greater  than or equal to Confirmed Order Quantity The test was designed to investigate the effects of increase in data and trigger quantity, and answer the following questions: How well is BPTrigger performing compared to the DB Trigger?

44

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

Fig. 13. A snapshot of activation of BPTrigger action.

How much is the performance affected when the data quantity is increased in the system? How much is the performance affected when the extra triggers are employed in the system at the same time? Is the performance of both triggers affected by indexing the key used in trigger query? The tests were designed with following factors: Triggers (DB Trigger, BPTrigger) DBMS (Oracle9i, SQL Server)

Data quantity (1000, 10,000, 100,000) Trigger quantity (10, 100, 1000) Indexing (Yes, No) Both the DB Trigger and BPTrigger are applied to the treatment of each combination of factors consisting of two levels of DBMS environment, three levels of data quantity, three levels of trigger quantity, and two levels of indexing. Therefore, there are 72 treatments: (DBMS(2)  Data quantity(3)  Trigger quantity(3)  Indexing(2)  Triggers(2) ¼ 72).

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

45

Table 3 Results of elapsed time (DBMS A) Data

Result (s) DB Trigger (no. of triggers)

1000 10000 100000

BPTrigger (no. of triggers)

10

100

1000

10

100

1000

0.048/0.029 0.181/0.054 6.5/0.8

0.27/0.095 1.0/0.097 95/1.2

2.2/1.37 9.0/1.38 1185/3.7

0.05110.032 0.052/0.032 0.1/0.08

0.051/0.032 0.052/0.033 0.3/0.1

0.052/0.033 0.052/0.035 0.3/0.2

Table 4 Results of elapsed time (DBMS B) Data

Result (s) DB Trigger (no. of triggers)

1000 10000 100000

BPTrigger (no. of triggers)

10

100

1000

10

100

1000

6/6 6/7 10/10

50/50 55/55 104/104

503/508 558/557 1032/1035

0.012/0.013 0.030/0.032 0.123/0.120

0.012/0.011 0.024/0.022 0.121/0.120

0.017/0.015 0.029/0.030 0.126/0.122

The tests were performed on two commercial DBMSs which will be represented as DBMS A and B. The primary measures of overall execution time in test DBMSs are summarized in Tables 3–5, respectively. Tables 3 and 4 represent the elapsed time required for trigger processing in the two DBMSs, respectively. The tables contain the seven columns: the column ‘Data’ for data quantity of order table in the DBMS, three columns—‘10’, ‘100’, ‘1000’ for the additional time for trigger processing after the updating operation with three levels of DB Triggers, and another three columns—‘10’, ‘100’, ‘1000’ for the additional time for trigger processing after the updating operation with three levels of BPTriggers. The unit

of measurement is second. The first number in each cell shows the elapsed time in trigger processing without indexing the key attribute, and the second number shows the elapsed time in trigger processing with indexing the key attribute. Considering that the elapsed time without indexing is not different from the elapsed time with indexing, the key attribute is assumed to be indexed by default in DBMS B. As expected, the test result shows that the elapsed time in DB Trigger case increases in proportion to the numbers of triggers and data quantity. The elapsed time in BPTrigger, however, is little affected by the numbers of triggers and data quantity. Table 5 shows a comparison matrix. The matrix contains seven columns:

Table 5 Results of performance comparison tests Data

Result (%) DBMS A (no. of triggers) 10

1000 10000 100000

6.25/0 71.2/0 98.4/90

DBMS B (no. of triggers)

100

1000

10

100

1000

81.1/66.3 94.8/66.0 99.7/91.7

97.6/97.6 99.4/99.4 99.9/94.6

99.8/99.78 99.5/99.54 98.7/98.88

99.97/99.97 99.95/99.96 99.88/99.88

99.99/99.99 99.99/99.99 99.98/99.98

46

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

column ‘Data’ for data quantity of order table in the DBMS, three columns—‘10’, ‘100’, ‘1000’ for the percentage of the reduction in the processing time of DB Triggers against the processing time of BPTriggers in DBMS A, and another three columns—‘10’, ‘100’, ‘1000’ for the percentage of the reduction in the processing time of DB Triggers against the processing time of BPTriggers in DBMS B. When the numbers of triggers and data quantity are small, the elapsed time of DB Triggers is not much different from the elapsed time of BPTriggers (see the case with 10 triggers and 1000 data quantity). That is, the performance of BPTriggers is not much affected by extra triggers and data quantity. The test result, however, shows that the reduction rate in elapsed time of DB Triggers against BPTriggers increases in proportion to the numbers of triggers and data quantity. That is, the performance of DB Triggers is critically affected by the presence of extra triggers or data quantity. Especially, when the number of DB Trigger is increased from 100 to 1000, the system performance deteriorated critically. In conclusion, the average execution time of the transactions with a BPTrigger is far less than that of the transactions with a DB Trigger. Therefore, the result suggests that BPTrigger can be used to implement a constraint enforcement system with a much lower overhead compared to typical DB Triggers (at least in the test DBMSs environment), as the numbers of data quantity and triggers are increased. 4.5. Termination issue of BPTrigger Termination of active databases and/or rule systems is an important research issue for which a number of papers have been published. Baralis and Widom [7] developed a general framework to provide static analysis techniques for predicting whether a given rule set, including both condition-action (CA) and eventcondition-action (ECA) active database rules, is guaranteed to terminate and whether rule execution is confluent (guaranteed to have a unique final state). They have shown how a propagation algorithm can be applied to check termination and confluence for sets of CA and ECA rules. Bonifati et al. [11] provided the properties of termination, confluence, and observable determination of a set of active rules in the XML context.

This section will shortly describe the research agenda that are being addressed related to the termination issue of BPTrigger [50]. Unlike database triggers that are defined on each data item stored in databases and checked every time the data item is updated, process-oriented BPTrigger is defined on a business process and checked before, after, or at a specific time of the process execution. The action of a BPTrigger, which is to be invoked when the condition is evaluated as true, is a process/activity that will compensate the process/activity or redo it. This characteristic of BPTrigger can bring in structural cycles which may cause non-termination. Several cycle types are identified which can be caused by BPTrigger deployment: iteration, compensation, complementation, rework, and exception handling [50]. While some cycle types may cause non-termination in the overall process execution, others do not actually cause nontermination (they are called ‘pseudo-cycles’). Therefore, dangerous cycles that can cause non-termination should be detected and treated adequately in advance. Using the concept of well-formed sphere proposed by Hagen and Alonso [32] to provide fault tolerant processes, cycles that exist in a process graph are classified whether they are dangerous or pseudo cycles. The well-formed sphere is a sub-process that consists of activities of compensatable, pivotal, and retriable types. It guarantees at least the termination of the business process (sub-process) whether performed successfully or not. When a cycle path is identified, the terminability of the path is evaluated by analyzing the types of activities in the path. When the cycle path does not guarantee termination, the activities in the cycle path can be adjusted to prevent non-termination.

5. Conclusions and future research Business processes and constraints associated with them are increasingly considered as important corporate assets that need to be managed independently from application programs. DB Triggers, designed to enforce integrity constraints related to data stored in databases, are not adequate for complex business constraints that must be applied to several business processes or activities involving many data items. Workflow management systems are mainly focused on constraints related to the control of processes such

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

as branching conditions among alternative successor processes/activities or process time constraints. Therefore, a new enforcement mechanism is required for business process constraints. This paper proposed BPTrigger as a new mechanism capable of representing and enforcing complex business process constraints in a distributed and heterogeneous environment. First, to provide comprehensive support, the paper identified all possible constraints related to business processes based on literature survey. Next, they were classified into four types: entry, exit, running, and invariant, according to the time of enforcement. BPTrigger is defined by extending ECA model from the business process perspective and provided its syntax. Unlike a DB Trigger that is invoked when the database system performs an update operation and simply aborts the update operation if the constraint is violated or sends a certain message, BPTrigger supports actions with different semantics such as invocation of business process activities for compensation, rework, or exception. For invariants that must be always satisfied and hence require a prohibitive cost to maintain them, this paper proposed an additional construct for definition of invariants. With this construct, invariants can be flexibly enforced by checking them only for the declared activities, instead of enforcing them all the time throughout the execution of the entire range of business processes. The definition of an invariant is translated to a BPTrigger for each declared activity and enforced as a regular BPTrigger. Finally, we described a prototype system for BPTrigger with an extended example that demonstrated how complex business process constraints can be effectively managed. For a performance comparison between a typical DB Trigger and a BPTrigger, a benchmarking test

47

was performed. The results of performance comparison tests suggested that the proposed approach outperforms a DB Trigger at least with respect to overall execution time in the given test environment. This approach can be applied to the business process oriented integration in distributed environment. That is, BPTrigger can provide the mechanism for modeling and enforcing the integration requirement constraints to support the integration or collaboration of distributed business process applications such as EAI. As an implementation issue, a full scale BPTrigger management system can be implemented with state-of-the-art technologies such as Web Services. Further research issues also include detection/prevention of conflicts among constraints stated as BPTriggers. Finally, the management of business process constraints at the process level, which is replacing the constraints management at the data level, can leave an inconsistency in database data. While this inconsistency can be partly adjusted as the result of BPTrigger actions, a more robust countermeasure needs to be supplemented to BPTrigger model to overcome this alienation between managements of process and data level. Further research issues include investigation of the possibility of cyclic BPTrigger references and detection/prevention of conflicts among constraints stated as BPTriggers.

Acknowledgements The authors would like to thank the Ministry of Education of Korea for its financial support toward the Electrical and Computer Engineering Division at POSTECH through its BK21 program.

48

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

Appendix A. The DTD of BPTrigger

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

Appendix A. (Continued ) [11]

[12]

[13]

[14]

[15]

References [1] W.M.P. van der Aalst, A. Kumar, XML based schema definition for support of inter-organizational workflow, Information Systems Research 14 (1) (2003) 23–46. [2] W.M.P. van der Aalst, H.M.W. Verbeek, A. Kumar, XRL/ Woflan: verification of an XML/Petri-net based language for inter-organizational workflows, in: Proceedings of the 6th Informs Conference on Information Systems and Technology (CIST-2001), Informs, Linthicum, MD, 2001, pp. 30–45. [3] W.M.P. van der Aalst, H.M.W. Verbeek, A. Kumar, Verification of XRL: an XML-based workflow language, in: Proceedings of the 6th International Conference on CSCW in Design, NRC Research Press, Ottawa, Canada, 2001, pp. 427–432. [4] W.M.P. van der Aalst, A.H.M. ter Hofstede, M. Weske, Business process management: a survey, in: International Conference on Business Process Management (BPM 2003), Springer-Verlag, Berlin, 2003, LNCS, 2678, pp. 1–12. [5] T. Andrews, et al., Specification: Business Process Execution Language for Web Services Version 1.1 http://www-106.ibm.com/developerworks/library/ws-bpel/, 2003. [6] A. Arkin, et al., Web Service Choreography Interface 1.0 http://www.sun.com/software/xml/developers/wsci/wsci-spec10.pdf, 2002. [7] E. Baralis, J. Widom, An algebraic approach to static analysis of active database rules, ACM Transactions on Database Systems 25 (3) (2000) 269–332. [8] J. Becker, M. zur Muehlen, M. Gille, Workflow application architectures, classification and characteristics of workflowbased information systems, in: L. Fischer (Ed.), Workflow Handbook 2002, Lighthouse Point, FL, 2002, pp. 39–50. [9] V. Benzaken, A. Doucet, Th’emis: a database programming language with integrity constraints, in: Proceedings of 4th International Workshop on Database Programming Languages, Springer WICS, 1993, pp. 243–262. [10] V. Benzaken, X. Schaefer, Ensuring efficiently the integrity of persistent object systems via abstract interpretation, in: S. Nettles, R. Connor (Eds.), 7th International Workshop on

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

49

Persistent Object Systems, Cape May, USA (MorganKaufmann), June 1996, pp. 72–88. A. Bonifati, S. Ceri, S. Paraboschi, Active rules for XML: a new paradigm for E-services, The VLDB Journal 10 (2001) 39–47. Business Rules (BR) Group, Defining Business Rules— What Are They Really? Final Report, revision 1.3, July 2000. http://www.businessrulesgroup.org/first_paper/BRGwhatisBR_3ed.pdf. F. Casati, P.S. Ceri, B. Pernici, G. Pozzi, Deriving active rules for workflow enactment, in: International Conference on Database and Expert System Applications, Zurich, Switzerland, 1996. S. Ceri, J. Widom, Deriving incremental production rules for deductive data, Information Systems 19 (6) (1994) 467–490. S. Ceri, G. Gottlob, L. Tanca, Logic Programming and Databases, Springer-Verlag, 1990. S. Ceri, R.J. Cochrane, J. Widom, Practical applications of triggers and constraints: successes and lingering issues, in: Proceedings of the 26th International Conference on Very Large Data Bases, Cairo, Egypt, September 2000, pp. 285– 296, Invited Paper. S. Chakravarthy, V. Krishnaprasad, Z. Tamizuddin, R.H. Badani, ECA rule integration into an OODBMS: architecture and implementation, in: P.S. Yu, A.L.P. Chen (Eds.), Proceedings of the 11th IEEE International Conference on Data Engineering (ICDE’95), Taipei, Taiwan, IEEE Computer Society Press, March 1995, pp. 341–348. S. Chawathe, H. Garcia-Molina, J. Widom, A toolkit for constraint management in heterogeneous information systems, in: S.Y.W. Su (Ed.), Proceedings of the IEEE International Conference on Data Engineering, 1996, pp. 56– 65. I. Choi, C. Park, C. Lee, Task-Net: transactional workflow model based on colored Petri Net, European Journal of Operational Research 136 (2002) 383–402. I. Choi, M. Song, C. Park, N. Park, An XML-based process definition language for integrated process management, Computers in Industry 50 (2003) 85–102. I. Choi, H. Jung, M. Song, Y.U. Ryu, IPM-EPDL: an XMLBased Executable Process Definition Language, Working Paper, Pohang University of Science and Technology, 2003. M. Cilia, C. Bornhovd, A.P. Buchmann, Moving active functionality from centralized to open distributed heterogeneous environments, in: Proceedings of the 6th International Conference on Cooperative Information Systems, LNCS, vol. 2172, Springer-Verlag, 2001. S. Conrad, M. Hoding, G. Saake, I. Schmitt, C. Turker, Schema integration with integrity constraints, in: C. Small, P. Douglas, R. Johnson, P. King, N. Martin (Eds.), Advances in Databases, 15th British National Conference on Databases, LNCS, vol. 1271, Springer-Verlag, 1997, pp. 200–214. O. Diaz, Driving rules for constraint maintenance in an object-oriented database, in: I.R.A.M. Tjoa (Ed.), Proceedings of the International Conference on Database and Expert Systems, Springer-Verlag, 1992, pp. 332–337.

50

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

[25] A. Doucet, S. Gancarski, C. Leon, M. Rukoz, Checking integrity constraints in multidatabase systems with nested transactions, in: Proceedings of 9th International Conference on Cooperative Information Systems (CoopIS 2001), LNCS, vol. 2172, Trento, Italy, Springer-Verlag, September 2001, pp. 5–7. [26] M. Gertz, U.W. Lipeck, Deriving integrity maintaining triggers from transition graphs, in: Proceedings of the 9th International Conference on Data Engineering, Rockville, MD, IEEE Computer Society Press, 1993. [27] P. Grefen, J. Widom, P.M.G. Apers, Integrity Control in Relational Database Systems—An Overview, Data and Knowledge Engineering, vol. 10, no. 2, North Holland, Elsevier, 1993, pp. 187–223. [28] P. Grefen, J. Widom, Integrity constraint checking in federated databases, in: Proceedings of the 1st International Conference on Cooperative Information Systems, Brussels, Belgium, June 1996, pp. 38–47. [29] B.N. Grosof, Y. Labrou, H.Y. Chan, A declarative approach to business rules in contracts: courteous logic programs in XML, in: Proceedings of the 1st ACM Conference on Electronic Commerce (EC’99), Denver, Colorado, ACM Press, November 1999. [30] S. Grufman, M. Samson, S.M. Embury, P.M.D. Gray, T. Risch, Distributing semantic constraints between heterogeneous databases, in: A. GrayandPer, A. Larson (Eds.), Proceedings of the 13th International Conference on Data Engineering, ICDE 1997, Birmingham UK, IEEE Computer Society, 7–11 April 1997, pp. 33–42. [31] A. Gupta, J. Widom, Local verification of global integrity constraints in distributed databases, in: P. Buneman, S. Jajodia (Eds.), Proceedings of the 1993 ACM SIGMOD International Conference on Management of Data, vol. 22 of ACM SIGMOD Record, Washington, DC, USA, ACM Press, pp. 49–58. [32] C. Hagen, G. Alonso, Exception handling in workflow management systems, IEEE Transactions on Software Engineering 26 (10) (2000) 943–958. [33] Intalio, The Process-Managed Enterprise, White Paper, http:// www.intalio.com, 2000. [34] S.E. Johansson, B.H. Kallak, T.B. Pettersen, J.E. Ressem, Expert workflow—building knowledge based workflow systems with object technology, ACM SIGPLAN, in: Proceedings of OOPSLA’97 (Addendum), ACM Press, 1997, pp. 45–49. [35] B.H. Kallak, T.B. Pettersen, J.E. Ressem, Object-oriented workflow management: intelligence, flexibility, and real support for business processes, Position paper for the OOPLA ‘98 Workshop on Implementation and Application of ObjectOriented Workflow Management Systems, Vancouver, Canada, 19 October 1998. [36] M. Kamath, K. Ramamritham, Correctness issues in workflow management, Distributed Systems Engineering 3 (1996) 213–221. [37] M. Kamath, K. Ramamritham, Failure handling and coordinated execution of concurrent workflows, in: Proceedings of 14th International Conference on Data Engineering, Orlando, Florida, February 1998.

[38] G. Kappel, B. Proll, S. Rausch-Schott, W. Retschizegger, TriGSflow active object oriented workflow management, Hawaii International Conference on System Science (HICSS’95), 1995. [39] G. Kappel, S. Rausch-Schott, W. Retschitzegger, Coordination in Workflow Management Systems—A Rule-Based Approach, LNCS, vol. 1364, Springer, 1998. [40] G. Kappel, W. Retschitzegger, The TriGS Active Object Oriented Database System—An Overview, ACM SIGMOD Record, vol. 27, no. 3. [41] N. Krishnakumar, A. Sheth, Managing heterogeneous multisystem tasks to support enterprise-wise operations, Distributed and Parallel Databases 3 (2) (1995) 155–186. [42] J. Lee, M. Grunninger, Y. Jin, T. Malone, A. Tate, G. Yost, and other members of the PIF Working Group, The PIF process interchange format and framework version 1.2, The Knowledge Engineering Review 13 (1) (1998) 91–120. [43] K. Lenz, A. Oberweis, modeling interorganizational workflows with XML nets, in: Proceedings of Hawaii International Conferences on System Sciences, Maui, Hawaii, 3–6 January 2001. [44] F. Leymann, D. Roller, Business Processes in a Web Services World—A Quick Review of BPEL4WS, http://www106 . ibm . com / developerworks / webservices / library / wsbpelwp/, August 2002. [45] J. Lubell, C. Schlenoff, Process representation using architectural forms: accentuating the positive, Proceedings of the Markup Technologies, ’99 Conference, Philadelphia, PA, December 1999. [46] C. Mohan, D. Agrawal, G. Alonso, A. Abbadi, R. Gunthor, M. Kamath, Exotica: a project on advanced transaction management and workflow systems, ACM SIGOIS Bulletin 16 (1) (1995) 19–26. [47] A. Motro, Integrity ¼ validity þ completeness, ACM Transactions on Database Systems 14 (2) (1989) 480–502. [48] M.C. Norrie, M. Wunderli, R. Montau, U. Leonhardt, W. Schaad, H.-J. Schek, Coordination approaches for CIM, in: Proceedings of the European Workshop on Integrated Manufacturing Systems Engineering, Grenoble, France, December 1994, pp. 223–232. [49] W. Obermair, W. Retschitzegger, A. Hirnschall, G. Kramler, G. Mosnik, The AOODB Workbench: An environment for the design of active object-oriented databases, Software Demonstration at the International Conference on Extending Database Technology (EDBT 2000), Konstanz, Germany, March 2000, pp. 21–27. [50] C.S. Park, I. Choi, Management of Business Process Constraints using a Process-Oriented Trigger Model, Working Paper, Pohang University of Science and Technology, 2003. [51] C. Schlenoff, M. Gruninger, F. Tissot, J. Valois, J. Lubell, J. Lee, The Process Specification Language (PSL) Overview and Version 1.0 Specification, NISTIR 6459, NIST, 1999. [52] T. Sheard, D. Stemple, Automatic verification of database transaction safety, ACM Transactions on Database Systems 14 (3) (1989) 322–368. [53] A.P. Sheth, M. Rusinkiewicz, G. Karabatis, Using Polytransactions to Manage Interdependent Data, in: A.K.

C. Park, I. Choi / Computers in Industry 55 (2004) 29–51

[54] [55] [56]

[57]

[58]

[59]

[60] [61] [62]

[63]

Elmagarmid (Ed.), Database Transaction Models for Advanced Applications, San Mateo, CA, Morgan Kaufmann Publishers, 1992, pp. 555–581. A.P. Sheth, Managing with Less than Absolute Integrity, IICIS, 1997, pp. 195–202. H. Smith, P. Fingar, The Business Process Management: The Third Wave, Meghan-Kiffer Press, 2003. S. Smith, D. Neal, L. Ferrara, F. Hauden, The Emergence of Business Process Management, CSC’s Research Services, 2002. M. Strassler, M. Schonhoff, Integrating engineering databases: how does the application domain influence the FDBMS architecture? in: Online-Proceedings of 3rd Workshop ‘‘Fo¨ derierte Datenbanken’’, Magdeburg, December 1998, pp. 101–119. S.D. Urban, M. Desiderio, CONTEXT: a CONstraint EXplanation tool, Data and Knowledge Engineering 8 (1992) 153–183. S.D. Urban, R. Nannapaneni, The implementation and evaluation of integrity maintenance rules in an objectoriented database, in: Proceedings of the 8th International Conference on Data Engineering, Phoenix, AZ, February 1992, pp. 565–572. J.B. Warmer, A.G. Kleppe, The Object Constraint Language—Precise Modeling with UML, Addison-Wesley, 1999. W. Weber, W. Stugky, J. Karzt, Integrity checking in database systems, Information Systems 8 (2) (1983) 125–136. M. Weiden, A Critique of the Pure Business-rule Approach, Department of Social Science Informatics, University of Amsterdam, 2000. WfMC, Interface1: Process Definition Interchange Process Model, WfMC Standards, WFMC-TC-1016-P, http:// www.wfmc.org, 1999.

51

[64] WfMC, Interoperability Wf-XML Binding, WfMC Standards, WFMC-TC-1023, http://www.wfmc.org, 2000. [65] WfMC, Workflow Process Definition Interface–XML Process Definition Language (XPDL), WfMC Standards, WFMC-TC-1025, http://www.wfmc.org, 2001. [66] D. Worah, A. Sheth, K. Kochut, J. Miller, An Error Handling Framework for ORBWork Workflow Enactment Service of METEOR, Technical Report, LSDIS Laboratory, Department of Computer Science, University of Georgia, July 1997. Chulsoon Park is with Industrial and Systems Engineering at Changwon National University. He received his PhD degree in industrial engineering from Pohang University of Science and Technology in 2003. His research interests include scheduling, workflow/business process management, and processcentric constraint management.

Injun Choi received the PhD degree in management information system from University of Texas at Austin in 1991. He is currently an associate professor in the Department of Industrial Engineering at the Pohang University of Science and Technology. His research interests include object-oriented modeling and reasoning, database system, workflow and business process management, and knowledge management.