Practical ASP.NET

Modelling Actor Behaviors in Akka.NET

Simplify conditional actor code and improve readability.

• By Jason Roberts
• 10/22/2015

When using Akka.NET to build concurrent systems, the actor code that you write can become complicated if there are many different ways an actor can respond to a message. One of the features of actors in the Actor Model is that they can change their behavior over time. This switching of behavior can make it easier to represent what your actors should do.

An Example Without Switchable Behaviour
As an example, suppose you have an actor that represents the eye (a camera) of a robot. This eye has a robotic eyelid that can be opened or closed. This actor can respond to three types of messages:

• OpenEyeMessage
• CloseEyeMessage
• TakePhotoMessage

Table 1 shows the way these different messages need to be handled depending on the current state of the eye.

You could implement the behavior of your actor by holding the current state of the eye in a Boolean _eyeIsOpen field in the actor and then having conditional if statements based on this field as shown in Listing 1.

class RobotEyeActor : ReceiveActor
{
  private bool _eyeIsOpen; // Default to closed

  public RobotEyeActor()
  {
    Receive<OpenEyeMessage>(
      message =>
      {
        if (_eyeIsOpen)
        {
          // Do nothing
        }
      else
      {
        // Open robotic eye
        eyeIsOpen = true;
      }
      });


    Receive<CloseEyeMessage>(
      message =>
      {
        if (_eyeIsOpen)
        {
          // Close robotic eye
          _eyeIsOpen = false;
        }
        else
        {
          // Do nothing
        }
      });


    Receive<TakePhotoMessage>(
      message =>
      {
        if (_eyeIsOpen)
        {
          // Take photo
        }
        else
        {
          // Error, eye is not open
          }
      });
  }
}

Using Switchable Actor Behaviours
Akka.NET actors have access to the Become method that allows their behavior to be changed at runtime. Doing this you can control how the next message will be processed -- the message being currently processed will be unaffected. Listing 2 shows the use of the Become method to represent the eye open and eye closed behaviors. Notice that you don't need the Boolean field when taking this approach.

class RobotEyeActor : ReceiveActor
{
  public RobotEyeActor()
  {
    Closed();
  }

  private void Closed()
  {
    Receive<OpenEyeMessage>(
      message =>
      {
        // Open robotic eye

        Become(Open);
      });


    Receive<CloseEyeMessage>(
      message =>
      {
        // Do nothing
      });


    Receive<TakePhotoMessage>(
      message =>
      {
        // Error, eye is not open
      });
  }

  private void Open()
  {
    Receive<OpenEyeMessage>(
      message =>
      {
        // Do nothing
      });


    Receive<CloseEyeMessage>(
      message =>
      {
        // close robotic eye

        Become(Closed);
      });


    Receive<TakePhotoMessage>(
      message =>
      {
        // take photo
      });
  }
}

Notice here that you set the initial behavior of the actor when it's created to Closed in the constructor. Here you don't need to use the Become method because you're setting the initial state. In response to incoming messages, you can change the behavior of the actor over time in response to messages that it receives.

Switchable behaviors are a powerful technique, which once mastered, can make actor code easier to reason about and code. In the examples in this article you only have two states (opened and closed). Imagine if you had six message types and four distinct states -- writing this code with if statements could quickly become unmanageable.