Since I’ve been reading up on Reactive Extensions, I listened with interest to the recent .NET Rocks! podcast on the subject. During the conversation, Akka.NET was mentioned.
Akka.NET is another reactive technology. It’s an implementation of the Actor model. Basically, you break down an application’s functionality into small computational units called Actors which have limited state and communicate via message passing. There are parallels in Rx’s concept of observables and observers. Akka.NET also provides the kind of supervision hierarchy that you find in erlang, which is that an actor has child actors and when those child actors fail, the parent can resume or restart the failed children. This makes the application ‘self healing’.
I watched two Pluralsight course on Akka.NET by Jason Roberts, Building Concurrent Applications with the Actor Model in Akka.NET and Building Reactive Concurrent WPF Applications with Akka.NET (subscriptions required for both links). The former gives an overview of Akka.NET and the latter applies it to an MVVM WPF application.
In the demo MVVM application, the author uses Akka.NET with Ninject dependency injection and the MVVM Light toolkit. Personally, I prefer Unity and Prism, so as an exercise for myself I created the demo using those two languages. The result is on GitHub at https://github.com/mkb137/AkkaPrismUnityDemo.
The project consists of
* Akka.DI.Unity – A copy of Akka.NET’s Akka.DI.Unity upgraded from Unity 3.5 to Unity 4.0. No code changes were required otherwise.
* AkkaPrismUnityDemo – The Prism shell project
* AkkaPrismUnityDemo.Infrastructure – The common infrastructure project (which in this simple demo only contains the region names)
* AkkaPrismUnityDemo.Modules.Stocks – The main module containing the demo code.
A screenshot of the result is shown at the top of this post. In it, the view model creates actors which then have knowledge of the view model that created them and will call methods on the view model when messages are received and processed.
Here a view model creates an actor and passes it a reference to itself:
this.StockToggleButtonActorRef =
this.UnityContainer.Resolve<ActorSystem>()
.ActorOf(
Props.Create( () => new StockToggleButtonActor(
this.StocksCoordinatorActorRef,
this,
this.StockSymbol
)
)
);
Here the actor makes a callback to the view model:
this.Receive<ToggleStockMessage>( message => {
this._stocksCoordinatorActorRef.Tell( new WatchStockMessage( this._stockSymbol ) );
this._viewModel.UpdateButtonTextToOn();
this.Become( this.ToggledOn );
} );
Like Rx and its Observables/Observers, messages are handled on the thread pool so actors will make full use of the processors available on the machine with no extra effort from the developer.
It’s an interesting technology. Compared to Rx, Akka is missing some of Rx’s advanced publish/subscribe methods like the ability to buffer or throttle messages. It does have a Sample equivalent via the scheduler’s ScheduleTellRepeatedly method. On the plus side, it provides the supervision hierarchy and provides a more natural message pipeline. With Rx it seems like having an object that is both observer and observable (i.e. is part of a pipeline), while supported, is somehow discouraged.
Dogs Chasing Squirrels 
Great Example!
This example helps me very much to understand how to put Akka.NET, Prism and Unity together!
I want to go some steps further. Do you think that it is possible to create the actor system within the “main” application, instead within the module, and share this over multiple modules via the module constructor? Or is there a better approach you can recommend?
My goal is to have several independant modules in prism, which are using the same Actor System to interact with each other.
I am realy looking forward to your answer!
Kind regards,
Martin
You can create the actor system in the bootstrapper and register it with the Unity container before modules are created or initialized. Then any module can resolve it and use it, including by adding it to the modules’ constructors.
Awesome! Good idea! Thank you!
The idea is great but i don´t know how to solve this problem. Do i need the Akka.DI.Unity Project within the solution if i register it to the Prism Unity Container?
You’ll need to include Akka and Unity, but you’re not using the DI stuff at this point.
I would recommend overriding “InitializeModules” in Bootstrapper.cs and then moving the actor system initialization steps currently in the module there (everything up to RegisterInstance), before calling base.InitializeModules. The module can get the actor system via unityContainer.Resolve.
Thanks again for your realy quick reply!
As you recommend i have overwritten the InitializeModules() Method within the Bootstrapper:
protected override void InitializeModules()
{
// Create the actor system
var actorSystem = ActorSystem.Create(“StockActorSystem” );
// Register the actor system with the container
this.Container.RegisterInstance(actorSystem);
base.InitializeModules();
}
The application starts but when i push on a Stock-Symbol Button i get a NullReferenceException in the StockActor.cs while creating a priceLookupChild.
I am realy sorry but i am new in Dependency Injection.
Thanks in advance for your help!
I modified the demo in a branch: https://github.com/mkb137/AkkaPrismUnityDemo/tree/system-in-main
Hello Mike,
the modified demo worked as expected. I realy appreciate your help!
Thanks a lot!
I´ve started creating my own project depending on your professional example.
As expected i hit some new assembly version problems. Now i understand why you added the Akka.DI.Unity project to your solution.
I was trying around to solve this issue by adding and removing different Akka assemblys but i didn´t find the right one. Am i right that all these problems refers to the UnityDependencyResolver which needs an older Unity version than the prism framework?
I am looking forward to your reply 🙂
Yes, that’s right. The only change I made to that project was to update the Unity version. I don’t actually find the Akka.Net Unity stuff to be particularly useful as there’s no way to pass values to a constructor call. If you choose to just omit the UnityDependencyResolver part, you might be better off.