The Actor Model is a very dynamic form of dataflow where nodes and arcs can come and go based on run-time demands.
It is a concurrent model of computation developed by Carl Hewitt that is also similar to Object Oriented Programming (OOP). The Actor Model is actually closer to the original definition of OOP than most current OO languages. Alan Kay, the creator of OOP, commented on a blog post...
"Many of Carl Hewitt's Actors ideas... were more in the spirit of OOP than the subsequent Smalltalks." From Moti asks: Objects Never? Well, Hardly Ever!"
Mr. Kay defines OOP to be...
"...only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." Dr. Alan Kay on the Meaning of Object-Oriented Programming"
The Actor Model uses message passing to send data directly to a single actor asynchronously. Every actor has a unique address to determine which actor should receive what message. A mailbox (an ordered queue) stores received messages in the actor.
Messages can be taken from the mailbox in any order. In most implementations, actors have a message processing procedure that will pattern match on the messages, similar to a case or switch statement, and pass the messages to the appropriate methods of the actors. If the message is unknown, then it is either silently discarded or creates an error depending on the implementation.
Actors can only send messages to other actors that they know about (i.e. actors they have addresses to). It could be an address that was sent in a message or an address of an actor it created.
Message delivery is not guaranteed. At most, messages are delivered once and possibly never get delivered. To ensure that a message reaches its destination you have to use an acknowledgment protocol between the two actors.
Like all types of dataflow, receiving a message triggers the activation of an actor. Execution happens concurrently.
Actors are referentially transparent (functional) per invocation. They can change their internal state but it does not take effect until the next activation. Effectively they pass their state out and back to themselves so that the next activation uses the updated state.
Local data is encapsulated inside actors. The only way to communicate with them is through messages. Internal data can not leak out unless it is specifically sent to other actors.
The Actor Model is similar to OOP except the methods do not return a value. Instead they send messages to return values.
A message is a form of indirect call. An actor never directly calls methods in other actors. In fact, they couldn't even if they wanted to.
By removing direct calls, actors are able to work concurrently with other actors, essentially asynchronous objects.
Like objects, actors retain local state and can be created.
The Actor Model is different from most other dataflow models where data is transmitted over arcs. We can say that the Actor Model is just dynamic dataflow where the arcs have a capacity of one and are created immediately before sending the data and then disconnected immediately afterwards.
It is an asynchronous dataflow model that has functional nodes but passes state from one activation to the next to simulate stateful nodes.
Since everything is an actor, compound nodes are easily created by defining actors in terms of other actors.
The Actor model is a very dynamic and fluid dataflow model. It is beneficial anytime applications need to change due to runtime demands such as:
In situations where the program is essentially static, the dynamism of the Actor Model gets in the way. For example, a fixed pipeline of transformations or circuit simulations.
To some applications, the connections between nodes are as important as the nodes themselves. When you need to ensure that nodes can be freely reused simply by changing the connections to the nodes, the Actor Model is a poor fit.
This is an excerpt from the book "Dataflow and Reactive Programming Systems"