WSAT A Tool for Formal Analysis of Web Services

1. WSATA Tool for Formal Analysis of Web Services Xiang Fu Tevfik Bultan Jianwen Su Department of Computer Science University of California, Santa Barbara {fuxiang,bultan,su}@cs.ucsb.edu

2. Web Services • Loosely coupled, interaction through standardized interfaces • Standardized data transmission via XML • Asynchronous messaging • Platform independent (.NET, J2EE) Interaction WSCI BPEL4WS Composition WSDL Implementation Platforms Service Microsoft .Net, Sun J2EE SOAP Message XML Schema Type XML Data Web Service Standards

3. Challenges in Verification of Web Services • Distributed nature, no central control • How do we model the global behavior? • How do we specify the global properties? • Asynchronous messaging introduces undecidability in analysis • How do we check the global behavior? • How do we enforce the global behavior? • XML data manipulation • How do we specify XML messages? • How do we verify properties related to data?

4. Outline • Web Service Composition Model • Conversations: Capturing Global Behaviors • Top-Down vs. Bottom-Up Specification and Verification • Realizability vs. Synchronizability • XML messaging • MSL, XPath • Translation to Promela • Web Service Analysis Tool • Conclusions and Future Work

5. Composite Web Services Investor Stock Broker Firm ?register !register ?reject !reject !accept ?accept !request !ack rep acc bil ?report ?ack ack reg !bill ?bill ?cancel !cancel ?bill !bill !terminate Research Dept. !report ?request ter req Watcher ?terminate reg acc req rep ack bil ter

6. Conversation Protocols • A conversation is a sequence of messages the watcher sees during an execution [Bultan, Fu, Hull, Su WWW’03] • Conversation Protocol: An automaton that accepts the desired conversation set SAS conversation protocol report ack 1 6 7 8 register request cancel ack request reject accept bill 3 2 5 9 report terminate 4 12 11 10 bill cancel terminate

7. msg1 msg4 Peer A Peer B Peer C Conversation Schema msg2, msg6 msg3, msg5 LTL property BA:msg2 BC:msg5 ? Conversation Protocol G(msg1  F(msg3  msg5)) AB:msg1 BA:msg6 BC:msg3 C B:msg4 Composite Web Service Peer A Peer B Peer C ?msg1 !msg1 Input Queue !msg3 ?msg3 !msg2 ?msg2 !msg5 ?msg5 ?msg4 !msg4 ?msg6 !msg6 ... ? Virtual Watcher G(msg1  F(msg3  msg5)) LTL property

8. Top-Down Approach • Conversation protocol specifies the global communication behavior • How do we implement the peers? • Project the global protocol to each peer • By dropping unrelated messages for each peer Are there conditions which ensure the equivalence? ? Conversations generated by the composed behavior of the projected services Conversations specified by the conversation protocol 

9. Realizability Problem • Not all conversation protocols are realizable! A  B: m1 !m2 ?m2 ?m1 !m1 C  D: m2 Peer A Peer B Peer C Peer D Conversation protocol Projection of the conversation protocol to the peers Conversation “m2 m1” will be generated by any legal peer implementation which follows the protocol This protocol fails Lossless join condition

10. Another Non-Realizable Protocol m1 A B A m2 m2 m3 C B m1 B A, C C m3 B  A:m2 A  B:m1 Watcher A  B:m1 B  A:m2 m2 m1 m3 A  C:m3 This protocol fails Autonomous condition

11. Yet Another Non-Realizable Protocol m1 A B A m2 m2 C B m1 C A  B:m1 Watcher C  A:m2 m2 m1 This protocol fails Synchronous compatible condition

12. Realizability Problem • Three sufficient conditions for realizability [Fu, Bultan, Su, CIAA’03, TCS] • Lossless join: Conversation set should be equivalent to the join of its projections to each peer • Synchronous compatible: When the projections of the conversation protocol are executed with synchronous communication semantics, there should not be a state where a peer is ready to send a message while the corresponding receiver is not ready to receive • Autonomous: Each peer should be able to make a deterministic decision on whether to send or to receive or to terminate

13. Bottom-Up Approach • We know that analyzing conversations of composite web services is difficult due to asynchronous communication • The question is, can we identify composite web services where asynchronous communication does not create a problem?

14. Three Examples, Example 1 • Conversation set is regular: (r1a1 | r2a2)* e • During all the executions queues are bounded !a1 ?r2 r1, r2 !e ?r1 !a2 e ?a2 !r1 ?e a1, a2 !r2 ?a1 requester server

15. Example 2 • Conversation set is not regular • Queues are not bounded ?a1 !r1 !a1 ?r2 r1, r2 !e ?r1 !a2 e ?e a1, a2 !r2 ?a2 requester server

16. Example 3 !r2 !r1 r1, r2 !e ?r !a e ?a !r a1, a2 ?r2 ?r1 ?e requester server • Conversation set is regular: (r1 | r2 | r a)* e • Queues are not bounded

17. Three Examples # of states in thousands queue length • Verification of Examples 2 and 3 are difficult even if we bound the queue length • How can we distinguish Examples 1 and 3 (with regular conversation sets) from 2? • Synchronizability Analysis

18. Synchronizability Analysis • A composite web service is synchronizable, if its conversation setdoes not change when asynchronous communication is replaced with synchronous communication • A composite web service is synchronizable, if it satisfies the synchronous compatible and autonomous conditions [Fu, Bultan, Su WWW’04]

19. Are These Conditions Too Restrictive?

20. Web Service Analysis Tool (WSAT) Demonstration Saturday or anytime you find me with my laptop Verification Languages Web Services Front End Analysis Back End Intermediate Representation GFSA to Promela (synchronous communication) success BPEL to GFSA Synchronizability Analysis BPEL Guarded automata fail (bottom-up) GFSA to Promela (bounded queue) skip Promela GFSA parser Conversation Protocol success GFSA to Promela(single process, no communication) Guarded automaton Realizability Analysis fail (top-down)

21. Guarded Automata Model • Uses XML messages • Uses MSL for declaring message types • MSL (Model Schema Language) is a compact formal model language which captures core features of XML Schema • Uses XPath expressions for guards • XPath is a language for writing expressions (queries) that navigate through XML trees and return a set of answer nodes

22. SAS Guarded Automata Topdown { Schema{ PeerList{ Investor, Broker, ResearchDept }, TypeList{ Register ... Accept ... }, MessageList{ register{ Investor -> Broker : Register }, accept{ Broker -> Investor : Accept }, ... } }, GProtocol{ States{ s1,s2,s3,s4,s5,s6,s7,s8,s9,s10,s11,s12 }, InitialState{ s1 }, FinalStates{ s4 }, TransitionRelation{ t1{ s1 -> s2 : register, Guard{ true } }, t2{ s2 -> s5 : accept, Guard{ true => $accept[//orderID := $register//orderID] } }, ... } } }

23. An XML Document and Its Tree Register investorID requestList payment VIP01 stockID stockID accountNum 0001 0002 0425 <Register> <investorID> VIP01 </investorID> <requestList> <stockID> 0001 </stockID> <stockID> 0002 </stockID> </requestList> <payment> <accountNum> 0425 </accountNum> </payment> </Register>

24. An MSL Type Declaration and an Instance <Register> <investorID> VIP01 </investorID> <requestList> <stockID> 0001 </stockID> <stockID> 0002 </stockID> </requestList> <payment> <accountNum> 0425 </accountNum> </payment> </Register> Register[ investorID[string] , requestList[ stockID[int]{1,3} ] , payment[ creditCardNum[int] | accountNum[int] ] ]

25. MSL to Promela Example typedef t1_investorID{ mtype stringvalue;} typedef t2_stockID{int intvalue;} typedef t3_requestList{ t2_stockID stockID [3]; int stockID_occ; } typedef t4_accountNum{int intvalue;} typedef t5_creditCard{int intvalue;} mtype {m_accountNum, m_creditCard} typedef t6_payment{ t4_accountNum accountNum; t5_creditCard creditCard; mtype choice; } typedef Register{ t1_investorID investorID; t3_requestList requestList; t6_payment payment; } Register[ investorID[string] , requestList[ stockID[int]{1,3} ] , payment[ creditCardNum[int] | accountNum[int] ] ]

26. XPath Expressions Register investorID requestList payment VIP01 stockID stockID accountNum 0001 0002 0425 //payment/*returns the node labeled accountNum /Register/requestList/stockID/intreturns the nodes labeled0001and 0002 //stockID[int > 1]/intreturns the node labeled0002

27. XPath to Promela IF (cond) IF (bRes1) IF (bRes2) INC (i2) SET (bRes1,0) SET (i2,1) SET (bRes1,1) SET (bRes2,0) SET (bRes2,0) $register // stockID / [int()>5] / [position() = last()] / int() EMPTY 1 FOR (i1,1,3) IF (i2==i3) 5 EMPTY 5 5 6 Sequence cond  v_register.requestlist.stockID[i1] > 5 Insert

28. $request//stockID=$register//stockID[int()>5][position()=last()]$request//stockID=$register//stockID[int()>5][position()=last()] /* result of the XPath expression */ bool bResult = false; /* results of the predicates 1, 2, and 1 resp. */ bool bRes1, bRes2, bRes3; /* index, position(), last(), index, position() */ int i1, i2, i3, i4, i5; i2=1; /* pre-calculate the value of last(), store in i3 */ i4=0; i5=1; i3=0; do :: i4 < v_register.requestList.stockID_occ -> /* compute first predicate */ bRes3 = false; if :: v_register.requestList.stockID[i4].intvalue>5 -> bRes3 = true :: else -> skip fi; if :: bRes3 -> i5++; i3++; :: else -> skip fi; i4++; :: else -> break; od;

29. $request//stockID=$register//stockID[int()>5][position()=last()]$request//stockID=$register//stockID[int()>5][position()=last()] i1=0; do :: i1 < v_register.requestList.stockID_occ -> bRes1 = false; if :: v_register.requestList.stockID[i1].intvalue>5 -> bRes1 = true :: else -> skip fi; if :: bRes1 -> bRes2 = false; if :: (i2 == i3) -> bRes2 = true; :: else -> skip fi; if :: bRes2 -> if :: (v_request.stockID.intvalue == v_register.requestList.stockID[i1].intvalue) -> bResult = true; :: else -> skip fi :: else -> skip fi; i2++; :: else -> skip fi; i1++; :: else -> break; od;

30. Model Checking Using Promela • Error in SAS conversation protocol t14{ s8 -> s12 : bill, Guard{ $request//stockID = $register//stockID [position() = last()] => $bill[ //orderID := $register//orderID ] } } • Repeating stockID will cause error • One can only discover these kinds of errors by analysis of XPath expressions

31. Related Work • Conversation specification • IBM Conversation support project http://www.research.ibm.com/convsupport/ • Conversation support for business process integration [Hanson, Nandi, Kumaran EDOCC’02] • Realizability problem • Realizability of Message Sequence Charts (MSC) [Alur, Etassami, Yannakakis ICSE’00, ICALP’01]

32. Related Work • Verification of web services • Simulation, verification, composition of web services using a Petri net model [Narayanan, McIlraith WWW’02] • Using MSC to model BPEL web services which are translated to labeled transition systems and verified using model checking [Foster, Uchitel, Magee, Kramer ASE’03] • Model checking Web Service Flow Language specifications using SPIN [Nakajima ICWE’04] • BPEL verification using a process algebra model and Concurrency Workbench [Koshkina, van Breugel TAV-WEB’04]

33. Future Work • Other input languages in the front end • WSCI, OWL-S • Other verification tools at the back end • SMV, Action Language Verifier • Symbolic representations for XML data • Abstraction for XML data and XML data manipulation

34. Future Work Web Service Specification Languages Verification Languages Front End Analysis Back End Intermediate Representation BPEL success Translation with synchronous communication Translator for bottom-up specifications Promela SynchronizabilityAnalysis Guarded automata Conversation Protocols fail ActionLanguage Translation with bounded queue Automated Abstraction skip SMV . . . Translator for top-down specifications WSCI Realizability Analysis Translation withsingle process, no communication Guarded automaton . . . success fail