Analyzing Interactions of
Asynchronously Communicating
Systems
Tevfik Bultan
Department of Computer Science
University of California, Santa Barbara
bultan@cs.ucsb.edu
http://www.cs.ucsb.edu/~bultan
University of California at Santa Barbara
Acknowledgements
• Joint work with
– Xiang Fu, Hofstra University
– Jianwen Su, University of California, Santa Barbara
– Zachary Stengel, Microsoft
– Samik Basu, Iowa State
Motivation 1: Web Services
• Web services support basic client/server style interactions
WSDL
Request
Service
Requester
Client
SOAP
Response
Service
Provider
Server
• Example: Amazon E-Commerce Web Service (AWS-ECS)
• AWS-ECS WSDL specification lists 40 operations that provide differing
ways of browsing Amazon’s product database such as
– ItemSearch, CartCreate, CartAdd, CartModify, CartGet, CartClear
• Based on the AWS-ECS WSDL specification one can implement
clients that interact with AWS-ECS
Composing Services
• Can this framework support more than basic client/server style
interactions?
• Can we compose a set of services to construct a new service?
• For example:
– If we are building a bookstore service, we may want to use both
Amazon’s service and Barnes & Noble’s service in order to get
better prices
• Another (well-known) example:
– A travel agency service that uses other services (such as flight
reservation, hotel reservation, and car rental services) to help
customers book their trips
Orchestration vs Choreography
Orchestration: Define an executable process that interacts with existing
services and executes them in a particular order and combines the
results to achieve a new goal
– From atomic services to stateful services
– Web Services Business Process Execution Language (WS-BPEL)
Choreography: Specify how the individual services should interact with
each other. Find or construct individual services that follow this
interaction specification
– Global specification of interactions among services
– Web Services Choreography Description Language (WS-CDL)
A choreography can be realized by writing an orchestration for each peer
involved in the choreography
– Choreography as global behavior specification
– Orchestration as local behavior specification that realizes the
global specification
Web Services Standards Stack
Choreography
Web Services Choreography Description Language (WS-CDL)
Orchestration
Service
Web Services Business Process Execution Language (WS-BPEL)
Web Services Description Language (WSDL)
Simple Object Access Protocol (SOAP)
Protocol
Type
XML Schema (XSD)
Extensible Markup Language (XML)
Data
WSDL
WS-BPEL
SOAP
Atomic
Service
Orchestrated
Service
SOAP
SOAP
WS-CDL
WS-BPEL
Orchestrated
Service
WSDL
SOAP
SOAP
Atomic
Service
Asynchronous Messaging
• Sender does not have to wait for the receiver
– Message is inserted to a message queue
– Messaging platform guarantees the delivery of the message
• Why support asynchronous messaging?
– Otherwise the sender has to block and wait for the receiver
– Sender may not need any data to be returned
– If the sender needs some data to be returned, it should only wait
when it needs to use that data
– Asynchronous messaging can alleviate the latency of message
transmission through the Internet
– Asynchronous messaging can prevent sender from blocking if the
receiver service is temporarily unavailable
• Rather then creating a thread to handle the send, use
asynchronous messaging
Motivation 2: Singularity OS
• Experimental OS developed by Microsoft Research to explore new
ideas for operating system design
• Key design principles:
– Dependability
– Security
• Key architectural decision:
– Implement a sealed process system
• Software Isolated Processes (SIPs)
– Closed code space (no dynamic code loading or code generation)
– Closed object space (no shared memory)
• Inter-process communication occurs via message passing over
channels
Singularity Channels
• Channels allow 2-Party asynchronous communication via FIFO
message queues
– Sends are non blocking
– Receives block until a message is at the head of a receive queue
• Each channel has exactly two endpoints
– Type exposed for each endpoint (Exp and Imp)
– Each endpoint owned by at most one process at any time
• Owner of Exp referred to as Server
• Owner of Imp referred to as Client
Channel Contracts
• Written in Sing #
• Contracts specify two things:
1. The messages that may be sent
over a channel
• out message are sent from the
Server endpoint to the Client
endpoint (SC)
• in messages are sent from the
Client endpoint to the Server
endpoint (CS)
public contract KeyboardDeviceContract {
out message AckKey( uint key );
out message NakKey();
out message Success();
in message GetKey();
in message PollKey();
state Start {
Success! -> Ready;
}
state Ready {
GetKey? -> Waiting;
PollKey? -> (AckKey! or NakKey!)
-> Ready;
}
2. The set of allowed message
sequences
• out message marked with !
• in messages marked with ?
state Waiting {
AckKey! -> Ready;
NakKey! -> Ready;
}
}
Channel Contracts
• A contract specifies a finite state machine
• Each message causes a deterministic transition from one state to
another state
public contract KeyboardDeviceContract
out message AckKey( uint key );
out message NakKey();
out message Success();
KeyboardDeviceContract
in message GetKey();
in message PollKey();
Start
SC:AckKey
SC:Success
Waiting
SC:AckKey
Ready
SC:NakKey
state Start {
Implicit
Success! -> Ready;
State
}
CS:PollKey
CS:GetKey
{
Ready$0
SC:AckKey
state Ready {
GetKey? -> Waiting;
PollKey? -> (AckKey! or NakKey!)
-> Ready;
}
state Waiting {
AckKey! -> Ready;
NakKey! -> Ready;
}
}
Outline
• Motivation
– Composition of Web Services
– Singularity Channel Contracts
• Conversations
• Realizability
• Synchronizability
• Applications
• Recent Results
Going to Lunch at UCSB
• Before Xiang left 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.
• Let’s call this protocol the First Caller Decides (FCD) protocol.
• At the time we did not have answering machines or voicemail!
FCD Protocol Scenarios
•
•
•
Possible scenario
1. Tevfik calls Jianwen with the decision of where and when to eat
2. Jianwen calls Xiang and passes the information
Another scenario
1. Jianwen calls Tevfik with the decision of where and when to eat
2. Tevfik calls Xiang and passes the information
Yet another scenario
1. Tevfik calls Xiang with the decision of where and when to eat
• Maybe Jianwen also calls Xiang at the same time with a
different decision. But the phone is busy.
• Jianwen keeps calling. But Xiang is not going to answer
because according to the protocol the next thing Xiang has to
do is to call Jianwen.
2. Xiang calls Jianwen and passes the information
FCD Protocol: Tevfik’s Behavior
Let’s look at all possible behaviors of Tevfik based on the FCD protocol
Tevfik calls Jianwen with
the lunch decision
Tevfik is hungry
Tevfik calls Xiang with
the lunch decision
Tevfik receives a call
from Xiang telling him
the lunch decision that
Tevfik has to pass to
Jianwen
Tevfik receives a call from
Jianwen passing him the
lunch decision
Tevfik receives a call from
Xiang passing him the
lunch decision
FCD Protocol: Tevfik’s Behavior
T->J:D
Message Labels:
!
?
Tevfik calls Jianwen with the lunch decision
send
receive
J->X:P
Jianwen calls Xiang to pass the decision
!T->J:D
?J->T:P
!T->X:D
?X->T:P
?J->T:D
!T->X:P
?X->T:D
!T->J:P
State machines for the FCD Protocol
Tevfik
Xiang
!T->J:D
?J->T:P
!T->J:D
?X->T:P
!X->J:D
!X->T:D
?J->T:D
?X->T:D
?J->X:D
!T->X:P
!T->J:P
!X->T:P
Jianwen
?J->X:P
?T->X:P
?T->X:D
!X->J:P
!J->T:D
?T->J:P
!J->X:D
?X->J:P
?T->J:D
!J->X:P
?X->J:D
!J->T:P
• Three state machines characterizing the behaviors of Tevfik, Xiang
and Jianwen according to the FCD protocol
FCD Protocol Has Voicemail Problems
• When the university installed a voicemail system FCD protocol started
causing problems
– We were showing up at different restaurants at different times!
• Example scenario:
– Tevfik calls Xiang with the lunch decision
– Jianwen also calls Xiang with the lunch decision
• The phone is busy (Xiang is talking to Tevfik) so Jianwen leaves
a message
– Xiang calls Jianwen passing the lunch decision
• Jianwen does not answer (he already left for lunch) so Xiang
leaves a message
– Jianwen shows up at a different restaurant!
• Message sequence is: T->X:D J->X:D X->J:P
– The messages J->X:D and X->J:P are never consumed
• This scenario is not possible without voicemail!
A Different Lunch Protocol
• To fix this problem, 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.
• Let’s call this protocol the Jianwen Decides (JD) protocol
State machines for the JD Protocol
Tevfik
?J->T:D
Xiang
Jianwen
?X->T:P
?J->X:D
!J->T:D
?T->X:P
!J->X:D
!T->X:P
• JD protocol works fine with voicemail!
!X->T:P
Conversations
• The FCD and JD protocols specify a set of conversations
– A conversation is the sequence of messages generated during an
execution of the protocol
• We can specify the set of conversations without showing how the
peers implement them
– we call such a specification a conversation protocol
FCD and JD Conversation Protocols
JD Protocol
FCD Protocol
T->X:D
T->J:D
J->X:P
J->X:D
X->T:D
T->J:P
J->T:P
J->X:D
J->T:D
X->T:P
T->X:P
X->T:P
T->X:P
X->J:P
Conversation set:
{ T->X:D X->J:P,
T->J:D J->X:P,
X->T:D T->J:P,
X->J:D J->T:P,
J->T:D T->X:P,
J->X:D X->T:P
X->J:D
J->T:D
Conversation set:
{ J->T:D T->X:P,
J->X:D X->T:P}
}
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?
Conversations, Choreography, Orchestration
• Peer state machines are orchestrations
– A peer state machine can be specified using an orchestration
language such as WS-BPEL
– One can translate WS-BPEL specifications to peer state machines
• A conversation protocol is a choreography specification
– A conversation set corresponds to a choreography
– A conversation set can be specified using a choreography
language such as WS-CDL
– One can translate WS-CDL specifications to conversation protocols
Bottom-Up vs. Top-Down
Bottom-up approach
• Specify the behavior of each peer
– For example using an orchestration language such as WS-BPEL
• 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
– For example using a choreography language such as WS-CDL
• Ensure that the conversations generated by the peers obey the
protocol
Top-Down vs. Bottom-Up
Conversation
Protocol
(Choreography
Specification)
Peer T
?X->T:P
J->T:D
J->X:D
?
T->X:P
LTL property
GF(T->X(P)  X->T(P))
X->T:P
Peer X
Peer J
!J->T:D
?T->X:P
?J->X:D
?J->T:D
!T->X:P
Virtual Watcher
!J->X:D
!X->T:P
... ?
GF(T->X(P)  X->T(P))
LTL property
Input
Queue
Outline
• Motivation
– Composition of Web Services
– Singularity Channel Contracts
• Conversations
• Realizability
• Synchronizability
• Applications
• Recent Results
Realizability Question
• 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?
– Synthesize peer implementations by projecting the global protocol
to each peer by dropping unrelated messages for each peer
Conversations specified by
the conversation protocol
?

Conversations generated by the
projected services
If this equality holds the conversation protocol is realizable
• The JD protocol is realizable
• The FCD protocol is not realizable
Are there conditions which ensure the equivalence?
Realizability Problem
• Not all conversation protocols are realizable!
AB: m1
!m1
?m1
!m2
?m2
CD: m2
Peer A
Conversation
protocol
Peer B
Peer C
Peer D
Projection of the conversation
protocol to the peers
Conversation “m2 m1” will also be generated by all peer
implementations which follow the protocol
Realizability Conditions
Three sufficient conditions for realizability (no message content)
• 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)
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
CD: m2
CA: m2
AB: m1
AC: m3
Not lossless
join
Not synchronous
compatible
Not autonomous
Outline
• Motivation
– Composition of Web Services
– Singularity Channel Contracts
• Conversations
• Realizability
• Synchronizability
• Some Experiments
• Applications
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?
• We call such compositions synchronizable
• The implementation of the JD protocol is synchronizable
• The implementation of the FCD protocol is not synchronizable
Three Examples, Example 1
r1, r2
!e
?a1
?a2
!r1 !r2
e
!a1
!a2
?r1
a1, a2
requester
?r2
?e
server
• Conversation set is regular: (r1a1 | r2a2)* e
• During all executions the message queues are bounded
Example 2
r1, r2
!e
?a1
?a2
!r1
!r2
e
a1, a2
requester
• Conversation set is not regular
• Queues are not bounded
!a1
!a2
?r1
?r2
?e
server
Example 3
!e !r
2
!r1
r1, r2
e
?a
!r
?r
?r1
a1, a2
requester
• Conversation set is regular: (r1 | r2 | ra)* e
• Queues are not bounded
!a
?r2
?e
server
# of states in thousands
State Spaces of the Three Examples
1600
1400
1200
1000
Example 1
Example 2
Example 3
800
600
400
200
13
11
9
7
5
3
1
0
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
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
Synchronizability Analysis
Sufficient conditions for synchronizability:
• A composite web service is synchronizable, if it satisfies the
synchronous compatible and autonomous conditions
• 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
Outline
• Motivation
– Composition of Web Services
– Singularity Channel Contracts
• Conversations
• Realizability
• Synchronizability
• Applications
• Recent Results
Are These Conditions Too Restrictive?
Problem Set
Source
Name
ISSTA’04
SAS
CvSetup
MetaConv
IBM
Chat
Conv.
Buy
Support
Haggle
Project
AMAB
BPEL
shipping
Loan
spec
Collaxa.
com
Auction
StarLoan
Cauction
#msg
9
4
4
2
5
8
8
2
6
Size
#states
12
4
4
4
5
5
10
3
6
Pass?
#trans.
15
4
6
5
6
8
15
3
6
yes
yes
no
yes
yes
no
yes
yes
yes
9
6
5
9
7
7
10
7
6
yes
yes
yes
Singularity Channel Contract Verification
• State machine construction allows for automated verification and
analysis of channel communication
• Singularity compiler automatically checks compliance of client and
server processes to the specified contract
• Claim from Singularity documentation:
– "clients and servers that have been verified separately against the
same contract C are guaranteed not to deadlock when allowed to
communicate according to C.“
• This claim is wrong!
Deadlock Example: The TpmContract
Server
Projection
Send?
Server
Receive Queue
AckStartSend!
SendComplete!
TpmStatus!
GetTpmStatus?
GetTpmStatus?
Client
Projection
ReadyState$0
Send!
Client
SC:AckStartSend
CS:Send
AckStartSend?
SendComplete?
SC:SendComplete
ReadyState
TpmStatus?
TpmStatus!
SC:TpmStatus
CS:GetTpmStatus
GetTpmStatus!
GetTpmStatus!
ReadyState$1
Receive Queue
IO_RUNNING
SC:TpmStatus
TpmStatus?
CS:GetTpmStatus
IO_RUNNING$0
Conversation
Deadlock Example: The TpmContract
Server
Projection
ReadyState$0
Send?
Server
Receive Queue
AckStartSend!
SendComplete!
TpmStatus!
GetTpmStatus
Send
ReadyState
IO_RUNNING
GetTpmStatus?
GetTpmStatus?
ReadyState$1
IO_RUNNING$0
Client
Projection
TpmStatus!
ReadyState$0
Send!
Client
Receive Queue
AckStartSend?
SendComplete?
SendComplete
AckStartSend
ReadyState
IO_RUNNING
GetTpmStatus!
GetTpmStatus!
ReadyState$1
IO_RUNNING$0
TpmStatus?
TpmStatus
TpmStatus?
Conversation
CS:
SC:
SC:
CS:
SC:
Send
AckStartSend
SendComplete
GetTpmStatus
TpmStatus
Realizability Problem
• KeyboardDeviceContract is not realizable
– It violates the autonomous condition
• It turns out that autonomous condition is sufficient (but not necessary)
for realizability of two-party protocols (Singularity channel contracts are
two-party protocols)
– If a contract is autonomous, it is guaranteed to be realizable
– However, it can be realizable but not autonomous
• i.e., false positives are possible when we use autonomous
condition as our realizability check
Autonomous condition and false positives
• Example: FixedTpmContract
ReadyState$0
CS:Send
SC:AckStartSend
SC:SendComplete
ReadyState
SC:TpmStatus
CS:GetTpmStatus
ReadyState$1
Violates
Autonomous
condition
IO_RUNNING
SC:TpmStatus
CS:GetTpmStatus
IO_RUNNING$0
SC:TpmStatus
IO_RUNNING$1
SC:SendComplete
Model checking efficiency
• Explicit state verification is expensive using asynchronous
communication
– Exponential state space explosion in the worst case
• Example: BlowupKContract
S1
SC:m1
SC:m2
S2
SC:m1
SC:m2
…
SC:m1
CS:m3
SC:m2
Sk
Model checking efficiency
• If contract is realizable, conversations generated using asynchronous
communication and synchronous communication are the same
– Therefore, synchronous communication model can be used for
verification
S1
SC:m1
SC:m2
S2
SC:m1
SC:m2
…
SC:m1
CS:m3
SC:m2
Sk
Tune: A Tool For Analyzing Sing# Contracts
Consumed by
Produces
Channel
Contract
Sync
Promela
File
Contract
Parser
Contract
State
Machine
LTL
Formulas
Contract
Analyzer
LTL
Formulas
Realizable?
Asynchronous
Promela
Generator
Synchronous
Promela
Generator
Yes
Tune
Component
External
Tool
No
Spin
Report
Data
Collector
Async
Promela
Analysis Efficiency
• Performed autonomous check and exhaustive deadlock search for
~95% of contracts to compare analysis time
• Results show clear advantage to performing the autonomous check
LTL Property Validation
• Selected 10 contracts for LTL property validation
• Both synchronous and asynchronous models were used to compare
performance
Realizability Results
• Ran analysis on 93 contracts from the Singularity code base
(version 2.0) and documentation
• Found two contracts that violate the autonomous condition
(TpmContract and ReservationSession)
• Exhaustive search showed deadlocking execution traces for both
contracts
– Confirmed by Singularity developers
• Tune did not report any false positives from autonomous check for any
of the contracts analyzed
• In practice, autonomous condition is not too restrictive
Outline
• Motivation
– Composition of Web Services
– Singularity Channel Contracts
• Conversations
• Realizability
• Synchronizability
• Applications
• Recent Results
Recent Results
• Open problems (until recently):
– Is realizability decidable?
– Is synchronizability decidable?
• Recent result
– Synchronizability is decidable!
• We are pretty sure that we will also be able to show that realizability is
decidable
Synchronizability Result
• Given a set of peers
– Let C-A be their asynchronous composition
– Let C-k be their bounded-asynchronous composition where queues
are bounded to be of size k
• A send to a full queue (i.e., a queue with k elements) blocks
– C-0 corresponds to synchronous composition
Theorem: A composition is synchronizable (i.e., L(C-0)=L(C-A)) if and
only if the conversation set of C-0 and C-1 are the same
(i.e., L(C-0) = L(C-1))
Reachability & Synchronizability
• It is well-known that reachability problems for asynchronously
communicating systems are undecidable
• We can extend the synchronizability definition to include reachability
– We call a composition reachability-synchronizable if 1) it is
synchronizable and 2) the set of states reachable in the
synchronous composition is same as the set of empty-queue
states reachable in the asynchronous composition
• Very recent result: Determining if a composition is reachabilitysynchronizable is decidable
– Theorem: A composition is reachability-synchronizable if and only
if the conversation set and the (empty-queue) reachable states of
C-0 and C-1 are the same
Related Work
• Singularity:
– [Hunt, Larus SIGOPS ‘07] Singularity: rethinking the software stack
– [Fähndrich, Aiken, Hawblitzel, et. al SIGOPS/Eurosys ‘07]
Language support for fast and reliable message-based
communication in singularity os.
– Influenced by work on Session Types
• [Honda, Vasconcelos, Kubo ESOP ’98] Language primitives
and type discipline for structured communication-based
programming
– Source code and RDK: http://codeplex.com/singularity
Related Work
• Realizability of message sequence charts
– [Alur, Etessami, Yannakakis] ICSE’00, ICALP’01]
– Defines similar notion of realizability
– Different conversation model
Related Work
• Specification approaches that are similar to conversation protocols
– [Parunak ICMAS 96] Visualizing agent conversations: Using
enhanced Dooley graphs for agent design and analysis.
– [Hanson, Nandi, Kumaran EDOCC’02] Conversation support for
business process integration
Related Work
• Message Sequence Charts (MSC)
– [Alur, Etassami, Yannakakis ICSE’00, ICALP’01] Realizability of
MSCs and MSC Graphs
– [Uchitel, Kramer, Magee ACM TOSEM 04] Implied Scenarios in
MSCs
Related Work
• Verification of web services
– Petri Nets
• [Narayanan, McIlraith WWW’02] Simulation, verification,
composition of web services using a Petri net model
– Process Algebras
• [Foster, Uchitel, Magee, Kramer ASE’03] Using MSC to model
BPEL web services which are translated to labeled transition
systems and verified using model checking
– Model Checking Tools
• [Nakajima ICWE’04] Model checking Web Service Flow
Language specifications using SPIN
– …
• See the survey on BPEL verification
– [Van Breugel, Koshkina 06] Models and Verification of BPEL
http://www.cse.yorku.ca/~franck/research/drafts/
Related Work
• Modeling Choreography & Orchestration
– Process algebras, synchronous communication
• [Busi, Gorrieri, Guidi, Lucchi, Zavattaro ICSOC’05]
• [Qiu, Zhao, Chao, Yang WWW’07]
– Activity based (rather than message based) approaches
• [Berardi, Calvanese, DeGiacomo, Hull, Mecella VLDB’05]
THE END