UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Verification of Data-Intensive Web Services Grigoris Karvounarakis University of Pennsylvania presented at: CIS 650 December 17, 2004 CIS 650
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Data-Intensive Web Services n Web services supported by databases g. Large amount of data (e. g. , for product catalogs) g. Common database features (transactions, concurrency control) g. State transitions involve database operations (e. g. , queries) g. Control flow depends on data values (results of queries) n As services become more complex, it is important to be able to verify their correctness automatically. g. But verification models/techniques cannot handle programs that involve “external” data in their transitions CIS 650 2
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 The database approach n Instead of trying to extend program models to handle interaction with databases, use databases to encode program specifications! g. Express state transitions, input/output in a database (high-level, declarative) language g. E. g. , datalog-like rules g. Adding dynamic aspect to databases, reminiscent of active databases CIS 650 3
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Relevant papers n Several papers on this problem in database theory conferences in the last several years: g. Relational Transducers for Electronic Commerce: Abiteboul, Vianu, Fordham, Yesha, PODS’ 98 & JCSS’ 00 g. Verification of Relational Transducers for Electronic Commerce: Spielmann, PODS’ 00 & JCSS’ 03 g. Specification and Verification of Data-driven Web Services: Deutsch, Sui, Vianu, PODS’ 04 CIS 650 4
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Example n Online bookstore that allows users to order books, sends them a bill for their order, receives a payment and, if the amount is correct, ships the product CIS 650 5
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Outline n High-level Specification models g. Relational Transducers g. ASM Transducers g. Web Page Schemas n Automatic Verification g. Past input g. FO-LTL g. CTL/CTL* n Conclusions CIS 650 6
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Relational transducers n Transducers: automata with output g. Transition function g. Output function n Use datalog: rules to express transition and output functions g. RHS: Conjunction of (positive or negative) relational atoms g. State rules: inflationary, asserted atoms are accumulated g. Output rules: non-inflationary, at every step only newly inferred facts are retained CIS 650 7
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Example Schema Database: price(product, price) n Input: order(user, product), pay(user, product, price) n Output: sendbill(user, product, price), ship(user, product) n n State: past-order(user, product) Color code: input state action data CIS 650 8
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Example Specification n State rules: gpast-order(U, X) n Output rules: gsendbill(U, X, Y) n +: - order(U, X) Æ price(X, Y) Problem: orders cannot be removed from past-order g. We cannot go back to a previous state, i. e. , we cannot express loops g. The rule above would sendbill again and again for every future step CIS 650 9
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 A way to side-step the problem Database: price(product, price) n Input: order(user, product), pay(user, product, price) n Output: sendbill(user, product, price), ship(user, product) n n State: past-order(user, product), pastpay(user, product, price) CIS 650 10
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Example Specification n State rules: gpast-order(U, X) +: - order(U, X) gpast-pay(U, X, Y) +: - pay(U, X, Y) n Output rules: gsendbill(U, X, Y) : - order(U, X) Æ price(X, Y) Æ : past- pay(U, X, Y) gship(U, X) : - past-order(U, X) Æ price(X, Y) Æ pay(U, X, Y) Æ : past-pay(U, X, Y) CIS 650 11
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 But there are still problems n State rules: gpast-order(U, X) +: - order(U, X) gpast-pay(U, X, Y) +: - pay(U, X, Y) n Output rules: gsendbill(U, X, Y) : - order(U, X) Æ price(X, Y) Æ : past- pay(U, X, Y) gship(U, X) : - past-order(U, X) Æ price(X, Y) Æ pay(U, X, Y) Æ : past-pay(U, X, Y) CIS 650 12
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 But there are still problems n State rules: gpast-order(U, X) +: - order(U, X) gpast-pay(U, X, Y) +: - pay(U, X, Y) n Output rules: gsendbill(U, X, Y) : - order(U, X) Æ price(X, Y) Æ : past- pay(U, X, Y) gship(U, X) : - past-order(U, X) Æ price(X, Y) Æ pay(U, X, Y) Æ : past-pay(U, X, Y) After payment has been received and entered in past-pay, a user cannot buy the same item again (sendbill, ship cannot be fired!) CIS 650 13
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Solutions? n Make X in past-order(U, X)/past-pay(U, X, Y) unique for every different item of a product g. Then price(X, Y) would have to contain one tuple for every item in the store inventory! n Add unique order id: past-order(U, N, X)/past-pay(U, N, X, Y)) g. However, the fact that it is unique cannot be expressed in the model (and we would not be able to verify properties that depend on this fact) · e. g. , the property that “every time an order is submitted and that book is in stock, then eventually a bill will be sent to the customer” holds for this specification under this assumption, but not without it … CIS 650 14
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Solution: ASM transducers n Allow state rules to delete tuples from state relations gdatalog: : g. Arbitrary n FO on right-hand side of rules State rules: gpast-order(U, X) +: - order(U, X) g: past-order(U, X) +: - past-order(U, X) Æ pay(U, X, Y) Æ price(X, Y) n Output rules: gsendbill(U, X, Y) : - order(U, X) Æ price(X, Y) Æ : past-order(U, X, Y) gship(U, X) : - past-order(U, X) Æ price(X, Y) Æ pay(U, X, Y) CIS 650 15
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Solution: ASM transducers n Allow state rules to delete tuples from state relations gdatalog: : g. Arbitrary n FO on right-hand side of rules State rules: gpast-order(U, X) Remove order after payment is received and go back to state before the order was received +: - order(U, X) g: past-order(U, X) +: - past-order(U, X) Æ pay(U, X, Y) Æ price(X, Y) n Output rules: gsendbill(U, X, Y) : - order(U, X) Æ price(X, Y) Æ : past-order(U, X, Y) gship(U, X) : - past-order(U, X) Æ price(X, Y) Æ pay(U, X, Y) CIS 650 16
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Web Page Schemas n Observation: web services are usually g. Sequence of web pages g. User input is usually picked from lists of choices compiled by the system (based on information in the database). n Adjust ASM transducer model to handle this: g. One ASM transducer page g. Rules for page transitions g. Rules to pre-populate input options CIS 650 17
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Page transitions ORDER PAGE HOMEPAGE (W 0) Welcome to Bookstore. com button(“cancel”) Find books Book 1 Book 2 Book 3 order cancel order(X) Æ button(“order”) Æ : pastorder(U, X) PAYMENT PAGE Your bill is: $xx. xx Enter payment amount: button(“pay”) pay CIS 650 18
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 WP schema of example n Order Page g. Input: order(X), button(X) g. Input Rules: · Optionsorder(X) Ã price(X, Y) · Optionsbutton(X) Ã X=“order” Ç X=“cancel” g. State Rules (this example: one state relation error): · past_order(U, X) +: - order(X) Æ U = user Æ : past_order(U, X) g. Target WP: PP, HP g. Target Rules: · PP : - order(X) Æ button(“order”) Æ : past_order(U, X) · HP Ã button(“cancel”) g. Output rules: · sendbill(U, X, Y) : - order(U, X) Æ U = user Æ button(“order”) Æ price(X, Y) Æ : past_order(U, X) CIS 650 19
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 WP schema of example (cont’d) n Payment Page g. Input: pay(U, X, Y), button(X) g. Input Rules: · Optionsorder(X) Ã price(X, Y) · Optionsbutton(X) Ã X=“order” Ç X=“cancel” g. State Rules (this example: one state relation error): · past_order(U, X) +: - order(X) Æ U = user Æ : past_order(U, X) g. Target WP: PP, HP g. Target Rules: · HP : - button(“pay”) g. Output rules: · ship(U, X, Y) : - past_order(U, X) Æ pay(U, X, Y) Æ button(“pay”) Æ price(X, Y) Æ 9 Z (credit-limit(U, Z) Æ Z >= Y) CIS 650 20
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Outline n High-level Specification models g. Relational Transducers g. ASM Transducers g. Web Page Schemas n Automatic Verification g. Past input g. FO-LTL g. CTL/CTL* n Conclusions CIS 650 21
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Verifying properties about past input Properties of the form: 8 x[φ(state, db, in)(x) ! ψ(state, db, in)(x)] n n n E. g. , “Whenever a product is shipped, at some previous step a proper payment has been received” Such properties can be verified on Spocus transducers (in NEXPTIME) g. Semi-positive output: every variable appearing in an output rule must occur in at least one positive atom g. Cumulative state: state rules can only accumulate previous input CIS 650 22
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Spocus transducers n Cumulative state is a bit too restrictive g. Cannot express the following simple machine: a b b c a c because state can only contain past input, and relations are sets (unordered) CIS 650 23
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Some properties require more expressiveness Cannot express properties like: “if a customer pays for a book, then eventually the book will be shipped to them” n CIS 650 24
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 First-Order Linear-time Temporal Logic n Temporal operators g. Xp: p holds in the next time gp. Uq: p holds until q holds g. Fp: p holds eventually g. Gp: p always holds gp. Bq: either q always holds or p holds before q fails n Examples: gif a customer pays for a book, then eventually the book will be shipped to them: 8 u 8 x 8 y[past_order(u, x) Æ price(x, y) Æ pay(u, y) ! F ship(u, x)] g. A product must be paid for before it is shipped: 8 u 8 y [pay(u, y) Æ 9 x price(x, y) B : ship(x, y)] 25 CIS 650
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 LTL-FO Example Verification is undecidable for ASM transducers: n Restrictions: n g. Maximal input flow g. Input-boundedness: · Input rules: 9*FO with ground state atoms · All other rules: quantification only on variables that are bounded by expressions on (current or last but not further “past”) input relations n Given an input bounded Web Service W and an input bounded LTL-FO formula φ, checking W ² φ is in EXPSPACE (PSPACE-complete for fixed schema) CIS 650 26
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Input-boundedness n n Not input-bounded formula: 8 u 8 y[pay(u, y) Æ 9 x price(x, y) B : ship(x, y)] Input-bounded formula: 8 u 8 y[last_order(u, x) Æ pay(u, y) Æ 9 x price(x, y) B : ship(x, y)] CIS 650 27
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Boundaries of decidability Relaxing the requirement that state atoms must be ground in formula defining the input options, by allowing state atoms with variables. Reduction: Does TM halt on input epsilon? n Lifting the input-bounded requirement by allowing state projection (i. e. , state rules of the form: S(x) : - 9 y S’(x, y)). Reduction: Implication for FDs and IDs n Allowing variables to be bounded on state relations that hold all past input (rather than the most recent one). Reduction: Trakhtenbrot’s Theorem n Extend the LTL-FO formula with path quantification. Reduction: validity of 9*8*FO formulas n CIS 650 28
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Branching-time Temporal Logic n CTL (Computation Tree Logic) introduces path quantifiers: g. A: ”for every path” g. E: ”there exists a path” Proposed for Web page schemas (to express properties of transition between pages) n Example n g. From every page (i. e. , the target of every path) there always exists a path that eventually reaches HP: A G E F HP CIS 650 29
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Verification of CTL-FO Input-boundedness is not enough for decidability of CTL-FO verification n Further restriction: Propositional input-bounded Web Services n g. Actions and states are propositional (no data values) g. Input rules need not be propositional n Propositional CTL formulas g. Use input, action, state relation names and WP symbols (viewed as propositions) CIS 650 30
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Input-bounded propositional CTL-FO n Verification of W ² φ for CTL(*) formulas for propositional Web services: g. CO-NEXPTIME for CTL g. EXPSPACE for CTL* n But propositional Web services are not very expressive g. Can be viewed as an abstraction g. Can express property in previous slide g. Cannot express navigational properties that depend on data, e. g. : 8 pid, 8 pr [AG(ξ (pid, pr) ! A((EF cancel(user, pid))U(ship(user, pid))] CIS 650 31
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Outline n High-level Specification models g. Relational Transducers g. ASM Transducers g. Web Page Schemas n Automatic Verification g. Past input g. FO-LTL g. CTL/CTL* n Conclusions CIS 650 32
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Conclusions Spocus transducers are probably too restrictive n ASM transducers more appropriate for practical use n Interesting properties require temporal operators n g. Decidable n for input-bounded specifications/formulas Navigational properties require further restrictions g. Trade-off between more expressiveness of model and of property language g. Questionable whether the model for which verification is decidable is expressive enough to represent interesting applications CIS 650 33
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Conclusions n Static analysis is decidable under restrictions, but we need practical verification algorithms to build applications g. Heuristics could help in achieving good performance g. Attempt to implement real-life applications could uncover more limitations of the models g. Performance of algorithms for such applications will determine whether this work can be widely used in practice CIS 650 34
UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Extensions n Allow updates in database relations g. During runs, or g. Sessions: verify properties within a session and allow updates between sessions n Interacting Web services g. Extend models with communication primitives to model web service composition g. Discover important properties for composite web services g. Devise appropriate restrictions under which verification of those properties is decidable CIS 650 35
Скачать презентацию UNIVERSITY of PENNSYLVANIA Grigoris Karvounarakis December 04 Verification
c930210e9dfde98928a7ce17f458757d.ppt