chapter 11 transactional business processes

Process-Aware Information Systems. Edited by Dumas, van der Aalst, and ter Hofstede 257Copyright © 2005 John Wiley & Sons, Inc.

CHAPTER 11

Transactional Business Processes

GUSTAVO ALONSO

The other terror that scares us from self-trust is our consistency; a reverence for ourpast act or word, because the eyes of others have no other data for computing our orbitthan our past acts, and we are loath to disappoint them.

—Ralph Waldo Emerson

11.1 INTRODUCTION

Since its inception, the transaction concept has played a fundamental role in allforms of information systems. Business processes are no exception and it is not rareto find the term transactional attached to that of business processes. Unfortunately,there is quite a lot of confusion about what transactional means in this context. Thisconfusion that translates into a rather chaotic set of competing specifications and awide range of entirely different products that, at least in theory, should be solvingthe same set of problems. This chapter tries to offer a broader perspective on trans-actional processes. A perspective that goes beyond existing products and specifica-tions and tackles the essence of the problem and the range of available solutions. Toachieve this, we start by clarifying what transactional means when applied to busi-ness processes and what are the basic techniques needed to support transactionalprocesses. Keeping in mind that the transactional nature of many processes is adhoc and determined by the programmer, the chapter will also explain how a basicset of design primitives can be used to implement a variety of transactional con-structs.

The chapter opens with an overview of the notion of transactional consistency(Section 11.2), starting with the traditional view developed in the realm of databas-es and showing how this view applies outside the database domain. Next, Section11.3 explores the concept of atomicity, which is considered to be the transactionalproperty that is most applicable in the area of workflow and business process man-agement. Section 11.4 then describes specific realizations of this concept in thecontext of system development platforms and standardization initiatives. The chap-ter closes with an overview of trends (Sections 11.5). Exercises and assignment

c11.qxd 7/28/2005 9:27 AM Page 257

subjects are provided in Section 11.6. Most of these assignments require the readerto refer to external sources and put them in context with respect to the concepts in-troduced throughout this chapter.

11.2 TRANSACTIONAL CONSISTENCY

The notion of transactional consistency is typically captured by the acronym ACID(atomicity, consistency, isolation, and durability). These four properties cover allpossible aspects of transactional consistency. In practice, however, the ACID prop-erties have a meaning only within the context of a transaction model and there aremany such models in which some of these properties are ignored. Hence, whentalking about transactional consistency, we first need to clarify under what modelwe are operating and what properties are being enforced. The history of transaction-al support for different applications is not so much how each property is treated andimplemented within each model, but how each transactional model reflects thecharacteristics of the application.

11.2.1 The ACID Model

The best known and most widely used transaction model is the one used by data-base management systems to implement concurrency control, recovery, enforce-ment of constraint, and disaster recovery. This model is discussed in much detail innumerous textbooks [3, 11] so we will concentrate here on a few relevant aspects ofthis database transaction model.

The database transaction model is based on a closed-world assumption. It as-sumes, in the first place, that transactions can only exchange information by readingor writing to the database. In other words, all communication between transactionshappens under the control of the transaction engine. Moreover, transactions areseen as functions that take the database from one state to another. The database stateis defined as the values of all the relevant data items and system parameters of thedatabase; this state changes only as a result of the execution of transactions. Thecorrectness criteria and the properties enforced by the database transaction modelaim at guaranteeing that the states that are produced by the concurrent execution oftransactions are consistent. The model also defines what “to be consistent” actuallymeans.

In the database transaction model, the ACID properties can be formulated as fol-lows:

! Consistency guarantees that any transaction that (1) starts from a consistentstate, (2) executes by itself (no other concurrent transaction in the system), (3)is completely executed (the whole transaction is completed), and (4) executeswithout failures will produce a consistent state. Consistency in database en-gines is enforced through integrity constraints that check the values writtenby a transaction and will abort the transaction if any rules are violated.

258 ALONSO

c11.qxd 7/28/2005 9:27 AM 58

! Isolation guarantees that transactions will behave as if they were alone in thesystem, even when other transactions are being executed concurrently. Isola-tion allows running of transactions in parallel while still preserving consisten-cy. In abstract terms, the need for isolation can be explained in terms of con-sistency (i.e., a transaction must start from a consistent state). If we assumethat the database is in a consistent state, executing one transaction at a timeguarantees that the database remains consistent. If transactions are executedin parallel, a transaction may actually read an inconsistent state because it hasaccess to the intermediate result of a concurrent transaction. Note that theproperty of consistency guarantees that a transaction produces consistent re-sults if completely executed. It does not say anything about the state of thedatabase if the transaction is executed only halfway through. If a transactionreads the intermediate state of another transaction rather than a consistentstate of the database, the conditions for consistency are not met and that trans-action may actually leave the database in an inconsistent state. Isolation is en-forced through concurrency control mechanisms that enforce a particular or-dering in the execution of transactions.

! Atomicity is the property that makes sure transactions always leave the data-base in a consistent state. As the consistency property implies, this can onlyhappen if the transaction is executed in its entirety. Hence, atomicity guaran-tees that the transaction is either executed to completion (and, hence, leavesthe database in a consistent state) or not executed at all (and, hence, the data-base remains in the initial consistent state). Atomicity is enforced through re-covery mechanisms that undo transactions that need to be aborted (e.g., be-cause they violate integrity constraints or isolation rules, or because thetransaction could not be completed due to a database failure).

! Durability is a fuzzier property that, nevertheless, makes a lot of practicalsense. It can be interpreted in many different ways but, for most intents andpurposes, it can be seen as the guarantee that, if a transaction successfullycompletes its execution, the changes it has performed will not be lost. De-pending on what type of failures are considered, it can be far from trivial toenforce durability, as this might involve using backup systems, replicateddatabases, and so on.

For our purposes here, the important aspect of these properties is that, as theyhave been defined, they make sense only within the context of a conventional data-base engine. Once we are outside databases, many of the ideas built around theACID principles no longer apply.

11.2.2 Transactions Outside Databases

When we talk about transactional business processes, we are talking about a trans-actional model that is very different from the one found for database engines.Processes describe operations that are far more complex and varied than the opera-tions considered for the database engine. For instance, an activity within a process

TRANSACTIONAL BUSINESS PROCESSES 259

c11.qxd 7/28/2005 9:27 AM Page 259

may involve an entire transaction or even several transactions against a database. Inother cases, the activities may not involve transactions at all, but calls to operationssuch as sending or receiving messages, printing documents, or getting approvalfrom a manager for a particular business operation. As a result, most of the ACIDproperties are not considered in models of transactional processes.

In the context of process management, it does not make sense to assume that allcommunications among processes (or the activities of different processes) are underthe control of a single transaction engine or take place only through reading andwriting to a common database. Real business processes interact in many differentways, most, if not all, of them outside the control of the system that executed theprocesses. Hence, in general, isolation is not a good way to make sure things arecorrect in the context of processes. For one thing, we may not be able to isolateprocesses from each other. For another, often we do not even want to isolateprocesses from each other in the way transactions are isolated from each other.Hence, isolation is not a property that is considered in relation with models of trans-actional processes (although this does not mean that it never makes sense or that itis not possible to so [9]).

For the same reason, consistency is much less clear when processes are involved.Unlike database transactions, processes may terminate in many different ways, allof them correct. For transactions, consistency is enforced by the system through in-tegrity constraints, concurrency control, and recovery mechanisms, all of themidentical for all transactions and orthogonal to the transactions themselves. Forprocesses, consistency is typically the responsibility of the process itself. If aprocess does not reach a given point, then it must clean up whatever needs to becleaned up to make sure things are consistent (we will see later on in the chapterwhat this implies). In practice, that means that consistency is not a property en-forced by the system or a property of the model, but a characteristic that needs to beprogrammed by the process designer. Hence, although some of the concepts lookvery similar, the properties and behavior of the transactional process model andthose of the database transaction model are very different. As a result, models fortransactional processes do not consider consistency in the same way as databasetransactions. Consistency typically becomes a programmable feature rather than asystem property.

Finally, durability is even fuzzier in transactional processes than it is in databasetransactions. Typically, durability in the context of processes refers both to the per-sistence of the process execution (the ability to resume execution from the pointwhere it was interrupted after a failure) and the execution traces that are often re-quired for post-execution analysis and auditing (if necessary, it must be possible toreconstruct the steps taken by the process). Both aspects are very important in prac-tice but differ significantly from the notion of durability considered in databases. Aswith isolation and consistency, durability is also not part of most models of transac-tional processes.

In practice, the only property that is really relevant in the context of transaction-al processes is atomicity, although not for the same reasons as in the database trans-action model. Much of the rest of this chapter will be devoted to examining what

260 ALONSO

c11.qxd 7/28/2005 9:27 AM Page 260

atomicity means for transactional processes and how it is implemented in practice.But before we get there, it is important to understand how atomicity is implementedin general as, for better or for worse, these same ideas are the basis for implement-ing atomicity in transactional processes.

11.2.3 Atomicity in Database Transactions

Atomicity in the database transaction model has two sides. One affects transactionsexecuting in a single database and it is enforced using a variety of mechanisms thatcan undo the effects of a transaction at any given point in time. The other affectsdistributed transactions that involve more than one database. In the latter case, theinternal recovery mechanisms of each database are not enough, as the differentdatabases need to be coordinated to make sure that the transaction is executed in itsentirety in all databases or not at all in any of the databases. These two sides ofatomicity are similar to those used in transactional processes. In the first case (in-traprocess atomicity), the concepts are similar, although the mechanisms used toimplement them are very different. In the second case (interprocess atomicity), boththe concepts and the implementation mechanisms are almost identical.

Atomicity of a Transaction. Transaction recovery is a very complex problemthat is still not understood in its entirety. It is far less formalized than concurrencycontrol since it is highly dependent on the underlying implementation of the data-base. Yet, its basic concepts are relatively easy to understand. To make sure trans-actions are atomic in their execution, we need to make sure that the transaction canbe undone if something goes wrong. Isolation already guarantees that the transac-tion will see a database that will appear as if no other transaction would be runningat the same time. Hence, before the transaction modifies any data item in the data-base, we make a copy of that item. If the transaction successfully completes, thenthe new values that it has written are committed and we can forget about the old val-ues. If the transaction needs to be canceled, we restore the state of the database be-fore the transaction started making any changes by copying back the values of thedata items that were saved before each update took place. Once these values havebeen copied back, the database appears exactly as it was before the transaction wasexecuted (i.e., the transaction has not been executed at all). The huge advantage ofthe database model, particularly for relational databases, is that these recovery pro-cedures can be implemented independently of what the transaction does. That is, alltransactions follow the same recovery procedure independently of what they modi-fy in the database.

Atomicity of a Distributed Transaction. A distributed transaction is run onseveral databases. Within each database, recovery takes place as just discussed.However, each database cannot do recovery on its own. All of them need to agreewhether to commit or abort the transaction. For this purpose, an atomic commitmentprotocol is needed. The current standard protocol for this purpose is 2 Phase Com-mit (2PC). As the name implies, 2PC works in two phases. In the first phase, all


c11.qxd 7/28/2005 9:27 AM Page 261

participants (the databases where the transaction has run) agree on whether thetransaction is going to be committed or not. This is commonly done by having a co-ordinator requesting and collecting votes. If the coordinator sees that all partici-pants want to commit, then it enters the second phase and sends a message indicat-ing to the participants that they can go ahead and commit the transaction. Simple asit may seem, there are many details and subtleties behind 2PC and much work hasbeen done to understand the problem and come up with optimized solutions [11].Fortunately, these details are not that important for transactional processes so wewill just ignore them in the rest of the chapter and simply use 2PC to imply anatomic commitment protocol like the one just described.

11.3 ATOMICITY

The problem of how to make complex sequences of operations atomic, whether de-scribed as a process or not, has been addressed in many different ways. Most of thiswork was done in the context of advanced transaction models [5]. In general, how-ever, the vast majority of these ideas have never been used in real settings. In thissection, we cover the most relevant ones and discuss how they have been adapted tomodern process modeling languages.

11.3.1 Problem Description

Although the mechanisms used to maintain atomicity within a transactional processare conceptually identical to those used in database transactions, the practical imple-mentation is very different. To start with, it is very rare to be in situations in whichthe entire process must be atomic. Certainly, we want processes to terminate but wedo not necessarily want them to disappear without a trace if they do not succeed.

A simple example can be used to illustrate the differences with database transac-tions. In a database, the application semantics are ignored. That is, if the transactionencounters any problems, it is simply aborted. Typically, this is done by undoingany changes done by the transaction, a procedure that is done at a very low level(e.g., by replacing images of memory pages) and in a manner that is completely or-thogonal to the transaction. At the process level, things are very different. First, theprocess actually corresponds to the application that submits transactions. It is herewhere one must react to transactions that abort. It will not do to just kill the processand undo all partial results. Second, even in those cases in which the process mustterminate, termination cannot be implemented by undoing the whole process. In thevast majority of cases, the termination can only occur by taking additional steps aspart of the process. That is, atomicity is not guaranteed by a low-level mechanismorthogonal to the process but as part of the normal logic of the process. Consider,for instance, a purchase order process. The buyer can cancel the order at any timeby sending the appropriate message [see Chapter 9, patterns 19 (cancel activity) and20 (cancel case)]. If the cancel message is received, the process does not just abortand undo all its steps. Canceling the order involves, for example, creating new

262 ALONSO

c11.qxd 7/28/2005 9:27 AM Page 262

records that register the cancellation, may involve partial charges if the cancellationarrived late in the process, and requires sending additional cancellation notices tothose involved in the purchase (inventory control, production chain, billing, deliv-ery, etc.). In many cases, canceling the order might be as complex as the processingof the purchase order.

The main problem with transactional processes is that the mechanisms necessaryto implement atomicity, independently of the type of atomicity chosen, are neces-sarily programming mechanisms. Thus, the problem of intraprocess atomicityneeds to be solved by providing appropriate programming constructs for program-mers and process designers to incorporate the necessary transactional guaranteeswithin their processes. In what follows, we outline the most important program-ming concepts for intraprocess atomicity and how they are used in modern businessprocess modeling languages.

11.3.2 Compensation—Sagas

One of the earliest programming models for dealing with what we now call transac-tional processes is sagas [6]. In their simplest form, sagas assume a process whereeach step is an independent transaction (in the conventional database sense) that isexecuted sequentially or in parallel. In the case of a sequential saga, the executioncan be represented as the sequence

T1 T2 . . . Tn–1 Tn

Atomicity in the context of sagas is achieved through compensation. Sagas as-sume that for each step in the process there is a compensating action. That is, if theeffects of the step need to be undone, there is another compensating step that takescare of it. That is, for each step Ti in the normal process, there is a compensatingstep Ti

–1. The compensation can take many forms and sagas do not impose any par-ticular form of compensation. It can be a low-level compensation such as the mech-anisms used in databases, or it can be a high-level compensation based on the se-mantics of the step to be compensated. An example of the latter is a step that placesa purchase order by sending a particular document to an e-mail address; this stepthat can be compensated for by sending another e-mail to the same address cancel-ing the purchase order. The sending of the cancellation message is what constitutesthe compensating step.

Using sagas, a process designer can ensure the atomicity of a process by indicat-ing a compensating step for every normal step. If at a certain point the process needsto be undone, the compensating steps for all steps that have been completed are exe-cuted. The compensating steps are executed in the reverse order of the normal stepsto ensure that after the execution of every compensating step, the state of the processis semantically equivalent to having been executed only to that point. That is, to com-pensate for a saga that has been executed until step k, the execution has the sequence

T1 T2 . . . Tk Tk–1 . . . T2

–1 T1–1


c11.qxd 7/28/2005 9:27 AM Page 263

Conceptually, the main contribution of the saga concept to transactional process-es are the notion of compensation associated to each step and the undoing of aprocess by executing the compensating actions in the reverse order. Based on theseideas, many different combinations of this basic model can be derived. For instance,rather than associating with compensating step for every step, a compensating stepcould be associated to a group of steps. That is, the compensating step undoes not asingle step but a group of them. Another example are optimized compensation se-quences for Sagas with an arbitrary partial order between the steps. In general, theseextension add more flexibility to the use of compensation but do not alter the basicunderlying idea behind sagas.

For a programmer, designing a process as a saga facilitates implementing atom-icity by simply defining the compensating steps. The underlying execution enginecan then keep track of which steps have been executed and, if needed, trigger theexecution of the compensating steps in the proper order. This frees the programmerfrom having to extend the normal control flow with the compensating control flow.The main ideas behind sagas have been incorporated in many programming andspecification languages (see Chapter 5 on how UML allows designers to associatecompensations with single actions, or Chapter 13 on how compensation is treated inBPEL)

11.3.3 Alternatives—Semiatomicity

Sagas impose a rather rigid structure on the compensation; that is, either the processterminates successfully or it is compensated. This is due to the context in whichsagas were proposed—the model of atomicity mirrored that of classic databasetransactions. In long-lived business processes, it might make sense to be able toundo or roll back part of the process until a given point and then continue fromthere without compensating the entire process.

This basic idea is taken up by the notion of semiatomicity proposed for flexibletransactions [17]. The idea behind semiatomicity is to extend the basic model ofsagas with the possibility of providing alternative execution paths. That is, within aprocess, there might be different ways to proceed. If one of these options fails,whatever part of this alternative has already been completed is compensated for fol-lowing an approach identical to sagas. Then, an alternative execution path is select-ed. From a formal point of view, this model is based on differentiating betweenthree types of steps within a process: compensatable, pivotal, and retriable. A stepis compensatable if it has similar semantics to that in a saga; that is, there is a com-pensating step for it. A step is retriable if it is guaranteed to succeed if its executionis retried a sufficient number of times. A step is pivotal if it is neither compensat-able nor retriable. Based on these three elements, it is possible to construct process-es that provide a great deal of flexibility when dealing with failures. The basic rulethat needs to be observed is that the resulting combination of steps needs to be suchthat there is always the possibility of either compensating back to the beginning (asin sagas) or to finish the process by retrying steps. Without getting into the detailsof the formalism, this implies that once a pivot is executed, there must always be an

264 ALONSO

c11.qxd 7/28/2005 9:27 AM Page 264

execution path that ensures the process will terminate (i.e., a path of retriable steps).Similarly, before a pivot is executed, all steps must be compensatable since failureof the pivot implies having to roll back either to the beginning or to a previous alter-native path.

These ideas illustrate very well the advantages and disadvantages of advancedtransaction models. On the one hand, they apparently provide more flexibility andallow one to automate the navigation over the process by clearly indicating whatneeds to be done at each point in the execution. For instance, if a pivot fails, thenthe process needs to be compensated for back to the beginning as in a saga or up toan alternative execution path if any is available. If alternative execution paths areavailable, it is possible to assign priorities and automatically try each alternative inthe proper order until one succeeds. All this can be specified and then navigationproceeds automatically. On the other hand, the programming complexity increasessignificantly. The designer needs to identify steps as compensatable, retriable andpivotal, combine them accordingly, and establish alternative paths that lead to awell-formed process. Although automatic tools can be used to check the resultingstructure, it is the programmer’s responsibility to make sure the structure is correct.The problem in doing this is that it might be very difficult to cast the semantics of aprocess into a correct process structure. In addition, if the process involves stepsoutside the control of the process designer (e.g., services provided by other compa-nies), it might be impossible to determine the nature of these steps (whether they arecompensatable, retriable, or pivotal).

The main contribution of semiatomicity is the idea of using alternative execu-tions paths that can be followed after a given path fails. As with sagas, it is possibleto automate the selection of these alternatives, thereby greatly simplifying the de-sign of processes while having more sophisticated recovery and failure handling ca-pabilities. For a programmer, semiatomicity adds to the advantages of sagas thepossibility of compensating only parts of a process and of using alternative execu-tion paths to avoid having to discard work already done if something goes wrong ata later point in time.

11.3.4 Mapping to Workflow Processes

Although most advanced transaction models were developed independently ofworkflow management systems and process modeling languages, the close relationbetween them was shown long ago [7, 2]. In fact, the three key ideas discussedabove—compensation, undoing by reversing the sequence of execution with com-pensating steps, and alternative paths—can all be easily mapped to almost any formof workflow language. The mapping can be manual or automatic.

In case of manual mapping, it is the process designer who uses constructs in theprocess representation language to build a process that can recover from failures byimplementing either sagas, semiatomicity, or combinations thereof. In the case ofmanual mapping, the actual model used is not that relevant. The programmer is freeto combine many different possibilities. Because of this, the underlying infrastruc-ture and execution engine does not need to be aware of what the programmer in-


c11.qxd 7/28/2005 9:27 AM Page 265

tends to do. It just executes what has been specified without being aware of whethera given step is a normal step, a compensating step, an alternative path, and so on.

In the case of automatic mapping, the workflow system can offer one or moretransactional models and apply them to the process described by the programmerbased on certain rules. In practice, this is feasible only for simple models like sagas,in which, as indicated above, the programmer writes the process and gives compen-sation steps for each step in the process. Then the system can automatically undo aprocess by executing compensations in the reverse order of the forward steps. Formore complex models, automatic derivation of the compensation procedures is typ-ically not feasible. In addition, any given model restricts the freedom of the pro-grammer in terms of what can be expressed. Thus, automatic mapping is seldomused in practice and only for relatively simple, well-defined cases.

Using a very simple and schematic workflow model, it is possible to show howto implement sagas using standard programming constructs of workflow languages.The idea is to define steps and compensating steps as activities of the process andthen include the corresponding control flow based on whether forward activitiessuccessfully complete or o not. Figure 11.1 shows how this is done for the simplecase of linear sagas. Similar approaches can be taken to implement alternativepaths, compensation of subprocesses, and so on.

11.3.5 Atomicity in Process Modeling Languages

Over the years, the concepts discussed above have appeared and disappeared as partof a number of different systems and platforms (e.g., advanced transaction models,workflow systems, composition in object request brokers). As a result, these ideas

266 ALONSO

T1 T2

LINEAR SAGA

Tn. . .

T1 T2 T2

compT1

WORKFLOW PROCESS

success success

failure failure failure

success successcompTn

compT2

Figure 11.1 A linear saga mapped to a workflow process.

c11.qxd 7/28/2005 9:27 AM Page 266

have been assimilated by many developers and programmers and have crystallizedinto a number of basic primitives that can be found in many process modeling lan-guages. An example is BPEL (also discussed in this book), which contains specificconstructs to support these ideas.

In BPEL, the most relevant constructs for transactional purposes are the faultand compensation handlers, in addition to the standard primitives for implementingdifferent forms of control flow. The fault handlers are a set of steps within theprocess that will be executed if a failure occurs within a given scope (see Chapter13 for the definition of scope in BPEL and a detailed description of the types offaults considered in BPEL). Fault handlers are one way to implement alternatives incase there is a problem with a particular service or with a particular execution pathwithin the process. They are, however, not the only way to implement such func-tionality since similar effects can be achieved by using explicit control flow. Com-pensation handlers have similar semantics as in sagas and are executed if a particu-lar step or group of steps need to be compensated.

These programming primitives show how the notion of transactional behaviorwithin a process has become a matter of programming the necessary behavior ratherthan having automatic support. This makes perfect sense since there is no modelthat fits all possible types of business processes, not even a majority of them.Hence, today support for intraprocess atomicity means supporting the process de-signer in specifying how the process should behave when different events takeplace, for example, failures, exceptions, unsuccessful attempts to perform an opera-tion, and cancellations.

11.4 INFRASTRUCTURE FOR IMPLEMENTING ATOMICITY

11.4.1 Atomicity in the Context of Middleware

The notion of atomicity once outside the database revolves around 2PC and how tointegrate it with the applications running the transactions. A common simplifyingassumption made in textbooks about distributed transactions is that the transactionhas a single origin; for example, a program calls first one database, and then anoth-er, and so forth. In practice, this is not the always the case. In many architectureswhere databases are hidden behind higher-level interfaces, transactions are the re-sult of the execution of programs. Distributed transactions arise when a programthat itself runs one transaction on one database also calls up a second program thatthen runs another transaction on another database. In general, these two programsare aware that the other program also calls up a transaction.

This scenario is very common in business processes; in fact, more common thanthe one in which a single program calls several databases within a single transac-tion. The practical problem that it creates is, who will be in charge of coordinatingthe execution of the necessary 2PC protocol. The Object Transaction Service (OTS)of CORBA [8] is a good example of how this is done in practice. As shown in Fig-ure 11.2, assume that we have two applications, A and B, each one working on top


c11.qxd 7/28/2005 9:27 AM Page 267

of a different database. Application A starts executing and since it knows that it willrun transactions against its own database, it informs the OTS module that it wants tobegin a transaction (Figure 11.2, part 1). The OTS then assigns a transaction identi-fier and a context to that transaction so that application A can refer to the transac-tion and the OTS module can keep track of all the operations associated to thattransaction. After application A obtains the transactional context from the OTSmodule, it registers its database with the OTS module (Figure 11.2, part 2). In thisway, the OTS module knows where to go when running the 2PC protocol (as it is

268 ALONSO

DB APP A DB

ORB

Object TransactionService

DB APP A DB

ORB


DB APP A DB

ORB


DB APP A DB

ORB


DB APP A DB

ORB


DB APP A DB


DB APP A DB

ORB


DB APP A DB

ORB


APP B

APP B

APP B

APP B APP B

APP B

APP B

APP B

(5) register database

(2) register database

(7) commit transaction(3) execute transaction (no commit)

(4) call APP B

(1) begin transaction

ORB

(6) execute transaction (no commit)

(8) run 2PC

Figure 11.2 A transactional interaction in CORBA’s OTS.

c11.qxd 7/28/2005 9:27 AM Page 268

the database in charge of the atomicity of the transaction run by application A). Af-ter these two steps (obtaining the transactional context and registering the database)are completed, application A can execute its transaction against its database (Figure11.2, part 3).

Now, assume that application A also wants to call application B and it wants itstransaction and whatever B does to be an atomic operation (Figure 11.2, part 4). Letus assume that application A has already executed its transaction on its databaseand then calls B through whatever interface B makes available. When A calls B, itadds to the call the transactional context it got from the OTS. When B receives thecall, it realizes that it is being invoked within the context of a transaction. Since Bknows it will run another transaction in its own database, it will repeat the steps ofA. First, it will register its database with the OTS module, adding the transactionalcontext it got from A (Figure 11.2, part 5). That way, the OTS module knows thatthe transaction initiated by A has also ramifications in B and also gets from B theinformation on how to contact the corresponding database. Once this is done, B canrun its transaction against its database and return the results to A (Figure 11.2, part6). A will then want to finish the transaction and inform the OTS module that thetransaction should be committed (Figure 11.2, part 7). The OTS will then committhe transaction by running 2PC among the two databases involved in the exchange(Figure 11.2, part 8). In this case, the OTS module will act as the coordinator andthe two databases as the participants. Once the 2PC protocol terminates, the OTSmodule informs application A of the outcome.

This mechanism is not exclusive to CORBA. With small differences, it is usedessentially in all forms of middleware that support transactions and it illustratesvery well what is needed for maintaining atomicity of distributed transactions. First,we need a transactional context so that the different participants in the transactionknow on behalf of whom they are working. Second, there must be a registrationprocedure to tell the coordinator who will be in charge of running 2PC once thetransaction completes. Third, the participants must support an interface that allowsthem to run 2PC or a similar protocol under control of the coordinator. Fourth, weneed somebody who acts as the coordinator and can both assign transactional con-texts and run 2PC. As we will see in what follows, transactional processes use avery similar infrastructure to implement interprocess atomicity.

11.4.2 XA Interface

The XA interface specifies the interfaces necessary to implement the type of inter-action just described [15]. Although a process designer will typically not interactwith an XA interface, it is explained here since it constitutes the conceptual basis(and often the actual physical basis) for transactional specifications targeting busi-ness processes.

The model behind the XA interface is shown in Figure 11.3. It contains an appli-cation program, which is the program that decides to start and end a transaction us-ing the transaction manager (TM). The application program communicates with theresource managers (RM) (typically databases) to execute operations, but relies on the


c11.qxd 7/28/2005 9:27 AM Page 269

transaction manager for all aspects of transactional control. The XA interface defineshow the transaction manager and the resource managers communicate with each oth-er in order to enforce transactional consistency by running the 2PC protocol.

The most important services of the XA interface are shown in Table 11.1. Theinterface also contains additional features to deal with threads and other details thatare not relevant for the purposes of this chapter. The services shown in the tablecorrespond almost one to one with the ones described for the CORBA OTS: registerand unregister a resource manager with the transaction manager, start a transaction,running 2PC, and so on. This is not surprising since the CORBA OTS is designed towork precisely with resource managers that support the XA interface. The impor-tant aspect of this interface is that any resource manager supporting it can now par-ticipate in the execution of transactions that use the 2PC protocol (the XA interfacealso defines the different states of the entities involved, the order in which the oper-ations must be invoked, and so on).

11.4.3 WS-Coordination and WS-Transaction

For business processes operating over Web services, there is no direct way to usethe XA interface even if the systems involved support such an interface [1]. The

270 ALONSO

Resource

(RM)Manager

TransactionManager

(TM)

APPLICATION PROGRAM

Figure 11.3 The model behind the XA interface.

Table 11.1 Services within the XA interface

Name Description

ax reg Registers an RM with a TMax unreg Unregisters an RM with a TMxa open Initializes an RM for use by an applicationxa close Terminates the use of an RM by an applicationxa start Starts or resumes a transaction associating a transaction ID to itxa prepare Tells the RM to prepare to commit a transactionxa commit Tells the RM to commit a transactionxa rollback Tells the RM to roll back (abort) a transaction

c11.qxd 7/28/2005 9:27 AM Page 270

problem is that a Web service front end is needed for the the XA interface to be ableto operate using the mechanisms of Web service interactions (SOAP messages).Moreover, since business processes might be distributed across many companiesand might be long lived, using 2PC is not always a good idea.

Thus, in the context of Web services, the ideas behind the XA interface havebeen generalized to operate in that setting without changing the underlying princi-ples. This generalization involves two steps. The first one is related to the fact thatdistributed business processes like those used in electronic commerce cannot relyon a single transaction manager for executing 2PC or whatever protocol is used.The other step consists of modularizing the transactional protocol itself so that it isnot only 2PC that can be run (as it is the case with the XA interface). That way, ad-ditional protocols can be defined without having to change the infrastructure to runthem.

These two steps have been formalized in two specifications: WS-Coordination[12] for the task of the transaction manager, and WS-Transaction [13] for the trans-actional protocols. The WS-Transaction specification has recently been divided intoWS-Atomic Transaction and WS-Business Activity.

WS-Coordination defines a generic infrastructure for the coordination of termi-nation and commitment protocols between Web services (and by extension, be-tween the business processes running atop such Web services). Its main goal is toserve as a generic platform for implementing 2PC and variations of it. The behaviorof WS-Coordination is quite similar to that of an XA interface but adapted to Webservices. Figure 11.4 shows the structure of the coordinator described in the speci-fication. The activation service is a Web service that allows an application to createa context for a particular interaction. This is similar to obtaining a transaction ID


Activationservice

Registrationservice

Coordinationprotocol

B

Coordinationprotocol

A

COORDINATOR

. . .

Start a coordinationprotocol

Register for acoordination protocol

Operations ofcoordination protocol

Operations ofcoordination protocol

Figure 11.4 Structure of the coordinator in WS-Coordination.

c11.qxd 7/28/2005 9:27 AM Page 271

from the TM in the XA interface. In the case of Web services, the context is richerand includes information such as URL of the registration service of that coordinatorand the type of protocol being used. Once the application has obtained a context, itincludes the context in the header part of SOAP messages to other Web services. Asecond, remote Web service, upon receiving a request with a context attached to it,will ask for another context from its own coordinator. When it obtains that context,it passes information to its local registration service about the address of the regis-tration service of the invoking Web service. The registration services then talk toeach other to synchronize and set up the coordination protocol that has been chosen.This procedure is similar to the registration procedures in the XA interface exceptthat the registration services also need to agree on the protocol they will use and setup the addresses to use for the interactions, which will typically take place as Webservice operations. The second application can use the context it has obtained toforward it to other Web services and the procedure will be repeated again. In thisway, it is possible to link together several coordination protocols.

WS-Transaction is designed to use WS-Coordination as the underlying infra-structure. WS-Transaction specifies a set of coordination protocols that can be usedbetween Web services. The first of these protocols is now part of the WS-AtomicTransaction specification and it covers interactions similar to 2PC, very much in thesame way the XA interface implements 2PC. The other two protocols are part of theWS-Business Activity specification and includes the business agreement with par-ticipant completion protocol (a simplified form of commitment that supports can-celing and compensating), and the business agreement with coordinator completionprotocol (similar to the previous protocol but with an additional step in the protocolfor completing the work that resembles the tentative hold protocol discussed be-low).

11.4.4 WS-CAF (Web Services Composite Application Framework)

The area of transactional processes in Web services is still a very active arena inwhich many different groups are competing to dominate the standardizationprocess. WS-Coordination and WS-Transaction have been proposed by a set ofvendors, but an alternative, conceptually similar specification has been proposed byanother set of vendors. The Web Services Composite Application Framework (WS-CAF) comprises three specifications [14]:

! Web Service Context (WS-CTX). WS-CTX is the lowest-level specificationand covers basic elements like the generation of context information and thepropagation of this information as Web services invoke each other. The ideais that these basic elements and notions will be augmented and tailored by theother two specifications. As such, it supports interfaces that allow an applica-tion to create a context, define the demarcation points for an activity (e.g., fora transaction), register Web services so that they can participate in an activitywith the same context, and propagate the context as needed when invocationsare made.

272 ALONSO

c11.qxd 7/28/2005 9:27 AM Page 272

! Web Service Coordination Framework (WS-CF). WS-CF specifies a coor-dinator, similar to WS-Coordination, but it is built on top of the WS-CTXspecification. The main elements of WS-CF are a coordinator (which extendsthe notion of activity from WS-CTX to a set of set of tasks with a set of relat-ed coordination actions), a participant (including the operations involved inthe coordination process), and a coordination service (defining the behaviorof the coordination protocol; instances of the coordination service could be2PC, sagas, etc.)

! Web Service Transaction Management (WS-TXM). WS-TXM is used todefine concrete instances of the coordination service of WS-CF (i.e., indicat-ing how the coordinator and the participants must behave) and to augment thedistribution context of WS-CTX. Similarly to WS-transactions, WS-TXMprovides three different transaction models: ACID transactions (followingconventional 2PC), long-running actions (which include the possibility tocompensate), and business process transactions (which extend the notion ofcompensation to interactions based on business processes rather than individ-ual steps). The latter model is included to be able to deal with those processesin which compensation does not necessarily happen in an automatic mannerbut might involve off-line work to restore a consistent state.

WS-CAF explicitly recognizes the fact that there are two forms of transactionalinteractions that Web services need to support. One involves conventional middle-ware platforms and enterprise application integration efforts, in which transactionalbehavior is covered by 2PC and the mechanisms reflected by the XA interface. Theother one involves business processes in which 2PC is not the best way to imple-ment transactional behavior and the coordination procedures are more oriented to-ward compensation, either following the same model as sagas, semiatomicity, orcombinations thereof. WS-Transaction also makes this distinction but in a ratherimplicit manner. Nevertheless, it is not by accident that both specifications proposethree coordination protocols or services: one for 2PC-like interactions (presumablyfor systems based on the XA interface), one for compensation-based consistency(like sagas), and one for more flexible compensation approaches (like semiatomici-ty or programmer-defined models).

11.4.5 Tentative Hold Protocol

The Tentative Hold Protocol [10] is an interesting case and a contrast to the previ-ous proposals. The protocol addresses more semantic issues than low-level transac-tional mechanisms and, in fact, heavily depends on the nature of the process and theactual business process being adapted for this type of protocol. The main idea is toallow a nonbinding reservation for a particular item. This reservation is not bindingeither for the requester or the provider; that is, it can be revoked by sending a mes-sage notifying of the fact.

The advantage of the tentative hold protocol lies in allowing one to place a reser-vation on one or more items while a decision is being made. If the item becomes un-


c11.qxd 7/28/2005 9:27 AM Page 273

available, the provider sends a message indicating that this is the case and the re-quester can then proceed with other options. That way, both sides are informedabout the possible future use of that item but without having to block it until the de-cision is actually made. As an example of where this idea can be applied, consider acompany interested in receiving a set of offers for different components that will beused to build a single product. The company may want to obtain offers from differ-ent subsets of companies so that there are different combinations of price, quality,delivery dates, and so on, and then eventually decide on a particular combination.The Tentative Hold protocol allows the company in question to place tentativereservations for the different components with different providers without actuallycommitting to purchasing those components. That way, and unlike what happenswith conventional transactions, the items are not blocked while a decision is beingmade. If any of the providers changes the available offer, it notifies the company ofthe fact, which can then remove that offer from the current options. Once the com-pany decides on a given option, it notifies the providers that the components are nolonger on tentative hold.

The Tentative Hold protocol is not so much a protocol for guaranteeing transac-tional consistency but a practical approach to indicate that, later in time, a transac-tion may actually arrive that will request a particular item or resource. As such, itcan be used in combination with WS-CAF or WS-Coordination/WS-Transactions.First, interest in a given item is expressed using the Tentative Hold protocol andthen a transaction, run with any of the approaches described above, will actually re-quest the item in a binding manner. Notice, nevertheless, that the proposals in WS-Transactions (business agreement with completion) and WS-CAF (business processtransactions) can be used to implement processes with behavior very similar to thatproposed in the Tentative Hold protocol. The difference is that the Tentative Holdprotocol, if accepted as a standard, would then provide an accepted framework fortentative reservations. In WS-Transactions and WS-CAF, there is a possibility ofimplementing a similar behavior but not in a standard manner, as tentative holdswould be one of the many possibilities for such business agreements or businessprocess transactions.

11.4.6 Transactional Processes in Electronic Commerce

An often forgotten fact behind the notion of transactional business processes is thatthe type of transactional characteristics associated with the process depend verymuch on the programming abstractions used as part of the process. All the ideas andspecifications discussed address, almost exclusively, processes in which invoca-tions take place through RPC-like mechanisms (and that includes RMI, J2EE, andmost current Web services). Similarly, and as seen in WS-Transactions and WS-CAF, ideas like 2PC are still very much at the top of the list in terms of what itmeans to have a transactional business process. That has the big advantage that thenew specifications fit very well with existing infrastructures (like the XA interface,by now widely used by almost all forms of middleware). Yet, a problem that is be-coming increasingly obvious in practice is that business processes that involve re-

274 ALONSO

c11.qxd 7/28/2005 9:27 AM Page 274

mote systems—and not typical middleware or Enterprise Application Integrationscenarios—do not use this programming model. Most electronic commerce com-merce today is based on the interaction between business processes of differentcompanies through the exchange of documents [4]. In most cases, these exchangestake place through queues and using asynchronous messages. In such systems, thenotions of transaction, compensation, and coordination have a very different mean-ing. In many cases, it is not even clear how to apply transactional notions to puredocument exchanges.

Here, it is worth mentioning that some of the ideas developed in the context ofmessage-oriented middleware and persistent queuing [1] can be very useful. A per-sistent queue is a way of exchanging messages so that instead of going directlyfrom sender to receiver, they are deposited in a queue. That way, the sender and thereceiver are completely decoupled from each other as the sender only needs to putmessages in the queue and the receiver to read them from that queue. When the in-teraction is between business processes of different companies, the queuing systemtypically involves two queues. A sending queue is used to store the messages of thesender until they are successfully transmitted to the receiver. At the receiver side, aqueue is used to store all incoming messages until the application retrieves them. AsFigure 11.5 shows, these interactions can be made transactional by using simplifiedversions of 2PC, thereby ensuring that messages are not lost and that operationswithin each process can actually tie the processing of the messages to actual trans-actions.

In these systems, the notion of transactional process acquires a different meaningas the transactional parts are the interactions between the participants to ensure thereceipt of certain documents. These systems do not use transactional mechanismswithin the process itself to enforce consistency. Rather, consistency is part of theprocess logic itself, as the following example, taking from the xCBL library [16]shows:

The xCBL 4.0 ChangeOrder document is a buyer-initiated document that can be usedto change an existing Order already received and responded to by a seller. The docu-ment can be used to make changes to header level information, change line items, can-cel line items or entire orders, add line items, etc. Note that if an OrderResponse has


APP A APP B

output queue

2PC

input queue

2PC

2PC

Figure 11.5 Document exchanges using transactional queues.

c11.qxd 7/28/2005 9:27 AM Page 275

not been received for a given Order, a ChangeOrder is not necessary (an Order with apurpose of “Replace” should be used). Similarly, if an entire order is to be canceledand an OrderResponse has not been received an Order with a purpose of “Cancella-tion” can be used. However, if an OrderResponse has been received, a ChangeOrderwith a ChangeOrder/ChangeOrderHeader/ChangeType/ChangeTypeCoded = “Can-cel” should be used to cancel the entire Order.

The above paragraph describes a standard way of dealing with purchases ordersthat includes cancellation. It does not say what needs to be done at each end as partof the cancellation. In fact, it is possible that each process, for example, on the sell-er side, actually reacts to the arrival of such a message by using some sort of com-pensation mechanism such as those available in BPEL (although it is less thanstraightforward to express the logic above in BPEL). Yet, what is clear from thisdescription is that there is no coordination protocol between both sides. Cancella-tion or changes occur as part of the normal processing logic and not as part of aglobal transaction encompassing the processes of buyer and seller. An interestingproblem that will need to be clarified in the short and medium term is how to recon-cile specifications like WS-Transactions or WS-CAF (and the models behind them)with processes based on document exchanges like those being developed by xCBLor ebXML [4].

11.5 OUTLOOK

The notion of transactional business processes is anything but new and has been ap-plied in a wide variety of settings: advanced transaction models with more or lessconventional transactions, workflow systems, conventional middleware platformssuch as transaction processing monitors, modeling languages for processes basedon Web services, and so on. In this chapter, we have described the background formost of the ideas used today and discussed the relevance of each one of the existingsolutions.

The most important distinction made in the chapter is between mechanisms thatare used to guarantee the internal consistency of a given process (typically compen-sation), and mechanisms used to guarantee the consistency of several businessprocesses that interact with each other (using a variety of models, from 2PCto busi-ness transactions). The two aspects are not entirely independent but they should notbe confused, as they require and use different mechanisms. Internal consistency hastoday become a programming problem—how to help a programmer to expresscomplex recovery logic as part of a business process. This question is of vital im-portance since, as the xCBL example shows (Section 11.4.6), depending on themechanisms used, it may not be necessary to use distributed coordination protocols.Consistency between processes is today still seen as a problem largely similar tothat of transactional consistency using mechanisms like the XA interface. The intro-duction of other coordination possibilities is interesting and tied to the use of com-pensation as part of the process logic. Yet, it remains to be seen to what extent these

276 ALONSO

c11.qxd 7/28/2005 9:27 AM Page 276

advanced mechanisms will be used in practice and how they can be combined withinteractions such as document exchanges.

11.6 EXERCISES AND ASSIGNMENTS

1. Using the process representation format of your choice, describe the behaviorof a ChangeOrder document exchange such as the one described in Section11.4.6.

2. Read reference [2]. Using the process description language of your choice,describe how to implement sagas and other advanced transaction models us-ing that particular format. Is there any construct missing? Are there any pro-gramming primitives that would make the whole design easier?

3. Read reference [6]. Extend the ideas in that paper to sagas to allow (a) arbi-trary partial orders between the activities and (b) nesting of activities. Canyou represent the resulting mechanisms using a process modeling language?

4. Read reference [17]. Using the process description language of your choice,describe how to implement flexible transactions and other advanced transac-tion models using that particular format. Is there any construct missing? Arethere any programming primitives that would make the design easier?

5. Construct (using the process description language of your choice) twoprocesses, one corresponding to the buyer and one corresponding to the sell-er, that internally use compensation but communicate using the procedure de-scribed in the xCBL excerpt of Section 11.4.6.

6. Construct two processes, one for the buyer and one for the seller, that interactthrough direct invocations (e.g., RPC or Web service operations) and use theTentative Hold protocol to reserve a particular item before placing the finalorder.

ACKNOWLEDGMENTS

I would like to thank Claus Hagen, Amaia Lazcano, Win Bausch, Cesare Pautasso,Heiko Schuldt, Daniel Jönnsson and Biörn Biörnstad. All of them Ph.D. students atone time or another at the Department of Computer Science at ETH Zürich and whohave worked with me during the last years on topics related to those discussed inthis chapter.

REFERENCES

1. G. Alonso, F. Casati, H. Kuno, and V. Machiraju. Web Services: Concepts, Architec-tures and Applications. Springer-Verlag, 2003.

2. G. Alonso, D. Agrawal, A. El Abbadi, M. Kamath, R. Guenthoer, and C. Mohan. Ad-


c11.qxd 7/28/2005 9:27 AM Page 277

vanced Transaction Models in Workflow Contexts. In Proceedings of the 12th Interna-tional Conference on Data Engineering, New Orleans, LA, Feb. 26–March 1, 1996.

3. P. A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery inDatabase Systems. Addison-Wesley, Reading, MA, 1987.

4. ebXML Technical Architecture Specification v1.04. http://www.ebxml.org/specs/in-dex.htm.

5. A. K. Elmagarmid (Ed.). Transaction Models for Advanced Database Applications.Morgan Kaufmann, 1992.

6. H. Garcia Molina and K. Salem. Sagas. In Proceedings of ACM SIGMOD, May 1987,pp. 249–259.

7. F. Leymann. Supporting Business Transactions via Partial Backward Recovery in Work-flow Management Systems. In GI-Fachtagung Datenbanken in Buero Technik und Wis-senschaft—BTW’95. Dresden, Germany. March 1995.

8. Object Management Group. Transaction Service. http://www.omg.org/technology/docu-ments/formal/transaction service.htm.

9. H. Schuldt, G. Alonso, C. Beeri, and H.-J. Schek. Atomicity and Isolation for Transac-tional Processes. In ACM Transactions on Database Systems (TODS), Volume 27, No. 1,March 2002.

10. J. Roberts and K. Srinivasan. Tentative Hold Protocol. W3C Note 28 November 2001.http://www.w3.org/Submission/2001/11/.

11. G. Weikum and G. Vossen. Transactional Information Systems: Theory, Algorithms,and the Practice of Concurrency Control and Recovery. Morgan Kaufmann, 2001.

12. F. Cabrera et al. WS-Coordination. http://www-106.ibm.com/developerworks/library/ws-coor/.

13. F. Cabrera et al. WS-Transaction. http://www-106.ibm.com/developerworks/webser-vices/library/ws-transpec/.

14. Web Services Composite Application Framework (WS-CAF). OASIS WS-CAF Techni-cal Committee. http://www.arjuna.com/standards/ws-caf/.

15. Distributed Transaction Specification: The XA interface. The Open Group. http://www.opengroup.org/onlinepubs/009680699/toc.pdf.

16. XML Common Business Library (xCBL), version 4.0. http://www.xcbl.org/xcbl40/xcbl40.html.

17. A. Zang, M. Nodine, B. Bhargava, and O. Bukhres. Ensuring Relaxed Atomicity forFlexible Transactions in Multidatabase Systems. In Proceedings of the ACM SIGMODConference on Management of Data, Minneapolis MN, June 1994.

278 ALONSO

c11.qxd 7/28/2005 9:27 AM Page 278

chapter 11 transactional business processes

Documents