IoT & Microsoft Orleans Agenti software che vivono nel cloud come Avatar di dispositivi fisici che vivono…nel mondo reale.

Sponsor

Microsoft Orleans (& IoT)

Criticità dei sistemi IoT Enterprise I tradizionali modelli di sviluppo delle soluzioni IoT non forniscono una soluzione valida quando i numeri crescono Razionalizzare una soluzione comporta una suddivisione di competenze tra diversi Servizi, che al crescere della dimensione del problema tendono a diventare «bottleneck» o «single point of failure» Spesso però esiste la possibilità di una decomposizione del problema in sotto-problemi più semplici, che inoltre beneficiano della capacità di essere parallelizzati e distribuiti

Il Cloud è una soluzione? Storage: utile, anzi utilissimo, ma non gestisce la logica funzionale di una soluzione Hosting Web: contenitore ideale per ospitare il front- end di un sistema…ma non certo per ospitare il sistema in se’ Hosting «Worker»: riesce ad astrarre parzialmente la runtime che «esegue» i nostri Servizi, il sistema operativo che incapsula la runtime e la macchina che ospita il sistema operativo…ma è un contenitore troppo «sottile», privo di Servizi utili alla mia applicazione Infrastruttura di comunicazione: indispensabile…ma fornisce di fatto solo dei «canali di comunicazione»

Serve un nuovo modello! Vorrei poter: Sviluppare logiche applicative in termini di oggetti che implementano le funzionalità «business» richieste Far interagire tra loro tali oggetti, utilizzando i tradizionali concetti dell’OOP Ignorare la complessità della gestione asincrona/parallela di più oggetti che operano simultaneamente Far “girare” questi oggetti liberamente all’interno del Cloud, trascurando la complessità degli aspetti di un deployment distribuito ed adattivo

Microsoft Orleans É una piattaforma che implementa il cosiddetto «Actor Model», in cui gli «Attori» vengono chiamati «Grain» Ogni (istanza di) Grain in Orleans viene eseguita con semantica «single-thread» Ogni Grain è stateful e può persistere il proprio stato nello storage che preferisce I Grain sono creati e distrutti in maniera dinamica, a seconda delle risorse hardware disponibili I Grain comunicano tra loro e con i loro client tramite metodi ed eventi/callback, utilizzando i servizi di remotizzazione della piattaforma Orleans Sono stati appena introdotti anche gli «Stream»!

Un’immagine vale più…

Microsoft Orleans #2 É una piattaforma già matura, in produzione da diversi anni, rilasciata pubblicamente nei primi del 2014 e resa «open» circa un anno dopo Un White Paper di MS Research su Orleans riporta i dati di diversi «lab» sviluppati internamente, uno dei quali replica il backend di Twitter (!), dimostrando performance significativamente superiori Si integra perfettamente nel «ciclo» di sviluppo.NET (supporto NuGet, estensioni per la generazione automatica di codice client, ecc.) PROFEZIA: in futuro lo chiameremo «Azure CLR»

Sviluppare per Orleans Si definiscono le interfacce Interfacce pubbliche dei Grain Interfacce pubbliche dei GrainObserver Modelli POCO/Serializable delle entità business esposte o consumate da Grain e GrainObserver Si definiscono le implementazioni per tali interfacce Metodi delle interfacce Grain Oggetti che implementano le interfacce GrainObserver Modelli POCO/Serializable che definiscono lo stato dei Grain stateful-persistenti Si implementano i front-end Client Web (ASP.NET WebForm, MVC, SignalR, OWIN) Client Worker (per esporre i Grain ad altre applicazioni)

Grain come «Avatar» di Device Mappando mentalmente un (tipo di) «Grain» su un (tipo di) device è facile riconoscere una naturale «empatia» tra i due concetti Entrambi operano parallelamente, indipendentemente e in maniera asincrona Entrambi interagiscono scambiando informazioni strutturate secondo schemi, canali, formati e pattern di messaging ben precisi Entrambi possono contare un numero di istanze ragguardevole, ciascuna delle quali in grado di produrre o consumare un numero spaventoso di messaggi Entrambi mantengono uno stato persistente

DEMO Orleans Railway

Demo: Orleans Railway Il sistema implementa una rete ferroviaria fittizia (magazzino automatico, navette «guida» per ospedali, carrelli robotizzati per centri commerciali, ecc.) Il grafo ferroviario è rappresentato da nodi ( Stazioni ) e archi direzionati ( Strade ), questi ultimi con uno specifico costo/tempo di percorrenza Ogni Navetta fisica ha un proprio Grain «omologo» che ne rappresenta l’Avatar La Demo utilizza un simulatore ( esterno ) che processa i comandi e genera notifiche per conto delle navette device “simulate” ( N_1,...,N_4 )

Demo: Orleans Railway Live Per seguire la demo «live»: Collegatevi all’access-point TP-LINK_TRIFIDO Navigate su

DEMO Orleans Railway (con Simulatore Navette)

Demo: Orleans Railway #2 Validiamo il sistema con dispositivi fisici: Una navetta “fisica” deve processare i comandi inviati (tramite il front-end M2M) dal suo Grain “Avatar” Una navetta “fisica” deve generare notifiche (tramite il front-end M2M) destinate al suo Grain “Avatar” Una navetta “fisica” deve…interagire con il mondo fisico! “Sentire” la prossimità di Strade e Stazioni “Muoversi” lungo i binari (ok, quello lo faccio io )

DEMO Orleans Railway (con Navetta «fisica»)

Q&A #1: Performance Using X-Large VMs (8 CPU Cores / 14 GB RAM) on Microsoft Azure, with one “silo” per VM: A grain will handle a maximum of 1,000 requests per second. A silo will handle a maximum of 10,000 requests per second. A silo will hold 100,000 active grains.

Q&A #2: Orleans Railway Il front-end UI è implementato con SignalR su infrastruttura OWIN Il front-end M2M è implementato sotto forma di client MQTT Il detecting della prossimità di Stazioni e Strade da parte della «Navetta» è implementato con BLE+iBeacon Il gateway iBeacon/MQTT ed il simulatore di navette sono implementati come «flow» Node-Red Il firmware in esecuzione sulla «Navetta» è realizzato con.NET Micro Framework (con il contributo di M2Mqtt di Paolo Patierno e di NETMFBLE del sottoscritto )

Modulo di Feedback per l’evento di oggi

Sponsor