failure handling in corbaflow: a corba-based ...lingtw/dasfaa_proceedings/...corba’s...

Failure Handling in CORBAflow: A CORBA-based Transactional Workflow Architecture

Casimir J. Crawley

Senior Project Engineer Delco Electronics Corporation

Omran Bukhres

Department of Computer Science Purdue University School of Science

Kokomo, Indiana Indianapdlis, Indiana

Abstract

55-ansactional workflows have been previously specified using commercially-available workflow management systems (WFMSs). WFMSs have facil- itated this specification by providing task coordination and execution capabilities. However, these current WFMSs have limitations in terms of heterogeneous distributed system integration, non-proprietary crass-platform support, and flexible ACID property support. A key weakness is their lack of recovey support which is a critical requirement for most WFMSs.

This paper makes two contributions towards workflow management systems. First, CORBAflow (a CORBA-based architecture for transactional workflow management) is presented. Second, a minor modification to CORBA’s Interface Definition Language (IDL) grammar is also presented. Through this modification compensating subtransactions in transactional workflows can be specified. A workfiow example using Saga transactions is then presented which illustrates transactional workflow specification. This research shows how compensating subtransactions can be combined with CORBA ‘s cross-platform support and heterogeneous system integration capability to resolve semantic failures in transactional workflows.

Keywords advanced transactions, transactional workflows, distributed databases, heterogeneity, CORBA, semantic failures, workflow transaction models

1 Introduction

Workflow management is an area of intense research in both academic and commercial circles. Businesses need to operate on a global scale in order to meet the competitive demands of the international marketplace. Companies have discovered workflow management as a

Proceedings of the Fifth International Confer-

ence on Database Systems for Advanced Appli- cations, Melbourne, Australia, April 1-4, 1997.

key technology for integrating and automating their enterprise-wide operations. The academic community has responded by investigating both traditional and non-traditional transaction management and applying its concepts to workflow management.

Workflows have been described as models of the business process [20] where a business process describes an enterprise’s business activities. Defin- ing a business process into a workflow specification is termed process modeling. The Workflow Man- agement Coalition was formed in 1993 with a key objective of standardizing these workflow specifications. This coalition defines the business process as era procedure where documents, information or tasks are passed between participants according to defined sets of rules to achieve, or contribute to, an overall business goal” [27]. Recently, the Workflow Management Coalition has also established a working group looking. into transactional workflows.

A workflow management system (WFMS) provides “the ability to specify, execute, report on, and dynamically control workflows involving multiple humans and HAD (heterogeneous, autonomous, distributed) systems” [13]. The Workflow Manage- ment Coalition defines a WFMS as “a system that completely defines, manages and executes workflows through the execution of software whose order of execution is driven by a computer representa- tion of the workflow logic” [27]. Currently, there are many commercially available WFMSs such as IBM’s FlowMark, DEC’s Objectflow, etc [13].

The current capabilities and limitations of commercial WFMSs were outlined in [13, 261. However, these current WFMSs have limitations in terms of heterogeneous distributed system integration and non-proprietary cross-platform support via application programming interfaces (API) or other protocols. Moreover, other weaknesses of current WFMSs include the limited support for consistency of concurrent workflows, lack of interoperability, availability, scalability, and lack of reliability support to handle the inevitable workflow failures [26]. These are essential requirements for workflows in large-scale multi-system applications executing

77

in HAD environments. In this paper, we take advantage of an emerging and maturing technology such as CORBA [22] to address some of these important requirements, namely, interoperability and failure handling. In this paper, a CORBA-based architecture for transactional workflow management, termed CORBAflow, is presented. A modification to CORBA’s Interface Definition Language (IDL) grammar to handle semantic failures in transactional workflows is also presented.

Figure 1 [14] characterizes workflows by plotting them on a graph with human-oriented workflow intervention versus system-oriented workflow intervention as dimensions.

Commercial Transaction Processing Systems

System-oriented

Figure 1: Workflow Characterization.

Workflows are categorized as computer supported cooperative work (CSCW), commercial workflow management systems, transactional workflows, or commercial transactional processing systems. CSCWs utilize computers but still rely on humans for task control and coordination as well as correctness and reliability. Commercial workflow management systems provide system- oriented task control and coordination but are still heavily dependent on human intervention for workflow correctness and reliability in the face of system aborts or task failures. Transactional workflows have system-oriented task control, task coordination, correctness, and reliability. This paper focuses on these transactional workflows. Commercial transactional processing systems fully support all ACID properties. Figure 1 shows that transactional workflows fit between commercial TP systems and commercial WFMSs. Transactional workflows combine the recovery and concurrency handling features of TP systems with the distributed task control and coordination features of WFMSs.

Organizations rely heavily on WFMSs for the implementation of their business processes. Therefore, the consistent and reliable execution of these processes has become very critical to the success of these organizations. This paper addresses two main deficiencies that

current WFMSs exhibit: first, they lack recovery mechanisms necessary for the inevitable workflow system or semantic failures; and second, they lack the ability to integrate heterogeneous autonomous systems prevalent in the commercial environment. The recovery features from advanced transaction models are transplanted into the CORBAAow architecture through the modification of CORBA’s Interface Definition Language (IDL) grammar in order to specify semantic failure handling. Since the architecture is CORBA-based, CORBAffow also integrates heterogeneous systems by using CORBA’s object-oriented, distributed, and open client-server architecture. As a result, CORBAflow overcomes two current WFMS limitations by simultaneously providing HAD system integration with reliable workflow specification.

The rest of the paper is organized as follows: Section 2 provides a short background on advanced transaction models. It also describes semantic failures and sagas. Section 3 presents the CORBA- flow architecture for transactional workflow management. It then identifies CORBA’s IDL limitations as a workflow language and proposes an IDL grammar modification which enables failure handling. Section 4 discusses related work and Section 5 concludes the paper.

2 Advanced Transaction Models

2.1 Discussion

The traditional transaction model fuly supports the atomicity, consistency, isolation, and durability (ACID) properties of conventional database management systems. This strict level of support severely hampers its usefulness in such advanced applications as multidatabase systems, WFMSs, and long-lived transaction systems [18]. As a consequence, advanced transaction models (ATMs) have been proposed in order to broaden the suitability of transactional concepts [Z, 181. ATMs have been categorized into extended transaction models and relaxed transaction models [251. Extended transaction models contain operations or subtransactions which form hierarchical structures within a given transaction. Two extended transaction examples are nested and multi-level transactions. Relaxed transaction models selectively relax the ACID properties of atomicity and isolation.

The direct implementation of ATMs into WFMSs has been found impractical since actual business workflows are far too complicated to be modeled solely by ATMs [26]. ATM features such as consistency, fault-tolerance, and recovery support have been used to solve problems in the database system domain [26]. Recovery features from Sagas and Flexible Transactions have been

78

transplanted into WFMSs in order to improve their reliability [3].

Multi-system transactional workjlows are applications which utilize ATM features in managing distributed tasks which are executed on heterogeneous systems [25]. ATM features have been incor- porated into commercial WFMSs [l, 21. A method of specifying workflows by adding intertask dependency specification to CORBA’s IDL was presented in [19]. This paper builds on the foundation of this previous research through the proposed CORBA- flow architecture and by further modifying IDL in order to accommodate relaxed transactional workflows.

2.2 Sagas

A saga is formally defined as follows [ 121: let Tr , Tz,

“‘> T, represent traditional subtransactions which fully support all ACID properties in saga T. Let Cl, c2, .‘., C,, represent compensating subtransactions which correspond to each Tr , Tz, . . . . T, traditional subtransaction. A system which implements the saga model must enforce either the execution sequence

Tl,Tz,...,Tn

which results in a committed acceptable termination state, or the execution sequence

for some 1 5 j < n which results in an aborted acceptable termination state. In summary, each subtransaction Tj has its corresponding Cj compensating subtransaction which semantically un- does any actions Tj executed and committed. The saga relaxes the atomicity of these long-lived transactions by allowing subtransaction access to shared resources even though each individual subtransaction fully supports the ACID properties.

We use a saga to demonstrate the proposed CORBAflow architecture’s ability to handle recovery from workflow semantic failures. The saga’s compensating subtransactions are a formal means of handling semantic failures and are specified using the proposed CORBAflow IDL. The modified IDL allows the proposed CORBAflow architecture to provide reliable workflow execution when failures occur.

2.3 Semantic Failures

There are two workflow failure mechanisms [3]. Since workflows typically execute in a distributed computing environment, the potential for system downtime exists at numerous locations. Task aborts resulting from system downtime are termed system failures. The other failure mechanism is termed semantic failure.

Semantic failures occur when a workflow can- not execute as specified because a task fails in the context of the business process. Examples include overdrawing money from a bank account or deliv- ering an out-of-stock item [3]. Semantic failure has also been described as an activity failure or exception with a negative (but not abnormal) termination of the business process [lo]. Authorized agent (human or computer) intervention which un- does previously committed tasks is also classified as semantic failure. If the workflow is inconsistent when a semantic failure occurs, then the workflow management system must bring the workflow to a consistent state. Failure handling may be accomplished through forward recovery with contingency tasks or backward recovery with compensating tasks [24, 121.

A workflow’s failure atomicity requirements could be specified through the definition of the workflow’s acceptable termination states [24]. An acceptable termination state can either be committed or aborted. These failure atomicity requirements describe how a failed workflow can be terminated in a semantically correct state. For instance, if a money withdrawal request in a bank workflow aborts due to an overdrawn account, the failure atomicity requirements may state that an acceptable termination state may be a committed money deposit request to the overdrawn account.

Recovery is a critical requirement for transactional workflows. The fulfillment of this requirement allows reliable workflow execution when failures occur. The proposed CORBAflow architecture is CORBA-based which provides an object- oriented means of capturing workflow failure atomicity requirements. The proposed CORBAflow IDL permits the specification of compensating or contingency tasks in transactional workflows. These tasks enable workflow recovery from semantic failures. This feature will be demonstrated through the specification of saga transactions.

3 CORBAflow

This section first reviews OMG’s CORBA architecture. It then discusses the proposed CORBAflow architecture for transactional and non-transactional workflow management which is based on CORBA. The CORBAflow architecture’s semantic failure handling features are demonstrated using its IDL for the specification of Saga transactions.

3.1 CORBA Overview

The OMG Reference Model provides the conceptual framework upon which all of CORBA is based. The following is a brief summary of the Reference Model as it directly pertains to

79

the proposed CORBAflow architecture. Further details can be found in [22].

l The Object Request Broker (ORB) processes requests and responses among clients and objects while isolating each entity’s implementation from one another.

l The Object Services or CORBAservices represents the set of generalized operations which are required for all object interaction. The proposed CORBAflow architecture uses the Relationship Service, Event Service, Concurrency Control Service, and Persistent Object Service. The Relationship Service provides relationship objects which describe and govern relationships among objects and role objects which describe and govern object behavior in a given relationship. Further details about other services can be found in

W - l The Common Facilities classifies WFMSs as

Task Management Common Facilities which provide work process object management and coordination [21]. The proposed CORBAflow architecture contains several Common Facili- ties entities which are described later.

l The Application Objects represents the set of vendor-specific objects required for a particular domain and are beyond the scope of OMG specifications.

Figure 2 [15] illustrates the structure of OMG’s Reference Model. The ORB is the middleman which provides access to the other three OMG elements. As previously mentioned, the ORB also provides the connectivity among clients and objects. Therefore, the ORB can be thought of as a common software bus among distributed objects, systems, applications, and any CORBA- provided services. This model specifies an open architecture which provides an object-oriented, cross-platform approach which can integrate a distributed environment.

Figure 2: OMG Reference Model Diagram

CORBA’s ORB interface is outlined in Figure 3 122). A client can choose either a static or dynamic interface to an Object Implementation. The object implementation provides server object semantics by defining object instance data and method code [22]. An Object Reference specifies an object within an ORB and provides an object implementation handle to a client which is valid only for the lifetime of the client. The Object Adapter is the primary ORB service provider to object implementations. The Object Adapter has been described as an object TP monitor [15] which performs such housekeeping duties as object instan- tiation, reference management, class registration, and client request routing. An interface for a given object implementation is defined prior to a client application’s compilation using CORBA’s IDL.

Figure 3: ORB Interface Diagram

The proposed CORBAflow architecture uses CORBA and CORBAservices as the foundation of its workflow management architecture. The proposed CORBAflow IDL provides a mechanism for the specification of workflow recovery from semantic failures. This feature gives the proposed CORBAflow architecture the ability to handle the inevitable failures that occur during the business process.

3.2 CORBAflow Architecture CORBA is an excellent candidate for transactional workflow implementation since it is intended as a distributed, cross-platform, object-oriented, and open architecture. An architecture with these attributes offers great potential for becoming a pervasive technology. Consequently, CORBAflow uses CORBA as its foundation as a workflow management system.

The necessary criteria for general purpose workflow systems has been identified [ll]. Advanced control mechanisms are required for the specification of task execution dependencies, data dependencies, and external constraints. These mechanisms insure controlled and correct workflow task execution given a workflow specification. System integration support is required for the integration of

HAD systems which are prevalent in workflow environments. The object model is another requirement since it provides the best method for capturing data integration and system behavior semantics. A transaction capability is also needed for the incor- poration of ATM features into WMFSs.

CORBAflow objects represent workflow tasks which are controlled by a WFMS through the specification of guards which enforce task dependency and external constraints [ll]. Tasks can have state [4] as well as data [7] dependencies. Task execution control flow is specified with state dependency relations or ptimitives [4]. The following lists three state dependency relations for task execution control flow:

occurrence [17, 41 ti + ti+l: If event ti occurs, then event ti+l must also occur. No order is implied between ti and t;+l.

precedence [17, 4, 281 ti + ti+l: If event ti and ti+l both occur, then ti must occur before ti+l.

ACTA inter-transaction dependencies Twelve different inter-transaction dependencies based on the BEGIN, COMMIT, and ABORT transaction primitives together with the occurrence and precedence state dependency relations are listed in [8]. These dependencies are part of the ACTA transaction framework or meta-model which can be used for the analysis and specification of ATMs. Although the list is not comprehensive, it can be used as a starting point in generating new dependencies for new ATMs.

Workflow management requires guards that enforce external constraints for single or multiple tasks. Time dependency is an external constraint which includes maximum execution time limit, minimum execution time limit, and valid execution time period [7]. Other external constraints include external resources such as dependencies between workflows or retry conditions.

The Relationship Service is a key element in the specification of a CORBAflow workflow. The Relationship Service models entities and relationships with five characteristics: 1. type, 2. role, 3. degree, 4. cardinality, and 5. relationship semantics [23]. The entity-relationship type classifies both entities and relationships and thus permits restric- tions among entities and relationships. The role describes entity behavior and represents an entity in a relationship. A given entity could perform different roles in different relationships. Degree specifies the required number of roles an entity must perform in a given relationship. Cardinality specifies the maximum number of relationships in which a given

role may participate. The relationship semantics are defined by a relationship object’s operations and attributes.

The Relationship Service builds on these characteristics by defining three service levels. The Base Relationships service or CosRelationships module provides the interfaces for fundamental relationship support among two or more entities. The Graphs of Related Objects service or CosGraphs module provides the interfaces for modeling entities and their relationships as graphs with nodes and edges. The Specific Relationships service defines the CosContainment and CosReference modules as two particular relationship interfaces which should be supported.

Figure 4 shows the elements of a CORBAflow workflow. Each Workflow Task Object represents a transactional task whose status is modeled by the object’s state. Each object is bound to the relationship by Role and Relationship Objects which are created by the invocation of the Relationship Service. The execution and data dependencies between workflow entities are embedded in these objects and thus the semantics of a transactional workflow are captured and enforced. It is this CORBAservice which gives CORBAflow its cross-platform, implementation- independent capability as a transactional WFMS architecture.

Figure 4: CORBAflow Workflow Elements

CORBAflow combines transactional task state primitives, inter-task control and data flow dependencies, and the CORBA architecture to provide a general purpose workflow management system with transactional capabilities. Transac- tional tasks are modeled as objects with their object interfaces specified in IDL. Transactional task primitives model a given object’s state and are defined as IDL operations to that object. Inter-task data flow is provided by IDL operation parameter passing between task objects. Inter- task control flow is provided by CORBAservices’ Relationship and Event Service. State dependency relationships are modeled as relationship objects in the Relationship Service. CORBAflow implements the occurrence, precedence, and ACTA inter- transaction dependencies as relationship objects. Transactional tasks are relationship entities whose transactional dependencies and constraints are modeled by role and relationship objects. CORBAflow thus builds on previous workflow

81

management research such as ACTA [8], ASSET [5], TriGSflow [16], and WIDL [19].

Figure 5 shows a BAD or Begin-on-Abort dependency relationship between two transactional tasks. The Begin-on-Abort dependency is used when modeling the Saga ATM with the ACTA framework [8]. The Transactional Task Object performs the transactional task ABORT role in the relationship. The Compensating Task performs the transactional task BEGIN role in the relationship. All role and relationship objects are accessed if they are adjacent to the currently accessed Workflow Task Object node. If the Transactional Task is in the ABORT state, then the Transactional Workflow Scheduler will schedule the Compensating Task for execution.

Figure 5: CORBAflow Transactional Workflow

The CORBAflow architecture is shown in Figure 6. The ORB provides the communication infrastructure among all objects or entities through an IDL interface. The CORBAflow Designer, CORBAflow Monitor, Transactional Workflow Scheduler, and Workflow Scheduler are all classified as Common Facilities since they have a horizontal application scope and serve a broad range of users [21]. The Persistent Object Service, Event Service, Relationship Service, and Concurrency Control Service are defined as CORBAservices [23] and are used by the proposed CORBAflow architecture for the object- oriented specification and execution of workflows. A CORBAflow workflow is the CORBA-based specification of a workflow using both CORBAflow Designer and the Relationship Service and may be transactional, non-transactional, or a combination of the two. The CORBAflow Traversal Object is also created with the Relationship Service and is used by the Transactional Workflow Scheduler or Workilow Scheduler for workflow execution.

CORBAflow Traversal Objects are created through the invocation of the Relationship Service by the Transactional Workflow Scheduler or the Workflow Scheduler. These objects manage the execution of a particular workflow. The two schedulers cooperate in the management of both transactional and non-transactional workflows. As previously mentioned, this paper focuses on transactional workflows. The details of how these two schedulers cooperate will be reported after the completion of the CORBAflow architecture implementation.

,______-__.-._.-.-...-., ;.--.....-.......-. --I

Figure 6: CORBAflow Architecture The CORBAflow Monitor checks and records

the entire state of the CORBAflow architecture. It accomplishes this task through the use of the Persistent Object Service and the Event Service. The Persistent Object Service provides data objects which log a workflow’s state and history. These persistent objects are crucial in the restoration of a workflow to a consistent state should failures occur. The Event Service provides notification throughout the CORBAflow architecture as Workflow Task Objects change state. The Concurrency Control Service manages the concurrent access of non-transactional data objects. The CORBAflow Designer provides a workflow designer with a graphical user interface for workflow specification.

It should be emphasized that CORBA is a specification, not an implementation. This characteristic isolates CORBA from any particular computing platform which in turn allows the architecture to function in heterogeneous environments. A table that lists several CORBA implementations can be found in [19].

The proposed CORBAflow architecture meets the requirements of object model and system integration support. Indeed, CORBAflow’s basic architecture is derived from the Object Management Group’s Object Model Architecture [22]. CORBAA ow supports system integration by incorporating the client-server paradigm which is focused on message passing between two objects. Examples of CORBA-based system integration can be found in [9] where both system interface and database schema integration were implemented. CORBAflow’s architecture provides the means of specifying recovery when failures or exceptions occur in the business process.

82

3.3 CORBAflow IDL CORBA lacks the advanced control mechanisms necessary for workflow support. The Interface Defi- nition Language IDL is focused on facilitating communications among clients and objects. The semantics of these communications must be inter- preted at a client level. As such, CORBA’s IDL lacks the expressiveness necessary to implement either transactional or non-transactional workflows [ll]. Consequently, CORBA’s IDL must be extended to support workflows. Miller, Sheth, et al., in [19] created the Workflow Interface Definition Language (WIDL) by proposing the “enabled by” clause addition to IDL. CORBAflow complements this work by further modifying CORBA’s IDL to specify recovery from workflow failures.

The “raises” expression lists all exceptions that might arise from the invocation of its accompanying method. IDL exceptions are data structures which may be returned to the client when an exceptional condition is encountered. OMG IDL grammar uses a syntax that is similar to Extended Backus-Naur Form (EBNF). The existing “raises” expression is as follows:

<raises-expr> ::= llraisest! 11 (11

<scoped-name> { ‘I, ‘I <scoped-name> )* “)‘I

where <scoped-name> is a previously defined exception. The modified IDL grammar proposed a simple extension for recovery specification:

<raises-expr> ::= “raises” )) (,,

<scoped-name> { ‘I, ” <scoped-name> 3* ")"

1 “raises” ‘I (‘I <scoped-name> ‘I ” ( ‘I[” <scoped-name> ‘I ,I’ <identifier> “1 ‘I )+ c “, I’ <scoped-name> ‘I, I’ { “[” <scoped-name> ‘I I’ <identifier> ‘I] I’ )+ 1; ‘I) I1

where the ” C” <scoped-name>, <ident if ier> “1 ‘I predicate identifies a task-state vector which is enabled by the exception <scoped-name>. <scoped-name> in the ‘I C” <scoped-name>, Cidentif ier> “I ” predicate must reference a previously defined interface name while <identifier> must reference a previously defined operation name within the scope of <scoped-name>% interface. Now if an exception is raised as the result of a corresponding operation invocation, a compensating subtransaction task is enabled.

An example is presented which will illustrate the modified expression’s implementation. This example is modified from the one outlined in [19]. The example is shown below:

struct Money-Transfer c long account-no; double money; long retries;

3; // Money Transfer

interface Withdrawal-Task : TTask c exception Overdrawn (

string<80> errmsg; 3 long Execute(in Money-Transfer

withdrawal) raises(Overdrawn,

[Deposit-Task, Execute], [Deposit-Task, Commit]) ;

long Abort (> ; long Commit (1;

1 // Withdrawal-Task

interface Deposit-Task : TTask I

long Execute(in Money-Transfer deposit) ;

long Abort 0 ; long Commit 0 ;

) // Deposit-Task

Asin[19],Withdrawal_TaskandDeposit,Task inherit an abstract base class named TTask. The structure Money-Transfer is an IDL constructed type which is used as the request parameter. The exception Overdrawn is raised when insufficient funds exist at the requested bank account. The task-state vectors [Deposit-Task, Execute] and [Deposit-Task,Commitl are enabled when Overdrawn is raised.

This is a simple example with two subtransactions which withdraw funds from two different banks. TI withdraws money from bank 1 and then T2 withdraws money from bank 2. The compensating subtransaction in this example is Cr which returns the withdrawn money to bank 1. The Overdrawn exception is raised when the bank 2 account is overdrawn. If this event occurs, the compensating subtransaction Deposit-Task’s task-state vectors [Deposit-Task, Execute] and [Deposit-Task, Commit1 are enabled. As a consequence, Deposit-Task returns the first withdrawal to bank 1. This example illustrates the backward recovery feature of the modified IDL.

83

This is a simple example with a contingency subtransaction which deposits funds into an overdrawn account. Tl withdraws money from a bank account and the contingency subtransaction Cl deposits money into the bank account if the account is overdrawn. The Overdrawn exception is raised when the bank account is overdrawn. If this event occurs, the contingency subtransaction Deposit-Task’s task-state vectors [Deposit-Task, Execute] and [Deposit-Task, Commit] are enabled. As a consequence, Deposit-Task deposits money into the overdrawn account. This example illustrates the forward recovery feature of the modified IDL.

4 Related Work Transactional workflows were discussed in [25]. This paper recognized the trend of exploiting advanced transactional concepts in applications which supported the control and coordination of heterogeneous tasks. However, problems with this trend were identified. One problem is that many advanced transaction models have constraints which may not apply in workflow environments. The paper recalled that advanced transaction models evolved from database management systems where the emphasis is on the maintenance of data consistency, not task coordination. It was also mentioned that candidate systems might not have the capabilities required for successfully implementation of these models. These issues were confirmed in later research [20, 131.

An abstract model of task behavior using a state transition diagram termed a task skeleton was presented in [25]. State diagram nodes represented externally visible task states while transition edges represented events that forced a given task from one state to another. This model was extended in [19] for the classification of transactional and non-transactional tasks. Transactional tasks were identified as minimally supporting the atomicity property and maximally supporting all ACID properties . The externally visible states in transactional tasks were termed initial, executing, aborted, and committed. This paper incorporates this task model by adopting the task-state vector concept as part of its modified IDL. The proposed work differs in that its modified IDL allows semantic failure handling.

Workflow management systems are classified as application-centric since its emphasis is on correct control and data flow enforcement [6]. Multidatabase transaction management was classified as data-centric since its emphasis is on controlling interleaved data operations for data dependency enforcement. This paper described workflow management viewing workflows as a set of independently executed transactions

with corresponding execution dependencies. Transaction management was described as viewing workflows as a single transaction. Task termination was categorized as semantic success (committed with a positive result), semantic failure (committed with a negative result), or abort (a system related failure). Forward recovery from semantic failures was accomplished by contingency tasks while backward recovery was accomplished by compensating tasks. This paper builds on these concepts by incorporating the specification of compensating and contingency tasks or subtransactions into CORBA’s IDL grammar.

The application of advanced transaction models into the FlowMark WFMS has been researched as part of IBM’s Exotica project [I]. Sagas and flexible transactions have been implemented in Flow- Mark in order to demonstrate how semantic failures could be handled in a workflow environment 13). Workflow performance issues such as availability, scalability, and reliability and their impact on workflow architectures were also explored. The CORBA-based architecture in this paper uses the replicated database and workflow server concepts from [l] for an optimum configuration. It differs in that its implementation is CORBA rather than FlowMark-based.

In summary, the work presented in this paper complements the previous research work on transactional workflows. It is hoped that the combination of CORBA’s flexibility with advanced transaction models’ discipline will create a workflow environment which will solve the apparent problems in current workflow management systems.

5 Conclusions The contribution of this paper is twofold. First, we propose a CORBAflow, a CORBA-based architecture that provides heterogeneous distributed system integration, non-proprietary cross-platform support, and flexible ACID property support. This is done through the use of the CORBA Common Facilities and CORBAservices. Second, we propose CORBAflow IDL which permits the specification of compensating or contingency tasks in transactional workflows. This is done through minimal changes to the grammar of the current CORBA IDL to implement forward recovery in transactional workflows. This feature gives the proposed CORBAflow architecture the ability to handle the inevitable failures that occur during the business process, A workflow example using compensating tasks is also presented which illustrates transactional workflow specification.

The research in this paper has revealed that CORBA has an opportunity to become the flexible glue which can bind distributed systems together.

84

CORBA’s IDL offers the correct level of abstrac- tion with its object-oriented architecture for heterogeneous system integration. It has been demonstrated in this paper and [19] that CORBA IDL needs only minor modifications for workflow applications. This characteristic is a tribute to its exten- sibility, scalability, and expressiveness. The proposed CORBAflow IDL augments WIDL so that when the two are combined a powerful means of specifying transactional workflows is created.

Since business processes require access to distributed information systems, WFMSs and information systems must interoperate. In addition, previously external isolated applications must also be integrated into the WFMS. Since common protocols must be utilized for the integration of this heterogeneous and distributed environment, an emerging and maturing technology such as OMG’s CORBA will become indispensable.

Workflow systems require an infrastructure for reliably capturing the states of business processes and tying together distributed applications and DBMS%. In general, advanced transactions models have been found to be the most natural choice for this infrastructure. As workflow systems scale to the enterprise level, the requirements on robustness, scalability, and distribution are linked to those required and developed in TP monitors and DBMS%. This system evolution will lead to the fusion of workflows with transactional concepts yielding transactional workflows as the final outcome.

The CORBAflow architecture in this paper provides a solid foundation for further research. We are currently working on the implementation of the CORBAflow architecture. We are planning to formalize the transactional workflows specifications in a CORBA-based environment.

References

PI

PI

G. Alonso, D. Agrawal, A. El Abbadi, M. Ka- math, R. Giinthiir and C. Mohan. Advanced transaction models in workflow contexts. In Proceedings of the 12th International Confer- ence on Data Engineering, New Orleans, LA, Feb. 1996. Also available as IBM Research Re- port RJ9970, IBM Almaden Research Center, July 1995.

G. Alonso, M. Kamath, A. El Abbadi, D. Agrawal, R. Giinthijr and C. Mohan. Ex- otica: A project on advanced transaction management and workflow systems. SlGOIS Bulletin (Special Issue on Business Process Management Systems: Concepts, Methods and Technology), Volume 16, Number 1, pages 45- 50, Aug. 1995.

[31

PI

PI

PI

PI

PI

PI

WI

Pll

PI

[131

G. Alonso, M. Kamath, D. Agrawal, A. El Abbadi, R. Giinthijr and C. Mohan. Failure handling in large scale workflow management systems. IBM Research Report RJ9913, IBM Almaden Research Center, Nov. 1994.

P. Attie, M. Singh, A. Sheth and M. Rusinkiewicz. Specifying and enforcing intertask dependencies. In Proceedings of the 19th VLDB, Dublin, Ireland, 1993.

A. Biliris, S. Dar, N. Gehani, H. Jagadish and K. Ramanrithman. ASSET: A system for supporting extended transactions. In Pro- ceedings of the ACM SIGMOD 1994 Inter- national Conference on Management of Data, Minneapolis, MN, pages 44-54, May 1994.

Y. Breitbart, A. Deacon, H.-J. Schek, A. Sheth and G. Weikum. Merging application- centric and data-centric approaches to support transaction-oriented multi-system workflows. SIGMOD Record, Volume 22, Number 3, Sept. 1993.

J. Chen. Interbase: A Systematic Approach to the Specification and Execution of Global fiansactions in Multidatabase Systems. Ph.D. thesis, Purdue University, Aug. 1993.

P. Chrysanthis and R. Ramamritham. ACTA: The SAGA continues. In A. Elmagarmid (editor), Database l%ansaction Models for Ad- vanced Applications, Chapter 10, pages 349- 397. Morgan Kaufmann, San Mateo, CA, 1992.

A. Dogac, C. Dengi, E. Kilic, G. Ozhan, F. Ozcan, S. Nural, C. Evrendilek, U. Halici, B. Arpinar, P. Koksal, N. Kesim and S. Man- cuhan. METU interoperable database system. SIGMOD Record, Volume 24, Number 3, Sept. 1995.

J. Eder and W. Liebhart. Workflow recovery. In Proceedings of the 1st IFCIS International Conference on Cooperative Information Sys- tems, Brussels, Belgium, Jun. 1996.

A. Forst, E. Kuhn and 0. Bukhres. Gen- eral purpose workflow languages. Distributed and Parallel Databases, Volume 3, Number 2, pages 187-218, Apr. 1995.

H. Garcia-Molina and K. Salem. Sagas. In Proceedings of the ACM Conference on Man- agement of Data, pages 249-259, May 1987.

D. Georgakopoulos, M. Hornick and A. Sheth. An overview of workflow management: From process modeling to workflow automation infrastructure. Distributed and Parallel

Databases, Volume 3, Number 2, pages 119- The Object Model, Interoperability, and Be- 153, Apr. 1995. yond, Chapter 29, pages 592-620. ACM Press,

[14] D. Georgakopoulus and M. Rusinkiewicz. New York, NY, 1995.

From transactions to transactional workflows. [25] A. Sheth and M. Rusinkiewicz. On trans- 12th International Conference on Data Engi- actional workflows. IEEE Data Engineering neering tutorial notes, New Orleans, LA, Feb. Bulletin, Volume 16, Number 2, pages 1-4, 1996. Jun. 1993.

[15] S. Helal and R. Elmasri. Open standards de- [26] D. Worah and A. Sheth. What do advanced velopments for database interoperability. 12th transaction models have to offer for workflows? International Conference on Data Engineering In Proceedings of the International Workshop tutorial notes, Feb. 1996. on Advanced Transaction Models and Archi-

[16] G. Kappel, P. Lang, S. Rausch-Schott and W. Retschitzegger. Workflow management based on objects, rules, and roles. Data Engineering pulletin (Special Issue on Infras- tructure for Business Process Management), Volume 18, Number 1, pages 11-18, Mar. 1995.

[17] J. Klein. Advanced rule driven transaction management. In Proceedings of the IEEE COMPCON, 1991.

[18] Y. Leu, J. Mullen and 0. Bukhres. Intro- duction to advanced transaction models. In A. Elmagarmid (editor), Database Thnsac- tion Models for Advanced Applications, Chap- ter 2, pages 33-52. Morgan Kaufmann, San Mateo, CA, 1992.

[19] J. Miller, A. Sheth, K. Kochut and X. Wang. CORBA-based run-time architectures for workflow management systems. Journal of Database Management, Special Issue on Mul- tidatabases, Volume 7, Number 1, pages 16-17, 1996.

[20] C. Mohan, G. Alonso, R. Giinthijr and M. Ka- math. Exotica: A research perspective on workflow management systems. Data En- gineering Bulletin (Special Issue on Infras- tructure for Business Process Management), Volume 18, Number 1, pages 19-26, Mar. 1995.

[21] Object Management Group. Common Facil- ities Architecture, revision 4.0 edition, Jan. 1995. OMG Document 95-l-2.

[22] Object Management Group. The Common Object Request Broker: Architecture and Spec- ification, revision 2.0 edition, Jul. 1995.

[23] Object Management Group. CORBAservices: Common Object Services Specification, up- dated edition, Mar. 1996.

[24] M. Rusinkiewicz and A. Sheth. Specification and execution of transactional workflows. In W. Kim (editor), Modern Database Systems:

tectures (ATMA), Goa, India, Aug. 1996.

[27] The Workfiow Management Coalition, Work- group 1 A. The Workflow Reference Model, Feb. 1995. Document No. WFMC-WGOl- 1000.

[28] A. Zhang, M. Nodine, B. Bhargava and 0. Bukhres. Ensuring relaxed atomicity for flexible transactions in multidatabase systems. In Proceedings of the 1994 SIGMOD Inter- national Conference on Management of Data, pages 67-78,1994.

86

failure handling in corbaflow: a corba-based ...lingtw/dasfaa_proceedings/...corba’s...

Documents