Web Services Choreography Description Language Overview

1. 6th December 2004 JP Morgan Steve Ross-Talbot Chair W3C Web Services Activity Co-chair W3C Web Services Choreography Gary Brown Member W3C Web Services Choreography Web Services ChoreographyDescription Language Overview

2. 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?

3. 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

4. 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

5. 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.

6. 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.

7. 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)

8. What are the components? Package Roles, Relationships, Channels Choreography, Interaction Workunits, Exceptions, Finalizers Structured composition Non Observable Conditionals No State Mgmt State Mgmt Observable Conditionals

9. 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

10. 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).

11. 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.

12. Components (4) • 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.

13. 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

14. 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.

15. Components (6) • <workunit name="ncname" • guard="xsd:boolean XPath-expression"? • repeat="xsd:boolean XPath-expression"? • block="true|false"? > • other-activity/other-activities • </workunit>

16. 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.

17. 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>

18. 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.

19. 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)

20. Web service Implementation Process Does roughly what client wants it to do Bisimulation ‘approximation’ Contract Behaviorial type The Approach Mobile process calculi provided a natural candidate.