ATELIER e la sua
infrastruttura
Esercitazione 3 del corso di Sistemi Context-aware
http://www.siti.disco.unimib.it/didattica/sistemica
Marco Loregian
loregian@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 ...)
protocolli di rete,
problemi (vd. stack
• [Per (infrastruttura software in generale)più
alto
questo corso] Ci interessa il livello
• 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

Eterogeneità
funzionale
• 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

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)

MVC
in sintesi
• Separazione dei compiti fra
componenti software Event Manager
• model: contiene i dati e Controller
fornisce i metodi per accedervi;
• view: visualizza i dati contenuti
nel model;
View Model
• controller: riceve i comandi
User Interface Business/Application
dell'utente (attraverso il view) e Logic
li attua modificando lo stato Associazione indiretta
degli altri due componenti. Associazione diretta
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

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.pdf
http://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
Component
• Servizi aggiuntivi del
kernel (interni)
Adapter
• Protocolli External Service Protocol
• Servizi applicativi
aggiuntivi (esterni)
Kernel
• Adapters
•
Internal Service
Componenti

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>
} Registrazione
<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\" /> }
Messaggi che il componente produrrà
</metainfo>
<metainfo name=\"parameters\" type=\"registration\" id=\"RegistrationParameters\">
<parameter name=\"port\" value=\"COM1\" />
</metainfo>
</body>
</message>

Gerarchia dei messaggi
• Categoria (con sub-categorie)
• Messaggi, eventi, application-specific
• Tipo
• Dettaglio, funzione specifica (RPC)
• Esempio:
category: application/db
type: 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

BadgeReaderGUI PresenceService
BadgeReader Adapter
Adapter BadgeID
#People
BadgeID
Kernel
#People
Adapter
SituationMonitor
SituationMonitorGUI

Prima di iniziare
• Ambiente di sviluppo di riferimento: Eclipse
http://www.eclipse.org/
• Package infrastruttura, scaricabile da:
http://www.siti.disco.unimib.it/didattica/
sistemica/materiale-didattico
• Esempi, stessa pagina

Conoscenze
• Necessarie • Accessorie
• Java • OWL
• XML • DB
In generale Per il progetto
(non per tutti)

Per iniziare
• infrastructure.jar contiene:
• bin: files batch Per decomprimere:
jar xf infrastructure.jar
• conf: files di configurazione
• doc: APIs
• lib: infrastruttura e jar necessari
• META-INF: manifest del jar

Fase 1
• Creazione nuovo progetto eclipse
• Import infrastruttura
• Test: avvio del kernel
• N.B. Screenshots fatti con Eclipse per Mac OS

File → Import

Libraries
Java Build Path

Run

Fase 2:
Implementazione
Tutto il codice lo • BadgeReader
potete scaricare dalla
pagina dei
• BadgeReaderGUI
materiali. • PresenceService
Ora lo commentiamo e
• SituationMonitor
testiamo
• SituationMonitorGUI

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