Cac Es3 2009

796 views

Published on

Esercitazione su ATELIER 2009

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

  • Be the first to like this

No Downloads
Views
Total views
796
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cac Es3 2009

  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 • Esempio di implementazione • 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 ...) 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, ...
  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 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
  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 base Component • Servizi aggiuntivi del kernel (interni) Adapter • Protocolli External Service Protocol • Servizi applicativi aggiuntivi (esterni) Kernel • Adapters • Internal Service Componenti
  22. 22. Infrastruttura di Atelier
  23. 23. 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
  24. 24. MVC distribuito e microkernel • Model,View e Control sono frammentabili e comunicano via XML: <message> <category name=quot;root/registrationquot;> <type name=quot;registerquot; /> </category> } Registrazione <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>
  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. Adapter • Gli Adapters forniscono le funzionalità di comunicazione ai componenti • abstract communication link • Fungono da proxy per l’infrastruttura di comunicazione
  27. 27. 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)
  28. 28. 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); }
  29. 29. 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)
  30. 30. 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
  31. 31. Configurabilità • Fattori: • meccanismo publish/subscribe • filtraggio e trasformazione dei messaggi • Configurabilità a runtime • start/stop componenti e servizi • routing dinamico
  32. 32. Esempi di componenti e applicazioni • Configurazione ambiente fisico • RFID/Barcode • Interazione con documenti • HMDB • Ontologia • Tangible Image Query
  33. 33. Esempio implementazione di un semplicissimo sistema basato sull’infrastruttura del progetto Atelier
  34. 34. 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
  35. 35. BadgeReaderGUI PresenceService BadgeReader Adapter Adapter BadgeID #People BadgeID Kernel #People Adapter SituationMonitor SituationMonitorGUI
  36. 36. 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
  37. 37. Conoscenze • Necessarie • Accessorie • Java • OWL • XML • DB In generale Per il progetto (non per tutti)
  38. 38. 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
  39. 39. Fase 1 • Creazione nuovo progetto eclipse • Import infrastruttura • Test: avvio del kernel • N.B. Screenshots fatti con Eclipse per Mac OS
  40. 40. File → Import
  41. 41. Libraries Java Build Path
  42. 42. Run
  43. 43. Fase 2: Implementazione Tutto il codice lo • BadgeReader potete scaricare dalla pagina dei • BadgeReaderGUI materiali. • PresenceService Ora lo commentiamo e • SituationMonitor testiamo • SituationMonitorGUI
  44. 44. Nella prossima lezione • Inseriremo un servizio basato su una rappresentazione del contesto definita come ontologia
  45. 45. 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

×