BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

.NET Actor Model Implementations Differ in Approach

by Jan Stenberg on Jul 21, 2014 |

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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

There is also Akka.Net by Faisal Waris

See github.com/akkadotnet

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.

Internet of Things link by Michael Donkhin

The link to MSDN article by Richard Astbury is dead.

Re: Internet of Things link by Jan Stenberg

There seems to be some problem with the MSDN site. If it doesn't work, copy the link and try again after an error, for me it will always show up. I've tried with different browers and incognito windows.

Thanks for informing about the problem,
Jan

Re: Internet of Things link by Michael Donkhin

Yep, now it's OK.
Thanks!

Akka.NET by Roger Alsing

I am the founder of Akka.NET so I thought I should fill in some blanks about it:

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..

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT