The Actor Model is a programming paradigm in which the basic unit of execution is the actor. Unlike an object in the Object Oriented Programming (OOP) paradigm where work can be done on a standalone basis, Printer.Print() for example, in the Actor Model, an actor does work by using messages to express actions upon a system or other actors within the given system (see Figure 1).
Figure 1: The Actor Model lends itself well to service-oriented architecture
The Actor Model is particularly useful when programming in large, distributed, asynchronous systems that have unpredictable degrees of latency.
A Little Background
In the old days, for many of us, computing was about one person using one computer to do work. Today, one person uses hundreds, if not thousands of computers working concurrently to get work done. A simple example is doing a price lookup for an airplane flight. You go to a Web site that handles flight bookings, enter some data, and then issue a command to the site to find prices on the flight. Does the site look up the prices one at a time? No. The price lookup is done concurrently. The site sends your purchase parameters to all the airlines at once and waits for the information to come back. Once the information is gathered, it’s all sent back to you at once (please see Figure 2).
Figure 2: 
Flight booking is the poster child of concurrent programming and the dynamics of the flight booking are a textbook use case example of the actor model. In the case of Figure 2, the user acts upon the Web site, the Web site acts upon the backend server, and the backend server acts upon each airline’s ticketing system.
Let’s take a more detailed look.
Enter the Actor Model
As mentioned above, in the Actor Model the basic unit of execution is an actor. In the Actor Model, everything is an actor. An actor expresses an action upon a system or another actor by way of a message. An actor can express actions upon many systems and actors concurrently using messages.
Consider the following scenario shown in Figure 3: Dad wants Kid to clean Kid’s Room while not interfering with his Poker game.
Figure 3: In the Actor Model, an actor acts on one or many actors
Understanding the Role of Messages
Figure 3 describes a scenario in which Dad, the central actor, is sending messages to another actor, Kid, and a system, Poker Game. Dad acts upon the actor, Kid, by sending a message “Clean room.” Also, Dad acts upon the system, Poker Game, by sending a message, “Make bet.” The important thing to understand is that Dad is an actor acting upon two domains asynchronously and work is accomplished by way of the messages. An actor sends a message to a system or other actor. Interaction between the originating actor and the subsequently messaged system or actor is facilitated by way of a return callback message.
The essential feature of the Actor Model is that all interaction is asynchronous and autonomous. The affected actor does work and then notifies interested parties when work has been accomplished. The coupling is loose with message management being a critical dynamic of the model.
Listing 1 shows an example message in JSON that one could imagine being sent in the flight booking scenario described in Figure 1. Notice please the declaration of a callback URL to which flight information is to be sent as the last property of the JSON message. Remember, processing actor messages is asynchronous and loosely coupled. The actor responds only to information of the message provided. Should one or more callbacks be required, that callback information must be provided within the content of the message.
Also, please understand that although Listing 1 uses JSON, any format that is well known to the sending actor and receiving system or actor can be used. In Listing 1, you can just as easily use XML, protocol buffers, or any other message format you choose as long as that format is understood by all the actors in play.
{
"id":"SOME_ID",
"from":"LAX",
"to":"DSM",
"date":"12/25/2015",
"callback":"http://www/coolflightbroker.com/
api/flightInfo/SOME_ID"
}
Listing 1: A message can have a callback address by which it notifies other interested actors of system status
Again, the beauty of the Actor Model is that it’s discrete and lends itself well to asynchronous, concurrent work. An actor acts upon something and that’s it. Subsequent work and callback notifications are independent mechanisms. Thus, when implementing an Actor Model you are going to spend a lot of time managing messages and managing process calls within threads. It can be a lot of work. However, to save time and labor, there are many pre-existing frameworks you can use that implement the Actor Model, Akka/Akka.NET, Orleans, and Dotsero, to name a few.
Putting It All Together
The Actor Model is well suited to the landscape of process-intensive, large-scale service-oriented architectures. Given the intrinsic variation in responsiveness of cloud-based services, the Actor Model accommodates both the power and hazard of working with Internet-based data processing. The asynchronous nature of the send-response messaging feature that is a vital part of the Actor Model allows you to do concurrent computing is a way that is flexible and extensible. And, if you use an existing Actor Model framework, you can get yourself operational is a fraction of the time that it would take to build your own.
Once you adjust your thinking into the message-driven way of developing, you’ll find the Actor Model to be invaluable when it comes to designing large-scale, service-oriented systems that run on the Internet.
