Contents

• Overview
• Principal Specifications and Standards Activities
• Articles, Papers, News

Overview

This document references specifications and standards activities related to coordination of messages/transactions, especially in the Web Services arena. A list of citations for general works (papers, presentations) follows.

---

Principal Specifications and Standards Activities

• Business Process Execution Language for Web Services (WS-BPEL/BPEL4WS)
• WS-BPEL Extension for People (BPEL4People)
• WS-BPEL Extension for Sub-Processes (BPEL-SPE)
• Business Transaction Protocol (BTP)
• OASIS Asynchronous Service Access Protocol TC
• OASIS Web Services Composite Application Framework (WS-CAF) Technical Committee
• OASIS Web Services Transaction (WS-TX) Technical Committee
• W3C Web Services Choreography Working Group
• Web Service Choreography Interface (WSCI)
• Web Service Composite Applications Framework (WS-CAF)
  • Web Service Context (WS-CTX)
  • Web Service Coordination Framework (WS-CF)
  • Web Services Transaction Management (WS-TXM)
• Web Services Choreography Description Language (WS-CDL)
• Web Services Conversation Language (WSCL)
• Web Services Transaction Framework
  • Web Services Coordination (WS-Coordination)
  • Web Services Atomic Transaction (WS-AtomicTransaction)
  • Web Services Business Activity Framework (WS-BusinessActivity)
• WS Choreography
• Related Work (not further abstracted or referenced):
  • Business Process Management Initiative Specifications (BPML, BPMN, BPQL)
  • Business Process Specification Schema (BPSS), including:
    • ebXML.org [ebBPSS] and Business Process Specification Schema v1.01
    • UN/CEFACT Business Process Specification Schema Project and UN/CEFACT's ebXML BPSS V1.09 Review Draft [source]
  • OMG Business Process Definition
  • Workflow Standard XML Process Definition Language (XPDL)
  • Web Services Flow Language (WSFL)
  • XLANG

---

Articles, Papers, News

• [March 13, 2006] "Modeling Web Services Choreography with New Eclipse Tool: Dancing with BPMN and New Eclipse Tool pi4soa." By Michael Havey. From SYS-CON SOA Web Services Journal (February 04, 2006). "[It is] incorrect to say that a process choreographs its services. Choreography describes the global protocol that governs how individual processes interact with one another. Each process offers its own services and uses services of partner processes. It is correct to say that a process orchestrates these services, but the view from one process is only the behavior of that process in terms of its partners. Choreography presents the unified global view, depicting all of the processes and their required interactions. Web Services Choreography Description Language (WS-CDL) is the leading choreography language, and Business Process Execution Language (BPEL) is the dominant process orchestration language. Though both XML-based languages feature a similar flow-oriented design style, only BPEL is meant to have an actual run-time platform: BPEL processes run, and WS-CDL choreographies are formal specifications documenting rules to guide interprocess exchange. There are no traffic cops in this laissez faire world, only traffic laws and law-abiding drivers. This article focuses on two parts of the choreography cycle: modeling and code refinement. In the modeling area, there are plenty of good business process tools supporting UML and BPMN from which to choose, but none of them can generate WS-CDL output directly. Many can export models in a canonical form (e.g., XML metamodel interchange, or XMI), but there are no third-party tools that can generate WS-CDL code from that form. An open-source version of the proposed code editor, to our delight, is now available in alpha form. The tool, known as Pi Calculus for Service-Oriented Architecture (pi4soa, developed by the company Pi 4 Technologies), is an Eclipse plugin that provides a graphical editor to compose WS-CDL choreographies and generate from them compliant BPEL..."

• [September 30, 2005] "Web Services Transactions: A Practitioner's Approach." By Manish Verma (Center Head and VP Delivery, Second Foundation). From IBM developerWorks. September 30, 2005. "Transactions are an important building block in all serious business applications. A transaction is a unit of work that involves one or more resources and is either completed in its entirety or is not done at all. Participating resources are locked for the duration of the transaction. Depending on the readiness of all the participating resources, the changes made to the resources are either committed or rolled back, and the lock is released... Many developers have grown comfortable with ACID-based transactions, but with business software growing more complex, such transactions no longer address all scenarios. Hence, you might need a different transaction type for scenarios in which: (a) transactions are long running; (b) transaction participants are not under the control of a single authority; (c) the outcome of a transaction might differ from the individual participant's outcome. This article examines an alternative transaction type, the compensation-based transaction. The author shows you how Web services transactions are different from normal transactions, and demonstrates how to create Web services that can participate in transactions." See: "OASIS Members Form Web Services Transaction (WS-TX) Technical Committee."

• [March 24, 2005] Dancing with Web services: W3C Chair Talks Choreography." By Nitin Bharti. From SearchWebServices.com (March 09, 2005). "As companies embrace service-oriented architecture, the Business Process Execution Language (BPEL) continues to gain traction as a means to weave Web services into meaningful business processes. While BPEL allows existing services to be orchestrated into composite services, the Web Services Choreography Description Language (WS-CDL) goes a step further and describes the relationships between services in a peer-to-peer scenario. In this interview, Steve Ross-Talbot, co-chair of the W3C Web Services Choreography Working Group, describes choreography and how it differs from orchestration in the context of Web services. He compares the WS-CDL and BPEL specifications, looks at how the two can work together and describes four tools that will be needed to work with WS-CDL. Ross-Talbot: "Any real business transaction isn't just one function call, it's a sequence of function calls and it may be lots of things in parallel between different services that occur. BPEL is about 'how do I construct Web services out of existing Web services.' In other words, BPEL is about the orchestration of existing services to yield another service. Choreography is completely complementary to that. WS-CDL is an unambiguous way of describing the relationships between the services in a peer-to-peer collaboration without necessitating any orchestration at all. That's very important because if my business and your business are talking together, I can guarantee you that neither of us would accept orchestrating the other's services. On the orchestration side of it, which is what BPEL does, that comes in on your side of the firewall and my side of the firewall in order for me to reuse my services. Now I might include in my orchestration, one of your services but then present it as my service; however, I'm really calling out to your service. So with BPEL I'm the conductor in the pit. In any dance, however, you never see somebody on stage telling the dancers what to do. The dancers have a choreography description. I know this because my daughter's a dancer. They learn their dance and they learn the 'touch points' where they interact with others, the same way you do in a choreography description... Orchestration has more to do with the recursive composition of services so that it will yield another service. Orchestration gets realized as an executable, so you can identify the conductor in the pit and realize that he's as much an actor as the violinist. Choreography, on the other hand, is a description. The choreographer writes the descriptions down and gives it to the dancers and works with them to make sure they learn their parts, but he's not there as an 'executable actor' when it's happening. So choreography is purely a description, but it's a description that can be used to generate the behavior of the dancers. You can use it to generate, but it is not executable..."

• [September 02, 2004] "Tour Web Services Atomic Transaction Operations. Beginner's Guide to Classic Transactions, Data Recovery, and Mapping to WS-AtomicTransactions." By Thomas Freund (Senior Technical Staff Member, IBM) and Daniel House (Senior Technical Staff Member, IBM). September 02, 2004. From IBM developerWorks. "Explore how transactions work in one common and classic form to preserve data integrity, and apply that classical transaction description to the operations of the new Web Services Atomic Transactions (WS-AT) and related Web Services Coordination (WS-C) specifications. Mapping classical to Web services transactions helps you discover that Web Services Atomic Transactions embodies age-old common industry best practices for one kind of transaction. The authors look at classical transaction processing and how it enables data integrity across a number of actions by forcing an all-or-none semantic to the set of actions. Transaction processing using Web services is logically very similar to classical transaction processing. There is a relatively straightforward map from classic to Web services transactions and we mapped the Durable 2PC variety of Web Services Atomic Transaction as an illustration."

• [January 28, 2004] "Coordinating Web Services Activities with WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity." By Luis Felipe Cabrera, George Copeland, Jim Johnson, and David Langworthy. Microsoft White Paper. January 28, 2004. Learn "how the new WS-Coordination specification relates to the WS-AtomicTransaction and WS-BusinessActivity specifications. These specifications collectively provide the necessary mechanisms to create activities, join in activities, and reach common agreement on the outcome of joint operations across distributed systems... WS-Coordination provides uniformity for the creation, propagation, and joining of a distributed activity. WS-AtomicTransaction and WS-BusinessActivity extend this with agreement coordination protocols. Together they provide coordination mechanisms to handle exceptions from a wide variety of sources, ranging from hardware to software to the real world. In conjunction with other Web services standards, we expect them to be useful for applications where the scope spans from an organization within an enterprise, across different organizations in an enterprise, across enterprises, and across different vendor platforms..."

• [October 28, 2003] "Secure, Reliable, Transacted Web Services: Architecture and Composition." By Donald Ferguson (IBM Fellow and Chairman IBM Software Group Architecture Board, IBM Corporation), Tony Storey (IBM Fellow, IBM Corporation), Brad Lovering (Distinguished Engineer, Microsoft Corporation), and John Shewchuk , Web Services Architect (Microsoft Corporation). From IBM developerWorks. October 28, 2003. "This paper provides a succinct overview for the set of Web service specifications that addresses the needs of security, reliability, and transactability. For the details of the specifications it provides references to the actual documents.The main purpose of this paper is to briefly define the value these specifications provide to our customers. It also describes how these specifications complement each other to compose robust environments for distributed applications... IBM, Microsoft, and our partners are developing Web service specifications that can be used as the building blocks for a new generation of powerful, secure, reliable, transacted Web services. These specifications are designed in a modular and composable fashion such that developers can utilize just the capabilities they require. This 'component-like' composability will allow developers to create powerful Web services in a simple and flexible manner, while only introducing just the level of complexity dictated by the specific application. These Web service technologies enable organizations to easily create applications using a Service-Oriented Architecture (SOA). Furthermore, IBM and Microsoft have demonstrated secure, reliable, transacted SOA applications that illustrate the richness of the business processes that can be created using this approach. Moreover, these demonstrations have been operating in a federated security environment on a heterogeneous collection of systems running IBM WebSphere and Microsoft .NET software..." Also available from Microsoft.

• [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. See also: "OASIS Business Transactions Technical Committee."

• [October 06, 2003] "Web Services Orchestration and Choreography." By Chris Peltz (Hewlett-Packard Company). In IEEE Computer Volume 36, Number 10 (October 2003), pages 46-52 (with 6 references). ['Combining Web services to create higher level, cross-organizational business processes requires standards to model the interactions. Several standards are working their way through industry channels and into vendor products.'] "The terms orchestration and choreography describe two aspects of emerging standards for creating business processes from multiple Web services. The two terms overlap somewhat, but orchestration refers to an executable business process that can interact with both internal and external Web services. Orchestration always represents control from one party's perspective. This distinguishes it from choreography, which is more collaborative and allows each involved party to describe its part in the interaction. Proposed orchestration and choreography standards must meet several technical requirements that address the language for describing the process workflow and the supporting infrastructure... Proposed orchestration and choreography standards must meet several technical requirements for designing business processes that involve Web services. These requirements address both the language for describing the process workflow and the supporting infrastructure for running it. First, asynchronous service invocation is vital to achieving the reliability and scalability that today's IT environments require. The capability to invoke services concurrently can also enhance process performance. Implementing asynchronous Web services requires a mechanism to correlate requests with each other. Software architects commonly use correlation identifiers for this purpose. The process architecture must also provide a way to manage exceptions and transactional integrity. In addition to handling errors and time-out constraints, orchestrated Web services must ensure resource availability for long-running distributed transactions. Traditional ACID (atomicity, consistency, isolation, and durability) transactions are typically not sufficient for long-running, distributed transactions because they cannot lock resources in a transaction that runs over a long time. The notion of compensating transactions offers a way to undo an action if a process or user cancels it. With compensating transactions, each method exposes an undo operation that a transaction coordinator can invoke if necessary. Web services orchestration must be dynamic, flexible, and adaptable to meet changing business needs... While BPEL4WS, WSCI, and BPML work their way through standards processes and into vendor product implementations, other enhancements and issues relevant to Web services orchestration are emerging. IBM researchers have proposed a peer-to-peer model of e-business interaction. They compare current Web services to a vending machine -- a set number of buttons that can be pressed in a predefined order. They propose a conversational model -- more like a telephone call with flexible, dynamic exchanges between the parties at each end. At this time, IBM's Conversation Support for Web Services is the only proposal that claims to support this capability..."

• [August 27, 2003] "BPEL and Business Transaction Management: Choreology Submission to OASIS WS-BPEL Technical Committee." By Tony Fletcher, Peter Furniss, Alastair Green, and Robert Haugen (Choreology Ltd). Copyright (c) Choreology Ltd, 2003, subject to OASIS IPR Policy. Working paper presented to the OASIS Web Services Business Process Execution Language Technical Committee. "An overall motivation for this submission is given in an article by one of the authors, Alastair Green, in the September issue of Web Services Journal (see following bibliographic entry). From the 27-August-2003 posting of Peter Furniss: "... [WRT] the announcements of a raft of issues on "business transaction management". These all relate to the long-promised submission from Choreology on how to handle transactions in BPEL... The submission gives the background and context for the BTM issues and proposes syntax constructs as solutions for [items] 54 to 59" in the issues list... "BTM Issue A (BPEL issue 53), Desirable for WS-BPEL to include Business Transaction Management (BTM) programming constructs which are compatible with WS-T, BTP and WS-TXM, "There are three multi-vendor specifications which address the needs of business transaction management for Web Services: Business Transaction Protocol 1.0 (OASIS Committee Specification, June 2002); WS-Transaction (proprietary consortium, August 2002), and the very recently published WS-TXM (proprietary consortium, August 2003). In our view BTP Cohesions, WS-T Business Activity, and WS-TXM Long-Running Actions are the most relevant aspects of these specifications for WS-BPEL. These aspects overlap to a very high degree, each effectively utilizing a two-phase (promise/decide) outcome protocol. (We should emphasize that there has been little time to analyze or assimilate WS-TXM, so this is a provisional conclusion with respect to that specification). WS-BPEL should be equipped with the ability to create and terminate business transactions, and to define process participation in such transactions, in a way which is compatible with the intersection of these three capabilities. This will minimize dependence on future standardization efforts in the BTM area... It is should be noted that a 'business transaction' is normally performed in support of some economic transaction -- that it coordinates actions that have an effect on the parties and their relationships that go beyond the lifetime of the transaction itself. Since a BPEL process cannot directly manipulate data with a lifetime longer than the process, but always delegates to a web-service, the invoked web-services will either themselves be participants in the business transaction (strictly, the invocation will trigger the registration of participants) or the BPEL process will register as a participant and then make non-transaction invocations on other web-services. In the former case, the invoked web-services are 'business-transaction aware'; the BPEL process will export the context to it and the web-services will implement the transactional responsibilities internally. Similarly, a BPEL process, as an offerer of a web-service, may import a context from a non-BPEL application -- in which case it is itself a business-transaction aware web-service from the perspective of its caller -- and either registers as a participant or passes the context on in its own invocations..." General references in "Business Process Execution Language for Web Services (BPEL4WS)."

• [August 26, 2003] "Transacting Business with Web Services, Part I. The Coming Fusion of Business Transaction Management and Business Process Management." By Alastair Green (Choreology Ltd). In WebServices Journal Volume 3, Issue 9 (September 2003), pages 32-35. "Business transaction management (BTM) is a promising new development in general-purpose enterprise software. Most large companies are devoting significant resources to the problem of reliable, consistent integration of application services. BTM offers previously inaccessible levels of application coordination and process synchronization, radically simplifying the design and implementation of transactional business processes. Business process management (BPM) needs to be enriched by BTM for users to see the potential value of BPM realized in practice. XML is already widely deployed as a useful lingua franca enabling the creation of canonical data standards for particular industries, trading communities, and information exchanges. The extended family of Web services standards (clustered around the leading duo of SOAP and WSDL) is gaining growing acceptance as an important way of providing interoperable connectivity between heterogeneous systems. Many organizations are also examining the use of BPM technologies, exemplified by the current OASIS initiative, Web Services Business Process Execution Language (WS BPEL). Increasingly, attention is turning to the special problems associated with building transactional business processes and reliable, composable services. This is where BTM technology comes into its own. In this article I'm going to look at the rationale for and current status of BTM, and how vendors and users are thinking about the integration or fusion of BTM with BPM, particularly in the OASIS BPEL standardization effort. BPEL, as a special-purpose programming language designed to make processes portable across different vendors' execution engines, can become a very useful standard programming interface for business transactions in the Web services world... Full-scale BTM software needs to implement interoperable protocols that define three phases of any transactional interaction, whether integrating internal systems, or automating external trades and reconciliations: (1) Phase One: Collaborative Assembly: The business-specific interplays of messages that assemble a deal or other synchronized state shift in the relationship of two or more services. A useful general term for such an assemblage of ordered messages is collaboration protocol. Examples include RosettaNet PIPs, UN/Cefact trade transactions, and the FIX trading protocol. In the future, BPEL abstract processes should help greatly in defining such protocols. Reliable messaging has an important role in this assembly phase, but as a subordinate part of a new, extended concept of GDP (guaranteed delivery and processing). (2) Phase Two: Coordinated Outcome: The coordination of an outcome that ensures that the intended state changes occur in all participant systems, consistent with the business rules or contracts which govern the overall transaction. Examples of relevant coordination protocols are WS-Transaction (Atomic Transaction and Business Activity, supplemented by WS-Coordination) and BTP (the OASIS Business Transaction Protocol) and the recently released WS-TXM (Transaction Management, part of the WS-Composite Application Framework). A coordination protocol requires three related sub-protocols: a control protocol, which creates and terminates a coordination or transaction (present in BTP); a propagation protocol, which allows a unique transaction identity to be used to bind participating services to a coordination service (this sub-protocol is mostly defined by WS-Coordination); and an outcome protocol, which allows a coordination service to reliably transmit the instructions of a controlling application to the participants, even in the event of temporary process, processor or network failures. WS-T, BTP, and WS-TXM, contain very similar outcome protocols... (3) Phase Three: Assured Notification: Notification of the result of the transaction to the parties involved, ensuring that they're all confident of their final relationship to their counterparties. Ideally, this requires a reliable notification protocol, which allows the different legal entities or organizational units to receive or check the final outcome, including partial or complete failures..." General references in "Business Process Execution Language for Web Services (BPEL4WS)." [alt URL]

• [August 01, 2003] "Oracle, Sun and Partners Publish WS Coordination Specification." By [CBDi Newswire Staff]. In CBDI Newswire: Insight for Web Service and Software Component Practice (August 01, 2003). "Last August IBM, Microsoft and BEA published two specifications -- WS-Transaction and WS-Coordination. [With Web Services Composite Applications Framework (WS-CAF)] we now have a further specification covering a very similar area from Oracle, Sun and partners. At a capability level these specifications cover very similar functionality. At first sight the WS-Coordination specification looks to be tightly bound with BPEL, which of course Oracle and Sun are currently in opposition to. Whilst we are predicting that the broader industry will eventually converge around a BPEL like protocol, it is clear that this is currently very inadequate when compared to ebXML, and it will not happen soon. However in reality the interface between business process steps is a Web Service, and hence an agreed standard protocol. Neither specification has been submitted to a standards body yet, and this latest publication from Oracle Sun et al. seems like an attempt to bounce IBM et al. into a standards process that has broader representation. We think this is a good idea. The industry really needs to address how it is going to come together on the standards in the area of complex business transactions, and the arbitrary leadership of IBM, Microsoft plus a chosen partner (in this case BEA) is really inadequate for what is a complex and crucial set of protocols. We assess that the specifications are sufficiently close to be a basis for agreement on that specific area, without requiring the more difficult and contentious area of process scripting to be resolved concurrently..." Note: The "Global XML Web Services Specifications" from Microsoft and its partners include WS-Coordination and WS-Transaction; see also "Understanding GXA." Commentary is provided in the Web Services Journal articles by Jim Webber and Mark Little: "Introducing WS-Coordination"; "Introducing WS-Transaction Part 1"; "Introducing WS-Transaction Part 2." See references in the news story "Web Services Composite Application Framework (WS-CAF) for Transaction Coordination."

• [July 29, 2003] "Sun's Proposed New Web Services Standards." By Charles Babcock. In InformationWeek (July 39, 2003). "Sun is trying to initiate a new round of Web services with a proposal for a set of standards that work on top of XML and Web Services Description Language (WSDL). But Sun and its partners have yet to say to which standards body they will submit their proposed specification... Arjuna Technologies, Fujitsu Software, Iona Technologies, Oracle, and Sun have teamed up to propose that individual Web services be called up and combined to form 'composite applications.' Through Sun's proposed set of standards, such a composite application would be given a shared runtime environment that could determine the specific systems contributing to the service. It also would be given a coordination agent that made sure applications ran in the correct sequence and a transaction manager that supervised transactions across dissimilar applications. The proposed set is called Web Services-Composite Application Framework, or WS-CAF. Today's leading Web services handle such coordination issues is 'in a very ad hoc manner, if at all,' says Mark Little, chief team architect for Arjuna. The proposed standards will take the guesswork and ambiguities out of how to coordinate services from scattered systems into one composite application, or new Web service, says Ed Julson, Sun's group manager of Web services standards and technology. The alternative, Julson says, is to go forward with competing methods of resolving service issues, as is the case with two of today's Web-services security standards: Web Services-Security proposed by IBM, Microsoft and VeriSign, and Web Services-Reliability proposed by Fujitsu, Hitachi, NEC, Oracle, Sonic Software, and Sun. Among the standards bodies that might receive the Sun proposal are the Oasis Open consortium of vendors setting XML standards; the World Wide Web Consortium; and the Internet Engineering Task Force. 'From a pure technology standpoint, the group isn't breaking new ground,' says Stephen O'Grady of Red Monk, a market research group. Sun and partners are making use of existing technologies, sometimes already in use in deployed Web services, he says. But 'it's a novel and unique approach for creating composite applications composed of distinct Web services.' The most significant part of the proposal may prove to be the way it defines a way to manage transactions in the Web-services context, O'Grady says..." See: (1) the news story "Web Services Composite Application Framework (WS-CAF) for Transaction Coordination"; (2) the Arjuna announcement "Arjuna Enables Reliable Web Services-Based Business Applications with Arjuna XTS. Technology to Address the Reliable Coordination Issues Preventing the Early Adoption of Serious E-Business Solutions Through Web Services."

• [July 29, 2003] "Introducing BPEL4WS 1.0. Building on WS-Transaction and WS-Coordination." By Dr. Jim Webber and Dr. Mark Little (Arjuna Technologies Limited). In Web Services Journal Volume 3, Issue 8 (August 2003), pages 28-33. With source code and 3 figures. "The value of BPEL4WS is that if a business is the sum of its processes, the orchestration and refinement of those processes is critical to an enterprise's continued viability in the marketplace. Those businesses whose processes are agile and flexible will be able to adapt rapidly to and exploit new market conditions. This article introduces the key features of Business Process Execution Language for Web Services, and shows how it builds on the features offered by WS-Coordination and WS-Transaction. The BPEL4WS model is built on a number of layers, each one building on the facilities of the previous. The fundamental components of the BPEL4WS architecture consists of the following: (1) A means of capturing enterprise interdependencies with partners and associated service links; (2) Message correlation layer that ties together messages and specific workflow instances; (3) State management features to maintain, update, and interrogate parts of process state as a workflow progresses; (4) Scopes where individual activities (workflow stages) are composed to form actual algorithmic workflows. We'll explore the features of this stack, starting with the static aspects of the application -- capturing the relationship between the Web services participating in workflows -- and on to the creation of workflows using the BPEL4WS activities... BPEL4WS is at the top of the WS-Transaction stack and utilizes WS-Transaction to ensure reliable execution of business processes over multiple workflows, which BPEL4WS logically divides into two distinct aspects. The first is a process description language with support for performing computation, synchronous and asynchronous operation invocations, control-flow patterns, structured error handling, and saga-based long-running business transactions. The second is an infrastructure layer that builds on WSDL to capture the relationships between enterprises and processes within a Web services-based environment. Taken together, these two aspects support the orchestration of Web services in a business process, where the infrastructure layer exposes Web services to the process layer, which then drives that Web services infrastructure as part of its workflow activities. The ultimate goal of business process languages like BPEL4WS is to abstract underlying Web services so that the business process language effectively becomes the Web services API. While such an abstract language may not be suitable for every possible Web services-based scenario it will certainly be useful for many, and if tool support evolves it will be able to deliver on its ambition to provide a business analyst-friendly interface to choreographing enterprise systems..." See also: "Introducing WS-Transaction Part II. Using Business Activities," in Web Services Journal Volume 3, Issue 7 (July 2003), pages 6-9. General references in "Business Process Execution Language for Web Services (BPEL4WS)." [alt URL]

• [July 03, 2003] "Introducing WS-Transaction Part II. Using Business Activities." By Dr. Jim Webber and Dr. Mark Little (Arjuna Technologies Limited). In Web Services Journal Volume 3, Issue 7 (July 2003), pages 6-9. "In July 2002, BEA, IBM, and Microsoft released a trio of specifications designed to support business transactions over Web services. BPEL4WS, WS-Transaction, and WS-Coordination together form the bedrock for reliably choreographing Web services-based applications. In our previous articles we introduced WS-Coordination, a generic coordination framework for Web services, and showed how the WS-Coordination protocol can be augmented to provide atomic transactionality for Web services via the WS-Transaction Atomic Transaction model. This article looks at support for extended transactions across Web services. We also show how these can be used to provide the basis for higher-level business process management and workflow technology... A business activity (BA) is designed specifically for these long-duration interactions, where exclusively locking resources is impossible or impractical. In this model, services are requested to do work, and where those services have the ability to undo any work, they inform the BA so that if the BA later decides to cancel the work (i.e., if the business activity suffers a failure), it can instruct the service to execute its undo behavior. The key point for business activities is that how services do their work and provide compensation mechanisms is not the domain of the WS-Transaction specification, but an implementation decision for the service provider... The business activity model has multiple protocols: BusinessAgreement and BusinessAgreementWithComplete. However, unlike the AT protocol, which is driven from the coordinator down to participants, this protocol is driven from the participants upwards...The crux of the BA model, compared to the AT model, is that it allows the participation of services that cannot or will not lock resources for extended periods. While the full ACID semantics are not maintained by a BA, consistency can be maintained through compensation, although writing correct compensating actions (and thus overall system consistency) is delegated to the developers of the services controlled by the BA. Such compensations may use backward error recovery, but typically employ forward recovery... The BPEL4WS specification suggests WS-Transaction Business Activity as the protocol of choice for managing transactions that support the interactions of process instances running within different enterprise systems. A business activity is used both as the means of grouping distributed activities into a single logical unit of work and the dissemination of the outcome of that unit of work -- whether all scopes completed successfully or need to be compensated... The OASIS Business Transactions Protocol (BTP) was developed by a consortium of companies, including Hewlett-Packard, Oracle, and BEA, to tackle a similar problem to WS-Transaction: business-to-business transactions in loosely coupled domains. BTP was designed with loose coupling of services in mind and integration with existing enterprise transaction systems was not a high priority... Although at least in theory WS-Transaction and BTP are intended to address the same problem domain, there are significant differences between them. BTP allows business-level negotiation to occur during many points in the protocol in its Qualifier mechanism; WS-Transaction does not have such a capability. [So] we've seen both the atomic AT protocol and the non-ACID BA designed to support long-running transactions. While both the AT and BA models will be available to Web services developers directly through toolkits, it is the BA model that is supported by the BPEL4WS standard to provide distributed transaction support for business processes..." See also: (1) "Introducing WS-Transaction, Part 1. The Basis of the WS-Transaction Protocol."; (2) "Introducing WS-Coordination." See also the source in PDF from Arjuna Technologies. [alt URL]

• [May 31, 2003] "Introducing WS-Transaction, Part 1. The Basis of the WS-Transaction Protocol." By Dr. Jim Webber and Dr. Mark Little (Arjuna Technologies Limited). In Web Services Journal Volume 3, Issue 6 (June 2003), pages 28-33 (with 6 figures and source code). WSJ Feature Article. "In July 2002, BEA, IBM, and Microsoft released a trio of specifications designed to support business transactions over Web services. These specifications, BPEL4WS, WS-Transaction, and WS-Coordination, together form the bedrock for reliably choreographing Web services-based applications, providing business process management, transactional integrity, and generic coordination facilities respectively. In our previous article we introduced WS-Coordination, a generic coordination framework for Web services, and showed how the WS-Coordination protocol can be augmented to support coordination in arbitrary application domains. This article introduces the first publicly available WS-Coordination-based protocol -- Web Services Transaction -- and shows how WS-Transaction provides atomic transactional coordination for Web services... An important aspect of WS-Transaction that differentiates it from traditional transaction protocols is that a synchronous request/response model is not assumed. This model derives from the fact that WS-Transaction is layered upon the WS-Coordination protocol whose own communication patterns are asynchronous by default... WS-Coordination provides only context management -- it allows contexts to be created and activities to be registered with those contexts. WS-Transaction leverages the context management framework provided by WS-Coordination in two ways. First, it extends the WS-Coordination context to create a transaction context. Second, it augments the activation and registration services with a number of additional services (Completion, Completion WithAck, PhaseZero, 2PC, Outcome Notification, BusinessAgreement, and BusinessAgreementWithComplete) and two protocol message sets (one for each of the transaction models supported in WS-Transaction) to build a full-fledged transaction coordinator on top the WS-Coordination protocol infrastructure... In common with other transaction protocols (like OTS and BTP), WS-Transaction supports the notion of the service and participant as distinct roles, making the distinction between a transaction-aware service and the participants that act on behalf of the service during a transaction: transactional services deal with business-level protocols, while the participants handle the underlying WS-Transaction protocols... No one specific protocol is likely to be sufficient, given the wide range of situations that Web service transactions are likely to be deployed within. Hence the WS-Transaction specification proposes two distinct models, each supporting the semantics of a particular kind of B2B interaction... As with WS-Coordination, the two WS-Transaction models are extensible, allowing implementations to tailor the protocols as they see fit, e.g., to suit their deployment environments..." Previous article: "Introducing WS-Coordination. A Big Step Toward a New Standard," by Jim Webber and Mark Little (Arjuna Technologies Limited). In WebServices Journal Volume 3, Issue 5 (May 24, 2003). See also the source in PDF from Arjuna Technologies. [alt URL]

• [April 26, 2003] "Introducing WS-Coordination." A Big Step Toward a New Standard." By Jim Webber and Mark Little (Arjuna Technologies Limited). In WebServices Journal Volume 3, Issue 5 (May 24, 2003). With 5 figures. ['In July 2002, BEA, IBM, and Microsoft released a trio of specifications designed to support business transactions over Web services. These specifications - BPEL4WS, WS-Transaction, and WS-Coordination - together form the bedrock for reliably choreographing Web services-based applications, providing business process management, transactional integrity, and generic coordination facilities respectively.'] "This article introduces the underlying concepts of Web Services Coordination, and shows how a generic coordination framework can be used to provide the foundations for higher-level business processes. In future articles, we will demonstrate how coordination allows us to move up the Web services stack to encompass WS-Transaction and on to BPEL4WS... The fundamental idea underpinning WS-Coordination is that there is indeed a generic need for propagating context information in a Web services environment, which is a shared requirement irrespective of the applications being executed. The WS-Coordination specification defines a framework that allows different coordination protocols to be plugged in to coordinate work between clients, services, and participants. The WS-Coordination specification talks in terms 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... Ahatever coordination protocol is used, and in whatever domain it is deployed, the same generic requirements are present: (1) Instantiation (or activation) of a new coordinator for the specific coordination protocol for a particular application instance; (2) Registration of participants with the coordinator such that they will receive that coordinator's protocol messages during (some part of) the application's lifetime; (3) Propagation of contextual information between the Web services that comprise the application; (4) An entity to drive the coordination protocol through to completion... The context is critical to coordination since it contains the information necessary for services to participate in the protocol. It provides the glue to bind all of the application's constituent Web services together into a single coordinated application whole. Since WS-Coordination is a generic coordination framework, contexts have to be tailored to meet the needs of specific coordination protocols that are plugged into the framework... WS-Coordination looks set to become the adopted standard for activity coordination on the Web. Out of the box, WS-Coordination provides only activity and registration services, and is extended through protocol plug-ins that provide domain-specific coordination facilities. In addition to its generic nature, the WS-Coordination model also scales efficiently via interposed coordination, which allows arbitrary collections of Web services to coordinate their operation in a straightforward and scalable manner. Though WS-Coordination is generically useful, at the time of this writing only one protocol that leverages WS-Coordination has been made public: WS-Transaction We'll look at this protocol in our next article." See also the source in PDF from Arjuna Technologies. [alt URL]

• [February 22, 2003] "Web Services Orchestration: A Review Of Emerging Technologies, Tools, and Standards." By Chris Peltz (Hewlett Packard, Developer Resource Organization). Technical Paper from HP Dev Resource Central (January 2003). 20 pages. "Web services technologies are beginning to emerge as a defacto standard for integrating disparate applications and systems using open, XML-based standards. In addition to building web services interfaces to existing applications, there must also be a standard approach to connecting these web services together to form more meaningful business processes. In 2002, a number of new standards were introduced to address this problem, including BPEL4WS and WSCI. The purpose of this paper is to provide a review of these emerging standards, to help the reader better understand how web services orchestration can be accomplished today." [cache]

• [February 04, 2003] "Business Processes and Workflow in the Web Services World. A Workflow is Only As Good As the Business Process Underneath It." By Margie Virdell (e-business Architect, IBM Developer Relations). From IBM developerWorks, Web services. January 2003. "This article looks at business processes, their relationship to workflow and Web services today, and the challenges that lie ahead... A business process can be defined as a set of interrelated tasks linked to an activity that spans functional boundaries. Business processes have starting points and ending points, and they are repeatable... The standardization of workflow behavior and interoperability is late to this game, trying to standardize everything all at once. Perhaps the standards bodies and their members should focus their efforts on finishing the basic, core workflow standard and not be so distracted by the outer layers..." References several workflow specifications, including: '(1)Wf-XML and Workflow Reference Model from the Workflow Management Coalition (WfMC): Wf-XML is an XML-based encoding of workflow interoperability messages. The Workflow Reference Model is a description of the underlying workflow system architecture. Wf-XML has no binding to SOAP and WSDL at this time. (2) WSFL IBM Web Services Flow Language: Specifies two types of Web services composition A) an executable business process known as a flowModel, and B) a business collaboration known as a globalModel. Compatible with SOAP, UDDI, and WSDL. (3) XLANG Microsoft's XLANG: Business modeling language for BizTalk, which is a component of .NET that enables EAI. BizTalk Orchestration is the workflow engine and BizTalk Orchestration Designer is the visual business process modeling tool based on XLANG. (4) BPEL4WS Business Process Execution Language for Web Services is the cooperative merging of WSFL and XLANG for Web services orchestration, workflow, and composition. It has not yet been submitted to an IT standards organization. (5) ebXML BPSS The eBusiness Transition Working Group carries forward the definition of workflow conversation and orchestration in the Business Process Specification Schema (BPSS) layer of ebXML, which defines many protocols and layers for XML-based e-business. (6) WSCI Sun/BEA/Intalio/SAP consortium's Web Services Choreography Interface 'is an XML-based interface description language that describes the flow of messages exchanged by a Web Service participating in choreographed interactions with other services.' (7) WSCL W3C's Web Services Conversation Language: A submission by Hewlett-Packard to the W3C, it allows defining the abstract interfaces of Web services (that is, the business level conversations or public processes supported by a Web service), the XML documents being exchanged, and the sequencing of those documents. (8) PIPs, RosettaNet's Partner Interface Process: defines business processes between trading partners via specialized system-to-system XML-based dialogs. Many PIPs have been defined for various partner scenarios. (9) JDF CIP4's Job Definition Format is an upcoming workflow industry standard for the Graphics Arts industry designed to simplify information exchange among different applications and systems..."

• [December 07, 2002] "Multi-Party Electronic Business Transactions." By Bob Haugen (Logistical Software LLC, ebXML and UN/CEFACT TMG Business Process Work Group) and Tony Fletcher (Choreology Ltd, OASIS Business Transaction Protocol Committee and UN/CEFACT TMG Business Process and Architecture Work Groups). Version 1.1. 7-December-2002. "We present a business scenario, the Drop-Dead Order, that is best handled as a multi-party electronic business transaction. We present models of such transactions using the UN/CEFACT Modeling Methodology (UMM) and the OASIS Business Transaction Protocol (BTP). We claim that the two models are sufficiently equivalent that the same runtime software could execute either. We recommend that BTP be considered as an underpinning implementation technology for UMM, thus harmonizing two specifications that have been considered incompatible. We suggest that further efforts be made to harmonize the other major proposals for electronic business processes so as to converge from a confusion of incompatibility to one global standard, or at least good interoperability..."

• [November 20, 2002] "WS-C+T and BTP: Comments and Comparisons." By Peter Furniss and Alastair Green (Choreology Ltd). 20-November-2002. "As Choreology announced previously, we believe there should be a single standardization approach for web-services transactions, combining the best features of BTP and WS-C+T. This message summarises some of the principal differences and similarities between BTP and WS-C+T, under the headings: Terminology: sub-protocols; Taxonomy: atoms and cohesions; BTP, WS-T: variations on a single outcome protocol; Functionality discrepancies; Optimisation; Scope - web-services only or web-service and more; WS-Coordination - why separate it?; WSDL integration; Synchronization; Security; Transfer of control... This message gives some detail on the first three, especially the issue that BTP and WS-T are just variations on one protocol, and summarises the other issues..."

• [September 01, 2002] "Conversational Support for Web Services: The Next Stage of Web Services Abstraction. Use This alphaWorks Technology to Build Your Dynamic E-Business" By Santhosh Kumaran and Prabir Nandi (Researchers, IBM T.J. Watson Research Center). From IBM developerWorks, Web services. ['A new series of Web services protocols -- BPEL4WS, WS-Coordination, and WS-Transaction -- aim to abstract groups of services into easy-to-handle processes. While most developers are just starting to use these technologies, Santhosh Kumaran and Prabir Nandi, two researchers at IBM's T.J. Watson Research Center, are already studying how to take Web services to the next level of abstraction. In this article, you'll learn about Conversation Support for Web Services (CS-WS), an experimental technology from IBM's alphaWorks. You'll learn how conversations can hide the implementation details involved with collecting multiple Web services into real-life business exchanges. Once you finish here, you can download the project's code from alphaWorks and get in on the ground floor of development.'] "IBM, Microsoft, and BEA have just announced a set of Web services standards for automating business processes on the Web: (1) Business Process Execution Language for Web Services (BPEL4WS), for executable specification of business processes; (2) WS-Coordination (WS-C), for specifying an extensible framework for the coordination of actions of distributed applications; (3) WS-Transaction (WS-T), for coordination types that are used with the framework described in WS-Coordination. In addition, IBM is making available through alphaWorks a technology called Conversation Support for Web Services (CS-WS) for supporting a conversational model of interaction between distributed, autonomous systems. The goal of this article is to articulate a vision in which these complementary technologies work together to enable dynamic e-business. Once you've finished here, you'll understand the sorts of problems that this emerging technology is meant to address, and you'll be ready to download the CS-WS package from alphaWorks and start to explore its code. The Resources section below contains links to this package as well as other offsite materials referenced in this article. We begin with a very brief overview of the technologies pertinent to our discussion. Then we introduce a travel reservation scenario, and see how the technologies we'll discuss here can be used to build Web services of various levels of sophistication... BPEL4WS, WS-Coordination, and WS-Transaction, along with WSDL and UDDI, provide the basis for the programming model for dynamic e-business. The significant and complementary features that conversations bring to this model, as illustrated in our example, include: [1] Dynamic and flexible interaction patterns, as shown by the ability of the conversation technology to support complex interactions between Acme and customers. [2] Adaptable, open-ended, and extensible B2B integration capability, as demonstrated by the ability of the conversation module to account for interface changes. [3] The addition of the conversation module as a process broker layer, dealing with multiple business protocols that the partners employ to provide the business services the BPEL processes expect. For example, different car companies may have different protocols for making a reservation; the conversation module supports the selection of the right protocol for each partner while utilizing the same BPEL processes..." See also Conversation Support for Web Services (alphaWorks) and "Conversation Support for agents, e-business, and component integration."

• [August 01, 2002] "Transactions in the World of Web Services, Part 2. An Overview of WS-Transaction and WS-Coordination." By Tom Freund and Tony Storey (IBM). From IBM developerWorks, Web services. "In Part 1 we introduced the technical concepts behind the distributed transaction model designed for Web services, as defined in the WS-Coordination and WS-Transaction specifications. This paper focuses on specific scenarios of business transactions that can apply to the Web services model. The two main types discussed in this article are Atomic transactions that are individual transactional calls to a specific service operation, and Business transactions that generally consist of one or more atomic transactions... Transactions are one of the most fundamental concepts in delivering reliable application processing. Web services require a flexible and extensible mechanism for controlling requests and outcomes in addition to the behavior offered by traditional distributed and database transaction models. Additionally, specific requirements for a Web services environment are support for Collaborations, Long-duration tasks, and Cross-business applications. The WS-Coordination specification provides a coordination framework offering services for activity creation, registration and coordination. The generalized framework offers the capability for specifying the operational context of a request (or series of requests), controlling the duration of the activity and defining the participants engaged in an outcome decision. Additionally, WS-Transaction provides a number of coordination patterns typically used within the industry to accommodate differing application: (1) Atomic Transactions: application operations on web services occur completely or not at all. (2) Business Transactions: application operations on web services exhibit a loose unit of work where results are shared prior to completion of the overall activity. The semantics of a compensate is that each participant will undo the operations it has performed within the conversation. These styles or behaviors mechanisms are by no means complete. However, they allow sites participating in Web services to supplement their existing implementations to support more complex processing and compensation models. The sites can build on their internal transaction and business logic environments to provide the increased flexibility. Additionally the coordination service framework would allow for additional operational patterns beyond the traditional transactional model. The sole requirement we currently place on web services is the ability for two endpoints to agree on the outcome. Multiparty 'transaction' processing occurs within enterprises that use their own internal transaction and workflow models to manage operations and conversations with multiple participants..." Also in PDF format.

• [August 01, 2002] "Transactions in the World of Web Services, Part 1. An Overview of WS-Transaction and WS-Coordination." By Tom Freund and Tony Storey (IBM). From IBM developerWorks, Web services. August 1, 2002. "This paper presents and illustrates a high-level overview of the Web service specifications for WS-Coordination and WS-Transaction. The new specifications outline the mechanisms required when creating reliable applications by connecting together Web services. These Web services need to participate and cooperate on the agreement of the overall application outcome. The WS-Coordination specification provides a generic foundation for Web services coordination. It provides support for standard transaction mechanisms that exist in today's marketplace. The WS-Transaction specification includes a definition of atomic and business transaction protocols. It is anticipated that additional patterns and protocols will emerge and be based on an extensible coordination framework defined in the specification. These specifications tackle the growing need for consistent support of transactions and addresses the more general requirement to guarantee the reliable coordination of operations across Web services... Transactions are a fundamental concept in building reliable distributed applications. A transaction is a mechanism to insure all the participants in an application achieve a mutually agreed outcome. Traditionally, transactions have held the following properties collectively referred to as ACID: (1) Atomicity: If successful, then all the operations happen, and if unsuccessful, then none of the operations happen. (2) Consistency: The application performs valid state transitions at completion. (3) Isolation: The effects of the operations are not shared outside the transaction until it completes successfully (4) Durability: Once a transaction successfully completes, the changes survive failure. A Web service environment requires the same coordination behavior provided by a traditional transaction mechanism to control the operations and outcome of an application. However it also requires the capability to handle the coordination of processing outcomes or results from multiple services, in a more flexible manner. This requires more relaxed forms of transactions -- those that do not strictly have to abide to the ACID properties--such as collaborations, Workflow, Realtime processing, etc. Additionally, there is a need to group Web services into applications that require some form of correlation, but do not necessarily require transactional behavior. The WS-Coordination and WS-Transaction specifications provide a WSDL definition for such coordinated behavior... The Coordination Framework provides a system to coordinate communications across a distributed network of Web services and can work with strict transaction-based systems with ACID properties as well as other forms of transactions, while the Coordination Protocols can implement actual ACID transactions..."

• [April 10, 2002] "Business Process Standards for Web Services." By David O'Riordan (Bind Systems). From Web Services Architect. (April 10, 2002). 12 pages. ['Discusses ebXML BPSS, XLANG, WSFL, BPML, OMG EDOC.'] "A business process standard that provides comprehensive support for both public and private processes should consider the following features: (1) Collaboration-Based Process Models; (2) Workflow; (3) Transaction Management; (4) Exception Handling; (5) Service Interfaces; (6) Message Security and Reliability; (7) Audit Trail; (8) Agreements; (9) Execution... we examine those specifications that address the orchestration layer of the Web Services stack, the core layer that describes business process semantics. These are ebXML BPSS, XLANG, WSFL, and BPML. Each supports some subset of the aforementioned features, depending largely on the domain they are addressing..." See also the abbreviated version in HTML format. [alt URL]

• [April 03, 2002] "Transactional Attitudes: Reliable Composition of Autonomous Web Services." By Thomas Mikalsen, Stefan Tai, and Isabelle Rouvellou (IBM T.J. Watson Research Center, New York, USA). Paper prepared for the June 26, 2002 Workshop on Dependable Middleware-based Systems (WDMS 2002), part of the International Conference on Dependable Systems and Networks (DSN 2002), Washington D.C., June 2002. 10 pages (with 11 references). "The Web services platform offers a distributed computing environment where autonomous applications interact using standard Internet technology. In this environment, diverse applications and systems become the components of intra- and inter-enterprise integration. Yet, transactional reliability, an often critical requirement on such integration, is presently missing from the Web services platform. In this paper, we address this shortcoming and propose the WSTx framework as an approach to Web service reliability. WSTx introduces transactional attitudes to explicitly describe the otherwise implicit transactional semantics, capabilities, and requirements of individual applications. We show how explicit transactional attitude descriptions can be used by a middleware system to automate the reliable composition of applications into larger Web transactions, while maintaining autonomy of the individual applications... See also the project website. [cache]

• [October 01, 2001] "OAGIS Implementation Using the ebXML CPP, CPA and BPSS Specifications v1.0." OAGI White Paper. By Jean-Jacques Dubray (Eigner US, Inc.). 9/27/2001. Version 1.03. 64 pages.

• [September, 2000] "CheeTah: a Lightweight Transaction Server for Plug-and-Play Internet Data Management." By Guy Pardon and Gustavo Alonso. Presented at VLDB 2000 and published in Proceedings of 26th International Conference on Very Large Data Bases, September 10-14, 2000, Cairo, Egypt. "The ability to maintain transactional interaction in a distributed system has proven to be a key feature in information systems. Unfortunately, as technology moves towards more distribution and decentralization, it becomes increasingly difficult to use existing transactional tools. In fact, current solutions are entirely unsuitable for what we call composite systems. Composite systems can be characterized as a collection of distributed, autonomous components, linked in an arbitrary configuration. In this paper, we describe CheeTah, a Java based set of tools for building composite components capable of interacting transactionally in arbitrary, dynamically changing configurations. We describe the technology provided, how designers would use it to build composite transactional systems, and examine in detail the performance of the resulting solution. Among the results we have achieved, the performance and the simplicity of use are of particular interest..." See also the thesis Composite Systems: Decentralized Nested Transactions" [Dissertation ETH Nr. 13993], a dissertation submitted to the Swiss Federal Institute of Technology Zurich, for the degree of Doctor of Technical Sciences, presented by Guy Pardon, accepted on the recommendation of Prof. Dr. G. Alonso (examiner) and Prof. Dr. C. Beeri (co-examiner), 2000.