WSCDL and a Theoretical Basis for CommunicationCentred Programming

1
WS-CDL and a Theoretical Basis for
Communication-Centred Programming

• 5th December 2006
• Marco Carbone
• Imperial College London

2
Agenda

• Choreography
• WS-CDL
• Tools for code generation, monitoring, etc.
• Modelling WS-CDL
• The Global Calculus
• Formalizing code generation (EPP)
• Conclusions and Future Work

3

• In collaboration with
• Kohei Honda, Nobuko Yoshida and myself (Theory)
• Gary Brown and Steve Ross-Talbot (Pi4Tech) and
  W3C WS-CDL working group (Practice)

4
WS-CDL

• Web Services Choreography Description Language
• Language developed by W3C (WS-CDL working-group)
  from January 2003
• in collaboration with many private companies e.g.
  Pi4Tech, Adobe, Oracle, Sun, etc.
• p-calculus experts invited in 2004 (R. Milner and
  us)
• soon a W3C standard

5
What is CDL?

• CDL is an XML-based description language for
  designing systems
• Initially tasked with defining business processes
  in a Web Service context
• Focus became a behavioral contract language for
  distributed systems (e.g. collaboration protocols
  of cooperating Web Service participants)

6
What is CDL? (2)

• A CDL-based description is a multi-participant
  contract that describes, from a neutral or global
  viewpoint, the common observable behaviour of the
  collaborating Service participants in order to
  achieve the same goal
• The main idea is
• Dancers dance following a global scenario
  without a single point of control

7
What is CDL? (3)
What about writing something like Bob ? Alice
ltm, xgt. Dave ? Alice ltn,ygt or (xml-style) ltseque
ncegt ltmessage fromBob toAlice valm
varxgt ltmessage fromDave toAlice valn
varygt lt/sequencegt
Alice int x, y y ch1.receive(Bob) x
ch2.receive(Dave)
Bob int y y ch1.send(Alice,m)
Dave ch2.send(Alice, n)
8
WS-CDL - An example
What about writing alternative options e.g. a
QuoteReject?
or spawning parallel behaviours?
or recursive behaviours (e.g. while, repeat,
etc.) ?
9
WS-CDL - An example
10
WS-CDL - Structure
11
Why/how would I use it?

• More robust Services as they can be validated
  statically and at runtime against a choreography
  description
• To ensure effective interoperability of Services
  as they will have to conform to a common
  behavioral multi-party contract specified in the
  CDL
• To reduce the implementation cost by ensuring
  conformance to expected behaviour described in
  CDL
• 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
• All things above to be supported by theory

12
WS-CDL - Tools

• Open Source www.pi4soa.org Eclipse plugins
• Validating editor (graphical and tree based)
• Behavioral Monitoring
• CDL2Java (1.4, 1.5), CDL2BPEL (1.X, 2.0) ,
  CDL2WSDL (1.1, 2.0) and CDLEPP (soon available)
• Project members
• Steve Ross-Talbot, Gary Brown (lead), Nobuko
  Yoshida, Kohei Honda, Marco Carbone, Robin
  Milner, Charlton Barretto

13
WS-CDL - Tools
Graphical Grammar
14
WS-CDL - Tools
Graphical Grammar
15
WS-CDL - Tools
Graphical Grammar
16
WS-CDL - Tools
Graphical Grammar
17
WS-CDL - Tools
Code Generation and Deployment
18
WS-CDL - Tools
Behavioral Monitor
19
Few more questions

• How do we map WS-CDL to executable processes?
  What
• is the behaviour underlying CDL?
• How can we offer formal foundations for static
  and dynamic
• validation of WS-CDL? Can we precisely relate CDL
  to
• theories of processes?
• Are there good programming/type disciplines for
  CDL?
• What is structured programming for communication
  and
• concurrency?

20
Formalising WS-CDL

• The Global Calculus and a Theory of End-Point
  Projection

21
Syntax of the Global Calculus
I A ? B ch(s1,, sk). I (init)
A ? B s(op, e, y). I (comm) x_at_A e. I
(assign) if e_at_A then I1 else I2
(cond) I1 I2 (par) I1 I2
(sum) (?s) I (new) X
(recvar) µX. I (rec)
0 (inaction)
22
Formal Semantics

• Between configurations
• (s, I) ? (s, I)
• where s is an environment. It maps, for each
  participant A, local variables to their stored
  values.
• Example rules
• (s, A ? B s(op, V, x). I) ? (sx_at_B ? V, I
  )
• (s, x_at_A V. I) ? (sx_at_A ? V, I )

23
Buyer-Seller Examples (1)
Buyer ? Seller ch1( s, t). Buyer ? Seller s (
QuoteReq, product, x ). Seller ? Buyer t (
QuoteRes, quote, y ). Buyer ? Seller s (
QuoteAcc, creditcard, z ). Seller ? Shipper
ch2( r ). Seller ? Shipper r ( ShipReq, z, x
). Shipper ? Seller r ( ShipConf ). Seller
? Buyer t ( OrderConf ). 0 Seller ?
Database ch3( r ). Seller ? Database r (
Transaction, z, x ). Shipper ? Seller r (
Conf ).0
24
Buyer-Seller Examples (2)
Buyer ? Seller ch1( s, t). Buyer ? Seller s (
QuoteReq, product, x ). Seller ? Buyer t (
QuoteRes, quote, y ). Buyer ? Seller s (
QuoteAcc, creditcard, z ). Seller ? Shipper
ch2( r ). (as before) Buyer
? Seller s ( QuoteNoGood ). 0
25
Buyer-Seller Examples (3)
Buyer ? Seller ch1( s, t). Buyer ? Seller s (
QuoteReq, product, x ). Seller ? Buyer t (
QuoteRes, quote, y ). if reasonable(y)_at_Buyer
then Buyer ? Seller s ( QuoteAcc, creditcard,
z ). Seller ? Shipper ch2( r ). (as
before) else Buyer ? Seller s (
QuoteNoGood ). 0
26
Buyer-Seller Examples (4)
Buyer ? Seller ch1( s, t). Buyer ? Seller s (
QuoteReq, product, x ). µX. Seller ? Buyer t (
QuoteRes, quote, y ). if reasonable(y)_at_Buyer
then Buyer ? Seller s ( QuoteAcc, creditcard,
z ). Seller ? Shipper ch2( r ). (as
before) else Buyer ? Seller s (
QuoteNoGood ). X
27
Session Types

• Each service channel ch has a type a which
  specifies how the two participants opening a
  session exchange information (protocol)
• each channel ch belongs to only one participant
• Communications are linear
• Properties Subject Reduction, Minimal Typing,
  ...

28
The End-Point Projection

• EPP projects a global description to multiple
  end-points
• I ? ?EPP A P B Q C R
  
• Desirable properties
• Type preservation the typing is preserved
  through EPP.
• Soundness nothing but behaviours in I are in
  its EPP.
• Completeness all behaviours in I are in its
  EPP.

Code running at each peer
29
How does EPP work?

• A will behave as
• Req(b,s). Out (s,go). In(s,ok). . .
• par
• !Serv(a,r). Out (r,hi). . . .
• B will behave as
• !Serv(b,s). Out(s,go). Req(c,t). In(t,acc).
  Out(s,ok). . . .
• C will behave as
• !In(c,t). Req(a,r). In(r,hi). Out(t,acc)

A ! B b( s). A ! B shgoi. B ! C c( t) . C !
A a( r ) . A ! C r hhii . C ! B thacci . B
! A shoki.
30
Three Principles for EPP

• Connectedness a causality principle
• Well-threadedness a local causality principle
• Coherence consistent behaviour of the same
  service
• scattered over a global description
• These properties can be (in)validated
  algorithmically.

31
Results on EPP

• Theorem.
• If a well-typed global interaction I enjoys
  the three principles then EPP(I) is well defined
  and
• Types are preserved
• The projection can simulate the global
  description
• No unwanted behaviour in the projection

32
Final Remarks

• We first write down a global description and ...
• Produce a prototype code (only communication
  behaviour).
• Produce a full application.
• Produce a run-time monitor.
• Do a conformance checking (can we really use
  that web service for this protocol?)
• Do a conformance checking for team programming
  (is my
• code conformant to a global specification?).

33
Current Status

• The current implementation of EPP in the pi4soa
  tool is independently designed by Gary Brown, and
  closely follows the presented framework.
• The implementation of a formally-based EPP is
  currently underway for the pi4soa code base.
• A W3C working note presenting an EPP theory is
  already available at
• www.dcs.qmul.ac.uk/carbonem/cdlpaper/

34
Thank you
35
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.

36
Connectedness
Good... i. A ? B b( s). ii. A ? B s
(go). iii. B ? C c( t). . . .
Bad... . A ? B b( s). . A ? B s
(go). . C ? D t (hello). . . .

• is disconnected from .
• we must synchronise either A or B with either C
  or D
• connectedness in A ? Blt...gt. C ? Dltgt we have
• A, B n C, D ? Ø