Web Services Choreography

Description Language Overview

6th December 2004JP Morgan

Steve Ross-Talbot

Chair W3C Web Services Activity

Co-chair W3C Web Services Choreography

Gary Brown

Member W3C Web Services Choreography

Agenda• What is Choreography?• What is CDL?• Why would I use the CDL?• How would I use the CDL?• What are the components of CDL?• How does BPEL compare with CDL?• What is the underlying approach to CDL?• What extensions and tools are planned for CDL?

What is Choreography?• A working group in W3C, that is tasked with defining a

language for describing peer to peer interactions of services from a neutral perspective.

• Based on a formalized description of external observable behavior across domains

• Current status– Requirements document (published March 2004)– Model Overview document (published April 2004), – 1st Working Draft of the CDL specification (published April

2004),– Latest Working Draft of CDL (published Sept 2004)– Next draft will form the basis of a Last Call Working Draft

What is CDL?• CDL is the Choreography Description Language

• It is a language that can be used to describe collaboration protocols of cooperating [Web] Service participants in which

– Services act as peers– Interactions may be long-lived and stateful

• A CDL-based description is a multi-participant contract that describes, from a neutral or global viewpoint, the common observable behavior of the collaborating Service participants

Not just Web Services

The syntax of the roleType construct is: <roleType name="ncname"> <behavior name="ncname" interface="qname"? />+ </roleType>

The attribute name is used for specifying a distinct name for each roleType element declared within a Choreography Package. Within the roleType element, the behavior element specifies a subset of the observable behavior a party exhibits. A Role Type MUST contain one or more behavior elements. The behavior element defines an optional interface attribute, which identifies a WSDL interface type. A behavior without an interface describes a Role Type that is not required to support a specific Web Service interface.

Why would I use it?• You would use the CDL to create

– More robust Services because they can be validated statically and at runtime against a choreography description,

– To ensure effective interoperability of Services, which is guaranteed because Services will have to conform to a common behavioral multi-party contract specified in the CDL,

– To reduce the cost of implementing Services by ensuring conformance to expected behaviour described in the CDL. This in turn can be used to guide and structure testing and so reduce the overall time to deployment of a Service.

– To formally encode agreed multi-party business protocols such as fpML, FIX, SWIFT and TWIST so that those parties that use these protocols can be sure of conformance across parties.

How would I use it?• You would use the CDL through a validating design tool, perhaps as an

Eclipse plug-in.

• You would describe your multi-party contract in terms of a global model and it would be rendered in CDL.

• You would use additional CDL-based tools to generate:– Skeletal code (in Java, C#, BPEL etc) that ensures behavior of a service

conforms to the CDL description,– Test programs that generate appropriate messages based on the CDL

description,

• You would use additional CDL-based tools to provide runtime verification of services against their expected behavior as defined in the CDL description.

• You would use CDL to describe existing multi-party protocol in terms of their behavior and import the necessary information types (data types i.e. fpML + CDL)

What are the components?

Roles, Relationships, Channels

Choreography, Interaction

Structured composition

Non Observable Conditionals

Observable Conditionals

State MgmtNo State Mgmt

Package Work

un

its, Exce

ptio

ns, Fin

al ize

rs

Components (1)• Package

– Participants - service locations that implement a set of roles,

– Roles - service end points (WSDL), – Relationships - association between roles – Channel types – communication channel

definitions

Components (2)• Choreography

– Composable unit that describes the behaviour between the defined participants based on the roles that they play and the channels that they use to interact.

• Interaction– Describes a communication between two

participants along a channel instance (e.g. req/resp, oneway req, etc).

• Channel instances– Represents the communication 'pipe' that is

established between two roles. The channel type, associated with the instance, may permit an instance of the channel to transfer other channel instances as valid messages (i.e. channel passing).

Components (3)

• Structured Activities– Sequence - describes a sequence of activities– Parallel - describes a parallel set of activities– Choice – describes a mutually exclusive set of

activities– Repetition - describes the ability to repeat a

set of activities– Perform - describes the ability to perform a

sub-choreography within an enclosing choreography such that it appears to be in-lined.

• Conditionals – Non-observable

• Describes a conditional through inference based on observation. Describing what happened in a business protocol

– Observable• Describes the ability to define a boolean predicate that

is evaluated to true or false. Describing a business constraint on a protocol e.g. AcceptQuote can only relate to most recent quote info.

Components (4)

Components (5)

• Distributing knowledge to constrain a business protocol through Observable conditions– Achieved through conditional activities (repetition,

conditionals (if) and guards (workunits))– Recording state– Sharing/Aligning state– Assignment of state

Components (6)• Workunits

– A workunit represents a grouping construct for a set of contained activities

– A workunit can define a guard condition, to make these activities conditional

– A workunit can express a repetition condition, to indicate whether the activities should be repeated

– A workunit can be used for synchronization based the variables used in the guard condition. If variables used in the condition are not currently set, then the evaluation of the condition would suspend until all the information was available.

Components (6)

<workunit name="ncname" guard="xsd:boolean XPath-expression"? repeat="xsd:boolean XPath-expression"? block="true|false"? >

other-activity/other-activities </workunit>

Components (7)

• Exceptions – a special kind of workunit associated with a

choreography that is enabled when an exception is detected.

• Finalizers – A finalizer defines a set of activities. When a

'performed' choreography completes successfully, it can enable one or more finalizers. One of these finalizers can then be selected by the performing choreography to complete the work associated with the 'performed' choreography (e.g. Confirm or Cancel). This mechanism can be used to provide a typical compensation model, as well as support a range of coordination models.

An Example<choreography name="priceRequest" root="false">

<relationship type="tns:BuyerSeller"/><variableDefinitions>

<variable name="SellerA” informationType="tns:channelType"/><variable name="SellerB” informationType="tns:channelType"/>

<\variableDefinitions><parallel>

<!—Two interactions with two variables … -- ><interaction channelVariable="tns:SellerA” operation="priceRequest" align="false" initiateChoreography="true">

<participate relationship="tns:BuyerSeller" fromRole="tns:Buyer" toRole="tns:Seller"/> <exchange messageContentType="tns:priceReqMessage" action="request" /> <exchange messageContentType="priceRespMessage" action="respond" /> <!—Record the price at the buyer role for later consolidation into “prices” -- ><record role="tns:Buyer" action="response">

<source variable="cdl:getVariable(tns:price, PR/????, tns:Seller)"/> <target variable="cdl:getVariable(tns:priceA, tns:Buyer)"/>

</record> </interaction>

<interaction channelVariable="tns:SellerB" operation="priceRequest" align="false" initiateChoreography="true"> <participate relationship="tns:BuyerSeller" fromRole="tns:Buyer" toRole="tns:Seller"/> <exchange messageContentType="tns:priceReqMessage" action="request" /> <exchange messageContentType="priceRespMessage” action="respond" /> <!—Record the price at the buyer role for later consolidation into “prices” -- ><record role="tns:Buyer" action="response">

<source variable="cdl:getVariable(tns:price, PR/????, tns:Seller)"/> <target variable="cdl:getVariable(tns:priceB, tns:Buyer)"/>

</record> </interaction>

<\parallel><\choreography>

Comparing BPEL with CDL• BPEL

– Orchestration implies a centralized control mechanism. – Recursive Web Service Composition.– Executable language.– Requires Web Services.

• CDL– Choreography has no centralized control. Instead control is

shared between domains.– Description language.– Does not need Web Services but is targeted to deliver over

them.– Can be used to generate BPEL and so complimentary.

The Approach

• Based on simple contract-like mechanisms– Deadlock-freedom (Kobayashi, 99, 00)– Liveness (Kobayashi, 01; Yoshida, et al, 02)– Security (Abadi et al; Cardelli and Gordon;

Berger, Honda, Yoshida)– Resource management (Tofte; Kobayashi;

Gordon and Dal Zillio; Yoshida, et al)– Race-condition detection (refs)

• Which are extensions to CCS/CSP and π-calulus (Milner)

The Approach

Contract

Does roughly what client wants it to do

Web service Implementation

Behaviorial type

Bisimulation ‘approximation’

Process

Mobile process calculi provided a natural candidate.