WSAT A Tool for Formal Analysis of Web Services Xiang Fu Tevfik Bultan Jianwen Su Department of Computer Science University of California, Santa Barbara

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

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

!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 Services !terminate bil ter Watcher rep acc bil regack reqter

Conversation Protocols register reject terminate accept request report ack request report ack cancel billcancel bill terminate 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

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 Composite Web Service

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  ?

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 This protocol fails Lossless join condition

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

Yet Another Non-Realizable Protocol m1 m2 m1 m2 A  B: m1 C  A: m2 A B C m1m2 Watcher AB C 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 !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

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

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

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

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

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) Demonstration Saturday or anytime you find me with my laptop

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{ 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] } },... }

An XML Document and Its Tree VIP investorID Register VIP01 requestList payment accountNum 0425 stockID

An MSL Type Declaration and an Instance Register[ investorID[string], requestList[ stockID[int]{1,3} ], payment[ creditCardNum[int] | accountNum[int] ] VIP

MSL to Promela 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; }

XPath Expressions //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 payment accountNum 0425 stockID

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 INC (i2) SET (i2,1) XPath to Promela

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

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

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

Related Work Conversation specification –IBM Conversation support project –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, 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]

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

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 WSCI Promela SMV Action Language Verification Languages... Automated Abstraction Future Work