Reactive Programming with Actors

Reactive systems are computer systems that continuously respond to their environment. The term actor model, coined in this context, was first used by Carl Hewitt in the early 1970s. His mathematical model describes a universal method for parallel programming. He was far ahead of his time, as computers at that point were not yet powerful enough. The model was first used in 1987 in the programming language Erlang by Ericsson. By using this technology, Ericsson was able to build a switch with a reliability of 99.999999999%. This corresponds to a downtime of less than 0.65 seconds in 20 years. In the following decades, computer performance continued to increase. At the beginning of the new millennium, processors reached their maximum clock frequency with the materials used. Processor manufacturers like Intel and AMD began building processors with multiple cores while maintaining the same clock frequency. On one hand, heat generation at even higher clock rates can no longer be managed with conventional means. On the other hand, quantum mechanical side effects occur with increasingly smaller transistors. Today, manufacturers increase the number of cores per CPU to still achieve performance improvements. This increases the relevance of parallel programming, as algorithm computations must be distributed across multiple CPU cores. Developing software with multiple threads, or across multiple machines, is complicated and problematic for developers. This is partly due to the memory management of threads and processes. As a result, more and more reactive frameworks have emerged in recent years for modern programming languages, such as akka for Scala and Java. Reactive frameworks offer developers much more than just simple parallelization across multiple cores…

Designing concurrent applications has been a challenge for years, with no simple solution. The actor model represents a proven and comparatively simple way to implement concurrent algorithms. The actor model is an architectural pattern that enables distributed applications based on message passing without requiring shared state among multiple actors. The actor model is implemented in various ways, partly in functional languages like Erlang, partly as frameworks like akka or libcppa. An actor is a lightweight and autonomous process. Messages can be sent to the actor, for which it has its own behavior that typically does not change at runtime. An actor always processes only one message at a time. The actor model is not tied to specific data structures, so actors can communicate loosely coupled with each other. An actor is lightweight because it does not have its own process but is assigned a process to handle a message. Actors optimally utilize the available resources of a thread and do not block processing.

Actor Model Actors akka

The figure shows an example network of actors. Each actor has its own mailbox and an isolated state. Based on its defined behavior, the actor responds by sending its own message or creates its own actors and changes its future behavior. In summary, an actor system is defined by the following properties:

• An actor can create other actors and communicate with them.
• Each actor has a unique name that can be used as an address for communication. (in akka)
• Communication between actors is based on sending asynchronous, immutable messages to other actors.
• Messages are buffered for processing in a mailbox. It is a queue with n producers (sender actor) and one consumer (receiver actor)
• Depending on the order, priorities, or internal state, messages are processed using pattern matching by internal functions, which in turn send their results as messages.

Akka implements the actor model as a framework for the JVM. It is commonly used in the programming languages Scala and Java and was first published on GitHub by Jonas Bonér in July 2009. An actor in akka is the smallest unit in the system and typically handles a specific task. The actor can change its state, and thus its behavior when receiving further messages. An actor’s state is defined by the values of its variables. These values can only be changed by incoming messages from other actors. Since there are no shared memory areas with other actors, it is guaranteed that an actor’s state cannot be manipulated by external access. If an actor crashes due to an error, the supervisor, i.e., the creator of the actor, can reinitialize and restore the actor. An actor’s behavior refers to the logic executed when a message arrives. The logic can be changed at any time as a reaction to a message. Each actor has exactly one mailbox for receiving messages. The mailbox is by default a First In – First Out (FIFO) queue. The mailbox queue in akka can be configured so that certain messages are processed with priority. The queue size is also freely definable.

akka offers many other advantages that are described in many different blog posts on the internet and in relevant books. These include remote access and clustering. These capabilities make akka an excellent framework for modern microservices. akka is often found in the so-called SMACK Stack – SMACK stands for Spark, Mesos, akka, Cassandra, Kafka. This stack is the basis for our Fast Data System at croGoDeal.

Reactive programming is more relevant than ever. However, the term is not precisely defined. Thus, many applications call themselves reactive when they are not. Reactive programming is often used more as a buzzword for a specific type of asynchronous programming. The probably most fitting description of a reactive architecture is provided by the Reactive Manifesto. Various frameworks pursue the goal of achieving the objectives of the Reactive Manifesto as easily as possible. One of the best for Java and Scala is currently akka. It is possible with relatively simple means to implement responsive, resilient, elastic, and message-driven systems based on the JVM. A Java or Scala software architect for scalable applications should definitely acquire advanced knowledge in akka and include the framework in their planning.