POLITECNICO DI TORINO. Configuration And Management In Internet-Of-Things Middleware Environments

Transcript

1 POLITECNICO DI TORINO III Facoltà di Ingegneria dell'informazione Corso di Laurea in Ingegneria Informatica MASTER S THESIS Configuration And Management In Internet-Of-Things Middleware Environments Relatore: Prof. Luciano LAVAGNO Laureando: Juliver De Jesús GIL HERRERA Correlatori: Istituto Superiore Mario Boella Area Pervasive Technologies Ing. Riccardo TOMASI Ing. Davide CONZON Anno accademico 2013 I Beneficiario COLFUTURO 2010

2 Ringraziamenti A Dio che è presente e vive dentro di me, alla mia famiglia che è il motore della mia vita, a Eliza che è il mio amore e la mia ispirazione, a miei professori e correlatori che sono stati sempre disponibili per darmi il loro orientamento e sostegno, ed a tutti gli altri compagni e conoscenti, con cui ho fatto amicizia. III Beneficiario COLFUTURO 2010

3 Indice RINGRAZIAMENTI...III CAPITOLO I: MIDDLEWARE E SUO UTILIZZO NELLO SCENARIO DELL INTERNET OF THINGS DEFINIZIONE DI INTERNET OF THINGS EVOLUZIONE DEL CONCETTO DI INTERNET OF THINGS Storia L'Internet of Things oggi Situazione in Italia Prospettive future TECNOLOGIE ABILITANTI Paradigma smart Smart object Efficienza energetica degli smart object Standard per i protocolli di comunicazione Bluetooth ZigBee LoWPAN RFID WSN nel contesto dell'internet of things MODELLO ARCHITETTURALE Metodi di comunicazione tra oggetti AMBITI APPLICATIVI DELL'INTERNET OF THINGS PRIVACY E SICUREZZA IOT MIDDLEWARE Aspetti caratterizzanti di un IoT middleware Context-awareness...31 CAPITOLO 2: STATE-OF THE-ART DEI MIDDLEWARE CLASSIFICAZIONE DEI MIDDLEWARE Remote Procedure Call (RPC) Middleware Semantiche Comunicazione Sincrona vs Asincrona Soluzioni attuali Object-based Middleware Object Request Broker Middleware Common Object Request Broker Architecture (CORBA) Soluzioni attuali Publish And Suscribe Middleware Soluzioni attuali Message Oriented Middleware (MOM) Middleware SQL-Oriented Web Application Server ARCHITETTURE DI MIDDLEWARE Service Oriented Architecture (SOA)...67 V Beneficiario COLFUTURO 2010

4 Architettura di servizio Infrastruttura SOA Web Services Service Oriented Device Architecture (SODA) Architettura Devices Profile for Web Services...77 CAPITOLO 3: SISTEMI DI CONFIGURAZIONE DEI MIDDLEWARE COMMISSIONING AND PROVISIONING COMMISSIONING TOOLS NEL SETTORE ENERGETICO Energy Management Commissioning tool commerciali LINKSMART Introduzione Architettura Virtual Address 2.x Gestione dell'identità e discovery Installazione e configurazione di Linksmart Linksmart Configurator Network Manager Status...99 CAPITOLO 4: MIDDLEWARE VIRTUS FRAMEWORK E ALTRE TECNOLOGIE COMPLEMENTARI OSGi Protocollo XMPP Openfire Knopflerfish SOLUZIONI UTILIZZATE PER REALIZZARE LE FUNZIONALITÀ DEL MIDDLEWARE Protocollo di comunicazione Tecnologie usate DESCRIZIONE DELL'ARCHITETTURA VIRTUS Moduli del sistema Comunicazione interna ad una singola istanza Presenze Publish/subscribe Messaggi di chat Ad-hoc commands COMUNICAZIONE MULTI-DOMINIO Presenze Publish/subscribe Ad-hoc commands COMPONENTI SOFTWARE DELLA SOLUZIONE Manager Gateway Altri bundle Modularità della soluzione Interfacciamento verso altre soluzioni INTERFACCIA UTENTE VI Beneficiario COLFUTURO 2010

5 4.6.1 Configurazione del software Bundle del sistema Bundle opzionali Aggiornamenti e Legenda SVILUPPI INTRODOTTI Configurazione dell'ambiente Configurazione di eclipse e Knopflerfish Operazioni compiute Risultati ottenuti CONCLUSIONI E SVILUPPI FUTURI BIBLIOGRAFIA E WEBLIOGRAFIA VII Beneficiario COLFUTURO 2010

6 INTRODUZIONE Il concetto di Internet of Things (IoT) è definito come un evoluzione dell attuale Internet, che ha lo scopo di permettere a tutti gli oggetti identificabili univocamente in digitale, di comunicare con altri oggetti e sistemi distribuiti attraverso Internet, utilizzando standard aperti. Questo paradigma permette di fornire molti servizi innovativi, pervasivi e ubiqui, che trovano applicazione sia in settori tradizionali come automazione o controllo industriale, sia in campi più moderni, come e-health, smart energy e smart city, tra gli altri. Una delle principali tecnologie abilitanti per l Internet delle Cose è quella dei tag RFID. Infatti, questi tag associati ad un oggetto non «intelligente», possono identificarlo univocamente ed essere utilizzati per memorizzare informazioni sull oggetto stesso. Anche la standardizzazione di tecnologie wireless, come le consolidate Bluetooth e ZigBee e le più recenti 6LoWPAN e COAP, ha avuto una grande importanza nella diffusione del concetto di IoT, perché ha permesso di avere sensori poco invasivi, sensibili, economici e molto accurati, i quali non perturbano i parametri misurati dagli altri sensori esposti, possono essere stand-alone oppure raggruppati in reti di sensori e possono funzionare in maniera indipendente. Tali sensori sono utilizzati per raccogliere informazioni in tempo reale su parametri dell ambiente circostante (context-awareness), come temperatura, localizzazione, movimento, etc. E possono essere gestiti ed integrati in piattaforme tecnologiche per l IoT. Affinché questi oggetti intelligenti possano interagire tra di loro a dispetto delle differenze in termine di hardware, software e protocolli di comunicazione usati, una soluzione comune è quella di utilizzare uno strato software detto middleware. Si tratta di un importante componente architetturale per il supporto delle applicazioni distribuite, che usualmente si posiziona tra applicazioni e sistema operativo. Il ruolo del middleware è quello di presentare un modello di programmazione unificato per progettisti e sviluppatori di applicazioni e di mascherare i problemi di eterogeneità tra gli oggetti e di distribuzione del software. Vista la complessità delle piattaforme per l Internet of Things, un aspetto molto importante per facilitare l uso di tali sistemi è il tool di configurazione che viene fornito con esse, il quale deve permettere di 1 Beneficiario COLFUTURO 2010

7 configurare un'istanza del sistema, gestire il ciclo di vita dei vari moduli che lo compongono ed avere un'idea chiara in tempo reale del loro stato di esecuzione, facilitando l utente sia nella fase di commissioning della piattaforma, sia nella fase di configurazione dei vari componenti. L obiettivo di questa tesi è quello di estendere l attuale tool di configurazione del middleware VIRTUS, basandosi sulle considerazioni fatte studiando lo stato dell'arte dei metodi per la configurazione e la gestione di architetture software distribuite, come i middleware. Vista l ampiezza del campo di possibili soluzioni, si è scelto di concentrarsi su alcune soluzioni nel settore smart energy/smart building, ritenuto di particolare interesse, e sul middleware open-source LinkSmart. VIRTUS è un middleware IoT-oriented che, facendo leva su strumenti aperti e standard, offre una soluzione scalabile, agile e totalmente event-driven, per il supporto di applicazioni per l IoT. L architettura di VIRTUS prevede uno strumento per la configurazione e la gestione del middleware. Questo software permette all utente di connettere tra loro i vari moduli del sistema, di controllare, in fase di esecuzione, il ciclo di vita del software (start, stop, riavvio e configurazione) e di recuperare lo stato di esecuzione attuale delle applicazioni. Dopo la fase di studio, si è deciso di concentrare gli sviluppi sulla funzionalità di configurazione dinamica di applicazioni multi-dominio, cioè quelle in cui devono comunicare tra loro moduli appartenenti ad istanze di middleware diverse, perché non ancora presente nel sistema di configurazione di VIRTUS. Oltre ad aggiungere questa feature, nello stesso contesto, è stato implementato anche un sistema di discovery, per permettere di scoprire quali sensori sono presenti in un istanza remota di VIRTUS e scegliere quelli che interessano per completare la configurazione della propria applicazione. Quest ultima parte è stata realizzata attraverso l uso del protocollo XMPP, protocollo di messaggistica istantanea open, utilizzato in VIRTUS per la comunicazione tra le varie entità. Il presente lavoro è strutturato in 4 capitoli: nel primo capitolo vengono analizzati a livello generale i concetti di IoT e middleware. Il secondo capitolo descrive come si possono classificare i middleware e le loro diverse architetture. Nel terzo capitolo è presentato lo studio fatto sui principali sistemi di configurazione e commissioning tools 2 Beneficiario COLFUTURO 2010

8 nell ambito smart-energy e su LinkSmart. Nell ultimo capitolo si descrive l architettura del middleware VIRTUS, il suo sistema di configurazione ed, infine, vengono dettagliati gli sviluppi fatti (con possibili evoluzioni) e le conclusioni. 3 Beneficiario COLFUTURO 2010

9 4 Beneficiario COLFUTURO 2010

10 PARTE 1 MIDDLEWARE E SUO UTILIZZO NELLO SCENARIO DELL'INTERNET OF THINGS 5 Beneficiario COLFUTURO 2010

11 6 Beneficiario COLFUTURO 2010

12 CAPITOLO I: Concetto di Middleware e suo utilizzo nello scenario dell Internet of Things 1.1 Definizione di Internet of Things Figura 1: Paradigma dell internet of things L Internet of Things (IoT) è un nuovo paradigma tecnologico in cui il mondo virtuale delle tecnologie dell'informazione e della comunicazione è strettamente integrato con il mondo reale delle cose e si basa sull idea di smart objects oggetti dotati d identità, che possono essere localizzati, che hanno capacità d interazione con l ambiente circostante e di elaborazione di dati. Questi oggetti sono tra loro interconnessi in modo che possano scambiare le informazioni possedute, raccolte e/o elaborate. Una definizione di IoT (anche noto come Web 3.0), formulata nella Strategic Research Agenda of the Cluster of European Research Projects on the Internet of Things (CERP-IoT in 2009), è la seguente: l'iot può essere definita come una infrastruttura di rete globale e dinamica con capacità di auto configurazione sulla base di protocolli di comunicazione standard e interoperabili, dove gli oggetti fisici e virtuali hanno un identità, attributi fisici, personalità virtuale e utilizzano interfacce intelligenti, oltre ad essere perfettamente integrati nella rete di telecomunicazione. [1] Gli ambiti applicativi sono innumerevoli e molti di questi potrebbero avere impatti importanti sulle attività d imprese private e pubbliche 7 Beneficiario COLFUTURO 2010

13 amministrazioni, oltre che modificare in meglio, auspicabilmente la vita della gente. Smart City, Smart Home, Smart Energy, Smart Environment, Smart Logistics, Smart Car, ehealth sono solo alcuni dei termini che sinteticamente evocano gli scenari applicativi. 1.2 Evoluzione del concetto di Internet of Things Storia Secondo Cisco Internet Business Solutions Group (IBSG), Internet of Things è nato tra il 2008 e il 2009, in un momento in cui le cose erano più connesse a Internet delle persone. Di seguito una rapida rassegna degli eventi rilevanti che hanno segnato la nascita e l'evoluzione di Internet of Things. Dovremmo tornare al 1926 per discutere di Nikola Tesla, i cui studi hanno costituito la base delle comunicazioni wireless e radio. Nel 1969, è stato inviato il primo messaggio attraverso ARPANET. Dieci anni dopo si sono stati creati i protocolli di rete TCP/IP, che sono la base di Internet e consentono la trasmissione di dati tra computer. Nel 1990 Tem Berners-Lee definisce il protocollo HTTP (Hypertext Transfer Protocol), che permette una lettura ipertestuale non sequenziale dei documenti e realizza la prima comunicazione con successo tra un HTTP-Client e un server su Internet, e stata la base per il World Wide Web. Lui stesso, un anno dopo ha creato la prima pagina Web. Da quel momento in poi, lo sviluppo tecnologico cresce rapido e costante, e comincia la rivoluzione di Internet. Nel 1999, Kevin Ashton ha tenuto una conferenza presso Procter & Gamble, dove ha parlato per la prima volta del concetto di Internet delle cose (Internet of Things). Nei primi anni di questo secolo, il termine è menzionato in pubblicazioni importanti come The Guardian, Scientific American e la Boston Globe. Anche la tecnologia RFID, che è una delle tecnologia abilitanti come si vedrà in seguito, inizia a essere distribuita in maniera massiccia, sia dal Dipartimento della Difesa degli Stati Uniti sia da Walmart a livello commerciale. Nel 2005, l agenzia delle Nazioni Unite International Telecommunications Union-ITU ha pubblicato il primo studio sull'argomento. Da quel momento Internet of Things è visto con maggiore importanza a livello mondiale. 8 Beneficiario COLFUTURO 2010

14 Nel 2008 un gruppo di aziende si unisce per creare l'alleanza IPSO con l'obiettivo di promuovere l'uso del protocollo di Internet in reti di oggetti intelligenti e rendere possibile L IoT. Attualmente in IPSO partecipano 59 aziende di tutto il mondo come Bosch, Cisco, Ericsson, Motorola, Google, Toshiba e Fujitsu. Nel 2010, il premier cinese Wen Jiabao ha detto che l IoT era una delle tecnologie chiave per l'industria della Cina in tutti i settori della produzione di beni e servizi. In febbraio 2011, IANA (Internet Assigned Numbers Authority) ha assegnato gli ultimi blocchi liberi IPv4 (Internet Protocol versione 4), dei milioni d indirizzi che esistenti. Per questo nel 2012 viene lanciato il nuovo protocollo IPv6 che è la versione sei dell'internet Protocol designata come successore dell'ipv4, con l Ipv6 si quantifica che per ogni metro quadrato di superficie terrestre, ci sono indirizzi IPv6 unici disponibili, questo risolverebbe per un lungo periodo il problema dell'esaurimento degli indirizzi IPv4. Questo è un vantaggio per la diffusione dell IoT, perché permette la connessione ad internet di un, potenzialmente illimitato, numero di oggetti. Nello stesso periodo, Samsung, Google, Nokia e altri produttori annunciano i propri progetti NFC (Near Field Communication), tecnologia che permette nuove applicazione nel campo dell internet of things. Inoltre, si crea l iniziativa IoT-GSI Global Standard per promuovere l'adozione di standard per IoT a livello globale. Infine, La Cina continua a investire e favorire lo sviluppo e la ricerca in Internet of Things con istituzioni, come Shanghai Institute o l'accademia Cinese delle Scienze. [2] L'Internet of Things oggi Grazie ai progressi delle tecnologie wireless e satellitari, oggi l'internet of Things è una nuova dimensione tecnologica, attraverso la quale è possibile mettere a sistema il mondo analogico, attraverso tutta una serie di accessi, ognuno dei quali veicola una serie d informazioni e tecnologie, quali sensori, tag RFID, cellulari, smartphone, tablet, chioschi multimediali, telecamere, videocamere, ecc. l IoT include più standard tecnologici, come ad esempio, GPS (Global Positioning System) e NFC. Attualmente, i primi gangli dell'internet of Things hanno cominciato a funzionare in modo del tutto autonomo: telecamere per gestire le zone a traffico limitato, smart card e pass RFID per gestire gli accessi e i parcheggi, centraline che rilevano grazie ai sensori i tassi d inquinamento, per 9 Beneficiario COLFUTURO 2010

15 attivare politiche maggiormente ecosostenibili, gestione dei rifiuti intelligente, attraverso nuovi sistemi di monitoraggio e di raccolta, che utilizzano strumenti d identificazione univoca per erogare servizi dedicati, e farmaci dotati di codici Data Matrix. Questi sono solo alcuni dei tanti esempi in cui la Rete è utilizzata come nuova infrastruttura di servizio. Dal 2010, si sono visto diverse applicazioni dell'internet of Things orientate alla conservazione dell energia, la cosiddette smart grid, infatti, applicano un utilizzo intelligente del consumo elettrico, che sfruttando nuove economie di scala e software di supporto. Tra le società che hanno iniziato a investire su questo fronte, si trovano General Electric e Google, che attraverso il consorzio USNAP (Utility Smart Network Access Port) stanno lavorando a un processo di standardizzazione, per definire dispositivi di misurazione tali da permettere all utenza domestica di accedere alle smart grid monitorando i propri consumi Situazione in Italia Tra gli ambiti applicativi più consolidati in Italia troviamo alcune soluzioni semplici, con oggetti dotati di una sola funzione specifica e che rispecchiano solo marginalmente le caratteristiche di apertura e raggiungibilità che caratterizzano l'internet of Things. Esempi sono l'antintrusione e la videosorveglianza (Smart Home & Building, Smart City & Smart Environment), la gestione delle flotte aziendali (Smart Logistics), la tracciabilità di oggetti di valore, come ad esempio apparecchiature elettro-biomedicali, e la manutenzione di dispositivi e impianti (Smart Asset Management), il monitoraggio del traffico cittadino tramite telecamere o spire conduttive e la localizzazione dei mezzi utilizzati per il trasporto pubblico (Smart City & Smart Environment). [3] Al gruppo degli ambiti consolidati appartengono, però, anche soluzioni già più vicine al paradigma Internet of Things, caratterizzate da una maggiore raggiungibilità degli oggetti e, in alcuni casi, dalla presenza di funzionalità di elaborazione dati in locale: i contatori intelligenti per la misura dei consumi elettrici (Smart Metering electric), le soluzioni domotiche per l energy management, la sicurezza delle persone e la gestione di scenari 10 Beneficiario COLFUTURO 2010

16 ambientali (Smart Home & Building), i servizi di info-mobilità e i box GPS per la localizzazione dei veicoli privati e la registrazione dei parametri di guida (Smart Car). Figura 2: Stato dell IoT in Italia Nel grafico di Figura 2 gli ambiti applicativi vengono posizionati a seconda del grado di aderenza al paradigma IoT in Italia e del grado di maturità che può essere embrionale, sperimentale e consolidato. Allarme antintrusione, gestione accessi e videosorveglianza, telecontrollo del riscaldamento, smart logistics e smart asset sono le aree fortemente consolidate con un grado di aderenza basso, mentre smart car, smart home & building presenta un grado di aderenza medio. Smart metering, rete viaria e gestione traffico, e raccolta rifiuti sono in fase sperimentale con un grado di aderenza basso, invece monitoraggio del territorio presenta un grado di aderenza media. In fase embrionale, con grado di aderenza medio, si trovano raccolta rifiuti e anche sicurezza e controllo del territorio, mentre rete viaria e gestione traffico, monitoraggio ambientale e trasporto pubblico hanno un grado di aderenza alto.[4] 11 Beneficiario COLFUTURO 2010

17 1.2.3 Prospettive future Oggi sono connessi a Internet circa 1,9 miliardi di personal computer, mentre i cellulari connessi alla Rete sono quasi 1,3 miliardi. Secondo gli analisti, da qui ai prossimi dieci anni i dispositivi collegati a Internet supereranno i 100 miliardi. Attraverso l Internet of Things sarà virtualmente possibile identificare e gestire in modalità remota dispositivi e veicoli, tracciare animali e cose, sfruttando tag RFID, chip e bar code bidimensionali, sensori a infrarossi e sistemi di georeferenziazione, collegati a Internet o a una qualsiasi rete di telecomunicazioni. La nazione che in questo momento è più avanti nello sviluppo dell'internet of Things è la Cina, che da tempo ha introdotto misure atte a supportare l IoT offrendo incentivi economici e detrazioni fiscali. È il caso di Jinan Yinquan Technology, una delle sussidiarie del gruppo CIIS (China Intelligence Information Systems), che è stata selezionata dal governo di Shandong come una delle aziende di riferimento del prossimo piano quinquennale tra 2011 ed il 2015, dedicato a uno sviluppo industriale dell Internet of Things o, com è chiamato più semplicemente, The Plan. Il programma prevede che da qui ai prossimi cinque anni la provincia di Shandong diventi la culla geografica industriale della IoT cinese.[5] 1.3 Tecnologie abilitanti Paradigma smart La società attuale è sommersa da tante tecnologie che sono orientate all'ecosistema dell'internet of things e dove un nuovo paradigma sta emergendo: il paradigma Smart. Questo paradigma è guidato dall'emergere dei cosiddetti smart object, ovvero oggetti di uso quotidiano che assumono nuove funzionalità e nuove modalità d interazione con gli esseri umani e con il contesto. In questo paradigma, gli oggetti fisici sono dotati di capacità di rilevamento, di calcolo e di comunicazione e sono in grado di percepire e interagire con l ambiente e con altri smart object. 12 Beneficiario COLFUTURO 2010

18 Dotare di capacità di elaborazione gli oggetti abilita diverse modalità d interazione e comunicazione: da persona a dispositivo (ad esempio per la pianificazione, il controllo remoto, o l'aggiornamento di stato), da dispositivo a dispositivo o da dispositivo a rete (ad esempio in applicazioni per programmare il carico elettrico nell orario più favorevole, in sistemi che prevedono fasce orarie di prezzo dell'energia elettrica). Gli smart object possono costituire una risposta alle sfide ambientali, sociali ed economiche che derivano dalla scarsità di risorse, dal cambiamento climatico, dall'invecchiamento della popolazione e dalla globalizzazione. Per questo motivo, sono sempre di più utilizzati in un gran numero di settori, soprattutto nei trasporti, nella sanità, nell energia e ambiente, nella sicurezza, nella logistica, nelle ICT e nel manifatturiero Smart object Figura 3: Ossipulsimetro digitale Al di là di telefoni cellulari, tablet, computer e altri dispositivi IT tradizionali collegati alle reti, sta gradualmente crescendo la diffusione di dispositivi intelligenti, via via che sempre più oggetti di natura diversa vengono connessi in rete. Ad esempio: dispositivi di monitoraggio medico sul corpo (Figura 3), sistemi telematici per la sicurezza stradale, servizi di prenotazione automatica, sistemi di assistenza alla guida dei veicoli ecc. Stiamo entrando in un'epoca di asset più intelligenti", in cui gli asset del mondo fisico (ad esempio sistemi HVAC, container, macchinari, tubazioni, etc.) possono monitorare gli eventi, eseguire funzioni e automatizzare i processi aziendali. La comunicazione tra dispositivi intelligenti sta convergendo con l'it e le infrastrutture di rete per migliorare notevolmente l'efficienza e la produttività. Gli smart objects, pertanto, sono dei "normali" oggetti ai quali sono applicati dispositivi come RFID o QrCode, che aggiungono i seguenti caratteristiche: 13 Beneficiario COLFUTURO 2010

19 Sono indirizzabili in modo univoco, sicuro, universale. Hanno un intelligenza autonoma (smartness), che permette all'oggetto di conoscere le sue proprietà comuni quali le creazioni, il riciclo, la trasformazione, il cambio di titolarità o l'uso per diversi scopi e sono in grado di reagire a sollecitazioni esterne (elettroniche abitualmente), applicate ai suddetti dispositivi ed interagire attivamente con l'ambiente con un alto grado di autonomia nella cattura dei dati e gestione di eventi. Posseggono un elevato grado di connettività e interoperabilità per comunicare tra di loro o con gli esseri umani nell'ambito de nuovo paradigma di IoT.[6] Efficienza energetica degli smart object L interoperabilità a livello degli oggetti richiede hardware e software con maggiore complessità e capacità prestazionale. Per questo motivo, L efficienza energetica dei dispositivi diventa pertanto fondamentale per garantire la sostenibilità e la qualità del servizio della futura Internet of Things. Il livello di mediazione svolto tradizionalmente dai dispositivi gateway dovrà essere sempre più svolto dagli oggetti stessi. L evoluzione delle capacità di elaborazione dell hardware deve quindi essere accompagnata da una riduzione dei consumi energetici (attraverso l'utilizzo di sistemi dedicati System on Chip SoC ultra low-power), da un aumento delle capacità energetiche delle batterie per garantire un maggiore tempo di vita dei dispositivi (utilizzando ad esempio batterie a film sottile agli ioni di litio) e dall'introduzione (laddove possibile o necessario) di meccanismi di approvvigionamento energetico, capaci di acquisire energia dall ambiente in cui operano (ad esempio pannelli solari). Per supportare questa maggiore complessità hardware, che rende le unità della rete maggiormente soggette a malfunzionamenti e guasti, gli oggetti fisici dovranno poi essere dotati di meccanismi software intelligenti, volti alla validazione dei dati raccolti, così da individuare, isolare e identificare autonomamente eventuali guasti e intervenire in maniera proattiva sulla rete stessa (aspetto fondamentale quando le unità fanno parte di una rete di sensori e attuatori, dovendo pertanto fornire un azione di controllo o essere in grado di prendere localmente delle decisioni). 14 Beneficiario COLFUTURO 2010

20 1.3.3 Standard per i protocolli di comunicazione Uno degli aspetti fondamentali, che ha permesso l evoluzione del concetto di IoT è il consolidarsi di un buon numero di standard per la comunicazione, che garantiscono interoperabilità tra i singoli dispositivi. In questo paragrafo verranno trattati tre fra i più interessanti: Bluetooth, le cui specifiche sono promosse e sviluppate dal Bluetooth SIG (Special Interest Group), che gestisce i programmi di qualifica e si occupa anche della protezione del marchio; ZigBee definito e promosso dalla ZigBee Alliance; e 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks) controllato dall IPSO Alliance Bluetooth Bluetooth è uno standard tecnico industriale di trasmissione dati per reti personali senza fili WPAN (Wireless Personal Area Network). Fornisce un metodo standard, economico e sicuro per scambiare informazione tra dispositivi diversi, siano fissi o mobili, attraverso una frequenza radio sicura a corto raggio. Creato da Ericsson nel 1994, originalmente era pensato come un alternativa senza fili ai cavi dati RS-232. Ora, Bluetooth fornisce un modo sicuro di interconnettere e scambiare informazioni fra dispositivi come smartphone, tablet, stampanti, telefoni, computer, portatili, sistemi GPS, camere digitali e console per videogames ecc. Come ho detto in precedenza, Bluetooth è gestito dal Bluetooth SIG (Special Interest Group), che consta di oltre compagnie nell area delle telecomunicazioni, computing, networking ed elettronica di consumo. Dal punto di vista pratico, lo scambio delle informazioni tra dispositivi Bluetooth avviene attraverso la creazione di PAN (Personal Area Networks), con alti livelli di sicurezza. Bluetooth usa la tecnologia radio chiamata AFH (Adaptive Frequency-Hopping spread sprectum), la quale spezzetta i dati da inviare e invia le varie parti su 79 bande diverse (1 MHz ciascuna, centrate da 2402 a 2480 MHz), nel rango fra i 2400 e 2483,5 MHz (comprendendo le bande di guardia). Questo 15 Beneficiario COLFUTURO 2010

21 rango è inserito nella banda di radio frequenze libere a corto raggio 2.4 GHz ISM (Industrial, Scientific and Medical). Si tratta di un protocollo a pacchetti con una struttura master-slave. Un master può comunicare con fino a 7 slave in una piconet, una rete ad hoc in cui la velocità di trasferimento dati può variare fra i 200 e i 1200 kbit/s. I dispositivi possono cambiare il proprio ruolo, quindi lo slave può diventare master e viceversa. La specifica Bluetooth indica la possibilità di connettere due o più piconet per formare una scatternet, in cui certi dispositivi fanno da bridge, svolgendo simultaneamente il ruolo di master in una rete e di slave nell altra. I dispositivi Bluetooth sono divisi in tre classi, che si distinguono secondo la massima potenza consumata: 100 mw per la classe 1, 2.5 mw per la classe 2, 1 mw per la classe 3; secondo la classe di appartenenza, varia il raggio d azione dei dispositivi: 100 metri per la classe 1, 10 metri per la classe 2 e 1 metro per la classe 3. Ovviamente, questi valori possono variare, infatti sono influenzati delle condizioni di propagazione, del materiale di copertura del dispositivo, delle configurazioni dell antenna e delle condizioni della batteria. Bluetooth è un protocollo standard per la comunicazione senza fili, progettato originariamente per bassi consumi e comunicazioni a corto raggio, basato su microchip a basso costo, integrati in ogni dispositivo. Utilizzando un sistema di comunicazione radio, i dispositivi che usano Bluetooth per comunicare, possono anche essere fuori linea di vista, ovvero, possono comunicare, anche se ci sono degli ostacoli interposti, oppure se non si trovano nella stessa stanza, in accordo con i ranghi previsti dalla propria classe di appartenenza. [7] Le applicazioni della tecnologia Bluetooth sono molteplici: Comunicazione senza fili tra telefono mobile e auricolare. Connessione di un pc a strumenti d input/output come mouse e stampanti. Trasferimento di file o sincronizzazione di dispositivi per agende, calendari. 16 Beneficiario COLFUTURO 2010

22 ZigBee La ZigBee Alliance raccoglie importanti vendor di sistemi dedicati, di moduli radio, di microprocessori/microcontrollori, di elettrodomestici e di sistemi di domotica. La soluzione ZigBee definisce diversi profili applicativi, condivisi da tutti i dispositivi che cooperano alla realizzazione di un determinato servizio, garantendo interoperabilità tra dispositivi di diversi rivenditori. Si tratta della specifica di un set di protocolli di comunicazione ad alto livello.[8] Tali protocolli prevedono l'utilizzo di antenne a basso consumo e si basano sullo standard IEEE , per la creazione di LR-WPANs (Low-Rate Wireless Personal Area Networks). Questi collegamenti sono adatti per trasferimenti dati, con bit-rate non elevati. La tecnologia definita dalle specifiche ZigBee vuole essere più semplice e meno costosa degli altri tipi di WPANs (come ad esempio il Bluetooth) ed è indirizzata alle applicazioni a radio frequenza che richiedono lunga durata della batteria, reti sicure e basse velocità di trasmissione. ZigBee comporta tre vantaggi principali, rispetto ad altri protocolli: Il basso costo permette alla tecnologia di essere largamente utilizzata in applicazioni di controllo wireless e monitoraggio. L'utilizzo a basso consumo permette maggiore durata con batterie più piccole. Grazie alla possibilità di creare reti a maglia (in cui non esistono server centrali, ma in cui ogni nodo fa da ricevitore, trasmettitore e ripetitore), si possono creare reti che permettono grande affidabilità. Come ruolo principale, la ZigBee Alliance ha standardizzato il corpo principale che definisce ZigBee, ed inoltre, pubblica profili applicativi, che permettono a più venditori OEM di creare prodotti interoperabili fra loro. In particolare, in confronto a Bluetooth, ZigBee ha alcuni vantaggi: La capacità di attivarsi in 30 msec o meno, quindi la latenza è molto bassa ed i dispositivi che lo usano possono essere molto 17 Beneficiario COLFUTURO 2010

23 più reattivi rispetto a quelli Bluetooth, che impiegano di solito circa tre secondi. La possibilità di essere per la maggior parte del tempo disattivato, riducendo di molto i consumi e aumentando la durata della batteria. I protocolli ZigBee sono intesi per l uso in applicazioni embedded, che richiedono basse velocità di trasmissione e bassi consumi. Alcuni mercati di riferimento di ZigBee sono quelli delle telecomunicazioni, dell elettronica di consumo, della sanità e del controllo industriale. L utilizzo di ZigBee permette di ridurre i costi ed i consumi energetici, infatti i singoli dispositivi devono avere una durata della batteria di almeno 2 anni per avere la certificazione ZigBee. Le tipiche applicazioni ZigBee sono nella domotica (illuminazione intelligente, controllo della temperatura, sicurezza della casa) e nelle WSN (Wireless Sensor Network) LoWPAN 6LoWPAN è il nome di un gruppo di lavoro nel settore Internet della IETF (Internet Engineering Task Force). L obiettivo è di usare sui dispositivi fisici di bassa potenza e con capacità di elaborazione limitate gli stessi standard di comunicazione dell Internet classico IPv6+TCP, rendendo quindi i dispositivi stessi accessibili con le stesse procedure (e protocolli) con cui si accede ad esempio a server web. Questo permette e facilita ai dispositivi partecipare all Internet of things. Al momento, gli approcci Bluetooth e ZigBee presentano una maggiore maturità, in ragione del fatto che i lavori dell IPSO Alliance sono iniziati da poco. Esistono tuttavia già soluzioni ibride in cui l'approccio ZigBee, per esempio, sfrutta primitive di comunicazione 6LowPAN.[9] Il gruppo 6LoWPAN ha definito i meccanismi di compressione e incapsulamento dell intestazione, che permettono ai pacchetti IPv6 di essere inviati e ricevuti da reti basate su IEEE IPv4 e IPv6 sono i sistemi di trasporto per la consegna dei dati in reti locali di dati, reti metropolitane e reti geografiche, come Internet RFID La più consolidata e ormai datata, in senso strettamente cronologico, tecnologia alla base dell IoT è la tecnologia RFID (Radio Frequency 18 Beneficiario COLFUTURO 2010

24 Identification). È semplicemente un sistema d identificazione che sfrutta le onde radio per trasmettere informazioni. Le componenti necessarie sono il tag (o transponder) e il lettore[10]. Il tag (figura 4), composto di microchip, antenna, eventuale batteria e supporto, comunica con il reader, che oltre a ricevere i dati, è in grado di convertire le onde radio del tag in un segnale digitale trasferibile su un computer. Perché siano in grado di comunicare fra loro, è necessario che transponder e reader siano sintonizzati sulla stessa frequenza. I tag sono caratterizzati da un identificativo univoco e sono applicati sugli oggetti, come anche sulle persone e sugli animali. Possono essere attivi, in questo caso sono alimentati da una batteria; Semi-attivi, alimentati da batterie solo per mantenere attiva la parte circuitale interna, mentre per l'irradiazione utilizzano una parte dell'energia ricevuta dall'onda radio che trasmette anche le informazioni; E infine passivi, in questo caso non posseggono alcuna fonte di alimentazione interna, ma traggono energia dall'onda radio inviata dal lettore che li interroga. La tecnologia RFID si può considerare un'evoluzione dei bar code monodimensionali, i quali, sono ormai inadatti all attuale panorama della convergenza tecnologica.[11] Certamente, per il momento, il bar code rimane più economico rispetto ad altri tipi di supporto, ma i progressi nel campo della produzione dei tag sono già numerosi, e l abbassamento dei prezzi è un trend già attivo. Inoltre, un grande vantaggio di questi transponders è che il loro supporto non deve essere necessariamente un materiale classico come la carta o la plastica: sono attualmente previsti tag integrati nei tessuti, nei metalli, nel cibo, e nelle polveri. In molti casi questi espedienti permetteranno ai tag di sopravvivere ad ambienti estremamente inospitali, dove per l uomo la sopravvivenza è messa a repentaglio. È facile intravedere, in questo senso, la grande utilità scientifica di queste reti, potenti e diffuse, in grado di dar voce alle entità più impensabili anche negli scenari più ostili. La miniaturizzazione e le nanotecnologie, si prospettano infatti come nuove importantissime componenti dell'internet delle Cose, che si avvarrà di sensori adatti a essere incorporati in unità davvero minime, addirittura della dimensione di un granello di polvere. Anche in questo caso, le ricadute per la ricerca sono enormi e fondamentali. 19 Beneficiario COLFUTURO 2010

25 Figura 4: Tag RFID Nelle applicazioni business, i sistemi RFID vengono sempre di più impiegati nella gestione della catena di fornitura, con i reader distribuiti lungo l'impianto di produzione, nei magazzini e nei negozi al dettaglio. In generale, i sensori e i tag si stanno adottando in tutto il manifatturiero e nella logistica, con l'obiettivo di monitorare i processi e la qualità dei prodotti. Ad oggi, per RFID gli standard principali, almeno nell'ambito della logistica, sono quelli forniti da EPC GLOBAL, ma anche ETSI ed ISO ne propongono di propri WSN nel contesto dell internet of things Altra tecnologia importante è quella delle WSN (Wireless Sensor Network). Si tratta di una determinata tipologia di rete, realizzata da un insieme di dispositivi elettronici autonomi, in grado di prelevare dati dall'ambiente circostante e di comunicare tra loro. Essa è composta da sensori di piccole dimensioni, bassa capacità, basso costo e basso consumo energetico. Questi sensori vengono, di solito, distribuiti in un area di monitoraggio e acquisiscono dati relativi ad uno o più fenomeni osservati, per poi essere inoltrati ad un nodo, il quale li gestisce in un processo decisionale. Le WSN sono in grado di prelevare dati dall'ambiente circostante e comunicarli tra di loro oppure ad un nodo remoto, per raggiungere un obbiettivo comune, come ad esempio monitorare la presenza di persone in una determinata zona. Attualmente, tra i nodi reperibili sul mercato, i più comuni sono delle famiglie: Telos, Texas Instruments, Zolertia, STM32 e Waspmote. Alla lista se ne aggiungono molti altri, ognuno con proprie caratteristiche di elaborazione dati (CPU, RAM, memoria fisica, ecc.) e durabilità della batteria. 20 Beneficiario COLFUTURO 2010

26 L'interesse per questo tipo di rete, negli ultimi anni, è dovuto al suo potenziale utilizzo in una vasta gamma di applicazioni. Tra le applicazioni in cui è possibile far uso di una rete di sensori WSN esiste il monitoraggio di ambienti fisici, quali il traffico in una grande città oppure dati rilevati da un'area disastrata da un terremoto, sorveglianza nei campi di battaglia, home automation (domotica), controllo all'interno di veicoli (di velocità, temperatura), geolocalizzazione e tracking, controllo qualità dell'aria o acqua ed eventuale segnalazione in caso di pericolo per l'uomo, regolazione automatica dell'illuminazione o della temperatura, controllo continuo parametri vitali, monitoraggio temperatura e segnalazioni di valori fuori scala (incendio), sensori di presenza in un parcheggio coperto per mappare i posti liberi e quelli occupati e molte altre.[12] Nonostante ciò, l'eterogeneità dei dispositivi, delle tecnologie usate e dei fornitori presenti, lasciano ancora delle sfide aperte da affrontare, come quella di accedere in modo standard ai servizi offerti dei diversi dispositivi appartenenti alla WSN. 1.4 Modello architetturale Figura 5: Modello architetturale IoT. Fonte: IoT Smart Present or Smart Future? 21 Beneficiario COLFUTURO 2010

27 L'architettura di rete dell Internet of Things può essere articolata su 3 livelli: interfaccia con il mondo fisico, mediazione e centri di controllo. Tag RFId e lettori, nodi sensore, gateway e centri di controllo sono solo alcuni degli elementi funzionali che vanno a costituire l'internet of Things. Questi dispositivi, che si differenziano per capacità elaborativa e sensoriale, dimensioni, costi e autonomia, sono generalmente strutturati in un architettura di rete a tre livelli, mostrata in figura 5. Interfaccia con il mondo fisico: a questo primo livello un elevato numero di nodi (tag o unità sensoriali) interagisce con l'ambiente, fornendo un codice identificativo, acquisendo informazioni o comandando un attuatore. Questi nodi possono essere sprovvisti di alimentazione (tag passivi) o alimentati da batteria (unità sensoriali e attuatori) e sono generalmente caratterizzati da una ridotta capacità di elaborazione e memoria. Essi sono inoltre dotati di meccanismi di comunicazione (wired o wireless) per comunicare con le unità del secondo livello. Il costo dipende dalle funzionalità offerte e può variare dai pochi centesimi di euro per tag RFId passivi, fino ai circa 100 euro per i nodi con capacità sensoriale e/o di attuazione; la vita operativa spazia da alcuni anni per i dispostivi alimentati a batteria (fortemente dipendente dal tipo di applicazione), fino a superare i dieci anni per i tag RFId passivi. Mediazione: le unità di secondo livello, di cui fanno parte i lettori di tag RFId e i gateway, hanno il compito di raccogliere le informazioni dai nodi di primo livello per veicolarle ai centri di controllo. Esse sono caratterizzate da una maggiore capacità di elaborazione e memoria, sono generalmente alimentate dalla rete di distribuzione fissa e hanno un costo che può variare molto, dai 50 euro di un nodo gateway ai euro di un reader RFId. Centro di controllo: le unità del terzo livello, di cui fanno parte i sistemi di acquisizione centrale e le sale operative, hanno il compito di ricevere le informazioni dalle unità di secondo livello per le successive fasi di memorizzazione, elaborazione e la messa in fruibilità dei dati. Il costo di queste unità può variare da a euro, trattandosi di calcolatori di fascia medio alta. 22 Beneficiario COLFUTURO 2010

28 1.4.1 Metodi di comunicazione tra oggetti L ecosistema che costituisce l'internet of Things è attualmente caratterizzato da soluzioni altamente eterogenee a livello di hardware, software e protocolli di comunicazione tra gli oggetti del mondo reale e il mondo digitale di Internet. Mentre per tag e lettori RFId l'offerta tecnologica è consolidata, lo stesso non vale per le reti di sensori, in quanto i nodi sensore e i gateway non sono ancora caratterizzati da soluzioni standardizzate né in termini di hardware (Mica Motes, Sunspot, Jennic, ecc.), né di software (Tiny OS, SOS, Mantis, Contiki, FreeRTOS, ecc.), né di middleware (Tiny DB, GSN, DNS, SWORD, ecc.). Diversamente, le unità del terzo livello godono di una maggiore maturità tecnologica che si appoggia ad architetture consolidate per server, interazione Client-Server e basi di dati. La mancanza di standardizzazione nelle unità dei primi due livelli ha portato al consolidarsi di un approccio ad-hoc, volto all ottimizzazione della singola applicazione (ad esempio sotto il profilo energetico) piuttosto che all astrazione dallo specifico problema applicativo a favore di uno sviluppo utile a una più ampia classe di applicazioni. Questa eterogeneità delle soluzioni è ancora più evidente, se si considerano i meccanismi di comunicazione tra i dispositivi, con soluzioni specifiche per il singolo ambito applicativo. Ad esempio, in ambito Smart Home & Building, la tecnologia usata per l'interconnessione tra i dispositivi di livello 1 e livello 2 dipende dallo specifico scenario applicativo; troviamo quindi sia tecnologie radio (come ad esempio IEEE , ZWave, Bluetooth, UWB) sia tecnologie cablate (come ad esempio Power Line Communication). Similmente, in ambito Smart City & Smart Environment esiste una distinzione netta tra le tecnologie di comunicazione dell ultimo miglio e tecnologie di comunicazione per la creazione dell'infrastruttura di backend. Anche in questo caso, a seconda dello scenario applicativo, le tecnologie di ultimo miglio variano da ZigBee, Wireless M-BUS, WiFi e Bluetooth, mentre l infrastruttura di backend si appoggia generalmente alla tecnologia cellulare 2G+, 3G, 4G, Wireless Mesh o Power Line Communication. 23 Beneficiario COLFUTURO 2010

29 Nella seguente figura 6, si vede com è concepita l'interoperabilità nell IoT realizzata a livello di centro di controllo. In questo caso, ogni oggetto si collega direttamente con un concentratore, il quale gestisce le comunicazioni e il trasferimento dati, e comunica con un altro nodo, dove si possono eseguire le applicazioni. Figura 6: Interoperabilità realizzata a livello di centro di controllo. Invece, in figura 7 viene mostrata l'interoperabilità realizzata a livello di dispositivo (oggetto), in questo caso, ogni oggetto può collegarsi direttamente con un altro oggetto ed applicazioni sia in locale, che remotamente. Figura 7: Interoperabilità realizzata a livello di centro di dispositivo. 24 Beneficiario COLFUTURO 2010

30 Quest'ultima configurazione viene considerata come modello d interoperabilità degli smart object, che si producono per applicazioni future nell'ecosistema dell Internet of Things. 1.5 Ambiti applicativi dell'internet of Things Figura 8: Internet of Things: utenti finali e le aree d implementazione. Come detto in precedenza le tecnologie pervasive orientate all'internet of Things hanno diversi campi di applicazione, di seguito vengono analizzati più nel dettaglio. Smart City & Smart Environment: Ha lo scopo di facilitare il monitoraggio e la gestione degli elementi di una città (es. mezzi per il trasporto pubblico o lampioni) e dell'ambiente circostante, per migliorarne la vivibilità, sostenibilità e competitività. Gli impieghi delle soluzioni Internet of Things all'interno delle aree urbane sono molto variegati: dalla rete viaria e gestione del traffico (gestione dei parcheggi, informazioni aggiornate sul traffico, gestione semaforica, illuminazione stradale) al trasporto pubblico (localizzazione dei mezzi di trasporto, monitoraggio istantaneo del flusso di viaggiatori), dalla raccolta rifiuti (identificazione dei cassonetti, monitoraggio del loro livello di riempimento) alla sicurezza e controllo del territorio 25 Beneficiario COLFUTURO 2010

31 (videosorveglianza, individuazione situazioni di pericolo), dal monitoraggio ambientale (misura inquinamento dell aria o dell acqua) al monitoraggio del territorio (prevenzione e monitoraggio di alluvioni, incendi, frane), fino all entertainment e servizi turistici (informazioni a turisti, Smart Poster, percorsi culturali). Smart Metering & Smart Energy: questi campi sono focalizzati sulle reti elettriche e contatori intelligenti per il livellamento del carico della rete, la gestione della produzione distribuita e della mobilità elettrica, nonché la corretta fatturazione dei consumi. Tutto questo per garantire un servizio di elevata qualità e minimizzare il consumo di elettricità, dato che molti miliardi di kwh sono sprecati ogni anno dai consumatori, a causa della mancanza d informazioni sul consumo di energia. Smart Home & Smart Building: permette la gestione automatica d impianti e sistemi (es. Illuminazione e climatizzazione). I dispositivi (es. elettrodomestici) «parlano» tra loro e agiscono autonomamente in un'ottica di risparmio energetico; serve inoltre, per il monitoraggio degli ambienti interni in un ottica di risparmio energetico, comfort e sicurezza delle persone (ad esempio, in impianti industriali). Smart Logistics: soluzioni per la tracciabilità di filiera, la protezione del brand e il monitoraggio della catena del freddo, per la sicurezza in poli logistici complessi e per la gestione delle flotte (tracciabilità del mezzo e delle sue condizioni). Smart Factory: facilita l implementazione di nuove logiche di gestione della produzione, grazie all'uso di macchine sensibili al contesto, in grado di rilevare informazioni in tempo reale, comunicare tra loro e prendere decisioni. Smart Asset Management: si tratta della gestione in remoto di asset di valore (es. dispositivi elettro-biomedicali, vending machine), ai fini di rilevazione guasti e manomissioni, localizzazione, tracciabilità e gestione inventariale. Smart Agricolture: monitoraggio parametri ambientali a supporto dell'agricoltura per migliorare la qualità dei prodotti, ridurre le risorse utilizzate e l'impatto ambientale. Smart Car: connessione tra veicoli o tra questi e l'infrastruttura circostante (es. guardrail) per la prevenzione e rilevazione d incidenti. Offerta di nuovi modelli assicurativi e/o d informazioni geo-referenziate su viabilità e situazione del traffico. E-Health: monitoraggio in real time di parametri vitali da remoto, riducendo il ricorso all'ospedalizzazione, a fini diagnostici e di cura di persone anziane oppure malati cronici. Può anche servire per la localizzazione di pazienti (es. malati di Alzheimer). 26 Beneficiario COLFUTURO 2010

32 Analizzati i campi di applicazione, si procede ora ad analizzare i problemi relativi a protezione della sicurezza e della privacy, aspetto molto importante, per permettere la diffusione del paradigma dell Internet of Things. 1.6 Privacy e sicurezza Il problema della privacy nell'ampio mondo dell'internet of Things non è focalizzato solo nel farla rispettare durante l'elaborazione, memorizzazione e trasmissione delle informazioni, ma anche nel proteggerla da malintenzionati, che possono cercare di intercettare le comunicazioni illecitamente. In questo contesto, la sicurezza è messa a dura prova dal fatto che la maggioranza delle tecnologie d interesse, lavorano tramite comunicazioni in chiaro e in reti pubbliche, e quindi, di facile intercettazione. [13] Inoltre da notare, che alcune delle possibili soluzioni per aumentare il livello di sicurezza, presentano, in questo contesto, alcuni svantaggi. Ad esempio: L'autenticazione del lettore dal sensore e viceversa, comporterebbe un notevole aumento dei costi per tag che fanno del basso costo l'arma vincente per il loro sviluppo. La criptazione dei dati, causerebbe una drastica diminuzione delle informazioni che il tag potrebbe inviare. Per questo, si può concludere che sono necessarie nuove soluzioni adattate al nuovo contesto tecnologico che viene a crearsi nel campo dell'iot, soluzioni che permetteranno di trovare il giusto compromesso tra efficienza e sicurezza rispettando anche la privacy. Dopo aver parlato dell'ecosistema dell Internet of Things, si prosegue con la spiegazione del concetto di middleware e come viene utilizzato nell ambito dell IoT. 1.7 IoT middleware L origine del concetto di middleware data da 1968 ma negli anni 80 cominciò ad avere successo perché rappresentava la soluzione per far funzionare programmi nuovi su sistemi di vecchia generazione e facilitava il calcolo distribuito. 27 Beneficiario COLFUTURO 2010

33 IBM, Red Hat e Oracle sono le società maggiormente coinvolte nello sviluppo di middleware. A queste si affiancano Axway, SAP, TIBCO per Middleware Web Oriented e gruppi come Apache Software Foundation, OpenSAF e ObjectWeb Consortium per soluzioni open source. Si tratta di un importante componente architetturale per il supporto delle applicazioni distribuite, il ruolo del middleware è quello di presentare un modello di programmazione unificato per i programmatori e di mascherare i problemi di eterogeneità e di distribuzione. Ciò permette ai vari oggetti usati nell'internet of Things e alle diverse entità comunicanti all interno di una rete, di connettere gli apparati di front-end (tag, reader, sensori) con gli apparati di back-end (ERP, Database, Management Applications). I middleware hanno innumerevoli applicazioni. Nell ambito dei database, consentono di risolvere i problemi d interoperabilità fra diverse strutture di database e facilitano un accesso trasparente ai DBMS o ad altre applicazioni attraverso web server. Nell ambito della sanità, i laboratori fanno un largo uso di applicazioni middleware per il data mining, il backup del LIS (Laboratory Information System) e per combinare fra loro sistemi di ospedali diversi. Nel campo delle WSN, un middleware permette agli sviluppatori di integrare sistemi operativi e hardware diversi, con la grande varietà di applicativi disponibili. Per quanto riguarda l e-commerce, i middleware agevolano l esecuzione di transazioni rapide e sicure, fra elaboratori architetturalmente diversi. Per gli sviluppatori, l utilizzo di un middleware rappresenta un livello di astrazione che si trasforma in un unica interfaccia con cui interagire, senza la necessità di dover scrivere API diverse, per ogni specifico programma utilizzatore. Come si può facilmente notare, i middleware sono diventati elementi fondamentali, in una vasta gamma di settori, grazie alla capacità di unire risorse, che risiedono su reti e piattaforme diverse. La disponibilità di uno strato middleware, che nasconda i dettagli legati alle diverse tecnologie abilitanti, è fondamentale per liberare lo sviluppatore di applicazioni per Internet of Things da dettagli che non sono direttamente pertinenti alla propria attività. L'internet of Things può trarre molti benefici dall esistenza di un tale middleware, grazie al quale i nuovi servizi saranno sviluppati più facilmente e l'interazione con gli oggetti sarà più avanzata. 28 Beneficiario COLFUTURO 2010

34 Come dice il nome, il middleware si trova "In the middle" (figura 9), cioè tra le applicazioni ed il sistema operativo, inoltre ai giorni nostri, possiamo trovare middleware già integrati nei sistemi operativi moderni. I middleware vengono realizzati con un architettura di tipo modulare, intendendo per moduli dei componenti software, in grado di svolgere specifiche funzionalità. Figura 9: Ruolo del middleware Un middleware viene usato perché permette di avere: Portabilità: infatti, offre un comune modello di programmazione indipendentemente dal linguaggio e/o dall'architettura. Affidabilità: i middleware sono testati indipendentemente. Permette di astrarre dagli aspetti di basso di livello e di utilizzare librerie testate. E gestione della complessità: gli aspetti di basso livello sono gestiti da apposite librerie/driver. Si riduce la probabilità d'errore e si diminuiscono i tempi di sviluppo. Un middleware può fornire servizi per differenti classi di applicazioni (database distribuiti, servizi di mobile computing, multimedia). Permette lo scambio di informazioni facilitando la gestisce e le comunicazioni di rete. Infine, si occupa di trovare risorse distribuite, gestire la sicurezza delle trasmissioni, gestire le eccezioni e valutare le performance. Lo sviluppo di soluzioni middleware nel dominio dell'internet of Things è un'area attiva di ricerca; ci sono molte ricerche che puntano allo sviluppo di middleware per indirizzare l'interoperabilità tra dispositivi 29 Beneficiario COLFUTURO 2010

35 eterogenei, che servono in diversi campi di applicazioni. Pertanto, c è una forte necessità di capire come i sistemi middleware esistenti per Internet of Things funzionano e rispondono alle diverse esigenze di ubiquità e soprattutto ai problemi e lacune esistenti. [14]. Per la progettazione di una soluzione di middleware per l'iot si devono soddisfare caratteristiche di context awareness (capacità di percepire e reagire a dei cambiamenti nell'ambiente), capacità di adattamento e modularità. Infatti, non si può costruire una soluzione di questo tipo legandosi troppo strettamente ad una certa piattaforma o ad un certo tipo di utilizzo. Il middleware deve essere in grado di adattarsi a funzionare in diversi ambienti (con difformità nelle piattaforme hardware, software, nella disponibilità di risorse, ecc.) ed essere funzionale a diversi scopi. Inoltre, deve essere possibile modificare le funzionalità della soluzione a run-time, aggiungendo o rimuovendo moduli, senza la necessità di riavviare l intera applicazione, questo permette al middleware essere visto come un componente pratico, semplice e facile da utilizzare Aspetti caratterizzanti di un IoT middleware Un middleware fornisce un astrazione di programmazione distribuita e un modello computazionale uniforme per mascherare le eterogeneità delle reti, hardware, sistemi operativi e linguaggi di programmazione, garantendo trasparenza, astrazione e semplicità, ma per fare ciò sono necessari requisiti fondamentali senza i quali non si potrebbe permettere il corretto funzionamento del middleware stesso. Bisogna considerare i seguenti aspetti: Carico computazionale. Differentemente da un sistema distribuito tradizionale, dove si hanno a disposizione processori veloci, molta memoria, alimentazione continua ecc. In uno scenario IoT, bisogna rapportarsi alle risorse limitate dei dispositivi, e garantire comunque un alta qualità del servizio; tanto più alta si richiede la qualità del servizio, tanto più complesso sarà il middleware in esecuzione sotto le applicazioni. Paradigma di comunicazione. I paradigmi generalmente usati sono di due tipi: sincrono, in cui entrambi i soggetti della comunicazione sono contemporaneamente presenti durante un interazione, e asincrono in cui non è necessario che i due soggetti siano presenti allo stesso tempo. L approccio sincrono è indicato laddove non si hanno problemi 30 Beneficiario COLFUTURO 2010

36 di risorse energetiche o di rete, per cui i due soggetti, client e server, possono restare sempre connessi al middleware, in attesa di messaggi o invocazioni. Rappresentazione del contesto. Le applicazioni in esecuzione in un sistema permettono la raccolta di numerose informazioni sul contesto, come la larghezza di banda, i servizi disponibili, la latenza ecc. I middleware che raccolgono tali informazioni possono trattarle con due approcci differenti che sono Trasparency e Awareness; il primo metodo tiene nascoste tutte le informazioni che si riferiscono al contesto all interno del middleware e le rende trasparenti alle applicazioni; il secondo approccio, invece, rende direttamente disponibili alle applicazioni le informazioni del contesto di esecuzione, permettendo quindi alle applicazioni stesse di poter prendere decisioni durante l esecuzione. Generalmente i middleware attivi su sistemi distribuiti statici preferiscono un approccio trasparente, in vista alla grande possibilità di risorse, consentendo di tenere bassa la complessità delle applicazioni che li utilizzano.[15] [16]. Una importante caratteristica offerta dai middleware è quella della context-awareness, nel seguente paragrafo viene approfondito questo concetto Context-awareness La possibilità offerta dai middleware context-aware di trasportare fino al livello delle applicazioni i dati di contesto non rappresenta solo un opportunità per ottimizzare il comportamento delle applicazioni, ma fornisce anche la possibilità di sfruttare questi dati per supportare le funzionalità delle applicazioni che trovano vita in sistemi mobili. In questo caso il contesto può assumere significati molto ampi. Gli autori della definizione di contesto, individuano quattro elementi del contesto che possono essere considerati più importanti degli altri e sono detti primari per la capacità che hanno di caratterizzare la situazione di una particolare entità, questi sono: posizione, identità, attività e tempo. Queste informazioni possono essere usate come indici in altre fonti d informazioni di contesto; ad esempio, data l'identità di una persona, è possibile acquisire informazioni correlate come i numeri di telefono, indirizzi, indirizzi , data di nascita, la lista di amici, relazioni con altre persone nell'ambiente, ecc. Data la posizione di un entità, è possibile determinare quali altri oggetti o persone sono vicino all'entità e quali attività sono in corso nelle sue 31 Beneficiario COLFUTURO 2010

37 vicinanze. Da questi esempi è evidente che gli elementi di contesto primari per un entità possono essere usati come indici per trovare elementi secondari, per quella stessa entità, così come elementi primari di altre entità correlate. Gli elementi secondari condividono, quindi, la caratteristica di poter essere indicizzati da uno o più degli elementi primari; ad esempio il numero di telefono di un utente può essere ottenuto utilizzando la sua identità come indice in un servizio di elenco telefonico, oppure le condizioni meteorologiche possono essere individuate tramite un apposito servizio, a partire dalla data della previsione desiderata e dalla posizione. Insomma un sistema è detto context-aware se utilizza il contesto per fornire informazioni e/o servizi rilevanti all utente, dove la rilevanza dipende da cosa l utente stia facendo. Questa definizione è più generale di altre presenti in letteratura, in quanto non richiede che il comportamento dell applicazione cambi per essere considerata context-aware. Infatti, un applicazione che visualizza semplicemente informazioni sul contesto dell'ambiente dell'utente non sta modificando il suo comportamento, ma è context-aware. Schilit e altri propongono una tassonomia delle applicazioni context-aware su due dimensioni relative al task da eseguire: la prima è relativa all obiettivo del task, che può voler ottenere informazioni o eseguire un comando, la seconda è relativa al modo in cui è effettuato, cioè manualmente o automaticamente. Applicazioni che recuperano informazioni sul contesto intorno all utente, su richiesta dell'utente stesso, sono classificate come applicazioni proximate-selection. Si tratta di una tecnica d interazione in cui viene presentato un elenco di oggetti o luoghi, generalmente corredati da loro caratteristiche, che possono essere d interesse per l utente che lo visualizza. Ad esempio, la lista delle stampanti in un edificio ordinate per distanza dalla posizione attuale o per lunghezza della coda di stampa. È chiaro quindi che l approccio context-aware può riferirsi anche alla semplice consultazione delle informazioni di contesto, senza che chi ne fa uso modifichi i propri comportamenti o schemi. Descritto il concetto di middleware e le sue principali caratteristiche, nel seguente capitolo verranno dettagliati i diversi tipi di middleware esistenti e come si differenziano. 32 Beneficiario COLFUTURO 2010

38 PARTE 2 MIDDLEWARE 33 Beneficiario COLFUTURO 2010

39 34 Beneficiario COLFUTURO 2010

40 CAPITOLO 2: State-of the-art dei Middleware 2.1 Classificazione dei Middleware Judith Hurwitz, presidente e CEO di Hurwitz Group Inc, nel 1998 ha classificato i tipi di middleware in diverse categorie, basandosi su due criteri molto importanti per gli sviluppatori: Scalabilità (la capacità del sistema di continuare a funzionare correttamente all aumento del carico, con un minimo aumento delle risorse richieste) e ripristinabilità (possibilità di tornare ad una situazione stabile, in caso di errore). Queste due caratteristiche sono, naturalmente, in relazione: più si utilizzano tecniche necessarie per la ripristinabilità (journaling, handshaking ed altre), meno la soluzione può scalare, al contrario più la soluzione è scalabile, meno sarà possibile ripristinare il middleware in caso di errore. Alcuni esempi di (famiglie di) prodotti commerciali di middleware sono: RPC, Java RMI, Messaging, SQL Stored Procedures, ORB, TP monitor, web services. Nei prossimi paragrafi si entrerà nel dettaglio delle varie tipologie, descrivendone definizione di concetti, architettura, e analizzando le diverse caratteristiche dei middleware già esistenti. A oggi però le categorie definite non sono più così distinte l una dall altra. Ad esempio, molti tipi di middleware, come quelli SQLoriented, stanno aggiungendo la gestione degli oggetti. Sono disponibili ORB che hanno servizi per le transazioni, l accodamento, e la gestione dei messaggi. I middleware MOM e quelli Publish-and- Subscribe aggiungono il supporto per transazioni e la gestione degli oggetti e stanno assumendo una posizione privilegiata rispetto agli altri. Un esempio è Tuxedo, che come vedremo nel dettaglio, è nato come RPC sincrono ma ora gestisce sia Publish/Subscribe sia messaggi. Allo stesso tempo stanno sorgendo nuovi tipi di middleware, ma i criteri di scalabilità, ripristinabilità, e le tipologie di comunicazioni sincrone o asincrone, restano comunque validi per la scelta di un middleware per una specifica applicazione. 35 Beneficiario COLFUTURO 2010

41 2.1.1 Remote Procedure Call (RPC) Middleware I sistemi di questo tipo sono adatti a qualsiasi piattaforma hardware e software, infatti praticamente ogni casa di produzione supporta RPC. Le comunicazioni avvengono attraverso il seguente meccanismo (mostrato anche in figura 10): 1. Il client chiama una procedura, come fosse una normale chiamata in locale. 2. Questa chiamata, in realtà, si traduce in un messaggio inviato al server. 3. Il server riceve la chiamata con i parametri, la esegue e restituisce il risultato, attraverso un altro messaggio. 4. A seconda che si usino RPC sincrone o asincrone, dopo aver chiamato la procedura il client può aspettare la risposta (modalità sincrona) oppure continuare a svolgere altre operazioni, mentre il server elabora la risposta (modalità asincrona). Con RPC (Remote Procedure Call) si intende un sistema di interprocess communication, che permette ad un programma di eseguire una procedura in uno spazio di indirizzamento diverso dal proprio (comunemente un altro computer o una rete condivisa), senza che il programmatore debba scrivere esplicitamente il codice per questa interazione remota. Infatti, il codice può essere scritto come se la procedura fosse locale. Figura 10: Meccanismo di Remote Procedure Call 36 Beneficiario COLFUTURO 2010

42 Le RPC funzionano con il paradigma Client-Server: il client avvia il processo, richiedendo al server di eseguire una certa funzione o procedura ed aspetta in risposta il risultato da parte dal server. Ci sono diversi tipi di RPC, molti di loro standardizzati, come ad esempio il RPC di Sun chiamato ONC RPC (RFC 1057), il RPC di OSF denominato DCE/RPC e il modello di oggetti di componenti distribuiti di Microsoft DCOM, anche se nessuno di questi sono coerenti tra di loro. La maggior parte usano un linguaggio di descrizione di interfaccia (IDL), che definisce i metodi esportati dal server. Anche se l'obiettivo di RPC può essere definito come quello di fornire un meccanismo di chiamata di procedura remota la cui semantica sia essenzialmente equivalente a quella della chiamata di procedura locale (da cui la suddetta trasparenza del meccanismo), tale equivalenza non è mai compiutamente realizzata, a causa delle difficoltà che possono insorgere nella comunicazione su rete (sempre soggetta a fallimento). Non essendovi un unico modo ovviamente "giusto" per gestire queste complicazioni, i meccanismi di RPC possono differire in modo sottile, per quanto concerne la semantica esatta della chiamata remota Semantiche Alcuni meccanismi, per esempio, hanno una semantica "at most once" (semantica "al massimo una volta"): in altre parole, una chiamata di procedura remota può non venire eseguita, ma è garantito che non possa risultare in molteplici attivazioni della subroutine richiamata. L'approccio opposto è rappresentato dalla semantica "at least once", che garantisce che la subroutine venga richiamata almeno una volta (potrebbe, quindi, accadere che essa sia attivata più volte). La semantica ideale è la "exactly once" (semantica "esattamente una volta"), che coincide con la semantica tradizionale della chiamata a procedura. Nel caso di procedure idempotenti (cioè per le quali una singola attivazione e molteplici attivazioni sono funzionalmente equivalenti), la semantica "at least once" coincide con quella "exactly once". Altre differenze semantiche fra l'rpc e la chiamata di procedura tradizionale riguardano l'evidente impossibilità, per la procedura 37 Beneficiario COLFUTURO 2010

43 richiamata, di produrre effetti collaterali nell'ambiente del chiamante. Anche alcune forme di passaggio parametri, come il passaggio parametri per indirizzo, non sono direttamente applicabili all'rpc, ma possono essere sostituite da concetti semanticamente molto vicini. [17] Comunicazione Sincrona vs Asincrona È fondamentale anche considerare il tipo di comunicazione, che può essere sincrona o asincrona. Nei sistemi sincroni, chi effettua una richiesta aspetta la risposta prima di eseguire altre operazioni. Invece, i sistemi asincroni fanno richieste senza aspettare le risposte (che vengono restituite non necessariamente rispettando l ordine delle richieste). I middleware sincroni, a volte usati nei sistemi di produzione, non scalano molto bene, però sono facilmente ripristinabili. Quelli asincroni, sono molto scalabili, ma non sono ripristinabili facilmente. Sfruttando questi due criteri appena descritti, è possibile classificare i middleware RPC in una scala, che va dal sistema RPC asincrono (il più scalabile e meno ripristinabile) al RPC sincrono (il più ripristinabile ma meno scalabile). Resta comunque valido il fatto che è possibile far scalare i sistemi aumentando il numero di server a seconda del carico RPC Sincrona L RPC sincrono è una soluzione per lo scambio di informazioni che permette a programmi distribuiti di chiamare servizi resi disponibili da vari dispositivi in rete. Scrivere RPC non è semplice, ma i middleware forniscono interfacce di alto livello che nascondono gran parte dei problemi tecnici RPC asincrona La soluzione RPC asincrona permette ai client di richiedere servizi senza aspettarne la risposta. Tipicamente, un client deve conoscere l indirizzo di rete del server e stabilire una connessione punto-punto con esso. Il client a questo punto può richiedere informazioni al 38 Beneficiario COLFUTURO 2010

44 server e, contemporaneamente, eseguire altre operazioni. Nel caso in cui la connessione cadesse, il client sarebbe costretto a rifare tutto dall inizio Soluzioni attuali Esistono molte soluzioni disponibili in commercio per il controllo e l amministrazione di chiamate RPC, che permettono facilmente di effettuare operazioni di bilanciamento del carico sul sistema. Le chiamate RPC non supportano il filtraggio dei messaggi, ma supportano le transazioni molto facilmente, infatti un sottoinsieme di questo tipo di middleware è formato dai cosiddetti middleware transazionali o TPM (Transactions Processing Monitors). Per transazioni, si intendendo delle unità di lavoro atomiche, che permettono ad un server o ad un client di trovarsi sempre in uno stato stabile, una volta fatto il commit. Le transazioni richiedono scalabilità, per questo il ruolo importante dei TPM è di gestire un grande numero di RPC transazionali, in maniera robusta ed economica. I programmi che gestiscono transazioni devono avere caratteristiche di portabilità, scalabilità e interoperabilità, poiché rappresentano essi stessi una piattaforma per altri programmi. In realtà, oggi, il ruolo dei TPM è stato soppiantato da un modello di programmazione basato su Java ed Enterprise Java Beans. Di seguito alcuni esempi di middleware basati su RPC non transazionali. NobleNet RPC: utilizza RPC asincrone. A metà degli anni 90 si trattava del più avanzato e testato middleware basato su RPC. Alla fine del 1996 uscì la versione 3.0, che integrava importanti feature come sicurezza, bilanciamento del carico, operazioni asincrone, multithreading, e gestione del server. Permetteva di abbassare il tempo di sviluppo di applicazioni distribuite, generando automaticamente il codice client/server, per tutte le strutture dati e le API dei programmi, permettendo agli sviluppatori di distribuire facilmente le proprie applicazioni client/server sia all interno di intranet, che in internet. JaRPC (NC Laboratories): fornisce gli strumenti necessari per sviluppare client e server rpc in Java. 39 Beneficiario COLFUTURO 2010

45 PowerRPC (Netbula): consiste in un compilatore RPC, più molte funzioni di libreria. Permette a programmatori C/C++ di creare potenti client/server compatibili con RPC e altre applicazioni distribuite senza scrivere codice di rete. NXTWare TX (ecube System): si tratta del primo prodotto commerciale, disponibile per permettere alle applicazioni basate su RPC di partecipare ad una SOA. Anche se ora le compagnie possono utilizzare J2EE, CORBA e SOAP per accedere ai dati in sicurezza ed eseguire transazioni dalle applicazioni, con questo prodotto, possono sfruttare gli investimenti già fatti in applicazioni Entera, DCE e RPC. Di seguito alcuni esempi delle principali soluzioni basate su RPC transazionali: IBM CICS (Costumer Information Control System): E uno dei primi TPM realizzati, scritto in Assembler, fungeva solo da controllore del terminale con qualche capacità di gestione del database. Successivamente ci sono state molte versioni che l hanno trasformato in un TPM. Nel 1979 si è deciso di svilupparne una nuova versione scritta in linguaggio ad alto livello. Questo lavoro fu finito solamente alla fine degli anni 80. Nei primi anni 90 le API CICS sono state estese alle piattaforme AS400 e OS/2. Oggi Il 90% delle compagnie comprese nella classifica Fortune 500 si basano su questo sistema (usando z/os) per le funzionalità di core business. CICS è usato da molte applicazioni bancarie, dai sistemi ATM (tipo bancomat), da sistemi industriali di controllo della produzione, applicazioni assicurative e molti altri tipi di applicazioni interattive. I sistemi CICS sono essenzialmente sistemi client - server (Application Server o AS), con i server raggruppati in domini noti come Regioni, che supportano un numero di programmi, noti come Transaction Programs (o semplicemente transazioni). Dalle prime versioni CICS si è sempre più evoluto durante gli anni, le ultime versioni comprendono: Il supporto per EJB (Enterprise Java Beans) e per Web Sphere. La possibilità di chiamare transazioni attraverso http, in questo modo le transazioni CICS possono fare da server per conversazioni REST (Representational State Transfer) e POX (Plain Old XML). 40 Beneficiario COLFUTURO 2010

46 La possibilità di invocare servizi CICS attraverso Java (oltre alla possibilità di debuggare facilmente le applicazioni CICS da client Java). Il supporto ai Web Services, che permette ai programmi CICS di essere sia fornitori, sia richiedenti di Web Services. BEA Tuxedo: si tratta di un middleware usato per gestire il calcolo di transazioni distribuite ed è sviluppato per C, C++ e COBOL. Tuxedo è stato, inizialmente, pensato per gestire applicazioni molto scalabili, supportando migliaia di transazioni al secondo su sistemi distribuiti, ora supporta il trasporto di diversi tipi di dati ed è in grado di gestire transazioni e web services. Implementa diverse feature per la sicurezza come autenticazione, autorizzazione e crittazione e gestisce il bilanciamento del traffico. Alla base del sistema c è un meccanismo di routing e accodamento dei messaggi. Le richieste sono inviate a un determinato servizio e Tuxedo usa strutture di IPC (Inter-Process Communication) in memoria per accodare le richieste ai server. Il cuore del sistema Tuxedo è il BB (Bulletin Board), un segmento di memoria condivisa che contiene lo stato di un dominio Tuxedo. Server, servizi, transazioni e client sono tutti registrati nel BB che fornisce una vista globale del loro stato. Oltre al BB è fondamentale anche il Bridge, responsabile di passare le richieste da una macchina all altra. Per i client remoti Tuxedo fornisce dei concentratori di comunicazioni chiamati listeners/handlers, ai quali i client si connettono e che agiscono come proxy. Per facilitare la condivisione di servizi fra domini diversi, Tuxedo fornisce dei gateway, che hanno lo scopo di permettere di importare ed esportare servizi da un dominio remoto. Tuxedo fornisce anche un sistema di code chiamato /Q. Queste code possono essere di diverso tipo: LIFO, FIFO, priority e altre. Esiste un server di forwarding della coda, che rimuove le richieste dalla coda e invoca i servizi Tuxedo associati. Il sistema di eventi all interno di Tuxedo supporta sia eventi non sollecitati, sia eventi gestiti. Quelli non sollecitati permettono alle applicazioni Tuxedo di inviare delle notifiche ai client, che non necessariamente le stanno aspettando. Gli eventi gestiti, permettono alle applicazioni di iscriversi a eventi di proprio interesse e ricevere le notifiche quando altre applicazioni pubblicano eventi di quel tipo. Questo permette alle applicazioni di usare un modello event-driven rispetto al solito Client- Server. 41 Beneficiario COLFUTURO 2010

47 NCR Top End: è stato rilasciato la prima volta nel Negli anni successivi, il successo di Top End aumentò soprattutto nel campo del Data Warehousing. Nel 1999 BEA mise in commercio un gateway per permettere agli utenti di Top End di migrare a Tuxedo, e da allora il progetto Top End si può considerare finito. Encina: si tratta di un sistema TPM sperimentale, sponsorizzato da IBM. Originariamente conosciuto come Camelot, aveva un proprio linguaggio di programmazione, object oriented, che conteneva concetti di persistenza. Nel 1991 il progetto divenne commerciale e sviluppato sulla piattaforma DCE, tecnologia alla base di diversi sistemi transazionali. In seguito fu acquisita da IBM che la chiuse, fondendo il progetto nel proprio TXSeries. MTS - Microsoft Transaction Server: si tratta del programma con cui inizialmente venivano offerti i servizi ai componenti software COM (Component Object Model), per rendere più semplice sviluppare grandi applicazioni distribuite. I servizi più importanti erano quelli di gestione delle transazioni, gestione delle istanze e sicurezza. In Windows 2000, fu integrato in modo migliore e rinominato in COM+, che aggiungeva delle funzionalità a quelle originali. COM+ è stato ancora inserito in Windows Server 2003 e Windows Server 2008 e, attraverso WCF (Windows Communication Foundation), è possibile chiamare le applicazioni COM+ attraverso web services. Un architettura base MTS comprende il programma MTS (mtxex.dll), i Wrapper per ogni componente, i componenti Server MTS, i client MTS ed alcuni sistemi ausiliari come COM, SCM (Service Control Management), MSMQ (Microsoft Message Queue) Object-based Middleware Uno dei modelli più popolari è il middleware basato su oggetti, in cui le applicazioni sono strutturate in oggetti che interagiscono attraverso la invocazione trasparente di metodi. Utilizza comunicazione sincrone con la semantica at-most-once ed è facile da integrare con middleware orientati ai messaggi. 42 Beneficiario COLFUTURO 2010

48 Object Request Broker Middleware L ORB (Object Request Broker) è un bus software (Open Software Bus), o un canale di comunicazione, dove il collegamento tra ORB sulla rete avviene tramite i protocolli GIOP e IIOP (figura 11), che implementano il marshalling, unmarshalling e la rappresentazione esterna dei dati; supportano la trasparenza di locazione, così da nascondere al client tutti i dettagli sulla localizzazione degli oggetti sulla rete e sul loro linguaggio d implementazione; infine, supportano la trasparenza di comunicazione, così da mascherare le chiamate remote come semplici invocazioni locali. Figura 11: Un Request è inviato attraverso l'object Request Broker. Gli Object Request Broker rappresentano una soluzione che permette alle applicazioni di inviare oggetti e richiedere servizi in un sistema orientato agli oggetti. Questi tengono traccia delle informazioni e degli indirizzi attuali di tutti gli oggetti del sistema e sono in grado di instradare le richieste nel formato giusto per ogni specifico oggetto. Inoltre, permettono agli sviluppatori di un applicazione, composta da molti oggetti, di dividerli facilmente su diversi nodi di rete. Questo semplifica il lavoro degli sviluppatori che usano linguaggi objectoriented, poiché evita di creare un collegamento tra gli oggetti e le loro funzioni. [18] Il mondo ORB ha molti standard, tra cui CORBA (Common Object Request Brocker Architecture) dell Object Management Group, OLE della Microsoft e OpenDoc. 43 Beneficiario COLFUTURO 2010

49 Common Object Request Broker Architecture (CORBA) CORBA è uno standard proposto da OMG. I suoi obiettivi sono di contribuire a abbassare la complessità, ridurre i costi e accelerare l'introduzione di nuove applicazioni informatiche; promuovere la teoria e la pratica della tecnologia orientata agli oggetti in sistemi distribuiti, e nascondere la programmazione a basso livello; permette la comunicazione fra componenti, indipendentemente dalla loro distribuzione sui diversi nodi della rete o dal linguaggio di programmazione con cui siano stati sviluppati. I vari componenti comunicano attraverso un "broker" (figura 12). I componenti sono "presentati" al broker attraverso la scrittura di un'interfaccia nel linguaggio IDL. Figura 12: ORB visto come il cuore di CORBA CORBA specifica poi una mappatura da IDL a specifici linguaggi di implementazione come C++ o Java. Mappature standard esistono inoltre per Ada, C, C++, Lisp, Smalltalk, Java, COBOL, PL/I epython. Esistono anche mappature non standard per Perl, Visual Basic, Ruby, Erlang, e Tcl, implementati mediante ORB scritti per questi linguaggi. La specifica CORBA prevede che l'applicazione inizializzi l'orb e acceda ad un Object Adapter interno che ha compiti come il conteggio dei riferimenti, la politica di istanziazione di oggetti e riferimenti, le politiche sul tempo di vita degli oggetti e così via. L'Object Adapter è usato per registrare istanze delle classi generate. Le classi generate sono il risultato della compilazione del codice IDL, che traduce la definizione ad alto livello dell'interfaccia in una classe dipendente da un sistema operativo e da un linguaggio, che verrà 44 Beneficiario COLFUTURO 2010

50 usata dall'applicazione utente. Questo passo è necessario al fine di garantire la semantica definita da CORBA e di fornire un processo preciso per interfacciarsi con l'infrastruttura CORBA. Alcune mappature da IDL a specifici linguaggi di programmazione sono più ostili di altre. Ad esempio, data la natura di Java, la mappatura IDL-Java è relativamente semplice e rende l'uso di CORBA molto semplice in un'applicazione Java. La mappatura verso C++ non è banale, ma rende disponibili tutte le caratteristiche dell'infrastruttura CORBA, come la gestione delle eccezioni. La mappatura verso C è ancora più ostica (dato che non è un linguaggio Object Oriented) ma è costruita in modo sensato e rende bene la semantica delle chiamate RPC. (Red Hat Linux viene distribuito con il sistema GNOME UI, il cui IPC era basato su CORBA, ora rimpiazzato da D-Bus). [19] Nei seguenti paragrafi vengono brevemente descritti i protocolli utilizzati da CORBA per la comunicazione fra oggetti General Inter-ORB Protocol (GIOP) E un protocollo astratto che specifica: un insieme di tipi di messaggi utilizzabili tra un client e un server, una sintassi standard nel trasferimento dati delle interfacce IDL, un formato standard per ogni messaggio utilizzabile. In GIOP sono definiti otto tipi di messaggi (Request, CancelRequest, LocateRequest, Reply, LocateReply, CloseConnection, MessageError, Fragment. GIOP richiede un sistema di trasporto con connessione (es: TCP/IP) Internet Inter-ORB Protocol (IIOP) E il mapping specifico di GIOP sul protocollo TCP/IP, inoltre i messaggi IIOP contengono inoltre informazioni di servizio. IIOP è utilizzato in altri sistemi che non forniscono l'api CORBA (per esempio, RMI su IIOP, EJB, ecc.) Poiché,molti sistemi usano IIOP, i programmi scritti per queste API possono interagire tra di loro e con i programmi di CORBA. 45 Beneficiario COLFUTURO 2010

51 Soluzioni attuali I principali middleware basati su Object Request Broker sono: Borland VisiBroker: si tratta dell infrastruttura CORBA più utilizzata presente sul mercato, con oltre 30 milioni di licenze in uso. E un ambiente robusto, ideale per sviluppare e rendere disponibili applicazioni distribuite. Rispetta la specifica CORBA 3.3 e supporta lo sviluppo in Java, C++ e linguaggi.net. Borland VisiBroker: offre una gestione sofisticata dei thread e della connessione, oltre a naming e clustering. Aumenta l interoperabilità delle applicazioni CORBA con applicazioni che usano altre tecnologie, attraverso una Service Oriented Architecture. Supporta la specifica Real-Time CORBA per applicazioni distribuite in una grande varietà di dispositivi. Il sistema si compone di tre servizi: Borland VisiNotify, che assicura la notifica di eventi in modo altamente efficiente, oltre a garantire il mantenimento del valore delle notifiche in una memoria persistente e su cui si possono effettuare ricerche. Borland VisiSecure, il quale assicura che i dati critici e i servizi non siano esposti ad un uso inappropriato o non previsto. Borland VisiTransact garantisce il supporto alle transazioni, mantenendo la consistenza e l integrità dei dati critici. BEA ObjectBroker: si tratta dell'orb basato su CORBA leader del mercato per il supporto di applicazioni ad oggetti distribuite. BEA ObjectBroker semplifica la creazione di soluzioni distribuite basate su oggetti, attraverso l'integrazione di applicazioni già esistenti e lo sviluppo di nuove applicazioni. Con ObjectBroker, gli sviluppatori possono sviluppare, gestire e rendere disponibili applicazioni a oggetti, completamente indipendenti dall'hardware e dall'ambiente del sistema operativo. Le feature fornite da ObjectBroker sono: API ad alto livello e basate su standard, per tutte le piattaforme supportate. 46 Beneficiario COLFUTURO 2010

52 Binding con C e C++, per fornire ai programmatori una interfaccia che rispetti le specifiche CORBA Versione 2.0. Tracciamento e logging degli eventi per il debug delle applicazioni sia lato client che server. Script server, che permettono l'accesso alle applicazioni usando interfacce da linea di comando, senza la necessità di modifiche nel codice. QuickStart, che rende più semplice agli utenti l'installazione ed il lancio di applicazioni, e rende più produttivi gli utenti esperti. Server Management API, che permettono ai gestori del sistema di controllare i server attraverso API. Supporto per UDT (User Defined Types). Supporto per funzioni DII (Dynamic Invocation Interface). Dome (Object Oriented Technologies, Ltd.): Distributed Object Management Enviroment è un toolkit C++ ad alte prestazioni per l'implementazione di sistemi distribuiti usando l'architettura CORBA per ORB. e*orb (PrizmTech): si tratta del più piccolo e veloce ORB sul mercato. La sua architettura, che si basa su 10 anni di applicazioni di successo, permette agli ingegneri di sistemi embedded di costruire prodotti solidi, con comportamenti predicibili. Con le alte prestazioni raggiungibili e la sua grande efficienza, e*orb è adatto per ogni sistema che abbia grandi richieste di prestazioni. Le estensioni per la tolleranza agli errori e il real-time permettono all'utente di selezionare il livello di disponibilità e predicibilità dei servizi. Elektra Object Request Broker (Softwired): è un ORB che rispetta le specifiche CORBA V2, supportando l'implementazione di applicazioni distribuite affidabili. Un applicazione si dice affidabile se il suo comportamento è predicibile nonostante errori parziali, e cambiamenti nel sistema. MICO (Johann Wolfgang Goethe Univeristaet Frankfurt am Main): l'acronimo sta per MICO Is CORBA. L'intenzione del progetto è fornire un implementazione dello standard CORBA 2.2 completa e assolutamente libera. MICO è diventato abbastanza popolare come progetto open source ed è ampiamente utilizzato. 47 Beneficiario COLFUTURO 2010

53 ORBacus (Object Oriented Concepts): precedentemente conosciuto come OminBroker, si tratta di un ORB robusto e provvisto di molte feature. Gratis per scopi non commerciali, con supporto completo per multithreading, rispetta le specifiche CORBA, è la soluzione più portabile presente sul mercato, fornisce un'architettura open e il completo codice sorgente. Vojager (ObjectSpace): è un ORB Java che permette agli sviluppatori Java di creare sofisticate applicazioni di rete usando sia le tecniche di programmazione distribuita tradizionali, che quelle ad agenti Publish And Suscribe Middleware I sistemi middleware come CORBA o RMI (Remote Method Invocation) Java hanno dimostrato di dare una astrazione utile per la creazione di applicazioni distribuite complesse. Essi forniscono un'interfaccia comune di più alto livello per il programmatore di applicazioni, e nascondono la complessità di trattare con una varietà di piattaforme e reti sottostanti. Oggi, la maggior parte dei sistemi middleware sono invocation-based e quindi seguono un paradigma request/reply, questo significa che un client richiede un servizio particolare da un server mandando sia un messaggio request o l'esecuzione di una e poi riceve a cambio una risposta in dietro. Anche se una tale modalità di funzionamento funziona bene in un contesto di rete locale, con un moderato numero di client e server, non è garantito che possa scalare in una grande reti come Internet. Il paradigma request/reply consente solo un modello di una relazione uno-a-uno e costringe un accoppiamento stretto tra le parti coinvolte. Tale comportamento non è desiderabile in Internet, a causa del gran numero di potenziali partner di comunicazione, e la natura dinamica di tutte le interazioni con i nuovi clienti. [20] Un approccio diverso per i sistemi di comunicazione distribuita su larga scala è quello dei sistemi basati su eventi, quelli che utilizzano il paradigma publish/subscribe. In un tale sistema, gli eventi sono il meccanismo di comunicazione di base: in primo luogo, i consumatori esprimono il loro interesse a ricevere determinati eventi, sotto forma di una sottoscrizione di eventi (subscribe). Poi, i produttori di eventi pubblicano eventi (publish), che saranno consegnati a tutti gli iscritti interessati. 48 Beneficiario COLFUTURO 2010

54 Nel modello pub/sub, i subscriber ricevono solo un sottoinsieme di tutti i messaggi pubblicati. Il processo di selezione dei messaggi è detto filtraggio, e può essere di due tipi: su base topic o su base contenuto. Nel primo caso, i messaggi sono appunto pubblicati su un topic specifico e i subscriber ricevono i messaggi pubblicati sui tutti i topic, ai quali hanno fatto una sottoscrizione; è responsabilità del publisher definire i tipi di messaggi a cui i subscriber possono iscriversi. Nel secondo caso, invece, i messaggi sono inoltrati ai subscriber solo se il contenuto incontra certe caratteristiche da loro definite; in questo caso è il subscriber che classifica i messaggi. Alcuni sistemi supportano, infine, una soluzione ibrida, dove i publisher pubblicano messaggi su topic, mentre i subscriber registrano sottoscrizioni content-based su uno o più topic. In molti sistemi di questo tipo, i publisher inviano i messaggi a un broker a cui i subscriber si iscrivono. A questo punto è il broker a occuparsi del filtraggio dei messaggi, di solito attraverso un sistema di store and forward. Un sistema che segue questo paradigma ha la caratteristica di essere: Lascamente accoppiato: i publisher sono lascamente accoppiati con i subscriber, e non devono sapere nulla della loro esistenza. Una volta che sono a conoscenza del topic, possono essere completamente all oscuro della topologia del sistema ed ognuno può agire senza preoccuparsi dell altro. Publisher e subscriber possono anche essere disaccoppiati temporalmente: non è detto, infatti, che i subscriber debbano ricevere solo gli eventi appena pubblicati, possono recuperare messaggi pubblicati tempo prima, anche nel caso in cui il publisher che li ha postati, sia attualmente offline. Invece, nel sistema di tipo Client- Server, il client non può inviare messaggi al server se questo non è attivo e, ovviamente, il server non può riceverne nulla se il client non è attivo. Scalabile per installazioni relativamente piccole: le soluzioni pub/sub sono più scalabili delle tradizionali Client-Server, grazie alla possibilità di operazioni parallele, cache dei messaggi, 49 Beneficiario COLFUTURO 2010

55 routing di tipo tree-based o network-based e altre. E anche vero che aumentando la complessità dei sistemi, questo beneficio tende a essere perso. Comunque, la scalabilità di sistemi di pub/sub per sistemi ad alto carico è un importante campo di studio. Tale sistema presenta, però, anche degli svantaggi: Il disaccoppiamento fra publisher e subscriber: è un effetto collaterale del suo principale vantaggio; è infatti difficile specificare caratteristiche supplementari, alla comunicazione che si desidera. Ad esempio, nella maggior parte dei sistemi di pub/sub, non c è modo di ottenere la garanzia che il proprio messaggio arrivi a destinazione e ricevere un avviso, nel caso ciò non sia possibile. Un altro esempio è dovuto al fatto che i publisher non sanno se un subscriber è in ascolto e questo potrebbe implicare che un certo numero di messaggi importanti vengano inviati dal publisher, senza che ci sia nessuno a riceverli e questo senza che il publisher abbia modo di saperlo. La non scalabilità per sistemi grandi: si manifesta con instabilità e rallentamenti. E soggetto ad attacchi: per esempio con subscribers che si iscrivono per ricevere dati a cui non sono autorizzati o publisher che inviano messaggi errati o dannosi. L unico modo sicuro di evitare ciò è mediante crittazione (per esempio SSL/TSL). Nel corso degli ultimi anni, sono stati sviluppati numerosi sistemi middleware pub/sub basati su eventi, ma alcuni sistemi esistenti hanno anche le funzionalità di un middleware tradizionale, come controllo d invocazioni, affidabilità, controllo accessi, transazioni, ecc. Gli esempi di applicazione per gli attuali sistemi pub/sub sono spesso molto limitati, come ad esempio instant-messaging e stock quote dissemination. Questo riflette il fatto che questi sistemi non sono destinati ad essere piattaforme di uso generale. [21] Di seguito, sono elencate importanti caratteristiche, necessarie in un middleware publish/subscribe: Interoperabilità: consente l'integrazione di una serie di componenti con il middleware. Il modello di eventi e subscription language devono essere indipendenti dalla piattaforma. Il middleware non deve 50 Beneficiario COLFUTURO 2010

56 fare affidamento su un particolare supporto della rete sottostante, non universalmente abilitato come l IP multicast. Affidabilità: il middleware offre requisiti di Quality of Service (QoS) ai client o server, e potrebbe supportare ranghi di QoS da ''best-effort'' a ''guaranteed and timely''. Supporta meccanismi di Fault-tolerance, e il fallimento di un solo componente architetturale non affetta l intero sistema. Espressività: L expressiveness è un requisito importante per specificare gli eventi e le sottoscrizioni. Le sottoscrizioni devono consentire il filtraggio in base al contenuto degli eventi (filtraggio in base al contenuto). Composite event Expressions rileva i modelli nel flusso di eventi, che sono di più alto livello intuitivo e di potente astrazione che aiuta gli event subscribers, di esprimere l informazione necessaria. Tuttavia, c'è sempre un trade-off tra espressività ed efficienza. Usabilità: significa che il middleware è facile da maneggiare. È dovrebbe chiaramente integrarsi con il linguaggio di programmazione dell'applicazione. Ad esempio, gli eventi devono essere oggetti tipizzati che sono mappati in modo trasparente su linguaggi di programmazione ad oggetti Soluzioni attuali Si entra ora nel dettaglio delle varie soluzioni esistenti per i middleware di questo tipo, partendo dal protocollo PubSubHubbub. Si tratta di un protocollo aperto e distribuito per comunicazioni di tipo Publish/Subscribe su Internet che estende le soluzioni nate per i feed Atom e RSS. Lo scopo primario è di garantire la notifica near realtime di eventi, evitando richieste continue al server in cerca di aggiornamenti. In PubSubHubbub le entità fondamentali sono publisher, subscriber e hub. 51 Beneficiario COLFUTURO 2010

57 Figura 13: Meccanismo di PubSubHubbub. Il funzionamento è il seguente (illustrato in figura 13): Un publisher carica il proprio feed Atom o RSS nella maniera tradizionale, aggiungendo però nel file xml, l indicazione dell hub di riferimento. Questi hub possono essere pubblici, o di proprietà del publisher stesso. A questo punto, il subscriber interessato al feed, si iscrive al topic relativo sull hub indicato ed il subscriber avvia un server, in modo che possa essere notificato ogni volta che il feed riceve un aggiornamento. Il subscriber si iscrive al Topic URL basandosi su quello dichiarato nell hub. Quando il publisher aggiorna il topic URL, avviene un ping verso l hub indicandogli che c è un aggiornamento. L hub invia in multicast i contenuti aggiornati a tutti i subscriber di quel feed. Il protocollo è libero e decentralizzato. Non ci sono aziende che lo controllano e chiunque può avviare un proprio hub, o pubblicare su hub pubblici. Altre soluzioni presenti sul mercato sono le seguenti: ActiveWeb (commerciale): è una soluzione sviluppata da Active Software. Si tratta di un middleware che permette a risorse differenti, come applicazioni, database e browser di scambiare informazioni attraverso intranet o internet. Il sistema si basa su un Information Broker e diversi Adapters. Gli Adapters hanno lo scopo di prendere le informazioni da database o applicazioni, permettendo agli sviluppatori di pubblicare tali informazioni sull Information Broker. Gli utenti, utilizzando applicazioni Java, si possono iscrivere a una o più risorse. A questo punto l Information Broker si occupa di inviare, in modo affidabile, le informazioni sulla rete a chi ne fosse interessato. Ai giorni nostri Active Software non esiste più e la soluzione è da considerarsi ritirata. 52 Beneficiario COLFUTURO 2010

58 TIBCO Rendezvouz (commerciale): si tratta della soluzione a oggi più provata e supportata disponibile sul mercato per la messaggistica a bassa latenza (in grado di garantire latenze dell ordine dei microsecondi). E usata da più di 2000 società nel mondo, per applicazioni che vanno dalla distribuzione di dati al trading; da sistemi di controllo real-time per impianti industriali, ad applicazioni del settore pubblico e militare. Le features chiave di questo sistema sono le seguenti: La varietà di sistemi di comunicazione supportati: la messaggistica può essere Publish/Subscribe o Request/Response, punto-punto o multicast, sincrona o asincrona, e inoltrata su LAN, WAN o Internet. La possibilità di scegliere la qualità di servizio, passando da servizi di messaggistica molto leggeri, a servizi di provata efficienza. Un routing dinamico con inoltro dei messaggi di tipo interestdriven, che aggiunge efficienza e semplifica la configurazione per sistemi multi dominio. La possibilità di supportare estensioni definite dall utente per il contenuto dei messaggi, migliorando la flessibilità del sistema, supportando diversi formati dati, come XML. Supporto integrato sia per il controllo del carico, sia per la gestione degli errori, con API per inserirlo nelle applicazioni. Le API sono disponibili per Java, C, C++, Perl e COM, e il sistema è disponibile per moltissime piattaforme, da FreeBSD 6.2 a MAC OS X 10.4 e superiori, da Red Hat Enterprise Linux 4 a Windows Server. TIBCO utilizza un architettura distribuita peer-to-peer di tipo daemonbased per eliminare colli di bottiglia e singoli punti di rottura. Le aziende possono usare demoni esterni per inviare i messaggi oppure inserire la parte di messaggistica direttamente nelle proprie applicazioni, per limitare ulteriormente la latenza. I sistemi di tolleranza agli errori e bilanciamento del carico inseriti nel sistema permettono inoltre di massimizzare le prestazioni. Esiste inoltre un framework di controllo (TIBCO Hawk ), che garantisce ai componenti basati su TIBCO Rendezvous un immediato ripristino da errori imprevisti. Hermes, si incentra attorno alla nozione di un tipo di evento e supporta caratteristiche comunemente note da linguaggi orientati agli oggetti, come gerarchie e iscrizioni super-tipo. Usa un algoritmo di 53 Beneficiario COLFUTURO 2010

59 routing scalabile utilizzando una rete di routing overlay con la creazione di nodi di rendezvous. Prevede meccanismi di tolleranza agli errori, che possono far fronte a diversi tipi di fallimenti, che sono integrati con l'algoritmo di routing, risultando in un sistema scalabile e robusto. La figura 14 illustra un sistema distribuito implementato con Hermes. È costituito da due componenti, event client e event broker. L event client può essere event publishers o event subscribers e usano i servizi di comunicazione forniti dal middleware, utilizzando eventi. [22] Figura 14: Sistema Distribuito HERMES. Gli event client sono leggeri componenti, che possono essere facilmente implementate in qualsiasi linguaggio di programmazione dell'applicazione. Loro si collegano a un event broker prima di utilizzare il servizio middleware. Figura 15: Rete di overlay tra Brokers. Il compito principale degli event broker è accettare sottoscrizioni da event subscribers e quindi distribuire gli eventi da publisher a tutti gli 54 Beneficiario COLFUTURO 2010

60 iscritti interessati. I brokers sono interconnessi tra di loro con una topologia arbitraria e usano message-passing per comunicare con i loro vicini (figura 15) Message Oriented Middleware (MOM) I Message-Oriented Middleware inviano messaggi che sono collezionati e memorizzati in code finché non vengono gestiti. I MOM sono spesso usati per processi estesi, come le applicazioni del processo di sviluppo e possono offrire un certo livello di ripristinabilità attraverso il meccanismo di journaling, che permette alle code di essere ripristinate in caso di errore. MOM è una categoria di software di comunicazione fra applicazioni, basata sull invio di messaggi in modo asincrono. Alcune soluzioni prevedono che la logica di routing sia fornita dal livello di messaggistica, altre che sia gestita direttamente dall utente e altre ancora prevedono soluzioni intermedie. In questa tipologia di middleware, le code di messaggi forniscono una memorizzazione temporanea, nel caso in cui il programma destinazione sia impegnato o non connesso o sia incorso in qualche errore, in modo da consentire al mittente di proseguire nelle proprie attività con la garanzia che i messaggi inviati verranno recapitati al destinatario, non appena questo sarà in grado di processarli. Il messaggio ricevuto non deve necessariamente essere identico a quello inviato, un sistema MOM, infatti, può trasformare i messaggi in transito, per soddisfare le richieste di mittenti e destinatari. Può quindi accadere che un applicazione invii un messaggio nel proprio formato nativo e due o più applicazioni ne ricevano una copia, ognuna in un formato diverso. Questo meccanismo rappresenta la caratteristica più interessante dei MOM. Lo svantaggio principale di molti sistemi di questo tipo è che richiedono un elemento aggiuntivo nell architettura: il message broker, che si occupa del trasferimento dei messaggi. Come in ogni sistema, l aggiunta di un componente può portare ad una riduzione delle performance e dell affidabilità e può rendere i sistemi più difficoltosi e costosi da gestire. Inoltre, alcune comunicazioni fra applicazioni richiedono un comportamento implicitamente sincrono, ciò non è facilmente 55 Beneficiario COLFUTURO 2010

61 gestibile con i MOM, anche se, nei sistemi più moderni, ci sono funzionalità che permettono di raggruppare richieste e risposte, in modo da rendere il comportamento simile ad una comunicazione sincrona. La presenza di un gran numero di standard sull uso di middleware message-oriented ha causato problemi di frammentazione, tutte le maggiori compagnie hanno scelto una propria implementazione, ognuna con proprie API e propri strumenti di gestione. Tra queste implementazioni possiamo citare: JMS (Java Message Service), API legate a J2EE, e implementate dalla maggior parte dei produttori di sistemi MOM con l obiettivo di nascondere l implementazione specifica del sistema. JMS non definisce il formato dei messaggi scambiati e prevede due meccanismi di comunicazione: Publish/Subscribe e punto-punto. AMQP (Advanced Message Queing Protocol), uno standard emergente che definisce sia il protocollo sia il formato dei messaggi da scambiare. L obiettivo è fornire un routing flessibile, con paradigmi per la comunicazione punto-punto, Publish/Subscribe o richiestarisposta. Le applicazioni che usano AMQP sono tipicamente scritte in Java, ma esistono anche API in C#, C++, PHP, Python, Ruby etc. Le soluzioni di questo tipo possono essere usate per: l integrazione di applicazioni eterogenee, perché di solito tutti i sistemi, anche se sviluppati in un linguaggio specifico, forniscono API per molti linguaggi. Questo è un grande vantaggio quando si devono integrare applicazioni scritte in linguaggi diversi su differenti piattaforme. In casi come questi, le varie API rendono possibile l invio e la ricezione dei messaggi sui sistemi utilizzati, senza preoccuparsi di quale sia il linguaggio impiegato. Sostituzione di RPC, poiché le applicazioni che usano RPC sincrone per comunicare sono ancora molto diffuse. Anche se questi sistemi sono efficienti, passare a un MOM può avere diversi vantaggi, senza perdere la garanzia della risposta. Ridurre l accoppiamento fra applicazioni e migliorare la scalabilità, in modo da rendere le applicazioni meno dipendenti l una dall altra e, quindi, migliori per sistemi in continuo sviluppo. Di seguito, vengono elencate varie implementazioni nate come middleware MOM, che oggi supportano anche il Publish-Subscribe: IBM WebSphere MQ (commerciale): si tratta di una famiglia di prodotti software di rete lanciata da IBM nel All inizio era 56 Beneficiario COLFUTURO 2010

62 conosciuta come MQSeries, per poi essere rinominata nel 2002 in WebSphere MQ. E disponibile per un grande numero di piattaforme (IBM e non) da z/os a Microsoft Windows. WebSphere MQ è una componente chiave della strategia SOA di IBM, e costituisce un backbone per lo scambio di messaggi fra 80 piattaforme diverse. Ci sono molte API per accedere alle funzionalità di WebSphere MQ, per diversi linguaggi tra cui C, COBOL, Java, C++ e altri. In WebSphere MQ è enfatizzata la robustezza e l affidabilità delle comunicazioni, e si assicura che un messaggio non sarà mai perso, se MQ è configurato in modo corretto. Per questo MQ può essere usato come una robusta alternativa per molte forme di comunicazione; per esempio, per l inoltro sicuro di file di grandi dimensioni al posto di FTP. Inoltre viene fornita la possibilità di effettuare trasformazioni di messaggi tra diverse architetture e protocolli, per esempio da Big Endian a Little Endian. Questo è fatto attraverso cosiddette exits. Queste exits sono applicazioni in funzione sull host del gestore delle code, e sono avviate da WebSphere MQ, quando c è bisogno di trasformare un messaggio. WebSphere MQ permette, infatti, anche l invio di messaggi di trigger per avviare altre applicazioni, e questo permette di costruire architetture message-driven. MQ può essere implementato anche come un cluster, in cui più implementazioni di MQ condividono la gestione dei messaggi, per aumentare le prestazioni e la gestione del carico. Il componente fondamentale del sistema WebSphere MQ è il gestore delle code, il quale gestisce la memorizzazione, il triggering e tutte le altre funzioni non strettamente legate al passaggio dei dati. Le comunicazioni fra i gestori delle code avvengono attraverso un canale, ogni gestore usa uno o più canali di tipo uni-direzionale per inviare e ricevere messaggi da altri gestori, e gestisce una propria coda di messaggi in cui essi sono memorizzati, in attesa di essere inoltrati. Per trasmettere un messaggio, un gestore rimuove il messaggio dalla propria coda di trasmissione e lo invia al gestore di destinazione che, non appena lo riceve, lo analizza per vedere se è per se stesso o se deve inoltrarlo ad altri. Se è per se stesso, controlla se la coda del destinatario sia presente e nel caso lo sia, vi pone il messaggio, altrimenti lo mette nella coda dei messaggi ad utenti offline, da recapitare in seguito. L altro elemento importante è quello della robustezza, fatta attraverso il log. Infatti ogni volta che un messaggio è messo in una coda, il dato viene anche loggato, in modo che nel caso di errori, si possa utilizzare il log per ricreare messaggi che sono andati persi. 57 Beneficiario COLFUTURO 2010

63 Microsoft MSMQ (commerciale): è un MOM sviluppato da Microsoft per i sistemi Windows Server (fin da Windows 95) ed è incluso anche in Windows 7 e Windows CE 3.0. MSMQ è comunemente usato in programmi sviluppati con Visual Studio, anche prima di.net. Microsoft lo ha anche incorporato nel suo framework di messaggistica: Windows Communication Foundation (WFC). Sotto WFC, MSMQ può essere usato per assicurare un trasporto sicuro e affidabile, con un modello di programmazione compatibile con altri standard di comunicazione. MSMQ è responsabile del trasporto affidabile dei messaggi fra applicazioni, per fare ciò inserisce i messaggi che non raggiungono il proprio destinatario in una coda per re-inviarli, non appena questo sia di nuovo raggiungibile. MSMQ supporta anche le transazioni, permette infatti che più operazioni su più code vengano raggruppate in una sola transazione, assicurando che tutte o nessuna abbiano effetto. Esiste infine un entità, il Microsoft Distributed Transaction Coordinator (MSDTC) che garantisce l esecuzione di queste transazioni. Oracle-BEA MessageQ (commerciale): si tratta di un sistema di code di messaggi. Per scambiare informazioni usando MessageQ, ogni programma deve collegarsi al bus di accodamento dei messaggi MessageQ, ad un particolare indirizzo di coda. L indirizzo di coda identifica la coda di messaggi nella quale il programma li riceve. Per inviare un messaggio MessageQ, un programma deve conoscere l indirizzo di coda del programma destinatario. Al contrario di altri sistemi di code di messaggi, le applicazioni MessageQ si collegano solo alle code su cui ricevono i messaggi, non su quelle a cui ne inviano. Il bus MessageQ rappresenta il canale su cui i messaggi vengono trasferiti tra applicazioni, creando una interconnessione fra le code di messaggi collegate ad esso. Una volta che un applicazione ha collegato la propria coda di messaggi al bus nell indirizzo di coda, può inviare messaggi a tutte le altre collegate e può anche leggere i messaggi ad essa indirizzati. Per questo, fornisce un approccio lascamente accoppiato, visto che le applicazioni che vogliono scambiare informazioni non devono: conoscere la rispettiva locazione (indirizzo di rete); sapere come stabilire comunicazioni fra l una e l altra; ed essere in esecuzione nello stesso momento o sullo stesso sistema operativo. 58 Beneficiario COLFUTURO 2010

64 Sui bus MessageQ esiste il concetto di gruppi di accodamento di messaggi. Ogni gruppo, identificato da un proprio ID, offre alle applicazioni un modo efficiente per condividere servizi MessageQ, come il recupero dei messaggi o il broadcasting. In uno stesso sistema, possono esserci più bus di accodamento dei messaggi. Le applicazioni connesse a bus differenti non possono comunicare fra loro. Ci sono due tipologie di prodotti: BEA MessageQ Server, per i sistemi che hanno abbastanza risorse da soddisfare tutti i servizi offerti da MessageQ (servizi di messaggistica, allocazione e gestione code, etc.) e Bea MessageQ Client, che è la versione più leggera, adatta per sviluppare applicazioni che adottano il solo sistema di messaggistica di MessageQ. Entrambi i prodotti sono estremamente portabili. Da notare come tutti i sistemi MessageQ richiedano l uso di almeno un server, per il routing sulla rete. MessageQ è considerato da molti come uno dei software di messaggistica più veloci e ricchi di feature presenti sul mercato. Alcune caratteristiche chiave sono la possibilità di nascondere alle applicazioni i dettagli di configurazione e la grande varietà di piattaforme supportate: sono supportate infatti praticamente tutte le piattaforme più importanti. Apache ActiveMQ (open source): è un middleware message-oriented open source della Apache Software Foundation, che implementa JMS 1.1 e fornisce grandi performance, scalabilità, affidabilità e sicurezza. Si tratta di un prodotto recente che fornisce la possibilità alle applicazioni, di comunicare in modo asincrono e lascamente accoppiato. ActiveMQ usa la licenza Apache, una delle licenze più libere disponibili e grazie a ciò, permette di modificare ActiveMQ senza problemi. Questo è ovviamente un punto a favore di questo sistema rispetto agli altri proprietari, visti in precedenza. Le feature di ActiveMQ sono le seguenti: Connettività: fornisce un ampio intervallo di opzioni di connettività, incluso il supporto per i protocolli come HTTP/S, multicast, SSL, TCP, UDP, XMPP e molti altri. Questo aumenta la flessibilità e rappresenta un vantaggio rispetto a molti sistemi esistenti che supportano un solo protocollo senza possibilità di cambiamento. Persistenza e Sicurezza: prevede molte soluzioni per la persistenza, per la sicurezza, autenticazione e autorizzazione. Integrazione con Application Server: fornisce l abilità di integrarsi facilmente con molti popolari application server Java. 59 Beneficiario COLFUTURO 2010

65 Svariate Client API: esistono API per molti linguaggi come Java, C/C++,.NET, Perl, PHP, Python, Ruby ed altri. Clustering: molti broker ActiveMQ possono lavorare insieme, formando delle reti di broker con scopi di scalabilità, queste reti possono supportare diverse topologie. Amministrazione semplificata: è sviluppato pensando agli utenti e prevede molte feature di amministrazione potenti e semplici da usare. Oracle Advanced Queing (commerciale): è un sistema completo di code di messaggi che permette di coordinare applicazioni all'interno e all'esterno dell'azienda. L'integrazione con il database permette ad AQ di ereditare la sicurezza, l'affidabilità e l'integrità dei database Oracle, e fornire la necessaria gestione dei messaggi per e-business. Gingerall GA MOM (commerciale): middleware MOM trasparente e scalabile che permette la comunicazione tra servizi, supportando applicazioni e piattaforme. Supporta il processing asincrono riducendo il numero e la complessità delle interfacce, fungendo da bridge a livello applicazione per ogni protocollo e interfaccia. In breve, è uno strumento che permette di creare, rendere disponibili e gestire sia servizi nuovi che esistenti. Vetex Interactive NetWeawe (commerciale): è un middleware che permette alle compagnie di interconnettere i propri sistemi informatici incompatibili fra loro, e aprirli alle tecnologie moderne come workstation, LAN e server SQL. PCB Systems Nirvana (commerciale): è un middleware MOM basato su Java che supporta il modello publish/subscribe. Supporta la persistenza dei messaggi e i documenti XML DOM oltre alle comunicazioni TCP e il tunneling HTTP/HTTPS. IIT Gmbh SwiftMQ (commerciale): è un micro-kernel basato sulla piattaforma JMS con alte performance e scalabilità. Dalla sua prima release di 7 anni fa, è usato ora da migliaia di utenti nel mondo. Fornisce una gestione intelligente ed un gran numero di feature. Envoy X-IPC (commerciale): è un set di strumenti avanzato per lo sviluppo di applicazioni multitasking e distribuite. Fornisce una gestione veloce e fault-tolerant dell'inoltro e dell'accodamento dei 60 Beneficiario COLFUTURO 2010

66 messaggi, sincronizzazione di semafori e memoria distribuita, il tutto in maniera trasparente alla rete. Nextient X Message Server (commerciale): è un middleware indipendente da hardware, sistema operativo e database. Altamente scalabile, XMS è capace di operare su piccole collezioni di dati o come server primario dei messaggi in larghe infrastrutture d'azienda. E un'opzione ideale per la connettività real-time per collezioni di dati distribuite, specialmente quelle in locazioni geografiche disperse. Molto leggero come occupazione di memoria e richiesta di risorse, XMS non richiede un database, per questo è adatto per il mercato delle soluzioni embedded. JORAM (Object Web, open-source): è un'implementazione puramente Java di JMS. Fornisce accesso ad un MOM, costruito su una piattaforma distribuita basata sugli agenti Scalagent. MQ4CPP (sixtyfourbit.org, open-source): permette a thread di applicazioni C++ di comunicare con altri thread localmente o in modo remoto attraverso lo scambio di messaggi. MantaRay (Coridan, open-source): è una soluzione di messaggistica e comunicazione peer-to-peer senza server, 100% Java, fornisce API per JMS e RMI, integrabile con JBOSS, WebLogic e WebSphere. Offre inoltro garantito, sicurezza e transazioni. Supporta il trasporto TCP e SSL. Open Message Queue (Glassfish Sun, open-source): si tratta di un server di messaggi scalabile, pronto per la produzione e di alta qualità. Fornisce un'implementazione completa di JMS per l'integrazione con sistemi orientati ai messaggi. Inoltre, Open MQ fornisce ulteriori feature necessarie alle aziende. Si basa su Java Message Queue e fornisce tutte le feature e le funzioni presenti nel prodotto Java System Message Queue. OSMQ (OSMQ, open-source): Open Source Message Queue è framework avanzato, puramente Java e asincrono sviluppato dal Boston System Group. XmlBlaster (xmlblaster.org, open-source): si tratta di un middleware MOM che supporta sia publish/subscribe sia messaggi punto-punto. Il messaggio è descritto attraverso metadata di tipo XML. I messaggi 61 Beneficiario COLFUTURO 2010

67 possono contenere vari tipi di contenuti: immagini GIF, oggetti Java, script Python, dati XML, un documento Word oppure testo semplice Middleware SQL-Oriented I middleware SQL-oriented connettono applicazioni con database, attraverso la rete e traducono richieste, sotto forma di generiche query SQL, nel linguaggio SQL nativo e specifico del database di destinazione. Il segmento relativo a questo tipo di middleware è maturo e dominato dalle grosse società produttrici di database e dalle compagnie che hanno già middleware che accedono a più database. La connessione è sincrona e la scalabilità può essere un serio problema facendo diventare, sia il middleware che il database, un punto di perdita delle prestazioni. Gli sviluppatori, di solito, usano i middleware SQL oriented, come meccanismo per estrarre informazioni da database locali o remoti. Per esempio, per estrarre informazioni da un database Oracle, gli sviluppatori possono invocare un middleware SQL per loggarsi sul database, richiedere informazioni e processare le informazioni che sono state estratte. I principali middleware di questo tipo sono: DataDirect: una famiglia di prodotti, che comprende DataDirect Connect e vari driver che offrono l'accesso a diversi database, senza richiedere l'uso di speciali strumenti specifici del database o di librerie client. I driver di DataDirect forniscono molte feature per aiutare lo sviluppo di applicazioni, e offrire benefici a runtime. Sono in grado di inoltrare, in modo automatico e trasparente, le richieste di connessione o le transazioni a un database server alternativo, se quello primario non è disponibile per un errore hardware o per questioni di traffico. DataDirect è utilizzabile con tutte le API (JDBC, ODBC, ADO.NET e OLE DB) per i più importanti database (SQL Server, Oracle, DB2, Sybase, MYSQL, ed altri) e supporta tutte le principali piattaforme (Windows, Linux e UNIX). DataDirect velocizza le operazioni di batch, o di caricamento di dati da file senza richiedere modifiche nel codice, o strumenti specifici del database. I driver DataDirect aumentano la velocità di elaborazione, l'efficienza della CPU e lo spazio di memoria occupato, e questo si traduce in migliori tempi di risposta, maggiore scalabilità e minor richiesta di hardware 62 Beneficiario COLFUTURO 2010

68 per supportare le applicazioni. Nei driver sono incorporate feature di sicurezza come crittazione dei dati TLS / SSL e autenticazione Kerberos per rafforzare le strategie di sicurezza degli utenti. CONNX DataSync: si tratta di un programma che rileva velocemente quali record, in un database, sono stati aggiunti, cancellati o cambiati e propaga i cambiamenti alla data warehouse. Le sincronizzazioni possono essere schedulate o eseguite a richiesta. DataSync lavora in collaborazione con i motori SQL distribuiti permettendo di trasferire i dati di una compagnia, virtualmente, da ogni locazione sorgente a ogni obiettivo. E' una soluzione scalabile e specificamente costruita per ambienti multi-macchina. Il CONNX DataSync Administrator permette di specificare in modo semplice quali dati devono essere propagati, chi deve ricevere questi dati, quando muovere i dati (sincronizzazioni schedulate) e se la transazione deve essere un ricaricamento completo o un aggiornamento incrementale. CONNX DataSync può essere usato per la migrazione di progetti e il supporto alla Business Intelligence, oppure per applicazioni di gestione dei processi d'azienda di tipo event-driven. DataJoiner (IBM): permette di vedere tutti i dati IBM, multiazienda, relazionali, non-relazionali, locali, remoti come se fossero dati locali. tcaccess : è una soluzione basata su SQL che combina i vantaggi di IBM S/390 con la flessibilità delle tecnologie internet e client/server. Permette a ogni PC o applicazione Web di accedere facilmente e recuperare i dati da una ogni sorgente dati IBM S/ Web Application Server Analizzate le categorie principali di middleware previste nella classificazione presa in esame, ora viene analizzata un'ultima importante sotto-categoria spesso associata ai TPM: quella dei Web Application Server. Un application server è un framework dedicato all'esecuzione efficiente di procedure (programmi, routine, script) per supportare la costruzione di applicazioni. Per le applicazioni web, questi componenti si trovano, di solito, sulla stessa macchina su cui c è il web server, e il loro scopo principale è supportare la costruzione di pagine dinamiche. Gli application server hanno, oggi, obiettivi più 63 Beneficiario COLFUTURO 2010

69 vasti del generare pagine web. Si occupano, infatti, di implementare servizi come il clustering, la gestione degli errori e il bilanciamento di carico, così che gli sviluppatori possano concentrarsi esclusivamente sullo sviluppo della business logic. Spesso il termine si riferisce ad application server Java, che possono essere visti come un estesa virtual machine per le applicazioni in esecuzione, che gestisce in modo trasparente le connessioni al database da un lato, e le connessioni al client dall'altro. I vantaggi degli application server sono: Integrità dei dati e del codice: centralizzando la business-logic su un solo server o su un piccolo numero di macchine, gli aggiornamenti e gli upgrade per tutti gli utenti possono essere garantiti. Non c'è rischio che versioni vecchie di un'applicazione cerchino di accedere e manipolare i dati in una maniera ormai sorpassata. Configurazione centralizzata: i cambiamenti alla configurazione dell'applicazione, come il movimento di un database server, o i settaggi del sistema, possono accadere in modo centralizzato. Sicurezza: un punto centrale attraverso cui i fornitori di servizi possono gestire l'accesso ai dati è un beneficio per la sicurezza, visto che toglie la responsabilità della sicurezza dal potenzialmente insicuro livello client, senza esporre il livello database. TCO (Total Cost of Ownership): in combinazione, i benefici appena descritti, possono sfociare in una diminuzione dei costi per un'organizzazione che sviluppa applicazioni aziendali. In pratica, però la sfida tecnologica di scrivere programmi conformi a questo paradigma, combinata con la necessità di distribuire il codice client, negano questi benefici. I principali application server sono: Apache Geronimo: si tratta di un application server open-source sviluppato da Apache Software Foundation e distribuito sotto licenza Apache. Geronimo è compatibile con le specifiche Java EE 5.0. IBM ha fornito un considerevole supporto al progetto, e infatti nel 2005 ha annunciato una versione free del proprio application server (WebSphere), basato proprio su Geronimo. Il design architetturale di Geronimo è basato sul concetto di Inversion of Control (IoC), il che significa che il kernel non ha dipendenza diretta su nessuno dei suoi 64 Beneficiario COLFUTURO 2010

70 componenti. Il kernel è un framework di servizi che controlla il ciclo di vita dei servizi e dei registri. La maggior parte dei servizi di Geronimo sono aggiunti e configurati attraverso dei Gbean, le intefacce per connettere servizi al kernel, per diventare parte dell'intero application server. Ogni interfaccia Gbean può interagire con altri Gbean e operare su eventi arrivati dal kernel o da altri Gbean. Tali interfacce rendono possibile la migrazione da un servlet container a un altro (per esempio da Jetty a Tomcat), senza influenzare l'intera architettura. Nel progetto Geronimo sono inclusi i seguenti componenti open-source: WebSphere Application Server (Community Edition): si tratta di un application server all'interno di WebSphere. WAS è costruito su standard aperti come Java EE, XML, e Web Services. E' supportato dalle principali piattaforme, quali Windows: AIX, Linux, Solaris, i/os e z/os. E in grado di appoggiarsi a diversi web server tra cui Apache HTTP Server, Netscape Enterprise Server, Microsoft Internet Information Services e IBM HTTP Server. A differenza di Geronimo, questo Application Server contiene driver per I database DB2 e Informix, oltre a migliori librerie per il parsing XML (XML4j ed XLXP). JBoss Application Server (o JBoss AS) è un application server opensource basato su Java EE. Un importante distinzione per questa classe di programmi è che non implementa solo un server che si appoggia su Java, ma implementa, realmente, la parte Java EE di Java. Essendo basato su Java, Jboss è usabile su ogni sistema operativo che supporta Java. Jetty: è un HTTP Server ed un servlet container basato su Java, ma è anche un application server. Inizialmente sviluppato come progetto free e open-source, come parte dell'eclipse Foundation, è, correntemente, usato in prodotti come Google App Engine, HP OpenView, ActiveMQ, Geronimo, Maven e Ubuntu. Jetty è anche usato come Java Application Server standard da molti progetti come Eucalyptus e Hadoop. Borland AppServer: si tratta di un application server molto adatto per applicazioni J2EE di fascia alta che richiedono alta disponibilità e scalabilità transazionale, sia in implementazioni integrate che aziendali. E altamente configurabile, in modo da potersi adattare ad un gran numero di requisiti, permettendo di ottenere massima 65 Beneficiario COLFUTURO 2010

71 disponibilità, scalabilità transazionale, alto throughput e tempi di risposta quasi istantanei. AppServer supporta diversi standard industriali come EJB, JMX, servlet, JSP, XML e SOAP e soluzioni JMS. Le capacità di gestione e profiling delle applicazioni di AppServer permettono di monitorare e risolvere problemi legati ai servizi forniti. Se si verifica un errore nel sistema in produzione, AppServer aiuta ad isolare il problema velocemente e ristabilisce il servizio automaticamente. Application Server (Oracle, commerciale): permette di costruire applicazioni web usando le più moderne tecnologie standard, incluse Java (con supporto degli ultimi standard J2EE), XML e PL/SQL. Application Server (Silver Stream, commerciale): si tratta di una piattaforma certificata J2EE per la costruzione di applicazioni Web. ColdFusion (Macromedia, commerciale): è un application server completo per lo sviluppo e l'inoltro di applicazioni di e-business scalabili. JEUS (Tmaxsoft, commerciale): è un application server certificato per J2EE 1.3. JEUS fornisce un sistema di clustering specialmente progettato per applicazioni per grandi aziende. Jrun (Macromedia, commerciale): è un application server Java facile da usare, che fornisce una soluzione ad alte prestazioni e scalabile per la distribuzione di applicazioni web e d'azienda. Iportal Application Server (Iona, commerciale): è un ambiente di sviluppo, assemblaggio e distribuzione completamente integrato J2EE, per applicazioni Java lato Server. ONE Application Server (Sun, commerciale): fornisce le fondamenta per la distribuzione di Web Service e application service. Integra inoltre un potente ambiente di sviluppo di applicazioni che incrementano la produttività degli sviluppatori e la velocità del time to market. WebLogic Enterprise, Express e Server (BEA, commerciale): la versione Enterprise fornisce una soluzione completa per distribuire applicazioni di e-business adattabili e personalizzate. Sfruttando gli standard J2EE, la robusta tecnologia CORBA e la connettività ai mainframe, alle applicazioni esistenti e ai dati, BEA WebLogic 66 Beneficiario COLFUTURO 2010

72 Enterprise permette di attivare sistemi di e-business velocemente. La versione Express fornisce una piattaforma scalabile per servire contenuti dinamici e dati ad applicazioni web e wireless. Il Server, incorporando i servizi di presentazione e accesso al database, consente agli sviluppatori di creare velocemente applicazioni di e- business interattive e transazionali, o fornire servizi di presentazione per applicazioni esistenti. Il Server costituisce un ambiente operativo per un sistema affidabile capace di transazioni sicure e gestione dei web service. JonAS (Object Web): si tratta di un implementazione delle specifiche EJB open source. E' un'implementazione puramente Java che si basa su JDK ed è parte dell'iniziativa ObjectWeb. MultiXTpm (Moshe Shitrit): si tratta di un Application Server, MOM e TPM. Fornisce un ambiente di runtime e API per lo sviluppo di applicazioni scalabili, che devono processare transazioni online originate da vari tipi di dispositivi. Finita l analisi dello stato dell arte delle diverse famiglie di middleware, si procede ora nell analisi delle loro diverse architetture. 2.2 Architetture di Middleware Service Oriented Architecture (SOA) La Service Oriented Architecture (SOA) è un'architettura concettuale che non fa riferimento a nessuna particolare implementazione. Essa pone delle specifiche condizioni, che i componenti di un sistema devono rispettare e le caratteristiche che tale sistema deve necessariamente avere. Un sistema, costruito seguendo la filosofia SOA, è costituito da applicazioni, chiamate servizi, ben definite ed indipendenti l'una dall'altra, che risiedono su più computer all'interno di una rete. Ogni servizio mette a disposizione una certa funzionalità e può utilizzare quelle che gli altri servizi hanno reso disponibili, realizzando, in questo modo, applicazioni di maggiore complessità. [22] Si può concepire l architettura orientata ai servizi anche come un'evoluzione del calcolo distribuito basato sul paradigma di progettazione request/reply per applicazioni sincrone e asincrone. La logica di business di un'applicazione, o singole funzioni, vengono 67 Beneficiario COLFUTURO 2010

73 modularizzati e presentati come servizi per le applicazioni consumer/client. Il punto chiave di questi servizi è che hanno un accoppiamento lasco, cioè l'interfaccia di servizio è indipendente dall implementazione. Gli sviluppatori di applicazioni possono creare applicazioni, componendo uno o più servizi senza conoscere le implementazioni dei servizi sottostanti. Per esempio, un servizio può essere attuato sia in.net o J2EE, e l'applicazione, che lo consuma, può essere su una differente piattaforma o linguaggio di programmazione.[23] Architetture orientate ai servizi hanno le seguenti caratteristiche principali: sono dotati di interfacce autodescrittive, sottoforma di documenti XML. Web Services Description Language (WSDL) è lo standard utilizzato per descrivere i servizi. Comunicano con messaggi formalmente definiti tramite schema XML (XSD). La comunicazione tra i consumatori ed i fornitori di servizi avviene tipicamente in ambienti eterogenei, con poca o nessuna conoscenza del fornitore. I servizi SOA sono mantenuti in azienda da un registro che agisce come un elenco di directory. Le applicazioni possono cercare i servizi nel Registro e richiamare il servizio. Universal Description, Definition and integration (UDDI) è lo standard utilizzato per il registro del servizio. Ogni servizio SOA ha una qualità di servizio (QoS) associata. Alcuni degli elementi chiave di QoS sono i requisiti di sicurezza, come l'autenticazione e l'autorizzazione, messaggistica affidabile ecc. SOA, con la sua natura lascamente accoppiata, consente alle aziende di collegare nuovi servizi o potenziare i servizi esistenti in modo granulare per rispondere alle nuove esigenze aziendali, e offre la possibilità di effettuare i servizi di consumo attraverso canali diversi Architettura di servizio Per implementare SOA, le imprese hanno bisogno di un'architettura di servizio, di cui un esempio è mostrato nella figura Beneficiario COLFUTURO 2010

74 Figura 16: Un esempio di architettura di servizio. Nella Figura 16, consumatori diversi di servizio (Service Consumers) possono richiamare servizi inviando messaggi. Questi messaggi sono trasformati e indirizzati da un service bus, ad un appropriata implementazione del servizio. In questa architettura è consentito incorporare regole di business dentro un servizio. L'architettura di servizio prevede anche una infrastruttura di Management del servizio, che gestisce i servizi e le attività come il controllo, la fatturazione e la registrazione. Inoltre, l'architettura offre alle aziende la flessibilità per avere processi aziendali agili, utile per risponde alle prescrizioni delle normative e modificare singoli servizi senza influire sugli altri Infrastruttura SOA Per eseguire e gestire applicazioni SOA, le imprese hanno bisogno di una infrastruttura SOA che fa parte della piattaforma SOA. Una infrastruttura SOA deve supportare tutti gli attuali standard pertinenti e necessari. Una tipica infrastruttura SOA è simile alla Figura Beneficiario COLFUTURO 2010

75 Figura 17: Una tipica infrastruttura SOA. SOA consente modifiche alle applicazioni, mantenendo i clienti o consumatori di servizi isolati dai cambiamenti evolutivi che avvengono nella implementazione di un servizio. SOA consente di aggiornare singoli servizi o servizi consumatori, non è necessario riscrivere completamente un'applicazione o mantenere un sistema esistente che non si rivolge più alle nuove esigenze aziendale. Infine, l architettura orientata ai servizi offre alle aziende una maggiore flessibilità nella creazione di applicazioni e processi di business in modo agile, sfruttando l'infrastruttura dell'applicazione esistente per comporre nuovi servizi Web Services Un web service è un interfaccia che descrive un insieme di operazioni accessibili sulla rete tramite messaggi standardizzati XML. In altre parole si può dire che è un applicazione software identificata da un Uniform Resource Identifier (URI), in cui le interfacce pubbliche sono definiti e descritte in XML, [8] queste interfacce descrivono una serie di operazioni (metodi) richiamabili attraverso il web, in altre parole utilizzando il protocollo http. Più precisamente, il protocollo che viene utilizzato (sempre all interno di http), per la comunicazione tra l applicazione client (tipicamente un applicazione web) ed un web service, prende il nome di Simple Object Access Protocol (SOAP), il quale è descritto in dettaglio più avanti. 70 Beneficiario COLFUTURO 2010

76 Un modo standardizzato di integrazione di applicazioni basate sul Web usa gli standard aperti XML, SOAP, WSDL ed UDDI su un internet backbone: XML è usato per etichettare i dati, SOAP viene utilizzato per il trasferimento dati, WSDL è usato per descrivere il servizio, e UDDI è usato per elencare i servizi disponibili. I servizi web lavoro sull ipotesi che le funzionalità messe a disposizione da una azienda siano esposte come servizio. I servizi Web sono analoghi ai wrapper sofisticati, che incapsulano una o più applicazioni, fornendo una interfaccia unica e anche un accesso web. Le risorse web sono controllate dal server, il quale è accessibile ai client, in modo sincrono usando metodi come GET, PUT, POST e DELETE di HTTP. Lo stato viene mantenuto solo dal server, che consente la memorizzazione nella cache, e il reindirizzamento delle richieste e delle risposte. [24] Un web service è costituito da 3 elementi che possono essere visti in figura 18: Service Broker: Registro che contiene le descrizioni di servizi, pubblicate su richiesta dei service producer e ricercate dai service consumer. Service Provider: E il proprietario del servizio. Da un punto di vista architetturale, rappresenta il nodo che contiene il servizio. Service Requester: E l applicazione che sta cercando, chiamando o iniziando un interazione con un servizio. Un service consumer può essere un browser o un applicazione (es., un altro web service) Figura 18: Architettura di Web Services. 71 Beneficiario COLFUTURO 2010

77 I web services possono essere considerati come una nuova forma di RMI dove: SOAP ha il ruolo di protocollo di trasporto applicativo (come IIOP) e WSDL ha il ruolo di IDL. [25] Simple Object Access Protocol (SOAP) Il Simple Object Access Protocol è un protocollo di rete che specifica le regole dello scambio d informazioni, quando esse sono fornite, come servizi Web. SOAP è stato sviluppato da Microsoft, DevelopMentor e Userland software ed è stato proposto come interfaccia standard per l'internet Engineering Task Force (IETF); Si basa su XML e può operare su differenti protocolli di rete, ma HTTP è quello comunemente utilizzato ed è l'unico standardizzato dal W3C. La parola object manifesta che l'uso del protocollo dovrebbe effettuarsi secondo il paradigma della programmazione orientata agli oggetti. [26] SOAP è la struttura operativa (framework) estensibile e decentralizzata che può operare sopra varie pile protocollari per reti di computer fornendo tramite messaggi richieste di procedure remote. I richiami di procedure remote possono essere infatti modellizzati come interazione di parecchi messaggi SOAP, la sua struttura segue la configurazione Head-Body, analogamente ad HTML. Il segmento opzionale Header contiene meta-informazioni come quelle che riguardano il routing, la sicurezza e le transazioni.[27] Il segmento obbligatorio Body trasporta il contenuto informativo e talora viene detto carico utile, o payload. Questo deve seguire uno schema definito dal linguaggio XML Schema. Soap può essere utilizzato in due modi diversi per una chiamata: Richiesta via SOAP di parametri: il client controlla nel Service Registry l'oggetto d'interesse e sviluppa il messaggio secondo i parametri contenuti nel Service Registry. General Purpose Messaging: un programmatore può sviluppare un suo protocollo privato, il client conosce a priori i parametri e non necessita di consultare il service registry. All'interno del body del messaggio inserisco i dati scritti nel formato concordato con lo sviluppatore. 72 Beneficiario COLFUTURO 2010

78 Figura 19: Meccanismo di SOAP. Un client può formattare un messaggio SOAP per richiedere informazioni su un prodotto da un Web Service. <soap:envelope xmlns:soap=" <soap:body> <getproductdetails xmlns=" <productid>827635</productid> </getproductdetails> </soap:body> </soap:envelope> Il web service potrebbe inviare il suo messaggio di risposta con le informazioni richieste. <soap:envelope xmlns:soap=" <soap:body> <getproductdetailsresponse xmlns=" <getproductdetailsresult> <productname>toptimate, set da 3 pezzi</productname> <productid>827635</productid> <description>set di valigie; 3 pezzi; poliestere; nero.</description> <price>96.50</price> <instock>true</instock> </getproductdetailsresult> </getproductdetailsresponse> </soap:body> </soap:envelope> 73 Beneficiario COLFUTURO 2010

79 2.2.2 Service Oriented Device Architecture (SODA) SODA è un adattamento di un architettura orientata ai servizi (SOA), la quale integra sistemi di business attraverso un insieme di servizi che possono essere riutilizzati e combinati, per affrontare nuove priorità aziendali. I servizi sono componenti software con interfacce ben definite, e sono indipendenti dal linguaggio di programmazione e delle piattaforme informatiche su cui vengono eseguiti. L'approccio SODA di progettazione e costruzione di software distribuito è quello di integrare una vasta gamma di dispositivi fisici distribuiti in sistemi IT di imprese. Al livello più semplice, come si vede in figura 20, SODA consente ai programmatori di trattare sensori e attuatori (Device Service) così come si tratta ai servizi SOA (Enterprise Service), che sono ampliamente utilizzati oggigiorno. Detto questo, SODA cerca di creare interfacce tra il mondo fisico di sensori e attuatori e il mondo del software dei sistemi aziendali, eliminando gran parte della complessità e costi associati con i dispositivi per integrarsi nei sistemi enterprise altamente distribuite. [28] Figura 20: Enterprise Service Bus. SODA si concentra sul confronto tra l ambito fisico e digitale. In altre parole, un sensore, un termometro digitale o un lettore tag-rfid, può tradurre un fenomeno fisico in corrispondenti dati digitali. Oppure, un attuatore, come ad esempio un relè del riscaldatore o un indicatore di allarme, sono in grado di tradurre un segnale digitale, in un fenomeno fisico. Sensori e attuatori si combinano fisicamente o concettualmente per creare dispositivi e servizi complessi, come ad esempio un modulo di controllo del clima o di un sistema di geofencing che monitora la posizione di un veicolo all'interno una zona 74 Beneficiario COLFUTURO 2010

80 ristretta. L architettura in questione, pone pochi limiti sul tipo di dispositivo o il suo utilizzo, i quali possono venire per esempio da parte del governo, l'industria o d'impresa scientifica. Il rango di dispositivi possono variare, da semplici interfacce di base di sensori a complesse apparecchiature di diagnostica. Nell ecosistema di SODA si possono incapsulare dispositivi come se fossero servizi, e trattare i collegamenti specifici del dispositivo e i protocolli, come se fossero interfacce di rete, necessarie per pubblicare i dati su un definito protocollo SOA. Un servizio di un certo dispositivo standard può avere un'ampia varietà di hardware sottostante, firmware, software, ed implementazioni di rete, ma ciò non influenza il consumatore finale del servizio. I fornitori sono responsabili degli adattatori dei dispositivi e la logica dei servizi necessari per fornire il servizio specifico. Si possono anche costruire servizi più complessi o composti da altri servizi di periferica di basso livello. Si possono usare componenti esterni, provenienti da fornitori diversi, evitando di mantenere più versioni d interfacce specifiche del dispositivo, nel codice dell'applicazione. Sviluppatori aziendali possono programmare un comune insieme di servizi. L'impresa potrebbe aggiornare l'hardware del dispositivo, il firmware, e anche le interfacce dei dispositivi di livello inferiore, con poco o nessun impatto sulle applicazioni di consumo. [29] Architettura SODA deve essere compatibile con SOA. I meccanismi per la creazione e la condivisione di interfacce di servizio, capacità di manutenzione del software remoto, e modelli di messaggistica debolmente accoppiati presentano tecnologie altamente efficaci per l'implementazione di SODA. [30] I requisiti di SODA includono: Impiegare messaggi debolmente accoppiati sul lato dei servizi, in grado di supportare molteplici servizi di streaming comunemente utilizzati nei sistemi SOA come un Enterprise Service Bus. Utilizzare un modello di adattatore di dispositivi, per incapsulare le interfacce di programmazione specifiche del dispositivo. Utilizzare standard aperti, se sono disponibile, su dispositivi e servizi a livello di interfaccia. 75 Beneficiario COLFUTURO 2010

81 Fornire un mezzo per presentare interfacce di servizi standard o aperte ai dispositivi che hanno protocolli propri. Dove questo potrebbe non essere pratico permette di usare gli standard nell'interfaccia del dispositivo di basso livello. Supportare l'implementazione di un spettro di dispositivi adattatori, dal più semplice sensore di dati di basso costo, ai protocolli di dispositivi complessi. Supportare il caricamento di componenti logici configurabili da remoto, che facilitano la manutenzione, l'aggiornamento ed estendere le sue funzionalità di sicurezza. L implementazione di SODA comprende tre componenti principali (vedere figura 21, i blocchi in blu). Il blocco Device adapters comunica con le interfacce, protocolli e collegamenti dei dispositivi e presenta un modello astratto di servizi di un dispositivo sugli altri. Il bus adapter sposta i dati del dispositivo sui protocolli di rete, mappando un servizio di un dispositivo su un modello astratto per un specifico meccanismo SOA di associazione, usato da parte delle imprese. Il device service registry prevede servizi per la scoperta e l'accesso a SODA. Figura 21: Componenti principali di SODA. 76 Beneficiario COLFUTURO 2010

82 Devices Profile for Web Services Il Devices Profile for Web Services (DPWS) definisce un insieme minimo di vincoli di implementazione per consentire la messaggistica sicura per Servizi Web ed il rilevamento, la descrizione e gestione degli eventi su dispositivi con risorse limitate. I suoi obiettivi sono simili a quelli di Universal Plug and Play (UPnP), ma, in aggiunta, DPWS è pienamente allineato con la tecnologia Web Services e comprende numerosi punti di estensione, che consentono una perfetta integrazione dei servizi forniti da dispositivi in scenari di applicazione a livello aziendale. [31] DPWS fornisce le seguenti funzionalità: Scoperta di dispositivi DPWS compatibili sulla rete e dei servizi che essi offrono. Invio di messaggi a dispositivi DPWS, che sono in grado di ricevere risposte. Descrizione di un servizio Web, fornendo un file WSDL. Interazione con un servizio utilizzando la sua descrizione. Iscrizione e ricezione di eventi da un servizio Web. I dispositivi possono essere client DPWS (invocando servizi sui dispositivi), server DPWS (fornitori di servizi), o entrambi. DPWS per il.net Micro Framework supporta i dispositivi sia in un solo ruolo o in entrambi contemporaneamente. Queste due serie di funzionalità sono fornite in DLL separate e non sono reciprocamente dipendenti. DPWS si basa su standard esistenti di servizi web, tra cui XML, WSDL, XML, SOAP, MTOM, e HTTP. DPWS per il. NET Micro Framework incorpora anche questa funzionalità di supporto, anche se non tutto è esposto nelle API. Ad esempio, ci sono classi per la leggere e scrivere i documenti XML, in modo che le applicazioni e implementazioni di servizi siano in grado di analizzare i messaggi di Web Services e costruire le risposte ad essi. 77 Beneficiario COLFUTURO 2010

83 78 Beneficiario COLFUTURO 2010

84 PARTE 3 SISTEMI DI CONFIGURAZIONE DEI MIDDLEWARE 79 Beneficiario COLFUTURO 2010

85 80 Beneficiario COLFUTURO 2010

86 CAPITOLO 3: Sistemi di configurazione dei middleware In questo capitolo si studiano i sistemi di configurazione e gestione di sistemi distribuiti ed in particolare dei middleware. Questi tool sono importanti, per facilitare l uso di tali sistemi, devono permettere di configurare un'istanza del sistema, gestire il ciclo di vita dei vari moduli che lo compongono ed avere un'idea chiara in tempo reale del loro stato di esecuzione, facilitando l utente sia nella fase di commissioning della piattaforma, sia nella fase di configurazione dei vari componenti. Vista la vastità del campo, si è scelto di concentrarsi sul settore energetico, analizzando una serie dei maggiori commissioning tools e di analizzare il sistema di configurazione del middleware open source LinkSmart. Prima di tutto, nel paragrafo seguente viene introdotto i concetti di commissioning e provisioning, poi vengono analizzati i sistemi nel campo energetico ed infine il middleware LinkSmart ed il suo sistema di configurazione. 3.1 Commissioning and Provisioning Il commissioning è la fase di installazione e start-up di un apparecchiatura oppure una fornitura tecnica e di sua verifica della conformità alle specifiche di progettazione o obiettivi e criteri, ben definiti. Un'efficace fase di commissioning non può però limitarsi al solo controllo del corretto funzionamento tecnico, prescindendo da tutti gli altri aspetti necessari per rendere una fornitura efficace. Il commissioning è importante, perché permette la verifica della qualità del prodotto, la verifica delle funzionalità della fornitura, la verifica del raggiungimento dell'obbiettivo di produttività ed anche la verifica dell'economicità del processo. L attività di monitoraggio, controllo ed affinamento continui, durante l'avvio della produzione permette di ottimizzare i vari aspetti del processo, fino a raggiungere gli obiettivi prefissati in fase di progetto. Il comissioning consente di ridurre anche i costi di progettazione di un sistema orientato all'iot, abbassando le barriere di accesso, riducendo i requisiti di abilità per gli sviluppatori, e il costo della migrazione hardware delle applicazioni. 81 Beneficiario COLFUTURO 2010

87 Altro concetto importante ed ampiamente usato nel settore delle telecomunicazione è quello del provisioning, cioè il processo di preparazione e l'allestimento di una rete per consentire di fornire servizi ai propri utenti. 3.2 Commissioning tools nel settore energetico Nel settore energetico, c è una limitata disponibilità di tools, completamente automatizzati, per il commissioning. Lo stato dell arte comprende una serie di commissioning tools automatici e semiautomatici che vengono sviluppati e testati in istituti di ricerca ed università in tutto il mondo, con finanziamento dell industria e agenzie governative principalmente. Facendo uso di un commissioning tool, si facilita la configurazione e la gestione del ciclo di vita per sistemi distribuiti complessi, questo è un aspetto importante per avvalorare a livello complessivo il corretto funzionamento di un intero sistema. Molti tools includono direttive sulle procedure del commissioning, permettendo di implementare prototipi di software in strumenti indipendenti ed incorporati nella costruzione di sistemi di gestione dell'energia (figura 22). Figura 22: Idea sulla gestione dell energia. Un set di tools si estende oltre al livello di interfaccia grafica dell utente, integrando perfettamente il flusso di informazioni tra i 82 Beneficiario COLFUTURO 2010

88 tools, con questa interfaccia grafica è possibile fare il setup, o gestire la configurazione di una specifica piattaforma o middleware general purpuse, che normalmente agirà come il backbone delle infrastrutture software distribuite. In seguito si fa riferimento ad alcuni commissioning tools nel settore energetico Energy Management Ai giorni nostri, l energia costituisce ormai una delle principali voci di costo per un azienda e la normativa vigente pone vincoli sempre più restrittivi, per questo l energia può diventare oltre che un fattore di costo, anche un fattore di ricavo, attraverso l autoproduzione ed eventuale cessione o autoconsumo. L Energy Management costituisce uno strumento strategico per ottimizzare le risorse energetiche, ridurre l impatto ambientale dell organizzazione ed ottimizzare il ritorno degli investimenti in autoproduzione. L Energy Management è un processo iterativo, finalizzato ad un uso più efficiente e razionale delle fonti energetiche, per un autentica sostenibilità economica e ambientale delle aziende. Tale processo è composto da quattro fasi principali: Misurazione e analisi: si tratta della rilevazione dei dati di consumo e/o produzione di energia, valutazione dei profili e delle esigenze/performance energetiche (di consumo e/o produzione). Identificazione delle aree di ottimizzazione: cioè la ricerca e valutazione dei possibili interventi di ottimizzazione rapida e di lungo periodo, degli investimenti necessari ed il calcolo degli impatti di efficienza energetica (sulla riduzione dei consumi e/o ottimizzazione della produzione), oltre che, attraverso specifici sopralluoghi, la verifica degli impianti e delle principali apparecchiature, per il rispetto delle normative di legge, in termini di sicurezza, efficienza, impatto ambientale. Manutenzione e progettazione: sono gli interventi progressivi di ottimizzazione rapida (es. regolazioni impiantistiche). Inoltre, in questa fase, avviene la progettazione preliminare ed esecutiva di interventi più complessi (detti CAPEX da CAPital EXpenditure) ed innovativi (es. la riqualificazione impiantistica od interventi organizzativi, ICT, architettonici, formativi, di marketing), finalizzati a produrre efficienza energetica continuativa e permanente. 83 Beneficiario COLFUTURO 2010

89 Realizzazione e conduzione di interventi CAPEX: realizzazione e gestione operativa degli interventi di efficienza energetica e riqualificazione con miglioramenti tecnologici che prevedono l'utilizzo di nuove tecnologie ad alte prestazioni. Di seguito vengono analizzate alcune soluzioni commerciali, presenti sul mercato Commissioning tool commerciali InterAct è un tool che permette di monitorare come viene usata l energia in un impianto. Questo strumento fornisce grafici, visualizzazione dei dati, analisi statistiche e strumenti di esportazione dei dati per permettere di: Monitorare la domanda del consumo di energia elettrica di una struttura e il suo utilizzo. Verificare come ogni processo di business sta influenzando l'uso totale di energia. Identificare i livelli massimi della domanda di energia in un giorno. Visualizzare ed esportare i dati rilevanti. Schedulare report per inviarli per posta elettronica. Capire il modello di consumo di energia per ora, giorno, mese o anno. Cisco EnergyWise è una nuova architettura di gestione dell'energia che serve a misurare, tenere sotto osservazione e ridurre il consumo energetico dei dispositivi IP, quali telefoni, laptop e access point. Cisco EnergyWise si concentra sulla riduzione di utilizzazione dell energia in tutti i dispositivi collegati a una rete Cisco. Questa azienda pensa che le tecnologie di rete possano contribuire a ridurre le emissioni nocive, diminuendo l'uso di energia e promuovendo la sostenibilità ambientale. Con funzionalità per misurare in tempo reale e in modo granulare i consumi di energia, EnergyWise dà ai CIO una migliore e più completa visibilità sulle opportunità di risparmio energetico, sia a livello dell'azienda nel suo complesso, sia a livello di specifiche sezioni della rete, quali la rete di campus, le reti delle filiali remote, e il data center. Oggi EnergyWise consente il controllo dell'alimentazione delle varie apparecchiature, ma in futuro controllerà l'efficienza di una 84 Beneficiario COLFUTURO 2010

90 intera rete, dei sistemi di gestione degli edifici e di tutte le operazioni legate al proprio business che vengono svolte in azienda. [32] LonMaker è un pacchetto software per la progettazione, installazione, messa in servizio e manutenzione di reti LON aperte per il controllo energetico. Basato sul sistema operativo LNS della Echelon combina un architettura Client-Server ed una intuitiva interfaccia basata su Microsoft Visio. Il pacchetto comprende 64 crediti. In seguito si riportano in sintesi alcune delle sue caratteristiche: Fornisce un design facile da usare, commissioning e manutenzione di reti LonWorks, utilizzando una semplice interfaccia fornita da Microsoft Visio Unisce reti indipendenti in un'unica rete di controllo. Fornisce una facile integrazione con strumenti di terze parti e le applicazioni LNSm, con supporto plug-in e con l'importazione ed esportazione XML. Fornisce la selezione automatica del tipo di collegamento per migliorare l'affidabilità della rete e ridurre gli errori più comuni, quando si specificano le connessioni. Il tool Lonmaker può essere usato per gestire tutte le fasi del ciclo di vita di una rete, dal design iniziale e commissioning fino all operatività, perché fornisce la funzionalità di vari tools di rete, su una singola soluzione.[33] Ora si passa ad analizzare il middleware open source LinkSmart ed il suo sistema di configurazione. 3.3 Linksmart Introduzione LinkSmart è un middleware per dispositivi fisici eterogenei, in un'architettura distribuita. Esso è un middleware, che consente agli sviluppatori di incorporare dispositivi fisici eterogenei nelle loro applicazioni, attraverso servizi web facili da usare, per controllare qualsiasi dispositivo. questo middleware è stato sviluppato all'interno del progetto UE del Sesto Programma Quadro, chiamato Hydra. LinkSmart è un middleware che è 'inclusive', cioè permette di abilitare qualsiasi dispositivo per essere rintracciabile e utilizzabile da un'applicazione LinkSmart. Ciò, punta a risolvere il problema di 85 Beneficiario COLFUTURO 2010

91 incompatibilità tra protocolli proprietari dei vari dispositivi. Esso fornisce strumenti di sviluppo per sviluppatori di applicazioni, che utilizzano tali dispositivi e anche gli strumenti per i produttori, per consentire ai loro dispositivi di essere parte di un ambiente inteligente Architettura LinkSmart si basa fondamentalmente su servizi web. Da una parte astraendo ogni dispositivo come un servizio web indipendentemente dalla tecnologia di rete utilizzata, come ad esempio Bluetooth, RF, ZigBee, RFID, WiFi, ecc. LinkSmart ha anche una serie di gestori di base, che forniscono funzionalità utili ai servizi web, per supportare gli sviluppatori a creare le loro applicazioni attraverso LinkSmart. Dal momento che questi managers sono lascamente accoppiati, il middleware è in grado di funzionare anche se i suoi componenti sono distribuiti su diversi dispositivi. Visto che ogni dispositivo è in grado di eseguire una parte del middleware, non vi è alcuna necessità di server centrali per eseguire un'applicazione complessa, perché i dispositivi meno potenti possono cooperare, per lavorare come potente piattaforma. Questo rende ideale LinkSmart per la creazione di applicazioni ubique.[34] Nell architettura di LinkSmart, ci sono diversi managers. Alcuni di questi sono considerati core managers (principali), in quanto forniscono le funzionalità elementari di LinkSmart e sono più avanzati nel loro stato. Oltre ai core managers ci sono un gran numero di manager prototipi, che mostrano possibili estensioni del middleware, ma non sono attivamente sviluppati. Le caratteristiche di base che LinkSmart offre sono: Networking Eventing Security Proxy discovery Proxy development Configuration I dispositivi integrati in LinkSmart possono essere classificati in una delle seguente due categorie: 86 Beneficiario COLFUTURO 2010

92 Dispositivi che necessitano di software proxy. Dispositivi nativi Linksmart. Un Proxy è un componente software responsabile della comunicazione con le piattaforme chiuse ed i vecchi dispositivi, che si occupa di comprendere la tecnologia utilizzata e il formato dei dati scambiati. I Dispositivi LinkSmart-Nativi sono dispositivi fisici in grado di eseguire un sottoinsieme di managers sulla propria piattaforma. Il requisito minimo per essere un dispositivo LinkSmart nativo è la possibilità di eseguire il network manager e l'event Manager. Il middleware LinkSmart offre un'ampia collezione di componenti software riutilizzabili per sviluppatori esperti. Sulla base di questi componenti software e astrazioni di programmazione, consento ai programmatori di sfruttare importanti concetti nel settore delle pervasive technologies. il middleware LinkSmart, infatti fornisce le seguenti funzionalità: Il Network Manager implementa web service usando il protocollo peer-to-peer Juxtapose (JXTA). Il Discovery Manager automatizza e facilita la scoperta di dispositivi in una rete Linksmart. L'Event Manager fornisce un servizio per costruire applicazioni che utilizzano il paradigma publish-subscribe in LinkSmart. CryptoManager e TrustManager si occupano delle operazioni di crittografia, la valutazione della fiducia in differenti tokens e l'applicazione delle politiche di sicurezza di controllo di accesso. La figura 23 mostra un esempio di architettura di rete per Linksmart. Ogni dispositivo nativo si collega tramite il Network Manager. Un Gateway ospita, inoltre, un paio di proxy per dispositivi di piattaforma chiusa (ad es: Bluetooth o ZigBee). Il gateway deve eseguire un Network Manager, che registra tutti i servizi, che appartengono ai dispositivi della rete LinkSmart. Inoltre, sul gateway, un Device Application Catalogue (DAC) può essere eseguito, per tenere traccia dei dispositivi disponibili nella rete LinkSmart. L'applicazione Linksmart gira su un PC, come una applicazione dedicata (cioè un'architettura centralizzata). L'applicazione può accedere ai servizi specifici, attraverso il Network Manager, se sa in 87 Beneficiario COLFUTURO 2010

93 anticipo quali servizi si desidera utilizzare, in alternativa, l'applicazione può esplorare i dispositivi sul DAC, basandosi su un criterio specifico e accedendo ai loro servizi. Questa funzione è particolarmente utile se l'applicazione ha bisogno di fare una operazione per gruppi di dispositivi. Ad esempio spegnere tutti i dispositivi di commutazione collegati ad un gateway. Figura 23: Architettura di Rete di Linksmart. Il middleware LinkSmart incorpora un supporto per l'auto-scoperta di dispositivi. Quando un dispositivo Linksmart viene introdotto e abilitato, successivamente il middleware è in grado di rilevare e configurare automaticamente il dispositivo. I web service LinkSmart devono poter essere identificati in modo univoco, nel paragrafo seguente viene spiegato come ciò avviene in LinkSmart 88 Beneficiario COLFUTURO 2010

94 3.3.3 Virtual Address 2.x L oggetto VirtualAddress contiene l'indirizzo che ogni servizio ha all'interno della rete LinkSmart, infatti, ogni endpoint del servizio è identificato da un VirtualAddress lungo 32 byte che ha il seguente formato: contextid-3.contextid-2.contextid-1.serviceid e.g.: Il Virtual Address viene utilizzato per incapsulare, in modo uniforme, specifici schemi di indirizzamento di diversi protocolli di rete (ad esempio: IP, Bluetooth, ZigBee, ecc.), che possono essere collegati alla rete LinkSmart. VirtualAddress mantiene anche l'ip dell endpoint nascosto, per garantire la privacy e la sicurezza del servizio. L'assegnazione del VirtualAddress avviene automaticamente, tramite il Network Manager, quando gli sviluppatori registrano i propri servizi web ad esso. Generalmente si ottiene il VirtualAddress durante la fase "attiva" del bundle, nel metodo activate, prima si recupera il Network Manager, in questo modo: RemoteWSClientProvider service = (RemoteWSClientProvider) this.bundlecontext.getservice( this.bundlecontext.getservicereference(remotewsclientprovider.class.getname()) ); try { networkmanager = (NetworkManagerApplication) service.getremotewsclient( NetworkManagerApplication.class.getName(), NETWORK_MANAGER_APPLICATION_ENDPOINT, false); } catch (Exception e1) { LOG.error(e1.getMessage(), e1.getcause()); } In una seconda fase, viene richiesto al Network Manager di assegnare un VirtualAddress, senza cui i servizi non sono accessibili tramite il network manager. Questo avviene registrando il servizio: Registration myvirtualaddress = registerservice(attributes, endpoint, backbonename); 89 Beneficiario COLFUTURO 2010

95 Nei prossimi paragrafi verrà indicato come queste identità vengono gestite e come vengono sfruttate per implementare la funzionalità di discovery Gestione dell identità e discovery LinkSmart permette di proteggere la privacy durante l esecuzione, utilizzando un innovativo sistema di rilevamento per proteggere le query, pur rimanendo robusto. Di seguito viene descritto come le informazioni, quali gli attributi di identità sono condivisi e scoperti. Per capire lo schema di discovery in LinkSmart bisogna prima dare una rapida occhiata allo schema di gestione delle identità. I servizi hanno un VirtualAddress, una descrizione e una identità basata su attributi. Il virtual address è stato descritto nel paragrafo precedente. Inoltre, quando si registra un servizio per LinkSmart si può scegliere una descrizione, che fornisce il modo più semplice per scoprirlo. Visto che le descrizioni non sono troppo esplicite, e non consentono di identificare univocamente i servizi, per avere un modo più accurato per accedere ai servizi, si hanno a disposizione un insieme di attributi a scelta libera. Utilizzando questi attributi è possibile definire esattamente il servizio che si sta cercando. [35] Ogni Network Manager trasmette regolarmente l'elenco dei VirtualAddress e le descrizioni che sono collegate a queste. In questo modo, se un'applicazione è alla ricerca di un VirtualAddress da una descrizione, il Network Manager locale può immediatamente rispondere a questa query. Ma, come accennato in precedenza, questo può portare a individuare più servizi, che condividono una descrizione comune. Per scoprire più precisamente i servizi si devono utilizzare le ricerche basate su attributi. Quando si cercano i servizi attraverso gli attributi, il Network Manager mappa gli attributi cercati in un filtro ed esegue la trasmissione in broadcasts di questi. Ogni Network Manager, che riceve questa trasmissione, associa i propri attributi in un filtro e verifica se corrisponde a quello della query. Se corrisponde, il Network Manager risponde con un filtro leggermente modificato per evitare falsi positivi. I risultati della scoperta sono mappati in oggetti di registrazione, che 90 Beneficiario COLFUTURO 2010

96 vengono restituiti all'applicazione. Questi oggetti forniscono le informazioni grazie a cui l'applicazione può selezionare il fornitore di servizi più appropriato. Questo meccanismo protegge la privacy ed è molto robusto. Se non si vuole utilizzare questo discovery, l alternativa più semplice è quella di utilizzare descrizioni univoche. In questo modo se si cerca un VirtualAddress per descrizione, cu si basa solo sulle informazioni di trasmissione, evitando l'intero processo di discovery.[36] Di seguito si entra nel dettaglio della configurazione di linksmart Installazione e configurazione di Linksmart Esistono diverse versioni di Linksmart, ma in questa tesi ci si è focalizzati su LinkSmart 2.0. La prima cosa che si deve fare è scaricare il pacchetto Linksmart 2.0 dal sito ufficiale di chi ha sviluppato il software: Per permettere di garantire un adeguato livello di sicurezza, LinkSmart fa uso del Java Cryptography Extension per la crittografia. Per abilitare questa funzione, sono necessari i seguenti passi: 1. Scaricare Java Cryptography Extension (JCE) da: -6-download html 2. Decomprimere e copiare i due file local_policy.jar e US_export_policy nella seguente posizione a seconda del sistema operativo: Su Windows, se si dispone di una installazione JDK e JRE, copiare i file su entrambi: - PATH_TO_JDK\jre\lib\security - PATH_TO_JRE\lib\security Su MacOS X, le opzioni di sicurezza dovrebbero essere già adeguate, per come sono fornite con il sistema operativo. 91 Beneficiario COLFUTURO 2010

97 In ogni caso, se ci sono problemi, i file possono essere copiati in: - JAVA_HOME/lib/security Una volta fatta questa prima configurazione, si può eseguire LinkSmart, eseguendo lo script run_linksmart (.bat su Windows oppure.sh su MacOS). A questo punto si può verificare se LinkSmart è in esecuzione accedendo a La schermata che si dovrebbe vedere, se il sistema è correttamente in esecuzione, è la seguente Figura 24: LinkSmart status. L accesso a questa schermata conferma che LinkSmart è in esecuzione sul sistema. Di seguito si descrivono i passi necessari per impostare l'ambiente di sviluppo per LinkSmart. La prima cosa che si deve fare è scaricare Eclipse IDE per Java EE Developers, Dopo aver scaricato e avviato eclipse si prosegue in questo modo, per configurare la target platform, cioè l ambiente di sviluppo che si utilizzerà: 1. Nella workspace selezionare Window-> Preference-> Plug-in development-> Target Platform. 92 Beneficiario COLFUTURO 2010

98 2. Selezionare Add... e quindi l'opzione Nothing (figura 25), e premere Avanti. Figura 25: Configurazione LinkSmart in Ecplise. 3. Scegliere un nome, ad esempio LinkSmart e quindi aggiungere due diverse directory della piattaforma che contengono gli eseguibili di LinkSmart, nell esempio di figura 26 ad esempio sono: a. ${workspace_loc}/opensource/components/target_platform b. ${workspace_loc}/opensource/components/distribution Figura 26: Configurazione LinkSmart in Ecplise - elenco plugin. 93 Beneficiario COLFUTURO 2010

99 Ora è possibile usare questa nuova target platform, al posto di quella predefinita. In questo modo, l ambiente di sviluppo LinkSmart è ora impostato. Si lascia a considerazione del lettore di questa tesi approfondire in aspetti più rilevanti come per esempio la creazione e esecuzione di bundle su linksmart, la configurazione dei servizi che questi possono offrire, ecc. A questo punto, l istanza di LinkSmart può essere configurata attraverso le schermate di configurazione che vengono elencate qui di seguito Linksmart Configurator Si tratta della schermata principale di configurazione e si compone di diverse sottosezioni: eu.linksmart.security.core In questa parte, si può settare il tipo di sicurezza desiderata, che può essere scelta tra: No sicurezza, cifrata, con firma sporadica o solo firma digitale (figura 27). Figura 27: Configurazione eu.linksmart.security.core 94 Beneficiario COLFUTURO 2010

100 eu.linksmart.network In questa parte vengono messi i parametri di rete come per esempio, porta HTTP e porta TCP tra altri, oltre ad alcune configurazioni del NetworkManager. (Figura 28) 95 Beneficiario COLFUTURO 2010

101 96 Beneficiario COLFUTURO 2010

102 Figura 28: Configurazione eu.linksmart.network. eu.linksmart.security.cryptomanager In questa parte vengono messi i parametri utili alla sicurezza come ad esempio la lunguezza delle chiavi che usano i diversi algoritmi di cifratura e scambio di chiave (figura 29). 97 Beneficiario COLFUTURO 2010

103 Figura 29: Configurazione eu.linksmart.security.core. eu.linksmart.security.trustmanager In questa ultima parte, vengono configurati i parametri del TrustManager. 98 Beneficiario COLFUTURO 2010

104 Figura 30: Configurazione eu.linksmart.security.trustmanager Network Manager Status E la parte che permette di verificare lo stato della rete LinkSmart a cui si è connessi. Anche questa parte è divisa in diverse sottosezioni: Network Managers Contiene l elenco dei network managers visibili (figura 31). Figura 31: Visualizzazione Network Managers. 99 Beneficiario COLFUTURO 2010

105 Local HIDs Contiene la lista degli HID dei servizi locali (figura 32). Remote HIDs Figura 32: Visualizzazione Local HIDs. Contiene la lista degli HID dei servizi remote visibili nella rete LinkSmart (figura 33). Figura 33: visualizzatone Remote HIDs. 100 Beneficiario COLFUTURO 2010

106 PARTE 4 VIRTUS 101 Beneficiario COLFUTURO 2010

107 102 Beneficiario COLFUTURO 2010

108 CAPITOLO 4: Middleware VIRTUS In questo capitolo si descrive il middleware VIRTUS, il quale è stato pianificato, progettato e implementato dai ricercatori dell Istituto Superiore Mario Boella, VIRTUS è un middleware IoT-oriented che fornisce una soluzione scalabile, agile, event-driven, per gestire una rete di oggetti eterogenei cooperanti su larga scala che sfruttano tools aperti e standard. Questo middleware attualmente è usato per una grande quantità di applicazione dato che è general purpose, aspetto che favorisce a usarlo in molti applicazioni come per esempio in e-hearth, smart energy, smart transport, smart home, Smart Logistics tra altri. 4.1 Framework e altre tecnologie complementari OSGi Nell architettura del middleware VIRTUS, è stato utilizzato come framework di riferimento OSGi (Open Service Gateway initiative), grazie al quale è stato possibile implementare un modello a componenti, completo e dinamico. OSGi è un sistema modulare dinamico che può essere considerato come un middeware universale. La tecnologia OSGi fornisce agli sviluppatori un ambiente, basato su componenti, e offre modalità standardizzate per gestire il ciclo di vita del software.[37] I componenti del nucleo delle specifiche OSGi sono i moduli e l ambiente di esecuzione. Utilizzando OSGi è possibile gestire in modo automatico le dipendenze (i casi in cui un modulo, per funzionare correttamente, richieda la presenza di un altro modulo) e in modo dinamico il ciclo di vita dei vari componenti software, permettendone l installazione, l avvio, lo stop e la rimozione a run-time, senza, quindi, la necessità di inutili riavvii: Ogni istanza del Middleware è dotata dei soli moduli necessari. È possibile aggiungere ed eliminare dinamicamente delle funzionalità del Middleware senza rilevanti complicazioni. In particolare, i concetti alla base di OSGi, sfruttati per la realizzazione del Middleware, sono: I moduli che sono conosciuti anche come bundle. La gestione automatica delle dipendenze. 103 Beneficiario COLFUTURO 2010

109 La facilità di configurazione. La facilità di distribuzione. In questo modo, si è costruita un architettura modulare, intendendo per moduli delle componenti software in grado di svolgere specifiche funzionalità. OSGi è una soluzione Java e questo è molto importante, perché, grazie a ciò, i moduli sviluppati per VIRTUS sono portabili in tutte le architetture che supportano questo linguaggio di programmazione, senza richiedere modifiche nel codice. La soluzione è modulare, in questo modo, in ogni istanza di VIRTUS, si può creare la propria composizione di sensori, che rilevino i dati, utili alla propria applicazione. A seconda dei moduli che si sceglie di utilizzare, l applicazione potrà servire a controllare i consumi energetici di una casa, tenere sotto controllo la salute di un paziente, controllare i movimenti delle merci all interno di un magazzino, ed a molti altri scopi. Dato l importante uso del concetto di bundle in questo capitolo, è importante definire di cosa si tratti, Un bundle non è altro che un archivio JAR, al cui interno, come da specifiche Java, è presente il file MANIFEST.MF, arricchito però di alcune informazioni, utili al framework, al fine di gestire il pacchetto come un modulo indipendente. Dopo avere analizzato questi aspetti, si prosegue con l analisi del protocollo di instant messaging XMPP, il quale è utilizzato da VIRTUS per stabilire le comunicazione con i suoi componenti Protocollo XMPP Extensible Messaging and Presence Protocol (XMPP) è il protocollo per la messaggistica utilizzato da VIRTUS, è stato scelto perché questo possiede le caratteristiche richieste da un middleware per l IoT, che sono: comunicazione in tempo reale, sicurezza, scalabilità e disponibilità su piattaforme diverse. XMPP è un protocollo aperto e basato su XML per la messaggistica near-real-time, per lo scambio di informazioni di presenza e per servizi di tipo richiesta-risposta. La tecnologia alla base di XMPP, supporta un ampia gamma di applicazioni: instant messaging, informazioni di presenza, multi-party chat, chiamate voce e video.[38] Anche se XMPP non è stato pensato per una architettura specifica, ad oggi viene di solito implementato 104 Beneficiario COLFUTURO 2010

110 attraverso un architettura Client-Server, in cui i client accedono ad un server attraverso una connessione TCP. Ogni utente XMPP per iscriversi ad un server, deve prima registrarsi su di esso creando un proprio account, con username e password. Tale account dovrà essere univoco all interno del server. Una volta iscritto, l utente avrà un proprio JID (Jabber ID) del tipo username@hostname/resource, la parte username@hostname (detto bare JID) è la parte univoca, mentre possono essere connessi contemporaneamente diversi full JID, con uguale bare JID, ma risorse diverse. Una volta iscritto ad un server, un utente può aggiungere altri utenti al proprio roster, per fare ciò, invia una richiesta di sottoscrizione alle presenze, all utente che vuole aggiungere ed aspetta che questo lo autorizzi. Una volta ottenuta l autorizzazione, riceverà le informazioni di presenza dell utente aggiunto. Altra componente essenziale del protocollo base è l invio di messaggi di chat, che oltre ai normali messaggi di testo, possono contenere anche un qualsiasi contenuto XML.[39] Openfire Openfire è il server utilizzato in VIRTUS, si tratta di un server XMPP ampiamente adottato per la messaggistica istantanea, altamente scalabile, è stato scelto per la realizzazione di VIRTUS perché è una soluzione open-source GPL, affidabile e testata, che garantisse l implementazione delle maggior parte delle estensioni XEP (XMPP Extensions Protocols) previste da XMPP, oltre al rispetto della parte base del protocollo. È facile da installare e gestire, offre una sicurezza solida e buone prestazioni, e non rendere troppo complessa l installazione e la gestione del middleware stesso.[40] 105 Beneficiario COLFUTURO 2010

111 Figura 34: Architettura Openfire Knopflerfish Knopflerfish è uno dei principali framework OSGi open-source. portato e mantenuto da Makewave, Knopflerfish offre un valore significativo come tecnologia chiave per molti prodotti tecnologici, cioè le specifiche OSGi R3 e OSGi R4. Knopflerfish implementa tutte le feature obbligatorie ed alcune di quelle opzionali definite nella specifica R4. In particolare Knopflerfish viene utilizzato dal middleware VIRTUS, dato che si adatta molto bene ad essere usato in un middleware per l Internet delle Cose.[41] 4.2 Soluzioni utilizzate per realizzare le funzionalità del Middleware Si entra ora più nel dettaglio dell implementazione di VIRTUS. Per prima cosa, si analizzano le caratteristiche del protocollo di comunicazione XMPP, utilizzato per la comunicazione intra ed extra dominio; dopo, vengono presentate le tecnologie usate per la realizzazione del middleware e la comunicazione con i vari dispositivi (sensori/attuatori) Protocollo di comunicazione Prima di entrare nel dettaglio del protocollo di comunicazione, è importante introdurre un concetto: Quello di istanza di middleware. Si intende per istanza di middleware, un insieme di moduli, residenti su 106 Beneficiario COLFUTURO 2010

112 uno o più dispositivi, che utilizzano, per comunicare, gli stessi componenti base del sistema (server XMPP, gestore, gateway). Quindi, ogni istanza di VIRTUS è formata da: un Server XMPP, un bundle Manager, un bundle Gateway (se è necessario interfacciarsi verso l esterno) ed un certo numero di altri bundle, ognuno con una propria specifica funzionalità. Per quanto riguarda la comunicazione, sia all'interno di una singola istanza di VIRTUS, sia fra istanze diverse, si sfruttano le funzionalità di comunicazione, real-time offerte dal protocollo XMPP. Ogni entità del sistema ha un proprio account XMPP ed, attraverso il meccanismo delle presenze offerto dal protocollo, può rendere nota la propria disponibilità agli altri moduli (bundle), che possono essere interessati ai dati che produce o ai servizi che offre.[42] Nella realizzazione dell architettura di VIRTUS vengono sfruttate altre due funzionalità base del protocollo, cioè: Gli Ad-Hoc Commands, che permettono di fare eseguire delle operazioni ad un altro modulo, facendosi, eventualmente, anche restituire dei risultati. Il design pattern publish-subscribe, che permette ad un modulo di pubblicare degli eventi (eventualmente anche con dati). Gli altri moduli interessati a tali eventi, si possono iscrivere a questi, per ricevere le informazioni pubblicate in tempo reale. Figura 35: Esempio di rete multi dominio. 107 Beneficiario COLFUTURO 2010

113 4.2.2 Tecnologie usate Le tecnologie utilizzate dal middleware VIRTUS per comunicare con i vari dispositivi che possono essere sensori/attuatori, sono molteplici. Bluetooth, ZigBee RFID (con gli standard EPCGlobal ed NFC ed altre sono in corso di integrazione (6LoWPAN, modbus). 4.3 Descrizione della Architettura VIRTUS In seguito viene dettagliata l architettura software e hardware di VIRTUS. Prima viene fornita una descrizione generica dei moduli software che costituiscono un istanza di VIRTUS, poi si entra nel dettaglio dei metodi di comunicazione utilizzati e dell hardware usato per la parte di sensoristica Moduli del sistema Le entità base di un'istanza di VIRTUS sono: Un server XMPP: ogni altra entità locale implementa un client XMPP, che si connette a questo server. Il modulo Manager: si occupa di mettere in comunicazione i vari moduli; infatti, ha nella propria lista di contatti (roster) l elenco completo dei bundle presenti nel sistema. Il modulo Gateway: implementa un client XMPP, che funge da interfaccia (gateway appunto) verso istanze remote di VIRTUS e, più in generale, verso qualunque software esterno che necessiti di comunicare con l istanza locale (ad esempio, perché richiede o eroga servizi). Ogni comunicazione verso l'esterno deve passare attraverso i servizi forniti da questa entità. [43] In Figura 36 si mostra l'architettura multi-dominio usata in VIRTUS. 108 Beneficiario COLFUTURO 2010

114 Figura 36: Esempio di architettura multi-dominio. A queste entità base, di cui tutti i moduli danno per scontata l esistenza, si aggiungono eventuali moduli specifici (ad esempio per gestire un lettore RFID, per interfacciarsi con un sensore di temperatura, ecc.). Questi bundle, all inizio, non sono a conoscenza dei restanti moduli di VIRTUS, ma ne apprendono la presenza tramite il modulo manager. Si entra ora nel dettaglio delle varie modalità di comunicazione usate all interno del sistema e nella comunicazione fra istanze diverse Comunicazione interna ad una singola istanza All interno di una singola istanza, le comunicazioni fra varie entità possono avvenire attraverso tre paradigmi: publish/subcribe (metodo preferenziale per la comunicazione 1 a molti); messaggi di chat (metodo preferenziale per le comunicazioni molti a 1); ed attraverso ad-hoc command (metodo usato per recuperare le informazioni a richiesta). Inoltre, esiste la possibilità di comunicare dei dati utilizzando il meccanismo delle presenze di XMPP Presenze Funzionalità fondamentale del protocollo XMPP, utilizzata all interno di VIRTUS, sia per conoscere la disponibilità di un determinato modulo nel sistema, sia per lo scambio di dati. Le presenze sono sfruttate per fare in modo che, ogni modulo sia sempre a conoscenza dell effettiva situazione dei restanti bundle, all interno del sistema. Ciò è 109 Beneficiario COLFUTURO 2010

115 importante, soprattutto, per quei moduli che dipendono dalla presenza di almeno un bundle di un certo tipo, per funzionare correttamente. Ad esempio, un visualizzatore di dati di temperatura richiede di ricevere i dati da almeno un sensore, per fornire le proprie funzionalità. Grazie alle presenze, il bundle in questione, è sempre in grado di controllare quanti sensori siano attivi nel sistema e, nel caso non ce ne siano, di segnalare l anomalia. Per quanto riguarda lo scambio di dati, si è scelto di non utilizzare l estensione XEP PEP (Personal Eventing Protocol), ma una soluzione più leggera, sfruttando la possibilità di aggiungere uno status testuale alle presenze. Grazie a questa funzionalità, quando un sensore effettua una lettura, invia una presenza, che contiene nello status un timestamp e il valore dell ultimo dato letto. In questo modo, tale informazione è ricevuta da tutti i moduli che hanno quel bundle nel proprio roster (e quindi, in fase di configurazione, hanno indicato di essere interessati ai suoi dati) e resta come status del bundle fino alla lettura di un nuovo dato; quindi è facilmente reperibile, anche in un secondo momento. Ad esempio, i reader inseriscono l ID dell ultimo tag letto; i sensori di temperatura, l ultima temperatura rilevata e così via. Bisogna sottolineare che lo scambio di informazioni, effettuato utilizzando lo status delle presenze, non è un metodo di comunicazione standard del protocollo, ma è unicamente una soluzione standardizzata per la comunicazione tra i vari moduli del Middleware. In futuro, se si scegliesse, invece, di passare ad utilizzare la soluzione PEP, per motivi di compatibilità verso altre soluzioni, il passaggio fra le due modalità di trasferimento dati, sarebbe facilmente realizzabile, senza importanti modifiche nel codice dei vari bundle. Infatti, i dati, all interno di VIRTUS, sono tutti incapsulati in estensioni XML, quindi facilmente utilizzabili anche nell estensione XEP Publish/subscribe Estensione XMPP che permette di inviare e ricevere eventi in modo asincrono disaccoppiando mittente e destinatario. In questa modalità di comunicazione, i moduli possono avere due ruoli: publisher e subscriber (anche se nulla vieta che un modulo sia al tempo stesso, 110 Beneficiario COLFUTURO 2010

116 sia l uno sia l altro). I publisher inviano i propri eventi su nodi di pub/sub, creati secondo una certa gerarchia predefinita, i subscriber si iscrivono ai nodi, su cui vengono pubblicati gli eventi di proprio interesse, e vengono notificati automaticamente, ogni volta che viene pubblicato un nuovo evento. In questo modo è possibile avere una comunicazione con le seguenti caratteristiche: asincrona: il publisher invia i propri dati e non deve aspettare la conferma che questi siano ricevuti; allo stesso modo il subscriber può continuare a svolgere i propri compiti, mentre aspetta di ricevere la notifica di qualche evento pubblicato; con disaccoppiamento tra mittente e destinatario: il publisher pubblica i suoi dati senza essere tenuto a sapere chi li riceve, ed allo stesso modo i subscriber non sono tenuti a sapere a priori (in modo hard coded ) da chi riceveranno i dati. Ciò permette di aggiungere mittenti e destinatari a run-time, senza la necessità di modificare il codice; con disaccoppiamento temporale tra mittente e destinatario: non c è stretta necessità che publisher e subscriber siano contemporaneamente online, per permettere lo scambio di dati. Se il subscriber è offline al momento della pubblicazione di un evento da parte del publisher, potrà recuperare l evento quando tornerà online. Allo stesso modo, l evento potrà essere recuperato, anche se in quel momento il publisher non è più disponibile. Il protocollo XMPP prevede due tipi di nodi: i nodi foglia ed i nodi collezione. Entrambi questi nodi vengono utilizzati in VIRTUS. In particolare, i nodi foglia rappresentano i nodi base su cui avviene la sottoscrizione e la pubblicazione di eventi, quelli collezione, invece, consentono di raccogliere diversi nodi foglia. Il vantaggio di questi ultimi è che, registrandosi come subscriber di un nodo collezione, si ricevono gli eventi di tutti i nodi foglia contenuti in esso (con una sola sottoscrizione). Dal punto di vista realizzativo, si è pensato di adottare una struttura dei nodi a tre livelli: Livello 1: Nodi collezione per tipologia (es. reader RFID, sensori di temperatura, ecc.); Livello 2: Nodi collezione per locazione (es. stanza1, stanza2, ecc.); Livello 3: Nodi foglia su cui vengono pubblicati i dati del modulo 111 Beneficiario COLFUTURO 2010

117 vero e proprio. In Figura 5 un esempio di gerarchia: A livello 1 il nodo collezione reader. A livello 2 il nodo collezione unknown_reader, che contiene i nodi foglia dei reader per cui non è specificata una specifica locazione; ed il nodo collezione stanza1_reader, che contiene i reader che si trovano nella stanza denominata stanza1. A livello 3 i nodi foglia dei 3 reader. Figura 37: Esempio di gerarchia dei nodi di pubsub. Questo consente ad un modulo del Middleware con delle dipendenze, di registrarsi come subscriber al livello di maggiore interesse Messaggi di chat All interno di VIRTUS, i messaggi di chat sono utilizzati come un metodo di comunicazione tra moduli, alternativo al pub/sub. Questa modalità è utilizzata nei casi di moduli centralizzati, che ricevono eventi da più mittenti (comunicazione molti a uno). Generalmente, si tratta di quei moduli che si occupano della gestione del database e quindi devono inserire in un unico database centralizzato, i dati prodotti dai vari sensori di un certo tipo. In questo caso, non serve che mittente e destinatario siano disaccoppiati, perché ci sarà solo un 112 Beneficiario COLFUTURO 2010

118 modulo previsto per accorpare i dati dei vari sensori, i quali, di conseguenza, possono essere programmati per inviare dati ad un modulo di quel tipo Ad-hoc commands Metodo di comunicazione che permette di scambiare dati in modalità richiesta/risposta e richiedere l esecuzione di un azione ad un bundle. Per questa modalità di comunicazione, ogni modulo pubblica, all interno di VIRTUS, la lista dei comandi che supporta, fornendo un nome con cui richiamare il comando ed una breve descrizione dello stesso. Questi comandi possono avere diversi scopi: Alcuni sono comuni a tutti i bundle (stop, riavvio, riconfigurazione). Altri sono specifici, come ad esempio, recuperare l ultima lettura effettuata, richiedere di eseguire una certa lettura non programmata, cambiare una certa configurazione nel sensore controllato, ed altri ancora. Si possono avere due tipi di comandi: mono-stage e multi-stage; in entrambi i casi, lo scambio di informazioni per il passaggio dei parametri e la restituzione dei dati, avviene attraverso il passaggio di data-forms (XEP-0004 del protocollo XMPP). 4.4 Comunicazione multi-dominio Quasi tutte le modalità di comunicazione previste all interno del singolo dominio, sono state estese anche nell ambito extra-dominio. In questo caso, per tutte le comunicazioni, si sfrutta la presenza del gateway, che è il punto di interconnessione del middleware verso l esterno. Per permettere la comunicazione multi-dominio, è presente un server XMPP globale, su cui tutti i gateway hanno un proprio account. In questo modo, i gateway possono comunicare tra di loro, rendendo possibile l interazione tra moduli, appartenenti a domini diversi. La comunicazione multi-dominio non è una funzionalità mandatoria di una istanza di VIRTUS. Possono esserci domini, che non necessitano di comunicare con l esterno. In questo caso, il 113 Beneficiario COLFUTURO 2010

119 gateway non è necessario e, quindi, può anche non essere installato in tali istanze. [44] Presenze Tutti i moduli presenti nel sistema, all avvio, devono aggiungere nel proprio roster il gateway (se presente), oltre al manager. In questo modo, il gateway riceve le presenze di tutti i bundle all interno dell istanza di VIRTUS a cui appartiene ed è in grado di propagarle verso l esterno. Si è scelto di realizzare ciò, creando un nodo di pub/sub sul server globale, su cui i gateway pubblicano le presenze che ricevono in locale. In questo modo, un bundle in un istanza di middleware, che è interessato alle presenze di moduli presenti in un altra istanza, deve semplicemente iscriversi a questo nodo, seguendo il paradigma di publish/subscribe multi-dominio Publish/subscribe Il funzionamento è simile a quello descritto all interno di una singola istanza, con la differenza dell interazione dei gateway. Si illustra il funzionamento usando un esempio pratico nel quale si ha: Un modulo X nel middleware A, pubblica i suoi dati verso l esterno. Un modulo Y nel middleware B, è interessato a ricevere tali dati. In questo caso, i passaggi sono i seguenti 1. il modulo X, all avvio, indica al gateway A di voler pubblicare i dati verso l esterno. 2. Il gateway A crea un nodo di pub/sub per il bundle X sul server globale (senza replicare la gerarchia di nodi collezione, creata in locale) e si iscrive al nodo di pub/sub locale del bundle X. In questo modo, ogni volta che X pubblica un evento sul nodo locale, questo viene ricevuto dal gateway A e inoltrato immediatamente sul nodo globale. 3. Il bundle Y indica al gateway B di voler ricevere i dati di X. 4. Il gateway B si iscrive al nodo di X sul server globale e crea un nodo di pub/sub per gli eventi di X in locale (ovviamente nel middleware B). Fatto ciò, quando il gateway A inoltra l evento di X 114 Beneficiario COLFUTURO 2010

120 sul nodo globale, questo viene ricevuto dal gateway B, che gira l evento sul nodo locale e di conseguenza l evento pubblicato arriva ad Y. Lo schema in Figura 38 illustra quanto spiegato in precedenza. [45] Ad-hoc commands Figura 38: Esempio di pub/sub extra-dominio. Il funzionamento è molto simile a quello descritto per gli ad-hoc command all interno della singola istanza, con la differenza che, trattandosi di un operazione multi-dominio, richiede l intervento del gateway. Si illustra il funzionamento usando un esempio pratico nel quale si hanno: Due istanze di Middleware: A e B. Un modulo Y nell istanza B, esporta un ad-hoc command. Un modulo X nell istanza A, deve richiamare il comando getinfo del modulo Y. Per consentire a X di eseguire un comando su un modulo (Y) in un dominio diverso (B), il gateway A esporta un callremotecommand verso il suo server interno. Il modulo locale X chiama questo 115 Beneficiario COLFUTURO 2010

121 comando, passando, come parametri, il nome dell'ad-hoc Command remoto da richiamare (in questo caso getinfo), il modulo su cui richiamarlo (Y) e il Middleware remoto (B) che contiene il modulo. X@A -->callremotecommand(b,y,getinfo)-->gateway@a A questo punto il gateway di A chiama il comando sul gateway di B. Quest ultimo, sfruttando la propria interfaccia locale, chiama il comando sul modulo che lo esporta all'interno di VIRTUS. Analogamente la risposta di Y farà il percorso inverso. Lo schema in Figura 39 illustra quanto spiegato in precedenza. Figura 39: Esempio di ad-hoc command extra-dominio. 4.5 Componenti software della soluzione In questo capitolo, inizialmente vengono presentati i moduli software usati all interno di VIRTUS, descrivendone le funzionalità. In seguito, si descrive come questi moduli possono essere assemblati per formare un istanza di VIRTUS. Infine, si discute di come un istanza di VIRTUS non sia una realtà chiusa, ma al contrario, come possa interconnettersi con altri middleware o servizi di terze parti, scritti ad hoc, oppure già esistenti. 116 Beneficiario COLFUTURO 2010

122 4.5.1 Manager Il Manager è il modulo che si occupa di mettere in comunicazione, fra loro, i vari bundle, sfruttando la conoscenza completa delle entità presenti. E al corrente di tutti i moduli del sistema, perché (al primo avvio) assegna loro lo username definitivo, che verrà utilizzato da quel momento in poi per connettersi al server XMPP. Come già detto, ogni modulo presente in VIRTUS può avere delle dipendenze: per esempio, un modulo logger, per svolgere il proprio compito, ha la necessità di un modulo che generi degli eventi da memorizzare. La gestione delle dipendenze avviene mediante dei comandi ad-hoc offerti dal Manager. Attraverso tali comandi, il Manager fornisce, al modulo che la richiede, una lista dei moduli di un certo tipo, disponibili, in quel momento, in VIRTUS. Inoltre, permette di effettuare tutte le operazioni di configurazione necessarie, per poter utilizzare tali moduli. Il modulo Manager ha un ruolo anche per quanto riguarda il pub/sub. Infatti, si occupa della creazione dei nodi collezione di Publish/Subscribe all interno di un istanza di VIRTUS. Infatti, il Manager è responsabile di costruire e tenere aggiornata la gerarchia dei nodi di pub/sub. La creazione dei nodi foglia, invece, è demandata al bundle che pubblicherà i dati su quel nodo, questo perché, come proprietario del nodo, avrà dei diritti particolari su di esso. Dopo aver creato un nuovo nodo foglia, ogni bundle richiamerà un ad-hoc command del Manager, indicando i propri dati identificativi: tipologia di bundle (reader, sensore) ed eventualmente la propria locazione. In questo modo, il manager sarà in grado di verificare la presenza dei nodi collezione, in cui il nodo foglia andrà inserito. Se sono già presenti, inserirà il nodo foglia nel nodo collezione di livello 2; in caso contrario, prima dell inserimento, creerà i nodi collezione mancanti Gateway Implementa un client XMPP, il quale funge da interfaccia verso un ulteriore istanza (remota) di VIRTUS e, più in generale, verso qualunque software esterno che necessiti di comunicazione con l istanza locale. Ogni interazione verso l'esterno deve passare attraverso i servizi forniti da questo modulo. Di conseguenza, questa, è l'unica entità visibile direttamente da altri. Per questo suo scopo di 117 Beneficiario COLFUTURO 2010

123 intermediario, ha due connessioni XMPP attive: una sul server locale per comunicare con i moduli interni a VIRTUS e una su un server pubblico per comunicare con i Gateway degli altri domini. Il modulo Gateway ha un ruolo anche durante la configurazione dei moduli. In particolare, offre alcuni ad-hoc command, che possono essere richiamati, in fase di configurazione, dai bundle, per rendere disponibili verso l esterno, gli eventi che generano (Pub/Sub) o i comandi che esportano (comandi Ad-Hoc). Quando un bundle, durante la propria fase di configurazione, richiama l ad-hoc command del Gateway, per indicare di voler pubblicare i propri eventi verso l esterno, il Gateway provvede a replicare il nodo di pub/sub locale sul server globale; in seguito, inoltrerà sul nodo creato, tutti gli eventi pubblicati da quel modulo in locale. Invece, per quanto riguarda gli ad-hoc commands, quando un bundle indica che vuole renderli disponibili globalmente, il Gateway li aggiunge alla lista di comandi che esporta verso l esterno del VIRTUS, e da quel momento saranno richiamabili da remoto attraverso la sua intermediazione Altri bundle Ogni modulo presente in VIRTUS realizza delle funzioni specifiche e può importare/esportare servizi da e verso gli altri moduli. Ogni modulo può possedere una lista di dipendenze, obbligatorie per il suo corretto funzionamento. Queste dipendenze si traducono nella necessità di avere all interno del sistema almeno un modulo che fornisca i servizi richiesti. Un esempio di modulo locale è il modulo sensore di temperatura che gestisce la connessione ad un sensore, pubblica le letture fatte tramite Pub/Sub ed esporta eventuali Ad-Hoc Commands per la sua gestione ed interrogazione Modularità della soluzione L architettura progettata permette di adattarsi a diversi tipi di applicazioni, senza modificare le caratteristiche del sistema, ma, semplicemente, modificando i moduli presenti nell istanza di VIRTUS. I moduli che formano il nucleo della soluzione, mandatori per ogni istanza di VIRTUS, sono Manager e Gateway (quest ultimo solo nel caso di necessità di comunicazione fra domini diversi). Tutti gli altri moduli sono facoltativi, e possono essere installati per formare la configurazione desiderata di VIRTUS. 118 Beneficiario COLFUTURO 2010

124 Ad esempio, per utilizzare VIRTUS con finalità di logistica, andranno installati: I moduli che gestiscono i reader RFID e pubblicano i report di lettura. Un modulo che riceve le letture effettuate, le interpreta, e presenta all utente un interfaccia grafica, per visualizzare le informazioni ricavate. Ad esempio, fornendo la situazione dei prodotti in un magazzino.[46] La stessa istanza di VIRTUS, può essere utilizzata per monitorare i dati di temperatura del magazzino, installando: Il modulo che gestisce i sensori e pubblica su un nodo di pub/sub i dati di temperatura, come messaggi XMPP. Un modulo che riceve i valori di temperatura, e visualizza tali dati in un interfaccia user friendly. In questo modo, ognuno può creare la propria versione del sistema, con i soli servizi che interessano, senza funzionalità superflue ed inutili per i propri scopi Interfacciamento verso altre soluzioni Anche se la soluzione proposta ha tutte le proprietà descritte in precedenza, non è immaginabile che sia l unica utilizzata nell ambito di riferimento dell Internet of Things. Infatti, ci sono già altre soluzioni presenti sul mercato, che utilizzano la più tradizionale architettura SOA (Service Oriented Architecture). Conservare la compatibilità verso tali soluzioni, permette di non limitare le potenzialità di diffusione di VIRTUS. Questo perché, si può pensare di rivolgersi anche a quegli utenti che utilizzano già un middleware basato su SOA, offrendogli la possibilità di utilizzare le funzionalità di VIRTUS, in coabitazione con il sistema già in uso, prima di effettuare una scelta fra i due. Per questi motivi, un altra proprietà di VIRTUS deve essere la capacità di interfacciarsi con altre soluzioni, soprattutto quando queste usano architetture e metodi di comunicazione diversi. A questo scopo, il VIRTUS è in grado di interfacciarsi con varie soluzioni che utilizzano web service, utilizzando il Gateway con ruolo di interprete tra XMPP e Web Service. 119 Beneficiario COLFUTURO 2010

125 Utilizzando questa soluzione, i moduli di VIRTUS sono abilitati a consumare Web Service esportati da moduli di sistemi di terze parti e esportare proprie funzionalità attraverso Web Service. [47] Nella Figura 40 viene mostrata l architettura di comunicazione, prevista per l interazione con una piattaforma SOA, utilizzando questo approccio. Figura 40: Architettura di comunicazione tra piattaforme. Le entità centrali di tale architettura sono i due gateway. Questi moduli sono in grado di comunicare fra di loro, utilizzando entrambi i sistemi di comunicazione (XMPP/Web Service) mentre, all interno della singola piattaforma, si continuerà ad utilizzare un unico protocollo. Il Gateway di VIRTUS, per poter svolgere questo compito, implementa un client HTTP, attraverso cui può invocare Web Service di tipo REST (Representional State Transfer). Questo protocollo permette, infatti, di identificare i Web Service con URI universali e di comunicare con essi, utilizzando i tipici metodi HTPP (GET, PUT, POST). Dal punto di vista della piattaforma SOA, ogni nodo deve essere virtualizzato con un Web Service con interfaccia REST. I moduli 120 Beneficiario COLFUTURO 2010

126 VIRTUS possono iscriversi, attraverso il Gateway, agli eventi di questi nodi. Per effettuare l iscrizione, il Gateway invoca un Web Service, passando come parametro, l endpoint di un socket TCP, su cui riceverà gli aggiornamenti di tale servizio. Dal momento dell iscrizione in poi, tutti gli eventi ricevuti, saranno inoltrati dal Gateway su nodi di pub/sub locali, a cui si saranno iscritti i moduli VIRTUS interessati. Si è scelto di prevedere questa soluzione, perché vicina all approccio event-driven adottato all interno del middleware VIRTUS. Scegliere, invece, di interrogare ad intervalli regolari il servizio REST per recuperare gli aggiornamenti, non sarebbe stata una soluzione coerente con la filosofia adottata nelle altre parti del sistema. Allo stesso tempo, dalla piattaforma SOA, è possibile ricevere aggiornamenti da moduli appartenenti a VIRTUS. A questo scopo, si sfruttano il paradigma pub/sub di XMPP ed i nodi pubblici, utilizzati anche per la comunicazione inter-dominio, fra diverse istanze di VIRTUS. Il Gateway della piattaforma SOA, effettua l iscrizione ai nodi di pub/sub globali, dei moduli a cui è interessato. Gli eventi ricevuti, attraverso il paradigma di pub/sub XMPP, verranno inoltrati all interno del sistema, utilizzando la comunicazione attraverso Web Service. 4.6 Interfaccia Utente PIC Innovative Platform for the Internet of Things è l Interfaccia utente progettata per gestire differenti servizi per l Internet of Things da un unico punto di accesso. Attraverso l interfaccia, l utente è in grado di configurare e gestire la propria istanza di VIRTUS, installando solo i servizi utili ai propri scopi. L interfaccia offre diverse funzionalità per la creazione di servizi per IoT come ad esempio: la configurazione di parametri dell istanza, quali server XMPP locale e globale; indicazione dello stato di connessione al server XMPP; gestione dei bundle di sistema e dei servizi; download, installazione, rimozione, avvio, arresto e configurazione di un bundle; indicazione dello stato corrente di un bundle, download componenti aggiuntive di un bundle e gestione degli aggiornamenti Configurazione del software PIC è un modulo che viene eseguito all interno del framework Knopflerfish. La procedura di installazione è stata progettata per 121 Beneficiario COLFUTURO 2010

127 assistere e guidare l utente nelle differenti operazioni di configurazione. Appena avviato, il software legge il proprio file xml di configurazione e ne carica i valori predefiniti. Uno di questi valori è il percorso web da cui scaricare un file xml, che contiene l elenco dei servizi disponibili per l installazione nel sistema e i relativi moduli. Dopo aver letto il file di configurazione, il software cerca di accedere al percorso configurato, per scaricare il file dei servizi. In caso di errore, segnala l anomalia all utente, mentre, se non si riscontrano problemi, si avvia, presentando la schermata di configurazione iniziale, illustrata in Figura 41. Figura 41: Schermata iniziale PIC. Il form che si vede nella figura 41, serve per inserire/modificare e salvare i campi del file xml di configurazione. E da segnalare che alcuni valori non sono modificabili, in quanto sono prodotti automaticamente dal sistema. Terminata con successo questa configurazione, il software prova a collegarsi al server XMPP locale. Se la connessione non viene stabilita con successo, il software mostra all utente una schermata con un messaggio di errore (figura 42). In questo caso, l utente può riprovare a connettersi al server, oppure accedere di nuovo alla schermata di configurazione iniziale, per modificare eventualmente le impostazioni precedentemente inserite. Figura 42: Connessione server XMPP non stabilita. 122 Beneficiario COLFUTURO 2010

128 Figura 43: Server XMPP stabilita con successo. Una volta effettuata con successo la connessione (Figura 43), l utente ha accesso a tutte le funzionalità dell applicazione. L interfaccia espone una toolbar, illustrata in Figura 44, attraverso la quale si può scegliere se visualizzare o nascondere, rispettivamente, le diverse parti dell interfaccia. Figura 44: Toolbar per accedere alle differenti funzionalità disponibili. Nei prossimi paragrafi, si entrerà in dettaglio delle funzionalità offerte all utente Bundle del sistema Attraverso l interfaccia PIC, l utente è in grado di personalizzare la propria istanza di VIRTUS, installando e configurando, fra quelli disponibili, solo i servizi utili ai propri scopi. Inoltre, sempre attraverso l interfaccia, l utente avrà a disposizione la condizione, aggiornata in tempo reale, dei moduli del sistema. PIC consente di gestire due tipologie distinte di moduli: quelli di sistema, la cui installazione è obbligatoria, e quelli opzionali. I bundle di sistema (Figura 45) sono quelli obbligatori per il funzionamento di un istanza di VIRTUS: si tratta del modulo Manager e del modulo Gateway. I moduli opzionali, invece, comprendono tutti i restanti bundle, ognuno con una propria funzionalità, che permettono di comporre la propria istanza di VIRTUS. Si entra ora nel dettaglio delle varie funzionalità implementate per la gestione del ciclo di vita dei singoli moduli, di entrambi i tipi. 123 Beneficiario COLFUTURO 2010

129 Figura 45: Elenco dei moduli obbligatori. Per i moduli di sistema le operazioni consentite sono: installazione, avvio, aggiornamento e stop. Quando l utente preme il pulsante Download in corrispondenza di un modulo di sistema, tale modulo viene scaricato dal percorso indicato nel file xml, e immediatamente avviato; l icona visualizzata nella colonna Status passa a Installed, e si ha l indicazione che il modulo è avviato (l icona nella colonna Running è diventata verde). A questo punto, premendo il pulsante Stop l utente può fermare l esecuzione del modulo. Figura 46: Moduli obbligatori. Infine, quando è disponibile online una versione aggiornata del modulo installato, l icona Status passa a Installed to update e il pulsante Update diventa attivo. Una volta premuto il tasto Update, il software disinstalla automaticamente il modulo precedentemente installato e lo sostituisce con quello nuovo, disponibile online Bundle opzionali Nel caso dei bundle non di sistema, la gestione del ciclo di vita è maggiormente complessa, rispetto a quella dei moduli obbligatori. I moduli opzionali sono impiegati all interno dei Servizi. Ogni servizio è composto dall insieme dei moduli che concorrono a realizzare una 124 Beneficiario COLFUTURO 2010

130 determinata funzione (per esempio il monitoraggio energetico, il monitoraggio dei parametri ambientali, etc.). Quando l utente decide di installare un servizio fra quelli disponibili, per prima cosa deve eseguire la configurazione del servizio desiderato; questo avviene premendo il tasto Configure del servizio scelto. Figura 47: Elenco dei moduli opzionali del servizio Energy. Una volta effettuata questa prima configurazione, l utente può installare i moduli che compongono il servizio. Di seguito per meglio spiegare il funzionamento,si prende come esempio la gestione del bundle energy_sensor, quello che permette la gestione di una o più smart-plug per il controllo dei consumi energetici, per descrivere la gestione del ciclo di vita di uno specifico modulo. Figura 48: Configurazione del servizio Energy. Per prima cosa bisogna configurare il servizio che comprende il bundle, questo lo si fa premendo il tasto Configure corrispondente al servizio energy. La Figura 48 mostra il form che viene presentato all utente per configurare il servizio; tale form permette di inserire 125 Beneficiario COLFUTURO 2010

131 un informazione di localizzazione (stanza, salotto, etc.) e di scegliere la modalità di funzionamento del servizio tra quelli disponibili: Without Logger, Local, Remote e Remote and Local. Finita la configurazione del servizio, l utente può procedere a configurare i moduli che lo compongono. A questo punto, come prima operazione, l utente deve premere il tasto Download, per scaricare il file JAR del bundle energy-sensor, da installare nel sistema. nella Figura 49 si vede la schermata del PIC dopo l installazione del bundle, si può notare come il pulsante che prima indicava Download, ora presenti la scritta Remove, lo status del bundle sia Installed, l icona Running sia verde (perché il bundle, appena scaricato, è avviato automaticamente ed entra in uno stato di attesa della configurazione, senza svolgere le proprie funzioni) ee come sia stato abilitato il tasto Configure. Figura 49: Download del bundle energy_sensor. Figura 50: Pannello Load Configuration. Subito dopo aver effettuato il download del modulo, l utente può eseguirne la configurazione, premendo il tasto Configure. Cliccando su quest ultimo tasto, all utente viene chiesto se desidera caricare la configurazione da file XML, in cui sarà stata salvata, da sessioni precedenti, oppure inserirla manualmente (Figura 50). Se l utente 126 Beneficiario COLFUTURO 2010

132 sceglie la seconda opzione, viene visualizzata la maschera di inserimento dei dati, con i campi vuoti (Figura 51). Se invece sceglie di caricare il file, allora ha a disposizione la finestra di ricerca file nel sistema, per individuare il file di configurazione desiderato e caricarlo. Una volta scelto il file, le configurazioni in esso contenute, vengono caricate e presentate all utente, con la stessa maschera per l inserimento manuale; in questo modo l utente può modificare i dati caricati, se lo ritiene utile, oppure semplicemente confermare la configurazione. Figura 51: Energy Sensor Configuration. Figura 52: Energy Sensor Configuration Secondo livello. 127 Beneficiario COLFUTURO 2010

133 Nella figura 52 viene presentata la schermata di configurazione di secondo livello, alla quale si accede selezionando New dalla schermata della Figura 51, oppure scegliendo uno dei sensori presenti nella lista. Questa schermata è utile per quei campi che richiedono la configurazione di ulteriori sottocampi. Per esempio, in questo caso si tratta della lista dei sensori controllati, che richiedono l inserimento dei pametri per ogni sensore. In particolare, campi visualizzati sono: il nome del sensore; il protocollo di comunicazione; l intervallo di lettura; la porta di comunicazione; l indirizzo fisico del sensore. E da segnalare che la maschera di inserimento della configurazione è generata dinamicamente, tramite un protocollo ad-hoc progettato a tale scopo. Dopo che l utente ha salvato la configurazione, questa viene inviata al bundle in oggetto, il quale verifica la correttezza dei dati inseriti. Se la configurazione contiene eventuali errori, questi sono segnalati attraverso una Message Box (Figura 53) e all utente è richiesto di correggere i valori inseriti. Figura 53: Energy Sensor Configuration Errore per il campo MAC Address. Una volta inserita una configurazione corretta, all utente viene data una conferma del successo dell operazione ed il bundle viene avviato ed inizia il suo normale funzionamento. A questo punto, l utente ha a disposizione diversi comandi (Start, Stop, Configure, Remove e Update), per controllare il ciclo di vita del modulo installato. I moduli possono essere installati in qualsiasi ordine, e si può lavorare in parallelo su diversi bundle (per esempio, si può effettuare il download di tutti i bundle e poi procedere alle configurazioni). E importante notare, inoltre, come l interfaccia sia in grado di reagire ai cambiamenti di stato dei moduli installati nel sistema. Se un bundle si ferma a causa di qualche errore, oppure il suo stato cambia perché l utente ha utilizzato un altro software per interagire con esso, l interfaccia riflette in tempo reale il cambiamento avvenuto. 128 Beneficiario COLFUTURO 2010

134 4.6.4 Aggiornamenti e Legenda Gli aggiornamenti sono gestiti in modo automatico dal sistema, che l ne controlla la disponibilità periodicamente. Inoltre, nella toolbar si può usare un pulsante per forzare il controllo di eventuali aggiornamenti, disponibili per i moduli installati. Qualora sia disponibile online una versione aggiornata di uno o più bundle, le icone nella colonna Status riporteranno l informazione Installed to update e saranno attivi anche i tasti Update. Una volta premuti i tasti, i bundle installati saranno rimossi e sostituiti da quelli più aggiornati. Nella figura 54 viene mostrata la legenda che fa parte dell interfaccia del PIC e rappresenta i vari stati in cui possono trovarsi i vari bundle: To install quando non è ancora installato; Installed quando è installato ma non configurato; Installed with errors quando è installato, non configurato ma presenta dei problemi, Installed to update quando è disponibile online una versione più recente di quella installata, Running quando il bundle è correttamente avviato, Not running se è stato stoppato. Figura 54: Legenda status bundle. In questa parte del capitolo sono state illustrate le funzionalità principali del PIC, che erano già presenti prima dell inizio di questa tesi; in seguito verranno dettagliati le funzionalità introdotte con questo lavoro di tesi. 4.7 Sviluppi introdotti In quest ultima parte, si descrivono gli sviluppi introdotti al middleware VIRTUS per ottenere gli obiettivi prefissati per questa tesi dopo di avere eseguito la fase di studio evidenziata nei capitoli precedenti. Si è deciso di concentrare gli sviluppi sulla funzionalità di configurazione dinamica di applicazioni multi-dominio, cioè quelle in cui devono comunicare tra loro moduli appartenenti ad istanze di middleware diverse, questo perché la funzionalità non era ancora 129 Beneficiario COLFUTURO 2010

135 presente nel sistema di configurazione di VIRTUS. Oltre ad aggiungere questa feature, nello stesso contesto, è stato implementato anche un sistema di discovery (simile a quello descritto per LinkSmart), per permettere di scoprire quali sensori sono presenti in un istanza remota di VIRTUS e scegliere quelli che interessano per completare la configurazione della propria applicazione. Quest ultima parte è stata realizzata attraverso l uso del protocollo XMPP, protocollo di messaggistica istantanea open, utilizzato in VIRTUS per la comunicazione tra le varie entità. L obiettivo in questi sviluppi è di permettere la configurazione remota, in cui cioè il modulo che controlla i sensori che producono i dati si trovano in un istanza di middleware diversa rispetto a quello in cui si trova l applicazione che riceve i dati. Come demo verrà utilizzato il servizio temperature, che serve come proof-of-concept per il controllo di sensori remoti, che prevede il bundle temperature-sensor installato in un istanza ed il bundle temperature-logger installato in un altra. Il servizio temperature andrà installato con Mode = Remote. Una volta installato il modulo temperature-logger, mentre lo si configura dovrà essere possibile indicare da quali sensori l applicazione dovrà prendere i dati. Sono possibili due tipi di configurazioni: 1. Se si conosce già il nome dei sensori da cui prendere i dati, dovrà essere possibile inserire direttamente nel modulo di configurazione del logger, i nomi dei sensori ed il middleware di appartenenza. 2. Se invece non si sa quali sono i sensori, ma si sa solo il middleware di appartenenza. Dovrà essere possibile fare un discovery dei sensori presenti di un certo tipo su un istanza di middleware, indicando il suo nome. Una volta ritrovata la lista dei sensori presenti sul middleware remoto dovrà essere possibile scegliere a quali iscriversi Configurazione dell ambiente Come configurazione iniziale si sono dovuti installare i 2 server utilizzati da VIRTUS, il primo è Openfire, il quale gestisce la messaggistica usando il protocollo XMPP, e il secondo è Apache Tomcat7 il quale è un web server dove si mettono sei file: 130 Beneficiario COLFUTURO 2010

136 Un file.xml, il quale serve per essere caricato dal file di configurazione del middleware e rendere attivi e disponibile i tasti sul PIC. Un file.txt, in questo file c è la versione del file xml che serve al PIC per gestire i suoi aggiornamenti. Per questo particolare servizio poi si sono aggiunti quattro bundle.jar, questi sono i bundle necessari per lanciare VIRTUS, Manager e Gateway sono i mandatori e gli altri due sono il Logger e il Sensore. Figura 55: File in server web. In Figura 27 viene illustrato il file configurazione iniziale del PIC con i dati più rilevanti, che viene utilizzato per generare la sua interfaccia. 131 Beneficiario COLFUTURO 2010

137 Figura 56: Informazione su ConfigPrimoBundle.xml Configurazione di eclipse e Knopflerfish Per quanto riguarda all ambiente di sviluppo e programmazione del codice si è usato ECLIPSE, il quale è un progetto open source, modulare e utile per facilitare la scrittura e l esecuzione dei programmi in java. Contiene un editor di testo, permette la compilazione diretta dei file, fornisce utili strumenti per muoversi nel codice e per ricercare gli errori. Eclipse viene eseguito congiuntamente con java v7.0. Come detto in precedenza, VIRTUS viene eseguito usando Knopflerfish come framework di riferimento, per questo si deve integrare Eclipse con Knopflerfish e per fare questo si deve installare il Knopflerfish Eclipse Plug-in, il quale è uno strumento per il lancio e il debug della distribuzione Knopflerfish OSGi. 132 Beneficiario COLFUTURO 2010

138 Per fare ciò si scarica il plugin e si installa, dopo si configurano Bundle repositories, Environments e Framework. Figura 57: Framework knopflerfish installato in eclipse. Dopo avere descritto questa fase di configurazione iniziale, si prosegue a descrivere a livello generale le modifiche e aggiunte fatte. Nel paragrafo 4.9 vengono riportati i codici più rilevanti. 133 Beneficiario COLFUTURO 2010

139 PIC come era inizialmente prima degli sviluppi (Figura 58) Remote Figura 58: Prima di aggiungere le modifiche. 134 Beneficiario COLFUTURO 2010

140 4.7.3 Operazioni compiute Di seguito si indicano i principali passi compiuti, per soddisfare gli obiettivi proposti in questa tesi. 1. Si è modificato il metodo getconfigurationform, che serve a generare il form di configurazione di energy_logger, in modo che, in caso di servizio configurato per funzionare in remoto, oltre alla location restituisca anche un campo con le dipendenze remote. In questo modo, l utente può inserire le i bundle che gli servono utilizzando i metodi che sono spiegati nel paragrafo seguente. 2. Ogni dipendenza è stata caratterizzata dai seguenti campi: Remote Dependency Name, è il nome univoco che identifica la dipendenza; primaryfeature è il tipo di bundle a cui si è interessati (ad esempio urn:xmpp:energy-sensor, identifica i bundle che controllano sensori di tipo smart-plug); mw è il nome dell istanza di VIRTUS su cui si vogliono recuperare i dati; mwdescription è la descrizione di questa istanza ed infine bundle è l identificativo del bundle. 3. Si è provveduto a fare in modo che i dati di queste dipendenze remote, vengano caricate e salvate nel file xml, di configurazione del bundle. In questo modo, la configurazione effettuata viene salvata nel bundle stesso e non viene persa al riavvio dell applicazione, che ripartirà restando collegata agli stessi sensori remoti configurati la prima volta (può essere ovviamente cambiata in qualsiasi momento). 4. In PicBundle, si sono effettuate delle modifiche, per fare in modo che la configurazione delle dipendenze remote fosse possibile solo se la modalità configurata per il servizio è Remote o Remote and Local; nascondendo tale configurazione in caso di servizio Local (infatti non avrebbe avuto senso, permettere di configurare dipendenze remote, se il servizio è solo locale). 135 Beneficiario COLFUTURO 2010

141 Figura 59: Aggiunta tasto New. 5. In PicBundle sono stati aggiunti, vicino al tasto new del campo TYPE_TEXT_MULTI (figura 59), anche un tasto browse (il quale compare solo viciono al campo per l inserimento delle dipendenze remote e non per tutti i campi TYPE_TEXT_MULTI). Figura 60: Aggiunta tasto Browse. 136 Beneficiario COLFUTURO 2010