A Top-Down Approach to Modeling
Global Behaviors of Web Services
Xiang Fu, Tevfik Bultan and Jianwen Su
Department of Computer Science
University of California, Santa Barbara
{fuxiang,bultan,su}@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?
Outline
•
•
•
•
•
Web Service Composition Model
Capturing Global Behavior: Conversations
Bottom-Up vs. Top-Down Specification and Verification
Realizability Problem
Current and Future Work
Web Service Example
• A user accesses to the UpToTheMinuteNews.com
(U2MNews) web service using a Browser
• To access the U2MNews, user’s Browser has to traverse a
web proxy on the corporate firewall
• A company called Acme Web Speedup Services (AWS)
provides a caching proxy web service to speedup web
accesses
• The corporate IT starts using AWS caching service
• The user starts receiving stale pages from U2MNews
• We want to specify/model the following global property
– User’s Browser always receives the webpages (which
have U2MNews as the source) from the U2MNews web
service, not from the AWS
Web Service Composition
• A composite web service is a triple S = (M, P, C )
[Bultan, Fu, Hull, Su WWW’03]
 P : finite set of peers
(web services)
 M : finite set of
message classes
Req1
Browser
IT
Data1
 C : finite set of
channels
Data2
U2M
News
Req2
AWS
Cache
Communication Channels
• Reliable channels
• Asynchronous communication
• Queues are FIFO and unbounded
Browser
Req1
R1 D1
IT
• 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 channel
Browser
Req1
IT
• Modeling messages: Approach 1
– No message content
– Can model messages with content as long as domains
are finite
Message Contents
•
Modeling messages: Approach 2
– Message classes have attributes which carry the
contents of the messages
message
class
Message Req {
message
content
Message Data {
string url;
string url;
…
string src;
}
original
source
actual
source
bool nocache;
string data;
…
}
nocache
tag
Finite State Peers
• Peer: Finite state automaton + one FIFO queue
– Reactive services (infinite behavior): Büchi automata
– Message contents: Guarded Büchi automata
output
messages
input
messages
Req3
Data3
[ Data3.src
= “U2M”…]
U2M News
Executing Web Service Composition
! Req1
? Data1
D1
? Req1
Browser
! Data1
? Req2
! Data2
! Req2
R321
D
R2
? Data3
AWS Cache
? Data2
! Req3
? Req3
! Data3
! Data1
IT
R3
U2M News
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 Behavior: Conversations
Bottom-Up vs. Top-Down Specification and Verification
Realizability Problem
Current and Future Work
Conversations
• Watcher: “records” the messages as they are sent
Req1
Browser
IT
Data1
Req2
U2M
News
Data2
Watcher
R 1 R2 D2 R3 D3 D 1
AWS
Cache
• 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)
Specify System Goal Using LTL
• 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: The news is always up to date
G (Data1  Data1.src = Data1.url = “U2M”)
• 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  (a | b) and
for each prefix w’, |a|w’ |b|w’}
!a
?b
P1
a
?a
b
!b
P2
• Causes: asynchronous communication with
unbounded queues
• Bounded queues or synchronous: Conversation Set
always regular
Outline
•
•
•
•
•
Web Service Composition Model
Capturing Global Behavior: Conversations
Bottom-Up vs. Top-Down Specification and Verification
Realizability Problem
Current 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
Conversation Protocols
• Conversation Protocol:
– An automaton that accepts the desired conversation set
– Reactive protocols, infinite message sequences
• Büchi automaton
• Accepts infinite strings
– Message contents
• Guarded automaton
• 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
Browser
Req1
Data1
AWS
IT
U2M
System Goal
G (Data1  Data1.url = Data1.src= “U2M”)
B  IT: Req1
[ true  Req1’.url = “U2M” ]
IT  B: Data1
[ true  Data1’ = Data3 ]
IT  B: Data1
[ Data2.NoCache = false
 Data1’ = Data2 ]
IT  AWS: Req2
[ true  Req2’ = Req1 ]
U2M  IT: Data3
[ Req3.url = “U2M” 
Data3’.url = Data3’.src = “U2M”
 Data3’.NoCache = true]
AWS  IT: Data2
[ true  Data2’.url = Req2.url
 Data2’.src = “AWS”]
IT  U2M: Req3
[ Data2.NoCache = true
 Req3’ = Req1 ]
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
Browser
Req1,
Data1
AWS
IT
Preset System Goal
G (Data1  Data1.url = Data1.src= “U2M”)
U2M
B  IT: Req1
IT  B: Data1
[ true  Req1’.url = “U2M” ]
[ true  Data1’ = Data3 ]
Signed(“U2M”, Data) 
IT  B: Data1
Data.nocache = true
[ Data2.NoCache = false
 Data1’ = Data2 ]
IT  AWS: Req2
[ true  Req2’ = Req1 ]
Signed(Data2.url’, Data2’)
AWS might
falsify the
NoCache tag
U2M  IT: Data3
[ Req3.url = “U2M” 
Data3’.url = Data3’.src = “U2M”
 Data3’.NoCache = true]
AWS  IT: Data2
IT  U2M: Req3
[ true  Data2’.url = Req2.url
[ Data2.NoCache = true
 Data2’.src = “AWS”]
 Req3’ = Req1 ]
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
? Req2 IT
! Data1 B
? Req1 B
[ true 
Data1’ = Data3 ]
! Data2 IT
AWS
[true  Data2’.src = “AWS” 
Data2’.url = Req2.url  Signed(Data2’.url,Data2’) ]
! Req2 AWS
? Data3 U2M
[ true  Req2’ = Req1]
Signed(“U2M”,Data)  Data.NoCache = true
? Req3 IT
! Data3 IT
[ true  Data3’.url = Data3’.src = “U2M”
 Data3’. NoCache = true ]
? Data2 AWS
! Data1 B
U2M
! Req3 U2M
[ Data2.NoCache = false
[ Data2.NoCache = true
 Data1’ = Data2 ]
 Req3’ = Req1 ]
IT
! Req1 IT
[ true  Req1’.url = “U2M” ]
? Data1 IT
Browser
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?
Outline
•
•
•
•
•
Web Service Composition Model
Capturing Global Behavior: Conversations
Bottom-Up vs. Top-Down Specification and Verification
Realizability Problem
Current and Future Work
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
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 wait or to send 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
• Skeleton Approach: The fourth condition
– “unambiguous” property:
for each word w accepted by a projected peer:
there is one and only one w’ accepted by the
conversation protocol whose projection to that peer is w
• This extra condition might be too restrictive
– Skeleton of U2M protocol does not satisfy the fourth
condition
• 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
Current and Future Work
• More analysis tools are necessary for guarded protocols
with infinite domains
– Symbolic analysis
– Abstraction
• Tying the formal model to the web service standards
– Conversation protocols, peers: BPEL4WS
– Message contents: XML, XML Schema
– Guard conditions: XPath
• Tools for model checking web services
– Finite state vs. infinite-state
– Message contents, local variables
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]
Our Previous Work
• Verification of Vortex workflows [Fu, Bultan, Hull, Su TACAS’01]
– Restrict to finite domains, use SMV
• Formal verification of e-services and workflows [Fu, Bultan,
Hull, Su WES’01]
– Infinite domains, use Action Language Verifier
• Conversations specification [Bultan, Fu, Hull, Su WWW’01]
– A formalism for specification of composite e-services
• Conversation protocols [Fu, Bultan, Su CIAA’03]
– Realizability conditions, model checking