WSAT A Tool for Formal Analysis of Web

WSAT A 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

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

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?

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

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

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 1 register 3 reject 6 request 2 accept report 7 cancel 5 l l i ack 8 ack request 9 b report terminate 4 12 terminate bill 11 cancel 10

msg 1 Conversation Schema Peer A msg 2, msg 6 msg 4 Peer B msg 3, msg 5 Peer C B A: msg 2 B C: msg 5 Conversation Protocol A B: msg 1 ? B A: msg 6 B C: msg 3 LTL property G(msg 1 F(msg 3 msg 5)) C B: msg 4 Composite Web Service Peer A Peer B !msg 1 Peer C ? msg 1 !msg 3 Input Queue ? msg 3 !msg 2 ? msg 2 !msg 5 ? msg 6 Virtual Watcher ? msg 5 ? msg 4 !msg 6 . . . ? G(msg 1 F(msg 3 msg 5)) LTL property

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 Conversations specified by the conversation protocol ? Conversations generated by the composed behavior of the projected services Are there conditions which ensure the equivalence?

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

Another Non-Realizable Protocol A m 3 B A: m 1 m 2 B m 2 A m 1 B m 3 C C B A, C m 2 A B: m 1 Watcher A B: m 1 B A: m 2 A C: m 3 m 2 m 1 m 3 This protocol fails Autonomous condition

Yet Another Non-Realizable Protocol m 1 A m 2 A B: C A: B m 2 A m 1 B C C m 1 m 2 Watcher m 2 m 1 This protocol fails Synchronous compatible condition

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

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?

Three Examples, Example 1 r 1, r 2 !e e ? a 2 !r 1 !r 2 !a 1 ? a 1 requester a 1, a 2 ? r 1 !a 2 ? e server • Conversation set is regular: (r 1 a 1 | r 2 a 2)* e • During all the executions queues are bounded

Example 2 ? a 1 !e !r 1 e !r 2 ? a 2 !a 1 r 1, r 2 a 1, a 2 requester • Conversation set is not regular • Queues are not bounded ? r 2 ? r 1 !a 2 ? e server

Example 3 !r 2 !r 1 r , r 1 2 !e ? r !a e ? a !r requester a 1, a 2 ? r 2 ? e server • Conversation set is regular: (r 1 | r 2 | r a)* e • Queues are not bounded ? r 1

# of states in thousands Three Examples 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

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]

Are These Conditions Too Restrictive? Problem Set Source Name #msg ISSTA’ 04 SAS 9 Cv. Setup 4 Meta. Conv 4 IBM Chat 2 Conv. Buy 5 Support Haggle 8 Project AMAB 8 BPEL shipping 2 Loan 6 spec Auction 9 Collaxa. Star. Loan 6 Cauction 5 com Size #states 12 4 4 4 5 5 10 3 6 9 7 7 Synchronizable? #trans. 15 4 6 5 6 8 15 3 6 10 7 6 yes yes no yes yes yes

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

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

SAS Guarded Automata Topdown { Schema{ Peer. List{ Investor, Broker, Research. Dept }, Type. List{ Register. . . Accept. . . }, Message. List{ register{ Investor -> Broker : Register }, accept{ Broker -> Investor : Accept }, . . . } }, GProtocol{ States{ s 1, s 2, s 3, s 4, s 5, s 6, s 7, s 8, s 9, s 10, s 11, s 12 }, Initial. State{ s 1 }, Final. States{ s 4 }, Transition. Relation{ t 1{ s 1 -> s 2 : register, Guard{ true } }, t 2{ s 2 -> s 5 : accept, Guard{ true => $accept[//order. ID : = $register//order. ID] } }, . . . } } }

An XML Document and Its Tree <Register> <investor. ID> VIP 01 </investor. ID> <request. List> <stock. ID> 0001 </stock. ID> <stock. ID> 0002 </stock. ID> </request. List> <payment> <account. Num> 0425 </account. Num> </payment> </Register> Register investor. ID VIP 01 request. List stock. ID 0001 0002 payment account. Num 0425

An MSL Type Declaration and an Instance Register[ investor. ID[string] , request. List[ stock. ID[int]{1, 3} ] , payment[ credit. Card. Num[int] | account. Num[int] ] ] <Register> <investor. ID> VIP 01 </investor. ID> <request. List> <stock. ID> 0001 </stock. ID> <stock. ID> 0002 </stock. ID> </request. List> <payment> <account. Num> 0425 </account. Num> </payment> </Register>

MSL to Promela Example Register[ investor. ID[string] , request. List[ stock. ID[int]{1, 3} ] , payment[ credit. Card. Num[int] | account. Num[int] ] ] typedef t 1_investor. ID{ mtype stringvalue; } typedef t 2_stock. ID{int intvalue; } typedef t 3_request. List{ t 2_stock. ID [3]; int stock. ID_occ; } typedef t 4_account. Num{int intvalue; } typedef t 5_credit. Card{int intvalue; } mtype {m_account. Num, m_credit. Card} typedef t 6_payment{ t 4_account. Num; t 5_credit. Card; mtype choice; } typedef Register{ t 1_investor. ID; t 3_request. List; t 6_payment; }

XPath Expressions Register investor. ID VIP 01 request. List stock. ID 0001 0002 payment account. Num 0425 //payment/* returns the node labeled account. Num /Register/request. List/stock. ID/int returns the nodes labeled 0001 and 0002 //stock. ID[int > 1]/int returns the node labeled 0002

XPath to Promela $register // stock. ID / [int()>5] / [position() = last()] int() / SET (i 2, 1) EMPTY 1 SET (b. Res 2, 0) SET (b. Res 1, 0) FOR (i 1, 1, 3) IF (cond) SET (b. Res 1, 1) IF (i 2==i 3) SET (b. Res 2, 0) 5 IF (b. Res 1) IF (b. Res 2) EMPTY 5 5 INC (i 2) cond v_register. requestlist. stock. ID[i 1] > 5 Sequence Insert 6

$request//stock. ID=$register//stock. ID[int()>5][position()=last()] /* result of the XPath expression */ bool b. Result = false; /* results of the predicates 1, 2, and 1 resp. */ bool b. Res 1, b. Res 2, b. Res 3; /* index, position(), last(), index, position() */ int i 1, i 2, i 3, i 4, i 5; i 2=1; /* pre-calculate the value of last(), store in i 3 */ i 4=0; i 5=1; i 3=0; do : : i 4 < v_register. request. List. stock. ID_occ -> /* compute first predicate */ b. Res 3 = false; if : : v_register. request. List. stock. ID[i 4]. intvalue>5 -> b. Res 3 = true : : else -> skip fi; if : : b. Res 3 -> i 5++; i 3++; : : else -> skip fi; i 4++; : : else -> break; od;

$request//stock. ID=$register//stock. ID[int()>5][position()=last()] i 1=0; do : : i 1 < v_register. request. List. stock. ID_occ -> b. Res 1 = false; if : : v_register. request. List. stock. ID[i 1]. intvalue>5 -> b. Res 1 = true : : else -> skip fi; if : : b. Res 1 -> b. Res 2 = false; if : : (i 2 == i 3) -> b. Res 2 = true; : : else -> skip fi; if : : b. Res 2 -> if : : (v_request. stock. ID. intvalue == v_register. request. List. stock. ID[i 1]. intvalue) -> b. Result = true; : : else -> skip fi; i 2++; : : else -> skip fi; i 1++; : : else -> break; od;

Model Checking Using Promela • Error in SAS conversation protocol t 14{ s 8 -> s 12 : bill, Guard{ $request//stock. ID = $register//stock. ID [position() = last()] => $bill[ //order. ID : = $register//order. ID ] } } • Repeating stock. ID will cause error • One can only discover these kinds of errors by analysis of XPath expressions

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]

Related Work • Verification of web services – Simulation, verification, composition of web services using a Petri net model [Narayanan, Mc. Ilraith 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 TAVWEB’ 04]

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

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