Sistemi Context-aware: Esercitazione 3

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

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

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)

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