Analyzing Conversations of Web Services

1
Analyzing Conversations of Web Services

• Tevfik Bultan
• Department of Computer Science
• University of California, Santa Barbara
• bultan_at_cs.ucsb.edu
• http//www.cs.ucsb.edu/bultan
• Joint work with
• Xiang Fu, Georgia Southwestern State University
• Jianwen Su, University of California, Santa
  Barbara

2
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.
• Lets call this protocol the First Caller Decides
  (FCD) protocol.

3
Implementation of the FCD Protocol
Tevfik
Xiang
Jianwen
!tj1
?jt2
!xj1
?jx2
!jt1
?tj2
!tx1
?xt2
!xt1
?tx2
!jx1
?xj2
?xt1
?jt1
?tx1
?jx1
?xj1
?tj1
!tx2
!tj2
!xt2
!xj2
!jx2
!jt2
! send ? receive
t x 1
Message Labels
from Tevfik
to Xiang
1st message
4
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!

5
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.
• Lets call this protocol the Jianwen Decides (JD)
  protocol

6
Implementation of the JD Protocol
Tevfik
Xiang
Jianwen
?xt
?tx
?jt
?jx
!jt
!jx
!tx
!xt

• JD protocol works fine with voicemail!

7
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

8
FCD and JD Conversation Protocols
FCD Protocol
JD Protocol
jt
jx
tj1
tx1
xt1
xj1
jt1
jx1
xj2
jx2
tj2
jt2
tx2
xt2
tx
xt
Conversation set (tx1, xj2), (tj1, jx2), (xt1,
tj2), (xj1, jt2), (jt1, tx2), (jx1, xt2)
Conversation set (jt, tx), (jx, xt)
9
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?

10
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

11
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

12
Characteristics of Web Services

• Loosely coupled, interaction through standardized
  interfaces
• Standardized data transmission via XML
• Asynchronous messaging
• Platform independent (.NET, J2EE)

WS-CDL
Interaction
BPEL4WS
Behavior
Interface
WSDL
Implementation Platforms
Microsoft .Net, Sun J2EE
SOAP
Message
XML Schema
Type
XML
Data
Web Service Standards
13
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?

14
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
jx
jt
Peer J
15
Communication Model

• We assume that the messages among the peers are
  exchanged using reliable and asynchronous
  messaging
• FIFO and unbounded message queues

Peer T
Peer X
tx
tx

• This model is similar to industry efforts such as
  
• JMS (Java Message Service)
• MSMQ (Microsoft Message Queuing Service)

16
Conversations

• A virtual watcher records the messages as they
  are sent

Peer T
Peer X
Watcher
tx
jt
Peer J

• A conversation is a sequence of messages the
  watcher sees during an execution
• Bultan, Fu, Hull, Su WWW03

17
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

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

19
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

20
tx
Conversation Schema
Peer T
Peer X
xt
Peer J
jt
jx
jt
jx
Conversation Protocol
LTL property
?
GF(tx ? xt))
tx
xt
Peer T
Peer X
Peer J
Input Queue
?xt
?tx
?jt
?jx
!jt
!jx
!tx
!xt
...
?
Virtual Watcher
LTL property
GF(tx ? xt))
21
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

22
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

23
Interesting Question

• If this equality holds the conversation protocol
  is realizable
• Are there conditions which ensure the
  equivalence?

?
Conversations generated by the projected services
Conversations specified by the conversation
protocol
?
24
Realizability Problem

• Not all conversation protocols are realizable!

A?B m1
C?D m2
Conversation protocol
Conversation m2 m1 will be generated by all
peer implementations which follow the protocol
25
Another Non-Realizable Protocol
m1
A
B
m2
A
m2
m2
m3
C
m1
m3
B
m1
B
A, C
C
A?B m1
B?A m2
m3
Watcher
B?A m2
m2 m1 m3
Generated conversation
A?B m1
A?C m3
26
Realizability Conditions

• Three sufficient conditions for realizability (no
  message content) Fu, Bultan, Su, CIAA03,
  TCS04
• 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)

27
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
A?B m1
C?D m2
C?A m2
A?C m3
Not lossless join
Not autonomous
Not synchronous compatible
28
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?

29
Three Examples, Example 1
!a1
!a2
r1, r2
!e
e
?r1
?r2
?a1
?a2
?e
a1, a2
!r2
!r1
requester
server

• Conversation set is regular (r1a1 r2a2) e
• During all executions the message queues are
  bounded

30
Example 2
!a1
!a2
r1, r2
!e
?a1
?a2
e
?r1
?r2
?e
!r2
!r1
a1, a2
requester
server

• Conversation set is not regular
• Queues are not bounded

31
Example 3
r1, r2
!e
!r1
!r2
?r
!a
e
?r1
?r2
?a
!r
a1, a2
?e
requester
server

• Conversation set is regular (r1 r2 ra) e
• Queues are not bounded

32
State Spaces of the Three Examples
of states in thousands
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

33
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

34
Synchronizability Analysis

• A composite web service is synchronizable, if it
  satisfies the synchronous compatible and
  autonomous conditions
• Fu, Bultan, Su WWW04, 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

35
Are These Conditions Too Restrictive?
36
Web Service Analysis Tool (WSAT)
Verification Languages
WebServices
Front End
Analysis
Back End
Intermediate Representation
GFSA to Promela (synchronous communication)
success
BPEL to GFSA
SynchronizabilityAnalysis
Guarded automata
BPEL
fail
(bottom-up)
GFSA to Promela (bounded queue)
Promela
skip
GFSA parser
Conversation Protocol
Guarded automaton
GFSA to Promela(single process, no
communication)
success
Realizability Analysis
fail
(top-down)
http//www.cs.ucsb.edu/su/WSAT/
Fu, Bultan, Su CAV04
37
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

38
Related Work

• Conversation specification
• IBM Conversation support project
  http//www.research.ibm.com/convsupport/
• Conversation support for business process
  integration Hanson, Nandi, Kumaran EDOCC02
• Orchestrating computations on the world-wide web
  Choi, Garg, Rai, Misram, Vin EuroPar02
• Realizability problem
• Realizability of Message Sequence Charts (MSC)
  Alur, Etassami, Yannakakis ICSE00, ICALP01

39
Related Work

• Verification of web services
• Simulation, verification, composition of web
  services using a Petri net model Narayanan,
  McIlraith WWW02
• BPEL verification using a process algebra model
  and Concurrency Workbench Koshkina, van Breugel
  TAV-WEB03
• Using MSC to model BPEL web services which are
  translated to labeled transition systems and
  verified using model checking Foster, Uchitel,
  Magee, Kramer ASE03
• Model checking Web Service Flow Language
  specifications using SPIN Nakajima ICWE04

40
Current and Future Work

• Extending the source and target languages
• Symbolic analysis
• Fu, Bultan, Su ICWS04, JWSR
• Abstraction
• Design for verification for web services
• Betin-Can, Bultan WWW05, ICWS05

41
Current and Future Work
Web Service Specification Languages
Verification Languages
Front End
Analysis
Back End
Intermediate Representation
BPEL
Translation with synchronous communication
success
Translator for bottom-up specifications
Promela
SynchronizabilityAnalysis
DAML-S
SMV
Guarded automata
fail
Translation with bounded queue
WS-CDL
Automated Abstraction
skip
ActionLanguage
Conversation Protocols
Translator for top-down specifications
. . .
Realizability Analysis
success
Translation withsingle process, no communication
Guarded automaton
. . .
fail