ATELIER e la sua infrastruttura
Esercitazione 3 del corso di Sistemi Context-awarehttp://www.siti.disco.unimib.it/didattica/sistemica
Marco [email protected]
Nelle scorse lezioni
Esempi pratici di ubiquitous e context-aware computing
Architettura e componenti del sistema Gaia
In questa lezione
Generalizzazione: Infrastrutture per l’ubiquitous computing
Il progetto ATELIER
L’infrastruttura software di ATELIER
References
Introduzione
Ubiquitous computing: integrazione di molti dispositivi e tecnologie diverse
Esempi di tecnologie per l’integrazione
CORBA (vd. Gaia), Java, Jini, OSGi, ...
Forniscono gli elementi di base per l’integrazione
protocolli di scoperta dei servizi, trasporto dei messaggi, ...
Infrastrutture tecnologiche: ne esistono molte e a diversi livelli
stratificazione dei problemi (vd. stack protocolli di rete, ...)
[Per questo corso] Ci interessa il livello più alto (infrastruttura software in generale)
Sfruttiamo le infrastrutture tecnologiche e ci concentriamo su problemi di più alto livello
Nascondiamo tutti i problemi sottostanti
Dipendenti da hardware, reti, ...
I componenti, servizi e applicazioni costruiti appoggiandosi sull’infrastruttura software devono essere configurabili e ricombinabili a seconda delle diverse situazioni
Sistemi estendibili (incrementalmente) nel tempo
Un’infrastruttura per l’ubicomp deve supportare la scoperta, l’adattamento, e la fruizione delle diverse funzionalità delle applicazioni a seconda della situazione corrente
Al variare delle condizioni degli utenti
La consapevolezza della disponibilità delle risorse è essenziale per avere la possibilità di utilizzarle
Eterogeneitàfunzionale
Requisiti non funzionali
Indipendenza da
hardware e sistema operativo
rete
linguaggio di programmazione
Estensibilità e configurabilità
Formato delle informazioni e dei contenuti
Indipendenza da HW e SO
Ubicomp: gamma completa di dispositivi
spesso privi di capacità computazionale o di connettività
Separazione funzionalità (es. I/O, app. logic)
Pattern Model-View-Controller (MVC)
esteso ad un sistema distribuito (es. frammentavione View)
MVCin sintesi
Separazione dei compiti fra componenti software
model: contiene i dati e fornisce i metodi per accedervi;
view: visualizza i dati contenuti nel model;
controller: riceve i comandi dell'utente (attraverso il view) e li attua modificando lo stato degli altri due componenti.
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
ModelView
Controller
Business/ApplicationLogic
User Interface
Event Manager
Associazione indirettaAssociazione diretta
Indipendenza dalla reteMolti tipi di dispositivi ⇒ molti protocolli da supportare
Conviene nascondere la complessità (es. del trasporto) con uno strato di comunicazione indipendente
Le applicazioni non si devono adattare all’ambiente (es. transizione copertura bluetooth → WiFi), ci pensa l’infrastruttura
Spesso ci sono reti diverse perché le situazioni sono diverse
Conviene avere un’infrastruttura generica che consenta di sviluppare applicazioni indipendentemente dal dominio
Approccio Platform / OS
Approccio di Gaia: sviluppare un OS (~virtual machine) per applicazioni ubicomp
Astrazione basata su OS del dispositivo + servizi aggiuntivi
API per sviluppatori basate su linguaggio esistente (es. Java, C++) o su uno nuovo (specifico)
Gaia si basa su CORBA
CORBA in sintesi
Common Object Request Broker Architecture
ORB = Object-oriented RPC (remote procedure call)
Middleware distribuito per la comunicazione tra applicazioni
http://www.omg.org/docs/formal/04-03-12.pdfhttp://www.ciaranmchale.com/corba-explained-simply/core-concepts-and-terminology.html
Indipendenza dal linguaggio di programmazione
Infrastrutture come Gaia hanno bisogno di una piattaforma HW in grado eseguire TAO (CORBA C++)
Spesso i dispositivi non possono eseguire neanche codice compilato
Ci vuole un adapter che faccia da tramite tra dispositivo e piattaforma
EstensibilitàNuovi requisiti da soddisfare
Aggiungere nuove funzionalità
ConfigurabilitàStessi dispositivi per differenti contesti
Per qualsiasi utente, non solo tecnici
Formato informazioni e contenuti
Dispositivi diversi (HW, OS)
si scambiano messaggi di diverso tipo (protocolli)
elaborano diversi tipi di documenti
Possibile una soluzione generale/standard?
XML
Quale deve essere il grado di specificità di
una piattaforma?
ATELIER
Progetto europeo
Diversi setup e scenari di test
Infrastruttura aggiornata e riutilizzata anche dopo la conclusione del progetto (2004)
Scopo: semplificare lo sviluppo di applicazioni in un ambiente eterogeneo
Caratteristiche dell’infrastruttura
Comunicazione asincrona basata su XML
Via TCP/IP (nella versione che useremo)
Indipendente dal linguaggio di programmazione (esempi e tools in Java)
Architettura a microkernel
Nucleo centrale (Kernel) per funzioni di base
Servizi aggiuntivi del kernel (interni)
Servizi applicativi aggiuntivi (esterni)
Componenti / Adapters
Protocolli
Component
Adapter
Protocol
Kernel
External Service
Internal Service
Infrastruttura di Atelier
MVC distribuito e microkernel
Model, View e Control (sono frammentabili) e comunicano via XML:
<message> <category name="root/registration"> <type name="register" /> </category> <body content-type="text/xml"> <registration name="RemoteControlComponent" class="Control" type="component"> <metainfo name="provides" type="registration" id="RegistrationProvides"> <provides name="category" value="Root/event" /> <provides name="type" value="input/remote" /> </metainfo> <metainfo name="parameters" type="registration" id="RegistrationParameters"> <parameter name="port" value="COM1" /> </metainfo> </body> </message>
} Registrazione
} Messaggi che il componente produrrà
Interazione fra componenti
Tutti i componenti e i servizi
devono registrarsi presso il kernel (vd. esempio precedente)
possono essere de-registrati
Meccanismo (message passing) tipo publish/subscribe
Ogni componente dice che tipo di messaggi produce a quale tipo di messaggi è interessato, e il kernel glieli inoltra se qualcuno li produce
Un componente può chiedere al kernel se c’è qualcuno che produce/consuma un certo tipo di messaggioAwareness
Gerarchia dei messaggiCategoria (con sub-categorie)
Messaggi, eventi, application-specific
Tipo
Dettaglio, funzione specifica (RPC)
Esempio: category: application/dbtype: additem
“Aggiungi un elemento al DB”, nel resto del messaggio avrò l’elemento vero e proprio
HelloWorld
Tutti i componenti devono rispondere alla categoria HelloWorld
test delle applicazioni
Adapter
Gli Adapters forniscono le funzionalità di comunicazione ai componenti
abstract communication link
Fungono da proxy per l’infrastruttura di comunicazione
Asincronicità
Modello a eventi (o quasi)
GUI → clicco il bottone e parte un handler associato all’evento specifico
Il componente si registra al kernel, che gli recapita i messaggi a cui è interessato
Quando arriva un messaggio il componente lo deve elaborare (demarshal), agire di conseguenza (PC), ed eventualmente generare un messaggio di risposta (marshal) da mandare al kernel (o direttamente a qualcun altro)
Facilità d’usoSono state sviluppate API (utilities Java) che semplificano la gestione dei messaggi XML
Marshal, Demarshal
public void newHyperNodeAdded(HyperNode newNode) { AtelierXMLMessage msg =
new AtelierXMLMessage("application/entrance", "newitemadded"); msg.setBodyContentType("text/xml"); XMLElement content =
XMLMessageFactory.getInstance().createXMLElement("node"); Integer idOfNode = newNode.getID(); content.putAttribute("hypernodeid", idOfNode.toString()); msg.setBodyContent(content.toString()); adapter.sendMessage(msg);
}
Indipendenza
Chi sviluppa un componente, adapter, o servizio non vede i meccanismi di scambio dei messaggi
Possono avvenire su reti di diverso tipo
Architettura peer-to-peer ibrida
Il kernel funge da directory dei servizi e degli indirizzi dei vari nodi (c’è la possibilità di creare route diretti)
Estensibilità
Estensione della piattaforma
Modifiche al kernel
Nuovi servizi interni/esterni di default
Attualmente gli unici servizi interni sono: pipeline, name server e id factory
Estensione delle applicazioni
Gestione nuovi messaggi: categorie/tipi
Estensione dei protocolli
Configurabilità
Fattori:
meccanismo publish/subscribe
filtraggio e trasformazione dei messaggi
Configurabilità a runtime
start/stop componenti e servizi
routing dinamico
Esempi di componenti e applicazioni
Configurazione ambiente fisico
RFID/Barcode
Interazione con documenti
HMDB
Ontologia
Tangible Image Query
Homework
Leggere i due articoli segnalati come riferimenti
Contribuire al SITI blogwww.siti.disco.unimib.it/blog !
Riferimenti
1. Antti Juustila, Toni Räisänen: Atelier Infrastructure for Ubiquitous Computing. Proceedings of the 30th Information Systems Reseach Seminar in Scandinavia. IRIS 2007 [pdf in area riservata]
2. Marco Loregian, Kresimir Matkovic, Thomas Psik: Seamless Browsing of Visual Contents in Shared Learning Environments. PerCom Workshops 2006: 235-239 http://doi.ieeecomputersociety.org/10.1109/PERCOMW.2006.120