WSATA Tool for Formal Analysis of Web Services

Xiang Fu Tevfik Bultan Jianwen Su

Department of Computer ScienceUniversity of California, Santa Barbara

{fuxiang,bultan,su}@cs.ucsb.edu

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 StandardsIm

ple

men

tatio

n P

latfo

rms

Mic

roso

ft .N

et,

Sun

J2

EE

WSDL

SOAP

XML Schema

XML

WSCIInteraction

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

?bill

Investor

?register

!reject !accept!request

?ack

?cancel!bill

!bill

Stock Broker Firm

?request

?terminate

Research Dept.

!report

acc

req

reg

rep

ack

Composite Web Services

!terminate

bil

ter Watcher

repacc bilreg ackreq ter

Conversation Protocols

1

23

4

6

5

7 8

10

9

12 11

register

reject

terminate

accept

request

report ack

request

report

ackcancel

bill cancel

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

ConversationProtocol

AB:msg1

BA:msg2

BC:msg3 C B:msg4

BC:msg5

G(msg1 F(msg3 msg5))? LTL property

!msg1

?msg2

Peer A?msg1

!msg2

!msg5

!msg3

?msg4

Peer B

?msg3

!msg4

Peer C

Peer A Peer B Peer C

msg1

msg2,msg6

msg3,msg5

msg4

ConversationSchema

InputQueue

...Virtual Watcher

?msg6

BA: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 A Peer B Peer C Peer D

Conversation “m2 m1m2 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

m3A B: m1

A C: m3

B A: m2

A

B

C

m1m2 m3

Watcher

A B

C

B A, 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

A B

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

?r1

!a1

!a2

?r2

?e

requester server

!r2 ?a1

?a2

!e

!r1

• Conversation set is regular: (rConversation set is regular: (r11aa11 | r | r22aa22)* e)* e

• During all the executions queues are bounded

r1, r2

a1, a2

e

Example 2

!r1

!r2

?a1

?a2

!e

?r1

!a1

!a2

?r2

?e

r1, r2

a1, a2

requester server

e

• Conversation set is not regularConversation set is not regular• Queues are not bounded

Example 3

r1, r2

a1, a2

requester server

e

!r1

!r

!r2

?a

!e

?r1

?r !a

?e?r2

• Conversation set is regular: (rConversation set is regular: (r11 | r | r22 | r a)* e | r a)* e

• Queues are not bounded

Three Examples

0

200

400

600

800

1000

1200

1400

1600

1 3 5 7 9 11 13

Example 1

Example 2

Example 3

queue length

# o

f st

ates

in

th

ou

san

ds

• 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 Size Synchronizable?Source Name #msg #states #trans.

ISSTA’04 SAS 9 12 15 yes

IBM

Conv.

Support

Project

CvSetup 4 4 4 yesMetaConv 4 4 6 no

Chat 2 4 5 yesBuy 5 5 6 yes

Haggle 8 5 8 noAMAB 8 10 15 yes

BPEL

spec

shipping 2 3 3 yesLoan 6 6 6 yes

Auction 9 9 10 yesCollaxa.

com

StarLoan 6 7 7 yesCauction 5 7 6 yes

BPEL to

GFSAGuardedautomata

GFSA to Promela (bounded queue)

BPEL

WebServices

Promela

Synchronizability Analysis

GFSA to Promela(synchronous

communication)

IntermediateRepresentation

ConversationProtocol

Front End

Realizability Analysis

Guardedautomaton

skip

GFSAparser

success

fail

GFSA to Promela(single process,

no communication)

success

fail

Analysis Back 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 AutomataTopdown { 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

<Register><investorID>VIP01</investorID><requestList><stockID>0001</stockID><stockID>0002</stockID></requestList><payment><accountNum>0425</accountNum></payment></Register>

investorID

Register

VIP01

requestList

0001 0002

payment

accountNum

0425

stockID stockID

An MSL Type Declaration and an Instance

Register[ investorID[string] , requestList[ stockID[int]{1,3} ] , payment[ creditCardNum[int] | accountNum[int] ]]

<Register><investorID>VIP01</investorID><requestList><stockID>0001</stockID><stockID>0002</stockID></requestList><payment><accountNum>0425</accountNum></payment></Register>

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

0001 0002

payment

accountNum

0425

stockID stockID

FOR (i1,1,3)

EMPTY

IF (cond)

SET (bRes1,0)

IF (bRes1)

IF (i2==i3)

IF (bRes2) EMPTY

SET (bRes2,0)

SET (bRes2,0)

SET (bRes1,1)

$register // stockID / [int()>5] / [position() = last()] / int()

cond v_register.requestlist.stockID[i1] > 5 SequenceInsert

1

5

5 56

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

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

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

Translatorfor bottom-upspecifications Guarded

automata Translation withbounded queue

SynchronizabilityAnalysis

Translation withsynchronous

communication

IntermediateRepresentation

ConversationProtocols

Front End

Realizability Analysis

Guardedautomaton

skip

Translatorfor top-downspecifications

success

fail

Translation withsingle process,

no communicationsuccessfail

Analysis Back End

BPEL

Web ServiceSpecificationLanguages

WSCI

Promela

SMV

ActionLanguage

VerificationLanguages

. . .

. . .

Aut

omat

ed

Abs

trac

tion

Future Work