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

1. 5th December 2006 Marco Carbone Imperial College London WS-CDL and a Theoretical Basis for Communication-Centred Programming

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. • π-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 <m, x>. Dave → Alice <n,y> or (xml-style) <sequence> <message from:”Bob” to:”Alice” val:”m” var:”x”> <message from:”Dave” to:”Alice” val:”n” var:”y”> </sequence> 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@A := e. I (assign) | if e@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: • (σ, I) → (σ’, I’) • where σ is an environment. It maps, for each participant A, local variables to their stored values. • Example rules: • (σ, A → B : s(op, V, x). I) → (σ[x@B → V], I ) • (σ, x@A ::= V. I) → (σ[x@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)@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)@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 α 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 → B<...>. C → D<…> we have • {A, B} ∩ {C, D} ≠ Ø