This document outlines a presentation on building reactive IoT using an actor-based model. It discusses the limitations of legacy IoT architectures and proposes a new reactive model based on actors and messages. This reactive IoT approach called RIoT is demonstrated through two case studies and an open-source implementation called O-Robot. The presentation concludes with a demo of O-Robot using a sensor board and backend.

1. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Reactive IoT
How to build the next generation
M2M communication using
the Actor based model
Nicola La Gloria
Andrea Zoleo
Kynetics, Santa Clara, CA

2. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Agenda
- Introduction:
- Legacy IoT and pains.
- How can we design a better model?
- Reactive Manifesto
- Some elements of a reactive architecture
- Definition of Plato Devices.
- What is Reactive IoT? (RIoT)
- 2 Case of Study
- Our Open Source implementation of RIoT: O-Robot
- Demo

3. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Legacy IoT
❯ Monolithic Architecture
》 3-tiers (Presentation, Application, Data)
》 Multiple AS (to scale)
》 Single RDBMS
❯ Traditional Microservices
》 Multiple isolated services
》 Http interconnected
》 No single programming model
》 Multiple RDBMS

4. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Pains of Legacy IoT
The problem: Trade off between scalability (adding different types of
devices) and the ability to plug-in arbitrary logic in the device
model
The legacy solution: device model too generic
❯ Generic list of attributes/setpoints in the device model (defined
a priori)
❯ Exchange of generic files (aka any kind of resource)
❯ Simple monitor and control of a single device without no advanced
definition of collaboration and coordination between devices

5. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
What would be a more effective model?
❯ Communication between server and devices and collaboration between
devices can’t be direct. It should be handled through a device
representation on the server in a scalable context.
❯ Behaviour orchestration of heterogeneous devices should be similar
to how human workers exchange messages and directives (commands)
❯ Unexpected events are the standard and the exception must be
handled through a hierarchy of responsibilities.

6. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
What should we ask to the new model?
An effective model should allow to:
❯ Write advanced business logic (using a DSL i.e)
❯ Not have any “a priori” hypothesis on the device.
❯ Scale without any service interruption.
❯ Be fast to provide responses to devices and clients in order
for them to react.

7. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
What should be the drivers?
❯ Asynchronous, responsive and full duplex messaging system.
❯ Be robust to any loss of connection between device and
backend.
❯ Workers isolation (tasks small enough to be handled
independently)
❯ Hierarchical structure for responsibilities and
countermeasures
❯ Tasks organized in a workflow

8. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
What is Reactive
- Reactive manifesto (2.0)
- ERRM (Elastic, Responsive, Resilient and Message Driven)
© Lightbend

9. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
How can we achieve this?
❯ Actors (human workers)
❯ Messages (communication)
❯ Reactive Streams (data flux manipulation)
❯ Microservices (isolation, reuse, deployment)
❯ Cluster management (scale with no service interruption)
❯ CQRS/ED (performances, scale)
❯ NOSQL (schemaless)
= AKKA O/

10. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Microservices vs Akka
❯ Multiple isolated services/Akka remote provides clustering
❯ Http (JSON) interconnected/Binary serialized messages
❯ Some aggregate service/Akka applies localization transparency
❯ Multiple RDBMS/CQRS

11. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Plato Devices
“The ideal world is stronger than reality”
❯ In this context if we associated a device to a specific actor,
this actor becomes a kind of projection of the real device but
living in the back end (the “Ideal World”)
❯ This is a great solution to responsiveness and backpressure
❯ Plato Device provides a rich definition even for a very simple
device

12. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
But more...
❯ Actor lives in the server (always reachable by the client).
❯ It’s state can be monitored even when the physical device is
not reachable (fallback).
❯ The system is robust to device failures, it can always provide
a prompt response to the user in a real time fashion.
❯ Complex orchestration logic can be handled on server
❯ The server can instantiate several actors leveraging few
thread pools.
❯ Actor lives in its execution thread with a stateful
connection.

13. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
A simplified architecture
Device
Client
Protocol
FAC
Server
PD
HTTP
WebS
ock
SFS
Device
Device
Device
PD
PD
PD
CQRS
Domain
Entities

14. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Reactive IoT (RIoT)
- Reactive IoT has the aim of applying the principles of the
Reactive Manifesto in order to provide a new foundation to the
interaction between elements of an IoT system and facilitate
their development.
- The device logic (and more) may be totally represented in the
Plato device (isolation), which is message driven towards
other actors, and responsible of the communication (MQTT i.e)
to the real device.

15. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Advantages of the RIoT approach
❯ Grow any device with custom logic developed in Java, Scala or
a custom DSL.
❯ With a careful development, scale without halting service
》 CQRS/ED (i.e Cassandra)
》 Schema evolution (Akka/Stamina)
》 Akka message serialization (between remote Actors)
》 Routers, Sharding, Roles
❯ Multiple protocol (mqtt, http, websocket, akka, tcp/ip, etc..)
with streaming support and reactive responsiveness.
❯ Hierarchical fault handling and recover (let it crash).

16. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
“Versatile” becomes the cornerstone
Let’s explore two Case of Study:
1. Microdevices, HUB, Backend, Client, HTTP
2. Devices, Backend, Client, MQTT

17. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Case of Study (1)
DevGat
Client
ES
HTTP
FAC
ActorServer
EVJ
PQ
µDev µDev µDev
EVP
PD
HTTP
WebS
ock
DEA
SFS

18. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Case of Study (2)
Device
Client
ES
FAC
ActorServer
EVJ
PQ
PD
HTTP
WebS
ockMC
MqTT
Broker
PDR

19. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
A (GPL) implementation of RIoT: O-Robot
❯ We developed a project which is our first implementation of a
RiOT system: O-Robot.
》 A robot (for monitoring or surveillance purposes) sends constantly position
and environmental data to the backend.
》 The client may request to supervise a particular robot which start to send a
video stream.
❯ It uses: CQRS, Messages, Actors, Microservices.
❯ Right now it runs on a single instance (no sharding, routing,
roles, we are getting there!)

20. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
O-Robot Architecture - Deploy
Robot
Device
Mqtt
Broker
Akka Play
Server
Browser
mqtt
mqtt akka
http/ws
Elastic
Search
Cassandra

21. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
O-Robot Architecture - Modules
❯ Modules:
》 Core → main actors
》 Model → domain model objects
》 Mqtt → actors and protocol handling
》 Persistence → persistent actors events (CQRS/ED)
》 Protocol → akka protocol
》 Elastic → mapping ES
》 Play → web application
》 Sim → robot device simulator

22. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
O-Robot Architecture - Actors
ORobot
Sup.
Facade
Robots
Sup.
Robot
Registry
Sup.
Mqtt
Connector
Sup.
Robot
Robot
Registry
Mqtt
Connector

23. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Demo:
❯ Demo setup:
》 Robot device simulated using warp board (running JVM 8)
■ Robot communicates via WIFI
■ WIFI is managed by a local AP
》 Backend running on a laptop connected to the AP

24. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Warp
❯ Small form factor: 16mm x 38mm x 3.5mm
(Board Area < 1 sq-in)
❯ 10 Layer HDI PCB (0.4mm BGA, LGA, 0201)
❯ 1Ghz ARM Cortex-A9 (Freescale i.MX6SL)
❯ 512MB Memory + 4GB Flash
❯ USB OTG, 6-axis ACC+Mag, PMIC, Wifi+BT/BLE
❯ B2B Expansion

25. Wearable Tech Conference, San Jose 2016© 2016 warpx.io

26. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Demo setup
Sensor
Board
Warp AP
Netbook
(Warp)
Mac
(Backend)
WiFi WiFi
WiFi

27. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Warp References
❯ Mailing list: >warpx.io on Google group
❯ Store: http://revotics.com/store
❯ Community website:www.warp.io
❯ Documentation:www.warpx.io/resources
❯ This presentation: www.warpx.io/resources
❯ GitHub: https://github.com/warpboard

28. JavaOne 2016, San Francisco, CA© 2016-2017 Kynetics, all right reserved
Thank you