chapter three

3 One actor is no actor

 

This chapter covers

  • Actors as hierarchy
  • Creating more actors
  • Send messages back and forth. Adapting responses.
  • Send messages and waiting for a reply

“A colony of ants is more than just an aggregate of insects that are living together. One ant is no ant. Two ants, and you begin to get something entirely new. Put a million together with the workers divided into different castes, each doing a different function—cutting the leaves, looking after the queen, taking care of the young, digging the nest out, and so on—and you’ve got an organism weighing about 11 kilograms [24 pounds], about the size of a dog, and dominating an area the size of a house”[1].

Actors are very much the same—they come in organized in groups. One actor is no actor they come in systems. Let’s see how.

3.1 Actors as a hierarchy

So far you have seen how to create actors of the ActorSystem type, but this is a unique actor. It has a double task. It is the root of the hierarchy of all actors and the mechanism that controls the entire system. This chapter is about this hierarchy. Why it is important and how to implement it.

One of the most compelling features of the actor model is that each actor makes local decisions. At the same time, they belong to a hierarchy. These two properties allow the actor model to easily delegate. Traditional Akka applications are based in this delegation.

3.2 Simple parse example

3.2.1 Coding the app

3.2.2 Coding the guardian and spawning

3.2.3 Sending messages back and forth. Adapting responses.

3.2.4 The protocol, with the adapter's message

3.2.5 The adapter's function

3.2.6 Delegating

3.2.7 A protocol not only with Command

3.2.8 Coding the worker

3.3 Asking parsing example. Expecting a reply.

3.3.1 A simple question

3.3.2 Coding the manager

3.3.3 The protocols

3.3.4 Asking

3.3.5 Coding the worker

3.3.6 Usages of context

3.3.7 Ask signature

3.4 Ask with payload example

3.5 Summary