Analyzing Conversations of Web Services
Tevfik Bultan
Department of Computer Science
University of California, Santa Barbara
[email protected]
http://www.cs.ucsb.edu/~bultan
Joint work with
Xiang Fu, Georgia Southwestern State University
Jianwen Su, University of California, Santa Barbara
Going to Lunch at UCSB
• Before Xiang graduated from UCSB, Xiang, Jianwen and I
were using the following protocol for going to lunch:
– Sometime around noon one of us would call another
one by phone and tell him where and when we would
meet for lunch.
– The receiver of this first call would call the remaining
peer and pass the information.
• Let’s call this protocol the First Caller Decides (FCD)
protocol.
Implementation of the FCD Protocol
Tevfik
Xiang
Jianwen
!tj1
?jt2
!xj1
?jx2
!jt1
?tj2
!tx1
?xt2
!xt1
?tx2
!jx1
?xj2
?jt1
?xt1
?jx1
?tx1
?tj1
?xj1
!tx2
!tj2
!xt2
Message Labels:
from
Tevfik
!xj2
!
?
t x 1
to
Xiang
!jx2
1st
message
!jt2
send
receive
FCD Protocol does not Work with Voicemail
• When the university installed a voicemail system FCD
protocol started causing problems
– We were showing up at different restaurants at different
times!
• Example scenario: tx1, jx1, xj2
The messages jx1 and xj2 are not consumed
– Note that this scenario is not possible without
voicemail!
A Different Lunch Protocol
• Jianwen suggested that we change our lunch protocol as
follows:
– As the most senior researcher among us Jianwen
would make the first call to either Xiang or Tevfik and
tell when and where we would meet for lunch.
– Then, the receiver of this call would pass the
information to the other peer.
– Let’s call this protocol the Jianwen Decides (JD)
protocol
Implementation of the JD Protocol
Tevfik
?jt
!tx
?xt
Xiang
?jx
Jianwen
?tx
!xt
• JD protocol works fine with voicemail!
!jt
!jx
Conversation Protocols
• The FCD and JD protocols specify a set of conversations
• The implementations I showed are supposed to generate
the set of conversations specified by these protocols
• We can specify the set of conversations without showing
how the peers implement them, we call such a
specification a conversation protocol
FCD and JD Conversation Protocols
FCD Protocol
JD Protocol
jt
tx1
xj2
tj1
xt1
xj1
jt1
jx1
jx2
tj2
jt2
tx2
xt2
Conversation set:
{(tx1, xj2), (tj1, jx2), (xt1, tj2),
(xj1, jt2), (jt1, tx2), (jx1, xt2)}
tx
jx
xt
Conversation set:
{(jt, tx), (jx, xt)}
Observations & Questions
• The implementation of the FCD protocol behaves
differently with synchronous and asynchronous
communication whereas the implementation of the JD
protocol behaves the same.
– Can we find a way to identify such implementations?
• The implementation of the FCD protocol does not obey the
FCD protocol if asynchronous communication is used
whereas the implementation of the JD protocol obeys the
JD protocol even if asynchronous communication used.
– Given a conversation protocol can we figure out if there
is an implementation which generates the same
conversation set?
Synchronizability and Realizability Analyses
• We formalized these observations and questions using
synchronizability and realizability analyses
– The implementation of the JD protocol is
synchronizable but the implementation of the FCD
protocol is not synchronizable
– The JD protocol is realizable but the FCD protocol is
not realizable
Outline
• Web Service Composition Model
• Capturing Global Behaviors
– Conversations
• 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
Characteristics of Web Services
WS-CDL
Behavior
BPEL4WS
Interface
WSDL
Message
SOAP
Type
XML Schema
Data
XML
Web Service Standards
Implementation Platforms
Interaction
Microsoft .Net, Sun J2EE
• Loosely coupled, interaction through standardized
interfaces
• Standardized data transmission via XML
• Asynchronous messaging
• Platform independent (.NET, J2EE)
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 the XML messages?
– How do we verify properties related to data?
A Model for Composite Web Services
• A composite web service consists of
– a finite set of peers
• Lunch example: T, X, J
– and a finite set of message classes
• Lunch example (JD protocol): jt, tx, jx, xt
tx
Peer T
Peer X
xt
jt
jx
Peer J
Communication Model
• We assume that the messages among the peers are
exchanged using reliable and asynchronous messaging
– FIFO and unbounded message queues
Peer T
tx
tx
Peer X
• This model is similar to industry efforts such as
– JMS (Java Message Service)
– MSMQ (Microsoft Message Queuing Service)
Conversations
• A virtual watcher records the messages as they are sent
Peer T
tx
Peer X
Watcher
Peer J
jt
tx
• A conversation is a sequence of messages the
watcher sees during an execution
[Bultan, Fu, Hull, Su WWW’03]
Effects of Asynchronous Communication
• Question: Given a composite web service, is the set of
conversations a regular set?
• Even when messages do not have any content and the
peers are finite state machines the conversation set may
not be regular
• Reason: asynchronous communication with
unbounded queues
• Bounded queues or synchronous communication
 Conversation set always regular
Properties of Conversations
• The notion of conversation enables us to reason about
temporal properties of the composite web services
• 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 ( payment  F receipt )
• Model checking problem: Given an LTL property, does
the conversation set satisfy the property?
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
Conversation
Schema
tx
xt
Peer T
jt
Conversation
Protocol
jx
Peer J
jt
jx
?
tx
Peer T
?jt
Peer X
LTL property
GF(tx  xt))
xt
Peer J
Peer X
?xt
!jt
?jx
!jx
!tx
Virtual Watcher
?tx
Input
Queue
!xt
... ?
GF(tx  xt))
LTL property
Conversation Protocols
• Conversation Protocol:
– An automaton that accepts the desired conversation set
• A conversation protocol is a contract agreed by all peers
– Each peer must act according to the protocol
• For reactive protocols with infinite message sequences we
use:
– Büchi automata which accept infinite strings
• For specifying message contents, we use:
– Guarded automata
– Guards are constraints on the message contents
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 projected services
If this equality holds the conversation protocol is realizable
Are there conditions which ensure the equivalence?
Realizability Problem
• Not all conversation protocols are realizable!
AB: m1
!m1
?m1
!m2
?m2
CD: m2
Peer A
Conversation
protocol
Peer B
Peer C
Projection of the conversation
protocol to the peers
Conversation “m2 m1” will be generated by all peer
implementations which follow the protocol
Peer D
Another Non-Realizable Protocol
m1
A
B
m2
m3
B
BA: m2
m2
A
m1
B
m3
C
C
m2
m1
m3
A, C
AB: m1
Watcher
BA: m2
AB: m1
AC: m3
Generated conversation: m2 m1 m3
Realizability Conditions
Three sufficient conditions for realizability (no message
content) [Fu, Bultan, Su, CIAA’03, TCS’04]
• 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
– At any state, each peer should be able to do only one
of the following: send, receive or terminate
(a peer can still choose among multiple messages)
Realizability Conditions
• Following protocols fail one of the three conditions but
satisfy the other two
AB: m1
BA: m2
AB: m1
AB: m1
BA: m2
CD: m2
CA: m2
AB: m1
AC: m3
Not lossless
join
Not synchronous
compatible
Not autonomous
Bottom-Up Approach
• We know that analyzing conversations of composite web
services is difficult due to asynchronous communication
– Model checking for conversation properties is
undecidable even for finite state peers
• The question is:
– Can we identify the composite web services where
asynchronous communication does not create a
problem?
Three Examples, Example 1
r1, r2
!e
?a1
?a2
!r1 !r2
requester
e
a1, a2
!a1
!a2
?r1
?r2
?e
server
• Conversation set is regular: (r1a1 | r2a2)* e
• During all executions the message queues are bounded
Example 2
r1, r2
!e
?a1
?a2
!r1
!r2
e
a1, a2
requester
• Conversation set is not regular
• Queues are not bounded
!a1
!a2
?r1
?r2
?e
server
Example 3
!e !r
2
!r1
r1, r2
e
?a
!r
?r
!a
?r1
a1, a2
requester
?r2
?e
server
• Conversation set is regular: (r1 | r2 | ra)* e
• Queues are not bounded
# of states in thousands
State Spaces of the 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 is synchronizable, if its
conversation set does not change
– when asynchronous communication is replaced with
synchronous communication
• If a composite web service is synchronizable we can
check the properties about its conversations using
synchronous communication semantics
– For finite state peers this is a finite state model
checking problem
Synchronizability Analysis
• A composite web service is synchronizable, if it satisfies
the synchronous compatible and autonomous conditions
[Fu, Bultan, Su WWW’04, TSE]
• Connection between realizability and synchronizability:
– A conversation protocol is realizable if its projections to
peers are synchronizable and the protocol itself
satisfies the lossless join condition
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
Pass?
#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
Web Service Analysis Tool (WSAT)
Web
Services
Front End
BPEL
(bottom-up)
BPEL
to
GFSA
Analysis
Back End
Intermediate
Representation
Guarded
automata
GFSA to Promela
(synchronous
communication)
Synchronizability
Analysis
GFSA to Promela
skip
Conversation
Protocol
(top-down)
GFSA
parser
Guarded
automaton
Verification
Languages
(bounded queue)
Realizability
Analysis
success GFSA to Promela
fail
http://www.cs.ucsb.edu/~su/WSAT/
[Fu, Bultan, Su CAV’04]
(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 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
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]
• 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]
– BPEL verification using a process algebra model and
Concurrency Workbench [Koshkina, van Breugel TAVWEB’03]
– 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]
Current and Future Work
• Extending the source and target languages
• Symbolic analysis
[Fu, Bultan, Su ICWS’04, JWSR]
• Abstraction
• Design for verification for web services
[Betin-Can, Bultan WWW’05, ICWS’05]
Current and Future Work
Verification
Languages
Front End
BPEL
DAML-S
WS-CDL
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
...