There will be over 20 billion connected things in use by 2020. This course will teach you why the Actor Model and Akka.NET is a good fit for representing IoT systems that support reactive, concurrent, scalable, distributed, and fault tolerant apps.
Traditional programming techniques can fall short when trying to represent IoT devices and systems due to the the need for concurrency management, scalability, reactivity, distribution, and fault tolerance. In this course, Representing IoT Systems with the Actor Model and Akka.NET, you will learn how to model Internet of Things devices as actors with Akka.NET. First, you will learn why the Actor Model and Akka.NET is a good fit for IoT systems. Next, you will explore how to model devices as actors and organize actors into groups and supervision hierarchies. Finally, you will discover how to model the querying of device actors as separate actor instances. By the end of this course, you will know how to design and implement actors that represent real-world connected devices in IoT scenarios and take advantage of the built-in features of Akka.NET such as concurrency management and fault tolerance.
Course Overview Hi, everyone. My name is Jason Roberts. Welcome to my course, Representing IoT Systems with the Actor Model and Akka. NET. I am a Microsoft MVP, freelance developer and author. In this course we're going to learn why the actor model is a good fit for Internet of Things applications and how to implement it with Akka. NET. Some of the major topics that we'll cover in this course include why you might want to consider the actor model for IoT scenarios, how to design an actor model system to represent IoT devices, how to group devices together, and how to query device sensor data. We'll also learn how we can use test-driven development when developing an Akka. NET actor system. By the end of this course you'll understand how to map IoT devices the actor model and how to represent IoT devices with actors using Akka. NET. Before beginning the course it's recommended that you have at least a basic understanding of Akka. NET and C#. I hope you'll join me on this journey with the Representing IoT Systems with the Actor Model and Akka. NET course at Pluralsight.
Designing the Actor Model System Hi, everyone. I'm Jason Roberts from Pluralsight. Welcome to this course, Representing IoT Systems with the Actor Model and Akka. NET. When it comes to developing systems that need to communicate with many individual devices, the actor model can help to embrace the characteristics of IoT systems and make it easier to represent individual devices and also groups of devices. In this course we're going to learn how to use Akka. NET to develop a backend representation of connected IoT devices. In this first module we're going to start off by getting an overview of the modules that comprise this course and then we'll look at why we might want to choose the actor model for IoT systems. We'll cover some suggested course prerequisites and then we'll get a brief refresher of what the actor model is. So we'll learn about the key concepts such as actors and messages. We'll then go and design the actor model that we're going to be implementing in this course. We'll start off by looking at the physical devices the IoT system is going to represent. We'll then look at some of the actors that we'll be developing during this course, and also how these actors fit together into a supervision hierarchy. Once we've got our high-level design, we'll head over to Visual Studio and we'll get things started. We'll create a new project in Visual Studio and install Akka. NET and we'll also create a complimentary test project where we can write tests in conjunction with test-driven development to ensure that our actors are behaving as expected.
Developing an Actor to Represent an IoT Temperature Sensor Device Hi, welcome back. In the previous module we learned some of the reasons why the actor model is a good fit for IoT solutions and we also got a high-level overview of the system we'll be developing in this course. In this module we're going to create our first actor in our system and this actor is going to represent a temperature sensor device. So in this module we're going to start off with a design overview of the TemperatureSensor actor and we'll get an overview of the state this actor will hold, the actor's behavior, and the messages it will handle. We'll also get an introduction to the request-response pattern and how this allows us to correlate requests with responses and then we'll go ahead and create our TemperatureSensor actor class. During this module we're also going to create classes that represent the messages flowing to and from the actor and we'll be developing the actor functionality using test-driven development. So for example we'll write tests to check that the sensor data is initialized, that we can successfully update the temperature readings, and that we can register new temperature sensors. By the end of this module we'll have a working TemperatureSensor actor that has a number of passing automated tests. So let's kick off this module by getting a design overview of the TemperatureSensor actor.
Creating, Grouping, and Supervising Temperature Sensor Actors Hi, welcome back. In the previous module we developed the TemperatureSensor actor and in this module we're going to see how we can manage these temperature sensor actors by grouping them into individual floors and also supervising them. So in this module we're going to start off with a high-level design overview and we'll create a new Floor actor class and associated test class and in this module we'll also be creating the relevant message classes that this Floor actor is going to handle. We're then going to use test-driven development to develop the Floor actor functionality, which includes the ability to register new sensors on the floor, the ability to return existing sensors, the ability to list all of the sensor IDs belong to that floor, and this Floor actor is also going to monitor the sensor children. By the end of this module we'll have a working Floor actor with a number of passing automated tests. Before we head over to Visual Studio, let's start off with a high-level design overview of the Floor actor.
Managing Sensor Groups and Registering New Temperature Sensors Hi! Welcome back. In the previous module we went and created our Floor actor. In this module we're going to be moving one step up the supervision hierarchy and creating an additional actor. So in this module we're going to start off with a design overview of the actor that we're going to be creating, and then we're going to look at the importance of message immutability. We'll go ahead and review the message classes that we've created thus far and check that these message classes, as much as possible, are immutable. We'll learn that one of the message classes that we've created at first glance looks like it is immutable, but we'll go and improve the design of this class. We're also going to be adding new message classes during this module and we're going to be adding a new FloorsManager actor. This actor is going to be able to list the floor IDs that it manages. It's going to be able to register new floor actors in the actor system. It will allow the reuse of existing floor actors if we've already created one for a specific floor, and it will also monitor child actors for terminated messages. By the end of this module we'll have a working FloorsManager actor and associated tests. So let's kick off this module with an overview of the FloorsManager class.
Querying Temperature Sensor Actor Data Hi! Welcome back. In the previous module we went and developed the FloorsManager actor. In this module we're going to learn how we can query temperature sensor data. So in this module we're going to start off by getting a design overview of the solution we're going to build. We'll learn about some of the inherent complexities in developing this query functionality such as the fact that temperature sensors may come and go during the execution of a query, multiple queries may be initiated at the same time, and that sensors may not always respond in time to complete the query. We'll learn that we could go and add code to the Floor actor to create this query functionality, but this might not be the best idea. Instead we can actually represent the query as a completely separate actor. We'll head into Visual Studio and add some new message classes and we'll also go and add some additional classes to represent the sensor query results. We'll add a new FloorQuery actor to the solution where we'll implement the query functionality. By the end of this module we'll be able to query all of the temperature sensor readings for any given floor. So let's kick off this module by having a look at the design and some of the inherent complexities.
Implementing a Simple Console Actor System Host Hi. Welcome back to this final module. In the previous module we went ahead and implemented the query functionality for our actor system. In this module we're going to wrap up the course while implementing a simple console actor system host. We'll see the creation of our actor hierarchy that we've created in this course and we'll see the querying in action. We're going to kick off this module by getting a recap of the design. So we'll look at the final supervision hierarchy that we've developed. We'll recap how the registration process works for new temperature sensors. We'll review the updating process and the messages that are involved, and we'll also get a recap of the querying functionality we created in the last module. We'll then head into Visual Studio and we'll start off by creating a new console app project in our solution and we'll go and create a simulated sensor so this is going to simulate a physical temperature sensor in the real world. Finally, we'll go and implement a host actor system in the console app and we'll see the updating and querying of temperatures in action. We'll wrap up this module with a number of resources to help you continue your Akka. NET journey. So let's kick off this module by getting a design recap of the system that we've built.