Tools for Automated Verification of Web Services

1
Tools for Automated Verification of Web Services

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• bultan_at_cs.ucsb.edu

2
Web Services

• Loosely coupled
• Standardized data transmission via XML
• Asynchronous messaging
• Platform independent (.NET, J2EE)

Interaction
BPEL4WS, WSCI
WSDL
Service
SOAP
Implementation Platforms
Message
Microsoft .Net, Sun J2EE
XML Schema
Type
XML
Data
Web Service Standards
3
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?

4
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
5
Web Service Composition

• A composite web service is a tuple S ( P, M )
• Bultan, Fu, Hull, Su WWW03

• P finite set of peers(web services)

Req1
Traveler
Agency
Booking1

• M finite set of message classes

Req3
Req2
Booking2
Booking3
Hotel
Airline
6
Communication Model

• Reliable
• Asynchronous
• Queues are FIFO and unbounded

Airline
Agency
Req1

• This model is similar to industry efforts
• JMS (Java Message Service)
• MSMQ (Microsoft Message Queuing Service)

7
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

Airline
Agency
Req2
8
Finite State Peers

• Peer Finite state automaton one FIFO queue
• Extensions
• Reactive services Büchi automata
• Message contents Guarded automata

outputmessages
inputmessages
!Booking3
?Req3
Booking3.date Req3.date
Airline
9
Executing Web Service Composition
! R1
B1
? R1
? B1
Traveler
! R2
! B1
! B1
? R2
R1
B2
B3
R2
! B2
? 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

10
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

11
Conversations

• Watcher records the messages as they are sent

R1
Agency
Traveler
B1
Watcher
R2
R1
R2
B2
B3
R3
B1
Hotel
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)

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

13
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

14
Answer

• Conversation Sets are not always regular, even
  without message contents

Example C(S) w w ? (r a)? and
for each prefix w, rw? aw
r
?r
?a
!r
a
!a
P1
P2

• Causes asynchronous communication with unbounded
  queues
• Bounded queues or synchronous communication
• ? Conversation Set always regular

15
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

16
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

17
msg1
msg4
Peer A
Peer B
Peer C
Conversation Schema
msg2, msg6
msg3, msg5
LTL property
B?Amsg2
B?Cmsg5
?
Conversation Protocol
G(msg1 ? F(msg3 ? msg5))
A?Bmsg1
B?Amsg6
B?Cmsg3
C? Bmsg4
(c)
Peer A
Peer B
Peer C
?msg1
!msg1
Input Queue
!msg3
?msg3
!msg2
?msg2
!msg5
?msg5
?msg4
!msg4
?msg6
!msg6
...
?
Virtual Watcher
G(msg1 ? F(msg3 ? msg5))
LTL property
18
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

19
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

20
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

21
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
?
22
Realizability Problem

• Not all conversation protocols are realizable!

A ? B a
! a
! b
? b
? a
C ? D b
Peer A
Peer B
Peer C
Peer D
Conversation protocol
Projection of the conversation protocol to the
peers
Conversation ba will be generated by any legal
peer implementation which follows the protocol
23
Realizability Problem

• Three sufficient conditions for realizability
  (contentless messages) Fu, Bultan, Su, CIAA03
• 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

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

25
Examples
Skeleton is realizable, but guarded protocol is
not
Guarded protocol is realizable, but its skeleton
is not
.
D ? B d(1)
D ? A e(2)
A ? B a(1)
C ? D c(2)
D ? B d(2)
D ? A e(1)
C ? D c(1)
A ? B a(2)
A ? B a
B ? A b
c (1) a(2) is a conversation of the projected
peers
26
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

27
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

28
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

29
msg1
msg4
Peer A
Peer B
Peer C
Conversation Schema
msg2, msg6
msg3, msg5
LTL property
B?Amsg2
B?Cmsg5
?
Conversation Protocol
G(msg1 ? F(msg3 ? msg5))
A?Bmsg1
B?Amsg6
B?Cmsg3
C? Bmsg4
(c)
Peer A
Peer B
Peer C
?msg1
!msg1
Input Queue
!msg3
?msg3
!msg2
?msg2
!msg5
?msg5
?msg4
!msg4
?msg6
!msg6
...
?
Virtual Watcher
G(msg1 ? F(msg3 ? msg5))
LTL property
30
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?

31
Three Examples, Example 1
!a1
?r2
r1, r2
!e
?r1
!a2
e
?a2
!r1
?e
a1, a2
!r2
?a1
requester
server

• Conversation set is regular (r1a1 r2a2) e
• During all the executions queues are bounded

32
Example 2
!r1
?a1
r1, r2
!e
e
a1, a2
!r2
?a2
requester
server

• Conversation set is not regular
• Queues are not bounded

33
Example 3
!r2
!r1
r1, r2
!e
?r
!a
e
!r
?a
a1, a2
?r1
?r2
?e
requester
server

• Conversation set is regular (r1 r2 r a) e
• Queues are not bounded

34
Three Examples
of states in thousands
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

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

36
Are These Conditions Too Restrictive?
37
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

38
Web Service Analysis Tool
Verification Languages
WebServices
Front End
Analysis
Back End
Intermediate Representation
GFSA to Promela (synchronous communication)
success
BPEL to GFSA
SynchronizabilityAnalysis
Guarded automata
BPEL
fail
(bottom-up)
GFSA to Promela (bounded queue)
Promela
skip
GFSA parser
Conversation Protocol
Guarded automaton
GFSA to Promela(single process, no
communication)
success
Realizability Analysis
fail
(top-down)
39
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

40
An XML Message
ltRegistergt ltinvestorIDgt 1234 lt/investorIDgt ltreques
tListgt ltstockIDgt AAAA lt/stockIDgt ltstockIDgt BBBB lt/
stockIDgt lt/requestListgt ltpaymentgt ltaccountNumgt 56
lt/accountNumgt lt/paymentgt lt/Registergt
41
MSL Type Declaration
ltRegistergt ltinvestorIDgt 1234 lt/investorIDgt ltreques
tListgt ltstockIDgt AAAA lt/stockIDgt ltstockIDgt BBBB lt/
stockIDgt lt/requestListgt ltpaymentgt ltaccountNumgt 56
lt/accountNumgt lt/paymentgt lt/Registergt
Register investorIDxsdint , requestList
stockIDxsdstring1,50 , payment
creditCardNumxsdint accountNumxsdint

42
XPATH Queries
//payment/ returns the node labeled
accountNum /Register/requestList/stockID/string
returns the nodes labeled AAAA and
BBBB //stockIDstringAAAA/string returns the
node labeled AAAA
43
The Guarded Automata Model
// XML Schema Type Decl. request id
int // messages r2 request //local
variables last request
!r1
?a1
!e
?a2
!r2
Guard r2/id last/id ? r2/id last/id
1
44
Guarded Automata to Promela

• Restrictions
• Bound all the domains
• Only ordered lists
• Map MSL types to Promela Type System
• Translate XPATH expressions to Promela

45
request // stockID register // stockID
int()gt5 position() last()
46
request // stockID register // stockID
int()gt5 position() last()
47
Model Checking Using Promela

• Subtle errors in an example
• SAS Stock Analysis Service Fu, Bultan, Su
  ISSTA04
• 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

48
Related Work

• Conversation specification
• IBM Conversation support project
  http//www.research.ibm.com/convsupport/
• Conversation support for business process
  integration Hanson, Nandi, Kumaran EDOCC02
• Orchestrating computations on the world-wide web
  Choi, Garg, Rai, Misram, Vin EuroPar02
• Verification of web services
• Simulation, verification, composition of web
  services Narayanan, McIlraith WWW02
• Realizability problem
• Realizability of Message Sequence Charts (MSC)
  Alur, Etassami, Yannakakis ICSE00, ICALP01

49
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

50
Current and Future Work
Web Service Specification Languages
Verification Languages
Front End
Analysis
Back End
Intermediate Representation
BPEL
Translation with synchronous communication
success
Translator for bottom-up specifications
Promela
SynchronizabilityAnalysis
DAML-S
SMV
Guarded automata
fail
Translation with bounded queue
WSCI
Automated Abstraction
skip
ActionLanguage
Conversation Protocols
Translator for top-down specifications
. . .
Realizability Analysis
success
Translation withsingle process, no communication
Guarded automaton
. . .
fail