Enterprise Integration PatternsConversation Patterns
HOME    PATTERNS    RAMBLINGS    ARTICLES    TALKS    DOWNLOAD    BOOKS    CONTACT

Choreography

Conversation Patterns

Previous Previous   Next Next

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)



Introduction
Overview
Preface
Table of Contents
Introduction
Describing Conversations
Choreography
Orchestration
Hypermedia State
Conversation Vocabulary
Discovery
Dynamic Discovery
Advertise Availability
Consult Directory
Referral
Leader Election
Starting a Conversation
Three-Way Hand Shake
Acquire Token First
Rotate Tokens
Verify Identity
User Grants Access
Basic Conversations
Fire-and-Forget
Asynchronous Request-Response
Request-Response with Retry
Polling
Subscribe-Notify
Quick Acknowledgment
Intermediaries
Proxy
Relay
Load Balancer
Scatter-Gather
Managing Distributed Systems
Heartbeat
Resource Management
Incremental State Build-up
Lease
Renewal Reminder
Ensuring Consistency
Ignore Error
Compensating Action
Tentative Operation
Coordinated Agreement
Appendices
Bibliography