Your SlideShare is downloading. ×
Cac Es3 2009
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Cac Es3 2009

543
views

Published on

Esercitazione su ATELIER 2009

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
543
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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. Nelle scorse lezioni • Esempi pratici di ubiquitous e context- aware computing • Architettura e componenti del sistema Gaia
  • 3. In questa lezione • Generalizzazione: Infrastrutture per l’ubiquitous computing • Il progetto ATELIER • L’infrastruttura software di ATELIER • Esempio di implementazione • References
  • 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. • 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. • 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. 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. Requisiti non funzionali • Indipendenza da • hardware e sistema operativo • rete • linguaggio di programmazione • Estensibilità e configurabilità • Formato delle informazioni e dei contenuti
  • 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. 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. 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. 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. 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. 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. Estensibilità • Nuovi requisiti da soddisfare • Aggiungere nuove funzionalità Configurabilità Stessi dispositivi per differenti contesti Per qualsiasi utente, non solo tecnici
  • 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. Quale deve essere il grado di specificità di una piattaforma?
  • 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. http://atelier.k3.mah.se
  • 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. 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. Infrastruttura di Atelier
  • 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. 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. 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. Adapter • Gli Adapters forniscono le funzionalità di comunicazione ai componenti • abstract communication link • Fungono da proxy per l’infrastruttura di comunicazione
  • 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. 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. 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. 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. Configurabilità • Fattori: • meccanismo publish/subscribe • filtraggio e trasformazione dei messaggi • Configurabilità a runtime • start/stop componenti e servizi • routing dinamico
  • 32. Esempi di componenti e applicazioni • Configurazione ambiente fisico • RFID/Barcode • Interazione con documenti • HMDB • Ontologia • Tangible Image Query
  • 33. Esempio implementazione di un semplicissimo sistema basato sull’infrastruttura del progetto Atelier
  • 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. BadgeReaderGUI PresenceService BadgeReader Adapter Adapter BadgeID #People BadgeID Kernel #People Adapter SituationMonitor SituationMonitorGUI
  • 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. Conoscenze • Necessarie • Accessorie • Java • OWL • XML • DB In generale Per il progetto (non per tutti)
  • 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. Fase 1 • Creazione nuovo progetto eclipse • Import infrastruttura • Test: avvio del kernel • N.B. Screenshots fatti con Eclipse per Mac OS
  • 40. File → Import
  • 41. Libraries Java Build Path
  • 42. Run
  • 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. Nella prossima lezione • Inseriremo un servizio basato su una rappresentazione del contesto definita come ontologia
  • 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

×