Sistemi Context-aware: Esercitazione 3

1,540 views

Published on

Esercitazione 1 del corso di sistemi context-aware - Corso di laurea magistrale in Informatica, università di Milano-Bicocca

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,540
On SlideShare
0
From Embeds
0
Number of Embeds
22
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Sistemi Context-aware: Esercitazione 3

  1. 1. 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
  2. 2. Nelle scorse lezioni Esempi pratici di ubiquitous e context-aware computing Architettura e componenti del sistema Gaia
  3. 3. In questa lezione Generalizzazione: Infrastrutture per l’ubiquitous computing Il progetto ATELIER L’infrastruttura software di ATELIER References
  4. 4. 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, ...
  5. 5. 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, ...
  6. 6. 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
  7. 7. 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
  8. 8. Requisiti non funzionali Indipendenza da hardware e sistema operativo rete linguaggio di programmazione Estensibilità e configurabilità Formato delle informazioni e dei contenuti
  9. 9. 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)
  10. 10. MVC in sintesi Separazione dei compiti fra componenti software Event Manager model: contiene i dati e fornisce i metodi per Controller accedervi; view: visualizza i dati contenuti nel model; View Model controller: riceve i comandi User Interface Business/Application dell'utente (attraverso il view) Logic Associazione indiretta e li attua modificando lo stato Associazione diretta degli altri due componenti. http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. Estensibilità Nuovi requisiti da soddisfare Aggiungere nuove funzionalità Configurabilità Stessi dispositivi per differenti contesti Per qualsiasi utente, non solo tecnici
  16. 16. 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
  17. 17. Quale deve essere il grado di specificità di una piattaforma?
  18. 18. 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
  19. 19. http://atelier.k3.mah.se
  20. 20. 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)
  21. 21. Architettura a microkernel Nucleo centrale (Kernel) per funzioni di Component base Adapter Servizi aggiuntivi del kernel (interni) External Service Protocol Servizi applicativi Kernel aggiuntivi (esterni) Componenti / Adapters Internal Service Protocolli
  22. 22. Infrastruttura di Atelier
  23. 23. MVC distribuito e microkernel Model, View e Control (sono frammentabili) e comunicano via XML: } <message> <category name=quot;root/registrationquot;> <type name=quot;registerquot; /> Registrazione </category> <body content-type=quot;text/xmlquot;> <registration name=quot;RemoteControlComponentquot; class=quot;Controlquot; type=quot;componentquot;> <metainfo name=quot;providesquot; type=quot;registrationquot; id=quot;RegistrationProvidesquot;> <provides name=quot;categoryquot; value=quot;Root/eventquot; /> <provides name=quot;typequot; value=quot;input/remotequot; /> } Messaggi che il componente produrrà </metainfo> <metainfo name=quot;parametersquot; type=quot;registrationquot; id=quot;RegistrationParametersquot;> <parameter name=quot;portquot; value=quot;COM1quot; /> </metainfo> </body> </message>
  24. 24. 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 Awareness messaggio
  25. 25. 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
  26. 26. HelloWorld Tutti i componenti devono rispondere alla categoria HelloWorld test delle applicazioni
  27. 27. Adapter Gli Adapters forniscono le funzionalità di comunicazione ai componenti abstract communication link Fungono da proxy per l’infrastruttura di comunicazione
  28. 28. 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)
  29. 29. 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(quot;application/entrancequot;, quot;newitemaddedquot;); msg.setBodyContentType(quot;text/xmlquot;); XMLElement content = XMLMessageFactory.getInstance().createXMLElement(quot;nodequot;); Integer idOfNode = newNode.getID(); content.putAttribute(quot;hypernodeidquot;, idOfNode.toString()); msg.setBodyContent(content.toString()); adapter.sendMessage(msg); }
  30. 30. 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)
  31. 31. 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
  32. 32. Configurabilità Fattori: meccanismo publish/subscribe filtraggio e trasformazione dei messaggi Configurabilità a runtime start/stop componenti e servizi routing dinamico
  33. 33. Esempi di componenti e applicazioni Configurazione ambiente fisico RFID/Barcode Interazione con documenti HMDB Ontologia Tangible Image Query
  34. 34. Homework Leggere i due articoli segnalati come riferimenti Contribuire al SITI blog www.siti.disco.unimib.it/blog !
  35. 35. 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

×