.NET Actor Model Implementations Differ in Approach

Last week Vaughn Vernon, author of Implementing Domain-Driven Design, published Dotsero, a .NET Actor model toolkit written in C# that closely follows the Akka API. The Akka toolkit, an implementation of the Actor model, has so far been available with a Java and a Scala API.

A preview release of the Orleans framework, a cloud programming model also based on the actor model, was released earlier this year by Microsoft Research with a goal of minimizing the challenges when building interactive services that are scalable and reliable.

The Orleans team believes that although actor platforms such as Erlang and Akka are a step forward in simplifying distributed system programming, they are still burdened with many complexities because of the relatively low level of provided abstractions and system services. To build a correct solution they claim that a developer must be a distributed systems expert. To avoid these complexities and targeting mainstream developers the team has raised the level of the actor abstraction in Orleans. It is actor-based, but differs from existing actor-based platforms by treating actors as virtual entities, not as physical ones.

In a recent twitter discussion between Vaughn and Sergey Bykov, lead of the Orleans project at Microsoft Research, Vaughn claimed that Orleans is not really an Actor model implementation partly due to its lack of Become/Unbecome to support a Finite State Machine (FSM) which Vaughn claims is part of the original definition of actors. He also believes the fact that an Orleans actor always exists is error prone by making it hard for a client to realize if it’s asking for something that doesn’t exist.

Sergey answered by claiming that Become is just one way of reading the definition and therefore not a requirement of the actor model. In his experience he has also found that the fact that an Orleans actor always exists is much less error prone since it eliminates races and simplifies recovery. Cases where an actor shouldn’t exist are handled by application logic returning an error, which he admits it’s not ideal but still better than experiencing racing conditions when creating actors.

Recently Richard Astbury, a Microsoft MVP for Azure, created a simple Internet of Things gateway application to demonstrate his view of how Orleans can help developers in building high scale, low latency and resilient .NET applications for the cloud. Richard notes that although it’s a trivial example, it contains the basic building blocks for building more complicated scenarios.

A paper, Orleans: Distributed Virtual Actors for Programmability and Scalability, presenting the design principles behind Orleans was published in March.

Vaughn talked last year about Actor model in reactive domain-driven design (DDD) and in an earlier talk about the foundation for actor model together with DDD.