Multiple participants are engaging in a conversation.
How can a conversation policy be described?
While some conversations foresee a clear "master"", e.g. the service provider in a simple two-party conversation, other conversations, such as leader election, are by definition symmetric across multiple participants.
A conversation is really about what happens between the participants. Hence a neutral view of all messages exchanged between all participants is natural.
Define the flow of messages between participants from the point of view of a third-party observer.
A choreography is not an executable element, but a specification that can be used to generate participant interfaces or to validate existing message flows, assuming all messages pass through a central observer. In widely distributed or high-throughput systems this may not be possible or practical.
A choreography can be described as an abstract process or as a set of constraints.
Example: BPMN 2.0
Example: WS-CDL
The Choreography Description Language (WS-CDL) specification describes the language as "aimed at being able to precisely describe collaborations between any type of participant regardless of the supporting platform or programming model" [http://www.w3.org/TR/ws-cdl-10/] WS-CDL defines which participant can send what type of message to which other participant in what order. The message ordering constraints are expressed through the elements sequence, parallel, and choice, similar to a process description. For example, a sequence element can prescribe that a request message has to be sent by the consumer before a response message can be sent by the service provider. Likewise, the parallel element expresses that two or more messages can be sent in any order.
Because WS-CDL describes a conversation from a neutral observer’s viewpoint the choreography is only a specification, not an executable language. Tools can, however, project this specification to generate endpoint processes (e.g. Java code or a BPEL process template) that fulfill the constraints set forth by the choreography.
WS-CDL is implemented by very few tools and has gained minimal market acceptance. One of the issues may have been that it was defined without a reference implementation or significant vendor support. The Savara open source project (http://savara.jboss.org/) was based on WS-CDL originally, but has since turned into a generic architecture testing and validation tool.
Ultimately, it may be that the WS-CDL standardization effort came too early in the evolution of SOAs. Indeed, WS-CDL has attempted at the same time to be groundbreaking and to create a consensus. In this respect, it is insightful to compare the development of WS-CDL with that of BPEL. BPEL stemmed from two sources, WSFL and XLang, which derived themselves from languages supported by existing tools (namely MQSeries Workflow and BizTalk). Furthermore, together with the first draft of BPEL, a prototype implementation was released. In contrast, WS-CDL has been developed without any prior implementation and does not derive (directly) from any language supported by an implementation. (http://www.bptrends.com/publicationfiles/03-05%20WP%20WS-CDL%20Barros%20et%20al.pdf)
