1. Conformance Checking for Web Services Jakob Rehof University of Dortmund Fraunhofer-ISST Dortmund Joint work with Tony Andrews (MS) Shaz Qadeer (MSR) Sriram K. Rajamani (MSR)

2. Outline • Background • The Contract Checker Project • Conformance Theory • Conclusion

3. m1 m2 m3 3-tier Systems Data source Domain/ application layer Presentation DB Business Logic GUI

4. 3-tier Systems Clients Web Service request Data source App layer Pre- sen- tation response WSDL, Web Methods, RMI, RPC

5. Distributed Workflows XML Data source App layer Data source App layer SOAP TCP/ IP Challenge: Composition of distributed, heterogeneous (legacy) Components • WS • Standards • Contracts • Security • Transactions Data source App layer Data source App layer

6. Loose Coupling Data source App layer Data source App layer • Across independent • organizations • Hard component boundaries. Data source App layer Data source App layer

7. Non-ACID Transactions Data source App layer Data source App layer Long-running, stateful ´transactions => not ACID => asynchronous Communication Data source App layer Data source App layer

8. Supplier 1 Supplier 2 Supplier 3 Buyer Agent

9. Application Protocols Data source App layer Data source App layer • Loose coupling => • new motivation for specifications Data source App layer Data source App layer

11. Challenges: • Composition of heterogeneous Components • Hard component boundaries • Development and exposition of components based on standards and interface specifications • Long-running transactions: not ACID • Asynchrony • State • Application protocols

12. Two paradigms • Traditional technology with libraries (.NET, J2EE) • Methods (OO) • RMI, RPC, callbacks, events,… • Explicit management of communikation state • “Shared-memory” synchronization • “Orchestration” • Message-passing • Asynchronous “send”, synchronization primitives (Receive, Join) • Communication state expressible in programming language • Extreme form: no shared memory

13. Asynchrone Form SampSyncSqrDelegate sampleDelegate = new SampSyncSqrDelegate(sampSyncObj.Square); callParameter = 17; IAsyncResult aResult = sampleDelegate.BeginInvoke(callParameter, null, null); //Wait for the call to complete aResult.AsyncWaitHandle.WaitOne(); callResult = sampleDelegate.EndInvoke(aResult);

14. Asynchrone Form // define the delegate for the long operation delegate int LongOperationDelegate(int time, ref int refParam); private void button1_Click(object sender, System.EventArgs e) { // create an instance of the delegate LongOperationDelegate dlgt = new LongOperationDelegate(LongOperation); int refParam = 0; int state = 999; // call BeginInvoke to initiate the asynchronous operation // When the operation is complete, the DoneCallback method // will be called. The state parameter is passed in the // IAsyncResult.AsyncState property. IAsyncResult ar = dlgt.BeginInvoke(5000, ref refParam, new AsyncCallback(DoneCallback), state); }

15. Asynchrone Form // Callback method is called when the asynchronous operation is complete. private void DoneCallback(IAsyncResult iar) { if (this.InvokeRequired) { // if operating on a different thread, then invoke a // delegate on the UI thread so we can update controls. IAsyncResult arx = this.BeginInvoke( new AsyncCallback(DoneCallback), new object[] {iar}); this.EndInvoke(arx); return; } AsyncResult ar = (AsyncResult)iar; // get the delegate used to // initiate the asynchronous operation LongOperationDelegate dlgt = (LongOperationDelegate)ar.AsyncDelegate; int refParam = 0; // harvest the result int longResult = dlgt.EndInvoke(ref refParam, ar); ... } private int LongOperation(int time, ref int refParam){ … }

16. Asynchrone Form • Komplizierte Programmstruktur • CPS style, schwierig zu verstehen • Erklärungen sind im Programmtext verteilt • Viele Objekte sind involviert • Callback, delegate, state parameter, multi-threading, IAsyncResult, BeginInvoke/EndInvoke • Undurchsigtig, fehleranfällig, • Schwierig wiederzubenutzen • … obwohl konzeptuell einfach

17. Existing technology • RMI/RPC • Synchronous • Does not scale for long-running transactions • Asynchronous forms of RMI/RPC • Derived from synchronous technology • Natural only for request/response • Stateful communications become complicated (CPS) • Not sufficient as programming model for scalable asynchronous architectures

18. Orchestration DSL for communication middleware DSL for global business processes

19. Web Service Orchestration Languages • BPEL4WS • Web Service Execution Language for WS • BEA, IBM, Microsoft • WSCI • Web Services Choreography Interface • Sun, SAP, BEA, Intalio • WSCL • Web Services Conversation Language • HP

20. BPEL4WS, 1.1. May 2003.

21. Distribution

22. Orc Orc Orc Orc Distribution

23. Indigo • A programming model for Indigo ...

24. Outline • Background • The Contract Checker Project • Conformance Theory • Conclusion

25. Application Protocols Data source App layer Data source App layer • Loose coupling => • new motivation for specifications Data source App layer Data source App layer

26. Behavioral contracts • Describe public behavior of service • Enable service composition, programming by contract • Temporal specification of service interface • Not just data formats (WSDL), but also legal sequences of messages accepted by service component

27. Goal • Integrated development tool to state and check contracts at source • Contracts as behavioral types: • Communication protocols as source-level specs • Type-safety for concurrent interaction • Check behavioral contracts statically against implementations • Does service correctly implement its contract? • Does service obey contracts of other services? • Do it compositionally • Check only one service at a time • Rely on contracts to represent other services

28. Integrated contract checker “protocol” errors type errors Visual Studio .NET Language Service ? .NET compiler

29. Temporal notion of “type-safety”: Stuck-Freedom • No deadlocks • No un-received messages • Behavioral “type-safety” • Communication proceeds from beginning to end with consistent expectations on what to do next • Only internal non-termination can prevent progress

30. Stuck-Free Conformance • Refinement relation (P ≤ Q) defined on CCS processes • Preserved by all contexts: • P ≤ Qimplies C[P] ≤C[Q] for all contexts C • Preserves ability to get stuck: • P ≤ Q=> (P can get stuck => Q can get stuck) • Consequence: Substitutability • P ≤ Q=> (C[Q] stuck-free => C[P]stuck-free)

31. Stuck-Free Conformance • Inspired by CSP stable failures refinement (Brookes-Hoare-Roscoe) but more discriminating • Can be applied directly to any labeled transition system in which visible actions as well as stability can be observed • Naturally captures deadlock in CCS • Refusal Testing (CCS), ≤, Stable Failures (CSP) • [Fournet,Hoare,Rajamani,Rehof CAV 2004] • [MSR-TR-2004-69]

32. Stuck-Free Conformance • Implemented in ZING refinement checker, on top of ZOM. • Used in conformance checking for message-passing applications

33. Integrated contract checker “protocol” errors type errors Visual Studio .NET Language Service Zing Conformance checker .NET compiler Src Zing model generator state-space exploration Zing compiler Zing models (spec & impl)

34. Contract checking S1 C1 b1 . . . S C a bn Sn Cn

35. Contract checking Stuck-free? Conforms? S1 C1 . . . S C Sn Cn Stuck-free?

36. Contract checking Imported contracts S1 C1 b1 System = (new b1 … bn) S1(b1) | … | Sn(bn) | S(a,b1,…,bn) . . . S C a bn Sn Cn Exported contract

37. Contract checking Reaction semantics C1 Model = (new b1 … bn) C1(b1) | … | Cn(bn) | M(S)(a,b1,…,bn) b1 . . . S C a bn Cn Commitment semantics

38. COMPONENT ShoppingCart: ShoppingCartContract { Channel Reserver: InventoryResrvation; Reserver = new Reserver(); while (true){ Receive{ Case AddItem(…) { ... } Case RemoveItem(…) { ... } Case Cancel(…){ Send Reserver [CancelReservation(…)]; Receive Reserver [Acknowledgement(…)]; Send [Rejected(…)]; Case CheckOut(…) if (...) Send [AcknowledgeOrder(...)]; else Send [Rejected(...)]; exit; } // Receive } }

39. Contracts Start Checking out Rejected AddItem Checkout AcknowledgeOrder Items End Cancel AddItem Rejected RemoveItem

40. Case Study: Contracts Contract ShoppingCart = AddItem?. ShoppingCart + RemoveItem?. ShoppingCart + CheckOut?. (AcknowledgeOrder! # Rejected!) + Cancel?. Rejected! Contract InventoryReservation = ReserveInventory?. InventoryReservation + UnreserveInventory?. InventoryReservation + CommitReservation?. Acknowledgement! + CancelReservation?. Acknowledgement!

41. Contract A Contract B Contract B Contract C Contract C ContractA B A A C Contract Checking   Conformance

42. Contract A Contract Checking  Contract B Contract C A Defects Pass

43. Service implementation Select Receive Case Receive AddItem(…) Case Receive RemoveItem(…) Case Receive Cancel(…) … Send Rejected(…) Case Receive CheckOut(…) … … Send AcknowledgeOrder(…) … … Send Rejected(…) … End Select Contract Start: AddItem --> Items Items: AddItemOrRemoveItem --> Items Checkout --> CheckingOut CancelThenRejected --> End CheckingOut: AcknowledgeOrder --> End Rejected --> End 

44. ZING model select visible{ event(AddItem, 0); event(RemoveItem, 0); event(Cancel, 0) --> … event(Rejected, 1); event(CheckOut, 0) --> … if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … … } ZING model Start: event(AddItem, 0); goto Items; Items: select visible{ event(AddItem, 0)--> …; event(RemoveItem, 0) --> … event(Checkout, 0) --> … event(Cancel, 0) --> event(Rejected, 1); … } CheckingOut: if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … 

45. AddItem select visible{ event(AddItem, 0); event(RemoveItem, 0); event(Cancel, 0) --> … event(Rejected, 1); event(CheckOut, 0) --> … if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … … } Start: event(AddItem, 0); goto Items; Items: select visible{ event(AddItem, 0)--> …; event(RemoveItem, 0) --> … event(Checkout, 0) --> … event(Cancel, 0) --> event(Rejected, 1); … } CheckingOut: if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … 

46. AddItem AddItem select visible{ event(AddItem, 0); event(RemoveItem, 0); event(Cancel, 0) --> … event(Rejected, 1); event(CheckOut, 0) --> … if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … … } Start: event(AddItem, 0); goto Items; Items: select visible{ event(AddItem, 0)--> …; event(RemoveItem, 0) --> … event(Checkout, 0) --> … event(Cancel, 0) --> event(Rejected, 1); … } CheckingOut: if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … 

47. select visible{ event(AddItem, 0); event(RemoveItem, 0); event(Cancel, 0) --> … event(Rejected, 1); event(CheckOut, 0) --> … if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … … } Start: event(AddItem, 0); goto Items; Items: select visible{ event(AddItem, 0)--> …; event(RemoveItem, 0) --> … event(Checkout, 0) --> … event(Cancel, 0) --> event(Rejected, 1); … } CheckingOut: if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … 

48. CheckOut select visible{ event(AddItem, 0); event(RemoveItem, 0); event(Cancel, 0) --> … event(Rejected, 1); event(CheckOut, 0) --> … if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … … } Start: event(AddItem, 0); goto Items; Items: select visible{ event(AddItem, 0)--> …; event(RemoveItem, 0) --> … event(Checkout, 0) --> … event(Cancel, 0) --> event(Rejected, 1); … } CheckingOut: if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … 

49. CheckOut CheckOut select visible{ event(AddItem, 0); event(RemoveItem, 0); event(Cancel, 0) --> … event(Rejected, 1); event(CheckOut, 0) --> … if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … … } Start: event(AddItem, 0); goto Items; Items: select visible{ event(AddItem, 0)--> …; event(RemoveItem, 0) --> … event(Checkout, 0) --> … event(Cancel, 0) --> event(Rejected, 1); … } CheckingOut: if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … 

50. select visible{ event(AddItem, 0); event(RemoveItem, 0); event(Cancel, 0) --> … event(Rejected, 1); event(CheckOut, 0) --> … if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … … } Start: event(AddItem, 0); goto Items; Items: select visible{ event(AddItem, 0)--> …; event(RemoveItem, 0) --> … event(Checkout, 0) --> … event(Cancel, 0) --> event(Rejected, 1); … } CheckingOut: if (*) event(AcknowledgeOrder, 1); … else event(Rejected, 1); … 