This blog has already mentioned message passing framework such as Erlang and Akka a number of times and hinted at the benefits of using them. Using message passing frameworks is a paradigm that puts Actors and Messages at the center of the stage rather than, more traditionally, Objects and Messages. As quoted by the Akka web site, the main advantages compared to a traditional OOP style software architecture are:
- Concurrency – Multiple actors can execute concurrently on the same machine without having to resort to traditional multithreading constructs such as locking and condition variables, mutable state is local to a (single threaded) actor.
- Distributed Computing – By making everything asynchronous and based on immutable messages, there is no impedance mismatch when messages are sent to remote actors. Unlike OOP style remoting, the asynchronous and unreliable nature of network communication is already present in the model.
- Error Handling – By treating exceptions as expected in a large scale long running system, and allowing for select subsystems of an application to be restarted, Erlang and Akka makes it possible to build self healing software systems.
While Akka is an impressive framework that does indeed deliver a lot of the above compared to traditional OOP based approaches to large systems programming, it is far from done yet, and in some aspects far from as done as the documentation suggests. For example, while Akka does have mature support for remoting, the documentation also claims to support location transparency. As noted in the Wikipedia page linked to, location transparency allows for resources to be used independent of both the user’s location and the resource location.
Location transparency is a very valuable quality in a distributed, fault tolerant system. For example, location transparency can allow an application to send a message to “an email sending service” or “the server currently responsible for user X”, regardless of which physical machine that currently happen to run that specific service. Akka, in version 2.0.2 being the current version at the time of writing, does not support location transparency – finding any resource is done using explicit network paths provided in either code or configuration.
True location transparency requires yet another feature currently missing from Akka – cluster membership support. In a system with a large number of nodes, or a system were uninterrupted reliable service is a priority, it must be possible to stop and start physical servers without having to restart and reconfigure the other members of the cluster. The Akka team is obviously aware of the importance of cluster membership support and are busy hacking away at it for the upcoming version, but for now we will have to live with Akka being a distributed rather than clustered system.
Next time, how to build Akka 2.2 in a week based on Akka 2.0.