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

WS-CDL - An exampleWhat about writing

alternative options e.g. a QuoteReject?

…or spawning parallel behaviours?

…or recursive behaviours (e.g. while, repeat, etc.) ?

WS-CDL - An example<parallel> < workunit name="Check Credit Rating "> < sequence> < interaction name="Seller check credit with CreditChecker " operation ="creditCheck " channelVariable="Seller2CreditChkC ">Ź <description type="description"> Check the credit for this buyer with the credit check agency </description>Ź <participate relationshipType ="SellerCreditCheck " fromRole="SellerRoleType " toRole="CreditCheckerRoleType " /> < exchange name="checkCredit " informationType ="CreditCheckType " action="request"></ exchange>Ź </ interaction>

< choice> < sequence>Ź < interaction name="Credit Checker fails credit check " operation ="creditFailed " channelVariable="Seller2CreditChkC "> Ź <description type="description">Credit response from the credit checking agency </description>Ź <participate relationshipType ="SellerCreditCheck " fromRole="SellerRoleType " toRole="CreditCheckerRoleType " /> < exchange name="creditCheckFails " informationType ="CreditRejectType " action="respond"></ exchange>Ź </ interaction> < assign roleType ="SellerRoleType ">Ź <copy name="copy">Ź <source expression="false" />Ź <target variable="cdl:getVariable ('creditRatingOk' ,'','') " />Ź </copy>Ź </assign> </ sequence>Ź

< sequence>Ź < interaction name="Credit Checker passes credit " operation ="creditOk " channelVariable="Seller2CreditChkC "> Ź <description type="description">Credit response from the credit checking agency </description>Ź <participate relationshipType ="SellerCreditCheck " fromRole="BuyerRoleType " toRole="CreditCheckerRoleType " /> < exchange name="creditCheckPasses " informationType ="CreditAcceptType " action="respond"> </exchange>Ź </ interaction> < assign roleType ="SellerRoleType ">Ź <copy name="copy"> Ź <source expression="true" />Ź <target variable="cdl:getVariable ('creditRatingOk' ,'','') " />Ź </copy>Ź </assign> </ sequence>Ź </ choice> </ sequence>Ź </ workunit>

< workunit name="Request Delivery " guard ="creditRatingOk = true" blocking="true"> ……Ź </workunit></parallel>

WS-CDL - Structure

Participants, Roles, Relationships, Information, Channels

Choreography, Interaction

WorkUnits, Structured composition

Non Observable Conditionals

Observable Conditionals

State MgmtNo State Mgmt

Package Exce

ptio

ns, Fin

alize

rs

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

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 - ToolsBehavioral Monitor

Few more questions…

• How do we map WS-CDL to executable processes? Whatis the behaviour underlying CDL?

• How can we offer formal foundations for static and dynamicvalidation of WS-CDL? Can we precisely relate CDL totheories of processes?

• Are there good programming/type disciplines for CDL?What is structured programming for communication andconcurrency?

Formalising WS-CDL

The Global Calculus and a Theory of End-Point Projection

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)

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 )

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 reasonable(y)@Buyer 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 reasonable(y)@Buyer 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 servicescattered 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 RemarksWe 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 mycode 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:

www.dcs.qmul.ac.uk/˜carbonem/cdlpaper/

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.

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