a top-down approach to modeling global behaviors of web services
DESCRIPTION
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. Loosely coupled Standardized data transmission via XML - PowerPoint PPT PresentationTRANSCRIPT
A Top-Down Approach to Modeling Global Behaviors of Web Services
Xiang Fu, Tevfik Bultan and Jianwen Su
Department of Computer ScienceUniversity of California, Santa Barbara
{fuxiang,bultan,su}@cs.ucsb.edu
Web Services
• Loosely coupled • Standardized data transmission via XML• Asynchronous messaging• Platform independent (.NET, J2EE)
Data
Type
Service
Interaction
Message
BPEL4WS, WSCI
Web Service StandardsIm
plem
enta
tion
Pla
tfor
ms
Mic
roso
ft .
Net
, S
un J
2EE
WSDL
SOAP
XML Schema
XML
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]
M : finite set of message classes
P : finite set of peers(web services)
C : finite set of channels
Browser IT
U2MNews
AWSCache
Req1
Data1
Req 3 Req2
Data 3
Data2
Communication Channels
• Reliable channels• Asynchronous communication• Queues are FIFO and unbounded
ITBrowserReq1
• Similar to industry efforts
– JMS (Java Message Service)
– MSMQ (Microsoft Message Queuing Service)
D1R1
Message Classes
• Messages are classified into classes • Each message class is associated with one channel
• Modeling messages: Approach 1– No message content– Can model messages with content as long as domains
are finite
ITBrowserReq1
Message Contents
• Modeling messages: Approach 2– Message classes have attributes which carry the
contents of the messages
Message Req {
string url;
…
}
Message Data {
string url;
string src;
bool nocache;
string data;
…
}
original source
actual source
nocache tag
message class
message content
Finite State Peers
• Peer: Finite state automaton + one FIFO queue– Reactive services (infinite behavior): Büchi automata – Message contents: Guarded Büchi automata
U2M News
Req3
Data3
[ Data3.src
= “U2M”…]
inputmessages
outputmessages
Executing Web Service Composition
Execution is a complete run if• Each sent message is eventually consumed • Each peer visits its final states infinitely often
IT
? Req1
! Req2! Data1
? Data2
! Data1
! Req3
? Data3
R1
R2
! Req1
? Data1
Browser
D1
? Req2
! Data2
AWS Cache
D2
? Req3
! Data3
U2M News
R3
D3
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
Watcher
AWSCache
U2MNews
Browser IT
Req1
Data1
R1 R2 D2 D3R3
• 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)
D1
Req 3
Data 3
Data2Req2
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 contentsExample: 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 SS, is the language C(S) always regular?
If it is regular, finite state model checking techniques can be used for verification
Example: C(S) = { w | w (a | b) and
for each prefix w’, |a|w’ |b|w’}
Answer
Conversation Sets are not always regular, even without message contents
• Causes: asynchronous communication with unbounded queues
• Bounded queues or synchronous: Conversation Set always regular
?b!a
P1 P2
?a
!b
a
b
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 IT
U2M
AWSReq1
Data1
U2M IT: Data3
[ Req3.url = “U2M”
Data3’.url = Data3’.src = “U2M”
Data3’.NoCache = true]
G (Data1 Data1.url = Data1.src= “U2M”)
Req2
Data2
Req3 Data3
System Goal
B IT: Req1
[ true Req1’.url = “U2M” ]
IT AWS: Req2
[ true Req2’ = Req1 ]
AWS IT: Data2
[ true Data2’.url = Req2.url
Data2’.src = “AWS”]
IT U2M: Req3
[ Data2.NoCache = true
Req3’ = Req1 ]
IT B: Data1
[ true Data1’ = Data3 ]
IT B: Data1
[ Data2.NoCache = false
Data1’ = Data2 ]
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 IT
U2M
AWSReq1,Data1
U2M IT: Data3
[ Req3.url = “U2M”
Data3’.url = Data3’.src = “U2M”
Data3’.NoCache = true]
G (Data1 Data1.url = Data1.src= “U2M”)
Req2,D
ata2
Req3,Data3
Preset System Goal
B IT: Req1
[ true Req1’.url = “U2M” ]
IT AWS: Req2
[ true Req2’ = Req1 ]
AWS IT: Data2
[ true Data2’.url = Req2.url
Data2’.src = “AWS”]
IT U2M: Req3
[ Data2.NoCache = true
Req3’ = Req1 ]
IT B: Data1
[ true Data1’ = Data3 ]
IT B: Data1
[ Data2.NoCache = false
Data1’ = Data2 ]
AWS might AWS might falsify the falsify the
NoCache tagNoCache tag
Signed(Data2.url’, Data2’)
Signed(“U2M”, Data)
Data.nocache = true
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
AWSAWS [true Data2’.src = “AWS” Data2’.url = Req2.url Signed(Data2’.url,Data2’) ]
? Req2 IT
! Data2 IT
U2MU2M
[ true Data3’.url = Data3’.src = “U2M” Data3’. NoCache = true ]
? Req3 IT
! Data3 IT
BrowserBrowser? Data1 IT
[ true Req1’.url = “U2M” ]
? Req1 B
[ true Req2’ = Req1]
? Data2 AWS
[ Data2.NoCache = true
Req3’ = Req1 ]
! Data1 B
[ Data2.NoCache = false
Data1’ = Data2 ]
? Data3 U2M
ITIT
! Req1 IT
Signed(“U2M”,Data) Data.NoCache = true
[ true Data1’ = Data3 ]
! Req3 U2M! Data1 B
! Req2 AWS
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
?
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
C D: b
Conversation protocol
! a ? a ! b ? b
Peer A Peer B Peer C Peer D
Conversation “baba” 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
A B: a(1)
C D: c(1)
C D: c(2)
A B: a(2)
.
c (1) a(2) is a conversation of the projected peers
D B: d(1) D A: e(2)
D B: d(2)D A: e(1)
A B: a B A: b
Skeleton is realizable,but guarded protocol is not
Guarded protocol is realizable, but its skeleton is not
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