UNIVERSITY OF CALIFORNIA, IRVINE Computational State Transfer: An Architectural Style for Decentralized Systems DISSERTATION submitted in partial satisfaction of the requirements for the degree of DOCTOR OF PHILOSOPHY in Information and Computer Science by Michael Martin Gorlick Dissertation Committee: Professor Richard N. Taylor, Chair Associate Professor James A. Jones Professor Crista V. Lopes 2016 Copyright © 2016 Michael Martin Gorlick DEDICATION To the memory of my mother Doreen Viola Gorlick (née Rose) December 1927 – February 2015 and my brother Patrick David Gorlick February 1953 – December 2008 ii TABLE OF CONTENTS Page LIST OF FIGURES vi LIST OF TABLES viii ACKNOWLEDGMENTS ix CURRICULUM VITAE xi ABSTRACT OF THE DISSERTATION xv INTRODUCTION 1 CHAPTER 1: Computation Exchange — From Idiom to Style 14 Thesis and Claims 15 Architecture Can Induce Security 17 Architecture Can Induce Adaptation 18 Capability Confines Risk 27 Computation Exchange: A Historical Perspective 28 Security for Computation Exchange 32 Summary 34 CHAPTER 2: COAST Roots — A Brief History of Mobile Code 35 Early History of Mobile Code (1960–1985) 35 Remote Function Evaluation (1987) 37 Remote Evaluation (1986) 38 Mobile Objects 38 Functional Mobile Code Languages (1995–2007) 41 Mobile Agents 45 Mobility Semantics (1996) 47 COAST Dictates Language Semantics and Infrastructure 49 CHAPTER 3: Computational State Transfer: The Style 50 The Threat Model of Computation Exchange 51 The Communication Model of COAST 54 The COAST Architectural Style 60 COAST Scenarios 64 A Notional COAST Infrastructure 66 Capability URLs in Detail 69 Computations and Identity 74 iii Summary 77 CHAPTER 4: Obligations of the COAST Style 80 Obligations of the COAST Services Rule 80 Obligations of the COAST Execution Rule 84 Obligations of the COAST Messaging Rule 90 Obligations of the COAST Interpretation Rule 92 What the COAST Style Leaves Unsaid 94 Summary 96 CHAPTER 5: Motile: Reflecting the Style 99 Frameworks 99 Domain-Specific Languages (DSLs) 100 Architectural Style-Specific Languages 101 Lessons Learned 102 Motile Binding Semantics 103 Islets and Message Passing 106 Decentralized Promises 110 Spawning 113 Example: A Client Computation for Palindromes 119 Remote Evaluation 120 Summary 123 CHAPTER 6: How Mobile is Motile and Why? 127 Weakness is a Greater Good 127 Intra- versus Inter-island Messaging 132 Intra-Island Messaging 136 Is Intra-Island Messaging COAST-Compliant? 139 Summary 140 CHAPTER 7: Motile: The Details 142 Expressions 142 Derived Expressions 143 Macros 144 Standard Procedures 144 Persistent Functional Data Structures 149 Syntax 160 CHAPTER 8: Evaluation: Live Update 165 Evaluation Criteria 166 Exploiting Binding Environments for Live Update 171 CURL-based Live Update 174 More General Forms of Live Update 175 Live Update for COAST 176 Related Work 187 Summary 188 CHAPTER 9: Evaluation: Web API Design 191 Web Service Design from a COAST Perspective 191 iv The Delicious API 193 Delicious as a COAST-Based Service 194 A Motile API for Delicious 196 Client-defined Extensions of the Motile API for Delicious 200 Performance 217 Summary 218 CHAPTER 10: Evaluation: Security 223 COAST is Authority-Safe 225 Motile/Island is Capability-Safe Hence Authority-Safe 226 Related Work 233 Summary 234 CHAPTER 11: Evaluation: Architectural Accountability 236 Approach: Capability is in Plain Sight 237 Early Experimental Evidence 239 Related Work 239 Summary 241 CHAPTER 12: Summary 243 CHAPTER 13: Future Work 247 Types for Live Computations 247 Extending Execution Engines 248 Service Discovery as a COAST Service 248 Pervasive Live Update 249 Fractalware 249 Integration with Existing Legacy Systems 249 Simplifying Motile/Island 250 References 251 v LIST OF FIGURES Page Figure 1.1 Growth in public web APIs by protocol 22 Figure 1.2 Growth in number of public web APIs 23 Figure 3.1 A generic transport with multiple ingress and egress points 55 Figure 3.2 A dedicated transport between computations x and y 56 Figure 3.3 Notional sketch of a COAST infrastructure 67 Figure 5.1 A Motile predicate to test for palindromes 106 Figure 5.2 A design pattern for variants of a spawning service 115 Figure 5.3 The client implementation of spawning 116 Figure 5.4 Spawning an islet to remotely compute palindromes at a dictionary service 119 Figure 5.5 Using curl/remote* to compute palindromes at a dictionary service 121 Figure 5.6 Using curl/remote to compute palindromes at a dictionary service 122 Figure 5.7 Using curl/remote/block to compute palindromes at a dictionary service 122 Figure 5.8 Implementations of curl/remote and curl/remote/block 124 Figure 6.1 Capture bindings from an execution site binding environment 135 Figure 8.1 Repair a defective implementation of a function in a binding environment 171 Figure 8.2 Notional nanoservice loop 177 Figure 8.3 The closures spawned on island I to create nanoservice f + 181 Figure 8.4 A simple higher-order generator 185 Figure 8.5 Spawn skeleton/f+ to undertake the live update of nanoservice f 186 Figure 9.1 Sample bookmark tags 196 Figure 9.2 A few utility functions for inspecting and querying tags 196 Figure 9.3 A client-defined routine for discovering the latest bookmark 200 Figure 9.4 iterate/fold 201 Figure 9.5 iterate/filter 201 Figure 9.6 iterate/map 202 Figure 9.7 iterate/pipe 202 Figure 9.8 Determine the number of bookmarks introduced per day 203 Figure 9.9 For each day generate a list of the bookmarks introduced on that day 205 Figure 9.10 For each day generate a list of the ids of the bookmarks introduced on that day 206 Figure 9.11 For each tag namespace α determine the bookmarks that mention α 207 Figure 9.12 Find all bookmarks that reference a photo of a roller-coaster 208 Figure 9.13 Function list/find finds the first item in a list that satisfies a predicate p. 209 Figure 9.14 Client-defined helper predicates for searching and querying bookmark tags 209 vi Figure 9.15 Search for all bookmarks that refer to a location. 210 Figure 9.16 Search for all bookmarks that refer to a location in France or Germany 211 Figure 9.17 Search the bookmarks for a photo of a roller coaster in either France or Germany 212 Figure 9.18 iterate/append 213 Figure 9.19 iterate/append is the source of bookmarks for iterate/pipe 214 Figure 9.20 iterate/compose/right extends combinators that accept a pair of generators 219 Figure 9.21 iterate/append* accepts m > 2 generators 219 Figure 9.22 Using iterate/pipe to form generators for iterate/append 219 Figure 9.23 The outputs of multiple generators can be interleaved in useful ways 220 Figure 9.24 iterate/temporal* 220 Figure 9.25 iterate/merge 221 Figure 9.26 iterate/temporal merges two streams in temporal order 221 Figure 9.27 iterate/limit enforces a limit-stop for generators 221 Figure 9.28 Remote evaluation of a search through interleaved bookmarks 222 Figure 11.1 A model financial trading system 240 Figure 11.2 A verification model for financial trading 242 vii LIST OF TABLES Page Table 3.1 The four levels of the Unifying Policy Hierarchy 52 Table 9.1 The Delicious HTTP interface for searching and manipulating bookmarks 193 Table 9.2 The Delicious HTTP interface for searching and manipulating tags 194 Table 9.3 The fields of a bookmark 196 viii ACKNOWLEDGMENTS If it takes a village to raise a child it takes a small mob to usher a doctoral student through advancement to candidacy and from there to final defense. In the spring of 2004 I approached my colleague and friend Dick Taylor with an unusual request: would he consider, given that our professional relationship stretched back to 1976 when we were both graduate students at the University of British Columbia, taking me on as a doctoral student? I will forever treasure his expression of shock and surprise when I popped that question. He bravely and recklessly assented; following the customary tedium of exams, forms and fees, I officially enrolled in the doctoral program at the University of California, Irvine on October 1, 2004 at the tender age of 53. I am deeply indebted to Dick for his willingness to take a flyer on me when any other rational man of letters would have dismissed me as an old fool. It has been a challenging slog from that first day to my thesis defense more than 11 years later. There was a running joke in the department as to which would come first, my doctorate or a Social Security check. I’m pleased to report that those of you in the betting pool who put your money on the Social Security check lost. Along the way I benefited greatly from the kindness and support of friends, many of them my fellow doctoral students. My first office mate was Eric Dashofy, who made the mistake of seriously entertaining my speculations on software architecture and then responding with articulate, well-informed arguments and observations. I repaid his kindness, upon his defense and graduation, by recommending him for a position at The Aerospace Corporation, my employer then, and now. His first office at Aerospace was next door to mine. Eric has risen quickly through the Aerospace ranks; I’m not sure that he will ever forgive me for entrapping him. My second office mate was Justin Erenkrantz, former president of the Apache Foundation and a re- spected figure of the open-source community. Justin became both a friend and colleague and I enjoyed our time together immensely. We quickly discovered our common interest in internet-scale architectures and began, almost immediately, vigorously debating the architectural future of the web.