[March 30, 2001] The Business Transactions Technical Committee will develop technology for business transactions on the Internet. Long lasting business transactions spanning multiple enterprises pose a unique challenge to B2B systems. The interdependent workflows among multiple trading partners, which drive business transactions, need to be coordinated to ensure that the outcome of the transaction is reliable. The purpose of this committee is to develop an agreed to set of requirements for a business transaction protocol; evaluate the BEA technology submission and other available technologies made available to the committee and determine their suitability to the requirements identified by the committee; and produce a final specification for a business transaction protocol which works in conjunction with existing business messaging standards, particularly those being developed in the ebXML initiative."

[December 24, 2004]   OASIS Technical Committee Advances Business Transaction Protocol (BTP) Specification.    OASIS has announced the approval of its Business Transaction Protocol Version 1.1 as a Committee Draft. BTP Version 1.1 represents a revision of the Version 1.0 specification in the light of feedback and implementation experience. The Business Transaction Protocol (BTP) is a carrier-neutral protocol designed "to allow coordination of application work between multiple autonomous, cooperating participants. It defines protocol exchanges to ensure the overall application achieves a consistent result. This consistency may be defined a priori: all the work is confirmed or none is (an atomic business transaction or atom); or it can be determined by application intervention in the selection of the work to be confirmed (a cohesive business transaction or cohesion)." The OASIS Business Transaction Protocol specification defines the protocol "in terms of abstract messages schematized in XML. It defines communications protocol bindings to SOAP, but also allows the transport of BTP messages over other communication protocols. BTP is based on a permissive and minimal approach where constraints on implementation choices are avoided. The protocol also tries to avoid unnecessary dependencies on other standards, with the aim of lowering the hurdle to implementation." BTP "provides the means to associate and coordinate the requests, responses, and outcomes for distributed applications elements. At a most simple level BTP allows a set of remote calls to be grouped together and the outcomes tied together. It allows for all or nothing outcome, mixed outcome, service alternative recognition and selection, time qualification, and exception reporting."

[October 29, 2001]   OASIS Business Transaction Protocol Technical Committee Publishes Revised BTP Specification.    A revised and 'pre-final' draft of the Business Transaction Protocol has been released by members of the OASIS Business Transactions Technical Committee. The committee is developing the specification to define an XML-based protocol for managing complex, B2B transactions over the Internet. The OASIS BTP Technical Committee "began its work at an inaugural meeting in San Jose, California on 13-March-2001. BTP uses a two-phase outcome coordination protocol to create atomic effects (results of computations). BTP also permits the composition of such atomic units of work (atoms) into cohesive business transactions (cohesions) which allow application intervention into the selection of the atoms which will be confirmed, and of those which will be cancelled. BTP is designed to allow transactional coordination of participants which are part of services offered by multiple autonomous organizations (as well as within a single organization). It is therefore ideally suited for use in a Web Services environment. For this reason this specification defines communications protocol bindings which target the emerging Web Services arena, while preserving the capacity to carry BTP messages over other communication protocols. Protocol message structure and content constraints are schematized in XML, and message content is encoded in XML instances... The BTP is an interoperation protocol which defines the roles which software agents (actors) may occupy, the messages that pass between such actors, and the obligations upon and commitments made by actors-in-roles. The BTP is based on a permissive and minimal approach, where constraints on implementation choices are avoided. The protocol also tries to avoid unnecessary dependencies on other standards, with the aim of lowering the hurdle to implementation." [Full context]

Overview of the Business Transaction Protocol: "A Business Transaction is a consistent change in the state of a business relationship between two or more parties. BTP provides means to allow the consistent and coordinated changes in the relationship as viewed from each party. BTP assumes that for a given business transaction state changes occur, or are desired, in some set of parties, and that these changes are related in some business-defined manner. Typically business-defined messages ('application messages') are exchanged between the parties to the transaction, which result in the performance of some set of operations. These operations create provisional or tentative state changes (the transaction's effect). The provisional changes of each party must either be confirmed (given final effect), or must be cancelled (counter-effected). Those parties which are confirmed create an atomic unit, within which the business transaction has a consistent final effect. The meaning of 'effect', 'final effect' and 'counter-effect' is specific to each business transaction and to each party's role within it. A party may log intended changes (as its effect) and only process them as visible state changes on confirmation (its final effect). Or it may make visible state changes and store the information needed to cancel (its effect), and then simply delete the information needed for cancellation (its final effect). A counter-effect may be a precise inversion or removal of provisional changes, or it may be the processing of operations that in some way compensate for, make good, alleviate or supplement their effect. To ensure that confirmation or cancellation of the provisional effect within different parties can be consistently performed, it is necessary that each party should (1) determine whether it is able both to cancel (counter-effect) and to confirm (give final effect to) its effect (2) report its ability or inability to cancel-or-confirm (its preparedness) to a central coordinating entity After receiving these reports, the coordinating entity is responsible for determining which of the parties should be instructed to confirm and which should be instructed to cancel. Such a two-phase exchange (ask, instruct) mediated by a central coordinator is required to achieve a consistent outcome for a set of operations. BTP defines the means for software agents executing on network nodes to interoperate using a two-phase coordination protocol, leading either to the abandonment of the entire attempted transaction, or to the selection of an internally consistent set of confirmed operations. BTP centres on the bilateral relationship between the computer systems of the coordinating entity and those of one of the parties in the overall business transaction..." [from the pre-final 1.0 Committee Specification]

On March 26, 2001 Karl Best announced the formation of mailing lists for BT subcommittees: Messaging (bt-messaging); Security (bt-security); Transaction models (bt-models); Interoperability (bt-interop); Specification (bt-spec); Workflow (bt-workflow).

[January 19, 2001] Background:    OASIS Technical Committee for Business Transactions.    BEA systems is presenting its 'Business Transaction Protocol (BTP)' as an initial specification in the work of a new OASIS Technical Committee for Business Transactions. From the recent announcment: "A new OASIS technical committee is being formed. The Business Transactions Technical Committee has been proposed by Rocky Stewart, BEA Systems (chair); Pal Takacsi-Nagy, BEA Systems; Frederick Carter, Sun Microsystems; and Mark Hale, Interwoven. BEA Systems, a member of OASIS, proposes to start a Technical Committee in OASIS to develop technology for business transactions on the Internet. Long lasting business transactions spanning multiple enterprises pose a unique challenge to B2B systems. The interdependent workflows managed among multiple trading partners, which drive business transactions, need to be coordinated to ensure that the outcome of the transaction is reliable. As an initial input, BEA intends to offer a specification for our Business Transaction Protocol (BTP), which provides this functionality and is implemented in our Weblogic Collaborate product. BTP is an eXtensible Markup Language (XML)-based protocol for representing and seamlessly managing complex, multi-step business-to-business (B2B) transactions over the Internet. The protocol allows complex XML message exchanges to be tracked and managed as loosely coupled 'conversations' between and among businesses. BTP goes beyond the problem domain currently being addressed by ebXML and is independent of transport protocols and messaging frameworks. We believe that it can be layered on any underlying transport mechanism including ebXML Messaging, RosettaNet, or XML-PC (SOAP). The purpose of this committee is: (1) To develop an agreed to set of requirements for a business transaction protocol; (2) To evaluate the BEA technology submission and other available technologies made available to the committee and determine their suitability to the requirements identified by the committee; (3) To produce a final specification for a business transaction protocol which works in conjunction with existing business messaging standards, particularly those being developed in the ebXML initiative. BEA will make its detailed submission available by the end of February 2001, before the first meeting, and will make a presentation describing the proposed BTP technology at the first meeting." See also in this connection: (1) description of the OASIS Technical Committee Process, and (2) Jon Bosak's recent article, "A Scalable Process for Information Standards."

Principal References

• OASIS BT Committee
• Business Transactions TC Charter
• OASIS Business Transactions TC FAQ document
• Contacts [2004-12]: Bill Pope, (TC Chair) and Peter Furniss (Choreology Ltd)
• Business Transaction Protocol. Version 1.1, Working Draft 05 approved as OASIS Committee Draft (CD). BTP v1.1 CD XML Schemas and WSDLs:
  • Core schema
  • Qualifiers schema
  • Node state information schema
  • SOAP binding WSDL
  • SOAP services WSDL
  • Abstract WSDL
• Business Transactions TC mailing list archives
• Public comment mailing list: business-transaction-comment@lists.oasis-open.org

Articles, Papers, News

• [October 7, 2003] "A Comparison of Web Services Transaction Protocols. A Comparative Analysis of WS-C/WS-Tx and OASIS BTP." By Mark Little (Arjuna Technologies Ltd) and Thomas J. Freund (IBM). From IBM developerWorks, Web services. October 7, 2003. ['Up to August 2003 there were two contenders for the Web services transaction space: OASIS Business Transactions Protocol (BTP), and the Web Services Transactions (WS-Tx) specification. There have been several subjective articles and comments comparing BTP to WS-Tx, attempting to show that BTP can do everything WS-Tx can and ignoring the important differences that exist. This article will try to give an objective comparison of these two specifications and show how they both attempt to address the problems of running transactions with Web services. At the end of the article it should be apparent how and why WS-Tx and BTP are different, while at the same time illustrating where they do have some commonality.'] "In 2001, a consortium of companies including Hewlett-Packard, Oracle and BEA began work on the OASIS Business Transaction Protocol (BTP), which was aimed at business-to-business transactions in loosely-coupled domains such as Web services. By April 2002 it had reached the point of a committee specification. However, others in the industry, including IBM, Microsoft, and BEA released their own specifications: Web Services Coordination (WS-C) and Web Services Transactions (WS-T)... Although we'll examine this in more detail later, they key differences between these specifications can be roughly categorized as follows: (1) BTP is not specifically about transactions for Web services -- the intention was that it could be used in other environments. As such, BTP defines the transactional XML protocol and must specify all of the service dependencies within the specification. WS-C and WS-Tx are specifically for the Web services environment and hence build on the basic definition of a Web services infrastructure. (2) The foundations of WS-Tx are based on traditional transaction infrastructures, where there is a strong separation between the functional aspects of business logic and the non-functional aspects of using transactions within an application. BTP essentially started from scratch and requires business-level decisions to be incorporated within the transaction infrastructure... In this paper we'll give an objective analysis of these two transaction protocols and compare and contrast the approaches they have taken. Because there are a number of good texts available on OASIS BTP we will not spend as much time describing that protocol as we will for WS-C and WS-Tx where less information is currently available... A few years ago the world of Web services and transactions looked like requiring new techniques to address the problems that it presented, and BTP was seen as the solution to those problems. Unfortunately, with the benefit of hindsight it did not address what users really want: the ability to use existing enterprise infrastructures and applications and for Web services transactions to operate as the glue between different corporate domains. Although the BTP model has some similarities with WS-Tx, the two specifications differ in some critical areas. For example, transaction interoperability: most enterprise transaction systems do not expose their coordinators through the two-phase protocol. In addition, BTP has many subtle (and some not-so-subtle) impacts on implementations, both at the transaction level and, more importantly, at the user/service level. Much has been made of the fact that ACID transactions aren't suitable for loosely-coupled environments like the Web. However, very little attention has been paid to the fact that these loosely-coupled environments tend to have large strongly-coupled corporate infrastructures behind them. Any Web services transactions specification should not ask 'what can replace ACID transactions?', but rather 'how can we leverage what already exists?' Note: The article concludes with a table showing a summary of the various differences and similarities between WS-C/T and BTP.

• [June 18, 2003] "Choreology Launches Cohesions 1.0: BTM Software for Application Coordination and Process Synchronization." - "Choreology Ltd, the business transaction management (BTM) software company, has released Cohesions 1.0, a coordination service that enables the synchronization of related business processes and the coordination of update operations spanning multiple applications. Cohesions ensures application-level consistency, and automated completion of business transactions, even in the event of failures. When processes and interactions between systems involve complex or high-value transactions, inconsistent business results can create serious costs, risks and delays which both afflict internal operations and damage customer relations and business reputation. Until now, there has not been a versatile solution, in product form, for the management of business transactions across applications. Traditionally, organizations have been faced with two choices: either they build complicated logic into their applications or they identify and manually repair transactional discrepancies after the fact. In either case the processes are costly and time-consuming to operate or construct. The management of business transactions spanning multiple applications is a common requirement across a broad range of business sectors. In investment and commercial banks applications include numerous aspects of straight through processing, transactional account aggregation and consistent cross-system data dispersal, such as distributed credit approval. In the insurance sector long-running transactions are common in policy and claims processing. Coordination of multiple systems is also needed in the telecommunications sector where service provisioning and billing applications are widespread. Cohesions implements OASIS Business Transaction Protocol and Web Services Coordination+Transaction. It works in the native Java environment and is also integrated with several leading Web Services toolkits - as well as working in the context of the developing Grid services environment. Cohesions is a critical underlay for reliable BPEL-based processes, simplifying their design and providing transactional control and automated recovery of business state. Cohesions is the culmination of two and a half years of theoretical and practical pioneering work in the developing field of business transaction management. The Cohesions product reflects the experience of Choreology's staff who have previously been involved in the engineering and marketing of three commercial transactional product lines..." On Web Services Coordination+Transaction, see: (1) WS-Coordination Specification Index Page and (2) WS-Coordination Transaction Index Page.

• [June 03, 2002] "Business Transaction Protocol." OASIS Committee Specification. Organization for the Advancement of Structured Information Systems, Business Transactions TC. Version 1.0. 3-June-2002. 188 pages. This document, which describes and defines the Business Transaction Protocol (BTP), is a Committee Specification of the Organization for the Advancement of Structured Information Standards (OASIS). The standard has been authored by the collective work of representatives of numerous software product companies, grouped in the Business Transactions Technical Committee (BT TC) of OASIS... BTP is designed to allow coordination of application work between multiple participants owned or controlled by autonomous organizations. BTP uses a two-phase outcome coordination protocol to ensure the overall application achieves a consistent result. BTP permits the consistent outcome to be defined a priori -- all the work is confirmed or none is -- (an atomic business transaction or atom) or for application intervention into the selection of the work to be confirmed (a cohesive business transaction or cohesion). BTP's ability to coordinate between services offered by autonomous organizations makes it ideally suited for use in a Web Services environment. For this reason this specification defines communications protocol bindings which target the emerging Web Services arena, while preserving the capacity to carry BTP messages over other communication protocols. Protocol message structure and content constraints are schematized in XML, and message content is encoded in XML instances..." See also the XML schemas. [cache]

• [June 05, 20002] "Business Transaction Protocol Primer." Version: 1.0. 3-June-2002. By: OASIS Business Transactions TC. An OASIS Committee Supporting Document. "The Business Transaction Protocol, or 'BTP,' provides a common understanding and a way to communicate guarantees and limits on guarantees between organizations. The formal rules are necessary for the distribution of parts of business processes outside the boundaries of an organization. BTP solves part of the problem for developers of loosely coupled transactions -- the coordination and forcing a consistent termination portions. Expertise in the design of compensating actions is still required, but these compensations are local rather than distributed." Also in PDF format. [cache]

• Use Cases for the Business Transaction Protocol

• [October 08, 2002] "Shootout At The Transaction Corral: BTP Versus WS-T." By Roger Sessions (Austin, Texas). In ObjectWatch Newsletter Number 41 (October 3, 2002). "... The joint IBM, BEA, Microsoft standard is called WS-T, which stands for Web Service-Transactions. The other standard is an effort of the Business Transactions Technical Committee of OASIS (Organization for the Advancement of Structured Information Standards). The contributors to this standard are Sun, Oracle, BEA, HP, and assorted riff-raff. This standard is known as BTP, which stands for Business Transaction Protocol... Both standards agree on two things. First, they both agree that they are focusing on transactions that span web services (what the cognoscenti would call software fortresses). Second, they both agree on the term transactions to describe the collection of work that must be coordinated across web services, although they do not agree on exactly what a transaction is... BTP is older than WS-T, but only by two months. BTP came out June 3, 2002. WS-T came out August 2, 2002. The failure of OASIS to get backing from either IBM or Microsoft and apparently only lukewarm backing from BEA must have been somewhat demoralizing, given that these three companies control virtually every business transaction processed in the world today. Then, when these three companies came out with a competing standard just two months later, the impact could only have been devastating to OASIS. These two standards leave you, the enterprise architect, in a rather difficult situation. BTP and WS-T are very different standards that do very similar types of work. Realistically, you can design your web service to be compatible with one or the other, but not both. Which should you choose? Which one is most likely to become the most widely adopted? ... Given all of my criticisms of WS-T, you might think that I favor the BTP standard. To some extent, this is true. BTP starts, for example, with a better understanding of the underlying problem that needs to be solved. BTP assumes that the transactions one wants to coordinate across web services are very different in nature than the all or nothing transactions that are the focus of WS-T's ATs. This, in itself, is a major improvement. BTP assumes, correctly, that the coordination needed between different web services (or what I would call software fortresses) is more of a contract coordination than a tightly coupled transaction coordination. And yet, even BTP has problems. Its biggest problem is, like WS-T, complexity. While it does not suffer from a confusing and useless inheritance model, it does include two different models for doing essentially the same thing with no reasonable explanation of why both are needed or even how one would choose between the two. BTP has both an 'atomic transaction' model and a 'cohesive transaction' model. The BTP atomic transaction model only sounds like the WS-T's atomic transactions (ATs). In fact, they are entirely different. BTP atomic transactions are just groupings of work that will either all complete or all fail/compensate. In this regard, they are much like WS-T's business activities (BA). My breakfast is a good example of a BTP atomic transaction..." See: "Web Services Specifications for Business Transactions and Process Automation."

• [October 07, 2002] "Web Services Infrastructure. Building Transactional Web Services with OASIS BTP." By Jim Webber (Arjuna Laboratory, Hewlett-Packard). In Web Services Journal Volume 2, Issue 10 (October 2002), pages 50-54. It's a fact: Web services have started to mature. Those emergent standards that once held so much promise are now actually starting to deliver useful implementations. With the basic Web services plumbing mastered, we're starting to see more advanced infrastructure, which enables these second-generation Web services to focus on complex interactions over the Internet. This article, the first of a two-part series, covers one such aspect of the second-generation infrastructure for Web services: transactions... The OASIS Business Transactions Protocol, or BTP, has become the prominent standard for Web services transactions. BTP is the product of just over a year's work by vendors such as HP, BEA, and Oracle, and has resulted in the development of a transaction model particularly suited to loosely coupled systems like Web services. In this article, we're going to look at how BTP fits into the whole Web services architecture, and how we can use one of the vendor toolkits (we'll use HP's toolkit, but the underlying principles apply to other vendors' software) to build and consume transaction-aware Web services. But before we do, let's review the architecture in the context of a simple transactional scenario. The diagram shown in Figure 1 is similar to a typical high-level Web services architecture. The only differences here are that one service, the transaction manager, has been singled out as being distinct from the other Web services (which we assume are responsible for some aspects of a business process), and the fact that we've chosen to identify two distinct categories of messages: control messages (which are used to control transactions) and application messages (which propagate application data around the system)..." See also the source code listings.

• [October 07, 2002] "The Business Transactions Protocol. Transactions for a New Age. Bringing ACID Models into the Web Services World." By Mark Little (Arjuna Laboratory, Hewlett-Packard). In Web Services Journal Volume 2, Issue 10 (October 2002), pages 56-60.

• [May 13, 2002] "The Business Transactions Protocol." By Mark Little. In EarthWeb (October 07, 2002). ['Is correct information critical to your site? Dr. Mark Little, of Hewlett Packard's Arjuna Labs, shows you how to guarantee consistency on your site by implementing the Business Transactions Protocol.'] "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, there are still important security and fault-tolerance considerations, which must be addressed. One of these is the fact that the Web frequently 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. 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. The structuring mechanisms available within atomic transaction systems are sequential and concurrent composition of transactions. These mechanisms are sufficient if an application function can be represented as a single atomic transaction. Transactions are most suitably viewed as 'short-lived' entities; they are less well suited for structuring "long-lived" application functions (e.g., running for hours, days, and so on). Long-lived atomic transactions may reduce the concurrency in the system to an unacceptable level by holding on to resources (e.g., locks) for a long time; further, if such a transaction rolls back, much valuable work could be undone. The OASIS Business Transactions Protocol specified by a collaboration of several companies, has tried to address this issue. In this paper we shall first consider why traditional atomic transactions are insufficient for long-running activities and then describe how the BTP has attempted to solve these problems..."

• [March 08, 2001]   Bea Presents Proposed Business Transaction Protocol Version 1.0 to OASIS TC.    BEA Systems, Inc. has submitted a proposed Business Transaction Protocol (BTP) specification to the OASIS Business Transactions Technical Committee. Authored by Sanjay Dalal and Pal Takacsi-Nagy, the 'starting point' specification proposal outlines a protocol "which can be used to orchestrate long running, inter-enterprise business transactions. It addresses the unique requirements of business-to-business transactions. BTP is based on the multi-level transaction model that provides the necessary independence for the participating resource managers -- in this case the B2B servers of companies engaging in business transactions." Document abstract: "Long lasting business transactions spanning multiple enterprises pose a unique challenge to B2B systems. The interdependent workflows among multiple trading partners, which drive business transactions, need to be coordinated to ensure that the outcome of the transaction is reliable. In this document we propose a solution to this problem in the form of a Business Transaction Protocol (BTP). B2B servers participating in business transactions over the Internet are expected to implement BTP to orchestrate multi-enterprise transactions." [Full context]

• [November 08, 2001] JAXTX "provides an API for packaging and transporting ACID transactions (as in JTA) and extended transactions (e.g., the BTP from OASIS) using the protocols being defined by OASIS, W3C." See the ballot results for the JSR #156 XML Transactioning API for Java (JAXTX) JSR Review Ballot. Details: "This specification will describe Java API's designed specifically for the management (creation and lifetime) and exchange of transaction information between participating parties in a loosely coupled environment. Rather than communicating via IIOP, such parties will typically use SOAP and XML document exchange to conduct business "transactions". If these "transactions" are to be conducted in an ACID transaction manner, then information (e.g., the transaction context) will need to accompany these XML documents and be managed appropriately. In addition, there is work going on within OASIS (the Business Transactions protocol) and the JCP community (JSR 95) to provide extended non-ACID transactions to users that will enable applications to run business transactions that span many organisations, last for hours, days, and weeks, and yet still retain some of the fault-tolerant and consistency aspects of traditional ACID transactions. The business community is working to converge on a set of standard message headers and industry-specific message payloads. It is planned that this JSR will leverage work currently under way in the OASIS, W3C, and potentially other relevant and open standards bodies to produce an API that will accomodate both strict ACID and relaxed ACID transactional applications. This JSR does not aim to define either XML messaging standards or XML schemas for particular tasks. These networking and formatting standards belong in networking standards bodies such as Oasis or IETF. Instead this JSR aims to define standard Java APIs to allow convenient access from Java to emerging XML messaging standards."

• BEA Proposal for Business Transaction Protocol Version 1.0. In Zipped .DOC format, as submitted. Also Proposal for Business Transaction Protocol Version 1.0 in [unofficial] PDF format.

• [March 13, 2001] "Scope of a Cohesion Protocol Specification." From Alastair Green and Peter Furniss (Choreology Ltd). 12 March 2001. 8 pages. For the OASIS Business Transactions Technical Committee: Choreology Ltd submission to the Inaugural BT Meeting on 13 March 2001, at San Jose, CA. "Long-running 'business transactions' which may be processed by discrete organizations across the public internet differ from classical atomic transactions in requiring increased protocol security and interoperability, and relaxable atomicity, isolation and durability properties. A protocol is required which is independent of communications mechanism, is capable of supporting fully ACID transaction processing, yet is also capable of supporting different AID qualities of service. Such a protocol would provide 'appropriate transactionality' to applications. 'Cohesive' actions (cohesions) could be processed as a superset of atomic actions, thus enabling a clean integration of legacy transactional resources and services, when appropriate... It is widely perceived that inter-organizational long-duration business transactions require a new protocol or protocols to assist applications in providing reliable service and consistent results. However, the complex logic of extended machine-to-machine conversations will necessarily be an application concern, often assisted by a business process manager. This paper is intended to help in drawing a reasonable boundary between protocol (the concern of the BT TC) and process (the concern of other standardization efforts or of the application). Our principal guide is that a BT protocol should not be aware of application control flow, application message content, or operation algorithms and effect. This criterion excludes business process definition and trading protocols (such as ebXML, in that role). We believe that this leaves three distinct problems which are the potential concern of the Technical Committee: communications, interoperability/security, and ACIDity. In this initial submission we restrict our comments largely to the latter two problems..." [source]

• [March 30, 2001] "A Framework for Implementing Business Transactions on the Web." Hewlett-Packard initial submission to OASIS BTP work. By Dr. Mark Little (Transactions Architect, HP Arjuna Labs, Newcastle upon Tyne, England), with Dave Ingham, Savas Parastatidis, Jim Webber, and Stuart Wheater. 20 pages (with 11 notes). [See the posting from Mark Little.] "An increasingly large number of distributed applications are constructed by being composed from existing applications. The resulting applications can be very complex in structure, with complex relationships between their constituent applications. Furthermore, the execution of such an application may take a long time to complete, and may contain long periods of inactivity, often due to the constituent applications requiring user interactions. In a loosely coupled environment like the Web, it is inevitable that long running applications will require support for fault-tolerance, because machines may fail or services may be moved or withdrawn. A common technique for fault-tolerance is through the use of atomic transactions, which have the well know ACID properties, operating on persistent (long-lived) objects. Transactions ensure that only consistent state changes take place despite concurrent access and failures... From the previous discussions it should be evident that there are a range of applications that require different levels of transactionality. Many types of business transaction do not have the simple commit or rollback semantics of an ACID transaction, and may complete in a number of different ways that may still be interpreted as successful but which do not imply everything that the business transaction did has occurred. We have shown that a flexible and extensible framework for extended transactions is necessary, then in addition to standardising on the interfaces to this framework, we also need to work on specific extended transaction models that suit the Web. We would not expect applications to work at the level of Signals, Actions and SignalSets, as these are too low-level. Higher-level APIs are required to isolate programmers from these details. However, from experience we have found that this framework helps to clarify the requirements on specific extended transaction implementations. We have given examples of the types of Web applications that have different requirements on any transaction infrastructure, and from these we believe it should be possible to obtain suitable extended transaction models." Other issues that will need to be considered when implementing many business transactions include: (1) Security and confidentiality... (2) Audit trail... (3) Protocol completeness guarantee... (4) Quality of service..."