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

2. TAV-WEB 2004 Discussion What are the defining characteristics of web services and how do these characteristics influence testing, analysis and verification?

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

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 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 accept or 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 SB or cancel the 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) register ack, cancel accept, reject, bill request, terminate report Investor (Inv) Research Dept. (RD) Stock Broker (SB) 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,...

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

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

10. Conversations A virtual watcher records the messages as they are sent Watcher A conversation is a sequence of messages the watcher sees during an execution Question: Given a composite web service, is the set of conversations a regular set? register accept request report Investor (Inv) Research Dept. (RD) Stock Broker (SB) ack rep acc bil regack reqter bill terminate

11. Example: Answer Conversation Sets are not always regular, even without message contents ?a!r P1P1 P2P2 ?r !a r a Conversation set = { w | w  ( r | a ) * such that, in each prefix of w the number of r ’s is greater than the number of a ’s and there are an equal number of r ’s and a ’s in w }

12. Asynchronous Communication 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 Communicating Finite State Machines (finite state machines with asynchronous communication) are as powerful as Turing machines

13. 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?

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

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

16. SAS Conversation Protocol 1 23 4 6 5 78 10 9 1211 register reject terminate accept request report ack request report ack cancel billcancel bill terminate This conversation protocol specifies the set of conversations for the SAS

17. Conversation Protocol A  B:msg1 B  A:msg2 B  C:msg3C  B:msg4 B  C:msg5 G(msg1  F(msg3  msg5)) ? LTL property !msg1 ?msg2 Peer A ?msg1 !msg2 !msg5 !msg3 ?msg4 Peer B ?msg3 !msg4 Peer C Peer APeer BPeer C msg1 msg2, msg6 msg3, msg5 msg4 Conversation Schema Input Queue... Virtual Watcher ?msg6 B  A:msg6 !msg6 ?msg5 G(msg1  F(msg3  msg5)) ? LTL property

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

19. Interesting Question Are there conditions which ensure the equivalence? Conversations generated by the composed behavior of the projected services Conversations specified by the conversation protocol  ?

20. Realizability Problem Not all conversation protocols are realizable! A  B: m1 C  D: m2 Conversation protocol !m1 ?m1 !m2 ?m2 Peer APeer BPeer CPeer D m2 m1 Conversation “ m2 m1 ” will be generated by any legal peer implementation which follows the protocol Projection of the conversation protocol to the peers

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

22. Realizability Problem Three sufficient conditions for realizability (contentless messages) [Fu, Bultan, Su, CIAA’03] –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 Each peer should be able to make a deterministic decision on whether to send or to receive or to terminate

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 composite web services where asynchronous communication does not create a problem?

24. Three Examples, Example 1 ?r 1 !a 1 !a 2 ?r 2 ?e requesterserver !r 2 ?a 1 ?a 2 !e !r 1 Conversation set is regular: (r 1 a 1 | r 2 a 2 )* eConversation set is regular: (r 1 a 1 | r 2 a 2 )* e During all the executions queues are bounded r 1, r 2 a 1, a 2 e

25. Example 2 !r 1 !r 2 ?a 1 ?a 2 !e ?r 1 !a 1 !a 2 ?r 2 ?e r 1, r 2 a 1, a 2 requesterserver e Conversation set is not regularConversation set is not regular Queues are not bounded

26. Example 3 r 1, r 2 a 1, a 2 requesterserver e !r 1 !r !r 2 ?a !e ?r 1 ?r!a ?e ?r 2 Conversation set is regular: (r 1 | r 2 | r a)* eConversation set is regular: (r 1 | r 2 | r a)* e Queues are not bounded

27. Three Examples queue length # of states in thousands 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 set does 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? Problem SetSizeSynchronizable? SourceName#msg#states#trans. ISSTA’04SAS91215yes IBM Conv. Support Project CvSetup444yes MetaConv446no Chat245yes Buy556yes Haggle858no AMAB81015yes BPEL spec shipping233yes Loan666yes Auction9910yes Collaxa. com StarLoan677yes Cauction576yes

30. BPEL to GFSA Guarded automata GFSA to Promela (bounded queue) BPEL Web Services Promela Synchronizability Analysis GFSA to Promela (synchronous communication) Intermediate Representation Conversation Protocol Front End Realizability Analysis Guarded automaton skip GFSA parser success fail GFSA to Promela (single process, no communication) success fail AnalysisBack End (bottom-up) (top-down) Verification Languages Web Service Analysis Tool (WSAT)

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 !r 1 ?a 1 ?a 2 !e !r 2 //type declaration request [ id [int] ] // message declaration r2: request // local variable declaration last: request Guard{ r2/id = last/id => r2/id := last/id + 1 }

33. XML (eXtensible Markup Language) XML is a markup language like HTML Similar to HTML, XML tags are written as followed by HTML vs. XML –In HTML, tags are used to describe the appearance of the data... –In XML, tags are used to describe the content of the data rather than the appearance XML documents can be modeled as trees where each internal node corresponds to a tag and leaf nodes correspond to basic types

34. An XML Document and Its Tree VIP01 0001 0002 0425 investorID Register VIP01 requestList 00010002 payment accountNum 0425 stockID

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

36. MSL (Model Schema Language) MSL (Model Schema Language) is a compact formal model language which captures core features of XML Schema 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 g 1, g 2 denotes an ordered sequence where the first member is of type g 1 and the second member is of type g 2 g 1 & g 2 denotes an unordered sequence where one member is of type g 1 and the other member is of type g 2 g 1 | g 2 denotes a choice between type g 1 and type g 2, i.e., either type g 1 or type g 2, but not both

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

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

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

41. Example Register[ investorID[string] & requestList[ stockID[int]{1,3} ] & payment[ creditCardNum[int] | accountNum[int] ] 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; }

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

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

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

45. 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 q 1 / q 2 returns each node which matches q 2 starting at a child of a node which matches q 1 q 1 // q 2 returns each node which matches q 2 starting at a descendant of a node which matches q 1 q 1 [ q 2 ] applies q 2 to the children of the nodes which match q 1 q [ exp ] returns the nodes that match q and for children of which the expression exp evaluates to true

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

47. XPath to Promela Generate code that evaluates the XPath expression 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

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

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

50. FOR (i1,1,3) EMPTY IF (cond) SET (bRes1,0) IF (bRes1) IF (i2==i3) IF (bRes2) EMPTY SET (bRes2,0) SET (bRes1,1) $register // stockID / [int()>5] / [position() = = last()]/ int() cond  v_register.requestlist.stockID[i1] > 5 Sequence Insert 15 55 5555 5 6 Generated Statements

51. $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;

52. $request//stockID=$register//stockID[int()>5][position()=last()] i1=0; do :: i1 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;

53. Model Checking Using Promela Subtle errors in an example –SAS: Stock Analysis Service [Fu, Bultan, Su ISSTA’04] –3 peers: Investor, Broker, ResearchDept. –Investor  Broker: a registerList of stockIDs –Broker  ResearchDept.: relay request (1 stockID per request) find the stockID in the latest request, send its subsequent stockID in registerList –Repeating stockID will cause error. –Only discoverable by analysis of XPath expressions

54. 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] –Orchestrating computations on the world-wide web [Choi, Garg, Rai, Misram, Vin EuroPar’02] Realizability problem –Realizability of Message Sequence Charts (MSC) [Alur, Etassami, Yannakakis ICSE’00, ICALP’01]

55. Related Work Verification of web services –Simulation, verification, composition of web services using a Petri net model [Narayanan, McIlraith WWW’02] –BPEL verification using a process algebra model and Concurrency Workbench [Koshkina, van Breugel’03] –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]

56. Current and Future Work More analysis tools are necessary for guarded protocols with infinite domains –Symbolic analysis –Abstraction Extending the source and target languages Tools for model checking web services –Finite state vs. infinite-state –Message contents, local variables

57. Translator for bottom-up specifications Guarded automata Translation with bounded queue Synchronizability Analysis Translation with synchronous communication Intermediate Representation Conversation Protocols Front End Realizability Analysis Guarded automaton skip Translator for top-down specifications success fail Translation with single process, no communication success fail AnalysisBack End BPEL Web Service Specification Languages DAML-S WSCI Promela SMV Action Language Verification Languages... Automated Abstraction Current and Future Work