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
• Esempio di implementazione
• 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 rete
• Molti 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)
• Protocolli
• Servizi applicativi aggiuntivi (esterni)
• Adapters
• Componenti
Component
Adapter
Protocol
Kernel
External Service
Internal Service
Infrastruttura di Atelier
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 messaggio
Awareness
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à
Gerarchia dei messaggi
• Categoria (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
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’uso• Sono 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
Esempio implementazione di un semplicissimo sistema basato sull’infrastruttura del progetto Atelier
Scenario• un sensore rileva gli ingressi in una stanza
• un servizio conta le presenze (p)
• un monitor identifica la situazione in un insieme limitato di casi
• p < 2 → attività personale
• 2 ≤ p ≤ 5 → riunione
• p > 5 → seminario
Adapter
SituationMonitor
SituationMonitorGUI
PresenceService
Adapter
BadgeReaderGUI
BadgeReader
Adapter
KernelBadgeID
BadgeID #People
#People
Prima di iniziare
• Ambiente di sviluppo di riferimento: Eclipsehttp://www.eclipse.org/
• Package infrastruttura, scaricabile da:http://www.siti.disco.unimib.it/didattica/sistemica/materiale-didattico
• Esempi, stessa pagina
Conoscenze
• Necessarie
• Java
• XML
• Accessorie
• OWL
• DB
In generale Per il progetto(non per tutti)
Per iniziare
• infrastructure.jar contiene:
• bin: files batch
• conf: files di configurazione
• doc: APIs
• lib: infrastruttura e jar necessari
• META-INF: manifest del jar
Per decomprimere: jar xf infrastructure.jar
Fase 1
• Creazione nuovo progetto eclipse
• Import infrastruttura
• Test: avvio del kernel
• N.B. Screenshots fatti con Eclipse per Mac OS
File → Import
Java Build Path
Libraries
Run
Fase 2: Implementazione
• BadgeReader
• BadgeReaderGUI
• PresenceService
• SituationMonitor
• SituationMonitorGUI
Tutto il codice lo potete scaricare dalla
pagina dei materiali.
Ora lo commentiamo e testiamo
Nella prossima lezione
• Inseriremo un servizio basato su una rappresentazione del contesto definita come ontologia
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
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
Top Related