Accelerate your code with the Actor Model of Computation
The average person has an attention span of 3–5 seconds. If you don’t fully engage a user during this time frame, they bounce. The longstanding pressure to write faster code affects every single one of us, every single day. And it’s only getting more intense as the technology develops. The more options users have the less patient they become.
Grant Steinfeld (@gsteinfeld) is an IBM Developer Advocate for Blockchain and Java/JVM
The software industry offers many solutions to this issue but most of them are convoluted and tricky, and the dilemma then lies in the choice of architecture.
The Actor Model is a great solution. It allows you to create responsive and reliable applications that provide the kind of interactive experience users are looking for.
What is the Actor Model? First introduced by Carl Hewitt in 1973, the Actor Model was inspired by things not normally associated with computers, like physics — quantum mechanics and general relativity — and influenced by logical thinking found in computer languages such as Simula, Smalltalk and Lisp.
The motivation behind it was the ability to have hundreds, or even thousands, of individual microprocessors all talking to each other in a high-performance swarm over an incredibly fast network.
The model is simple. It’s conceptual and abstract. It defines general rules of how Actors interact with each other and how an Actor should behave. One Actor needs to part of an ecosystem of multiple Actors and they cannot function alone.
An Actor is a basic building block of concurrent computation.
Actors have Mailboxes and unique identities or addresses whereby they can interact by sending asynchronous messages to each other.
One thing to note here is that Actors are completely Isolated from each other and they will never share Memory or State. State is private. To alter another Actor’s state the Actor must send it a message.
When an Actor receives messages in its Mailbox, it should process the messages in order, sequentially. If concurrency is called for, an Actor can create other Actors
Once an Actor receives a message it can do the following three things:
1) Create new Actors
2) Pass the message along to existing Actors
3) Designate what to do with the next message ( Mutate their state )
An example of mutation could be — imagine we have a Chameleon Actor, initially green. When it gets say a change Color(purple) message, it does not mutate its original state but rather declares that when the next message arrives, its state will be purple.
What happens if an Actor crashes? This crash does not affect other Actors. A Supervisor can watch Actors. If the Supervised Actor goes down the Supervisor can:
· Spawn a new Actor
· Raise an Exception to the User
Actors can run locally on the same server or remotely. We don’t care where Actor code runs, we’re only concerned with the message getting there. This allows us to create responsive and resilient systems that leverage concurrency across multiple servers.
Where do we find Actors? Actors show up in various places in the software world:
· In languages like Io, Scala, C# and Erlang
· Frameworks, like Akka and Lagom (Scala / Java ) and Akka.NET (C#, F#)
This was a brief summary of what the Actor Model is. It’s a great solution for certain use cases, especially distributed systems, but in some other cases like a local application running on a single process it’s not always appropriate and the cure for everything.
Actors provide a compelling alternative to threads and solve a lot of challenges related to speeding up your applications. It’s by no means the only alternative, but it’s one that got me interested and I highly recommend you look into it as well.
If you’ve read this far you are clearly interested in Actors and how they may enhance your programming skills. To find out more, please take a look at these resources:
· Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know but were afraid to ask) Microsoft Channel 9. April 9, 2012.
· Lightbends tech hub great resource on Scala, Akka and Lagom
· Start building Lagom microservices from IBM Cloud by Jeremy Hughes
· Akka.net
· Seven Languages in Seven Weeks, by Bruce A. Tate
· Learning RxJava by Thomas Nield
· JVM Concurrency and Actors with GPars Dr.Dobbs, 2011
Grant is an accomplished and innovative senior software architect and engineer with a reputation for delivering client-focused solutions. He is a problem solver and team mentor with the ability to work with and manage development teams. He is able to interface with senior management and product teams in order to translate business requirements and challenges into project plans and solutions.
