Path: The final part of the address is the path, which is used to identify an actor. All user defined actors start with the /user/ for this part of the path, but other system defined actors inhabit other root addresses.
The concept of an actor reference starts to ensure that our application is loosely cou- pled, but it still causes problems. In order to send a message to a given actor refer- ence, we’ll need to pass the actor reference around the application. When we considered the benefits of a message-driven architecture, one of the more important benefits was the ability to have loosely-coupled systems which didn’t rely upon inti- mate knowledge of other actors. In order to solve this problem with Akka.Net, we’re able to send messages to an address rather than an actor reference directly. Given an address we’re able to send a message to that address. For example, to send a message to an actor known as ActorA in our actor system, we’re able to retrieve a reference to it’s address as below.
var address = system.ActorSelection(“/user/ActorA”);
When we deployed our actor, we saw that it was deployed into a hierarchy. If we deployed our actor as the child of another actor, then we can continue to address it similar to how we find files which are within a folder in a file system. If ActorA has a child actor called Child, then we can send messages to it as follows.
var childAddress = system.ActorSelection(“/user/ActorA/Child”);
The addressing system within Akka.Net also respects the usage of certain path tra- versal elements which are typically be associated with URIs. For example, a common case is to retrieve the parent of the current actor, to allow messages to be sent to a sib- ling of the current actor. This can be achieved by using the .. syntax to retrieve the par- ent within an actor as follows.
var address = Context.ActorSelection(“../ActorB”);
Whilst it might seem that the concept of an actor selection and an actor reference are the same, there’s a significant difference, in that an actor reference points to a specific incarnation of an actor whilst an actor selection points to an address. This address
same path across instantiations. Given an actor selection, messages can be sent to it even if an actor is destroyed and recreated; all messages will be delivered.
This distinction allows for more complex paths to be used in the context of an actor address. An example of this is through the use of wildcards in the path to a given actor in order to select large numbers of actors at once. Once these actors have been selected, it’s possible to send the same message to all in the wildcard with a single method call. Paths in Akka.Net support two kinds of wildcards in an actor address based on standard wildcard syntax common across other languages and tools:
?: The question mark replaces a single instance of any given character in a path. For example, the path c?t would match paths such as cat, but not coat or cost.
*: The asterisk matches any string of characters usable as a path. For example, the path /parent/*/ would send a message to all children of the actor called parent.
On occasion it’s beneficial to have a direct reference to an actor instance rather than a generic address. In order to cater to these situations, Akka.Net provides a number of different means of retrieving a reference from an address.
Calling ActorOf to spawn a new actor: Upon spawning a new actor, a direct refer- ence to that actor is returned which represents the incarnation which has been spawned.
Sending a message to an actor: By sending a message to an actor, it’s possible to use the sender property of a received message to identify which actor replied to the request for information. Akka.Net provides built-in support for this through the Identify message, and through an abstraction on the ActorSelection, which can be used to resolve an instance.
Whilst there’s many cases whereby it’s appropriate to send messages to an address, it can frequently be beneficial to pass around a reference to a specific actor. For exam- ple, given a long-running actor which is valid throughout the lifecycle of the applica- tion and performs a specific purpose, it’s typical to pass an actor reference in the constructor of those actors that depend on it.
It’s important to understand the difference in an actor reference and an actor address due in part to the actor lifecycle, something covered in a later chapter. For our uses either option is an appropriate means of messaging a specific actor.
3.4.2 Sending a message
Upon spawning our actor into the system, we’re able to communicate with it by send- ing messages to it’s mailbox. In order to send a message to it, we need something capable of receiving a message. As we saw in the differences between an address and a reference, we’re able to send a message to either. Once an actor is spawned, the actor
49