Realizability Analysis for Message-based Interactions Using Shared-State Projections Sylvain Hallé Université du Québec à Chicoutimi, Canada shalle@acm.org Tevfik Bultan ∗ University of California, Santa Barbara, USA bultan@cs.ucsb.edu ABSTRACT The global interaction behavior in message-based systems can be specified as a finite-state machine defining acceptable sequences of messages exchanged by a group of peers. Re- alizability analysis determines if there exist local implemen- tations for each peer, such that their composition produces exactly the intended global behavior. Although there are existing sufficient conditions for realizability, we show that these earlier results all fail for a particular class of speci- fications called arbitrary-initiator protocols. We present a novel algorithm for deciding realizability by computing a finite-state model that keeps track of the information about the global state of a conversation protocol that each peer can deduce from the messages it sends and receives. By search- ing for disagreements between each peer’s deduced states, we provide a sound analysis for realizability that correctly classifies realizability of arbitrary-initiator protocols. Categories and Subject Descriptors B.4.3 [I/O and Data Communications]: Interconnec- tions (Subsystems)—Asynchronous/synchronous operation, Web technologies ; D.2.1 [Software Engineering]: Re- quirements/Specifications—Tools, validation General Terms Verification Keywords realizability, asynchronous communication, choreography 1. INTRODUCTION Nowadays, many software systems consist of multiple components that execute concurrently, possibly on differ- ent machines. New trends in computing, such as service- oriented architecture (SOA), cloud computing, multi-core ∗ This work is supported by NSF grants CCF-0916112 and CCF-0716095, and by the Fonds qu´ eb´ ecois de recherche sur la nature et les technologies (FQRNT). Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. FSE-18, November 7–11, 2010, Santa Fe, New Mexico, USA. Copyright 2010 ACM 978-1-60558-791-2/10/11 ...$10.00. hardware, all point to more concurrency and distribution among the components of software systems in the future. In order to complete a task, components of a software system have to coordinate their executions by interacting with each other. A fundamental question is, what should be the in- teraction mechanism given the trend for increased level of concurrency and distribution? One emerging paradigm is message-based communication [3, 5, 8, 15, 18, 19, 21], where components interact with each other by sending and receiv- ing messages. This is particularly the case for SOA, which, through the use of SOAP and XML, enable interaction among existing services to form composite, value-added applications. A key factor in SOA is the loose coupling between the various parties involved in an interaction. Apart from a mutually- agreed protocol of interaction (called a conversation proto- col [10,11] or a choreography specification [22] in SOA), each peer taking part in such a global “conversation” is an inde- pendent and self-contained unit. To further loosen this coupling between potential part- ners, many web services are implemented using asyn- chronous communication. While in synchronous communi- cation, the sender and receiver of a message are required to block their operation for the duration of the message transfer, in asynchronous communication this restriction is relaxed by treating sending and receiving as two separate events. The recipient of a message is no longer required to synchronize with the sender, and can rather buffer messages in an input queue and process them at an arbitrary later time. Interestingly, the same type of message-based interactions appear in other domains as well. For example, Singular- ity is a new, experimental, operating system developed by Microsoft Research to explore new approaches to OS de- sign [14]. One of its main goals is to improve the depend- ability of software systems by rethinking some design de- cisions that have largely governed operating system archi- tecture to date. Process isolation is a chief design princi- ple of the Singularity operating system. To achieve process isolation, certain constraints are enforced to ensure process independence. Among these is the rule that processes can- not share memory with each other or the kernel. All inter- process communication in Singularity, therefore, occurs via message passing over bidirectional conduits, called channels. Channels have two end points referred to as the client and the server that communicate with each other by sending and receiving messages. Communication through Singular- ity channels corresponds to asynchronous communication 27