Automatic Verification of Communicating Data-Aware Web Services

1. Automatic Verification of Communicating Data-Aware Web Services Victor Vianu U.C. San Diego and INRIA-Futurs Joint work with Alin Deutsch, Liying Sui, Dayou Zhou

2. Web service: service hosted on the Web • Interactive, often data-driven: accesses an underlying database and interacts with users/programs according to explicit or implicit workflow • Complex services: Web service compositions peers communicating asynchronously • Complexity of workflow leads to bugs: see the public database of Web site bugs (Orbitz bug) • Static analysis required -behavior of individual peers -protocols of communication between peers -global properties

3. This talk:Automatic, sound and complete verification of data-aware Web service compositions • Abstraction of web service compositions: communicating data-aware reactive systems • Verification of single peers and compositions • Experimental results for single peer verification WAVE verifier

4. Our target: data-aware Web services

5. Home page(HP) Home page(HP) Name passwd Name passwd login login cancel cancel Customer page(CP) Customer page(CP) Error message page(MP) Error message page(MP) Desktop Myorder laptop Desktop Myorder laptop back back Desktop Search(SP) Desktop Search(SP) laptop Search(SP) laptop Search(SP) Desktop search Ram: Hdd: Desktop search Ram: Hdd: Desktop search Ram: Hdd: Display: Desktop search Ram: Hdd: Display: Past Order (POP) Past Order (POP) Past Order Past Order search search search search Product index page(PIP) Product index page(PIP) Order status(OSP) Order status(OSP) Order status Order status Matching products Matching products Cancel confirmation page(CCP) Cancel confirmation page(CCP) Product detail page(PP) Product detail page(PP) Product detail Product detail buy buy Confirmation page(CoP) Confirmation page(CoP) Order detail Order detail database input update state query output

6. Input Triggers state update and transition to new page Input Input Input

7. state update DB output Home Page(HP) Message Page (MP) NAME: PASSWD: High-level WebML-style specification tools cancel login Message back Customer Page(CP) laptop desktop Laptop Search (LSP) Desktop Search (DSP) RAM: CPU: SCREEN: RAM: CPU: submit submit Matching products Confirmation Details buy print Product Detail (PDP) Confirmation (CoP) Product Index (PIP)

8. Home Page(HP) Product Info Page (PIP) Input: pick(pid,price) Input options: pick(pid,price) ram cpu prev-search(ram,cpu) catalog(pid,ram,cpu,price) Message Page (MP) NAME: PASSWD: cancel login Message back Customer Page(CP) laptop desktop Laptop Search (LSP) Desktop Search (DSP) db table RAM: CPU: SCREEN: RAM: CPU: previous input submit submit Matching products Confirmation Details buy print Product Detail (PDP) Confirmation (CoP) Product Index (PIP)

9. state update Web application code Home Page(HP) Message Page (MP) NAME: PASSWD: High-level WebML-style specification cancel login Message back Customer Page(CP) laptop desktop Laptop Search (LSP) Desktop Search (DSP) RAM: CPU: SCREEN: RAM: CPU: submit submit Matching products Confirmation Details buy print Product Detail (PDP) Confirmation (CoP) Product Index (PIP)

10. Examples of Desirable Properties • Semantic properties • “no product is delivered before payment in the right amount is received" • “no user can cancel an order that has already been shipped” • Basic soundness of specification • “conditions guarding transition to next Web page are mutually exclusive” • Navigational properties • “the shopping cart page is reachable from any page”

11. User payment(UPP) Payment CC No: Expire date Credit Verification M submit Compositions of Web services Buyer Login page(BP) Name passwd login cancel Category choice page(CP) Desktop Myorderlaptop Desktop Search(SP) laptop Search(SP) Desktop search Ram: Hdd: Desktop search Ram: Hdd: Display: Past Order (POP) Past Order search search Product index page(PIP) Order status(OSP) Order status Matching products Cancel confirmation page(CCP) Product detail page(PP) Product detail buy Confirmation page(CoP) Order detail

12. Examples of Composition Properties • “every payment request by a user results eventually in an approval or denial output to the user” • “the answer to every credit check request message for a user is a credit rating message poor, fair, or good, for the same user” • “for every two consecutive credit rating messages for the same user user there exists an intermediate credit request message for that user.”

13. Typical previous models: finite abstractions of Web services • Individual peer: finite-state Mealy machine order bill !b ?p !d ?o payment delivery

14. !o1 ?b1 ?k !a !k ?a !o2 ?r2 ?o2 ?o1 !b1 !b2 Web services compositions: communicating Mealy machines store bank . . . . . . supplier2 supplier1 . . . . . .

15. !o1 ?b1 ?k !a !k ?a !o2 ?r2 ?o2 ?o1 !b1 !b2 Executing a Mealy Composition (cont.) store bank a . . . . . . • STORE produces letter a and sends to BANK supplier2 supplier1 . . . . . .

16. !o1 ?b1 ?k !a !k ?a !o2 ?r2 ?o2 ?o1 !b1 !b2 Executing a Mealy Composition (cont.) store bank . . . . . . • Bank reads aand changes state supplier2 supplier1 . . . . . .

17. !o1 ?b1 ?k !a !k ?a !o2 ?r2 ?o2 ?o1 !b1 !b2 store bank b2 b1 . . . r2 . . . • Runs: finite or infinite supplier2 supplier1 . . . . . . o2 r2 o2 o1

18. Typical Web service verification problem temporal property of conversations: sequence of exchanged messages authorize store bank ok payment1 payment2 order2 receipt1 bill2 order1 bill1 receipt2 supplier1 supplier2 “conversation” p1 o2 a o1 b1 k r1 r2 b2 p2 LTL properties:Every authorize followed by some bill?

19. Linear time temporal logic (LTL) • Temporal operators • Xp: p holds in the next time • p U q: p holds until q holds • Fp: p holds eventually ; Gp: p always holds • p B q: if q ever holds then p holds before q * next time Current time p Some time later p p p q

20. Important parameters • bounded vs. unbounded queues • lossy vs. perfect channels • open vs. closed systems

21. Examples of results on Temporal Verification • Long history, see [Clarke et.al. ’00] • One fsa and propositional LTLon seq. of states • PSPACE in size of formula + fsa • Mealy compositions • Bounded queues • Composition can be simulated as Mealy machine • Verification is decidable • Unbounded queues • In general, undecidable [Brand & Zafiropulo 83]

22. Our abstraction: communicating data-aware reactive systems Control: (input, state, db)  (output, state) input Single peer control: FO state db output

23. History • Relational Transducers Abiteboul+Vianu 1998 • Abstract State Machine Transducers MarcSpielmann 2000 • Here: extension + communication

24. input Control: (input, state, db)  (output, state) Single peer control: FO state db output

25. FO query Single peer state db

26. user choice FO query Input options Single peer state db

27. user choice FO queries output Input options Single peer state db Technical point: queries can also refer to k previous inputs

28. input Configurations and runs state db Configuration output Run: infinite sequence of consecutive configurations

29. Communicating peers: composition • channels between peers • message: finite relation (set or singleton) • one FIFO queue at recipient of each channel

30. More on messages • Flat message: single tuple • Nested message: finite set of tuples • Messages queued at recipient • Message contents: !M(x) :- query(db, state, input, in-messages) Flat messages: query may generate several tuples, choose non-deterministically one to be sent

31. Peers with messages Control: (input, in-messages, state, db)  (output, out-messages, state) incoming messages input Single peer FO control state db outgoing messages output

32. input Configurations and runs incoming message queues Configuration of a single peer state db output

33. Configuration of a composition: member peer configurations Transitions: one peer at a time

34. Configuration of a composition: member peer configurations Transitions: one peer at a time

35. Configuration of a composition: member peer configurations Run: infinite sequence of consecutive configurations Transitions: one peer at a time

36. Language for properties of runs: LTL-FO • Start with FO formulas referring to the states, db, inputs, top and last message of queues in current configuration FO components • Apply Boolean and LTL operators: X, U, F, G, B • All remaining free variables are universally quantified FO + LTL operators + Boolean operators x (x)

37. Example Property “any shipped product must be previously paid for” pid, uname,price [(pid, uname, price) B Ship(uname, pid)] output Where (pid, uname, price) is the formula pay(price)picked(uname, pid, price)  prod-price(pid, price) input state database

38. The Verification Problem Given composition C and LTL-FO property  Decide if every run of Csatisfies . If not, exhibit a counterexample run. Challenge: infinite-state system!

39. Typical approaches in Software Verification are unsatisfactory: • Model checking: developed for finite-state systems described by propositional states. More expressive specifications first abstracted to propositional ones. Unsatisfactory: can check that some payment occurred before some shipment, but not that it involved the correct amount and product. • Theorem proving: no completeness guarantees, not autonomous. Prover requires expert guidance . • Our approach: identify a restricted but reasonably • expressive class of compositions that can be verified

40. Main restrictions for decidability guarded quantification: quantified variables must appear in input or (flat) message atoms “input boundedness” earlier variant: Spielmann bounded queues, guarded quantification pick(pid,price) ram cpu prev-search(ram,cpu)  catalog(pid,ram,cpu,price)

41. Input-bounded compositions • State, output, and nested message rules use FO formulas with guarded quantification: x ( guard(- x- )  φ( x )) x ( guard(- x- ) φ( x )) where guard is an input or flat message atom and state and nested message atoms in φ have no quantified variables • Input options and flat message definitions: *FO formulas with ground state and nested message atoms

42. Input-bounded LTL-FO property:FO components are input bounded “An order is rejected in the next step only if it has already been ordered but not paid correctly in the current input” x G [ X reject-order(x) (past-order(x)  y(pay(x,y)  price(x,y)))]

43. Main verification result Theorem: It is decidable whether an input-bounded composition with bounded queues and lossy channels satisfies an input-bounded LTL-FO property. Complexity: PSPACE-complete for bounded arity schemas, EXPTIME otherwise

44. Tightness: evensmall extensions lead to undecidability • Relaxing the requirement that state atoms must be ground in formula defining the input options. Reduction: Does TM halt on input epsilon? • Lifting the input-bounded requirement by allowing state projection. Reduction: Implication for functional and inclusion dep • Allowing perfect flat queues. Reduction: Post Correspondence Problem • Disallowing non-deterministic choice for flat messages Reduction: Post Correspondence Problem

45. Expressivity of input-bounded specs Significant parts of the following Web applications could be modeled: • Dell-like computer shopping website • Expedia • Barnes&Noble • GrandPrix motor sports Web site See demo site http://www.db.ucsd.edu

46. PSPACE verification: outline for single peer To check that C satisfies , verify that there is no run satisfying   Recall model checking approach (finite-state): • Build Büchi automaton A( ) for   • Build automaton R accepting all runs • Check that there is no counterexample run: emptiness of R A( )

47. Our case: infinite-state system Same idea: build A( ),then search for counterexample runs accepted by A( ) But: no automaton R for the runs! Problem in searching for counterexample runs: infinite runs infinitely many underlying databases How to limit the search space?

48. Infinite search space for runs number of underlying DBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . length of run

49. Sufficient to consider only DBs over a fixed domain of cardinality exponential in size of spec + prop double-exponentially many DBs • Periodic runs suffice: • counterexample iff • periodic one doubly-exponential length in size of spec+prop Bounding the search for counterexample runs number of underlying DBs . . . . . . . . . Finite search space yields decidability of verification . . . . . . . . . . . . . . . . . . length of run

50. Key insight for PSPACE complexity • No need to explicitly materialize entire configuration: • Instead, at each step construct only those portions of DB, states and outputs which can affect property. • Call them pseudoconfigurations.