Progettazione e Implementazione di API WebSocket per il Gateway Dog

Transcript

1 Corso di Laurea in Ingegneria Informatica Tesi di Laurea Magistrale Progettazione e Implementazione di API WebSocket per il Gateway Dog Relatori: Fulvio Corno Luigi De Russis Candidato: Teodoro Montanaro

2 Sommario 1. Introduzione Domotica Dog 2. Obiettivi 3. Progettazione 4. Implementazione 5. Test 2

3 Domotica È l integrazione nella vita domestica di diverse tecnologie quali l informatica, l'elettronica, l automazione con lo scopo di migliorare le condizioni di vita dell abitante offrendogli comfort, sicurezza e benessere. Temperature sensor 1 Client 1 1. INTRODUZIONE Power outlet 1 Power outlet 2 Gateway Internet Temperature sensor 2 Client 2 Client 3 Fig.1 Tipico sistema domotico 3

4 Il gateway Dog Dog (Domotic OSGi Gateway) è un gateway in grado di esporre differenti network domotici come un unica rappresentazione neutrale da un punto di vista tecnologico Temperature sensor 1 Gateway Client 1 1. INTRODUZIONE OSGi è un framework che implementa un modello a componenti per l'ambiente Java: bundle che si scambiano informazioni tramite servizi Power outlet 1 Power outlet 2 Temperature sensor 2 Gateway Gateway Fig.2 Tipico sistema domotico modificato tramite Dog Internet Client 3 Client 2 4

5 Obiettivi della tesi 2. OBIETTIVI Progettazione e implementazione di una Application Programming Interface (API) per il gateway Dog in grado di fornire una connessione asincrona e bidirezionale tra il gateway e gli end-user devices (tablet, smartphone, ) La comunicazione deve essere basata su un protocollo e/o una tecnologia standard per il web ampiamente diffusa in grado di fornire supporto a buona parte delle piattaforme software esistenti (per i più diffusi linguaggi di programmazione e/o dispositivi) 5

6 Scelta del protocollo Polling Facilmente integrabile in un ambiente OSGi 3. PROGETTAZIONE SSE WebSocket Fornisce una comunicazione full-duplex quindi permette al gateway di inviare informazioni non appena sono disponibili Nella maggior parte dei casi è più veloce delle tecnologie concorrenti È più supportato dai moderni browser Comet technologies 6

7 Architettura di Dog 3. PROGETTAZIONE Core Layer Drivers Layer Addons Metaprogrammazione: abilità di un programma di ispezionare codice esistente con l'obiettivo di invocare i suoi metodi e le sue funzioni 7

8 Struttura dei messaggi 3. PROGETTAZIONE Campo Significato clientid identifica univocamente l'utente (stabilito dal server) sequencenumber permette di capire a quale richiesta il server ha risposto messagetype tipo di messaggio. Possibili valori: ['request', 'response', 'info'] indica cosa contiene il messaggio. Utilizzato per i messaggi di tipo info e per la registrazione delle notifiche. Possibili valori: ['presentation', notification, type notificationregistration, notificationunregistration ] action endpoint parameters response notification indica l'azione da intraprendere. Corrisponde al verbo HTTP utilizzato nelle REST API. Possibili valori: [ GET, PUT, POST, DELETE ] indica a quale risorsa si vuole accedere. Corrisponde all'url utilizzato nelle REST API. possibili parametri contenuto della risposta (in formato JSON) contenuto delle notifiche (in formato JSON) { } esempio di RICHIESTA "clientid":"1f7170d4", "sequencenumber":"1", "messagetype":"request", "action":"get", "endpoint":"/api/devices/meteringpoweroutlet_3/status" 8

9 Implementazione Obiettivo Implementare un bundle OSGi integrabile in Dog in grado di: fornire supporto agli sviluppatori tramite API WebSocket 4. IMPLEMENTAZIONE accettare messaggi strutturati come precedentemente progettato onopen" onclose onmessage sendmessage 9

10 Gestione dei messaggi Abbiamo 2 tipologie diverse di messaggi da gestire: Messaggi relativi a informazioni da acquisire tramite REST API (metaprogrammazione) Messaggi relativi alle comunicazioni asincrone, ovvero le notifiche 4. IMPLEMENTAZIONE Core Layer Communication Layer 10

11 Gestione dei messaggi Messaggi da acquisire tramite REST API Utilizzo delle annotazioni JAX-RS (Java API for RESTful Services) 4. public class public String getgreetings() { return Hello ; } } esempio di metodo esposto tramite annotazione JAX-RS 11

12 Gestione dei messaggi 4. IMPLEMENTAZIONE 1. Notifiche contenenti: deviceuri notificationtopic 2. Registrazione delle notifiche: { } sottoscrivere TUTTE le notifiche per TUTTI o ALCUNI dispositivi sottoscrivere ALCUNE notifiche per TUTTI o ALCUNI dispositivi "clientid":"1f7170d4", "sequencenumber":"1", "messagetype":"request", "type":"notificationregistration", "action":"put", "endpoint":"/api/devices/notifications" Registrazione di tutte le notifiche per tutti i dispositivi Messaggi relativi alle notifiche { "clientid" : "3cabdc0f", "messagetype" : "info", "type" : "notification", "notification" : { "notificationtopic" : "SinglePhaseActivePower MeasurementNotification", "notificationname" : "newactivepowervalue", "deviceuri" : "MeteringPowerOutlet_3", "powervalue" : "0.0 W" } } Esempio di notifica 12

13 Applicazione d'esempio Creazione di una libreria lato Client: implementa i metodi che gli sviluppatori dovranno utilizzare per generare automaticamente i messaggi da inviare al server Creazione dell'applicazione d'esempio con JavaFX 5. TEST 13

14 Test prestazionali Abbiamo effettuato dei test per valutare le prestazioni delle API implementate effettuando anche un confronto con le API REST esistenti. Nell'ottica di verificare che le API WebSocket fossero più veloci delle API REST abbiamo effettuato i test in 2 diverse condizioni: Test locali: end-user device e gateway erano nella stessa rete locale Test remoti: end-user device e gateway comunicavano attraverso Internet 5. TEST Richiesta Richieste LOCALI Tempi medi REST Tempi medi WebSocket GET /api/v1/devices ms ms PUT /api/v1/devices/mainspoweroutlet_2/location ms ms GET /api/v1/environment ms 7.25 ms POST /api/v1/environment/flats ms ms 14

15 Test prestazionali Richiesta Richieste REMOTE Tempi medi REST Tempi medi WebSocket GET /api/v1/devices ms ms PUT /api/v1/devices/mainspoweroutlet_2/description ms ms 5. TEST GET /api/v1/environment ms ms POST /api/v1/environment/flats ms ms Nei test remoti è molto più evidente che le REST API sono più lente ed il motivo principale è che per ogni richiesta viene effettuata una nuova connessione, mentre in WebSocket una volta stabilita essa viene mantenuta aperta per tutte le richieste. 15

16 GRAZIE per la cortese attenzione! 16