The W3C Web Services Choreography Working Group has released an initial public working draft for Web Services Choreography Model Overview and an updated version of Web Services Choreography Requirements.

The Working Group has been chartered to define a choreography definition language for coordinating interactions among Web services and their users. The Choreography Definition Language (CDL) will "define a language based on WSDL 2.0 that can describe a peer-to-peer global model for cross-enterprise interactions and their semantics through the composition of web services that are independent of any specific programming language."

The Model Overview document provides "an information model that describes the data and the relationships between them that is needed to define a choreography that describes the sequence and conditions in which the data exchanged between two or more participants in order to meet some useful purpose. Global definitions of a choreography facilitate choreography reuse especially if choreographies are defined with varying degrees of abstraction. The draft model identifies and supports three different levels of abstraction in which choreographies can usefully be defined and used: abstract, portable and concrete choreographies."

The Web Services Choreography Requirements document "describes a set of requirements for Web Services choreography based upon a set of representative use cases, as well as general requirements for interaction among Web Services. In order to gather requirements for Web Services Choreography, the working group has currently chosen to follow two paths toward this end. The first means of gathering requirements consists of examination of member-submitted use cases, from which requirements may be inferred. The second methods involves the use of the Critical Success Factor analysis methodology."

Bibliographic Information

• Web Services [WS] Choreography Model Overview. W3C Working Draft 24-March-2004. Edited by David Burdett (Commerce One) and Nickolas Kavantzas (Oracle). First Public Working Draft. Produced by members of the W3C Web Services Choreography Working Group. Version URL: http://www.w3.org/TR/2004/WD-ws-chor-model-20040324/. Latest version URL: http://www.w3.org/TR/ws-chor-model/.

• Web Services Choreography Requirements. W3C Working Draft 11-March-2004. Edited by Daniel Austin (Sun), Abbie Barbir (Nortel Networks, Inc), Ed Peters (WebMethods, Inc), and Steve Ross-Talbot (Enigmatec, Inc). Produced by members of the W3C Web Services Choreography Working Group. Version URL: http://www.w3.org/TR/2004/WD-ws-chor-reqs-20040311/. Latest version URL: http://www.w3.org/TR/ws-chor-reqs/. Previous version URL: http://www.w3.org/TR/2003/WD-ws-chor-reqs-20030812/.

From the Web Services Choreography Model Overview

Business or other activities that involve multiple different organizations or independent processes that use Web service technology to exchange information can only be successful if they are properly coordinated. This means that the sender and receiver of a message know and agree in advance:

• The format and structure of the (SOAP) messages that are exchanged
• The sequence and conditions in which the messages are exchanged

WSDL and its extensions provide a mechanism by which the first objective is realized, however, it does not define the sequence and conditions, or choreography, in which messages are exchanged.

To solve this problem, a shared common or "global" definition of the sequence and conditions in which messages are exchanged is produced that describes the observable complementary behavior of all the participants involved. Each participant can then use the definition to build and test solutions that conform to the global definition.

The main advantage of a global definition approach is that it separates the process being followed by an individual business or system within a "domain of control" from the definition of the sequence in which each business or system exchanges information with others. This means that, as long as the "observable" sequence does not change, the rules and logic followed within the domain of control can change at will.

The purpose of this [Model Overview] paper is to describe an information model or "meta model" for a Choreography Definition Language that identifies the information and structures required to build a "global" definition.

Goals. Some additional goals of this model of a choreography definition language:

• Reusability. The same choreography definition is usable by different participants operating in different contexts (industry, locale, etc) with different software (e.g., application software) and different message formats and standards
• 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 the state changes caused by exchanges of information and their reactions to them
• Information Alignment. Choreographies allow the participants that take part in choreographies to communicate and synchronize their states and the information they share
• Transactionality. The processes or participants that take part in a choreography can work in a "transactional" way with the ability to specify how transactions are compensated
• Exception Handling. Choreographies can define how exceptional or unusual conditions that occur whilst the choreography is performed are handled
• Design Time Verification. A developer of a business process can use the Choreography Definition, on their own to: (1) Generate a behavioral interface that conforms to a BPEL definition that describes the sequence and conditions in which one of the participants in a choreography sends and receives messages; (2) Verify that a BPEL definition conforms to behavior defined by in a Choreography Definition
• Run Time Verification. The performance of a choreography can be verified at run time against the Choreography Definition to ensure that it is being followed correctly. If errors are found then the choreography can specify the action that should be taken
• Compatibility with other Specifications. The specifications will work alongside and complement other specifications such as the WS Reliability, WS WS Composite Application Framework (WSCAF), WS Security (WSS), WS Business Process Execution Language (WSBPEL) etc.

About Web Services Choreography

Web Services Choreography concerns the observable 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. A specific set of interactions maybe related over time to some form of collaboration grouping that is initiated at some source and runs through a set of Web Services and their client. We use the term "collaboration group" as a generic term that may encompass the concept of a "business transaction", an "ACID transaction" or a "cohesion". Thus for the purpose of clarity we define a collaboration group among Web Services and their clients as a specific set of observable interactions to which further meaning maybe attached.

A choreography description is a multi-party contract that describes from global view point the external observable behavior across multiple clients (which are generally Web Services but not exclusively so) in which external observable behavior is defined as the presence or absence of messages that are exchanged between a Web Service and it's clients.

A choreography description language (CDL) is the means by which such a technical contract is described.

The main use of a choreography description is to precisely define the sequence of interactions between a set of cooperating web services in order to promote a common understanding between participants and to make it as easy as possible to:

• promote a common understanding between WS participants
• automatically validate conformance
• ensure interoperability
• increase robustness
• generate code skeletons

A choreography description may be used to generate the necessary code skeletons that can be said to implement the required external observable behavior for that Web Service. For example, a choreography description that is used to describe the multi-party contract between a travel agent and a number of hotel companies might be used by any potential participant to generate a code skeleton for a web service that can be guaranteed to be interoperable with that particular travel agent.

A choreography description may also be used to aid the testing of participating Web Services through the generation of test messages that could be sent to participants by means of an appropriate vendor specific tool that reads the choreography description and manages the test interaction according to the choreography description.

A choreography description may also be used to validate the multi-party observable interactions amongst a collection of Web Services. For example, a hotel may load a choreography description into a vendor specific tool which informs them of any breaches of the cherography.

A choreography description may also be used to show the presence of usefull properties such as lock freedom and leak freedom in the behavioral contract. In this sense a choreography description acts as a model of the behavior across a number of Web Services which in turn can be subject to static analysis to show that if and only if the underlying Web Services behave according to the contract that the interaction between the Web Services will exhibit these properties.

The description of interactions among Web Services in particular with regard to the exchange of messages, their composition, and the sequences in which they are transmitted and received — is an important problem. These interactions may take place among groups of services which, in turn, make up a larger, composite service, or which interact across organizational boundaries in order to obtain and process information. The problems of Web Services choreography are largely focused around message exchange and sequencing these messages in time to the appropriate destinations. In order to fulfill the needs of the Web Services community, these aspects of Web Services must be developed and standardized in an interoperable manner, taking into account the needs of each individual service as well as those of its collaborators and users.

WG Mission Statement: The mission of the W3C Web Services Choreography Working Group is to define a language based on WSDL 2.0, that can describe a peer-to-peer global model for cross-enterprise interactions and their semantics through the composition of web services that are independent of any specific programming language.

This [Requirements]document describes a set of requirements for Web Services choreography based around a set of representative use cases, as well as general requirements for interaction among Web Services. In order to gather requirements for Web Services Choreography, the working group has currently chosen to follow two paths toward this end. The first means of gathering requirements consists of examination of member-submitted use cases, from which requirements may be inferred. The second methods involves the use of the Critical Success Factor analysis methodology... [adapted from the Web Services Choreography Requirements document, Sections 1-2]