Towards a Framework for Capturing Transactional Requirements of Real Workflows

Transcription

1 Towards a Framework for Capturing Transactional Requirements of Real Workflows Dean Kuo CSIRO Mathematical and Information Sciences GPO Box 664 Canberra ACT 2601 Australia dean.kuo@csiro.au Alan Fekete School of Information Technologies University of Sydney, Sydney NSW 2006 Australia fekete@it.usyd.edu.au Paul Greenfield, Julian Jang CSIRO Mathematical and Information Sciences Locked Bag 17, North Ryde NSW 1670 Australia {paul.greenfield, julian.jang}@csiro.au Abstract One fundamental issue that has yet to be adequately addressed in loosely couple distributed systems is long duration transactions maintaining integrity of the system in the presense of both failures and concurrent activities for processes that last from seconds to years. This issue is of particular importance to both business to business integration (B2Bi) and enterprise application integration (EAI) applications such as e-procurement. Numerous transaction models have been proposed in the past to address this issue. They include transactions with ACID (Atomicity, Consistency, Isolation and Durability) properties designed for short duration transactions milli-seconds in duration compensation transactions and other advanced/extended transaction models. For varying reasons such as performances, expressiveness and appropriateness, existing transaction models do not meet general requirements for long duration transactions in loosely coupled distributed systems especially B2Bi and EAI applications. This paper is a position paper with two main objectives. First, we describe an application that is based on a real e- procurement scenario and discuss its transactional requirements. In the discussion, we highlight why some existing advanced/extended transaction model fail to provide adequate transactional support for this particular application. Second, we informally describe an expressive framework that captures, declaratively, the transactional requirements of long duration transaction. 1 Introduction Providing transactional support for long running processes (transactional workflows 1 ) in a loosely coupled distributed environment has yet to be adequately addressed. There is no shortage of advanced/extended transaction models (ATMs) [5, 14] that try to address this issue, and they have influenced transactional support provided by commercial workflow products such as Biztalk [11]. However, for various reasons, which are illustrated in this paper, ATMs often do not provide the required transactional support. A commonly used motivating example for many existing ATMs is booking a business trip hotel, car and airline reservations. However, the application does not require many transactional properties a business to business integration (B2Bi) and enterprise application integration (EAI) application requires. This paper describes a real e- procurement scenario, derived from one of our consultancies, and discusses its transactional requirements. The application gives us an insight as to why current ATMs often fail to provide adequate transactional support for B2Bi and EAI applications. 1 In this paper, we use the terms long running processes and workflows interchangeably.

2 The focus of our current research is not to propose yet another ATM. The objective is to develop a framework that captures, declaratively, an application s required transactional properties without prescribing the use of any particular ATM. We view existing ATMs as mechanisms that provide support for certain types of transactional properties. An ATM is thus only appropriate for a loosely coupled environment if it supports the transactional properties required by every workflow in the environment. Not surprisingly, no existing ATM provides the required transactional supported for B2Bi and EAI applications. Our approach is to first be able to capture, through the framework, the required transactional properties of a workflow without referring to mechanisms. We can then establish a classification scheme of different classes of transactional properties and for each class, possible mechanisms and architectures to provide the required transactional support (design patterns). Some of these mechanisms will come from existing transaction models e.g. compensation transactions, check-in and check-out while others will need to be developed. We envisage that there will be classes of properties where there are no feasible mechanisms to provide the required transactional properties for example, an application requiring degree 3 isolation but cannot block other applications from accessing the data. In this case, through the framework, we will be able to describe possible relaxation of the required properties such that mechanisms do exist. We also plan to extend existing workflow products such as Biztalk to support the framework so that a workflow programmer can easily and naturally specify the required transactional properties of a transactional workflow and manage its execution. The framework is thus central of our research. The rest of this paper is organised as follows. In Section 2, we describe an e-procurement workflow and its transactional requirements. Section 3 informally describes the framework we are developing and show how the framework captures the transactional requirements of the e- procurement application as well as ACID (Atomicity, Consistency, Isolation and Durability) transactions. Section 4 discusses related work and we focus the discussion on the appropriateness of existing ATMs in the context of the e- procurement workflow. It shows that for certain classes of transactional properties, existing transaction models provide appropriate support, while for others, the support is lacking. A conclusion and discussion of future plans are presented in Section 5. 2 An E-procurement Scenario This section describes a merchant s ordering transactional workflow, as well as briefly describing the workflows for reporting. The focus of the discussion is on transactional requirements. An e-procurement system will require the integration of numerous components such as Enterprise Resource Managers (ERPs), Customer Relationship Managers (CRMs), catalogues, supplier s ordering system, transportation booking systems, amongst others. Each of these components are implemented, maintained and managed independently. Also, the process typically will take days to months to complete. This is thus a good example of a long running transaction in a loosely coupled distributed system. 2.1 Ordering This section describes a merchant s ordering process and its required transactional properties. We define a workflow as a set of tasks where a task may be a primitive operation (e.g. an operation provided by a component) or another workflow (nested workflows). A workflow also defines a partial order in which the tasks are executed. The tasks in the ordering workflow for a merchant is shown in Figure 1 and the labels used reference tasks described below. Receive Quote Request (RQR): The first task in the workflow is receive a quote request and it creates a new instance of the workflow. Check Customer (CC): The merchant first checks that the customer is a valid customer. If the customer is a valid customer, then the ordering process proceeds; Otherwise, the workflow sends a notification to the customer (NC) and then the workflow is aborted. Calculate Quote (CQ): The merchant calculates the quote and it will depend on a number of factors such as discounts available to the customer, current specials, amongst others. Send Quote (SQ): The quote is then sent to the customer. Receive Purchase Order (RPO): If the customer proceeds with the order, a purchase order is received by the merchant. Warehouse Inventory (WI): The order is then placed in the warehouse s inventory system. The inventory system will return a date when the ordered products will be available from the warehouse. There may be insufficient stocks in the warehouse to fulfill the order or it may require stocks to be replenished in which case an order to the supplier may be triggered. Exactly when and what other products are ordered from the supplier will depend on how the merchant manages its logistics. 2

3 RQR CC Invalid NC Abort Valid CQ SQ RPO WI SI RP SR OC SOR SOC ETA Commit SG PD Figure 1. E-Procurement Workflow Order Confirmation (OC): An order confirmation is then sent to the customer. Shipping Order Request (SOR): A shipping order to a transportation company is sent. Shipping Order Confirmation (SOC): Shipping confirmation from the transportation company is received. Estimated Time of Arrival (ETA): An ETA for the ordered products is determined and sent to the customer. Fork: The workflow then forks into two concurrent set of tasks. One manages payment while the other shipping of goods. The payment process is: Send Invoice (SI): An invoice is sent to the customer. Receive Payment (RP): Payment is then received. Send Receipt (SR): A receipt is then sent to the customer. The shipping process is: Ship Goods (SG): Products are picked by the transportation company. Products Delivered (PD): The merchant receives notification that the products have been delivered. The e-procurement process then terminates. This workflow require transactional behaviour so that it will not be adversely affected by concurrent activities and failures. However, it does not require full ACID properties. It also needs other properties normally not viewed as transactional properties such as time constraints and liveness. Below, we describe isolation, failure atomicity, time constraints and liveness requirements for the e-procurement scenario. Isolation Examining the e-procurement workflow reveals numerous interesting isolation requirements. The discussion below highlights why existing ATMs are often inappropriate. 1. Constraints are satisfiable during periods of execution of a transactional workflow. This type of isolation requirement occurs twice in the workflow. The workflow ideally should only process orders from customers who are valid customers where a valid customer is one that has a registered account with no overdue payments. The workflow thus requires that there are no tasks from other workflows that changes the status of the customer from valid to invalid after the check customer task. Unless the merchant restricts each customer to having at most one active order at anytime thus each customer has no payment owing and therefore will not become an invalid customer it is impossible to provide this isolation requirement. Only allowing one active order is, in most cases, far too restrictive and bad for business. The practical solution is to relax the isolation requirements by specifying that customers only need to be valid at certain times during the ordering process and a customer check is performed 3

4 at those specified times. Processes now need to be defined to deal with customers becoming invalid during the ordering process. These processes may include the cancellation of an order, changing payment due dates so that customer is no longer invalid, and possibly others. An interesting observation is that serializability is not the required behaviour when payment due dates are revised. A similar isolation requirement is calculating quotes. Quotes are calculated on current prices. Ideally, prices don t change during the ordering process but this is not the case as the merchant and its suppliers can change its prices at any time. The standard solution to this isolation requirement is to make quotes only valid for a certain period of time (e.g. 7 days) and if the prices changes, the merchant bears the cost. The other approach is that a quote is only an indicative price and the invoice is calculated on delivery date. In this particular case, the practical solution depends on the business model. 2. Guarantee that a task will successfully execute at a particular time. If the warehouse inventory system accepts an order, it needs to guarantee that the products ordered will be available when transportation arrives. This is an isolation requirement as it says that there will be no other tasks from other transactional workflows that will remove the guarantee. A simple check of inventory levels is insufficient to guarantee availability of products due to other concurrent orders. This is a common problem and the typical solution is for the inventory to provide an operation that reserves products for a specific order. The operation has the property that it guarantees that the ordered products will be available at the required time and no other tasks/operations from other transactional workflows will adversely affect the guarantee. Performing tasks to guarantee some other tasks will successfully execute in the future is discussed in [13]. In this particular case, this technique provides the required transactional behaviour however, there are other similar situations where this solution is inappropriate. 3. Funds are available at the time of payment. Due to space limitation we are unable to describe the full details of a corresponding customer ordering workflow. The following interesting isolation requirement occurs in that workflow. In the workflow, the customer would first check it has the means to pay, by the due date, for the order before it would proceed with sending a purchase order to the merchant this does not mean that the funds are already available, it only means that by the time the customer has to pay for the order, there are funds. There are a number of methods to ensure payment can be fulfilled. One possibility is to reserve funds currently available. Another possibility is to reserve expected income. The first method is an isolation property while the second is a liveness 2 property as the workflow can only successfully execute if some task from another workflow happens. The examples above discusses a number of techniques to provide the required isolation requirements. Notice that none rely on two phase locking [8], as it is far too restrictive. Failure Atomicity We now describe failure atomicity requirements for the ordering workflow. In ACID transactions, failure atomicity states that if a transaction commits, then all the operations in the transaction happen while if the transaction aborts, then all the operations never happened. All or nothing is far too restrictive for the ordering workflow as illustrated by the following discussion. 1. There are operations that do not have to successfully execute for the process to terminate successfully. For example, sending the order confirmation and sending ETA information are optional. 2. Execute a task s alternative if the original task fails in its execution. There are multiple transportation companies that can transport the order to the customer. If one company can not deliver, then alternative companies can be used. Advanced/extended transaction models described in [5] and Biztalk already support alternatives/contingencies. 3. Aborting a transactional workflow. The most interesting failure atomicity requirement is, not surprisingly, deals with the cancellation of an order. When an instance of an order workflow aborts order is cancelled running compensators in reverse chronological order for each successfully executed task is not the required behaviour. The process to cancel an order depends on the status of the order when the cancellation is initiated. 2 Liveness is defined as something will eventually happen or in this case, happen before a specified time 4

5 (a) Not all tasks need to be undone for the transactional to terminate in the abort state. If transportation has not been organised, then cancelling the order is straightforward the order is just cancelled. The merchant may, however, charge the customer a cancellation fee. Notice, there is no need to compensate tasks such as sending quotes to a customer, calculating quotes or receiving a purchase order from a customer. Thus, in this case, all or nothing is not the required transactional property. (b) Compensators are not guaranteed to successfully execute. If the merchant has received a shipping order confirmation this implies that the shipping order was also successfully sent but the transportation has not arrived, then the shipping order needs to be cancelled (compensator for sending shipping order request) and if successful, the remainder of the cancellation process is similar to the case above. There is no guarantee that one can successfully cancel a shipping order since the truck may already be on its way. Thus, there needs to be another process that deals with the case where the compensator fails. The process may invoke another workflow or just send a notification to a human operator to deal with the cancellation. ATMs, such as ConTract [16] and Sagas [7], that rely on compensators make the assumption that they are guaranteed to successfully execute. In this case, the compensator to cancel a shipping order do not have this property. (c) Execution of a complex workflow required for aborts. If the order is cancelled and the products have already been shipped, then there are complex workflows that process return goods and the process includes checking for damages, gaining approval and sending credit notes to the customer. The cancellation process may fail for numerous reasons. In fact, the return goods process is more complex than the ordering process. Compensation is not applicable in this case and there is no guarantee that the cancellation will be successful. (d) The need to undo tasks may depend on external factors. Suppose a customer order has triggered off an order to a supplier to satisfy this order or to replenish stocks. If the customer order is then cancelled after an order to the supplier has been placed then should the order to the supplier also be cancelled? If we follow the all or nothing philosophy, then the supplier order should also be cancelled via a compensation transaction. But this is not the required behaviour. The decision to cancel or not to cancel will depend on a number of factors such as what other products were part of the same order, the number of other customers placing orders on this product, amongst others. The decision is outside the scope of transactions and is an issue addressed by how the merchant manages its logistics. An open question is what is the most appropriate mechanism to support this class of behaviour. 4. Corrective actions need to be taken when certain tasks fail. The transactional workflow does not just abort. In the workflow, suppose the wrong product was delivered or the product has been damaged. This does not lead to a cancellation of the order but corrective actions defined by business rules need to be taken for example, the received goods need to be returned to the supplier and the goods re-sent, the customer may also be compensated (monetary wise) for any inconveniences. Alternatives/contingencies in existing ATMs and in Biztalk are appropriate mechanisms to handle this type of failure atomicity requirements. 5. If compensators are used, a compensator for a task in one transactional workflow may not be the compensator for the same task in another transactional workflow. A merchant may allow customers to cancel orders for a fee. For one customer, cancelling an order may be an appropriate compensator to its send purchase order task. However, for other customers, this may not be an appropriate compensator since they can t afford the cancellation fee. The main point here is that a compensator for a task in one transactional workflow may not be a compensator for the same task in another transactional workflow. 6. Using statistical information to relax both isolation and failure atomicity. For some merchants, especially large organisations, the warehouse inventory system is often notified of all quotes sent to customers. Merchant s warehouse can then base orders to its suppliers based on historical and statistical information, and outstanding quotes for example, if the merchant knows that 80% of all quotes turn into purchase orders, then the merchant can place its orders accordingly. 5

6 In this case, the merchant does not need to undo any of its previous tasks to abort the workflow if the customer does not proceed with the order. Notice that isolation is relaxed as intermediate results from the order are visible to other workflows. The failure atomicity requirements described above show that all or nothing often does not apply to long running transactions. In addition, running compensators in reverse chronological order is also often neither appropriate or possible. Timed Constraints Time constraints are not included in the ACID properties as ACID transactions are assumed to be short in duration and lasts at most a few milli-seconds. However, long running transactions rely heavily on timed constraints. For example, quotes are only valid for a certain period, thus there is a time constraint between the completion of task send quote and receive purchase order. There are similar constraints for payment due dates and when the receipt are to be sent to the customer. Commercial workflow products such as Biztalk already support time constraints. Liveness In the customer s ordering workflow, the customer may reserve future income for payment of an order. This is a liveness property [10] and it is interesting that if the customer reserve future funds then it is a liveness property, while if the customer reserves existing funds, then it is an isolation property. We only realised that workflows required liveness properties while describing the transactional requirements of the e-procurement scenario. We don t know of any ATMs or commercial workflow products that currently support liveness properties. 2.2 Reporting Reporting for both the customer and merchant, at first glance, seem to require fairly basic transactional support since they only require read operations. However, on closer inspection, different types of report will require different transactional support. A course grained report such as the percentage of orders cancelled and percentage of order result in late payments do not require protection from other concurrent workflows as approximate figures are sufficient. However, other types of reports such as financial reporting would need to be protected from other concurrent executions that impacts on figures in the reports. 3 Framework The e-procurement scenario described in Section 2 illustrates that for certain types of transactional requirements, existing ATMs often do not provide adequate support. For example, there is no support for executing processes to abort an order after the order has been delivered to the customer. This section describes the framework informally. Its primary objective of the framework is to, declaratively, capture the transactional requirements of a workflow. It does not prescribe what mechanism should be used to support the required transactional properties. The design of the framework is significantly influenced by the fact that ACID transactions and ATMs are too restrictive to provide adequate transactional support for workflows. ACID transactions have four main properties. They are: Failure Atomicity: Either all operations within a transaction happen (successfully execute) or none happen (failed or did not execute). Advanced transaction models such as SAGA [7] and ConTract [16] rely on compensators to guarantee failure atomicity. However, writing a compensator t 1 for a task t is not trivial as compensators have to have the following properties. 1. The execution of t followed by t 1 is the identity that is, the effect is the same as if t never executed. 2. For all task t from other transactional workflows that could have executed after t, t 1 commutes with t. 3. t 1 is guaranteed to execute successfully. Thus, writing compensators require deep knowledge of the semantics of all the tasks in the system. Also it is not always possible to write compensators that are guaranteed to successfully execute. Isolation (Serialisability): Operations within a transaction operate as if there was no other transaction executing concurrently. That is, the execution of concurrent transactions is equivalent to a serial execution. Durability: If a transaction commits, its changes to the state of a resource manager (RM) survive failures. Consistency: A transaction takes a RM from one consistent state to another consistent state. As illustrated by the e-procurement scenario, both failure atomicity and isolation are far too restrictive for transactional workflows. A transactional workflow may require varying isolation levels within a transactional workflow 6

7 that is, the isolation requirements between some tasks in a transactional workflow may differ to others. The framework therefore needs to capture isolation requirements of a transactional workflow at the task level. Similarly, for failure atomicity. This then provides the required flexibility and expressiveness. The following section describes our framework informally followed by sections showing how the framework declaratively captures the e-procurement scenario s isolation, failure atomicity, time constraints and liveness requirements. In addition, we show how the framework captures the transactional properties of ACID transactions. Thus, we demonstrate that the framework can capture very weak to very strong transactional properties. 3.1 The Framework The framework is, conceptually, simple and its features are described below. A transactional workflow is composed of a set of partially ordered tasks that forms a directed graph where the nodes are tasks and the edges represent the order of execution. All terminating tasks nodes in the graph with 0 outgoing edges are either commit or abort tasks. A task in a transactional workflow may be a transactional workflow. That is, the framework supports nesting. Attached to each task, including the terminating tasks, is a set of preconditions. The preconditions capture isolation, time constraints and liveness requirements. Suppose task i, task j are tasks in a transactional workflow and task task i precedes the task task j. The precondition to task j could specify that there does not exist any instances of a particular task type between the execution of task task i and task j or a predicate is always true between the execution of the two tasks. As a concrete example, take the ordering workflow, if task i is the task that checks a customer s validity and task j is the commit task of the ordering workflow, the precondition could specify that there does not exist any other task between the execution of tasks task i and task j that makes the customer invalid. It should be noted that the approach taken follows a similar approach to the ConTract model s synchronization invariants [16]. However, the framework differs when capturing other types of transactional properties. Associated with each commit task is a set of commit and abort executions. Associated with each abort task is a set of abort executions. These sets of executions capture failure atomicity requirements. Failure atomicity in ACID states that either all operations in a transaction happens (successfully executes) or none happens (fail to execute). This is too restrictive as not all operations need to happen (respectively, not happen) in a transactional workflow for it to successfully (respectively, fail to) execute. The execution of any task either terminates in a success or fail state. The commit (respectively, abort) execution for a commit task defines which tasks in the transactional workflow must terminate in the success state for the transactional workflow to terminate in the success (respectively, fail) state. Similarly, for abort executions for abort tasks. The rationale behind a set of commit executions rather than a single execution is that there are more than one way a workflow can successfully execute for example, the use of optional and alternative/contigency tasks. Similarly, for abort executions. The tasks in an abort execution of a transactional workflow can be any task. This provides the required flexibility to specify the execution of complex business processes to abort a workflow for example, cancellation of order after the order has been shipped to the customer. In the following sections, we use this simple framework to specify the isolation, failure atomicity, time constraints and liveness properties of the order workflow and an application requiring ACID properties. The objective is to show that this framework can capture a range of transactional properties, from relaxed to strict. 3.2 Specifying Isolation Properties All isolation properties of a transactional workflow are captured in task s preconditions. Arbitrary executions and predicates can be specified in a precondition which provides the required flexibility. A simple litmus test for the framework is to specify degree 0, 1, 2 and 3 isolation levels [8] and the isolation properties discussed in the e-procurement scenario. 1. To model transactions, the only tasks (operations) are read, write and commit. To express degree 0 isolation, no preconditions are required for any of the tasks in the workflow since all inter-leavings between transactions are permitted. To express degree 1 isolation, we need to express that there are no lost updates. The precondition to the commit task would specify, for each write on a data item x, 7

8 there does not exist any other writes on x by another transaction until the commit. To express degree 2 isolation, we need to express the additional property, to degree 1, of no dirty reads. Each read operation would specify in its precondition that the read reads the last committed value the last committed value is defined as the value written by the last write operation with the property that the transaction that executed the write committed. Finally, to express degree 3 isolation, we need to express the additional property, to degree 2, of repeatable reads. The precondition to the commit task would specify, for each read on a data item x, there does not exist any other writes on x by another transaction until the commit. 2. The framework provides a natural way of specifying the isolation requirements for the merchant s order transactional workflow. To capture the isolation requirement that the workflow only process orders from valid customers, the precondition to the task commit would specify there are no other tasks, after the check customer task, that would make the customer invalid until the ordering process terminates. As discussed in Section 2.1, this isolation requirement is too restrictive and the practical solution is to relax isolation such that customers are only valid at certain stages of the ordering process. A task to check customer s validity is then required at various stages of the transactional workflow and no preconditions on the commit task is required. 3. To ensure products ordered are available for delivery, the preconditions to the task ship goods would specify that there are sufficient stocks available when transportation arrives. A similar precondition would capture the requirement in the customer workflow that there are sufficient funds available when payment is due. 3.3 Consistency and Durability Like consistency in ACID transactions, consistency for transactional workflow requires that a transactional workflow takes the state of the system from one consistent state to another consistent state. Consistency is defined by a set of integrity constraints. Durability for ACID transaction only require that changes to state survive failures. For transactional workflows, especially for long running ones, state changes made by each task need to survive failures. 3.4 Specifying Failure Atomicity Requirements We now show how the framework captures failure atomicity of ACID transactions all or nothing as well as the failure atomicity required by the e-procurement scenario. For ACID transactions, there is one commit task and its commit execution set contains exactly one execution. It specifies that all operations in the transactional workflow must successfully execute all has happened. The abort executions for the commit task specifies that each task in the transaction either 1. did not execute, or 2. executed but terminated in the failed state, or 3. successfully executed and its undo operation also successfully executed. That is, the net result is that nothing has really happened. The commit executions need no explanation but the abort execution set turns out to be more interesting, especially the last property. The undo operation for a read is the null operation while the undo to the write operation is an operation that restores the write operation s before image. Interestingly, to guarantee that the undo will successfully execute requires that there does not exist any other write operations between the initial write and its undo. Thus, failure atomicity is dependent on isolation being maintained. To specify optional tasks, such as sending ETA information, a commit task s commit executions would contain two classes of executions. One would specify that the ETA task happens while the other specifies it does not. Similar to the above case, alternatives are also specified by a commit s commit executions. One class of executions would specify a task happens while the other class specifies that the alternative task happens. The abort execution only defines which tasks need to terminate in the success state for the transactional workflow to terminate in the fail state. Suppose there are two transactional workflows twf 1, twf 2 and they both contain the task t. In twf 1, the abort execution specifies that either t does not happen or t and t both successfully execute. For twf 2, the abort execution specifies that either t does not happen or t and t both successfully execute. That is, the tasks t and t are compensation transactions for the task t. Notice, in our framework, we can specify different compensators for the same task t for different 8

9 transactional workflows. The e-procurement example highlights the need for this. As illustrated in Section 2.1, cancellation of an order may require the execution of a complex transactional workflow. Like the case above, one utilizes the abort executions to specify the transactional workflow(s) that need to be executed when orders are cancelled since the tasks in an abort execution can be an arbitrary task or transaction workflow. 3.5 Specifying Time Constraints Requirements A task s preconditions is also used to specify time constraints. The preconditions for a task task j could specify that the task task i was executed less than time t before task j. Time constraints in the e-procurement scenario can all be easily specified. 3.6 Specifying Liveness Properties The e-procurement example revealed one unexpected liveness property. The successful execution of a transactional workflow may depend on the successful execution of another transactional workflow. A task s precondition can capture liveness properties. In Section 3.2, isolation properties typically would specify that certain types of operations do not occur. For liveness, the precondition of a task would typically say that some operation would occur before a task executes. Using the e- procurement example, if the customer plans to pay for the order using expected income, then the precondition to the send payment task would be income has arrived. 4 Related Work The ACID transaction was identified as a key abstraction for maintaining consistency in on-line transaction processing domain [6]. In the 1980s a large number of other models were proposed, especially targeting other application domains such as Computer Aided Design. Many of these are collected in chapters in the book [5]. Of particular impact have been nested transactions [12], Sagas [7] and Split-transactions [3]. More recent transaction models include WorkMan [13]. Nested transactions allow concurrent activities which are within the scope of a transaction, and have ACID properties with respect to one another. In particular, failure of a sub-transaction causes that subtransaction to rollback, but does not necessarily force the stopping of the enclosing transaction. Sagas are sequences of ACID transactions, with the extra property that a failure anywhere during the sequence causes compensation activities to be issued for each completed transaction of the sequence (in reverse order). Split-transactions allow an activity to divide into separate threads, which are ACID with respect to each other and to all other transactions, but which share access to results of the pre-slit activity. In WorkMan, the basic idea is, for each task tk in a transactional workflow, a preliminary task for tk is executed so that when the transactional workflow needs to execute tk, it is guaranteed to successfully execute. Like WorkMan, the Tentative Hold Protocol [15] also execute preliminary tasks but they only tentatively reserve the required resources. The transactional workflow is notified when the resource becomes unavailable. Compensators may then be required to maintain consistency. Each of these transaction models might be appropriate for some workflows, but none is right for every type of workflow we have seen. A number of features from these models are now supported in commercial workflow products such as Microsoft s Biztalk [11], TIBCO s InConcert [2], IBM s Workflow [1]. They include compensation transactions, alternatives, timed transactions and nested transactions. However, they don t provide all the support required by the e- procurement example. There have also been some flexible models, or metamodels, which allow the system designer to determine one from a wide variety of possible transactional approaches. Each framework includes a way to describe the sequencing of activities, and a way to indicate how the isolation and failure atomicity are handled. A framework thus should be powerful enough for the designer to choose between sagas, nested transactions, or traditional ACID transactions, for the activity being controlled. As such these are the approaches most similar to our own. The ACTA framework [4] allows the designer to indicate dependencies between the start/commit/abort of different activities. Thus one could indicate that one activity is an alternative to another by having the later one s start depend on the earlier one s abort. ACTA also allows the designer to delegate elements of one activities access set to another activity (in effect, passing the locks around explicitly). The ConTract framework [16] also has dependencies between start/commit/abort events. As well, it allows the designer to specify state properties (invariants) which are to be true on entry or exit of an activity. Other related work include the CORBA Activity Service Framework [9]. It provides a general purpose event signalling mechanism that can prove useful when implementing transaction models. 5 Conclusion and Future Work This focus of this position paper was to first describe an e-procurement B2Bi and EAI application and its transactional requirements. The e-procurement application illus- 9

10 trated that ACID transactions and ATMs do not, for various reasons, provide all the required transactional support. The paper then informally describes a declarative framework that can capture the transactional requirements of a workflow without any bias towards a particular transaction model. The framework is highly expressive and is able to capture very weak to very strong transactional properties. The e-procurement scenario highlighted that all or nothing is too restrictive. Not all tasks in a transactional workflow need to happen for the transactional workflow to commit. Some tasks are optional while other tasks have alternatives defined. Also, not all tasks need to be compensated for a transactional workflow to abort and the same task used in different workflows may have different compensators. Finally, the abort of a transactional workflow may require the execution of complex business processes. Full isolation is also not required in the e-procurement example. Other properties, such as liveness and time constraints, that are not traditionally considered as transactional properties also featured in the e-procurement scenario. The proposed framework can capture all these types of properties declaratively. Future work obviously include the refinement and formalisation of this framework. We aim at completing another case study, preferably in some other domain, to show that the framework can capture transactional requirements for applications in loosely coupled distributed systems that is not just specific to a particular application domain. The framework will serve a number of purposes in our future transaction research. The framework will enable us to formally classify classes of transactional properties. For each class, we can then describe possible mechanisms and architectures that would provide the required transactional support. For certain classes of properties, new mechanisms may be required to provide the required transactional support. Finally, we plan to extend existing workflow products, such as Biztalk and/or other commercial off the shelf products, to support the framework. [6] K. Eswaren, J. Gray, R.Lorie, and I. Traiger. The Notion of Consistency and Predicate Locks in Databse Systems. Comm ACM, 19(11): , Nov [7] H. Garcia-Molina and K. Salem. Sagas. In Proceedings of the ACM SIGMOD, pages ACM Press, [8] J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann, [9] I. Houston, M. Little, I. Robinson, S. Shrivastava, and S. Wheater. The CORBA Activity Service Framework for Supporting Extended Transactions. In Middleware, IFIP/ACM International Conference on Distributed Systems Platforms, [10] N. Lynch. Distributed Algorithms. Morgan Kaufmann, [11] Microsoft. Microsoft BizTalk Framework 2.0: Document and Message Specification, December techinfo/framwork20.asp. [12] E. Moss. Nested Transactions: An Approach to Reliable Distributed Computing. Phd thesis, MIT, [13] J. Puustjärvi and H. Laine. WorkMan A Transactional Workflow Prototype. In Database and Expert Systems Applications, pages Springer, [14] K. Ramamritham and P. K. Chrysanthis. Executive Briefing: Advances in Concurrency Control And Transaction Processing. IEEE Computer Society, [15] J. Roberts and K.Srinvivasan. Tentative Hold Protocol Part1: White Paper. W3C Note, TR/tenthold-1/. [16] H. Wächter and A. Reuter. The ConTract Model. In A. K. Elmagarmid, editor, Database Transaction Models for Advanced Applications. Morgan Kaufmann, References [1] IBM Workflow. software/ts/mqseries/workflow/. [2] TIBCO InConcert. products/in_concert/. [3] G. E. K. C. Pu and N. Hutchinson. Split-Transactions for Open-Ended Activities. In 14th International Conference on Very Large Data Bases, pages Morgan Kaufman, [4] P. Crysanthis and K. Ramamritham. Synthesis of Extended Transaction Models Using ACTA. ACM Transactions on Database Systems, 19: , [5] A. Elmagarmid, editor. Database Transaction Models for Advanced Applications. Morgan Kaufmann,