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.
- 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 Services Choreography Description Language (WS-CDL)
- Web Services Conversation Language (WSCL)
- Web Services Transaction Framework
- WS Choreography
- Related Work (not further abstracted or referenced):
- Business Process Management Initiative Specifications (BPML, BPMN, BPQL)
- Business Process Specification Schema (BPSS), including:
- OMG Business Process Definition
- Workflow Standard XML Process Definition Language (XPDL)
- Web Services Flow Language (WSFL)
The BPEL specification document "defines a notation called Business Process Execution Language for Web Services. Processes in BPEL4WS export and import functionality by using Web Service interfaces exclusively. Business processes can be described in two ways. Executable business processes model actual behavior of a participant in a business interaction. Business protocols, in contrast, use process descriptions that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior. The process descriptions for business protocols are called abstract processes. BPEL4WS is meant to be used to model the behavior of both executable and abstract processes. BPEL4WS provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web Services interaction model and enables it to support business transactions. BPEL4WS defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces." [v1.1]
- "Web Services Business Process Execution Language Version 2.0." Working Draft. 23-August-2005. Prepared by members of the OASIS Web Services Business Process Execution Language (WSBPEL) TC. 154 pages.
- Business Process Execution Language for Web Services. Version 1.1. 5 May 2003.
- OASIS Web Services Business Process Execution Language TC website
- "OASIS Forms Web Services Business Process Execution Language TC (WSBPEL)."
- "Business Process Execution Language for Web Services (BPEL4WS)" - Local reference page.
In January 2008, OASIS announced that consortium members had submitted a charter proposal for a new WS-BPEL Extension for People (BPEL4People) Technical Committee. Companies sponsoring the proposal include Active Endpoints, Adobe, BEA, IBM, Oracle, SAP, Software AG, and Sun Microsystems. The proposed BPEL4People Technical Committee would define: (1) extensions to the OASIS WS-BPEL 2.0 Standard to enable human interactions, and (2) a model of human interactions that are service-enabled. In particular, the new TC work will focus upon: (1) Defining the specification of a WS-BPEL extension enabling the definition of human interactions ("human tasks") as part of a WS-BPEL process; (2) Defining the specification of a model enabling the definition of human tasks that are exposed as Web services; (3) Defining a programming interface enabling human task client applications to work with human tasks.
In June 2007, a group of six technology vendors, including Active Endpoints, Adobe, BEA Systems, IBM, Oracle, and SAP AG, announced the publication of two "BPEL4People" specifications which define an approach for integrating human interactions using Web Services Business Process Execution Language (WS-BPEL) 2.0. In July 2005, IBM and SAP jointly issued a white paper "WS-BPEL Extension for People — BPEL4People." It describes scenarios where users are involved in business processes, and motivates and outlines appropriate extensions to WS-BPEL to address these scenarios. BPEL4People as released in 2007-06 is comprised of two specifications: WS-BPEL Extension for People (BPEL4People) Version 1.0 and Web Services Human Task (WS-HumanTask) Version 1.0. These two specifications take the ideas outlined in the white paper and together provide a concrete realization of them. BPEL4People extends the capabilities of WS-BPEL to support a broad range of human interaction patterns, allowing for expanded modeling of business processes within the WS-BPEL language.
In August 2005, IBM and SAP AG published an initial informal specification describing a proposed extension to the Web Services Business Process Execution Language (WS-BPEL) in the form of a joint white paper WS-BPEL Extension for People -- BPEL4People.. The current draft of WS-BPEL Version 2.0 does not support a needed component of business processes in action: human user interactions. The WS-BPEL Extension for People (BPEL4People) defines requirements for a WS-BPEL extension necessary for supporting a broad range of scenarios that involve people within business processes. BPEL4People is defined in such a way that it is layered on top of the BPEL language so that its features can be composed with the BPEL core features whenever needed. A formal specification defining BPEL4People syntax and semantics was planned.
- WS-BPEL for People (BPEL4People)
- OASIS Members Propose Charter for WS-BPEL Extension for People (BPEL4People) TC. News story 2008-01-14.
- "BPEL4People Specifications Integrate Human Interactions Into Business Process." News story 2007-06-25.
- "IBM and SAP AG Propose WS-BPEL Extension for People (BPEL4People)." News story 2005-08-26.
- Spec available from IBM
- Spec available from SAP AG [alt URL for sdn.sap.com]
- BPEL4People — How People Interact with Business Processes. By Ivana Trickovic (Standards Architect, SAP Platform Ecosystem Industry Standards Group, SAP AG). August 25, 2005. [sdn.sap.com PDF source]
- WS-BPEL Extension for People reference page. IBM developerWorks, SOA and Web services.
A technical white paper "WS-BPEL Extension for Sub-Processes: BPEL-SPE" published 2005-10-13 by IBM and SAP proposes an extension to WS-BPEL that allows for the definition of sub-processes that can be reused within the same or across multiple WS-BPEL processes. A formal language specification defining the precise syntax and semantics of the BPEL-SPE extension is planned for later release. The BPEL language currently "does not support the explicit definition of business process 'fragments' that can be invoked from another (or the same) business process. The only way to approximate similar behavior today is by defining a complete business process as an independent service and invoking it using an <invoke> activity. The fact that the invoked activity is really implemented as another process is completely hidden from the parent process, in other words, there is no chance to establish any coupling of process instance lifecycles"... Section 2 of the white paper defines sub-process in general, along with the notion of a standalone sub-process and an inline sub-process; section 3 supplies details about different modes of invocations between a parent process and a subprocess; section 4 describes aspects of interoperability such as a common state model, and a protocol to couple the lifecycle between a parent process and a subprocess defined and executed in different environments. BPEL-SPE identifies key features needed to provide sub-process capabilities in a direct way, meeting the following goals: (1)" allow for the invocation of a business process as a sub-process of another business process such that its lifecycle is tightly coupled to the lifecycle of the parent process; (2) allow for the definition of a business process within the context of another business process, so it can be used (and reused) within that other process; (3) allow a sub-process defined within the context of another business process to access data from its parent process; (4) allow for the invocation of sub-processes across BPEL engines so that a process running on one BPEL engine can invoke a sub-process on another BPEL engine."
- "IBM and SAP AG Release WS-BPEL Extension for Sub-Processes (BPEL-SPE)."
- WS-BPEL 2.0 Extensions for Sub-Processes.Overview from IBM.
- WS-BPEL Extension for Sub-Processes: BPEL-SPE. A Joint White Paper by IBM and SAP. September 2005. 17 pages. Also available from IBM.
- Modularization and Reuse in WS-BPEL.
"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..."
- "OASIS Technical Committee Advances Business Transaction Protocol (BTP) Specification." In December 20004, OASIS announced the approval of "Business Transaction Protocol" (BTP) Version 1.1 as a Committee Draft. Version 1.1 represents a revision of BTP V1.0 in the light of feedback and implementation experience. BTP is a carrier-neutral protocol designed to allow coordination of application work between multiple autonomous, cooperating participants. BTP defines the protocol in terms of abstract messages schematized in XML, along with an optional SOAP binding.
- Business Transaction Protocol. Version 1.1. Working Draft 05 approved as OASIS Committee Draft (CD).
- BTP v1.1 CD XML Schemas and WSDLs:
- Business Transaction Protocol. OASIS Committee Specification. Version 1.0. 3 June 2002.
- Business Transaction Protocol Primer. Supporting BTP v 1.0.
- OASIS Business Transactions Protocol TC website
- Business Transactions TC Charter
- OASIS Business Transactions TC FAQ document
- "OASIS Business Transaction Protocol Technical Committee Publishes Revised BTP Specification."
- XML Transactioning API for Java (JAXTX). Java Specification Request #156. "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."
- "OASIS Business Transactions Technical Committee" - Local reference page.
"The purpose of the OASIS Asynchronous Service Access Protocol TC is to create a very simple extension of Simple Object Access Protocol (SOAP) that enables generic asynchronous webservices or long-running webservices... Not all services are instantaneous. A standard protocol is needed to integrate asynchronous services across the Internet and provide for their interaction. The integration and interactions consist of control and monitoring of the service. The protocol should be lightweight and easy to implement, so that a variety of devices and situations can be covered... Asynchronous capability is not specific to any one problem. Rather, it is needed to one degree or another in a number of problem areas, such as workflow, business process management, e-commerce, data mining and mobile wireless devices. ASAP strives to provide to a simple common asynchronous capability that can be employed in any number of problem-specific protocols..." [from the Charter]
- ASAP TC website
- ASAP TC Charter
- Call for Participation in OASIS Asynchronous Service Access Protocol (ASAP) TC
- Asynchronous Transactions and Web Services - General reference page.
In September 2003, OASIS members formed a new WS-CAF Technical Committee to "define a generic and open framework for applications that contain multiple services used in combination (composite applications)." The TC will continue collaborative work on the Web Services Composite Application Framework (WS-CAF) specification suite recently published by Arjuna Technologies Limited, Fujitsu Software, IONA Technologies PLC, Oracle Corp, and Sun Microsystems. The proposal notes that "composability is a critical aspect of Web Service specifications; the initial TC members expect the work of the WS-CAF TC, particularly WS-Context, to become building blocks for other Web service specifications and standards. Therefore, the resulting specification must be non-overlapping and have demonstrated composability with other Web Service specifications that are being developed in open, recognized standards setting organizations. The WS-CAF TC will work with these organizations to gather requirements input and to define the relationships between their specifications and this TC's work with the goal of promoting convergence, consistent use, and a coherent architecture. The anticiated audience for this work includes: (1) other specification writers that need underlying web service coordination, context and transaction mechanisms; (2) vendors offering web service products; (3) software architects and progammers who design and write distributed applications requiring coordination, context and transaction mechanisms." The WS-CAF TC Convenor is Mark Little (Arjuna Technologies); the proposed TC Chairs are Martin Chapman (Oracle Corporation) and Eric Newcomer (Iona Technologies). The first meeting of the OASIS WS-CAF TC will held October 31, 2003 as a teleconference.
"Web Services Context Specification (WS-Context). Edited by Mark Little, Eric Newcomer, and Greg Pavlik. OASIS Committee Draft. Produced by members of the OASIS Web Services Composite Application Framework (WS-CAF) TC . Announced as a Committee Draft for public review from 12-November-2004 through 12-December-2004. Version 0.8. 3-November-2004. 23 pages. PDF extracted from the ZIP package. See also the XML Schema and WSDL file. "Web services exchange XML documents with structured payloads. The processing semantics of an execution endpoint may be influenced by additional information that is defined at layers below the application protocol. When multiple Web services are used in combination, the ability to structure execution related data called context becomes important. This information is typically communicated via SOAP Headers. WS-Context provides a definition, a structuring mechanism, and a software service definition for organizing and sharing context across multiple execution endpoints. The ability to compose arbitrary units of work is a requirement in a variety of aspects of distributed applications such as workflow and business-to-business interactions. By composing work, we mean that it is possible for participants in an activity to be able to determine unambiguously whether or not they are participating in the same activity. An activity is the execution of multiple Web services composed using some mechanism external to this specification, such as an orchestration or choreography. A common mechanism is needed to capture and manage contextual execution environment data shared, typically persistently, across execution instances. In order to correlate the work of participants within the same activity, it is necessary to propagate context to each participant. The context contains information (such as a unique identifier) that allows a series of operations to share a common outcome..." [source .ZIP file]
- "OASIS Forms Web Services Composite Application Framework Technical Committee."
- "Industry Leaders Demonstrate WS-Context Interoperability. IONA, Arjuna, and Oracle Showcase Viability of OASIS Committee Draft Specification." Announcement 2004-12-13.
- Announcement: OASIS TC Call For Participation: WS-CAF TC
- WS-CAF Technical Committee website
- WS-CAF TC Charter
- WS-CAF TC mailing list archive
On October 01, 2005 OASIS announced a Call for Participation in a new Web Services Transaction (WS-TX) Technical Committee. According to the Charter, the purpose of the WS-TX Technical Committee is "to define a set of protocols to coordinate the outcomes of distributed application actions. The TC will specify an extensible framework for developing coordination protocols through continued refinement of the Web Services Coordination (WS-Coordination v 1.0) specification; in addition, the TC will continue refinement of protocols for two coordination types that use the WS-Coordination framework: atomic transaction (AT) and business activity (BA), based on the Web Services Atomic Transaction (WS-AtomicTransaction v 1.0) and Web Services Business Activity (WS-BusinessActivity v 1.0) specifications [to be] submitted to the TC. Collectively, these three specifications will be referred to as the WS-TX Specifications..."
- "OASIS Members Form Web Services Transaction (WS-TX) Technical Committee."
- WS-TX Charter
- WS-TX TC home page
- WS-TX TC discussion archive
- WS-TX Members
- Announcement 2005-10-12: "OASIS Members Form Committee to Advance Web Services Transaction (WS-TX) Standards. Actional, Adobe, BEA Systems, Cast Iron Systems, DataPower, Fujitsu, Hitachi, IBM, IONA, Microsoft, Oracle, Reactivity, Ricoh, SAP, SOA Software, Sonic Software, Systinet, TIBCO, webMethods, and Others Collaborate on Extensible Framework for Developing Coordination Protocols."
- See also:
The Web Services Choreography Working Group is part of the W3C Web Services Activity. The WG was started in January 2003 and is chartered to design a language to compose and describe the relationships between Web services. This composition is known as choreography of Web services. The Working Group is working on publishing its first Working Draft of requirements and a usage scenarios document and will produce the following deliverables: (1) A requirements document, including a description of the factorization of the choreography space; (2) Usage scenarios; (3) One of more specifications of choreography language(s) and its XML schema; (4) A primer; (5) A test suite."
From the Reqirements WD document: "Web Services Choreography concerns the interactions of services with their users. Any user of a Web Service, automated or otherwise, is a client of that service. These users may, in turn, be other Web Services, applications or human beings. Transactions among Web Services and their clients must clearly be well defined at the time of their execution, and may consist of multiple separate interactions whose composition constitutes a complete transaction. This composition, its message protocols, interfaces, sequencing, and associated logic, is considered to be a choreography..."
- "Web Services Choreography Requirements and WS Choreography Model Overview." News story 2004-03-25.
- Oracle WS-CDL comparison against the Web Services Choreography Requirements. By Nickolaos Kavantzas (Oracle) Ashwini Surpur (Oracle). October 17, 2003. Notes are also made on BurdettML.
- 2003-10-01 from David Burdett: [there will be a] October 15-16, 2003 meeting in the in the Bay Area at BEA... the objective of the meeting is to take the specifications developed by Oracle and Commerce One and start the process of working out how best to use them together with the WS Chor "Requirements" spec and other known issues to create a draft WS Chor "Language" spec the whole group can consider..."
- Web Services Choreography Requirements 1.0. W3C Working Draft 12-August-2003.
- WS Choreography Model Overview W3C Working Draft 24-March-2004.
- Web Services Choreography Working Group
- Web Services Choreography Working Group Charter
- Mailing list archive for 'public email@example.com' list
- "W3C Creates Web Services Choreography Working Group." News item January 14, 2003.
"The Web Service Choreography Interface (WSCI) 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. WSCI describes the dynamic interface of the Web Service participating in a given message exchange by means of reusing the operations defined for a static interface. WSCI works in conjunction with the Web Service Description Language (WSDL), the basis for the W3C Web Services Description Working Group; it can, also, work with another service definition language that exhibits the same characteristics as WSDL. WSCI describes the observable behavior of a Web Service. This is expressed in terms of temporal and logical dependencies among the exchanged messages, featuring sequencing rules, correlation, exception handling, and transactions. WSCI also describes the collective message exchange among interacting Web Services, thus providing a global, message-oriented view of the interactions. WSCI does not address the definition and the implementation of the internal processes that actually drive the message exchange. Rather, the goal of WSCI is to describe the observable behavior of a Web Service by means of a message-flow oriented interface. This description enables developers, architects and tools to describe and compose a global view of the dynamic of the message exchange by understanding the interactions with the web service."
- Web Service Choreography Interface (WSCI) 1.0. W3C Note 8 August 2002.
- "Web Service Choreography Interface (WSCI)" - Local reference page.
"The Web Services Composite Application Framework specifications, or WS-CAF, propose standard, interoperable mechanisms for managing shared context and ensuring business processes achieve predictable results and recovery from failure. Transaction processing (TP) is the core of commerce. Some transactions are very simple, such as purchasing a book or transferring funds, and can be processed immediately. Other transactions are more complex, such as fulfilling a purchase order or completing an insurance claim, and may take days or even years to process. All businesses rely on the concept of a transaction, but have built upon the concept through various architectures, which limits interoperability and creates multiple 'islands' of mutually incompatible TP networks. WS-CAF solves the TP information management and sharing problem by defining an open, multi-level framework for standard coordination of long-running business processes across multiple, incompatible transaction processing models and architectures... The Web Services Composite Application Framework (WS-CAF) is divided into three parts..." as described in the Framework Primer:
Web Service Context (WS-CTX) provides "a lightweight framework for simple context management... The ability to scope arbitrary units of work is a requirement in a variety of aspects of distributed applications such as workflow and business-to-business interactions. By scoping work, we mean that it is possible for business activity participants to be able to determine unambiguously whether or not they are participating in the same activity... A Web Services Context Service maintains a repository of context information and tracks contexts shared between multiple participants in Web services interactions. An Context Service can also be a participant within an activity, creating a tree to further propagate the context. A Web Services Context Service accepts and emits SOAP messages for interoperability with any type of participant, regardless of operating system, programming language, or platform -- and is independent of underlying transfer or transport protocols..."
Web Service Coordination Framework (WS-CF) defines "a sharable mechanism to manage context augmentation and lifecycle, and guarantee message delivery... Coordination is a requirement present in a variety of different aspects of distributed applications. For instance, workflow, atomic transactions, caching and replication, security, auctioning, and business-tobusiness activities all require some level of what may be collectively referred to as 'coordination.' ... Coordination is a fundamental requirement of many distributed systems, including Web Services. However, the type of coordination protocol that is used may vary depending upon the circumstances (e.g., two-phase versus three-phase). Therefore, what is needed is a standardization on a coordination framework (coordination service) that allows users and services to register with it, and customize it on a per service or per application basis. Such a coordination service would also support newly emerging Web service standards such as workflow and transactions and builds on the Web services CTX Service..."
Web Services Transaction Management (WS-TXM) "comprising three distinct protocols for interoperability across multiple transaction managers and supporting multiple transaction models (two phase commit, long running actions, and business process flows)... WS-TXM supports multiple transaction models to help enable participants to negotiate outcomes with each other and make a common decision about how to behave, especially in the case of failure, regardless whether the execution environment is CORBA, Enterprise JavaBeans (EJB), .NET, Java Message Service (JMS), or some combination... WS-TXN provides a suite of transaction models, each suited to solving a different problem domain. However, because WS-TXN leverages WS-CF, it is intended to allow flexibility in the types of models supported. Therefore, if new models are required for other problem areas, they can be incorporated within this specification..."
- "Web Services Composite Application Framework (WS-CAF) for Transaction Coordination." News story July 29, 2003. Details and references.
- Announcement July 28, 2003. "Industry Leaders Drive Convergence, Publish Web Services Specifications to Coordinate Business Applications. Arjuna Technologies, Fujitsu Software, IONA, Oracle and Sun Microsystems Open Development with Imminent Standardization of Specification Framework."
- WS-CAF documents are available from the company websites of the principal authors:
- Arjuna Technologies Ltd. - http://www.arjuna.com/standards/ws-caf
- Fujitsu Software - http://www.fsw.fujitsu.com/standards/ws-caf
- IONA Technologies PLC - http://www.iona.com/devcenter/standards/WS-CAF/
- Oracle Corporation - http://otn.oracle.com/tech/webservices/htdocs/spec/ws-caf.html
- Sun Microsystems - http://developers.sun.com/techtopics/webservices/wscaf/index.html
On November 09, 2005, W3C released Web Services Choreography Description Language Version 1.0 as a Candidate Recommendation. From the draft Primer: "It is essential in understanding Web Services Choreography Description Language (WS-CDL) to realize that there is no single point of control. There are no global variables, conditions or workunits. To have them would require them to be somewhere and that somewhere would be, by definition, a centralization point. WS-CDL is a language for specifying peer-to-peer protocols where each part wishes to remain autonomous and in which no party is master over any other — i.e., no centralization point. WS-CDL does permit a shorthand notation to enable variables and conditions to exist in multiple places, but this is syntactic sugar to avoid repetitive definitions. There is also an ability for variables residing in one service to be aligned (synchronized) with the variables residing in another service, giving the illusion of global or shared state. It is also important to understand that WS-CDL does not distinguish between observable messages from applications, that might be considered as application or business messages, or from the infrastructure upon which an application is based, that might be considered as some form of signal. In WS-CDL all messages are described as information types and have no special signficance over each other. All that WS-CDl described is the ordering rules for the messages which dictate the order in which they should be observed. When these ordering rules are broken WS-CDL considers them to be out-of-sequence messages and this can be viewed as an error in conformance of the services that gave rise to them against the WS-CDl description regardless of how they may be derived..."
A September 10, 2003 posting from Nickolas Kavantzas (Oracle) to the W3C public list 'firstname.lastname@example.org' under the subject "Web Services Choreography Description Language (WS-CDL) proposal" contained a technology submission for consideration by the W3C Choreography Working Group.
Web Services Choreography Description Language (WS-CDL) 1.0 was edited by Nickolaos Kavantzas and names contributing authors Goran Olsson, Jeff Mischkinsky, and Martin Chapman (Oracle).
The specification abstract: "The Web Services Choreography Description Language (WS-CDL) is an XML-based language that describes cross-enterprise collaborations of Web Services participants by defining their common observable behavior; where ordered and synchronized message exchanges result in alignment of their shared information. The existing Web Services specifications, based on a stateless, connected, client-server model, offer a communication bridge between the heterogeneous computational environments used to develop applications today. The future of E-Business applications requires the ability to perform long-lived business transactions between autonomous services. Applications, exposed as Web Services, must be able to communicate and synchronize their shared state with other Web Services in a loosely coupled environment. These interactions are long-lived and must avoid resource constraints when accessing state information or relaxing consistency guarantees in the presence of potential error recovery conditions. Business collaborations between autonomous Web Service participants will be stateful and require that all participating services can act as peers while reliably communicating in an asynchronous fashion. This specification extends the emerging stack of Web Services standards targeted for integrating applications developed in heterogeneous computation environments."
- Web Services Choreography Working Group
- Announcement 2004-04-27: "World Wide Web Consortium Publishes First Public Working Draft of Web Services Choreography Description Language 1.0. W3C's WS-CDL Targets Peer-to-Peer Web Services Collaboration." Announcement also available in French and Japanese. [W3C source]
- Web Services Choreography Description Language Version 1.0. W3C Working Draft, 27-April-2004.
- Web Services Choreography: "The Web Services Choreography Description Language (WS-CDL) is an XML-based language that describes cross-enterprise collaborations of Web Services participants by defining their common observable behavior; where ordered and synchronized message exchanges result in alignment of their shared information."
- Web Services Choreography Description Language (WS-CDL) 1.0. By Nickolaos Kavantzas (Editor), Goran Olsson, Jeff Mischkinsky, and Martin Chapman. 65 pages.
- Web Services Choreography Description Language (WS-CDL) 1.0. PDF from 37 slides.
- Oracle WS-CDL comparison against the Web Services Choreography Requirements. By Nickolaos Kavantzas (Oracle) Ashwini Surpur (Oracle). October 17, 2003. Notes are also made on BurdettML.
- Oracle CDL Preentation from September 22, 2003.
- ZIP archive with the WS-CDL submission [cache]
- XML Schema 'wscdl.xsd', from the ZIP distribution
The Web Services Conversation Language (WSCL) "allows the abstract interfaces of Web services, i.e., the business level conversations or public processes supported by a Web service, to be defined. WSCL specifies the XML documents being exchanged, and the allowed sequencing of these document exchanges. WSCL conversation definitions are themselves XML documents and can therefore be interpreted by Web services infrastructures and development tools. WSCL may be used in conjunction with other service description languages like WSDL; for example, to provide protocol binding information for abstract interfaces, or to specify the abstract interfaces supported by a concrete service..."
- Web Services Conversation Language (WSCL) 1.0. W3C Note 14 March 2002.
- "Web Services Conversation Language (WSCL)" - Local reference page.
On October 01, 2005 OASIS announced that the three Web Services Transaction specifications were being contributed to a new WS-TX Technical Committee. See details in the news story "OASIS Members Form Web Services Transaction (WS-TX) Technical Committee."
Updated versions of WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity were published in August 2005. Joint authors included Arjuna Technologies, Ltd., BEA Systems, Hitachi, Ltd., International Business Machines Corporation, IONA Technologies, and Microsoft Corporation.
The 'Web Services Transaction Framework' specifications were (initially) published jointly by BEA Systems, IBM and Microsoft. Public drafts of Web Services Coordination (WS-Coordination) and Web Service Transaction (WS-Transaction) were released in August 2002. The Web Services Transaction framework [in 2003-09] was composed of three specifications: WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity. A revised WS-Coordination spec and a new WS-AtomicTransaction spec were published on September 15, 2003. "WS-AtomicTransaction replaces part I of the (original) WS-Transaction specification released August 2002. A specification titled WS-BusinessActivity that replaces part II of WS-Transaction [was] released separately." See "WS-BusinessActivity Specification Completes the Web Services Transaction Framework" [2004-02].
Web Services Coordination (WS-Coordination). Version 1.0. August 2005. 23 pages. With XML Schema (xsd) and WSDL. WS-Coordination namespace URI (RDDL): http://schemas.xmlsoap.org/ws/2004/10/wscoor. Copyright (c) 2002-2005 by Arjuna Technologies, Ltd., BEA Systems, Hitachi, Ltd., International Business Machines Corporation, IONA Technologies, Microsoft Corporation. ["August 2005" URIs: xsd, wsdl, PDF]
Authors: Luis Felipe Cabrera (Microsoft), George Copeland (Microsoft), Max Feingold (Microsoft, Editor), Robert W Freund (Hitachi), Tom Freund (IBM), Jim Johnson (Microsoft), Sean Joyce (IONA), Chris Kaler (Microsoft), Johannes Klein (Microsoft), David Langworthy (Microsoft), Mark Little (Arjuna Technologies), Anthony Nadalin (IBM), Eric Newcomer (IONA), David Orchard (BEA Systems), Ian Robinson (IBM), John Shewchuk (Microsoft), and Tony Storey (IBM). Acknowledgments. The following individuals have provided invaluable input into the design of the WS-Coordination specification: Francisco Curbera (IBM), Sanjay Dalal (BEA Systems), Doug Davis (IBM), Don Ferguson (IBM), Kirill Garvylyuk (Microsoft), Dan House (IBM), Oisin Hurley (IONA), Frank Leymann (IBM), Thomas Mikalsen (IBM), Jagan Peri (Microsoft), Alex Somogyi (BEA Systems), Stefan Tai (IBM), Satish Thatte (Microsoft), Gary Tully (IONA), and Sanjiva Weerawarana (IBM).
Abstract: "This specification (WS-Coordination) describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed activities. The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. Additionally this specification describes a definition of the structure of context and the requirements for propagating context between cooperating services."
Web Services Coordination (WS-Coordination). November 2004. 20 pages. With XML Schema and WSDL. A "second joint publication of the specification." Copyright (c) 2002-2004 BEA Systems, International Business Machines Corporation, Microsoft Corporation. See the licensing terms and Transaction Specification Index Page (Microsoft). "This specification describes an extensible framework for providing protocols that coordinate the actions of distributed applications. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. Additionally this specification describes a definition of the structure of context and the requirements for propagating context between cooperating services." [source PDF]
Web Services Coordination (WS-Coordination). September 15, 2003. "This specification (WS-Coordination) describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed activities. The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. Additionally this specification describes a definition of the structure of context and the requirements for propagating context between cooperating services.
Web Services Coordination (WS-Coordination) (initial version, August 2002)
Web Services Atomic Transaction (WS-AtomicTransaction). Version 1.0. August 2005. 21 pages. Edited by Max Feingold (Microsoft). Copyright (c) 2001-2005 by Arjuna Technologies, Ltd., BEA Systems, Hitachi, Ltd., International Business Machines Corporation, IONA Technologies, and Microsoft Corporation, Inc. With XML Schema (xsd) and WSDL. ["August 2005" URIs: XML Schema (xsd), wsdl, PDF]
Authors: Luis Felipe Cabrera (Microsoft), George Copeland (Microsoft), Max Feingold (Microsoft, Editor), Robert W. Freund (Hitachi), Tom Freund (IBM), Jim Johnson (Microsoft), Sean Joyce (IONA), Chris Kaler (Microsoft), Johannes Klein (Microsoft), David Langworthy (Microsoft), Mark Little (Arjuna Technologies), Anthony Nadalin (IBM), Eric Newcomer (IONA), David Orchard (BEA Systems), Ian Robinson (IBM), Tony Storey (IBM), and Satish Thatte (Microsoft). Acknowledgments. The following individuals have provided invaluable input into the design of the WS-AtomicTransaction specification: Francisco Curbera (IBM), Sanjay Dalal (BEA Systems), Doug Davis (IBM), Gert Drapers (Microsoft), Don Ferguson (IBM), Kirill Garvylyuk (Microsoft), Dan House (IBM), Oisin Hurley (IONA), Frank Leymann (IBM), Thomas Mikalsen (IBM), Jagan Peri (Microsoft), John Shewchuk (Microsoft), Alex Somogyi (BEA Systems), Stefan Tai (IBM), Gary Tully (IONA), and Sanjiva Weerawarana (IBM).
Abstract: "This specification provides the definition of the atomic transaction coordination type that is to be used with the extensible coordination framework described in the WSCoordination specification. The specification defines three specific agreement coordination protocols for the atomic transaction coordination type: completion, volatile two-phase commit, and durable two-phase commit. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of short-lived distributed activities that have the all-or-nothing property."
Web Services Atomic Transaction (WS-AtomicTransaction). November 2004. 17 pages. With XML Schema and WSDL. A "second joint publication of the specification." Copyright (c) 2002-2004 BEA Systems, International Business Machines Corporation, Microsoft Corporation. See the licensing terms and Transaction Specification Index Page (Microsoft). "This specification provides the definition of the atomic transaction coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification. The specification defines three specific agreement coordination protocols for the atomic transaction coordination type: completion, volatile two-phase commit, and durable two-phase commit. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of short-lived distributed activities that have all-or-nothing semantics." [PDF source]
Web Services Atomic Transaction (WS-AtomicTransaction). September 15, 2003. "This specification provides the definition of the atomic transaction coordination type that is to be used with the extensible coordination framework described in the WSCoordination specification. The specification defines three specific agreement coordination protocols for the atomic transaction coordination type: completion, volatile two-phase commit, and durable two-phase commit. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of short-lived distributed activities that have the all-or-nothing property."
Web Services Transaction (WS-Transaction) (initial version, August 2002)
Web Services Business Activity Framework (WS-BusinessActivity). Version 1.0. August 2005. 23 pages. Copyright (c) 2001-2005 by Arjuna Technologies, Ltd., BEA Systems Inc, Hitachi, Ltd., IBM Corporation, IONA Technologies, and Microsoft Corporation. With XML Schema (xsd) and WSDL. WS-BusinessActivity namespace URI (RDDL): http://schemas.xmlsoap.org/ws/2004/10/wsba. ["August 2005" URIs: xsd, wsdl, PDF]
Authors: Luis Felipe Cabrera (Microsoft), George Copeland (Microsoft), Max Feingold (Microsoft), Robert W Freund (Hitachi), Tom Freund (IBM), Sean Joyce (IONA), Johannes Klein (Microsoft), David Langworthy (Microsoft), Mark Little (Arjuna Technologies), Frank Leymann (IBM), Eric Newcomer (IONA), David Orchard (BEA Systems), Ian Robinson (IBM), Tony Storey (IBM), Satish Thatte (Microsoft). Francisco Curbera (IBM), Gert Drapers (Microsoft), Doug Davis (IBM), Don Ferguson (IBM), Kirill Garvylyuk (Microsoft), Dan House (IBM), Oisin Hurley (IONA), Frank Leymann (IBM), Thomas Mikalsen (IBM), Jagan Peri (Microsoft), John Shewchuk (Microsoft), Stefan Tai (IBM), Gary Tully (IONA), and Sanjiva Weerawarana (IBM).
Abstract: "This specification provides the definition of the business activity coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification. The specification defines two specific agreement coordination protocols for the business activity coordination type: BusinessAgreementWithParticipantCompletion, and BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of long-running distributed activities."
Web Services Business Activity Framework (WS-BusinessActivity). November 2004. 22 pages. With XML Schema and WSDL. A "second joint publication of the specification." Copyright (c) 2002-2004 BEA Systems, International Business Machines Corporation, Microsoft Corporation. See the licensing terms and Transaction Specification Index Page (Microsoft). "This specification provides the definition of the business activity coordination type that is to be used with the extensible coordination framework described in the WS-Coordination specification. The specification defines two specific agreement coordination protocols for the business activity coordination type: BusinessAgreementWithParticipantCompletion, and BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these protocols when building applications that require consistent agreement on the outcome of long-running distributed activities." [PDF source]
Web Services Business Activity (WS-BusinessActivity). Not yet published as of 2003-09-15. "WS-BusinessActivity defines the Business Activity coordination type. It is appropriate to use when building applications that require a consistent agreement on the coordination of a distributed activity, where strong isolation is not feasible, and application-specific compensating actions are used to coordinate the activity. This specification replaces Part II (BA) of the previouslyreleased WS-Transaction specification." Update 2004-02: "WS-BusinessActivity Specification Completes the Web Services Transaction Framework."
- Transaction Specification Index Page
- "Updated Specifications for the Web Services Transaction Framework." News September 16, 2003.
- "Web Services Specifications for Business Transactions and Process Automation." News August 12, 2002.
- 'August 2002' WS-Transaction reference page
- 'August 2002' WS-Coordination reference page
"This specification describes a formal method of defining a Choreography using a Choreography Definition Language. Choreographies describe the sequence and conditions in which messages are exchanged between independent processes, parties or organizations in order to realize some useful purpose, for example placing an order. This differs from a Process Execution Language that can be used when there is a single organization or process in control that can issue commands to other processes to carry out all the actions or activities required. If Choreographies are not defined and agreed between the organizations or processes involved, then those organizations and processes will not be able to successfully interoperate to realize their shared objectives... By providing a formal representation of a Choreography in an XML format, this specification allows the definition to be shared and therefore followed by all the organizations or processes that use it. This specification is in two main parts: (1) The first part describes how to define a Choreography in an abstract way that is independent of the format and packaging of the messages being exchanged, and [independent of] the technology used at each end to send and receive messages. (2) The second part describes how to bind the messages in a Choreography to WSDL and SOAP..."
- 2003-10-01 from David Burdett: [there will be a] October 15-16, 2003 meeting in the in the Bay Area at BEA... the objective of the meeting is to take the specifications developed by Oracle and Commerce One and start the process of working out how best to use them together with the WS Chor "Requirements" spec and other known issues to create a draft WS Chor "Language" spec the whole group can consider..."
- 2003-10-07: A comparison of BurdettML (WS Choreography specification) against the draft requirements specification. Posted October 7, 2003. [source PDF]
- "WS Choreography." By David Burdett and Dan Gannon (Commerce One), with contributions by Qiming Chen. Version 0-1 ("first version of the WS Choreography specification"). 13-June-2003. Copyright (c) 2003 Commerce One Operations Inc. 47 pages. Extracted from the ZIP archive, which contains XML sample and XML Schema files; see the file listing. [cache .ZIP]
- "WS Choreography v.0-1 Overview." June 18, 2003. David Burdett, Commerce One. "Work in progress." 30 slides. [cache]
- order placement example and XML source.
- Postings providing background information and references: April 2003, June 2003, August 2003.
[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:  Dynamic and flexible interaction patterns, as shown by the ability of the conversation technology to support complex interactions between Acme and customers.  Adaptable, open-ended, and extensible B2B integration capability, as demonstrated by the ability of the conversation module to account for interface changes.  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.