Update 2004-12-29: "Last Call for W3C Web Services Choreography Description Language (WS-CDL)."

An initial Public Working Draft of the Web Services Choreography Description Language Version 1.0 has been released by W3C.

This document, the first in a series of WS-CDL working drafts, has been produced by members of the W3C Web Services Choreography Working Group as part of the Web Services Activity. Editors of the specification are Nickolaos Kavantzas (Oracle), David Burdett (Commerce One), and Greg Ritzinger (Novell).

The WS-CDL XML-based language "describes peer-to-peer collaborations of Web Services participants by defining, from a global viewpoint, their common and complementary observable behavior, where ordered message exchanges result in accomplishing a common business goal. The Web Services Choreography specification is targeted for composing interoperable peer-to-peer collaborations between any type of Web Service participant regardless of the supporting platform or programming model used by the implementation of the hosting environment."

According to the W3C announcement, the Web Services Choreography Description Language is a "necessary complement to end point languages such as BPEL and Java. WS-CDL provides them with the global model they need to ensure that end point behavior — the 'rules of engagement' — is consistent across cooperating services. Business transactions, especially those envisioned by Web services, grow from complex interactions. These interactions can be viewed from a variety of points in the transaction chain, not simply the start or the expected endpoint. Modeling these interactions from a global viewpoint allows software developers to take into account the distributed race conditions (unexpected dependence on the sequence of events) that may exist — in much the same way they exist in non-Web business processes. Choreography provides the set of rules that explains how different components may act together, and in what sequence, giving a flexible systemic view of the process."

Bibliographic Information

Web Services Choreography Description Language Version 1.0. W3C Working Draft. 27-April-2004. Edited by Nickolaos Kavantzas (Oracle), David Burdett (Commerce One), and Greg Ritzinger (Novell). Version URL: http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/. Latest version URL: http://www.w3.org/TR/ws-cdl-10/.

From the W3C Announcement

The World Wide Web Consortium (W3C) has issued the Web Services Choreography Description Language Version 1.0 as a W3C First Public Working Draft. The Web Services Choreography Description Language (WS-CDL) is targeted to coordinate interactions among Web services and their users. This is the first in the series of WS-CDL drafts.

WS-CDL describes the set of rules that explains how different components may act together, and in what sequence, giving a flexible systemic view of the process. It serves as a necessary complement to BPEL, Java, and other programming languages which describe one endpoint on a transaction, rather than the full system.

Choreography Speeds Time to Market and Reduces Cost of Ownership: One of the aims of Web services is integration (combining components into a system) to reduce connectivity costs and increase the utility and thus the value of information. For many years, the only way integration could be achieved was to plug services together by custom-coding or "wiring" the integration points. Through the use of a global model, choreography ensures that contractual behavior across multiple services can be achieved without complex wiring or complex wiring tools.

Another Web services goal is conformance (the integration of applications so that they share the same rules of engagement) which ensures the desired business outcome. Because a well-defined choreography guarantees conformance across application domains, businesses gain faster time to market.

Statistically, choreography can be shown to be free from deadlocks (when processes stop because each is waiting for one of the others), livelocks (when processes continually react to each other and stop doing useful work) and leaks (interference from unauthorized participants). Leak freedom ensures greater security across connected services. The absence of deadlocks and livelocks lowers testing costs and reduces the total cost of ownership.

WS-CDL Defines Collaboration Between Applications: The WS-CDL specification defines peer-to-peer collaboration between Web service participants. A user of a Web service, automated or otherwise, is a "client" of that service. Users may be other Web services, applications and human beings. In WS-CDL, a set of client interactions may be related over time in a "collaboration group." A collaboration group could be for example, a set of components that make up a business transaction or a database transaction.

The future of e-business applications is in the loosely coupled, decentralized environment of the World Wide Web. This environment requires the ability to perform long-lived, peer-to-peer collaborations between the participating services, within or across the trusted domains of an organization. Applications that implement WS-CDL can accomplish this shared business goal, as the Working Group developed its requirements document to consider both broad practical business needs and sound theories.

WS-CDL Has Sound Industrial and Mathematical Foundations: The WS-CDL specification brings together important resources from both industry and research. WS-CDL incorporates not only business requirements, but also seminal mathematical work in pi (Π) calculus, an algebra based on naming used to model systems that are physically or virtually mobile. Invited Experts in the W3C Web Services Choreography Working Group include Professor Robin Milner, the principal creator of pi calculus; Dr. Kohei Honda; and Dr. Nobuko Yoshida. Their collective work on pi calculus and correctness properties (livelock, deadlock and leak freedom) is the underpinning of WS-CDL, giving the language mathematical soundness.

Participants: The participants in the W3C Web Services Choreography Working Group (in alphabetical order) are Apple Computer; Arjuna Technologies Ltd; BEA Systems; Choreology Ltd; Cisco Systems; Commerce One; Computer Associates; DSTC Pty Ltd (CITEC); EDS; Enigmatec Corporation; Fujitsu Ltd; Hewlett-Packard; Hitachi, Ltd.; Intalio Inc.; IONA; MTA SZTAKI; National Computerization Agency; Nortel Networks; Novell; Oracle; SAP AG; SeeBeyond Technology Corporation; Software AG; Sonic Software; Sun Microsystems, Inc.; Thomson Corporation; TIBCO Software; Uniform Code Council; University of Maryland (Mind Lab); W. W. Grainger, Inc.; webMethods, Inc., and Invited Experts Dr. Honda, Professor Milner, and Dr. Yoshida. The group is chaired by Martin Chapman (Oracle) and Steve Ross-Talbot (Enigmatec)... [excerpted; see details in the press release]

Introduction to WS-CDL

"For many years, organizations have being developing solutions for automating peer-to-peer collaborations, within or across their trusted domain, in an effort to improve productivity and reduce operating costs.

The past few years have seen the Extensible Markup Language (XML) and the Web Services framework developing as the de-facto choices for describing interoperable data and platform neutral business interfaces, enabling more open business transactions to be developed.

Web Services are a key component of the emerging, loosely coupled, Web-based computing architecture. A Web Service is an autonomous, standards-based component whose public interfaces are defined and described using XML. Other systems may interaction with the Web Service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.

The Web Services specifications offer a communication bridge between the heterogeneous computational environments used to develop and host applications. The future of E-Business applications requires the ability to perform long-lived, peer-to-peer collaborations between the participating services, within or across the trusted domains of an organization.

The Web Service architecture stack targeted for integrating interacting applications consists of the following components:

• SOAP: defines the basic formatting of a message and the basic delivery options independent of programming language, operating system, or platform. A SOAP compliant Web Service knows how to send and receive SOAP-based messages
• WSDL: describes the static interface of a Web Service. It defines the protocol and the message characteristics of end points. Data types are defined by XML Schema specification, which supports rich type definitions and allows expressing any kind of XML type requirement for the application data
• UDDI: allows publishing the availability of a Web Service and its discovery from service requesters using sophisticated searching mechanims
• Security layer: ensures that exchanged information are not modified or forged
• Reliable Messaging layer: provides exactly-once and guaranteed delivery of information exchanged between participants
• Context, Coordination and Transaction layer: defines interoperable mechanisms for propagating context of long-lived business transactions and enables participants to meet correctness requirements by following a global agreement protocol
• Business Process Languages layer: describes the execution logic of Web Services based applications by defining their control flows (such as conditional, sequential, parallel and exceptional execution) and prescribing the rules for consistently managing their non-observable data
• Choreography layer: describes peer-to-peer collaborations of Web Services participants by defining from a global viewpoint their common and complementary observable behavior, where information exchanges occur, when the jointly agreed ordering rules are satisfied

The Web Services Choreography specification is targeted for composing interoperable, peer-to-peer collaborations between any type of Web Service participant regardless of the supporting platform or programming model used by the implementation of the hosting environment..." [from the Version 1 spec 'Introduction']

Goals of WS-CDL

The primary goal of a Choreography Language for Web Services is to specify a declarative, XML based language that defines from a global viewpoint their common and complementary observable behavior, where message exchanges occur, when the jointly agreed ordering rules are satisfied.

Some additional goals of this definition language are:

• Reusability: The same choreography definition is usable by different participants operating in different contexts (industry, locale, etc.) with different software (e.g., application software)
• Cooperative: Choreographies define the sequence of exchanging messages between two (or more) independent participants or processes by describing how they should cooperate
• Multi-Party: Choreographies can be defined involving any number of participants or processes
• Semantics: Choreographies can include human-readable documentation and semantics for all the components in the choreography
• Composability: Existing Choreographies can be combined to form new Choreographies that may be reused in different contexts
• Modular: Choreographies can be defined using an "import" facility that allows a choreography to be created from components contained in several different Choreographies
• Information Driven: Choreographies describe how participants that take part in Choreographies maintain where they are in the Choreography by recording their exchanged information and the observable state changes caused by these exchanges of information and also their reactions to them
• Information Alignment: Choreographies allow the participants that take part in Choreographies to communicate and synchronize their observable state changes and the actual values of the exchanged information as well
• Exception Handling: Choreographies can define how exceptional or unusual conditions that occur whilst the choreography is performed are handled
• Transactionality: The processes or participants that take part in a choreography can work in a "transactional" way with the ability to coordinate the outcome of the long-lived collaborations, which include multiple, often recursive collaboration units, each with its own business rules and goals
• Compatibility with other Specifications: This specification will work alongside and complement other specifications such as the WS-Reliability, WS-Composite Application Framework (WS-CAF), WS-Security, Business Process Execution Language for WS (BPEL4WS), etc. [from spec Section 1.3]