BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles A History of Extended Transactions

A History of Extended Transactions

Extended transaction models for Business Process Management: from CORBA to Web Services

Abstract

Atomic transactions are a well-known technique for guaranteeing consistency in the presence of failures. The ACID properties of atomic transactions ensure that even in complex business applications consistency of state is preserved, despite concurrent accesses and failures. However, although this is an extremely useful fault-tolerance technique, it is not sufficient for long running transactions, where relaxation of the properties is necessary. So-called extended transaction models have been around for many years, but until the advent of Web Services, they have tended to remain within academic environments. In this paper we shall examine the requirements and how industry standards for extended transactions developed in the closely-coupled environment of CORBA, have heavily influenced the loosely-coupled environment of Web Services.

Introduction

Distributed systems pose reliability problems not frequently encountered in centralized systems. A distributed system consisting of a number of computers connected by a network can be subject to independent failure of any of its components, such as the computers themselves, network links, operating systems, or individual applications, and activities may take an indeterminate duration to execute. Decentralization allows parts of the system to fail while other parts remain functioning which leads to the possibility of abnormal behavior of executing applications. With the advent of Web Services, the Web is being populated by service providers who wish to take advantage of this large B2B space. However, the Web is the largest distributed system in history and suffers from failures which can affect both the performance and consistency of applications run over it.

Atomic transactions are a well-known technique for guaranteeing consistency in the presence of failures [1]. The ACID properties of atomic transactions (Atomicity, Consistency, Isolation, Durability) ensure that even in complex business applications consistency of state is preserved, despite concurrent accesses and failures. This is an extremely useful fault-tolerance technique, especially when multiple, possibly remote, resources are involved.

However, as Web Services have evolved as a means to integrate processes and applications at an inter-enterprise level, traditional transaction semantics and protocols have proven to be inappropriate. Web services-based transactions differ from traditional transactions in that they execute over long periods, they require commitments to the transaction to be "negotiated" at runtime, and isolation levels have to be relaxed. So-called extended transaction models have been around for many years, but until the advent of Web Services, they have tended to remain within academic environments. However, the OASIS Web Services Transactions (WS-TX) technical committee is defining the standard for transaction management in Web Services [2] using these models. In this paper we shall first consider why traditional atomic transactions are insufficient for long-running activities, and then describe how the WS-TX solves these problems, building upon research and development work within the OMG which predates Web Services.

The need for extended transaction models

For many years distributed objects plus ACID transactions provided a foundation for building high integrity business applications. The ACID properties of transactions ensure that even in complex business applications the consistency of the application’s state is preserved, despite concurrent accesses and failures. A transaction can be terminated in two ways: committed or aborted (rolled back). When a transaction is committed, all changes made within it are made durable (forced on to stable storage such as disk). When a transaction is aborted, all changes made during the lifetime of the transaction are undone.

Traditional transaction systems use a two-phase protocol to achieve atomicity between participants, as illustrated in Figure 1: during the first (preparation) phase, an individual participant must make durable any state changes that occurred during the scope of the transaction, such that these changes can either be rolled back or committed later once the transaction outcome has been determined. Assuming no failures occurred during the first phase, in the second (commitment) phase participants may "overwrite" the original state with the state made durable during the first phase.

Figure 1, Two-phase commit protocol.

In order to guarantee consensus, two-phase commit is necessarily a blocking protocol: after returning the first phase response, each participant which returned a commit response must remain blocked until it has received the coordinator’s phase 2 message. Until they receive this message, any resources used by the participant are unavailable for use by other transactions, since to do so may result in non-ACID behavior. If the coordinator fails before delivery of the second phase message these resources remain blocked until it recovers.

Consensus groups

It has long been realised that ACID transactions by themselves are not adequate for structuring long-lived applications [3][4]. One well-known enhancement (supported by the CORBA Object Transaction Service, OTS [5]) is to permit nesting of transactions; furthermore, nested transactions could be concurrent. The outermost transaction of such a hierarchy is typically referred to as the top-level transaction. The durability property is only possessed by the top-level transaction, whereas the commits of nested transactions (subtransactions) are provisional upon the commit/abort of an enclosing transaction. This allows for failure confinement strategies, i.e., the failure of a subtransaction does not necessarily cause the failure of its enclosing transaction. Resources acquired within a subtransaction are inherited (retained) by parent transactions upon the commit of the subtransaction, and (assuming no failures) only released when the top-level transaction completes, i.e., they are retained for the duration of the top-level transaction.

The above enhancement is sufficient if an application function can be represented as a single top-level transaction. Frequently this is not the case. Top-level transactions are most suitably viewed as "short-lived" entities, performing stable state changes to the system [4]; they are less well suited for structuring "long-lived" application functions (e.g., running for hours, days,...). Long-lived top-level transactions may reduce the concurrency in the system to an unacceptable level by holding on to resources for a long time; further, if such a transaction aborts, much valuable work already performed could be undone. In short, if an application is composed as a collection of transactions, then during run time, the entire activity representing the application in execution is frequently required to relax some of the ACID properties of the individual transactions. The entire activity can then be viewed as a non-ACID ‘extended transaction’.

The spheres of control model [6] describes the underlying concepts of recovery and commitment for extended transactions. Much research work has been done on developing specific extended transaction models [e.g., 7 – 10], concentrating on the notion of consensus groups. Not all participants within a particular extended transaction have to see the same outcome; a specific transaction may possess multiple different consensus groups, with participants in each group observing different outcomes. In addition some consensus groups may allow the atomicity within a specific transaction to be relaxed, allowing subsets of participants to receive different outcomes. This flexibility in the participant list of a group is an important difference between these kinds of extended transactions and traditional transaction systems.

Furthermore, it should be possible for a participant to exit a consensus groups when required. There are a number of reasons why a participant may not longer wish to be involved in the consensus decision; for example, the work it has performed can complete safely irrespective of the final outcome of the consensus group, or it may be necessary for a separate task (a different service or domain) to perform a counter-effect in the event the consensus group cancels the work.

Consensus groups achieve consistent outcomes amongst participants, but are only part of the picture. Often in business-to-business relationships there are hierarchies of these groups (scopes of work), with parent and child relationships existing between them. Typically the work performed by a child is provisional on the successful completion of the parent, i.e., the parent scope can perform a counter-effect for the completed child. In a nested scope relationship (e.g., nested transactions), the sub-scopes can complete independently of their parents and may then impose compensation requirements on the parent.

In addition to understanding the outcomes, a participant within a business transaction may need to support provisional or tentative state changes during the course of the transaction. Such parties must also support the completion of a business transaction either through confirmation (final effect) or cancellation (counter-effect). In general, what it means to confirm or cancel work done within a business transaction will be for the participant to determine. For example, an application may choose to perform changes as provisional effect and make them visible to other business transactions. It may store necessary information to undo these changes at the same time. On confirmation, it may simply discard this undo changes or on cancellation, it may apply these undo changes. An application can employ such a compensation based approach or take a conventional "rollback" approach, for example.

The CORBA Activity Service

Despite the fact that there are obvious requirements for extended transactions, most of the proposed techniques have not found any widespread usage; indeed, most commercial transaction processing systems do not even support nesting of transactions. One reason cited is lack of flexibility [11], in that the wide range of extended transaction models is indicative that a single model is not sufficient for all applications, so it would be inappropriate to ‘hardwire’ a specific extension mechanism. In any case, most transaction processing monitors are monolithic in structure, so difficult to extend. Thus the situation remained that a programmer often had to develop application specific mechanisms to build extended transactions.

There is a way out of this situation by exploiting a middleware based approach; in the case of CORBA for example, a set of open services are already available for building distributed applications. Within this context, it is appropriate to examine what additional functionality is required for flexible ways of composing an application using transactions, with the support for enabling the application to possess some or all ACID properties. This was the basis for the CORBA Activity Service work [12], which used the insight that the various extended transaction models can be supported by providing a general purpose event signalling mechanism that can be programmed to enable activities - application specific units of computations – to coordinate each other in a manner prescribed by the extended transaction model under consideration.

The different extended transaction models can be mapped onto specific implementations of the Activity Service framework permitting transactions to span a network of systems connected indirectly by some distribution infrastructure.

Therefore the CORBA Activity Service standard defines two entities [13]:

  • The coordinator: this is a generic coordinator that is only responsible for sending and receiving messages of arbitrary types, called Signals. The intention is that the coordinator implementation is simply a framework that is useful only when augmented.
  • The coordinator intelligence: this is the augmentation (called a SignalSet) to the coordinator that enables it to execute a specific protocol, such as two-phase commit. This is the key to the extensibility of the Activity Service.

A given coordinator implementation can take any number of SignalSets in order to execute different protocols. As a result, the coordinator is a fairly lightweight entity, having delegated most of its responsibilities to the SignalSet.

Although the framework was originally designed as part of CORBA, the main ideas were sufficiently general so that it was later incorporated within the J2EE architecture [14]. When the first attempt to provide an industry standard for Web Services was started in 2001 [15], one of the initial submissions was based on the Activity Service work [16]; unfortunately that proposal was not accepted, and it was not until 2005 that a similar proposal re-emerged in the form of the OASIS WS-TX committee.

Web Services Coordination

Although the original CORBA Activity Service was intended as a framework for extended transactions, it was apparent that it could be used more widely: wherever coordination was needed. Coordination is a requirement in a variety of different aspects of distributed applications, e.g., workflow, security, atomic transactions, caching and replication, security, auctioning, and business-to-business activities. Fortunately the Web Services architecture is sufficiently immature and evolving that coordination as a fundamental service fits in well.

Therefore, unlike in the original OMG Activity Service, the initial approach to defining a standard for Web Services transactions was to separate out the coordination aspect so that that it could be used more widely. This was the aim of the Web Services Coordination specification [2]: to provide a lightweight framework for coordination that can be augmented to suit specific requirements, as shown in Figure 2.

Figure 2, WS-Coordination and Web Services transactions.

The WS-Coordination specification defines an abstract notion of activities, which are distributed units of work, involving one or more parties (which may be services, components, or even objects). At this level, an activity is minimally specified and is simply created, made to run, and then completed. It is the responsibility of higher-level services or specifications to augment WS-Coordination and concretely define an activity.

Whatever coordination protocol is used, the same requirements are present:

  • Instantiation (or activation) of a new coordinator for the specific coordination protocol, for a particular application instance;
  • Registration of participants with the coordinator, such that they will receive that coordinator’s protocol messages during (some part of) the application’s lifetime;
  • Propagation of contextual information between Web services that comprise the application; the context contains sufficient information to uniquely identify the coordinator instance;
  • An entity to drive the coordination protocol through to completion.

The model for WS-Coordination is based upon similar concepts to the OMG Activity Service: defining a lightweight coordinator infrastructure. In WS-Coordination, this is accomplished through two Web Services.

The first, the activation service, supports the creation of coordinators for specific protocols and their associated contexts. The process of invoking an activation service occurs asynchronously, so the activation service calls back to deliver the context that identifies the type of transaction and coordinator location. This asynchronous approach reduces the tight coupling between end-points typically seen in other environments, which has the advantage of improved fault-tolerance, modularity and deployment considerations.

Once a coordinator has been instantiated and a corresponding context created by the activation service, the second service type, the registration service, is created and exposed. This service allows participants to register to receive protocol messages associated with a particular coordinator. Like the activation service, the registration service assumes asynchronous communication.

Apart from generic coordinator-specific faults, the WS-Coordination specification defines nothing else, leaving protocol specifics to users, such as the various Web Services transactions specifications.

Web Services Transactions

There are currently two transaction models defined by the WS-TX committee which augment WS-Coordination. In this section we shall compare and contrast the models. It is important to note that these two models are not meant to cover all possible use cases for transactions. If scenarios arise that cannot be solved using the existing transaction protocols, then additional models (and associated protocols) will be defined to further augment WS-Coordination.

The Atomic Transaction protocol

The Atomic Transaction (AT) protocol is a consensus group that enforces strict atomicity amongst its participants. There has been much written about the inapplicability of atomic transactions to Web Services [17][18]. However, these all ignore the central reason for using ATs: interoperability and short-duration interactions. There is a place for traditional transaction systems in Web services and this is precisely where the Atomic Transaction model is intended to be used. Interoperability between traditional transaction processing systems has been a holy grail for many years. Prior to Web Services, the closest that the industry came was in the development of the OMG's Object Transaction Service, but even then it took nearly 10 years to produce an interoperable version. Web Services would appear to have solved the problem in a fraction of that time [19].

To begin an atomic transaction, the client application must first locate a coordinator service (instance of WS-Coordination) that supports the correct model. Once located, the client instructs it to start a new transaction and gets back a transaction context containing a reference to the transaction's Registration Service. After obtaining the context, the client application then proceeds to interact with Web services to accomplish its business-level work. With each invocation on a business service, the client propagates the context, such that the each invocation is implicitly scoped by the transaction.

Once all the necessary application level work has been completed, the client can terminate the transaction. Transaction termination uses a traditional (durable) two-phase commit protocol (Durable2PC); participants are expected to act on persistent data, such as tables in a database or resources maintained in the file system. One obvious difference between the Atomic Transaction protocol and traditional transaction systems is the lack of a one-phase commit optimisation [3]: if a transaction involves only a single participant then the participant's decisions is implicitly the outcome of the transaction and only a single phase protocol is required. The lack of such support in the Web Services transactions protocol is an oversight that will adversely affect performance.

Figure 3 shows the state transitions of an Atomic Transaction and the message exchanges between coordinator and participant; the coordinator generated messages are shown in the solid line, whereas the participant messages are shown by dashed lines.

Figure 3, Two-Phase Commit State Transitions

In addition to the traditional Durable2PC protocol, the Atomic Transaction protocol also supports a Volatile2PC, whose prepare phase runs before the entire Durable2PC, whilst the commit or rollback phase runs after the Durable2PC has completed. The reason behind this protocol is that accessing durable storage is often the performance bottleneck, and hence caching of an object’s state (e.g., an entire database table) and operating on that cached state for the duration of a transaction can significantly improve performance over the alternative of continually going back and forth to the database. However, there is obviously a need to force that state back to the original persistence store prior to the transaction committing.

Volatile2PC turn the two-phase commit protocol into a four-phase protocol:

  1. Before the transaction starts the Durable2PC, all participants registered with the Volatile2PC are informed and can flush cached data. Any failure at this point will cause the transaction to roll back.
  2. The coordinator then conducts the entire Durable2PC protocol.>
  3. Once the transaction has terminated, the second phase of the Volatile2PC protocol is executed. However, this is a courtesy invocation because any failures at this stage are ignored: the transaction has terminated so there’s nothing to affect.

The Atomic Transaction model successfully models the traditional ACID transaction protocol within Web Services. It is meant to map to existing transaction standards which have a well defined behavior for atomicity (well-formed and two-phase), isolation (no dirty reads, repeatable reads) and durability (no lost data). AT is useful only in trusted domains where transactions are of short duration. If such is not the case, then the other transaction protocol defined with WS-TX should be used.

Business Activities (BA)

A business activity is designed specifically for long-duration transactions, where exclusively locking resources is impossible or impractical. In this model (based on the Sagas extended transaction model [11]), services are requested to do work, and where those services have the ability to undo any work, they inform the BA such that if the BA later decides to cancel, it can instruct the service to execute its undo behavior. While the full ACID semantics are not supported by this model, consistency can still be maintained through compensation, though the task of writing correct compensating actions (and thus overall system consistency) is delegated to the developers of the services.

A business activity may be partitioned into scopes, as described earlier. Such scopes can be nested to arbitrary levels, forming parent and child relationships. A parent scope has the ability to select which child tasks are to be included in the overall outcome protocol for a specific business activity, and therefore non-atomic outcomes are possible: a Business Activity defines a consensus group that allows the relaxation of atomicity based on business level decisions. For example, if a child task experiences an error, it can be caught by the parent who may be able to compensate and continue processing.

When a child task completes it can either leave the business activity or signal to the parent that the work it has done can be compensated later. In the latter case, the compensation task may be called by the parent should it ultimately need to undo the work performed by the child.

Unlike the Atomic Transaction protocol model, where participants inform the coordinator of their state only when asked, a task within a business activity can specify its outcome to the parent directly without waiting for a request. This feature is useful when tasks fail such that the notification can be used by business activity exception handler to modify the goals and drive processing forward without having to meekly wait until the end of the transaction to admit to having failed – a well designed Business Activities should be proactive.

Underpinning all of this are three fundamental assumptions:

  • All state transitions are reliably recorded, including application state and coordination metadata (the record of sent and received messages);
  • All request messages are acknowledged, so that problems are detected as early as possible. This avoids executing unnecessary tasks and can also detect a problem earlier when rectifying it is simpler and less expensive;
  • As with atomic transactions, a response is defined as a separate operation and not as the output of the request. Message input-output implementations will typically have timeouts that are too short for some business activity responses. If the response is not received after a timeout, it is resent. This is repeated until a response is received. The request receiver discards all but one identical request received.

As with the Atomic Transaction protocol, the BA model has multiple protocols: BusinessAgreementWithCoordinatorComplete and BusinessAgreementWithParticipantComplete. However, unlike the AT protocol which is driven from the coordinator down to participants, this protocol is driven much more from the participants upwards.

Under the BusinessAgreementWithParticipantComplete protocol, a child activity is initially created in an active state; if it finishes the work it was created to do and no more participation is required within the scope of the BA (such as when the activity operates on immutable data), then the child can unilaterally resign from the parent scope. However, if the child task finishes and wishes to continue in the BA then it must be able to compensate for the work it has performed. In this case it informs the parent scope and waits to receive the final outcome of the BA from the parent. This outcome will either be that the parent completes successfully and no further work is required from the participant, or that the parent completes unsuccessfully and therefore requires the child scope to compensate.

The BusinessAgreementWithCoordinatorComplete protocol is identical to the BusinessAgreement WithParticipantComplete protocol with the exception that the child cannot autonomously decide to end its participation in the business activity, even if it can be compensated. Rather the child task relies upon the parent to inform it when the child has received all requests for it to perform work which the parent does this by sending the complete message to the child. The child then acts as it does in the BusinessAgreementWithParticipantComplete protocol.

Example scenario

In this section we shall look at an example where Business Activities are more appropriate than Atomic Transactions. In this example, we shall take the relatively simple scenario of arranging travel and accommodation for a conference. In particular, the attendee will require a flight to the city where the conference is being held, a room reservation at a hotel and possibly a rental car for the duration of the conference. While locating flight, hotel and car rental options we need to ensure likely options can be reserved as we assemble the required set of reservations required for the trip as a whole. As well as considering the needs of the conference attendee, service providers also need to have some autonomy and maintain control of their own resources (flight, room, and car rental reservations).

The elements required for the booking are interrelated within this domain and yet they are not necessarily predetermined. Obviously without a flight it makes no sense to book the hotel or to rent a car unless the conference were local, but in other circumstances it may make sense to book the flight and hotel, but if the hotel booking we make is at the same hotel as the conference it may be possible to do without the car rental.

We may also want to keep our options open by reserving a number of flights while looking for other more direct travel options or other convenient hotels. The customer solicits multiple quotes to determine the lowest-cost supplier. Therefore, conducting the entire travel arrangements within a single Atomic Transaction is inappropriate, since in that situation either all of the work occurs or none occurs: it would not be possible to have the partial outcomes (relaxed atomicity) that might be required if visiting multiple flight booking services, for example.

Figure 4, Travel arrangement scenario.

This example discusses the requirements of business transactions which need a mechanism to select and manage the tasks that are included in the overall application outcome. For simplicity, we shall only consider relaxing the atomicity property for selecting the required flight; extensions to the entire travel scenario are left as an exercise to the reader. Figure 5 show the application configuration: each flight service exposes operations to reserve, confirm or cancel seats on a specific flight.

Figure 5, The system configuration.

The travel agent makes invocations on each of the services to obtain a quote for a seat on the flight. Xantas.com ALU.com and ZA.com acknowledge the Travel Agent’s Flight Booking Requests (i.e., application level response). In this example (shown in Figure 6),the implementations behind ALU and BA provisionally book seats while Xantas actually reserves a seat. The Xantas service implementation conveys this information to the BA coordinator which then knows it must inform the associated participant to compensate ("unbook" the seat) in the event the parent scope has to eventually undo the entire reservation process or the agent obtains a cheaper quote; the other services do not have to compensate because they have not performed any state changes.

Figure 6, Making the requests

Based on the prices returned, the travel agent decides to go ahead and book the two-legged flight offered by Xantas and ZA, shown in Figure 7 .Because ALU did not reserve seats, there is no need to cancel the ALU flight.

Figure 7, Canceling a quote.

Since the flight chosen involves two parties, Xantas and ZA, the Travel Agent then requests ZA to reserve a seat. ZA acknowledges the reservation. The participant then tells the coordinator that the task has completed (Figure 8).

Figure 8, Choosing the right quote.

The application has now chosen the seat reservations that are to be included in the overall booking. You will notice that the final set of participants chosen must terminate atomically. In the example ZA and Xantas need to make commitment to the transaction and complete as an atomic set. We could have shown this as an atomic transaction within the scope of the overall business application, but instead we chosen to illustrate a more simple scenario where the Travel Agent forces this outcome directly.

The Coordinator now has received acknowledgments from Xantas.com and ZA.com, and the requested portions of the business transaction Travel Agent have completed. The coordinator therefore goes ahead and confirms the Business Activity (via close shown in shown in Figure 9) the seat reservations offered by ZA.com and Xantas.com.

Figure 9, Travel agent forcing the outcome.

If ALU had reserved a seat then the Travel Agent would need to instruct ALU to cancel the booking. The transaction service would then remove ALU from the tasks participating in the transaction. The Travel Agent would then confirm the reservation for the remaining tasks as shown in Figure 10.

Figure 10, Travel agent confirming the quote.

Conclusions

It has long been realised that ACID transactions by themselves are not adequate for structuring long-lived applications and much research work has been done on developing specific extended transaction models. However, until the advent of the CORBA Activity Service framework, no middleware support for building extended transactions was available. The Activity Service provides a general purpose event signalling mechanism that can be programmed to enable activities to coordinate each other in a manner prescribed by the model under consideration.

Unfortunately, despite it also being adopted with J2EE, there were few opportunities for using extended transactions in these environments. It was not until the advent of Web Services, where applications are typically loosely coupled and interactions last for hours or days, that the need for extended transactions overtook that for traditional ACID transactions [20]. The principles defined within the original OMG work, separation of general coordination from specific protocol, were embraced. The fact that the Web Services architecture is still under development also means that the fundamental requirements for coordination that are encapsulated within the WS-Coordination specification, have not been provided elsewhere, which was certainly a contributing factor to the slow acceptance of the Activity Service within the OMG and J2EE.

It is worth noting that the WS-TX effort is not the first attempt at producing a standard for Web Services transactions. In 2001, a consortium of companies including Hewlett-Packard, Oracle and BEA began work on the OASIS Business Transaction Protocol (BTP) [21], which was aimed at business-to-business transactions in loosely coupled domains such as Web Services. The specification developed two new models for "transactions", requiring business-level decisions to be incorporated within the transaction infrastructure. It was based on the premise that a single (two-phase) protocol is suitable for all use cases. Because the traditional two-phase algorithm does not impose any restrictions on the time between executing the first and second phases, BTP took the approach of using this to allow business-logic decisions to be inserted between the phases. What this means is that users have to drive the two phases explicitly in what BTP terms an open-top completion protocol. The application has complete control over when transactions prepare, and using use whatever business logic is required later determine which transactions to confirm or cancel. Prepare becomes part of the service business logic, for example.

This work did not succeed because of lack of acceptance of the notion that one protocol can fit all use cases. Therefore, building upon the Activity Service concepts, in 2003 Arjuna, Oracle, Sun Microsystems, IONA Technologies and Fujitsu founded the OASIS Web Services Composite Application Framework [22], which has similar goals to WS-TX and defines three transaction protocols, each aimed at a specific use case.

However, there is still much debate as to the right approach. Does one-size really fit all? Is inserting business logic directly within the transaction protocol the right abstraction? The argument for a single protocol is that all of the models examined are two-phase, albeit with different names for the phases. However, proponents of the multi-protocol approach argue that despite the fact most models are two-phase, there are different semantics associated with each phase and it is those semantics that are important.

One thing that most people agree on, however, is that ACID transactions have been invaluable over the years in the construction of enterprise applications. Unfortunately, they are only really suited to short duration activities executing on closely coupled applications and environments. When used in a loosely coupled environment, they prove too inflexible and restricting for many applications. The work to incorporate extended transaction models that allow the relaxation of ACID properties began in the OMG, but has proven more valuable within the evolving Web Services arena.

References

[1] X/Open CAE Specification - Distributed Transaction Processing: The XA Specification, X/Open Document Number XO/CAE/91/300.

[2] Web Services Transaction Technical Committee, OASIS,

[3] J. N. Gray, "The transaction concept: virtues and limitations", Proceedings of the 7th VLDB Conference, September 1981, pp. 144-154.

[4] D. J. Taylor, "How big can an atomic action be?", Proceedings of the 5th Symposium on Reliability in Distributed Software and Database Systems, Los Angeles, January 1986, pp. 121-124.

[5] OMG Object Transaction Service, http://www.omg.org/cgi-bin/apps/do_doc?formal/02-08-07.pdf

[6] C. T. Davies, "Data processing spheres of control", IBM Systems Journal, Vol. 17, No. 2, 1978, pp. 179-198.

[7] A. K. Elmagarmid (ed), "Transaction models for advanced database applications", Morgan Kaufmann, 1992.

[8] H. Garcia-Molina and K. Salem, "Sagas", Proceedings of the ACM SIGMOD International Conference on the Management of Data, 1987.

[9] S. K. Shrivastava and S. M. Wheater, "Implementing fault-tolerant distributed applications using objects and multi-coloured actions", Proc. of 10th Intl. Conf. on Distributed Computing Systems, ICDCS-10, Paris, June 1990, pp. 203-210.

[10] G.Weikum, H.J.Schek, "Concepts and Applications of Multilevel Transactions and Open Nested Transactions", in Database Transaction Models for Advanced Applications, ed. A.K. Elmagarmid, Morgan Kaufmann, 1992.

[11] G. Alonso, D. Agrawal, A. El Abbadi, M. Kamath, R. Gunthor and C. Mohan, "Advanced transaction models in workflow contexts", Proc. of 12th Intl. Conf. on Data Engineering, New Orleans, March 1996.

[12] OMG Additional Structuring Mechanisms for the OTS, http://www.omg.org/cgi-bin/apps/do_doc?formal/02-09-03.pdf

[13] I. Houston, M. Little, et al. "The CORBA Activity Service Framework for Supporting Extended Transactions", Proceedings of Middleware 2001, Heidelberg, 2001.

[14] "J2EE Activity Service for Extended Transactions", http://www.jcp.org/jsr/detail/95.jsp

[15] BTP Committee specification, http://www.oasis-open.org/committees/business-transaction/, April 2002.

[16] "A Framework for Implementing Business Transactions on the Web", Hewlett-Packard initial submission to BTP, March 2001, http://www.oasis-open.org/committee/business-transactions/

[17] "The Business Transactions Protocol. Transactions for a New Age", Mark Little, in Web Services Journal, Volume 2, Issue 10 (October 2002), pp. 56-60.

[18] "Shootout at the transaction corral; BTP versus WS-T", http://www.objectwatch.com/issue_41.htm

[19] Results of WS-Transactions Interoperability Workshop,

[20] Business Process Execution Language for Web Services, version 1.1, http://www.oasis-open.org/committees/download.php/2046/BPEL%20V1-1%20May%205%202003%20Final.pdf

[21] BTP Committee specification, http://www.oasis-open.org/committees/business-transactions/, April 2002.

[22] The Web Services Composite Application Framework Technical Committee, http://www.oasis-open.org/committees/documents.php?wg_abbrev=ws-caf

mark.little@jboss.com

Rate this Article

Adoption
Style

BT