Tools for Automated Verification of
Web Services
Tevfik Bultan
Department of Computer Science
University of California, Santa Barbara
bultan@cs.ucsb.edu
Web Services
Interaction
BPEL4WS, WSCI
Service
WSDL
Message
SOAP
Type
XML Schema
Data
XML
Web Service Standards
Implementation Platforms
Loosely coupled
Standardized data transmission via XML
Asynchronous messaging
Platform independent (.NET, J2EE)
Microsoft .Net, Sun J2EE
•
•
•
•
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]
 P : finite set of peers
(web services)
Req1
Traveler
Agency
Booking2
 M : finite set of
message classes
Hotel
Req2
Booking1
Airline
Communication Model
• Reliable
• Asynchronous
• Queues are FIFO and unbounded
Agency
Req1 Airline
R2 R2
• This model is similar to industry efforts
– JMS (Java Message Service)
– MSMQ (Microsoft Message Queuing Service)
Message Classes
• Messages are classified into classes
• Each message class is associated with one sender and
one receiver
Agency
Req2
Airline
• 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
Finite State Peers
• Peer: Finite state automaton + one FIFO queue
• Extensions
– Reactive services: Büchi automata
– Message contents: Guarded automata
output
messages
input
messages
!Booking3
?Req3
[ Booking3.date
:= Req3.date ]
Airline
Executing Web Service Composition
! R1
? B1
Traveler
B1
? R1
! B1
? R2
! B2
! B1
! R2
R
B321
R2
? B2
? B3
Airline
! R3
? R3
Agency
! B3
R3
Hotel
Execution is a complete run if
• Each sent message is eventually consumed
• Each peer visits its final states infinitely often
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
R1
Traveler
B1
Agency
R2
Hotel
B2
Watcher
R 1 R2 B2 R3 B3 B 1
Airline
• 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)
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 S, is the language C(S)
always regular?
If it is regular, finite state model checking techniques can
be used for verification
Answer
Conversation Sets are not always regular, even without
message contents
Example: C(S) = { w | w  (r | a) and
for each prefix w’, |r|w’ |a|w’}
!r
?a
P1
r
?r
a
!a
P2
• Causes: asynchronous communication with
unbounded queues
• Bounded queues or synchronous communication
 Conversation Set always regular
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-Down
Bottom-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
msg1
Conversation
Schema
Peer A
msg2,
msg6
msg4
Peer B
msg3,
msg5
Peer C
BA:msg2 BC:msg5
Conversation
Protocol
AB:msg1
?
BA:msg6
BC:msg3
LTL property
G(msg1  F(msg3  msg5))
C B:msg4
(c)
Peer A
Peer B
!msg1
Peer C
?msg1
!msg3
Input
Queue
?msg3
!msg2
?msg2
!msg5
?msg6
Virtual Watcher
?msg5
?msg4
!msg4
!msg6
... ?
G(msg1  F(msg3  msg5))
LTL property
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
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: a
!a
?a
!b
?b
Peer A
Peer B
Peer C
Peer D
C  D: b
Conversation
protocol
Projection of the conversation
protocol to the peers
Conversation “ba” will be generated by any legal peer
implementation which follows the protocol
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
Skeleton is realizable,
but guarded protocol is not
Guarded protocol is realizable,
but its skeleton is not
.
D  B: d(1)
A  B: a(1)
C  D: c(2)
D  A: e(1)
C  D: c(1)
D  A: e(2)
D  B: d(2)
A  B: a(2)
A  B: a
c (1) a(2) is a conversation of the
projected peers
B  A: b
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
msg1
Conversation
Schema
Peer A
msg2,
msg6
msg4
Peer B
msg3,
msg5
Peer C
BA:msg2 BC:msg5
Conversation
Protocol
AB:msg1
?
BA:msg6
BC:msg3
LTL property
G(msg1  F(msg3  msg5))
C B:msg4
(c)
Peer A
Peer B
!msg1
Peer C
?msg1
!msg3
Input
Queue
?msg3
!msg2
?msg2
!msg5
?msg6
Virtual Watcher
?msg5
?msg4
!msg4
!msg6
... ?
G(msg1  F(msg3  msg5))
LTL property
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 , r2
!e
e
?a2
!r1
!r2
!a1
?a1
requester
?r2
?r1
!a2
?e
a1, a2
server
• Conversation set is regular: (r1a1 | r2a2)* e
• During all the executions queues are bounded
Example 2
?a1
!e
!r1
r 1 , r2
e
!r2
?a2
!a1
a1, a2
requester
• Conversation set is not regular
• Queues are not bounded
?r2
?r1
!a2
?e
server
Example 3
!r2
!r1 r , r
1 2
!e
?r
!a
e
?a
!r
requester
a1, a2
?r2
?e
server
• Conversation set is regular: (r1 | r2 | r a)* e
• Queues are not bounded
?r1
# of states in thousands
Three Examples
1600
1400
1200
1000
Example 1
Example 2
Example 3
800
600
400
200
13
11
9
7
5
3
1
0
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 S 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
Source
Name
#msg
ISSTA’04
SAS
9
CvSetup
4
MetaConv
4
IBM
Chat
2
Conv.
Buy
5
Support
Haggle
8
Project
AMAB
8
BPEL
shipping
2
Loan
6
spec
Auction
9
Collaxa. StarLoan
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
no
yes
yes
yes
yes
yes
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
Web Service Analysis Tool
Web
Services
BPEL
(bottom-up)
Front End
BPEL
to
GFSA
Analysis
Back End
Intermediate
Representation
Guarded
automata
GFSA to Promela
Synchronizability
Analysis
GFSA
parser
Guarded
automaton
(synchronous
communication)
GFSA to Promela
skip
Conversation
Protocol
(top-down)
Verification
Languages
(bounded queue)
Realizability
Analysis
fail
success 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 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
An XML Message
<Register>
<investorID>
1234
</investorID>
<requestList>
<stockID>
AAAA
</stockID>
<stockID>
BBBB
</stockID>
</requestList>
<payment>
<accountNum>
56
</accountNum>
</payment>
</Register>
Register
investorID
1234
requestList
payment
stockID stockID accountNum
AAAA
BBBB
56
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
Register
investorID
1234
requestList
payment
stockID stockID accountNum
AAAA
BBBB
56
//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
// XML Schema Type Decl.
?a1
!e
!r1
request [
id [int]
]
// messages
r2: request
?a2
!r2
Guard{
r2/id = last/id 
r2/id := last/id + 1
}
//local variables
last: request
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
Current and Future Work
Verification
Languages
Front End
BPEL
DAML-S
WSCI
Conversation
Protocols
...
Translator
for bottom-up
specifications
Translator
for top-down
specifications
Analysis
Back End
Intermediate
Representation
Guarded
automata
Guarded
automaton
Automated
Abstraction
Web Service
Specification
Languages
Synchronizability
Analysis
Translation with
synchronous
communication
Translation with
bounded queue
skip
Realizability
Analysis
fail
success Translation with
single process,
no communication
Promela
SMV
Action
Language
...