• Collaborators:
– Xiang Fu, Hofstra University, USA
– Jianwen Su, University of California, Santa Barbara, USA
– Rick Hull, IBM TJ Watson, USA
– Aysu Betin Can, Middle East Technical University, Turkey
– Zachary Stengel, Microsoft, USA
– Chris Ferguson, Active Network, USA
– Gwen Salaun, Inria, France
– Sylvain Halle, University du Quebec a Chicoutimi, Canada
– Samik Basu, Iowa State University, USA
– Meriem Ouderni, INP-ENSEEIHT, France

• All software is moving to the network
– Mobile or Browser-based thin clients combined with servers hosted on the cloud are replacing desktop applications
• More things are becoming programmable
– Smart-phones and smart-TVs are already common
– Smart-glasses, smart watches, programmable cars are soon to follow
• More things are moving to the network
– Internet of things is becoming a reality
• you can control your lights with your smart-phone
– Nowadays programmable things come with network connection
• It seems like a good time to focus on specification and analysis of interactions of software systems that communicate over a network!

• Web services support basic client/server style interactions
WSDL
Request
SOAP Service
Requester
Client
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

• 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: 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

Choreography Web Services Choreography Description Language (WS-CDL)
Orchestration Web Services Business Process Execution Language (WS-BPEL)
Service Web Services Description Language (WSDL)
Protocol
Type
Simple Object Access Protocol (SOAP)
XML Schema (XSD)
Data Extensible Markup Language (XML)
WSDL
Atomic
Service
SOAP
WS-CDL
WS-BPEL
Orchestrated
Service
SOAP
SOAP
WS-BPEL
Orchestrated
Service
SOAP
WSDL
Atomic
Service
SOAP

• 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

• 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

• 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();
2.
•
•
The set of allowed message sequences out in message marked with messages marked with
!
?
state Start {
Success! -> Ready;
} state Ready {
GetKey? -> Waiting;
PollKey? -> (AckKey! or NakKey!)
-> Ready;
} state Waiting {
AckKey! -> Ready;
NakKey! -> Ready;
}
}

• A contract specifies a finite state machine
• Each message causes a deterministic transition from one state to another state public contract KeyboardDeviceContract {
KeyboardDeviceContract out message AckKey( uint key ); out message NakKey(); out message Success(); in message GetKey(); in message PollKey(); Start
S  C:AckKey
S  C:Success
S  C:AckKey
Waiting
C  S:GetKey
S  C:NakKey
Ready
C  S:PollKey
S  C:AckKey
Ready$0 state Start {
Success! -> Ready;
}
Implicit
State state Ready {
GetKey? -> Waiting;
PollKey? -> (AckKey! or NakKey!)
-> Ready;
} state Waiting {
AckKey! -> Ready;
NakKey! -> Ready;
}
}

• Erlang is a general purpose programming language developed initially at Ericsson for improving dependability of telephony applications
• In Erlang distributed processes do not share memory and only interact with each other via exchanging messages asynchronously
• UBF(B) is a language for specifying communication contracts in distributed Erlang programs.
• UBF(B) specifications list transitions between states where each transition is identified with a request (the message received) and response (the message sent)
+NAME( “IRC SERVER”)
...
+STATE start logon() => ok() & active
| error() & stop
+STATE active ls() => files() & active getFile() => fileSent() & active
| noFileErr() & stop
...

+NAME( “IRC SERVER”)
...
+STATE start logon() => ok() & active
| error() & stop
+STATE active ls() => files() & active getFile() => fileSent() & active
| noFileErr() & stop
...
C  S:logon start
C  S:ls
S  C:ok S  C:error active
C  S:getfile
S  C:files
S  C:fileSent stop
S  C:noFileErr

:Customer
1:reserve A2,B2/2:reply must precede sequence label message
1/A1:fligtInquiry
A2:flightAvailability
:Airline
:TravelAgency
1/B1:roomInquiry
B2:roomAvailability
:Hotel

• Messages are ordered based on two rules
– Implicit: The sequence labels that have the same prefix must be ordered based on their sequence number
– Explicit: The events listed before “ / ” must precede the current event
Initial message
1:reserve
1/A1:flightInquiry 1/B1:roomInquiry
A2:flightAvailability B2:roomAvailability
A2,B2/2:reply
Final message

A

TA

A: flightInquiry
TA: flightAvailability
C

TA: reserve
TA

H: roomInquiry
TA

H: roomInquiry
TA

A: flightInquiry
H

TA: roomAvailability
TA

H: roomInquiry
A

TA: flightAvailability
H

TA: roomAvailability
TA

A: flightInquiry
H  TA: roomAvailability
A

TA: flightAvailability
TA

C: reply

• Specifications of message-based communication
– Web Service Choreography Specifications : Global specification of interactions for composition of services
– Singularity Channel Contracts : Coordinating inter-process communication in Singularity OS
– Erlang Communication Contracts : Coordinating interactions among distributed processes
– UML Collaboration diagrams : Specifying interactions among components
• All these specifications can be modeled as state machines and they all specify sequences of sent messages (aka, conversations):
Conversation: A sequence of messages sent during an execution
Conversation Protocol (aka Choreography): A state machine that specifies a set of conversations

• 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

• Each contract state machine specifies a set of conversations, i.e., it is a conversation protocol:
KeyboardDeviceContract
Start
S  C:AckKey
S  C:Success
S  C:AckKey
Waiting
C  S:GetKey
Ready
C  S:PollKey
Ready$0
S  C:NakKey S  C:NakKey
Conversation set:
Success(GetKey(AckKey|NakKey)|PollKey(AckKey|NakKey))*

• Motivation
– Composition of Web Services
– Singularity Channel Contracts
• Conversations
• Realizability
• Synchronizability
• Applications
• Conclusions

• At UCSB Samik, Meriem 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/her 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 due to budget cuts at UC!

• Possible scenario
1. Tevfik calls Samik with the decision of where and when to eat
2. Samik calls Meriem and passes the information
• Another scenario
1. Samik calls Tevfik with the decision of where and when to eat
2. Tevfik calls Meriem and passes the information
• Yet another scenario
1. Tevfik calls Meriem with the decision of where and when to eat
• Maybe Samik also calls Meriem at the same time with a different decision. But the phone is busy.
• Samik keeps calling. But Meriem is not going to answer because according to the protocol the next thing Meriem has to do is to call Samik.
2. Meriem calls Samik and passes the information

Let ’ s look at all possible behaviors of Tevfik based on the FCD protocol
Tevfik calls Samik with the lunch decision
Tevfik is hungry
Tevfik calls Meriem with the lunch decision
Tevfik receives a call from Meriem telling him the lunch decision that
Tevfik has to pass to
Samik
Tevfik receives a call from
Samik passing him the lunch decision
Tevfik receives a call from
Meriem passing him the lunch decision

Message Labels:
!
send
?
receive
T->S:D
Tevfik calls Samik with the lunch decision
S->M:P
Samik calls Meriem to pass the decision
!T->S:D ?S->T:P
!T->M:D
?S->T:D
?M->T:P
?M->T:D
!T->M:P !T->S:P

!T->S:D
!T->M:D
?S->T:D
Tevfik
?S->T:P
?M->T:P
?M->T:D
!T->M:P !T->S:P
Meriem
!M->S:D ?S->M:P
!M->T:D
?S->M:D
?T->M:P
?T->M:D
!M->T:P !M->S:P
Samik
!S->T:D ?T->S:P
!S->M:D
?T->S:D
?M->S:P
?M->S:D
!S->M:P !S->T:P
• Three state machines characterizing the behaviors of Tevfik, Meriem and Samik according to the FCD protocol

• After the economy started to recover, 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 Meriem with the lunch decision
– Samik also calls Meriem with the lunch decision
• The phone is busy (Meriem is talking to Tevfik) so Samik leaves a message
– Meriem calls Samik passing the lunch decision
• Samik does not answer (he already left for lunch) so Meriem leaves a message
– Samik shows up at a different restaurant!
• Message sequence is: T->M:D S->M:D M->S:P
– The messages S->M:D and M->S:P are never consumed
• This scenario is not possible without voicemail!

• To fix this problem, I suggested that we change our lunch protocol as follows:
– As the most senior researcher among us I would make the first call to either Meriem or Samik 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 Tevfik Decides (TD) protocol

?T->S:D
Samik
?M->S:P
!S->M:P
!T->S:D
Tevfik
!T->M:D
?T->M:D
Meriem
?S->M:P
!M->S:P
• TD protocol works fine with voicemail!

• A composition of services consists of
– a finite set of peers
• Lunch example with three peers: T, S, M
– and a finite set of messages
• Lunch example (TD protocol) with four messages
T->S(D) , T->M(D) , S->M(P) , M->S(P)
Peer S
S->M(P)
M->S(P)
Peer M
T->A(D) T->M(D)
Peer T

• We assume that the messages among the peers are exchanged using reliable and asynchronous messaging
– FIFO and unbounded message queues
Peer T T->S(D) T->S(D) Peer S
• There are existing messaging platforms that support this type of messaging
• Java Messaging Service (JMS)
• Java API for XML messaging (JAXM)
• MSMQ (Microsoft Message Queuing Service)

• Record the messages in the order they are sent
S->M(P)
Peer S Peer M
Generated conversation:
T->S(D) S->M(P)
Peer T
• A conversation is a sequence of messages generated during an execution

• The notion of conversation enables us to reason about temporal properties of the composite 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?

!T->S:D
!T->M:D
?S->T:D
Tevfik
?S->T:P
?M->T:P
?M->T:D
!T->M:P !T->S:P
Meriem
!M->S:D ?S->M:P
!M->T:D
?S->M:D
?T->M:P
?T->M:D
!M->T:P !M->S:P
Samik
!S->T:D ?T->S:P
!S->M:D
?T->S:D
?M->S:P
?M->S:D
!S->M:P !S->T:P

?T->S:D
Samik
?M->S:P
!S->M:P
!T->S:D
Tevfik
!T->M:D
?T->M:D
Meriem
?S->M:P
!M->S:P

FCD Protocol TD Protocol
T->M:D S->M:D
T->S:D
S->M:P
M->S:P
M->T:D
T->S:P
M->S:D
S->T:P
S->T:D
T->M:P
M->T:P
Conversation set:
{ T->M:D M->S:P,
T->S:D S->M:P,
M->T:D T->S:P,
M->S:D S->T:P,
S->T:D T->M:P,
S->M:D M->T:P }
T->S:D
S->M:P
T->M:D
M->S:P
Conversation set:
{ T->S:D S->M:P,
T->M:D M->S:P }

• 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

• The implementation of the FCD protocol behaves differently with synchronous and asynchronous communication whereas the implementation of the TD 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?

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

Conversation
Protocol
(Choreography
Specification)
?T->S:D
Peer T
?M->S:P
!S->M:P
T->S:D
S->M:P
T->M:D
LTL property
F( S->M:P  M->S:P )
M->S:P
!T->S:D
Peer J
!T->M:D
?T->M:D
Peer X
?S->M:P
Input
Queue
!M->S:P
Conversation
...
F( S->M:P  M->S:P )
LTL property

• Motivation
– Composition of Web Services
– Singularity Channel Contracts
• Conversations
• Realizability
• Synchronizability
• Applications
• Conclusions

• Conversation protocols identify the global communication behavior
– How do we implement processes that conform to the conversation protocol?
• Realizability question:
– Given a conversation protocol, are there processes whose communication behavior in terms of conversations (i.e., send sequences) is equal to the set of conversations (i.e., send sequences) specified by the conversation protocol?
Conversations specified by the conversation protocol
?
 Conversations generated by some processes
• The FCD protocol is unrealizable
• The TD protocol is realizable

• Three unrealizable conversation protocols:
A  B: m1
C  D: m2
A  B: m1
C  A: m2
B  A: m2
A  B: m1
A  B: m1
B  A: m2
A  C: m3

• This protocol is unrealizable both for synchronous and asynchronous communication!
A  B: m1
!m1
?m1
!m2
?m2
C  D: m2
Peer A Peer B Peer C
Conversation protocol
Conversation “ m2 m1 ” will be generated by all implementations which follow the protocol
Peer D
Projections of the protocol to the processes

• This protocol is realizable with synchronous communication but unrealizable with asynchronous communication!
A  B: m1 !m1
?m1
!m2
C  A: m2
?m2
Peer B Peer C
Conversation protocol
Peer A
Projections of the protocol to the processes
Conversation “ m2 m1 ” will be generated by all implementations which follow the protocol

B
B  A: m2
A, C
A  B: m1
B  A: m2
A  B: m1
A  C: m3 m2 A m1 B m3
C
Conversation: m2 m1 m3
Generated conversation: m2 m1 m3

• Finite state processes that communicate with FIFO message queues can simulate Turing Machines
– In general analyzing properties of asynchronously communicating finite state machines is undecidable
– For example, checking conformance to a conversation protocol is undecidable

Three conditions
• Lossless join
• Synchronous compatible
• Autonomous
Together they are sufficient conditions for realizability

• Lossless join
– Conversation set should be equivalent to the join of its projections to each peer
A
C


B:
D: m1 m2
Conversation set: {m1m2}
Projection to A: {!m1}
Projection to B: {?m1}
Projection to C: {!m2}
Projection to D: {?m2}
Join of the projections: {m1m2, m2m1}
Not equal to the conversation set!
This protocol is not lossless join

• 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
A  B: m1
!m1
?m1
!m2
C is ready to send but A is not ready to receive
C  A: m2 ?
m2
Peer B Peer C
Conversation protocol
Peer A
This protocol is not synchronous compatiable

• 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)
B  A: m2 A  B: m1
A has both a send and a receive transition from this state
(B also has both send and receive transitions)
B  A: m2
A  B: m1
A  C: m3
This protocol is not autonomous

• Motivation
– Composition of Web Services
– Singularity Channel Contracts
• Conversations
• Realizability
• Synchronizability
• Applications
• Conclusions

• 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

!e
?a
1
!r
1
!r
2
?a
2 r
1
, r
2 e
!a
?r
1
1
!a
2
?r
2
?e
a
1
, a
2 requester server
• Conversation set is regular: ( r
1 a
1
| r
2 a
2
)* e
• During all executions the message queues are bounded

?a
1
!r
1
!e
?a
2 r
1
, r
2 e
!a
?r
1
1
!a
2
?r
2
!r
2 a
1
, a
2
?e
server requester
• Conversation set is not regular
• Queues are not bounded

!r
1
?a
!e
!r
2
!r
r
1
, r
2 e a
1
, a
2
?r
1
?r
!a
?e
?r
2 requester
• Conversation set is regular: ( r
1
• Queues are not bounded
| r
2
| ra )* e server

1600
1400
1200
1000
800
600
400
200
0
1 3 5 7 9
11 13 queue length
Example 1
Example 2
Example 3
• 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

• 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

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

Problem Set
Source
ISSTA’04
Name
SAS
IBM
Conv.
CvSetup
MetaConv
Chat
Support
Project
BPEL
Buy
Haggle
AMAB shipping spec Loan
Collaxa.
com
Auction
StarLoan
Cauction
Size
#msg #states #trans.
8
2
5
8
9
4
4
2
6
12
4
4
4
5
5
10
3
6 6
6
8
15
3
15
4
6
5
9
6
5
9
7
7
10
7
6
Pass?
yes yes no yes yes no yes yes yes yes yes yes

• More recently we identified necessary and sufficient conditions for realizability and synchronizability

• Just looking at equivalence of the conversation sets is not enough
Conversations specified by the conversation protocol
?
 Conversations generated by some processes
• In addition to the above equivalence we may also want that the peers do not get stuck or some messages may never be consumed

So we need two requirements for realizability:
1.
Conversations specified by the conversation protocol =
Conversations generated by the asynchronous system
2.
Asynchronous system is well-formed :
All sent messages can be eventually consumed
Conversation protocol is realizable if and only if there exists such an asynchronous system

• Behavior exhibited by projections when communicating synchronously can be same or larger than the conversation set
• Behavior exhibited by projections when communicating asynchronously can be same or larger than that exhibited by projections when communicating synchronously
– For bounded channels, increasing the channel size leads to same or larger conversation set
C ≤ I
0
≤ I
1
≤ I
2
≤ … ≤ I

A system is synchronizable if and only if its behaviors are identical for asynchronous and synchronous communication
For synchronizable systems:
Forall k ≥ 0: I k is equivalent to I
I is synchronizable iff I
0 is equivalent to I
1

A synchronizable system that consists of deterministic processes is wellformed (all sent messages are eventually consumed)

1. Project conversations to processes
2. Determinize peers
3. Check equivalence between conversation C and I
1
– C = I
1 if and only if I is synchronizable [Obs 1, 2] and C = I
– C = I
1 implies I is well-formed [Obs 3]
C = I
1 if and only if C is realizable

• Motivation
– Composition of Web Services
– Singularity Channel Contracts
• Conversations
• Realizability
• Synchronizability
• Applications
• Conclusions

• Implemented using CADP toolbox
– Automatically generate a LOTOS specification for the conversation protocol
– Generate determinized projections (in LOTOS)
– Check equivalence of the 1-bounded asynchronous system and the conversation protocol
• Checked realizability of
– 9 web service choreography specifications
• 8 are realizable
– 9 collaboration diagrams
• 8 are realizable
– 86 Singularity channel contracts
• 84 are realizable
• Realizability check takes about 14 seconds on average

• 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!

Server
Projection
Send?
SendComplete!
AckStartSend!
Server
Receive Queue
Conversation
TpmStatus!
GetTpmStatus?
GetTpmStatus?
TpmStatus!
Client
Projection
Send!
C  S:Send
SendComplete?
S  C:SendComplete
S  Client
Receive Queue
TpmStatus?
S  C:TpmStatus
GetTpmStatus!
C  S:GetTpmStatus
TpmStatus?
C S:GetTpmStatus
S  C:TpmStatus

Server
Projection
Send?
ReadyState
ReadyState$0
AckStartSend!
SendComplete!
IO_RUNNING
TpmStatus!
GetTpmStatus?
GetTpmStatus?
TpmStatus!
Server
Receive Queue
ReadyState$1 IO_RUNNING$0
Conversation
C  S: Send
S  C: AckStartSend
S  C: SendComplete
C  S: GetTpmStatus
S  C: TpmStatus
Client
Projection
Send!
ReadyState
ReadyState$0
AckStartSend?
SendComplete?
IO_RUNNING
TpmStatus?
GetTpmStatus!
GetTpmStatus!
TpmStatus?
ReadyState$1 IO_RUNNING$0
Client
Receive Queue
TpmStatus

• TpmContract is not realizable
– It violates the autonomous condition
• As I mentioned earlier, 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

• Example: Fixed TpmContract
Since autonomous condition is not a necessary condition, it can cause false positives when used for checking realizability
ReadyState$0
C  S:Send S  C:AckStartSend
S  C:SendComplete
ReadyState IO_RUNNING
S  C:TpmStatus
C  S:GetTpmStatus C  S:GetTpmStatus
S  C:TpmStatus
ReadyState$1 IO_RUNNING$0
S  C:TpmStatus
IO_RUNNING$1
S  C:SendComplete
• Using our recent results we can show that this modified protocol is realizable using the necessary and sufficient condition for realizability

• Explicit state verification is expensive using asynchronous communication
– Exponential state space explosion in the worst case
• Example: BlowupKContract
S1
S  C:m1
S2
S  C:m1
…
C  S:m3
S  C:m1
S k
S  C:m2
S  C:m2
S  C:m2

• 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
S2
S  C:m1
…
C  S:m3
S  C:m1
S k
S  C:m2
S  C:m2
S  C:m2

• Performed realizability check and exhaustive deadlock search for
~95% of contracts to compare analysis time
• Results show clear advantage to performing the realizability check

• Selected 10 contracts for LTL property validation
• Both synchronous and asynchronous models were used to compare performance
• Verification using the synchronous model is more efficient as expected, demonstrating the usefulness of realizability/synchronizability checks

• [Fu et al. TCS’04] : Sufficient conditions for realizability
• [Fu et al. TSE’05] : Sufficient conditions for synchronizability
• [Bultan and Fu SOCA’08] : Application of realizability analysis to collaboration diagrams
• [Stengel and Bultan ISSTA’09] : Application of realizability analysis to
Singularity channel contracts
• [Halle and Bultan FSE’10] : more relaxed sufficient condition that allows arbitrary initiators
• [Basu and Bultan WWW’11] : Necessary and sufficient condition for synchronizability
• [Basu, Bultan, Ouderni POPL’12] : Necessary and sufficient condition for realizability
• [Basu, Bultan, Ouderni VMCAI’12] : Synchronizability for send sequences + reachability of synchronized states

• Singularity: Focuses on two-party communication
– [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
• More recent work on Session Types on multi-party communication
– [Honda, Yoshida, Carbone POPL’08] Multiparty Asynchronous
Session Types
– [Danielou, Yoshida, ESOP’12] Multiparty Session Types Meet
Communicating Automata
– Correspond to sufficient conditions for realizability

• Sufficient conditions for realizability:
– [Fu et al. TCS’04] Conversation Protocols
• [Honda et al. POPL’08] has similar conditions for session types
– Arbitrary Initiators are not allowed: Conversation protocol cannot have two different peers initiating send actions from the same state
• [Kazhamiakin, Pistore FORTE’06] : Realizability for restricted communication models
• [Lohmann, Wolf ICSOC’11] : Shows decidability of realizability with unbounded asynchronous communication when messages are not ordered (i.e., FIFO requirement is dropped)!

• Message Sequence Charts (MSC)
– [Alur, Etassami, Yannakakis ICSE ’ 00, ICALP ’ 01] Realizability of
MSCs and MSC Graphs
• Defines similar notion of realizability
– [Uchitel, Kramer, Magee ACM TOSEM 04] Implied Scenarios in
MSCs
– Different conversation model

Earlier results related to synchronizability:
• [Manohar, Martin MPC 98] Slack elasticity
– Presents conditions under which changing the size of communication queues does not effect the behavior of the system
– Behavior definition also takes the decision points into account in addition to message sequences
– It gives sufficient conditions for slack elasticity and discusses how to construct systems to ensure slack elasticity

• 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/

• 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

• 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]

• Extensions
– Choreography realizability, synchronizability for other communication models
– Branching time realizability
• Analyzing failure of realizability/synchronizability
– Automatically repairing unrealizable choreographies with minimal changes to the choreography
• Adoption of choreography specification and analysis in practice
– Web service choreography specification languages have been out there for years, are they being used in practice?
– Message-based interactions appear in many domains, can the general analysis techniques for message-based interactions be adopted in practice in multiple domains?
• All software is moving to the network/cloud and all devices are becoming programmable
– How can we integrate conversation specification and analysis to modern applications in practice?