Upload
verda
View
61
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Tools for Automated Verification of Web Services. Tevfik Bultan Department of Computer Science University of California, Santa Barbara [email protected]. Web Services. Loosely coupled Standardized data transmission via XML Asynchronous messaging Platform independent (.NET, J2EE). - PowerPoint PPT Presentation
Citation preview
Tools for Automated Verification of Web Services
Tevfik Bultan
Department of Computer ScienceUniversity of California, Santa Barbara
Web Services• Loosely coupled • Standardized data transmission via XML• Asynchronous messaging• Platform independent (.NET, J2EE)
Data
Type
Service
Interaction
Message
BPEL4WS, WSCI
Web Service StandardsIm
plem
enta
tion
Pla
tform
s
Mic
roso
ft .N
et, S
un J
2EE
WSDL
SOAP
XML Schema
XML
Motivation• Challenges in both specification and verification
– 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 • Capturing Global Behaviors
– Conversations• Top-Down Specification and Verification
– Realizability• Bottom-Up Specification and Verification
– Synchronizability• Web Service Analysis Tool• Conclusions and Future Work
Collaborators: Xiang Fu, Jianwen Su, Rick Hull
Web Service Composition• A composite web service is a tuple S = ( P, M )
[Bultan, Fu, Hull, Su WWW’03]
M : finite set of message classes
P : finite set of peers(web services)
Traveler Agency
Hotel Airline
Req1
Booking1
Req 3
Req
2
Booking 3
Boo
king
2
Communication Model• Reliable • Asynchronous• Queues are FIFO and unbounded
AirlineAgency Req1
• This model is similar to industry efforts – JMS (Java Message Service)– MSMQ (Microsoft Message Queuing Service)
R2R2
Message Classes• Messages are classified into classes • Each message class is associated with one sender and
one receiver
• Two models for messages:– No content, just classes
• this model can represent messages with content as long as domains are finite
– Messages with content• XML messages
AirlineAgencyReq2
Finite State Peers• Peer: Finite state automaton + one FIFO queue• Extensions
– Reactive services: Büchi automata – Message contents: Guarded automata
Airline
?Req3!Booking3
[ Booking3.date
:= Req3.date ]
inputmessages
outputmessages
Executing Web Service Composition
Execution is a complete run if• Each sent message is eventually consumed • Each peer visits its final states infinitely often
Agency
? R1
! R2! B1
? B2
! B1
! R3
? B3
R1
R2
! R1
? B1
Traveler
B1
? R2
! B2
Airline
B2
? R3
! B3
Hotel
R3
B3
Outline• Web Service Composition Model • Capturing Global Behaviors
– Conversations• Top-Down Specification and Verification
– Realizability• Bottom-Up Specification and Verification
– Synchronizability• Web Service Analysis Tool• Action Language Verifier• Conclusions and Future Work
Conversations• Watcher: “records” the messages as they are sent
Watcher
AirlineHotel
Traveler Agency
R1
B1
R1 R2 B2 B3R3
• A conversation is a sequence of messages the watcher sees in a complete run
• Conversation Set: the set of all possible conversations of a service S : C(S)
B1
R 3
B 3
B2R2
Properties of Conversations• The notion of conversation enables us to reason about
temporal properties of the web service composition
• 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 (R1 F B1)
• Model checking problem: Given an LTL property, does the conversation set C(S) satisfy the property?
Question• Given a web service composition SS, is the language C(S)
always regular?
If it is regular, finite state model checking techniques can be used for verification
Example: C(S) = { w | w (r | a) and for each prefix w’, |r|w’ |a|w’}
Answer
Conversation Sets are not always regular, even without message contents
• Causes: asynchronous communication with unbounded queues
• Bounded queues or synchronous communication Conversation Set always regular
?a!r
P1 P2
?r
!a
r
a
Outline• Web Service Composition Model • Capturing Global Behaviors
– Conversations• Top-Down Specification and Verification
– Realizability• Bottom-Up Specification and Verification
– Synchronizability• Web Service Analysis Tool• Action Language Verifier• Conclusions and Future Work
Bottom-Up vs. Top-DownBottom-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
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 Cmsg1
msg2,msg6
msg3,msg5
msg4
ConversationSchema
InputQueue
...Virtual Watcher
?msg6
BA:msg6
!msg6
?msg5
G(msg1 F(msg3 msg5))?
LTL property
(c)
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
Model Checking• Protocols without message contents
– Finite state model checking techniques and tools
• Protocols with finite domain message contents– Finite state model checking techniques and tools
• Protocols with infinite domain message contents– Infinite state model checking techniques and tools
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
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
?
Realizability Problem• Not all conversation protocols are realizable!
A B: a
C D: b
Conversation protocol
! a ? a ! b ? b
Peer A Peer B Peer C Peer D
Conversation “baba” will be generated by any legal peer implementation which follows the protocol
Projection of the conversation protocol to the peers
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
Realizability for Guarded Protocols• One natural conjecture:
– Drop all guards and message contents to get the “skeleton” of the conversation protocol
– Check realizability of the skeleton
• Conjecture fails because there exists– Nonrealizable guarded protocols with realizable
skeletons, and– Realizable guarded protocols with nonrealizable
skeletons.
Examples
A B: a(1)
C D: c(1)
C D: c(2)
A B: a(2)
.
c (1) a(2) is a conversation of the projected peers
D B: d(1) D A: e(2)
D B: d(2)D A: e(1)
A B: a B A: b
Skeleton is realizable,but guarded protocol is not
Guarded protocol is realizable, but its skeleton is not
Realizability for Guarded Protocols• A fourth condition
– Deterministic guards• If we determinize projection of the conversation
protocol to each peer, all the guards that map to a state should be identical
• If a guarded conversation protocol satisfies the above property – and if its skeleton satisfies the three conditions we
discussed before, • then it is realizable
Guarded Protocols• If the realizability conditions are not met we can still try
exhaustive state space exploration
– Treat each valuation of message contents as a new message class and get a standard conversation protocol without contents
– Accurate, but costly
• Future work: developing symbolic verification techniques for conversation protocols
Outline• Web Service Composition Model • Capturing Global Behaviors
– Conversations• Top-Down Specification and Verification
– Realizability• Bottom-Up Specification and Verification
– Synchronizability• Web Service Analysis Tool• Action Language Verifier• Conclusions and Future Work
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 Cmsg1
msg2,msg6
msg3,msg5
msg4
ConversationSchema
InputQueue
...Virtual Watcher
?msg6
BA:msg6
!msg6
?msg5
G(msg1 F(msg3 msg5))?
LTL property
(c)
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
0200400600800
1000120014001600
1 3 5 7 9 11 13
Example 1Example 2Example 3
queue length
# of
sta
tes
in th
ousa
nds
• 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 SS is synchronizable, if its
conversation set C(S) 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.
SupportProject
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
BPELspec
shipping 2 3 3 yesLoan 6 6 6 yes
Auction 9 9 10 yesCollaxa.
comStarLoan 6 7 7 yesCauction 5 7 6 yes
Outline• Web Service Composition Model • Capturing Global Behaviors
– Conversations• Top-Down Specification and Verification
– Realizability• Bottom-Up Specification and Verification
– Synchronizability• Web Service Analysis Tool• Action Language Verifier• Conclusions and Future Work
BPEL to
GFSAGuardedautomata
GFSA to Promela (bounded queue)
BPEL
WebServices
Promela
SynchronizabilityAnalysis
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
Guarded Automata Model• Uses XML messages
• Uses MSL for declaring message types– MSL (Model Schema Language) is a compact formal
model language which captures most 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
investorID
Register
1234
requestList
AAAA BBBB
payment
accountNum
56
stockID stockID
An XML Message<Register><investorID>1234</investorID><requestList><stockID>AAAA</stockID><stockID>BBBB</stockID></requestList><payment><accountNum>56</accountNum></payment></Register>
MSL Type Declaration
Register[ investorID[xsd:int] , requestList[ stockID[xsd:string]{1,50} ] , payment[ creditCardNum[xsd:int] | accountNum[xsd:int] ]]
<Register><investorID>1234</investorID><requestList><stockID>AAAA</stockID><stockID>BBBB</stockID></requestList><payment><accountNum>56</accountNum></payment></Register>
XPATH Queries
investorID
Register
1234
requestList
AAAA BBBB
payment
accountNum
56
stockID stockID
//payment/* returns the node labeled accountNum
/Register/requestList/stockID/string returns the nodes labeled AAAA and BBBB
//stockID[string=AAAA]/string returns the node labeled AAAA
The Guarded Automata Model
!r1?a1
?a2
!e
!r2
// XML Schema Type Decl.
request [ id [int]]
// messages r2: request
//local variableslast: request
Guard{ r2/id = last/id r2/id := last/id + 1}
Guarded Automata to Promela• Restrictions:
– Bound all the domains– Only ordered lists
• Map MSL types to Promela Type System
• Translate XPATH expressions to Promela
$request // stockID = $register // stockID [int()>5] [position() = last()]
$request // stockID = $register // stockID [int()>5] [position() = last()]
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
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]
• Verification of web services– Simulation, verification, composition of web services
[Narayanan, McIlraith WWW’02]
• Realizability problem– Realizability of Message Sequence Charts (MSC) [Alur,
Etassami, Yannakakis ICSE’00, ICALP’01]
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
Translatorfor bottom-upspecifications Guarded
automata Translation withbounded queue
SynchronizabilityAnalysis
Translation withsynchronous
communication
IntermediateRepresentation
ConversationProtocols
Front End
Realizability AnalysisGuarded
automaton
skip
Translatorfor top-downspecifications
success
fail
Translation withsingle process,
no communication
success
fail
Analysis Back End
BPEL
Web ServiceSpecificationLanguages
DAML-S
WSCI
Promela
SMV
ActionLanguage
VerificationLanguages
. . .
. . .
Aut
omat
ed
Abs
tract
ion
Current and Future Work