I problemi principali connessi ad uno scenario applicativo (par. 4.1) come quello descritto in precedenza, sono:
> Definizione di una tecnica di routing delle notifiche, nella rete fissa, che sia scalabile, efficente e completamente distribuita.
> Definizione della modalità di accesso al processo di notifica, sia per quanto riguarda i nodi transienti che per quanto riguarda i moduli software locali. Attraverso un’attenta fase di analisi dello scenario applicativo e delle principali problematiche che questo porta con se si è cercato di convenire, per entrambi i problemi su definiti, a delle soluzioni che fossero coerenti con l’architettura generale e al contempo avessero delle proprietà di portabilità, interoperabilità e prestazionali autonome dal contesto applicativo.
Analizzeremo prima la scelte progettuali effettuate per risolvere il primo dei pro-blemi su elencati e in seguito procederemo a chiarire le scelte che hanno condotto alla risoluzione del secondo.
Per riuscire a definire una scelta progettuale adeguata e coerente con gli obiettivi della tesi, è stata effettuato uno studio sullo stato dell’arte delle comunicazione basate sugli eventi. La scelta effettuata è stata rivolta verso un modello di tipo publish/subscribe particolarmente adatto per conferire, al processo di notifica, scalabilità, asincronia ed assicurare il disaccoppiamento temporale e spaziale fra gli attori del processo. Mentre per quanto riguarda il modello di selezione delle notifiche, possiamo dire che la scelta è stata fortemente influenzata da vincoli progettuali. Infatti, si è assunto che ciascun evento, nel sistema, avesse una
classe di appartenenza, un topic, e portasse con se informazioni supplementari come un indice di priorità e un payload attinente alla risorsa monitorato. Quindi la naturale convergenza è stata, in termini di modello di selezione delle notifiche, un modello topic/based. Nonostante la scelta del modello di selezione delle noti-fiche sia stato vincolato da assunzioni progettuali più generali, esso rappresenta in ogni caso la scelta più performante per tale ambiente applicativo perchè rende più scalabile il processo di notifica rispetto ai modelli content-based e type-based e al contempo è più raffinato per quanto riguarda la scelta degli eventi di interesse. Partendo da queste considerazioni e tenendo presente il principio ingegneristico che consiglia di non implementare nuovamente ciò che è già stato implementato e funziona, si è cercato di vedere se esistesse già una implementazione funzionan-te e coerenfunzionan-te con le esigenze progettuali. A tal proposito sono stafunzionan-te analizzafunzionan-te le diverse implementazioni del paradigma Publish/Subscribe disponibili, ponen-do particolare attenzione alle caratteristiche di scalabilità e complessità. Fra le diverse alternative analizzate: REBECA, Ermes, Jedi, Gryphon, Siena, SCRIBE, TERA, CORBA, Elvin, TIBCO rendez-vous è stato scelta come implementazione SCRIBE, sia perchè topic-based, sia perchè non eccessivamente complessa, sia perchè altamente scalabile grazie al sottostante pastry e alle tecniche di hashing di cui fa uso nella distribuzione del carico fra i nodi della rete.
Ora analizzeremo la fasi di analisi che hanno condotto alle scelte progettuali per la risoluzione del problema relativo alle modalità di accesso al processo di notifica. In prima istanza si è cercato di capire le proprietà che tale sistema di accesso al processo di notifica doveva assicurare e dopo un’attenta analisi si convenuto al fatto che dovesse assicurare le seguenti proprietà:
Figura 4.1: Ambiente Domotico con l’astrazione della rete SCRIBE formata dai Nodi Fissi e anche i Nodi Transienti
1. interoperabilità
2. omogeneità con il modello architetturale del SM4ALL Project 3. coerenza con una specifica esistente
4. coerenza col paradigma generale scelto (Pub/Sub) nella diffusione degli eventi
L’aver definito tali proprietà ha consentito così di poter in prima istanza definire alcuni elementi architetturali di partenza e poi di attuare uno studio sullo sta-to dell’arte in modo da verificare se esistesse qualche paradigma conforme alle proprietà definite in fase di analisi e alle scelte architetturali fatte.
Le prime due proprietà, in realtà, hanno circoscritto fortemente l’area tecnologico-architetturale entro la quale definire la soluzione, infatti l’architettura generale del progetto è di tipo SOA la quale ha come aspetto più positivo la capacità di rendere interoperabili i sistemi. Inoltre, visto che l’ENS doveva integrarsi con
altri moduli già sviluppati, tale scelta progettuale ha consentito al modulo ENS di essere utilizzato in combinazione con altri servizi per fornire servizi più com-plessi e ha reso dunque più flessibile il suo utilizzo. Va chiarito il fatto che tali vincoli non hanno inficiato la qualità della soluzione scelta, infatti di per se la sola proprietà di interoperabilità suggeriva un architettura SOA. A partire da que-ste considerazioni si è potuto avviare un processo di ricerca e studio nello stato dell’arte affinchè si trovasse una soluzione performante anche con le proprietà 3 e 4 precedentemente definite. La ricerca è stata dunque focalizzata su specifi-che web-service specifi-che supportassero il paradigma publish/subscribe. Le specifispecifi-che oggetto di interesse sono state tre:
> WS-Events > WS-Eventing > WS-Notification
Dalla studio di ognuna, si è potuto analizzare le qualità ma anche i limiti. Tutte e tre sono risultate essere molto simili tra di loro anche se la scelta è caduta sulla specifica WS-Notification per le seguenti motivazioni:
• Offre maggiore espressività fornendo un sistema di definizione dei tipi di evento basato sul concetto di topic.
• Standardizza la figura di un intermediario, il broker.
La maggiore espressività offerta dalla specifica WS-Notification è stata fonda-mentale nella scelta della stessa. Essa infatti contribuisce a rafforzare l’omoge-neità progettuale, adattandosi, in modo importante, al modello implementativo
fatto per la tecnica di routing degli eventi, cioè publish/subscribe topic-based. Dunque, SCRIBE e WS-Notification sembrano, nella loro totalità, risolvere in modo ottimale i principali problemi progettuali forniti dall’ambiente applicativo descritto, conferendo da un lato omogeneità progettuale e dall’altro l’integrazione all’interno dell’architettura generale del caso di studio.
Spiegato il processo di analisi che ha condotto alle conseguenti scelte progettua-li, sarà approfondita l’architettura generale dell’ENS. In questo modo si cerche-rà di rendere più chiara l’interconnessione che esiste fra le i due macroblocchi concettuali oggetto dell’analisi e della progettazione:
> routing degli eventi
> accesso al processo di notifica
Fino ad ora le riflessioni connesse all’analisi e alle conseguenti scelte pro-gettuali, potevano essere definite a prescindere da un altro vincolo progettuale fornito con la specifica dell’ENS. Ora però, apprestandoci a definire l’architettura software dell’ENS, non si può prescindere dall’inserire tale vincolo negli elemen-ti del discorso, questo perchè la strutturazione modulare dei componenelemen-ti e le modalità di relazione che questi hanno nell’attuare la logica di business sono state fortemente definite in coerenza dell’ambiente operativo che doveva ospi-tarli. La specifica dell’ENS chiedeva che i componenti fossero ospitati all’interno dell’ambiente OSGI. Apriamo una piccola parentesi sul framework OSGI.
Accenni sul Framework OSGI
Con il framework OSGi si vuole implementare un modello a componenti completo e dinamico capace di sopperire ai limiti che, in tal senso, ha Java. Dobbiamo però dire che il linguaggio Java ha alcuni meccanismi per la realizzazione di modelli a
componenti, però i limiti delle soluzioni fornite sono che bisogna lavorare a basso livello con conseguente rischio di introdurre errori nel codice oltre a diventare una soluzione ad-hoc quindi con un grado di astrazione molto basso. I concetti attraverso i quali OSGI prova a risolvere i limiti di modularità e dinamismo forniti da java sono i seguenti:
> Definizione del concetto di modulo (bundle) > Gestione automatica delle dipendenze
> Gestione del ciclo di vita del codice (configurazione e distribuzione dinami-ca)
In sintesi è possibile vedere la tecnologia OSGi come: > Un sistema modulare per la piattaforma Java
> Un sistema dinamico, che consente l’installazione, l’avvio, lo stop e la rimozione dei moduli a runtime, senza quindi necessitare di riavvii.
> Orientato ai servizi, i quali possono essere dinamicamente registrati ed utilizzati nella macchina virtuale Java.
OSGI ha diverse implementazioni come Knoplerfish OSGI, Apache Felix. Ma è Eclipse Equinox l’implementazione di riferimento per la specifica OSGI, oltre che quella utilizzata in questo contesto. Un bundle OSGi è un file .jar con meta informazioni aggiuntive. Queste meta informazioni sono memorizzate nella cartella META-INF nel file MANIFEST.MF. Quest’ultimo fa parte di una specifica standard per il file jar. Qualsiasi ambiente non OSGi ignorerà i metadati OSGi,
pertanto un bundle può essere utilizzato senza limitazioni in ambienti Java non OSGi.
Ogni bundle ha un numero di versione memorizzato nella proprietà Bundle-Version e un nome simbolico. Questi due elementi identificano in modo univoco un bundle in OSGi. L’ambiente OSGi può caricare uno stesso bundle con nume-ri di versione diversa. Attraverso il file MANIFEST.MF un bundle può definire la sua dipendenza da altri pacchetti e servizi. Se un bundle vuole utilizzare le classi di un altro bundle come API pubbliche, tali classi devono essere esporta-te, Export-Packages, nel file di manifest del bundle che le possiede, altrimenti il bundle che le richiede non può essere caricato. I bundle possono registrarsi e utilizzare i servizi di altri bundle. OSGi, quindi, fornisce un registro centrale per questo scopo. Un servizio è definito da una interfaccia Java mentre l’accesso a tale Service Register è effettuato tramite la classe BundleContext. OSGI è responsabile per la gestione delle dipendenze fra bundle, queste dipendenze sono divisibili in:
• Dipendenze dai Package: OSGi legge il MANIFEST.MF di un bundle du-rante l’installazione e assicura che se il bundle è attivo allora tutti i pacchetti dipendenti sono stati caricati, altrimenti non viene avviato.
• Dipendenze dai Servizi: un servizio in OSGi può essere dinamicamente avviato e fermato, sono i bundle a dover gestire queste dipendenze. Essi possono utilizzare un service listener per sapere quando un servizio è attivo oppure no.
Specificare questo elemento consente anche di comprendere meglio le scelte ar-chitetturali del software. Approfondita l’architettura analizzeremo il livello im-plementativo dei micromoduli che consentono il funzionamento dell’ENS e come essi interagiscono per attuare la logica di business.