Скачать презентацию Analyzing Interactions of Asynchronously Communicating Systems Tevfik Bultan Скачать презентацию Analyzing Interactions of Asynchronously Communicating Systems Tevfik Bultan

5bfb03976eeeb8c672e57707c466367c.ppt

  • Количество слайдов: 64

Analyzing Interactions of Asynchronously Communicating Systems Tevfik Bultan Department of Computer Science University of Analyzing Interactions of Asynchronously Communicating Systems Tevfik Bultan Department of Computer Science University of California, Santa Barbara [email protected] ucsb. edu http: //www. cs. ucsb. edu/~bultan

University of California at Santa Barbara University of California at Santa Barbara

Acknowledgements • Joint work with – Xiang Fu, Hofstra University – Jianwen Su, University 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 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 – Item. Search, Cart. Create, Cart. Add, Cart. Modify, Cart. Get, Cart. Clear • 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? • 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 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 Orchestration Service Web Services Choreography Description Language (WS-CDL) Web Web Services Standards Stack Choreography Orchestration Service Web Services Choreography Description Language (WS-CDL) Web Services Business Process Execution Language (WS-BPEL) Web Services Description Language (WSDL) Protocol Type Simple Object Access Protocol (SOAP) XML Schema (XSD) Extensible Markup Language (XML) Data WSDL WS-BPEL SOAP Atomic Service SOAP Orchestrated Service SOAP WS-CDL WS-BPEL Orchestrated Service WSDL SOAP Atomic Service

Asynchronous Messaging • Sender does not have to wait for the receiver – Message 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 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 – 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 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 Keyboard. Device. Contract { out message Ack. Key( uint key ); out message Nak. Key(); out message Success(); in message Get. Key(); in message Poll. Key(); state Start { Success! -> Ready; } state Ready { Get. Key? -> Waiting; Poll. Key? -> (Ack. Key! or Nak. Key!) -> Ready; } The set of allowed message sequences • out message marked with ! • in messages marked with ? state Waiting { Ack. Key! -> Ready; Nak. Key! -> Ready; } }

Channel Contracts • A contract specifies a finite state machine • Each message causes Channel Contracts • A contract specifies a finite state machine • Each message causes a deterministic transition from one state to another state public contract Keyboard. Device. Contract out message Ack. Key( uint key ); out message Nak. Key(); out message Success(); Keyboard. Device. Contract in message Get. Key(); in message Poll. Key(); Start S C: Ack. Key S C: Success Waiting S C: Ack. Key Ready S C: Nak. Key state Start { Implicit Success! -> Ready; State } C S: Poll. Key C S: Get. Key { Ready$0 S C: Ack. Key state Ready { Get. Key? -> Waiting; Poll. Key? -> (Ack. Key! or Nak. Key!) -> Ready; } state Waiting { Ack. Key! -> Ready; Nak. Key! -> Ready; } }

Outline • Motivation – Composition of Web Services – Singularity Channel Contracts • Conversations 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 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 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 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 Message Labels: ! ? T->J: D Tevfik calls Jianwen with FCD Protocol: Tevfik’s Behavior Message Labels: ! ? T->J: D 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: 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: 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 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 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: State machines for the JD Protocol Tevfik ? J->T: D Xiang Jianwen ? X->T: P !J->T: D ? J->X: 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 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: 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->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 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 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 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 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 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 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 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: m 1 !m Realizability Problem • Not all conversation protocols are realizable! A B: m 1 !m 1 ? m 1 !m 2 ? m 2 C D: m 2 Peer A Conversation protocol Peer B Peer C Peer D Projection of the conversation protocol to the peers Conversation “m 2 m 1” will also be generated by all peer m 1 implementations which follow the protocol

Realizability Conditions Three sufficient conditions for realizability (no message content) • Lossless join – 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 Realizability Conditions • Following protocols fail one of the three conditions but satisfy the other two A B: m 1 B A: m 2 C D: m 2 C A: m 2 A B: m 1 A C: m 3 Not lossless join Not synchronous compatible Not autonomous

Outline • Motivation – Composition of Web Services – Singularity Channel Contracts • Conversations 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 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 r 1, r 2 !e ? a 1 ? a Three Examples, Example 1 r 1, r 2 !e ? a 1 ? a 2 !r 1 !r 2 requester e a 1, a 2 !a 1 !a 2 ? r 1 ? r 2 ? e server • Conversation set is regular: (r 1 a 1 | r 2 a 2)* e • During all executions the message queues are bounded

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

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

# of states in thousands State Spaces of the Three Examples queue length • # of states in thousands State Spaces of the Three Examples 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 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 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 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 Cv. Setup Are These Conditions Too Restrictive? Problem Set Source Name ISSTA’ 04 SAS Cv. Setup Meta. Conv IBM Chat Conv. Buy Support Haggle Project AMAB BPEL shipping Loan spec Collaxa. com Auction Star. Loan 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 9 6 5 9 7 7 10 7 6 yes yes

Singularity Channel Contract Verification • State machine construction allows for automated verification and analysis 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 Tpm. Contract Server Projection Send? Server Receive Queue Ack. Start. Send! Deadlock Example: The Tpm. Contract Server Projection Send? Server Receive Queue Ack. Start. Send! Send. Complete! Tpm. Status! Get. Tpm. Status? Client Projection Ready. State$0 Send! Client S C: Ack. Start. Send C S: Send Ack. Start. Send? Send. Complete? S C: Send. Complete Ready. State Tpm. Status? Tpm. Status! S C: Tpm. Status C S: Get. Tpm. Status! Ready. State$1 Receive Queue IO_RUNNING S C: Tpm. Status? C S: Get. Tpm. Status IO_RUNNING$0 Conversation

Deadlock Example: The Tpm. Contract Server Projection Ready. State$0 Send? Server Receive Queue Ack. Deadlock Example: The Tpm. Contract Server Projection Ready. State$0 Send? Server Receive Queue Ack. Start. Send! Send. Complete! Get. Tpm. Status Send Ready. State Get. Tpm. Status? Ready. State$1 Tpm. Status! IO_RUNNING$0 Client Projection Tpm. Status! Ready. State$0 Send! Client Receive Queue Ack. Start. Send? Send. Complete? Send. Complete Ack. Start. Send Ready. State Tpm. Status? IO_RUNNING Get. Tpm. Status! Ready. State$1 IO_RUNNING$0 Tpm. Status? Conversation C S: S C: Send Ack. Start. Send. Complete Get. Tpm. Status

Realizability Problem • Keyboard. Device. Contract is not realizable – It violates the autonomous Realizability Problem • Keyboard. Device. Contract 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: Fixed Tpm. Contract Ready. State$0 C S: Autonomous condition and false positives • Example: Fixed Tpm. Contract Ready. State$0 C S: Send S C: Ack. Start. Send S C: Send. Complete Ready. State S C: Tpm. Status C S: Get. Tpm. Status Ready. State$1 Violates Autonomous condition IO_RUNNING S C: Tpm. Status C S: Get. Tpm. Status IO_RUNNING$0 S C: Tpm. Status IO_RUNNING$1 S C: Send. Complete

Model checking efficiency • Explicit state verification is expensive using asynchronous communication – Exponential Model checking efficiency • Explicit state verification is expensive using asynchronous communication – Exponential state space explosion in the worst case • Example: Blowup. KContract S 1 S C: m 2 S C: m 1 S C: m 2 … S C: m 1 C S: m 3 S C: m 2 Sk

Model checking efficiency • If contract is realizable, conversations generated using asynchronous communication and 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 S 1 S C: m 2 S C: m 1 S C: m 2 … S C: m 1 C S: m 3 S C: m 2 Sk

Tune: A Tool For Analyzing Sing# Contracts Consumed by Produces Channel Contract File LTL Tune: A Tool For Analyzing Sing# Contracts Consumed by Produces Channel Contract File LTL Formulas Sync Promela Contract Parser Contract State Machine 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 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 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 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 (Tpm. Contract and Reservation. Session) • 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 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 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 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 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 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, 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 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’ 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, Mc. Ilraith Related Work • Verification of web services – Petri Nets • [Narayanan, Mc. Ilraith 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, 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, De. Giacomo, Hull, Mecella VLDB’ 05]

THE END THE END