.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.
There is also Akka.Net
It is a port of Scala Akka and has a nice F# API.
I personally don't have any experience with them (other than base F# actors which are not distributed) but plan on working with at least of them this year.
Re: Internet of Things link
Thanks for informing about the problem,
Regarding the F# API, it is distributed, infact you can remote deploy new code just like erlang using the F# API (due to code quotations in F#)
We have a full port of Akka.Actor, Akka.Remote and Akka.TestKit.
There is also work in progress on Akka.Cluster.
And I do agree with Vaughn regarding Orleans, Become is part of the original definition.
But maybe worse IMO, is that since Orleans have their virtual actors, if you have a network split, you might end up with the same actor in two or more partitions.
Which effectivly breaks the actor model since now you have atleast two threads (on different machines) processing messages, thus breaking the internal actor consistency.
e.g. you can get race conditions with yourself, which is one of the problems that should actors solve..
Sarah Howe Jul 06, 2015