WSAT A Tool for Formal Analysis of Web Services

1
WSATA Tool for Formal Analysis of Web Services

• Xiang Fu Tevfik Bultan Jianwen Su
• Department of Computer Science
• University of California, Santa Barbara
• fuxiang,bultan,su_at_cs.ucsb.edu

2
Web Services

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

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

4
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

5
Composite Web Services
Investor
Stock Broker Firm
?register
!register
?reject
!reject
!accept
?accept
!request
!ack
acc
rep
bil
?report
?ack
reg
ack
!bill
?bill
?cancel
!cancel
?bill
!bill
!terminate
Research Dept.
!report
?request
req
ter
Watcher
?terminate
rep
acc
bil
reg
ack
req
ter
6
Conversation Protocols

• A conversation is a sequence of messages the
  watcher sees during an execution Bultan, Fu,
  Hull, Su WWW03
• Conversation Protocol An automaton that accepts
  the desired conversation set

SAS conversation protocol
report
ack
1
6
7
8
register
request
cancel
ack
request
reject
accept
bill
2
3
5
9
report
terminate
4
10
12
11
bill
cancel
terminate
7
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
Composite Web Service
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
8
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
?
9
Realizability Problem

• Not all conversation protocols are realizable!

A ? B m1
!m2
?m2
?m1
!m1
C ? D m2
Peer A
Peer B
Peer C
Peer D
Conversation protocol
Projection of the conversation protocol to the
peers
Conversation m2 m1 will be generated by any
legal peer implementation which follows the
protocol
This protocol fails Lossless join condition
10
Another Non-Realizable Protocol
m1
A
B
A
m2
m2
m3
C
B
m1
B
A, C
C
m3
A ? B m1
B ? A m2
Watcher
B ? A m2
A ? B m1
m1
m2
m3
A ? C m3
This protocol fails Autonomous condition
11
Yet Another Non-Realizable Protocol
m1
A
B
A
m2
m2
C
B
m1
C
A ? B m1
Watcher
C ? A m2
m1
m2
This protocol fails Synchronous compatible
condition
12
Realizability Problem

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

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

14
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

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

• Conversation set is not regular
• Queues are not bounded

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

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

17
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

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

19
Are These Conditions Too Restrictive?
20
Web Service Analysis Tool (WSAT)
Verification Languages
Web Services
Front End
Analysis
Back End
Intermediate Representation
GFSA to Promela (synchronous communication)
success
BPEL to GFSA
Synchronizability Analysis
BPEL
Guarded automata
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)

• Demonstration Saturday
• or anytime you find me with my laptop

21
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

22
SAS Guarded Automata
Topdown Schema PeerList Investor, Broker,
ResearchDept , TypeList Register ... Accept
... , MessageList register Investor -gt
Broker Register , accept Broker -gt
Investor Accept , ... , GProtocol
States s1,s2,s3,s4,s5,s6,s7,s8,s9,s10,s11,s12
, InitialState s1 , FinalStates s4 ,
TransitionRelation t1 s1 -gt s2 register,
Guard true , t2 s2 -gt s5 accept,
Guard true gt accept//orderID
register//orderID , ...
23
An XML Document and Its Tree
ltRegistergt ltinvestorIDgt VIP01 lt/investorIDgt ltreque
stListgt ltstockIDgt 0001 lt/stockIDgt ltstockIDgt 0002 lt
/stockIDgt lt/requestListgt ltpaymentgt ltaccountNumgt 04
25 lt/accountNumgt lt/paymentgt lt/Registergt
24
An MSL Type Declaration and an Instance
ltRegistergt ltinvestorIDgt VIP01 lt/investorIDgt ltreque
stListgt ltstockIDgt 0001 lt/stockIDgt ltstockIDgt 0002 lt
/stockIDgt lt/requestListgt ltpaymentgt ltaccountNumgt 04
25 lt/accountNumgt lt/paymentgt lt/Registergt
Register investorIDstring , requestList
stockIDint1,3 , payment
creditCardNumint accountNumint
25
MSL to Promela Example
typedef t1_investorID mtype
stringvalue typedef t2_stockIDint
intvalue typedef t3_requestList t2_stockID
stockID 3 int stockID_occ typedef
t4_accountNumint intvalue typedef
t5_creditCardint 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
Register investorIDstring , requestList
stockIDint1,3 , payment
creditCardNumint accountNumint
26
XPath Expressions
//payment/ returns the node labeled
accountNum /Register/requestList/stockID/int
returns the nodes labeled 0001 and
0002 //stockIDint gt 1/int returns the node
labeled 0002
27
XPath to Promela
register // stockID / int()gt5 / position()
last() / int()
EMPTY
1
FOR (i1,1,3)
IF (i2i3)
5
EMPTY
5
5
6
Sequence
cond ? v_register.requestlist.stockIDi1 gt 5
Insert
28
request//stockIDregister//stockIDint()gt5posi
tion()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 i21 / pre-calculate
the value of last(), store in i3 / i40 i51
i30 do i4 lt v_register.requestList.stockID_
occ -gt / compute first predicate /
bRes3 false if v_register.requestList.
stockIDi4.intvaluegt5 -gt bRes3 true
else -gt skip fi if bRes3 -gt i5
i3 else -gt skip fi i4 else
-gt break od
29
request//stockIDregister//stockIDint()gt5posi
tion()last()
i10 do i1 lt v_register.requestList.stockID
_occ -gt bRes1 false if
v_register.requestList.stockIDi1.intvaluegt5 -gt
bRes1 true else -gt skip fi if
bRes1 -gt bRes2 false if
(i2 i3) -gt bRes2 true else -gt
skip fi if bRes2 -gt
if (v_request.stockID.intvalue
v_register.requestList.stockIDi
1.intvalue) -gt bResult true
else -gt skip fi else -gt
skip fi i2 else -gt skip
fi i1 else -gt break od
30
Model Checking Using Promela

• Error in SAS conversation protocol
• t14 s8 -gt s12 bill,
• Guard
• request//stockID register//stockID
  position() last()
• gt
• bill //orderID register//orderID
• Repeating stockID will cause error
• One can only discover these kinds of errors by
  analysis of XPath expressions

31
Related Work

• Conversation specification
• IBM Conversation support project
  http//www.research.ibm.com/convsupport/
• Conversation support for business process
  integration Hanson, Nandi, Kumaran EDOCC02
• Realizability problem
• Realizability of Message Sequence Charts (MSC)
  Alur, Etassami, Yannakakis ICSE00, ICALP01

32
Related Work

• Verification of web services
• Simulation, verification, composition of web
  services using a Petri net model Narayanan,
  McIlraith WWW02
• Using MSC to model BPEL web services which are
  translated to labeled transition systems and
  verified using model checking Foster, Uchitel,
  Magee, Kramer ASE03
• Model checking Web Service Flow Language
  specifications using SPIN Nakajima ICWE04
• BPEL verification using a process algebra model
  and Concurrency Workbench Koshkina, van Breugel
  TAV-WEB04

33
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

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