1 / 86

Conformance Checking for Web Services

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). Outline. Background The Contract Checker Project Conformance Theory Conclusion. m1. m2. m3.

tuan
Download Presentation

Conformance Checking for Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

  12. 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);

  13. 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); }

  14. 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){ … }

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

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

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

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

  19. BPEL4WS, 1.1. May 2003.

  20. Distribution

  21. Orc Orc Orc Orc Distribution

  22. Indigo • A programming model for Indigo ...

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

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

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

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

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

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

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

  30. 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]

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

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

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

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

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

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

  37. 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 } }

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

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

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

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

  42. 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 

  43. 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); … 

  44. 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); … 

  45. 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); … 

  46. 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. 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); … 

  48. 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); … 

  49. 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); … 

More Related