45Spawning an actor

The decision to use actors for all top-level work within Akka.Net itself ensures that a uniform interface exists throughout the application. In any of these system-created actors, users are free to send a message to them in the same way that a user might expect to send a message to an actor which they’ve instantiated.

3.3.2 Spawning an actor

Now that we’ve defined an actor which is able to work, we need to deploy it into an application to use it. Before we’re able to deploy our actor, we need something which is capable of hosting an actor. In order to do this, we need to initialise an actor system. As we’ve seen, the actor system is the component of Akka.Net which is responsible for many of the tasks relating to how actors are run within the framework.

Instantiating an actor system in which we can host actors is a simple task and it requires calling the Create static method on the actor system. The only requirement when creating an actor system is to name it in a way that actors can be identified based on which actor system they live in.

var actorSystem = ActorSystem.Create(“MyActorSystem”);

An actor system can also be created with a configuration section in order to customise certain parts of the framework. This will be covered in a later chapter. For now, we cre- ate an actor system without a configuration file in C#, which causes a fallback onto the default configuration.

As we’ve seen, the actor system is responsible for many of the internal tasks and scheduling associated with the Akka.Net framework. Because of this the actor system ends up becoming a heavyweight object, and we typically only spawn one actor system per application. The actor system is the main means of interacting with the actors operating within the framework. In most scenarios, it’s typical for the actor system to either reside in a static class or singleton object, or be injected as a dependency into those methods which require it.

Once an actor system has been created, we’re free to deploy new actors into it. To deploy an actor into the actor system we use the ActorOf method, which requires the actor type to instantiate as a generic type argument. The example below shows how we can deploy our actor from earlier into the actor system to interact with it.

var actorRef = actorSystem.ActorOf<GreeterActor(“actorA”);

Once this method has been called, Akka.Net will create and initialize this new actor into the actor system. We pass it a string, which we can use to uniquely identify a given actor instance within the actor system. In this case we’ve chosen to refer to the actor as actorA. This means that given this name, we’re able to retrieve references to it directly from the actor system.

work, it’s beneficial to have an understanding of some of the features provided by the actor system. The actor system is also the key extensibility point of an Akka.Net appli- cation and allows more advanced features to be implemented, many of which we’ll look at in later chapters.

3.4

Communicating with actors

Once you’ve spawned an actor into your actor system, you’ll want to be able to com- municate with it. Whilst we have an actor deployed into our actor system, it’s currently doing no work and sits in memory, doing nothing. By communicating with it, the framework will invoke the message processign on that actor. The actor model relies upon message passing as a means of communication between actors. A message is a generic term for a collection of data which is packaged and sent to an actor instance somewhere in the actor system, as represented by the address. We saw in our example earlier that our messages will be a data type we’ve created.

3.4.1 Actor addresses and references

Upon spawning our actor, the actor system returned a direct reference to the actor through an IActorRef. This actor reference isn’t a direct reference to the actor’s loca- tion in memory, but is a reference to the actor as used by Akka.Net. It’s ultimate use is to facilitate sending messages to the inbox of the referenced actor. The Akka.Net framework provides a number of built-in means of referencing actors out of the box. These include the likes of actor references for clusters and remote actor systems. We won’t be seeing these until later chapters.

The most commonly used actor reference is LocalActorRef, whose job is to operate on actor systems that only operate on a single machine. The key component of the actor reference is the storage of the address of the actor itself. Upon deployment, every actor is given a unique address through which the actor is reachable. The address is reminiscent of a URI which might be used to identify files in a file system or web pages on a web site. In this case it represents the address of an actor in an actor system. Figure <X> below shows the components of an address. An actor address is made up of four key components:

 Protocol identifier: The protocol identifier is used to reference how a connection is made to that actor system. This is similar to how http and https are used in web addresses to identify which system should be used. For a single machine, this is typically through an identifier like akka://, but for handling concepts such as remoting, there are other commonly used examples, such as akka.tcp://.

 Actor system name: When we created an actor system, we gave it a unique name to refer to that actor system instance. This part of the address relates to that name.

 Address: This is only used when dealing with the concept of remoting, but it still forms a key part of the actor path and is used to identify the machine upon

47