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

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

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

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

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)

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” What is CDL? (2)

What is CDL? (3) 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); … What about writing something like: Bob → Alice. Dave → Alice or (xml-style)

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

WS-CDL - An example

WS-CDL - Structure

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

WS-CDL - Tools Open Source Eclipse pluginswww.pi4soa.org –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

WS-CDL - Tools Graphical Grammar

WS-CDL - Tools Graphical Grammar

WS-CDL - Tools Graphical Grammar

WS-CDL - Tools Graphical Grammar

WS-CDL - Tools Code Generation and Deployment

WS-CDL - Tools Behavioral Monitor

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?

Formalising WS-CDL The Global Calculus and a Theory of End-Point Projection

Syntax of the Global Calculus I ::= A → B : ch(s 1,…, s k ). I (init) | A → B : s(op, e, y). I (comm) | := e. I (assign) | if then I 1 else I 2 (cond) | I 1 | I 2 (par) | I 1 + I 2 (sum) | (υs) I (new) | X (recvar) | μX. I (rec) | 0(inaction)

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) → → V], I ) (σ, ::= V. I) → → V], I )

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 }

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

Buyer-Seller Examples (3) Buyer → Seller : ch1( s, t). Buyer → Seller : s ( QuoteReq, product, x ). Seller → Buyer : t ( QuoteRes, quote, y ). if then Buyer → Seller : s ( QuoteAcc, creditcard, z ). Seller → Shipper : ch2( r ). · · · (as before) · · · else Buyer → Seller : s ( QuoteNoGood ). 0

Buyer-Seller Examples (4) Buyer → Seller : ch1( s, t). Buyer → Seller : s ( QuoteReq, product, x ). μX. Seller → Buyer : t ( QuoteRes, quote, y ). if then Buyer → Seller : s ( QuoteAcc, creditcard, z ). Seller → Shipper : ch2( r ). · · · (as before) · · · else Buyer → Seller : s ( QuoteNoGood ). X

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

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

How does EPP work? 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. … 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)…

Three Principles for EPP 1.Connectedness: a causality principle 2.Well-threadedness: a local causality principle 3.Coherence: consistent behaviour of the same service scattered over a global description These properties can be (in)validated algorithmically.

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

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

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:

Thank you

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.

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} ≠ Ø