6. Related Work

We compare Orleans to general-purpose distributed programming frameworks and to actor frameworks.

6.1 Distributed Programming Frameworks

Although Orleans runs on both Windows Azure and Windows Server, nearly all current applications use Azure. It is therefore comparable to any framework for cloud application development. One well known framework is Google App Engine (GAE). Although both GAE and Orleans offer object-oriented programming models, they differ in two main respects. First, GAE’s object model is that of Java or Python, with synchronous RPC and multithreading. By contrast, Orleans offers an actor model, with asynchronous RPC and single- threading. Second, Orleans is agnostic about database services. By contrast, GAE has a built-in database service with transactions. Distributed object models such as Enterprise Java Beans (EJB), Distributed Component Object Model (DCOM), and the Common Object Request Broker Architecture (CORBA) have some similarities with actor frameworks. Unlike Orleans, they are primarily based on synchronous communications, although some also provide asynchronous communication too, such as Message-Driven Beans in EJB. Unlike Orleans, they require static placement of objects, e.g., by mapping class-to-server or class-partition-to-server, and allow multithreaded servers where objects can share state. None of them offers a virtual actor abstraction. However, they do provide many useful functions beyond those in Orleans: transactions, reliable messaging, request queuing, and publish-subscribe. A lot of work has been done to improve the performance of multi-tier architectures via caching ([9][11][13][14][16][19]). This however moves the burden of ensuring data consistency and data integrity semantics to the application. The function shipping paradigm like the actor model eliminates this problem.

6.2 Actor Frameworks

Orleans combines techniques from many previous actor systems. The comparison of actor frameworks in [7] identifies five key properties: state encapsulation, safe message passing (pass by value with deep copy), location transparency, mobility, and fair scheduling. Orleans fully supports the first three. It supports weak mobility—an actor can be moved from one machine to another but not while processing a request. It supports best-effort fair scheduling: in a well-behaved application every actor receives its fair share of CPU time. Erlang is a functional programming language with an associated actor model [3]. An Erlang actor is called a process. As in Orleans, each actor is single-threaded, accessed via a logical reference, and communicates with other actors via one-way messages. In principle, an actor has only private state, though in practice actors often share state in tables or a registry. Unlike Orleans, Erlang actors are explicitly created. The spawn operation creates an Erlang process on either the caller’s server (the default) or a remote server (specified in an argument). After the process is created, its location cannot be changed. This prevents important optimizations found in Orleans: dynamic load balancing across servers, actor migration, and automatic server failure-handling by restarting its actors on other servers. An Erlang application explicitly controls how errors propagate from one process to another by using the link operation. If a process is not linked to another process and raises an unhandled exception, it silently dies. By contrast, in Orleans, exceptions automatically propagate across the distributed call chain via promises. The Open Telecom Platform (OTP) extends Erlang’s runtime with capabilities that insulate the application from fault tolerance, distribution, and concurrency aspects. To enable application-specific error handling, it has an optional module that keeps track of a supervision tree, which is the tree of processes induced by process creation. It offers two options for handling a child failure: either its supervisor recreates it or its siblings are killed and the supervisor recreates them. While flexible, this requires the developer to explicitly manage each actor’s lifecycle. By contrast, in Orleans, there is no creation hierarchy. Actors are automatically created and garbage collected by the runtime. If an actor’s server fails, the actor is automatically re-created on a different server. This automatic lifecycle management greatly simplifies programming. Akka [2] is an actor-based programming framework for Java and Scala. Like Orleans, each actor is single- threaded, has only private state and is accessed via a logical reference. Akka guarantees at-most-once message delivery and FIFO ordering between every pair of actors. Unlike Orleans and like Erlang, actors are explicitly created in Akka and the creation hierarchy drives exception handling. In Akka, each actor is logically named by a path ex- pression that reflects the supervision hierarchy. Orleans uses a class type and a key. Akka uses physical paths for remote actor references. As in Erlang, an actor’s location is fixed at creation time, which prevents dynamic load balancing, actor migration, and automatic handling of machine failures. Akka has features not covered by Orleans, such as the ability to load new code into an actor at runtime and a transaction mechanism, which ensures the effect of a set of actor invocations is atomic. However, these only apply to actors on the same machine and are thus inapplicable to a distributed actor model. A prototype of Orleans was described in [5]. That earlier version did not support all aspects of virtual actors. Rather, it required explicit lifecycle management of actors. It automatically persisted actor state on every call, which was too expensive for our production users. This led us to the persistence mechanism in Section 2.6. It used a more explicit syntax for promises and continuations, which we replaced by the more succinct async-await syntax of .NET 4.5 and a modified Orleans runtime to support it. It offered a multi-master replication scheme for multi-activation actors, which we dropped because it failed to deliver good performance and our users found it too complex. The measurements in [5] were only for micro-benchmarks, not large-scale production scenarios as in Section 5. Other Actor Frameworks - There is a variety of other actor programming models. Kilim [16] focuses on single-node execution, and uses thread-switching for modeling actor execution and inter-actor communica- tions. ActorFoundry [1] uses synchronous send/receive communication between actors instead of asynchronous, continuation-based APIs used in Orleans. Thorn [4] (and Erlang) use loosely-typed, dynamic actor interfaces which require care to match sender and receiver code to ensure correct messaging semantic. Orleans uses strongly-typed interfaces, which allow easy compile- time consistency checking. Monterey is an actor-based framework for Java [12]. As in Orleans, an application uses a key to obtain an actor reference. Unlike Orleans, it requires explicit lifecycle management of actors. It al- lows synchronous communication (though it warns this may cause performance problems) and multithreaded actors. Orleans allows neither.