Data Abstractions for the Verification of Web Service Compositions

1. Data Abstractions for the Verification of Web Service Compositions

2. Loan Approval Ignoring data affects control flow: Loan Approval [amount >= 10000] [ amount < 10000] <INVOKE> assess <INVOKE> approve [risk != low] [ risk == low ] result := yes

3. Loan Approval Ignoring data affects control flow: Loan Approval [amount >= 10000] [ amount < 10000] <INVOKE> assess <INVOKE> approve [risk != low] [ risk == low ] result := yes

4. Loan Approval Ignoring data affects control flow: Loan Approval [amount >= 10000] [ amount < 10000] <INVOKE> assess <INVOKE> approve [risk != low] [ risk == low ] result := yes

5. Loan Approval Ignoring data affects control flow: Loan Approval [amount >= 10000] [ amount < 10000] <INVOKE> assess <INVOKE> approve [risk != low] [ risk == low ] result := yes Bad scenario: amount> 10000, approve.result = ‘no’, assess.risk = ‘low’, result = ‘yes’

6. Extended Loan Approval Ignoring data hides properties of the system: Loan Approval amount answer:= false result:=amount <WHILE> [ !answer] [ amount < 10000 ] [ amount >= 10000 ] <INVOKE> assess <INVOKE> approve [risk != low] [ risk == low ] [! answer] amount:= reduce(amount) answer := true result:= amount result Bad scenario: amountis reduced, result is not changed

7. Data Flow Analysis • Current approaches • Ignoring data and data flow (LTSA-BPEL, PN-based approaches) • Finite data domain instantiation (WSAT, WS-VERIFY) • Challenges • Infinite data domains – necessity to reason on infinite-state spaces • Custom functions and predicates – inability to reason and evaluate • Non-determinism – accurate modeling and representation • Problems • Complexity • Precision

8. Solution 1 • Conservative abstraction • Given a concrete system C, and a set of predicates (propositions over data), build an abstract system A, s.t. A is an over-approximation of C: L(A) ≥ L(C) • For a (universal) property p, if p holds on A, then p holds on C. • A converse does not hold • This does not work for existential properties P = “Eventually amount is greater than the initial one”: • C satisfies assertion (G ¬ p), and violates possibility (F p) • A violates assertion (G ¬ p), and satisfies possibility (F p) • Able to give only partial answer!

9. Solution 2 • 3-valued abstraction • Given a concrete system C, build a 3-valuedabstract system A, s.t. a proposition may have value true, false or unknown. • The result of the property analysis may also have 3 values • Reduced to the 2-valuedproblem with the help of two models/interpretations L(Ao) ≥ L(C) ≥ L(Au) If property holds on Ao, then it holds on C If property is violated in Au, then it is violated in C • Less precise w.r.t. previous model: P = “Eventually amount is greater or less (or equal) than the initial one”: • Property is trivially true • Ao violates the property!

10. Proposed Solution • Hybrid approach • Two models • E-model: over-approximated abstraction, 2-valued logic • K-Model: under-approximated abstraction, knowledge-level representation • Universal and existential properties AE⊧Aφ → C⊧Aφ → AK⊧Aφ AK⊧Pφ → C⊧Aφ → AP⊧Aφ

11. Abstract Composition Model • Set of predicates P = {p1,…,pn}, valuationV:P → 2P • Abstract STS <B,S,S0,R> • B – set of boolean variables corresponding to P • S – _PC x 2P set of states • S0 – set of initial states • R – S x S transition relation s.t. ((pc, V), (pc’, V’)) in R iff • Exists (s,φ,a,Ω,s’) • pc = pc(s) ; pc’ = pc(s’) • applicable[t](V) • V’ = exec[t](V’) result:=error [a>b] a:=a - 5 [!a>b] a:= 10 b:=1 P = {(a>b), !(a>b)} (T,F) (T,F) (T,F)

12. Branching Model (E-Model) • Interpretation: IE(V) – set of states g s.t. V(p) = Evalg(p) • applicableE[t](V) iff exists g s.t. Evalg(φ) = true • Transition is applicable if its condition is true in some ground state compatible with valuation • execE[t](V) is one of the valuations V’ s.t. exists g in V, for all pV’(p) = Evalupdate(g,Ω)(p) • Result of the execution of transition in an abstract state s is an abstract state s’ compatible with the update applied to one of the ground states compatible with s (F,T) (F,T) result:=error (T,F) (T,F) P = {(a>b), !(a>b)} (T,F)

13. Knowledge-level Model (K-Model) • Interpretation: IK(V) – set of states g s.t. if V(p) = true then Evalg(p) = true • If proposition is true then it is “known” to be true in all ground states • applicableK[t](V) iff for all gEvalg(φ) = true • Transition is applicable if its condition is true in every ground state compatible with valuation • execK[t](V) is a valuation V’ s.t. for each p,V’(p) = true iff forall g in VEvalupdate(g,Ω)(p) = true • Result of the execution of transition in an abstract state s is an abstract state s’ with the safest knowledge about propositions (T,F) (T,F) P = {(a>b), !(a>b)} (F,F)

14. Property Satisfiability • K-model of the formula (φK): • Convert to Negative Normal Form • Replace propositions with corresponding boolean variables • E-satisfiability • Assertion: AE⊧Aφ iff for each execution ππ⊧φ • Possibility: AE⊧Pφ iff exists execution ππ⊧φ • K-satisfiability • Assertion: AK⊧Aφ iff for each execution ππ not ⊧(¬φ)K • Possibility: AE⊧Pφ iff exists execution ππ⊧φK

15. Analysis approach • For an assertion: • Prove that E-model satisfies assertion (return TRUE) • If not, prove that K-model violates assertion (return FALSE) • If not, refine (return UNKNOWN) • For a possibility: • Prove that K-model satisfies possibility (return TRUE) • If not, prove that E-model violates possibility (return FALSE) • If not, refine (return UNKNOWN)

16. Justifying the approach • Over-approximated K-model has less precision • Under-approximated E-model is not applicable

17. Challenges • Refinement process: When the result is unknown, improve the abstraction s.t. the property satisfiability is known • Counterexample analysis: • Extract set of propositions that are necessary to improve the analysis • Extract assumptions on the abstract functions that would remove non-determinism e.g. if ((b<5) and (a=10)) then (a-5)>b

18. Customer Loan Approval amount := ? amount answer:= false result:=amount <INVOKE> request <WHILE> [ !answer] [ amount < 10000 ] [ amount >= 10000 ] Approver Assessor amount <INVOKE> assess <INVOKE> approve amount [risk != low] risk := ? answer := ? risk answer [ risk == low ] [! answer] amount:= reduce(amount) answer := true result:= amount result