Tools for Automated Verification of Web Services

1. Tools for Automated Verification of Web Services Tevfik Bultan Department of Computer Science University of California, Santa Barbara bultan@cs.ucsb.edu http://www.cs.ucsb.edu/~bultan/

2. Characteristics of Web Services Web services: Web accessible software applications which interact with each other through the Internet Goals • Platform independent (.NET, J2EE) • Dynamic service discovery • Loosely coupled • Tolerate pauses in availability and slow data transmission Approach • Standardized data transmission: XML • Interaction through standardized interfaces: WSDL • Asynchronous messaging

3. Web Service Standards Interaction WSCI Composition BPEL4WS Service WSDL Implementation Platforms Microsoft .Net, Sun J2EE Message SOAP Type XML Schema XML Data Web Service Standards

4. 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 the XML messages? • How do we verify properties related to data?

5. Outline • Web Service Composition Model • Capturing Global Behaviors • Conversations • 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 Collaborators: Xiang Fu, Jianwen Su, Rick Hull

6. An Example: Stock Analysis Service Three peers: Investor (Inv), Stock Broker (SB), and Research Department (RD) • Inv initiates the stock analysis service by sending a register message to the SB • The SB may acceptor reject the registration • If the registration is accepted, the SB sends an analysis request to the RD • RD sends the results of the analysis directly to the Inv as a report • After receiving a report the Inv can either send an ack to the SBor cancelthe service • Then, the SB either sends the bill for the services to the Inv, or continues the service with another analysis request

7. An Example: Stock Analysis Service (SAS) • SAS is a composite web service • a finite set of peers: Inv, SB, RD • and a finite set of message classes:register, ack, cancel, accept, reject, bill, request, terminate, report register ack, cancel Investor (Inv) Stock Broker (SB) accept, reject, bill report request, terminate Research Dept. (RD)

8. Communication Model • We assume that the messages among the peers are exchanged using reliable and asynchronous messaging • FIFO and unbounded message queues Stock Broker (SB) Research Dept. (RD) req req • This model is similar to industry efforts such as • JMS (Java Message Service) • MSMQ (Microsoft Message Queuing Service)

9. Composite Web Service Execution 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 req ter ?terminate

10. Conversations register ack terminate accept bill request report • A virtual watcher records the messages as they are sent Investor (Inv) Stock Broker (SB) Watcher reg acc req rep ack bil ter Research Dept. (RD) • A conversation is a sequence of messages the watcher sees during an execution [Bultan, Fu, Hull, Su WWW’03]

11. Effects of Asynchronous Communication • Question: Given a composite web service, is the set of conversations a regular set? • Even when messages do not have any content and the peers are finite state machines the conversation set may not be regular • Reason: asynchronous communication with unbounded queues • Bounded queues or synchronous communication Conversation Set always regular

12. Properties of Conversations • The notion of conversation enables us to reason about temporal properties of the composite web services • LTL framework extends naturally to conversations • LTL temporal operators X (neXt), U (Until), G (Globally), F (Future) • Atomic properties Predicates on message classes (or contents) Example: G ( accept F bill) • Model checking problem: Given an LTL property, does the conversation set satisfy the property?

13. Bottom-Up vs. Top-Down Bottom-up approach • Specify the behavior of each peer • The global communication behavior (conversation set) is implicitly defined based on the composed behavior of the peers • Global communication behavior is hard to understand and analyze Top-down approach • Specify the global communication behavior (conversation set) explicitly as a protocol • Ensure that the conversations generated by the peers obey the protocol

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

15. Conversation Protocols • Conversation Protocol: • An automaton that accepts the desired conversation set • A conversation protocol is a contract agreed by all peers • Each peer must act according to the protocol • For reactive protocols with infinite message sequences we use: • Büchi automata which accept infinite strings • For specifying message contents, we use: • Guarded automata • Guards are constraints on the message contents

16. SAS Conversation Protocol • This conversation protocol specifies the set of conversations for the SAS 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

17. Synthesize Peer Implementations • Conversation protocol specifies the global communication behavior • How do we implement the peers? • How do we obtain the contracts that peers have to obey from the global contract specified by the conversation protocol? • Project the global protocol to each peer • By dropping unrelated messages for each peer

18. Interesting Question If this equality holds the conversation protocol is realizable Are there conditions which ensure the equivalence? ? Conversations specified by the conversation protocol  Conversations generated by the projected services

19. Realizability Problem !m2 ?m2 ?m1 !m1 Peer A Peer B Peer C Peer D Projection of the conversation protocol to the peers • Not all conversation protocols are realizable! AB: m1 CD: m2 Conversation protocol Conversation “m2 m1” will be generated by all peer implementations which follow the protocol

20. Another Non-Realizable Protocol m1 A B m2 A m2 m2 m3 C m1 m3 B m1 B A, C C BA:m2 AB:m1 m3 Watcher BA:m2 Generated conversation: m2 m1 m3 AB:m1 AC:m3

21. Realizability Conditions Three sufficient conditions for realizability (no message content) [Fu, Bultan, Su, CIAA’03, TCS’04] • Lossless join • Conversation set should be equivalent to the join of its projections to each peer • Synchronous compatible • When the projections are composed synchronously, 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 • At any state, each peer should be able to do only one of the following: send, receive or terminate (a peer can still choose among multiple messages)

22. Realizability Conditions • Following protocols fail one of the three conditions but satisfy the other two AB: m1 AB: m1 BA:m2 AB:m1 BA:m2 CD: m2 AB:m1 CA: m2 AC:m3 Not lossless join Not synchronous compatible Not autonomous

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

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

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

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

27. State Spaces of the 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

28. 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]

29. Are These Conditions Too Restrictive?

30. Web Service Analysis Tool (WSAT) Verification Languages WebServices Front End Analysis Back End Intermediate Representation GFSA to Promela (synchronous communication) success BPEL to GFSA SynchronizabilityAnalysis Guarded automata BPEL fail (bottom-up) GFSA to Promela (bounded queue) Promela skip GFSA parser Conversation Protocol Guarded automaton success GFSA to Promela(single process, no communication) Realizability Analysis (top-down) fail http://www.cs.ucsb.edu/~su/WSAT/ [Fu, Bultan, Su CAV’04]

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

32. The Guarded Automata Model //type declaration request [ id [int] ] // message declaration r2: request // local variable declaration last: request !e ?a1 ?a2 !r1 !r2 Guard{ a2/id = last/id => r2/id := last/id + 1, last/id := last/id + 1 }

33. XML (eXtensible Markup Language) • XML is a markup language like HTML • Similar to HTML, XML tags are written as <tag> followed by </tag> • HTML vs. XML • In HTML, tags are used to describe the appearance of the data <b> </b> <i> </i> <br> <p> ... • In XML, tags are used to describe the content of the data rather than the appearance <date> </date> <address> </address>

34. 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> • XML documents can be modeled as trees • where each internal node corresponds to a • tag and leaf nodes correspond to basic types

35. XML Schema • XML provides a standard way to exchange data over the Internet. • However, the parties which exchange XML documents still have to agree on the type of the data • What are the tags that will appear in the document, in what order, etc. • XML Schema is a language for defining XML data types • MSL (Model Schema Language) is a compact formal model language which captures core features of XML Schema

36. MSL (Model Schema Language) • Basic MSL syntax g  | b | t[g ] | g{m ,n } | g,g | g&g | g|g g is an XML type (i.e., an MSL type expression)  is the empty sequence b is a basic type such as string, boolean, int, etc. t is a tag m and n are positive integers [ ] { } & , | are MSL type constructors

37. MSL Semantics • t[g ] denotes a type with root node labeled t with children of type g • g{m ,n } denotes a sequence of size at least m and at most n where each member is of type g • g1,g2 denotes an ordered sequence where the first member is of type g1 and the second member is of type g2 • g1&g2 denotes an unordered sequence where one member is of type g1 and the other member is of type g2 • g1|g2 denotes a choice between type g1 and type g2, i.e., either type g1 or type g2, but not both

38. 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] ] ]

39. Translating Guarded Automata to Promela • We used the SPIN model checker to verify the properties of conversations • SPIN is a finite state model checker • we restricted XML message contents to finite domains • We translate guarded automata models to Promela (input language of the SPIN model checker) • First, translate MSL type declarations to Promela type declarations • Then, translate XPath expressions to Promela code

40. Mapping MSL types to Promela • Basic types • integer and boolean types are mapped to Promela basic types int and bool • We only allow constant string values and strings are mapped to enumerated type (mtype) in Promela • Other type constructors are handled using • structured types (declared using typedef) in Promela • or arrays

41. Mapping MSL type constructors to Promela • t[g ] is translated to a typedef declaration • g{m ,n } is translated to an array declaration • g1,g2 is translated to a sequence of type declarations • g1|g2is translated to a sequence of type declarations and an enumerated variable which is used to record which type is chosen • g1&g2 is not handled! We do not handle unordered type sequence (it can cause state-space explosion)

42. 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] ] ]

43. XPath • In order to write specifications or programs that manipulate XML documents we need: • an expression language to access values and nodes in XML documents • XPath is a language for writing expressions (queries) that navigate through XML trees and return a set of answer nodes • An XPath query defines a function which • takes and XML tree and a context node (in the same tree) as input and • returns a set of nodes (in the same tree) as output

44. XPath Syntax Basic XPath syntax: q . | .. | b | t | * | /q | //q | q/q | q//q | q [ q ] | q [exp] q is an XPath query exp denotes a predicate on basic types, i.e., on the leaf nodes of the XML tree b denotes a basic type such as string, boolean, int, etc. t denotes a tag

45. XPath Semantics Given an XML tree and a node n as a context node . returns n ..returns the parent of n Given an XML tree and a set of nodes * returns all the nodes b returns the nodes that are of basic type b t returns the nodes which are labeled with tag t

46. XPath Semantics Contd. Starting at the context node • /q returns the nodes that match q • //q returns the nodes that match q starting at any descendant • q1/q2 returns each node which matches q2 starting at a child of a node which matches q1 • q1//q2 returns each node which matches q2 starting at a descendant of a node which matches q1 • q1[ q2] applies q2 to the children of the nodes which match q1 • q [exp] returns the nodes that match q and for children of which the expression exp evaluates to true

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

48. XPath to Promela • Generate code that evaluates the XPath expression [Fu, Bultan, Su ISSTA’04] • Traverse the XPath expression from left to right • Code generated in each step is inserted into the BLANK spaces left in the code from the previous step • A tree representation of the MSL type is used to keep track of the context of the generated code • Uses two data structures • Type tree shows the structure of the corresponding MSL type • Abstract statements which are mapped to Promela code

49. Statement Promela Code if :: v -> BLANK :: else -> skip fi IF(v) FOR(v,l,h) v = l – 1 do :: v < h -> BLANK v++ :: else -> break od EMPTY BLANK INC(v) v++ SET(v,a) v = a

50. Type Tree Register[ investorID[string] & requestList[ stockID[int]{1,3} ] & payment[ creditCardNum[int] | accountNum[int] ] ] 1 Register 7 2 4 payment investorID requestList 8 10 3 5 string stockID (idx: i1) creditCard accountNum 9 11 int int 6 int