Different ways to implement the Actor model in. Net

Last week, Vaughn Vernon, author of the Implementing Domain-driven design, published Dotsero, a "based on", written in C #. NET's Actor Model Toolkit, which is implemented with reference to the Akka API. The Akka Toolkit is an implementation of the actor model, so far there are APIs that correspond to Java and Scala versions.

Earlier this year, Microsoft Research also released a framework based on the actor model, a preview version of the Orleans framework. The framework uses a cloud-based programming model, which is designed to minimize the challenges of creating interactive services that tend to be highly scalable and reliable.

The Orleans team believes that while the actor platforms of Erlang and Akka have taken a step forward in simplifying the programming of distributed systems, their complexity remains high because they provide a relatively low level of abstraction and system services. Developers have to be experts in distributed systems to create the right solution using these tools. To avoid these complexities and to attract mainstream developers, the Orleans team promoted the level of abstraction of the actor. While it is still based on the actor model, it differs from any existing actor-based platform: it treats the actor as abstract rather than as a physical entity.

Recently, Vaughn and Orleans, the leader of the project, Sergey Bykov, from Microsoft's Department, had a discussion on Twitter. Vaughn that Orleans is not essentially an actor-based implementation, in part because it lacks become and unbecome methods to support finite state machines (FSM). And Vaughn that this is a necessary part of the actor's original definition. He also believes that because the actor is always present in Orleans, it is difficult to realize this when the client initiates a request for an actor that should not exist, which can easily cause problems.

Sergey in response that become is just one way to read the definition, not part of the actor model. From his experience, since the actor in Orleans has always existed, thus reducing the generation of race conditions and simplifying the recovery operation, the likelihood of this problem is much smaller than that of Vaughn. If an actor is not supposed to exist, it can be handled by returning an error state from the application logic, although he admits that this is not ideal, but it is better than encountering a race condition when creating the actor.

Recently, a Microsoft Mvp,richard Astbury in Azure has created a simple IoT gateway application to demonstrate his view of Orleans that Orleans can help developers create large-scale, low-latency, and well-adapted in the cloud. NET application. While this is a simple example, Richard says it already contains the various base building blocks needed to create more complex scenarios.

This March, a paper entitled "Orleans: Distributed virtual actor for programmability and scalability" specifically explains the design principles behind Orleans.

Vaughn last year talked about the actor model in an article on responsive field-driven design (DDD) and talked about the generation of actor models and the related topics of DDD in a previous speech.

Different ways to implement the Actor model in. Net