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