. .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . RFC 684 "Rather, we take exception to PCP’s underlying premise: that the procedure calling discipline is the starting point for building multi-computer systems." Commentary on RFC 674, which introduces the Procedure Call Protocol, Version 2. (PCP). Procedure calling is usually a primitive operation Local vs. remote calls have different cost profiles Message passing instead of procedure-calling is a better model Situations where the concept is weak: Difficulty to recover from malfunction or errors (rollback vs. execption) Difficult to sequence operations Synchronous; geared towards one-to-one call-return Backpressure and load-shedding becomes harder (priority servicing) Waldo et al (Sun) A Note On Distributed Computing Papers We Love, Boston 7 / 32
. .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . RFC 707 "Because of this cost differential, the applications programmer must exercise discretion in his use of remote resources, even though the mechanics of their use will have been greatly simplified by the RTE. Like virtual memory, the procedure call model offers great convenience, and therefore power, in exchange for reasonable alertness to the possibilities of abuse." Generalizes the request/response mechanism that services such as TELNET and FTP use to a procedure call mechanism that is usable by machines, not humans. Makes similar control flow argument. Waldo et al (Sun) A Note On Distributed Computing Papers We Love, Boston 8 / 32
. .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . It’s Just a Mapping Problem (2003) “The goal is to merge middleware abstractions directly into the realm of the programming language, minimizing the impedance mismatch between the programming language world and the middleware world. For example, mappings make request invocations on distributed objects and services appear as normal programming-language function calls, and they map distributed system exceptions into native programming language exception-handling mechanisms.” [12] Argues transparency is how quality is measured by developers. References current work as a case of transparencies masking failures. Waldo et al (Sun) A Note On Distributed Computing Papers We Love, Boston 11 / 32
. .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . Objects "It is the thesis of this note that this unified view of objects is mistaken." [7] Interfaces defined in an Interface Definition Language (IDL) Extension of the RPC mechanism to the object-oriented paradigm Abstracts how to perform the operation We’ve learned already that local and remote calls are not the same Waldo et al (Sun) A Note On Distributed Computing Papers We Love, Boston 13 / 32
. .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . Three False Principles "there is a single natural object-oriented design for a given application, regardless of the context in which that application will be deployed" "failure and performance issues are tied to the implementation of the components of an application, and consideration of these issues should be left out of an initial design" "the interface of an object is independent of the context in which that object is used" Waldo et al (Sun) A Note On Distributed Computing Papers We Love, Boston 15 / 32
. .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . Partial Failure and Concurrency "The question is not “can you make remote method invocation look like local method invocation?” but rather “what is the price of making remote method invocation identical to local method invocation?”" [7] Core problems in distributed systems: ensuring consistent state Consensus, agreement Indeterminacy Two possible paths to a unified object model: Treat all objects as local Treat all objects as remote Concurrency shares the same problembs Waldo et al (Sun) A Note On Distributed Computing Papers We Love, Boston 20 / 32
. .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . Partial Failure and Concurrency "This approach would also defeat the overall purpose of unifying the object models. The real reason for attempting such a unification is to make distributed computing more like local computing and thus make distributed computing easier. This second approach to unifying the models makes local computing as complex as distributed computing." [7] Waldo et al (Sun) A Note On Distributed Computing Papers We Love, Boston 21 / 32
. .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . Convenience Over Correctness (2008) "We have a general-purpose imperative programming-language hammer, so we treat distributed computing as just another nail to bend to fit the programming models." [13] Impedance mismatch with Interface Definition Languages (IDL) Base types are easy to map; more complex types are less so Concerns over scalability RPC mechanism lacks metadata for caching Representational State Transfer (REST) is a good mechanism Building frameworks on top of this is a repeat of the problem Waldo et al (Sun) A Note On Distributed Computing Papers We Love, Boston 26 / 32
. .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . .. . . . .. . . . . .. . . . .. . . . . .. . . . .. . . . .. . References II B. Charron-Bost. Concerning the size of logical clocks in distributed systems. Inf. Process. Lett., 39(1):11–16, July 1991. N. Conway, W. R. Marczak, P. Alvaro, J. M. Hellerstein, and D. Maier. Logic and lattices for distributed programming. In Proceedings of the Third ACM Symposium on Cloud Computing, SoCC ’12, pages 1:1–1:14, New York, NY, USA, 2012. ACM. S. C. Kendall, J. Waldo, A. Wollrath, and G. Wyant. A note on distributed computing. Technical report, Mountain View, CA, USA, 1994. L. Lamport. Time, clocks, and the ordering of events in a distributed system. Commun. ACM, 21(7):558–565, July 1978. Waldo et al (Sun) A Note On Distributed Computing Papers We Love, Boston 30 / 32