1 / 99

Automatic Verification of Data-Centric Web Services

Automatic Verification of Data-Centric Web Services. Victor Vianu U.C. San Diego. Web service : service hosted on the Web Should be accessible by humans or programs: need for standard interface

makan
Télécharger la présentation

Automatic Verification of Data-Centric 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. Automatic Verification of Data-Centric Web Services Victor Vianu U.C. San Diego

  2. Web service: service hosted on the Web • Should be accessible by humans or programs: need for standard interface • Should be possible to discover automatically: need for uniform description of functionality • Should be possible to create complex services using simpler ones: Web service composition and synthesis

  3. This talk:automatic verification of Web services • Finite-state abstractions • Beyond finite-state: workflow+data The WAVE verifier

  4. Specifying Web services • Black box: input/output signature order bill Supplier payment delivery

  5. Specifying Web services • White box: internal logic order bill !b ?p !d ?o payment delivery Simplest: finite state Mealy machines

  6. Specifying Web services • White box: internal logic !b order bill !d ?p ?o !d !d !b ?p payment delivery Simplest: finite state Mealy machines

  7. authorize bank store • P : finite set of Web services (peers) ok payment1 receipt2 • C : finite set of peer-to-peer channels bill1 order2 bill2 payment2 receipt1 order1 • M : (finite) set ofmessage classes supplier2 supplier1 • Interacting Web services

  8. !o1 ?b1 ?k !a !k ?a !o2 ?r2 ?o2 ?o1 !b1 !b2 Combining Peer and Composition Models store bank . . . . . . • Peer fsa’s begin in their start states supplier2 supplier1 . . . . . .

  9. !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 . . . . . .

  10. !o1 ?b1 ?k !a !k ?a !o2 ?r2 ?o2 ?o1 !b1 !b2 Executing a Mealy Composition (cont.) store bank . . . . . . • BANK consumes letter a supplier2 supplier1 . . . . . .

  11. !o1 ?b1 ?k !a !k ?a !o2 ?r2 ?o2 ?o1 !b1 !b2 store bank b2 b1 . . . r2 . . . • Important parameters: --bounded or unbounded queues --open or closed system • Execution successful if all queues are empty and fsa’s in final state supplier2 supplier1 . . . . . . o2 r2 o2 o1

  12. !o1 ?b1 ?k !a !k ?a “shipment just made” “shipment just made” !o2 “line-of-credit available” ?r2 ?o2 ?o1 !b1 !b2 Verifying Temporal Properties of Mealy Compositions store bank . . . • Label states with propositions • Express temporal formulas in LTL, e.g., • “shipment just made” only after “line-of-credit avail” . . . warehouse2 warehouse1 !b2 . . . ?r2 . . .

  13. Linear time temporal logic (LTL) • Temporal operators • Xp: p holds in the next time • pUq: p holds until q holds • Fp: p holds eventually ; Gp: p always holds • pBq: either q always holds or p holds before q fails next time Current time p Some time later p p p q

  14. Results on Temporal Verification • Long history, see [Clarke et.al. ’00] • E.g.: one fsa and propositional LTL • PSPACE in size of formula + fsa • linear time in size of fsa • Mealy compositions • Bounded queues • Composition can be simulated as Mealy machine • Verification is decidable • Standard techniques to reduce cost • Unbounded queues • In general, undecidable [Brand & Zafiropulo 83]

  15. Alternative: temporal property of sequence of exchanged messages authorize store bank ok payment1 payment2 order2 receipt1 bill2 order1 bill1 receipt2 ware-house1 ware-house2 “conversation” p1 o2 a o1 b1 k r1 r2 b2 p2 LTL properties:Every authorize followed by some bill?

  16. Conversation languages • Conversation: sequence of exchanged messages • Conversation language: set of all conversations between Mealy peers • Bounded queues: regular language

  17. Unbounded queues ?a a !a ?b b !b p1 p2 • Conversation language L is not regular: L a*b* = { anbn| n  0 } • Conversation languages are context sensitive in fact, they are quasi-realtime languages [Bulltan+Fu+Hull+Su 03]

  18. Synthesis of compositions • Given a set of peers and communication channels with message names, and a constraint Φon the conversation language, find Mealy automata for peers so that the constraint is satisfied.

  19. Bounded queues • Closed systems: PSPACE for LTL PTIME for ω-regular sets given by an automaton • Open systems: “game” against environment synthesis = finding winning strategy undecidable for arbitrary topology hierarchical topology: decidable [Kupferman + Vardi 01] but non-elementary even in linear case [Pnueli+Rosner] [

  20. Unbounded queues • Open systems: undecidable • Closed systems: open

  21. Synthesizing hierarchical compositionfrom “library” of services Customized Travel Service Travel Service Templates Air Travel Templates Airport Transfer Hotel Reservation

  22. Beyond fsa: workflow+data

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

  24. Motivation • Interactive, data-driven Web applications: powered by an underlying database and interacting with external users according to explicit or implicit workflow • Complexity of workflow leads to bugs: see the public database of Web site bugs (Orbitz bug) • Static analysis required to increase confidence in correctness and robustness of applications • Problem: Data-driven Web applications are infinite-state systems !

  25. The WAVE Verifier • WAVE = Web Application VErifier • Practical, sound and complete automatic verification for data-driven applications • Novel coupling of model checking and database optimization techniques.

  26. state update DB action Home Page(HP) Message Page (MP) NAME: PASSWD: High-level WebML-style workflow 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)

  27. Modeling Web Applications A Web application is described by • the set of • database relations D (fixed during a session) • state relations S (updateable) • input relations I (hold user’s input choice) • action relations A • and a set of web page schemas (templates) • their contents are determined at run-time, as function of D,S,I

  28. Webpage Schema • Input options (user may pick at most one of them) • Query(DB, State, Previous input) • Actions and Transitions (triggered by user input) • Actions: Query(DB, State, Input, Prev. input) • Next Webpage: Query(DB, State, Input, Prev. Input ) • State updates (triggered by user input) • insertions/deletions : Query(DB, State, Input, Prev. Input) “Query”: First Order Logic formula (core SQL)

  29. Details on Modeling the Input • input options as provided bymenus, pull-down lists, buttons, HTTP links: user must choose one • input constants model text input boxes: name, password, etc. • input I at previous step: prev-I can be viewed as special state

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

  31. Home Page(HP) Message Page (MP) NAME: PASSWD: cancel login Message back Customer Page(CP) input constant input constant laptop desktop Home page(HP) Input: name, password , clickbutton(x) Input options: clickbutton(x) (x= “login” or x = “cancel”) State update: error("bad user") notusers(name,password) and clickbutton("login") Page Transition rules: CP users(name,password) andclickbutton(“login”) MP  notusers(name, password) andclickbutton("login") Laptop Search (LSP) Desktop Search (DSP) RAM: CPU: SCREEN: RAM: CPU: submit submit state table DB table Matching products Confirmation Details buy print Product Detail (PDP) Confirmation (CoP) next page Product Index (PIP)

  32. 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 previous input RAM: CPU: SCREEN: RAM: CPU: submit submit Matching products Confirmation Details buy print Product Detail (PDP) Confirmation (CoP) Product Index (PIP)

  33. Verifying Web Applications We want to verify properties of the possible interactions between users and web app. • need to describe interactions: A run of Web application W is the sequence of configurations through which W evolves input actions Configuration: page state DB

  34. 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”

  35. Expressing properties in LTL-FO LTL-FO: First-Order logic + linear temporal logic operators • Xp: p holds in the next time step • pUq: p holds until q holds • Fp: p will finally hold • Gp: p generally holds (in all steps) • pBq: p must hold before q holds More expressive than classical (propositional) LTL

  36. Example Property Any shipped product must be previously paid for pid, uname,price [(pid, uname, price) B Ship(uname, pid)] action Where (pid, uname, price) is the formula input input PPpay(price)button(“authorize payment”) pick(pid, price)prod-price(pid, price) page name state database

  37. The Verification Problem Given Web application W and LTL-FO property P Decide if every run of W satisfies P. If not, exhibit a counterexample run.

  38. Challenge: infinite-state reactive system Control: (input, state, db)  (action, state) input relational transducer control state db action

  39. Verification of Infinite-State Systems • 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: not autonomous. Prover gets stuck during search and asks for guidance from expert user.

  40. Verification results for LTL-FO [PODS’04] • The verification problem is undecidable • Restriction for decidability: input boundedness • Essentially, input-guarded quantification, i.e. quantified variables must appear in input atoms pick(pid,price) ram cpuprev-search(ram,cpu) catalog(pid,ram,cpu,price)

  41. Input-bounded specs • State, action, and transition rules use FO conditions with “input-bounded” quantification: x ( input( x )  φ( x )) x ( input( x ) φ( x )) state atoms have no quantified variables prev-I can also serve as guard • Input options definitions: *FO (db, prev-input, ground state 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. Verification results: If W and P are input-bounded, checking whether W satisfies P is PSPACE-complete Even modest relaxations of input boundedness restriction lead to undecidability.

  44. Extensions leading 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 FDs and IDs • Allowing Prev-I to record all previous input to I rather than the most recent one. Reduction: Trakhtenbrot’s Theorem • Extend the FO-LTL formulas with path quantification. Reduction: validity of **FO formulas

  45. Expressivity of Input-bounded Specs. See demo site http://www.db.ucsd.edu for modeling of significant parts of the following Web applications: • Dell-like computer shopping website • Expedia • Barnes&Noble • GrandPrix motor sport Web site

  46. How to verify To check that W satisfies P,verify that there is no run satisfying P. Model checking approach (finite-state): • Build Buchi automaton A(P) for P • Build automaton S accepting all runs • Check that there is no counterexample run: emptiness of S X A(P)

  47. Our case: infinite-state system Verification: build A(P),thensearch for counterexample runs accepted by A(P) But: no automaton S for the runs! Challenge in searching for counterexample runs: infinite runs infinitely many underlying databases How to limit the search space?

  48. Challenge: 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

More Related