Programming the Cloud with Actors: Inside ActorFx

Play Programming the Cloud with Actors: Inside ActorFx
Sign in to queue


ActorFx is an MSOpenTech open source project with the goal of providing a non-prescriptive, language-independent model of dynamic distributed objects. This will in turn provide a framework and infrastructure on top of which highly available data structures and other logical entities can be implemented.

ActorFx (aka Ax) is based on the idea of the Actor Model developed by Carl Hewitt. Erik Meijer figured this model would fit perfectly into the realm of managing data in the cloud. See his paper on the topic, which is the basis for the ActorFx project. You can learn more about the Actor Model in this Channel9 video with Carl and Erik.

Here, the lead developers of ActorFx - Brian Grunkemeyer and Joe Hoag - join us to dig into some of the details of the technology. We also discuss the potential of Actors in the cloud, the problems they solve, how you program with them on the client (CloudList<T> is an interesting "cloud-enabled" type, for example), and potential applications of this approach to scalable distributed computing.



Right click to download this episode

The Discussion

  • User profile image

    So beautiful

  • User profile image

    It is similar to Kudzu's Tarakans

  • User profile image

    I dont mean to be negative, but:

    • magic strings
    • pseudo-dynamic
    • reflection


  • User profile image

    Is this looking to fill the same space in .NET that something like Akka fills in Java?  Thanks.

  • User profile image

    @luzi:I admit that "magic" strings make me cringe a little but after dealing with distributed systems for a number of years and all the headaches around versioning and in place upgrades, etc...  Even something as simple as an enum can be a real pain.  I'm fine with the "magic" strings as long as their are nice abstractions on top of them.  I would consider the "magic" strings almost like Assembly or IL, Wrap them nicely then you only rarely have to think about them. Smiley

  • User profile image

    Let me first say I love the idea. However, one question I would love to hear answered is how is ActorFx not succeptible to the same issues that lead us to drop things like Corba and RPC.

  • User profile image
    Matthew Moloney

    Hi folks,

    Durable actors through replication is an important feature which Akka sorely lacks. So well done on that.

    However, as previously mentioned, magic strings, pseudo dynamic, and reflection are all vomit inducing terrible.

    What I don't get is how you built an actor system without focusing on State Machines and Message Passing. What you appear to have built is something completely different.


  • User profile image
    Joe Hoag

    [From Joe Hoag, one of the presenters]

    Thanks for all of the feedback. Sometimes during live tapings it is easy to give unsatisfactory or incomplete explanations of things, or to gloss over important details.

    So let me clarify/respond to a few things:

    "MAGIC STRINGS": I admit that I’m a bit puzzled by this, but I’m assuming that it is referring to the strings that we pass as method names. This is simply a mechanism for late-bound methods. We call an actor method by passing its name in the form of a string, and we use that string to look up the method implementation (delegate) in the key-value store.

    This late binding of methods makes it very easy to update actor method logic “on the fly” without requiring that the service be restarted.

    I suppose that “Magic Strings” could also be referring to the fact that the keys in our key-value store are strings. Consider this to be analogous to the naming of a property in a .NET object. In conventional C#, you might have a property “Foo” and you would access it with “someObject.Foo”. In an actor method, you would access the property “Foo” via calling the Set/Get/TryGet on the IActorState object, passing in the string “Foo” as the key.

    And, by the way, we will soon be implementing support for C# actor methods that reference a dynamic IActorState object. This will make it possible to reference property “Foo” via “state.Foo”, bypassing the need to explicitly call state.Set/Get.

    REFLECTION: The only place where we use reflection is in the processing of an AddAssembly call, when we mine actor delegates from the assembly that is passed in. For each actor method that we identify in the assembly, we store a delegate in the key-value store, where the key is the method name and the value is a Func<IActorState, object[], object>.

    Reflection is not used in the process of calling an actor method. Calling an actor method involves a dictionary lookup of the method name followed by a direct call to the resulting Func<IActorState, object[], object>.

    MESSAGE PASSING: Within actor methods, we allow for direct calling of methods on other actors, as well as subscribing to events emitted by other actors. Does this not qualify as message passing? And if you want to allow for the passing of arbitrary byte streams, all that you have to do is implement an actor method that accepts a byte stream as a parameter, and then processes it in whatever way that you see fit.

    Hope this helps,

  • User profile image

    I wasn't bothered by "magic strings" although you could perhaps use C# 4 dynamics but not sure I'd prefer that.

    I like the story about Rx integration and lifting objects to the cloud and can see why that is appealing. By the time you have a cloud backend I'm probably ready play with it, after my current project is v1.

    It's quite stimulating to think about wat kinds of applications one might build with this technology.

    Say, how about a P2P backend as well? - Hey, Windows has P2P built-in with PNRP. Smiley

  • User profile image

    Trying to build and run sample. Ran into two issues.

    1) Namespace is "$safeprojectname$", which fails to compile. Is this a left over from internal build system?

    2) Project references System.Fabric, which is broken link. Where does System.Fabric exist?  I did install the msi already.


  • User profile image

    Is there a way to solve the late binding method name deal so you can leverage .Net intellisense and compile time checking for method names?

  • User profile image

    Another question is if you can dynamically discover actors and their methods - as if they were Web Services. Perhaps this could be coupled with F# 3 type providers via an actor type provider to "dot into" actors, their methods (or events) and the returning state.

    In this open world, perhaps you can even allow your actors to interact with "foreign actors" - other applications in a truly internetworked way - and perhaps associate billing semantics to method calls or data and CPU usage.

    Mesh into that P2P actors and this will be quite the interesting creature.

    It could also turn into a brittle beast perhaps - when API's change in an open world and things start to break - transitively.

  • User profile image
    Matthew Moloney

    G'day Joe,

    "Magic Strings" typically refers to the fact that you have to 'just know' as if by magic the strings you need in order to use the API. In this case method names and dictionary keys. From memory the dynamic object merely hides the magic thereby making it substantially more difficult find bugs.

    As previously mentioned by AceHack a possible way of factoring out the "magic" would be through wrapping it (e.g. behind an Enum which will both type check for intellisense and errors).

    My preferred method for 'typed' message passing is the use of Structural Typing - Akka Scala uses Case Classes (aka Union Types) and Erlang uses globally defined atoms.

    REFLECTION: I consider a checked downcast to be type introspection (reflection), and given the use of objects in methods and the state it looks like reflection will have to be used quite often in the body of the actor methods. I understand this design is needed to allow in place updating of the behavior but it is a side effect of not having structural typing and pattern matching which is your bigger problem.

    My apologies I should have been more precise about how I talk about message passing. I meant asynchronous message passing... synchronous message passing to me means method invocation. PubSub is a not a replacement for async message passing and suggesting that I build my own on top of byte stream makes it look like you are missing the point of an actor framework.

    No mention of State Machines?

  • User profile image


    1) Strings. Calling by method name (i.e. string) has the high road in terms of loose coupling. To gain the local typing, could always wrap in a typed client proxy class (or the tool could build them like service references). Not sure how enums would be used in terms of calling methods. But auto generated typed proxies from meta-data on the uri seems to work fine in other remoting frameworks. And the lower layer stays loose. I suppose a win-win. I am curious if a meta-data public interface method will be added to return method/property names and return types.

    2) Reflection. I am not clear where you feel reflection would be required in a method body. Maybe a use case example would help.

    3) Message passing.  Sync or Async, it is message passing either way.  You can layer async on any sync method or visa-versa.  AFAICT their Pub/sub is orthogonal to the subject of sync or async method invocation (i.e. message passing).

    4) State Machines. I see nothing stopping one from implementing state machine in the actor and methods do actions based on current state. If, on the other hand,  IAsyncState consistency is the concern, then that appears to be handled by correct construction of running delegates syncronously on a single thread. I may have missed your intention.

  • User profile image
    Matthew Moloney

    @Staceyw Look I don't get anything out of disagreeing with people on the net - I've said my 2c and now I'm checking out. All the best.

  • User profile image


    Namespace is "$safeprojectname$", which fails to compile. Is this a left over from internal build system?

    You must have opened the template directly. Check Developer Environment / Setup in the documentation.


  • User profile image

    In .net if you load an assembly then there is no way to unload it (with the exception of collectable assembly ... but we cannot get them form source, then they are not very practical solutions).
    Consequently, long running programs will consume more and more memory for the new assembly (there is AddAssembly in ActorFx framework).
    So this is not a solution for long running applications.
    This is a very old problem of .net and as far as I know Microsoft is not going to fix it.
    Because of that problem .net is probably not the best programming tool for creating dynamic applications.

  • User profile image


    Am I the only seeing relation between this and Azure Service Bus Queues, Topics, Notification Hubs and the whole Pub/Sub business that we have in the cloud already? To me it seems like yet another alternative to EAI.


    It would be cool however to be able to send actors to a queue/topic that some remote service is subscribed to. Essentially spreading self contained bits of computation to whoever is interested in them in an organised manner (Pub/Sub, smart proxies which are part of service bus etc..). Ultimately leading to one centralized database of readily available actors that you and I could have access to (with or without subscription fee). From there on, mash up some actors together to create whatever application you desire and enjoy the new way of "LEGO" building.


    One can but dream... Wink


  • User profile image
    Joe Hoag

    First off, let me clarify that the ActorFx project is in a very early state (release 0.2, to be precise), and still has lots of room for evolution. So we really appreciate this feedback and will seriously consider acting on all of it.

    @exoteric: We are working right now on support for C# actor methods with dynamic actor state. That would allow you to do something like “state.Foo = bar;”, rather than ‘state.Set(“Foo”, bar);’. This would somewhat alleviate the “magic string” problem, or at least hide it. But there will still be the problem of lack of intellisense or compiler-time checking for field validity. As mentioned by others, you could use an enum or const string definitions on the client side, but these would need to be manually kept in sync with the actual actor methods.

    And we currently do have the ability to run our actors in Azure. It’s just that I haven’t gotten around to integrating that into the ActorRuntimeManager GUI yet (it’s tricky). We hope to make it easy for you to run your actors in the cloud soon. In the meantime, you can hone your actor logic locally.

    Your idea for method discovery is a great idea that we’ve considered before. Every actor could have a GetMethods() method that would return the name of each method plus (optionally) some description about what it does and the parameters that it expects. We’ll put that on our list.

    Can you explain more as to what you mean by a “P2P backend”?

    @staceyw: RafaelF is right – it sounds like you were trying to open the template directly. Instead, place it in the appropriate folder as explained in the Developer Environment / Setup section of the ActorRuntimeManager doc.

    And to be blunt we do not currently know how we could make intellisense aware of an Actor’s methods. The best solution that we’ve arrived at so far is to use an enum on the client side, but we’ll keep noodling on this and see if we can’t come up with something better.

    @Matthew Moloney: You’re right that we need to do some thinking about async method calls to other actors. Right now, you might be able to do a poor-man’s version of this by issuing a method call and subscribing to an event on the callee to be notified of method completion. But that’s not entirely satisfactory. (My suggestion to build atop of byte stream stemmed from a misinterpretation of your question.)

    Re structural typing: I need to study this.

    Re state machines: We’re just providing some bare infrastructure here, and it seems possible to implement a state machine on top of it. Or have I misunderstood this issue?

    @Jedrek: We are aware that there is no way to unload an assembly; this is a problem and we currently have no solution for it. However, I would anticipate that AddAssembly() would be something that is called very infrequently, and so this problem should not prove to be too severe. And note that when actor replicas die and are reconstituted, “stale” assemblies will not be reloaded.

    Again – it’s a problem. But hopefully not too severe of a problem.

    @dreemeen: We had our reasons for choosing not to integrate with Azure Service Bus mechanisms for this initial go-round of actors. But the future is fluid – there is certainly the possibility of building actors based on these in the future.

  • User profile image

    Today my problem is to understand what is ActorFx target? Please, let us define what type of projects you want to solve to get a perspective of the features that are and are not done yet. The example of 'A score list for an 100 users' is nice as a demo example but at present time this kind of project is not an issue for me due to its low scale. From my perspective ActorFx real target should be large distributed projects with 'real time' and 'high availability'. In this case it will need to play with few thousands of actors (or more) and it miss many other features that are not in the box. I think that ActorFx team should be clear on what is there goal for us (developers\architects) to not over/under estimate the product.

  • User profile image

    Why don't you use the Perceptive Pixel?!

  • User profile image

    @briceprunier: I would say ActorFx is enabling distributed applications with distributed (and highly-available) state.

  • User profile image
    joe hoag

    @briceprunier: RafaelF has stated our goals fairly accurately. I would also add that we want our solution to be intuitive and non-prescriptive.

    And I'd like to clear up a misunderstanding: we're not limited to "a score list for 100 users". The capacity of that score list (which is represented as a single actor) would for now be limited by the memory on the VM that was hosting our runtime, and could therefore track tens of thousands of users.

    Our limitation is in the number of actors that can be active at any one time on an Actor Runtime cluster. Right now, that number is in the hundreds, which admittedly can be described as "medium scale" at best. However, (1) we expect that the scale capacity of the Actor Runtime will go up over time, and (2) we are studying the concept of multi-tenant actors, which would allow us to fit many "micro-actors" into a single "container actor". Both of those things will increase our ability to scale.

  • User profile image

    @joe hoag: With respect to P2P, I'm not sure, my thought was just that actors in different run-times could perhaps talk to eachother since access to state happens through methods (or events), so the state itself can be locally shielded. Therefore calling an "external actor" would be analogous to calling a (Web) [Service] method. How such a P2P protocol for talking between actors would look like I don't know; it's just a vague idea at this point. But in the WS realm there are concepts like Web Service discovery. So why not a similar concept for distributed actors (whether a peer happens to be a node in a cloud datacenter, a cellphone or a workstation)? But I'm new to actors.


  • User profile image
    Joe Hoag

    @exoteric: Ah, I see -- allowing actors to communicate with other actors that are outside of their "hive". That's definitely something to consider.

    Keep in mind, though, that actor *clients* should be able to run anywhere; they don't have to run in the "hive". So a cell phone, a desktop and a web service/site could all communicate with the same actor and thus (indirectly) communicate with each other, through the actor.

Add Your 2 Cents