the actor based model m2m communication using how to build … · 2019-06-27 · 》 schema...

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 GloriaAndrea Zoleo

Kynetics, Santa Clara, CA


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


Legacy IoT

❯ Monolithic Architecture》 3-tiers (Presentation, Application, Data)

》 Multiple AS (to scale)

》 Single RDBMS

❯ Traditional Microservices》 Multiple isolated services

》 Http interconnected

》 Some aggregate service

》 Multiple RDBMS


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

❯ Exchange of generic files (aka any kind of resource)

❯ Generic list of attributes/setpoints in the device model (defined

a priori)

❯ Simple monitor and control of a single device without any more

advanced definition of collaboration and coordination between

devices


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’s orchestration of heterogeneous devices is 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.

❯ Client and devices should receive quick responses to react faster.


What should we ask to the new model?

An effective model would allow to:

❯ Write advanced business logic (DSL)

❯ 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.


What should we ask to the new model (2)?

An effective model would allow to:

❯ 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 (state machine)


What is Reactive

- Reactive manifesto (2.0)

- RSER (Responsiveness, Scalability Elasticity and Resiliency)

© Lightbend


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, versioning)

❯ NOSQL (schemaless)


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


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.

❯ 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.


A simplified architecture

Device ClientProtocol FACServer

PDHTTPWebSock

SFS

Device Device

Device

PDPD

PD

CQRS

Domain Entities


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.

- In addition to the RSER, 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 to the real device.


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)

》 Custom message serialization (between 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).


“Versatile” becomes the cornerstone

Let’s explore two Case of Study:

1. Microdevices, HUB, Backend, Client, HTTP

2. Devices, Backend, Client, MQTT


Case of Study (1)

DevGat

Client

ES

HTTP

FACActorServer

EVJ

PQ

µDev µDev µDev

EVPPD

HTTPWebSock

DEA

SFS


Case of Study (2)

Device

Client

ES

FACActorServer

EVJ

PQ

PD

HTTPWebSockMCMqTT

Broker

PDR


A (GPL) implementation of RIoT: O-Robot

❯ We developed a project (GPL) which is our 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)


O-Robot Architecture - Deploy

RobotDevice

MqttBroker

Akka Play Server

Browser

mqtt

mqtt akka

http/ws

ElasticSearch Cassandra


O-Robot Architecture - Modules

❯ Modules:》 Core → main actors

》 Model → domain model objects

》 Mqtt → actors and protocol handling

》 Persistence → persistent actors events

》 Protocol → akka protocol

》 Elastic → mapping ES

》 Play → web application

》 Sim → robot device simulator


O-Robot Architecture - Actors

ORobotSup.

FacadeRobots

Sup.Robot

RegistrySup.

MqttConnector

Sup.

Robot

RobotRegistry

MqttConnector


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


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


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

http://revotics.com/store

http://www.warp.io

http://www.warpx.io/resources

http://www.warpx.io/resources


Thank you

the actor based model m2m communication using how to build … · 2019-06-27 · 》 schema...

Documents