Towards a Methodology for Designing Compensation ... - CiteSeerX

Towards a Methodology for Designing Compensation Processes in Long-Running Business Transactions Hafedh Mili, Robert Godin, Guy Tremblay, and Walles Dorfeuille

Abstract— In short-lived transactions, database systems ensure atomicity by either committing all of the elements of the transaction, or canceling all of them in case of an error. With long-running processes, the notion of transaction takes on a different meaning, and it is no longer possible to rely on database managed transactions: we need so called compensation processes. Much like alternative paths in a use-case, compensation processes constitute the bulk of business process definition, and are error-prone. The purpose of this work is to lay the foundation for a methodology for designing compensation processes based on 1) a classification of business transactions in terms of an accounting ontology, and 2) a catalogue of compensation heuristics associated with these transactions. In this paper, we present the principles underlying our approach.

I. INTRODUCTION

M

any inter-organizational business processes are long-

running business transactions. If one step of the process fails, we need to abort the whole process, and to somehow cancel the effects of those steps that were already completed. In short-lived transactions, database systems ensure the atomicity of the transaction by either committing all of the elements of the transaction, or canceling all of them in case of an error. With long-running processes, it is no longer possible to rely on database managed transactions, and hence the concept of compensation: because we cannot erase all of the changes that took place since the beginning of the process, and pretend that nothing has happened, we have to provide a process that compensates for what has already happened. Designing compensation processes is a complex and errorprone process [1]. There are two aspects to the problem. One might be called a purely computational aspect, and deals with ways of compensating for a compound activity, given compensations for each of the elementary activities. The other This work was supported in part by the National Sciences and Engineering Research Council of Canada (NSERC) the Fonds Québécois de Recherche sur la Nature et les Technologies (FQRNT) Hafedh Mili, Robert Godin, and Guy Tremblay are professors of Computer Science with the Univsersité du Québec à Montréal (UQAM), Montréal, Québec, Canada, H3C 3P8. Walles Dorfeuille is a Master’s student at the same institution. All four are members of the Laboratory for Research on eCommerce Technologies (LATECE, www.latece.uqam.ca). They can all be reached at [email protected].

aspect is related to the business domain and has to do with the kind of compensations that would make sense from a business point of view. There has been some work on the computational aspect of compensation, including the saga approach [2], and a number of more or less formal languages for compensation (see e.g. [3-5]). However, to the best of our knowledge, there has been little or no work on the business aspects of compensation. The purpose of this work is to lay the foundation for a management model of compensation processes based on 1) a classification of business transactions in terms of an accounting ontology, and 2) a catalogue of compensation heuristics associated with these transactions. This model can also serve as a basis for the automatic generation of compensation code. The next section explains the concept of compensation and discusses the hypotheses of our work. Section 3 talks about compensation in the context of inter-organizational processes, and more specifically, BPEL4WS processes. In particular, we discuss BPEL4WS’s approach to compensation, and then explain the principles underlying our approach. Section 4 details our approach. In particular, we use an accounting ontology to characterize business processes in terms of the exchanges that take place, and those that need to be reversed through compensation. We illustrate how our methodology can be used to help in designing compensation processes for web services. We conclude in section 5. II. UNDERSTANDING COMPENSATION Consider, for example, an on-line banking application. Using such an application, customers are typically able to perform all sorts of transactions. A typical transaction consists of making a payment on the credit card balance by transferring money from the checking account. Money transfer means withdrawing money from one account and depositing it in another account. Back-office systems (DBMSs) ensure that the withdrawal and the deposit are considered as one atomic transaction, so that either both operations succeed, or the system is rolled back to the state where it was before the transaction started. To ensure that no other application access the source account half-way through the transfer, both accounts are locked during the transaction. This is the AI part of ACID (atomicity and isolation) In the case of a money transfer, this is not a problem since the deposit follows the withdrawal with no delay. However,

some business transactions can take hours, days, or weeks before completing, and locking all the data related to that one transaction is not an option. The saga approach [2] consists of breaking a long-running process into a set of short activities, each of which can be treated as a regular ACID transaction. If a process P consists of a sequence of activities A1; A2; …; An, each of which can be treated as an ACID transaction, and activity Ai, for 1 ≤ i ≤ n, failed, then the whole process should stop: regular rollback will take care of Ai, and we need to cancel the effect of the activities that happened before, i.e., of activities A1; A2;…; Ai-1, all of which are committed transactions, in reverse order. This is what is called compensation. Things get quickly more complicated because not all activities need reversing, and because we can have parallel activities. For a number of reasons, canceling the effect of a committed transaction does not simply mean undoing the changes that occurred to the permanent data store. Each one of those changes in the database may have triggered some human processes that are not controlled by the computer system, or not even by the enterprise altogether. Take the example of an order processing system. A simplified activity diagram is show in Figure 1. After taking the order from the customer, we launch two processes in parallel: 1) packing the order and getting it ready for delivery, and 2) performing a credit check on the customer. If the credit check succeeds, we deliver the package, and if it fails, we cancel the order altogether. PackOrder credit OK

ShipOrder

AcceptOrder credit not OK CreditCheck

CancelOrder

Fig.1. An order processing process. What does it mean to cancel the order in this case? It can mean several things, but minimally, it means: 1) undoing/opening the package and shelving its contents; 2) deleting the order or changing the value of one of its attributes to cancelled. Notice that nothing needs to be done with regard to the “check credit” activity as this activity didn’t change the state of the system. A bunch of other processes or activities may have to be undone as well. For example, assume that i) the company has a policy of keeping inventory between 20 and 40 units, ii) it had 30 units at the time that the order was received, iii) the order came for 20 units, and iv) the company has a policy of refilling its inventory whenever it goes below 20, to a level of 30. In this case, the acceptance of the order (first activity) would trigger a separate refill process for 20 units. That refill process will need to be cancelled if the order itself is cancelled. The company may also have tentatively scheduled a pick-up of the package by a shipper, and that pick-up will have to be cancelled too. The reader may wonder why we would want to perform order packing and credit check simultaneously instead of

sequentially, knowing that in case of failure of credit check, we have to undo a bunch of stuff. There could be valid business reasons for that. If the company’s competitive advantage is on delivery speed, and if the overwhelming majority of credit checks succeed, then the gained efficiency can justify the additional costs in case of failure. The implications of the cancellations can be far reaching and affect unsuspected parts of the system. Assume that we have a reporting application that is run regularly (say daily, weekly or monthly), and assume that the deadline hits sometime between the acceptation of the order and the completion of the credit check. When we run the sales report, it will show a sale of 20 units of our product; however, that sale never completed. If we simply delete the purchase order, there will be no trace left of the cancellation, and no justification of packing and unpacking of products, which costs labor and materials (boxes) that need to be accounted for. For the purposes of our reporting application, we can decide to use a status attribute, and only report on those purchases that have been marked as “completed”. It would solve our current problem, but we would have a similar problem in case of product returns. The implications of having the wrong sales of course can be far-reaching as well. Depending on the end of the financial year, because income tax depends on revenue, any re-evaluation of the revenue will either be incorporated in the next year’s results, or lead to the filing of a corrective report, with the corresponding interest and/or penalty payments. Finally, should we consider product returns as cancellations of purchase processes or as separate processes? Are there any objective criteria that would tell us which way to go? This simple example illustrates two important points about compensation: 1) a compensation is far more involved than an undo, and can involve several actions, some of which may be beyond the computer system’s control; 2) choosing how to compensate for an action is a business decision. While the choice of a compensation mechanism is a business decision, that decision follows some rationale. We argue that that rationale is a combination of two factors: 1) some general business policy which can be understood in terms of widely agreed upon management or accounting rules, and 2) a company or organization-specific implementation or adaptation of that policy based on some considerations. For example, counting only completed sales for inventory management, revenue and tax reporting is only natural. How we do that counting for a given reporting period is left to specific organizations: “optimistic” organizations may decide to count non-completed sales, and retract them later if they fail to complete, while “conservative” organizations may decide not to count non-completed sales in the current reporting period. In fact, some jurisdictions allow cash flow-based revenue reporting while others use actual expenses incurred and revenues generated, even if the accounts are to be paid or

received in the subsequent reporting period. Etc. We conjecture that there are a limited number of such policies that govern the wide range of business processes, and that 1) the process designer is faced with fewer choices than one may be led to believe, and 2) those choices can be explained in terms of high-level business decisions, as opposed to obscure, low-level implementation decisions. III. COMPENSATION IN INTER-ORGANIZATIONAL PROCESSES WITH BPEL4WS Formal business process modeling languages recognize the importance of compensation in the specification of business processes [6]. Both the Business Process Modeling Language (BPML, [7]), proposed by the Business Process Management Institute (BPMI), and the Business Process Executable Language for Web Services (BPEL4WS, [8]), proposed by important IT organizations (IBM, Microsoft, SAP, Siebel Systems) and becoming the de facto standard for specifying executable business processes, include a construct for specifying compensations. BPEL4WS is interesting for many reasons. First, while both BPML and BPEL4WS are XMLbased, BPEL4WS is aimed at the expression of business processes as compositions of web services specified using the WSDL standard. This makes it an appropriate language for specifying and executing inter-organizational business processes that compose the (web) services of the individual organizations. In fact, BPEL4WS interpreters exist that can execute so-described processes. Finally, an ultimate goal of our research is to provide BPEL4WS “programmers” with help in specifying their compensation processes. In this section, we first introduce BPEL4WS and its compensation mechanism. Next, we discuss the problems raised by the compensation mechanism in light of the discussion of the previous section. Finally, we outline a strategy for assisting developers in designing compensation processes in BPEL4WS-like languages. A. BPEL4WS Roughly speaking, a BPEL4WS process description consists of a declaration part that introduces various elements needed to describe the process, followed by the actual description of the process. The declaration part includes the following elements: 1) A description of the messages exchanged between services. The message structure is similar to that used in Web services: a message consists of parts, each with a name and a type. The type component is typically described using XSD types, but BPEL4WS can accommodate other type systems.

2) A description of the services invoked by the process. The description follows the (old) WSDL standard: each service, defined as a portType, consists of a bunch of operations. An operation has a name, zero or one input message, zero or one output message, and zero or more exceptions (faults). For example:

3) A description of the contracts between process participants. Recall that the process is defined in terms of collaboration between web services, which are supposed to be supported by process participants. Each contract—called service link type—defines roles and associates them with interfaces (portTypes). For example, in a supply chain example, we have customers, businesses, and their suppliers. The interaction between a customer and the business to fulfill an order, and between the business and its suppliers to restock, are managed by two separate contracts/service link types, each of which identifies the roles played by each service interface:

4) A description of partners. While service link types define the various contracts, it is not clear which entity will play which side in the contract. A BPEL4WS process thus contains an identification of the various partners in the different contracts, and the roles they play in the contract (service link type). Those partners will be referred to later in the description of the steps of the process: each step is performed by a partner (or self). In this example, we have two partners, the customer and the “invoiceProvider” playing the role “invoiceService” in the contract (service link type) “invoiceLT”. Self (the partner who will be orchestrating the BPEL4WS process) plays the role of “invoiceRequester”. … … ...

Other elements in the declaration include local variables defined within the scope of the process and exchanged as inputs/outputs between the process steps, and a description of fault handlers, which specify the desired response in case of a fault. The process itself is defined using a flow, which is a

partially ordered set of activities that correspond to invocations of operations, defined in the various services, that will be performed by the partners identified above. Process flow supports sequential activities (using the "sequence" activity), concurrent activities (using the "flow" activity), and control dependencies between process steps using the link mechanism. The link mechanism ensures that a particular process step can only be executed after another step has completed. The following shows excerpts from the body of a process. The (purchase order handling) process starts by receiving a purchase order (PO) from a customer. It then makes a copy of the customer info from PO into the customer info of a shipping request. Then it invokes an operation of the partner “shippingProvider” to ship the order to the customer. This example illustrates control dependencies: the “requestShipping” operation is the source of a control dependency (a link, called “ship-to-invoice”) linking it to the operation (not shown here) “sendShippingPrice” of the partner called “invoiceProvider”. … … … …

In addition to the top-level process scope, the developer can specify sub-scopes explicitly using the tag. Subscopes play the role of blocks in traditional programming languages, and can contain local variables, but most importantly for our purposes, compensation handlers. The compensation handler for a scope X—say “SendPurchaseOrder”—is an activity that needs to be executed to roll back the effect of executing the body of scope X—in this case, placing a purchase order. The following shows an example. The compensation handler in this case cancels the PO:

A compensation handler can be referred to using the name of its enclosing scope, and may be invoked using the expression:

Typically, it would be invoked in some fault handler: if some step of the process failed, for whatever reason, we compensate for those steps that have already completed successfully. When no fault handler is specified, BPEL4WS processes get default handlers which play the compensation handlers in reverse order à la sagas [8]. B. Issues There are a number of problems with the compensation mechanism in BPEL4WS. The first problem, which has more to do with WSDL itself, is related to the fact that the user of the service has to specify himself/herself how to compensate for an operation of a service. In the above example, the programmer of the above BPEL4WS process had to know that the operation SyncPurchase needs to be compensated by the operation CancelPurchase. This information should be provided by the service’s provider, as opposed to its user. The WSDL standard makes a provision to specify the exceptions raised by an operation, but says nothing about compensation. And yet, only the provider of the service knows how to cancel the effect of an operation, especially in the context of interorganizational processes where (web) service providers may be different organizations, with different business models. The second problem, also related to WSDL, has to do with the transactional nature—or lack thereof—of the operations of a service. The WSDL standard views web services as stateless service providers such that the operations can be invoked in any order. A number of researchers have identified problems with such an assumption (see e.g. [9]): there are often hidden dependencies between the various operations of a service that make only some sequences of operations valid. Such sequences may be viewed as transactions, and compensation should be adjusted accordingly. In other words, it may not be possible to specify compensation on an operation by operation basis, but only for a particular sequence of operations. The third related problem has to do with the reusability of the process definition [10]: when the user (i.e., developer of a BPEL4WS process) is responsible for writing the compensation, this reduces the reusability of the process. If the individual component services come with their built-in compensation processes, then the overall process may be used

with different service providers, provided that they offer the same functionality. C. Approach Within the context of inter-enterprise e-business, we need to specify and execute inter-organizational processes that invoke (web) services provided by the individual partners. Because those processes tend to be long-running, we need to specify compensation processes for them. Specifying compensation processes to take into account everything that can go wrong in any of the participating partners will often eclipse the efforts to specify the so-called “happy path” process where everything goes according to plan. Our goal is to provide some assistance to business process/workflow developers (e.g., BPEL4WS “programmers”) in specifying compensation processes. We showed in section 2 that choosing a compensation for a business transaction is a business decision. We also tried to illustrate the fact that such business decisions are generally a combination of two factors: 1) some general business policy which can be understood in terms of widely agreed upon management or accounting rules, and 2) a company or organization-specific implementation or adaptation of that policy based on some considerations. If these factors can be captured formally, it becomes conceivable to imagine a process design repository tool that can aid process designers in a) designing processes, and b) designing their compensation processes. The question remains: how many of these will need to be captured to make such a tool useful. BPEL4WS is a language for specifying processes as compositions of web services, and may be used to describe and execute inter-organisational processes involving several partners. The approach followed by BPEL4WS puts the onus on the inter-organisational process designer to 1) recognize amongst the operations of a (web) service which ones compensate for each other, and 2) to use them to compensate for a block of operations. We believe that the right approach would be for each service provider to specify the compensation for their operations, individually, or for blocks of operations. Automated approaches such as the saga approach [2] or StAC (Structured Activity Compensation, [4, 5]) may then be used to generate default compensation processes, which process designers may choose to override. This has the advantage of making the BPEL4WS process more reusable as some partners may be substituted with others, as long as they provide the same basic functionality, without having to worry about compensation. By shifting the specification of compensation from the users of a service to its providers, we also considerably reduce the amount of work needed: the specification of the compensation becomes a one-time cost that service providers need to assume, and that cost is minimal: simply specifying, for each operation that changes the state of the service provider, the operation that needs to be called to cancel the

effects of that change. Finally, finding the compensation for single operations is simpler as they tend to have more elementary or canonical functionalities than entire processes. For example, a web travel service would have separate functions for search, does not need compensation, for booking, which needs compensation (e.g., releasing airplane seats), and for payment, which needs a more complex compensation (crediting the customer and releasing their seats). Now the question becomes: how to assist developers in designing compensations for elementary business processes/activities? Roughly speaking, there are two general approaches to this problem. The first might be called enumerative: we develop a catalogue of pairs for the elementary business activities that we are likely to find in the most common business processes. Web service developers can then use this catalogue to match the operations of their service to the entries in the catalogue, and design the compensation operations accordingly. The second approach might be called ontological, and consists roughly of the following: finding a set of primitives from which all business activities can be derived, and identify i) compensations for each one of the primitives, and ii) composition rules for those compensations that parallel the composition rules on activity primitives. The second approach is not guaranteed to work, but if successful, it obviates the need for developing an exhaustive catalogue which, by definition, will always remain work in progress. A number of business process modeling efforts of the mid90’s have gone the catalogue way. A number of researchers have developed catalogues of business processes for the purposes of helping managers design, audit, or re-engineer their processes. Examples of such efforts include the MIT Process Handbook [11]. Many more catalogues were built for the purposes of helping information system analysts specify, design, and implement application software, including the IBM San Francisco initiative, and SAP’s blueprint. In those cases, each business process component had a software component associated with it, and the idea was to use the overall business process as a guide for assembling software components [6]. The advent of inter-enterprise electronic business has compelled researchers and practitioners to seek a common business vocabulary, something that both the RosettaNet and ebXML initiatives tried to do (see www.rosettanet.org and www.ebxml.org). We could take one of these catalogues and design compensation processes for the (elementary) processes in them. There have been fewer efforts on the ontological side. The BIAIT method [12] may be thought of as an ontological approach for information system design: the author has reduced the problem of specifying an information system to answering a dozen of questions about the business process— and business model—of the organisation. Lefebvre and Coad [13, 14] have extended that work by using a hybrid approach: a) a generic object analysis pattern (ontology), and b) a few dozen instantiations of the pattern (catalogue) based on the

specifics of the underlying business processes and domains. We choose the ontological approach. BIAIT-like approaches are too coarse-grained for our purposes, and will be of no help in specifying compensation processes for elementary business processes. Coad et al.’s catalogue of archetypes [Coad et al., 1999] focuses on the structural (object model) aspects of business processes, and will be of little help. The Resource Event Agent framework [15, 16] proposes an ontology for describing the dynamic aspects of business processes with a particular interest in recording the kind of information that would be of interest to accountants. This framework is appealing for several reasons, including its simplicity (few primitives), but also the fact, thanks to its accounting focus, that it captures the lasting and measurable effects of business transactions, which are exactly the kinds of things that we would like to compensate. The REA framework, and how we intend to use it, is discussed in the next section. IV. TOWARDS A METHODOLOGY FOR SPECIFYING COMPENSATION PROCESSES

A. Overview of the Resource Event Agent Framework In a pioneering paper, William McCarthy proposed the Resource Event Agent framework as a way of representing accounting information that would solve the problems experienced by existing accounting procedures and accounting software, including [15]: 1) limited dimensions in the accounting data, supporting a limited number of measures, 2) a rigid and too coarse classification of accounting data, leading to inappropriate classification of accounting entries or to ignoring some accounting information, 3) high aggregation level of accounting data, precluding analyses by decision makers who may need different views on the data, 4) poor (or lack of) integration with other data contained in information systems. According to McCarthy [15] and Geerts & McCarthy [17], accounting systems of today use bookkeeping principles (double entry) first laid out more than 500 years ago by Luca Pacioli, a Franciscan monk from Venice. The REA framework aims at a more detailed and more expressive representation of what “needs to be counted” which is, primarily, economic resources and economic events. Resources, events, and agents are discussed below Economic resources are defined as objects that are scarce and have utility, and are under the control of an enterprise [18]. These are similar to what accountants consider “assets”, with one exception: claims, which will be discussed later. Economic events are defined as “a class of phenomena which reflect changes in scarce means [economic resources] resulting from production, exchange, consumption, and distribution” [19]. Economic events constitute the main information elements that need to be counted. Resources and events are related by stock-flow relationships, which link

events to the resources they modify (increment or decrement). An event that increments a resource will have an inflow relationship, and one that decrements it will have an outflow relationship. Most economic events won’t happen spontaneously, and will require actors to make that them happen . McCarthy argues that there are often two actors involved in an economic event: one within the organization whose processes we are modeling, and one outside actor. If the event decrements some resource, the outside actor is usually the beneficiary or recipient of that decrement. When an event increments a resource, the outside actor is usually the provider of that increment. The outside actor is called economic agent, and the inside actor is called economic unit, and may be an individual (a function or a role within the enterprise) or an organizational unit (department, division). Figure 2 shows a simple—and partial—REA model of a purchase of some product from the point of view of the purchasing organization. The diagram is shown in the Entity/Relationship notation. The product is represented by INVENTORY, and the act of purchasing by the entity Purchase. To purchase something, we need two actors, a buyer or a seller. The seller is represented by the entity ‘Vendor’, and is an external agent. The ‘Buyer’ works for the organization that we are modeling, and is thus linked to the department for which they work (‘Purchasing department’). Vendor

INVENTORY

Inflow

Purchase

Purchasing Department

party to

Buyer

works for

Fig. 2. A partial model of a purchase from the point of view of the purchasing organization. From an economic point of view, the description in Figure 2 provides a partial view of the purchasing act: organizations don’t get something for nothing, and each increment in a resource should have a corresponding decrement in another resource. This is called the duality principle, and is a widely accepted accounting principle [15]. Assuming that our buyer paid for the product in cash (an economic resource), we should model a dual economic event that corresponds to a cash disbursement from the buyer to the seller, but this time through some employee of the accounts payable department (cashier). Figure 3 shows a model of the two dual exchanges.

Vendor

INVENTORY

inflow

Purchase

party to

Purchasing department

Buyer

works for

pays for

Vendor

CASH

Cash disbursement

outflow

party to

Treasurer department

Cashier

works for

Fig. 3. A full-model of a product purchase from the point of view of the buyer organization. Figure 4 shows a partial metamodel of the REA framework represented using the ER notation. The stock flow relationship stands for inflow and outflow relationships. Inflow relationships may indicate an acquisition (e.g., through a purchase or transfer) or a production (manufacturing) [17] Outflow relationships reflect usage (wear), consumption (as input for a transformation process), or relinquishing control of the resource. The economic events themselves can be either transfers or transformations (e.g., manufacturing). In the tertiary relationship ‘control’, ‘Economic Agent’ represents the external agents, and ‘Economic unit’ represents the internal agents. Responsibility reflects control and accountability (units are accountable for the actions of the (sub-)units they control). Duality

Economic Resource

Stock-flow

Economic Agent

Economic Event

Control

Responsibility

Economic Unit

Fig. 4. The REA framework metamodel [16]. The model of Figure 4 is a first-cut metamodel of business processes. In [16], McCarthy identified a number of economic events and accounting phenomena that do not fit purely into this framework, and proposed ways to handle them. These include claims, which are not actual resources in the strictest sense of the word, depreciation of assets, where nothing seems to be gained in exchange, equity transactions (e.g., investments and dividend payments), and macro-level duality, where some global resource consumption (e.g., amortizing the headquarters of a corporation) needs to be imputed to (matched against) various revenue generating activities [16]. J. S. David proposed a refinement of economic events that allows to account for things such as claims as first order objects, and highlighted the distinction between what she

called business events, which create new information, and information events, which simply derive information from existing data [20]. Finally, Geerts and McCarthy proposed a more complete metamodel that takes into account contractual obligations [17]. We will refer to these extensions as needed in the next section. B. Compensating events Let us go back to our inter-organizational business processes and to our purchasing process of section 2. When the credit check of the customer fails, we decide to cancel the purchase order. What does it mean to cancel the purchase order? To better understand what is meant by cancelling a purchase order, we need to understand the changes that started to happen in the system as a result of processing the purchase order. Once we understand those changes, we will know how to reverse them properly. This is where the REA framework will help: if we accept the idea that the various transactions that occur within an information system embody, directly or remotely, some economic events that took place within the organization, then we will have an idea about what would make sense, from an economic or a business point of view, and how to reflect that at the level of the information system. We may have to distinguish between different kinds of economic events (e.g., a transfer versus a transformation of a resource), and for a given economic event, about different ways that event is captured by the information system. First, at the very basic level, REA has brought to the fore the notion of exchange. Let us take the purchasing example represented in the previous section. What does it mean to cancel a purchase? The purchase involves two dual transfers—one of a product, and one of cash–and cancellation will behave differently, depending on when it takes place. The REA model of Figure 3 does not tell us much about when the two exchanges take place: it just tells us that one “pays” for the other. In fact, there could be different business models: 1) a pay-first, get the product later business model: this is the model used in most on-line B2C organizations that sell tangible goods (things that need to be packed and sent) where on-line customers pay for the goods first, before a PO is processed internally, and the product is sent; 2) a get-the-product first, pay later: this is the model used most often in B2B commerce (electronic or otherwise), and is based on a model of trust; 3) a simultaneous exchange of payment and product. This is the model for off-the-counter sales (at a store) or for on-line sales of non-tangible goods (e.g., a software license or a service) which are delivered instantaneously. Generally speaking, if the two parts of an exchange do not happen simultaneously, the imbalance is temporarily covered by a claim (see previous section) or an invoice, which Ijiri refers to as a future asset [18]. Thus, in the pay-first, get the product later business model, the purchaser gets a claim instantaneously in exchange of her payment, and when she receives the product, she “releases” (gives back) the claim. The following table shows, for each purchasing business

model, what needs to be cancelled, depending on when the cancellation occurs. If the cancellation occurs after both parts of the transaction have taken place, we assumed that in the “pay first, get product later” model, we ask the customer to return the product, and when the product arrives, they get credit for the payment minus any applicable fees. By contrast, in the “get-product first, pay later“ model, we assume that we credit the customer first, and issue an order for product return. When the product is returned, the order is cancelled or somehow archived. TABLE 1 HOW TO COMPENSATE PURCHASES DEPENDING ON THE CANCELLATION TIME AND THE BUSINESS MODEL.

Business model ⇒

Pay first, get product later

Get product first, pay later

Pay and get product simultaneous ly

Credit customer for payment amount, cancel claim

Return product, cancel invoice

Not applicable

Cancellation time ⇓ Between the two parts of the exchange After both parts have been completed

issue order for Credit Return returns; Credit customer for product AND customer for payment credit payment minus fees; customer for minus fees issue order balance of when order for returns unused has been service. returned This example illustrates a general accounting principle highlighted by McCarthy [16], Geerts and McCarthy [17] and David [20]: when the two parts of an exchange cannot happen simultaneously, we have an imbalance in the duality relationship where the organization has either [16] (sic):” 1) gained control of a resource and is now accountable for a future decrement (future negative asset), or 2) relinquished control of a resource and is now entitled to a future increment (future positive asset).” Hence the claims given to customers if they pay first, or the invoices sent to them if they pay later. Those documents (future assets, negative or positive) are later exchanged against real assets when the second leg of the dual relationship takes place. J. S. David refers to the issuance of a claim as a business event as opposed to a typical economic event [20]. Generally speaking, business events are defined as “any business activity that management wants to plan, monitor, and evaluate” [21]. Other kinds of business events include “requisition goods”, “place purchase order”, “take customer order”, etc. For example, when a customer places an order, and the organization accepts it, both commit to a future economic event: the organization to actually provide the products, and the customer to pay for it [20]. We can now generalize Table 1 to the following table which characterizes any dual exchange. We added to the

cancellation process the imputation of the cost of cancellation according to whichever agreement binds the parties, which could depend on a variety of factors including the nature of the resources (e.g., class Y plane seats subject to cancellation fee), the status of the relationship between them (VIP customer or not), or some general business policy (“money back guaranteed”). Contractual agreements between parties in an exchange are an important part of the full REA metamodel [17]. The result is shown in Table 2. TABLE 2 COMPENSATING FOR RESOURCE EXCHANGES IN THE CASE OF SIMPLE TRANSFERS.

Business model ⇒

Transfer resource X from A to B, then Transfer Y from B to A

Simultaneous exchanges

Between exchanges of X and Y

Transfer resource X back from B to A; cancel A’s claim to the transfer of Y from B to A; distribute cost back to A and B according to binding agreement

Not applicable

After exchanges of X and Y

Transfer resource X back from B to A; transfer resource Y back from A to B; distribute cost back to A and B according to binding agreement

Cancellation time ⇓

Transfer resource X back from B to A; transfer resource Y back from A to B; distribute cost back to A and B according to binding agreement Notice that the compensation model in Table 2 corresponds to the transfer of non-perishable and non-consumable resources. If we had a transformation process involved (e.g., a manufacturing process), and cancellation occurred before the entire batch was produced, the customer would get charged for the fraction that was manufactured according to some formula. If the cancellation happened after the manufactured product was built and delivered, then the customer may well not qualify for any credit. Similarly, if the resource is consumable, the customer may be billed for the consumed portion (e.g., internet service, insurance, tech support). If the resource is perishable, then refund will depend on how close we are to the “good before date”. This applies to fruits and vegetables, canned goods, but also to plane tickets, hotel rooms as well as to time-critical financial products such as futures and other financial derivatives. This simple example is meant to illustrate the kind of analyses that can be made to design general compensation strategies using the REA ontology as a starting point. We show in the next section how we can make use of these analyses to help the designers of inter-organizational business processes specify compensation processes.

C. Applications to specifying compensation for web services We argued in section 3.3 that in the context of interorganizational business processes that involve the composition of web services of the participating organizations, among other things, that: 1) the individual web service providers should specify how to compensate for the various operations in their service 2) compensation for the entire process, or at least some reasonable default version of it, should be derived automatically from the specification of compensations for the individual web services. We show in this section how the kind of analyses described in section 4.2 can help web service providers design and specify their compensation processes. First, we hope to have convinced the reader that compensation is 1) critical, 2) not trivial, and 3) business knowledge intensive. Thus, any organization that wishes to expose some of its services as web services should pay a great deal of attention to compensation: all the operations that modify its internal state should have corresponding (single) operations or procedures to compensate for those changes, five minutes later, five hours later, or five weeks later. While an organization can control internally how its various services will be used, when it exposes its services to the world or to a select set of business partners, one has to think of all possible usages, and how to compensate for them. Existing software tools that can expose any transaction-oriented Java application into a web service betray a significant but silent paradigm shift: the issue of compensation. Once a web service designer decides what operations to expose, then comes the issue of identifying which sequences of operations are valid. We can more or less circumvent the problem of specifying a stateful service using a stateless interface/API by passing state information back and forth between the various operations, and having each operation validate its position in the invocation sequence that way. Next, comes the task of specifying compensations for the various operations that modify the state of the service. In this case, the designer has to match the various operations to various business patterns similar to the ones described in section 4.2. Let us take a simplified version of the familiar travel booking example. For the sake of simplicity, we will represent the service in a Java interface-like fashion. interface TravelService { // checks for flights from airport with code dp to airpot with code // dst, departing on d1 returning on d2. Returns a list of flights with // available rates Collection checkAvailabilities(Date d1, String dp,String dst, Date d2); // make reservation for customer custInfo on flight fNum rate category // rt. Returns a reservation number if reservation successful, and null // otherwise String makeReservation(Customer custInfo, String fNum, String rtCat); // make payment for reservation number resNum using credit card info // cardInfo. The result is a confirmation code for payment, if

// successful, and null otherwise. String makePayment(String resNum, CreditCard cardInfo); }

The function “checkAvailabilities” needs no compensation because it performs a simple look-up. Both “makeReservation” and “makePayment” need compensation. Implicit in this API (port type) is the fact that the proper way to book a flight is to first make a reservation, and then to make payment on that reservation within a certain amount of time. The reservation number that is returned by “makeReservation” and passed as an argument to “makePayment” will make sure that the sequence is properly followed. In this case, if only the reservation has been made, with no payment yet, and we need to compensate for that (i.e., compensate for “makeReservation”), we look up Table 2 to find a matching situation. Our situation matches “”, which tells us what to do. Thus, we should develop an operation which 1) returns the seat back to the airline (i.e., erases the reservation), and 2) cancels any expectation the system has about the customer paying something (e.g., the corresponding invoice). To compensate for “makePayment” means to compensate for the whole booking process, which matches the next row of Table 2, and we have to provide a function that behaves as specified in the corresponding cell of Table 2. We could conceivably go one step further and generate the compensation code automatically given a definition of the data model that represents the various resources and their relationships, but that is beyond the scope of this paper. Finally, now that we have designed and coded our compensation functions and made them available in our web services, the question becomes: how do we make the compensation information available to the web service users? As mentioned earlier, the WSDL standard makes no provision for specifying compensation. Thus, we can rely on the documentation fields to include such information about functions. V. DISCUSSION Many inter-organizational business processes are longrunning business transactions. If one step of such a process fails, we need to abort the whole process, and to somehow cancel the effects of those steps that were already completed. The model of transactions in databases is not appropriate in this case, because of the duration, hence the concept of compensation, i.e., compensating for some changes that have already been committed, as opposed to deleting them. Specifying compensation for the various fault points of longrunning processes is a complex and error-prone process. There are two aspects to the problem. One might be called a purely computational aspect, and deals with ways of compensating for a compound activity, given compensations for each of the elementary activities. The other aspect is related to the business domain and has to do with the kind of compensations that would make sense from a business point of view. We

have attempted to address this second aspect. The purpose of this work is to lay the foundation for a management model of compensation processes based on 1) a classification of business transactions in terms of an accounting ontology, and 2) a catalogue of compensation heuristics associated with these transactions. Our work is preliminary. The examples that we presented illustrate the approach but also show that a lot more work needs to be done. Our study of the REA ontology showed that, despite its relative simplicity, it accounts for a variety of fairly complex business phenomena, some of which were briefly mentioned in this paper. There is also a whole area of the ontology that we mentioned only briefly in this paper: the whole issue of reporting (see section 2), that is, how to deal with the various kinds of reports that may be generated during the execution of the process before it aborts, and more generally, with the whole concept of information events [20]. While our first study did not provide us with all of the answers, we felt that it raised questions at the right level of abstraction, and we expect many more insights into compensation.

[11]

REFERENCES

[16]

[1] [2] [3] [4] [5] [6]

U. Dayal, M. Hsu, and R. Ladin, "Business Process Coordination: State of the Art, Trends and Open Issues," presented at 27th Very Large Databases Conference, VLDB 2001, Roma, Italy, 2001. H. Garcia-Molina and K. Salem, "Sagas," presented at ACM SIGMOD, San Francisco, CA, 1987. R. Bruni, H. Melgratti, and U. Montanari, "Theoretical Foundations for Compensations in Flow Languages," presented at POPL'05, Long Beach, CA, 2005. M. Butler, M. Chessell, C. Ferreira, C. Griffin, P. Henderson, and D. Vines, "Extending the concept of transaction compensation," IBM Systems Journal, vol. 41, pp. 743-758, 2002. M. Butler and C. Ferreira, "A Process Compensation Languages," presented at Integrated Formal Methods 2000 Conference, 2000. H. Mili, G. B. Jaoude, E. Lefebvre, and G. Tremblay, "Business Process Modeling Languages: Sorting through the alphabet soup,"

[7] [8]

[9] [10]

[12] [13] [14] [15]

[17]

[18] [19] [20] [21]

LATECE, Université du Québec à Montréal November 2003 2003. "Business Process Modeling Language," Business Process Management Institute, 2003, pp. 96. T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, A. Trickovic, and S. Weerawaran, "Business Process Execution Language for Web Services (BPEL4WS) version 1.1," 5 May 2003 2003. G. Tremblay and J. Chae, "Toward Specifying Contracts and Protocols for Web Services," presented at Montreal Conference on eTechnologies (MCETECH2005), Montréal, Canada, 2005. M. Chessell, C. Griffin, D. Vines, M. Butler, C. Ferreira, and P. Henderson, "Extending the Concept of Transaction Compensation," IBM Systems Journal, vol. 41, pp. 743-758, 2002. T. W. Malone, K. Crowston, B. P. J. Lee, C. Dellarocas, G. Wyner, J. Quimby, C. S. Osborn, A. Bernstein, G. Herman, M. Klein, and E.O'Donnell, "Tools for inventing organizations: Toward a handbook of organizational processes," Management Science, vol. 45, pp. 425-443, 1999. W. M. Carlson, "Business Information Analysis and Integration Technique (BIAIT) - the new horizon," Data Base, vol. 10, pp. 3-9, 1979. É. Lefebvre, "Améliorer les méthodes de planification informatique: une approche pluraliste," Université de Grenoble II, 1996. P. Coad, E. Lefebvre, and J. Luca, Java Modeling In Color With UML: Enterprise Components and Process: Prentice-Hall, 1999. W. E. McCarthy, "Construction and Use of Integrated Accounting Systems with Entity-Relationship Modeling," in EntityRelationship Approach to Systems Analysis and Design, P.Chen, Ed.: North Holland Publishing, 1980, pp. 625-637. W. E. McCarthy, "The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment," The Accounting Review, pp. 554-578, 1982. G. L. Geerts and W. E. McCarthy, "Modeling Business Enterprises as Value-Added Process Hierarchies with Resource-Event-Agent Object Templates," in Business Object Design and Implementation, J. Sutherland and D. Patel, Eds.: Springer-Verlag, 1997, pp. 94113. Y. Ijiri, "The Theory of Accounting Measurement," American Accounting Association, 1975. S. C. Yu, The Structure of Accounting Theory: The University Press of Florida, 1976. J. S. David, "Three Events that Define an REA Methodology for Systems Analysis, Design, and Implementation," 1997. E. Denna, J. Cherrington, D. Andros, and A. Hollander, "EventDriven Business Solutions: Today's Revolution in Technology," presented at Business One, Irwin, IL, 1993.