ATELIER e la sua infrastruttura

Esercitazione 3 del corso di Sistemi Context-awarehttp://www.siti.disco.unimib.it/didattica/sistemica

Marco Loregianloregian@disco.unimib.it

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

http://atelier.k3.mah.se

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