wsat a tool for formal analysis of web services xiang fu tevfik bultan jianwen su department of...
Post on 20-Dec-2015
220 views
TRANSCRIPT
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