1. 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

2. Web Services Loosely coupled Standardized data transmission via XML Asynchronous messaging Platform independent (.NET, J2EE) Data Type Service Interaction Message BPEL4WS, WSCI Web Service Standards Implementation Platforms Microsoft.Net, Sun J2EE WSDL SOAP XML Schema XML

3. 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?

4. Outline Web Service Composition Model Capturing Global Behavior: Conversations Bottom-Up vs. Top-Down Specification and Verification Realizability Problem Current and Future Work

5. 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

6. 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 BrowserIT U2M News AWS Cache Req 1 Data 1 Req 3 Req 2 Data 3 Data 2

7. Communication Channels Reliable channels Asynchronous communication Queues are FIFO and unbounded IT B rowser Req 1 Similar to industry efforts –JMS (Java Message Service) –MSMQ (Microsoft Message Queuing Service) D1D1 R1R1

8. 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 IT B rowser Req 1

9. 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

10. 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 Req 3 Data 3 [ Data 3.src = “U2M”…] input messages output messages

11. 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 ? Req 1 ! Req 2 ! Data 1 ? Data 2 ! Data 1 ! Req 3 ? Data 3 R1R1 R2R2 ! Req 1 ? Data 1 Browser D1D1 ? Req 2 ! Data 2 AWS Cache D2D2 ? Req 3 ! Data 3 U2M News R3R3 D3D3

12. Outline Web Service Composition Model Capturing Global Behavior: Conversations Bottom-Up vs. Top-Down Specification and Verification Realizability Problem Current and Future Work

13. Conversations Watcher: “records” the messages as they are sent Watcher AWS Cache U2M News Browser IT Req 1 Data 1 R1R1 R2R2 D2D2 D3D3 R3R3 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) D1D1 Req 3 Data 3 Data 2 Req 2

14. 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 (Data 1  Data 1.src = Data 1.url = “U2M”) Model checking problem: Given an LTL property, does the conversation set C(S) satisfy the property?

15. Question SGiven 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

16. 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?b!a!a P1P1 P2P2 ?a !b a b

17. Outline Web Service Composition Model Capturing Global Behavior: Conversations Bottom-Up vs. Top-Down Specification and Verification Realizability Problem Current and Future Work

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

19. 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

20. B rowser IT U2M AWS Req 1 Data 1 U2M  IT: Data 3 [ Req 3.url = “U2M”  Data 3 ’.url = Data 3 ’.src = “U2M”  Data 3 ’.NoCache = true] G (Data 1  Data 1.url = Data 1.src= “U2M”) Req 2 Data 2 Req 3 Data 3 System Goal B  IT: Req 1 [ true  Req 1 ’.url = “U2M” ] IT  AWS: Req 2 [ true  Req 2 ’ = Req 1 ] AWS  IT: Data 2 [ true  Data 2 ’.url = Req 2. url  Data 2 ’.src = “AWS”] IT  U2M: Req 3 [ Data 2.NoCache = true  Req 3 ’ = Req 1 ] IT  B: Data 1 [ true  Data 1 ’ = Data 3 ] IT  B: Data 1 [ Data 2.NoCache = false  Data 1 ’ = Data 2 ]

21. 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

22. B rowser IT U2M AWS Req 1, Data 1 U2M  IT: Data 3 [ Req 3.url = “U2M”  Data 3 ’.url = Data 3 ’.src = “U2M”  Data 3 ’.NoCache = true] G (Data 1  Data 1.url = Data 1.src= “U2M”) Req 2, Data 2 Req 3, Data 3 Preset System Goal B  IT: Req 1 [ true  Req 1 ’.url = “U2M” ] IT  AWS: Req 2 [ true  Req 2 ’ = Req 1 ] AWS  IT: Data 2 [ true  Data 2 ’.url = Req 2. url  Data 2 ’.src = “AWS”] IT  U2M: Req 3 [ Data 2.NoCache = true  Req 3 ’ = Req 1 ] IT  B: Data 1 [ true  Data 1 ’ = Data 3 ] IT  B: Data 1 [ Data 2.NoCache = false  Data 1 ’ = Data 2 ] AWS might falsify the NoCache tag Signed(Data 2.url’, Data 2 ’) Signed(“U2M”, Data)  Data.nocache = true

23. 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

24. AWS [true  Data 2 ’.src = “AWS”  Data 2 ’.url = Req 2.url  Signed(Data 2 ’.url,Data 2 ’) ] ? Req 2  IT ! Data 2  IT U2M [ true  Data 3 ’.url = Data 3 ’.src = “U2M”  Data 3 ’. NoCache = true ] ? Req 3  IT ! D ata 3  IT Browser ? D ata 1  IT [ true  Req 1 ’.url = “U2M” ] ? Req 1  B [ true  Req 2 ’ = Req 1 ] ? Data 2  AWS [ Data 2.NoCache = true  Req 3 ’ = Req 1 ] ! Data 1  B [ Data 2.NoCache = false  Data 1 ’ = Data 2 ] ? Data 3  U2M IT ! Req 1  IT Signed(“U2M”,Data)  Data.NoCache = true [ true  Data 1 ’ = Data 3 ] ! Req 3  U2M! Data 1  B ! Req 2  AWS

25. 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  ?

26. Outline Web Service Composition Model Capturing Global Behavior: Conversations Bottom-Up vs. Top-Down Specification and Verification Realizability Problem Current and Future Work

27. Realizability Problem Not all conversation protocols are realizable! A  B: a C  D: b Conversation protocol ! a ? a ! b ? b Peer APeer BPeer CPeer D ba Conversation “ba” will be generated by any legal peer implementation which follows the protocol

28. 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

29. 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.

30. 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: aB  A: b Skeleton is realizable, but guarded protocol is not Guarded protocol is realizable, but its skeleton is not

31. 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

32. 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

33. Related Work Conversation specification –IBM Conversation support project http://www.research.ibm.com/convsupport/ 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]

34. 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