Web Services Choreography Description Language Overview

1
Web Services ChoreographyDescription Language
Overview

• 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

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
• ltroleType name"ncname"gt
• ltbehavior name"ncname" interface"qname"?
  /gt
• lt/roleTypegt
• 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)
ltworkunit name"ncname" guard"xsdboolean
XPath-expression"?
repeat"xsdboolean XPath-expression"?
block"truefalse"? gt other-activity/other-
activities lt/workunitgt
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
ltchoreography name"priceRequest"
root"false"gt ltrelationship type"tnsBuyerSeller
"/gt ltvariableDefinitionsgt ltvariable
name"SellerA informationType"tnschannelType"/gt
ltvariable name"SellerB informationType"tnsc
hannelType"/gt lt\variableDefinitionsgt ltparallel
gt lt!Two interactions with two variables --
gt ltinteraction channelVariable"tnsSellerA
operation"priceRequest" align"false"
initiateChoreography"true"gt ltparticipate
relationship"tnsBuyerSeller" fromRole"tnsBuyer
" toRole"tnsSeller"/gt ltexchange
messageContentType"tnspriceReqMessage"
action"request" /gt ltexchange
messageContentType"priceRespMessage"
action"respond" /gt lt!Record the price at
the buyer role for later consolidation into
prices -- gt ltrecord role"tnsBuyer"
action"response"gt ltsource variable"cdlgetVa
riable(tnsprice, PR/????, tnsSeller)"/gt
lttarget variable"cdlgetVariable(tnspriceA,
tnsBuyer)"/gt lt/recordgt lt/interactiongt
ltinteraction channelVariable"tnsSellerB"
operation"priceRequest" align"false"
initiateChoreography"true"gt ltparticipate
relationship"tnsBuyerSeller" fromRole"tnsBuyer
" toRole"tnsSeller"/gt ltexchange
messageContentType"tnspriceReqMessage"
action"request" /gt ltexchange
messageContentType"priceRespMessage
action"respond" /gt lt!Record the price at
the buyer role for later consolidation into
prices -- gt ltrecord role"tnsBuyer"
action"response"gt ltsource variable"cdlgetVa
riable(tnsprice, PR/????, tnsSeller)"/gt
lttarget variable"cdlgetVariable(tnspriceB,
tnsBuyer)"/gt lt/recordgt lt/interactiongt
lt\parallelgt lt\choreographygt
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 p-calulus
  (Milner)

20
The Approach
Mobile process calculi provided a natural
candidate.