Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Vlad Trifa - Final PhD Thesis Defense at ETH Zurich

16.846 Aufrufe

Veröffentlicht am

The final defense of my phd thesis at ETH Zurich. The final report will be posted soon on my personal Web site (vladtrifa.com), once accepted by the school commission and submitted.

Veröffentlicht in: Technologie, Business
  • Als Erste(r) kommentieren

Vlad Trifa - Final PhD Thesis Defense at ETH Zurich

  1. 1. Building Blocks for a Participatory Web of Things:Devices, Infrastructures, and Programming FrameworksDoctoral Defense – 26 August 2011Vlad Trifa
  2. 2. Context ■ Networked embedded devices (NEDs) omnipresent ■ Increasingly powerful CPUs, various sensors/actuators ■ Mobile Internet cheap and ubiquitous ■ Tremendous benefits when integrating their data and services ■ Social: energy-efficient building, smarts buildings and cities ■ Business: real-time enterprise, optimized logisticsDoctoral Defense, 26.8.2011 Vlad Trifa 2
  3. 3. Distributed Sensing Applications (DSA) Today ■ Tedious process that requires many resources (skills, time, $$$) ■ Various functionalities, sensors, requirements ■ Incompatible protocols, standards, programming models, APIs, etc. ■ “Wheel reinvention” is common (hard-wired applications) base-station connected via Web storage Gateway serial line low-power radio protocols (ZigBee, etc.) Web analysis & page processingDoctoral Defense, 26.8.2011 Vlad Trifa 3
  4. 4. Problem Statement How to create an infrastructure for facilitating the development of asynchronous DSAs on top of heterogeneous, mobile NEDs?Doctoral Defense, 26.8.2011 Vlad Trifa 4
  5. 5. The Web of Things ■ Leverage Web architecture, standards and techniques ■ REST, HTTP, HTML, JSON, MIME, caching, authentication, etc. ■ TCP/IP & Web granted, Wi-Fi routers ubiquitous ■ HTTP/REST: many advantages for larger DSAs ■ Flexible, loosely coupled, scalable, lightweight ■ Smooth integration with existing Web infrastructure ■ Blend real-world services and devices with the Web ■ Development of simple Web apps: cheaper & fasterDoctoral Defense, 26.8.2011 Vlad Trifa 5
  6. 6. Research Questions Is the Web as is sufficient to support DSAs? What is required for most DSA? How to build a framework for developing applications that are well integrated into the Web?Doctoral Defense, 26.8.2011 Vlad Trifa 6
  7. 7. Part 1Web-enabled Devices
  8. 8. Web-enabled Devices ■ Devices run Web servers GET ■ services RESTful resources fridge/food.html ■ REST core architecture of Web ■ HTTP implements REST style ■ URI for each component ■ Uniform Interface GET fire/alerts.xml ■ HTTP verbs & codes ■ Representations PUT tv/channel/4 ■ HTML: humans ■ JSON/XML/CSV: machines D. Guinard, V. Trifa, F. Mattern, and E. Wilde. Architecting the Internet of Things, Chapter From the Internet of Things to the Web of Things: Resource Oriented Architecture and Best Practices. Number 5. Springer, May 2011.Doctoral Defense, 26.8.2011 Vlad Trifa 8
  9. 9. Gateways Google APIs proprietary X10 HTTP Bluetooth Gateway HTTP Web API DLNA IEEE802.15.4 HTTP Flickr API V. Trifa, S. Wieland, D. Guinard, and T. M. Bohnert. Design and implementation of a gateway for web-based interaction and management of embedded devices. In Proc. of the 2nd International Workshop on Sensor Network Engineering (IWSNE’09), Marina del Rey, CA, USA, 2009.Doctoral Defense, 26.8.2011 Vlad Trifa 9
  10. 10. Gateway Internal Architecture proxy application device devices user application services DB services services control layer ../devices/1 direct Sun SPOT REST HTTP cached engine server device DT1 TMote thread pool templating device engine DT2 drivers ../devices/2 device layer presentation layerDoctoral Defense, 26.8.2011 Vlad Trifa 10
  11. 11. Response time for Consecutive HTTP GET Requests 1 0.9 D C Cumulative Density Function 0.8 Min. 159 2 0.7 Max. 3075 36 0.6 Avg. 203 3.9 0.5 q99% 282 19 0.4 RTT [ms] of 10’000 local read requests for direct and 0.3 cached approaches 0.2 0.1 Direct Cached 0 0 100 200 300 400 Response time [ms]Doctoral Defense, 26.8.2011 Vlad Trifa 11
  12. 12. Part 2Distributed Infrastructures
  13. 13. Distributed, Location-aware Infrastructures for WoT(can run anywhere) /ethz virtual gateways /ethz/CNB /ethz/CNB/FloorD /ethz/CNB/FloorE(must be embodied) physical gateways ../southWing/D48.1 ../floorD/southWing ../southWing/D48.2 V. Trifa, D. Guinard, and S. Mayer. Leveraging the Web for a Distributed Location-aware Infrastructure for the Real World. Chapter 17 in REST: From Research to Practice, Edited by Wilde and Pautasso, Springer-Verlag, 2011.Doctoral Defense, 26.8.2011 Vlad Trifa 13
  14. 14. Service 1: HTTP-based Devices and Resources DiscoveryDoctoral Defense, 26.8.2011 Vlad Trifa 14
  15. 15. Service 1: HTTP-based Devices and Resources Discovery Device with machine-readable embedded metadata (description, API, etc.) 1. Device connects to router and gets an IP address via DHCP 1 LAN Router LAN (Ethernet)Doctoral Defense, 26.8.2011 Vlad Trifa 14
  16. 16. Service 1: HTTP-based Devices and Resources Discovery Device with machine-readable embedded metadata (description, API, etc.) 1. Device connects to router and gets an IP address via DHCP 1 LAN Router LAN (Ethernet) LAN 2 2. Gateway polls the DHCP Gateway allocation table on the routerDoctoral Defense, 26.8.2011 Vlad Trifa 14
  17. 17. Service 1: HTTP-based Devices and Resources Discovery Device with machine-readable embedded metadata (description, API, etc.) 1. Device connects to router and gets an IP address via DHCP 1 LAN 3. For each new device it gets the root page, parses metadata and adds it to registry Router 3 LAN (Ethernet) LAN 2 2. Gateway polls the DHCP Gateway allocation table on the routerDoctoral Defense, 26.8.2011 Vlad Trifa 14
  18. 18. Service 2: Infrastructure-aided Location-aware Search "GET all meters at /zurich /zurich/ethz/CNB/" /zurich/ethz /zurich/ethz/CAB /zurich/ethz/CAB query scope ../room103 ../room102 "Here you are: ../room102/meter, ../room103/meter" ../meter ../meter ../spotDoctoral Defense, 26.8.2011 Vlad Trifa 15
  19. 19. Part 3Web-based Messaging
  20. 20. Real-time Web ■ HTTP designed as a request-response protocol (scalability) ■ “Eventing” done via polling or federation (feeds: RSS/ATOM) ■ Growing community around Real-time Web techniques ■ HTTP callbacks, Comet, XMPP, Web Sockets, etc. Client Server Application Client Server Application Request Request Response Event Event Response Request Response Event Event Response Request Response Event Event Response AJAX (Web polling) Comet, Web socketsDoctoral Defense, 26.8.2011 Vlad Trifa 17
  21. 21. Web Messaging System (WMS) ■ Gateways & devices need a minimal Web push mechanism ■ Not a protocol (Google’s pubsubhubbub), only Web patterns ■ Notification implemented as HTTP push callbacks [1] ■ RESTful, Simple, light (less options) to run on NEDs ■ Generic pub/sub support (queues & subscriptions) Subscribe to a channel: POST SUB http://.../channels/ethz/CNB/H/subscribers Publish to a channel: POST MSG http://.../channels/ethz/CNB/H/ Receive notifications: foreach SUB in http://.../channels/ethz/CNB/H/subscribers POST MSG SUB[1] V. Trifa, D. Guinard, V. Davidovski, A. Kamilaris, and I. Delchev. Web messaging for open and scalable distributed sensingapplications. In Proc. of the 10th International Conference on Web Engineering (ICWE 2010), Vienna, Austria, June 2010.Doctoral Defense, 26.8.2011 Vlad Trifa 18
  22. 22. Web Sensor Streams ■ Sensor data represented as sequence of messages ■ More complex constructs on top of minimal pub/sub implementaiton ■ Not bound to transport protocol (HTTP callbacks, WebSockets, etc.) ■ Parameterized D1 Web Sensor Stream data=light,temperature& ■ devices devices=D1,D2,D3 ■ sensors D2 t4 t3 t2 t1 Client ■ sampling frequency {"time":123223, ■ filter data D3 "data": [{"D1":{"light":4, "temp":22}}, {"D2":{"light":21, "temp":22}}, Devices {"D3":{"light":200, "temp":33}} ] } ■ Messaging: bi-directional glue between components to support asynchronous communicationDoctoral Defense, 26.8.2011 Vlad Trifa 19
  23. 23. Part 4End-to-end Event-drivenApplications
  24. 24. WISSPR - Web Infrastructure for Sensor Stream PRocessing 1. Device 2. Messaging 3. Query 4. Storage Sensors Connector Connector Connector Connector 3. raw data QC various data acquisition protocols 3. processed DC 1. raw MC 5. raw & processed 2. raw/filtered 4. processed Client Client SCDoctoral Defense, 26.8.2011 Vlad Trifa 21
  25. 25. Uniform messaging REST interface (Web API) Wisspr main node http://wisspr.net MC JAVA REST AMQP [1] Same-machine broker low latency low scalability high coupling Same-LAN broker Cloud-based broker medium scalability Highest scalability and flexibility [1] Advanced message queuing medium latency lower latency protocol amqp.org lower coupling lowest couplingDoctoral Defense, 26.8.2011 Vlad Trifa 22
  26. 26. Complete HTTP Request (& Application) POST /streams/ HTTP/1.1 Host: wisspr.net Content-Type: application/x-www-form-urlencoded devices=D1,D2,D3& data=temperature,light& frequency=2Hz& filter=light<200&&temperature>19& wms.cbk=http://store.wisspr.net/stores/31 Note: content should be %-encoded.Doctoral Defense, 26.8.2011 Vlad Trifa 23
  27. 27. End-to-end Notification Delay 20 Devices simulated in DC 4 10 processing fetching ■ Varied sampling frequency (SF) 3 10 ■ Average notification delay [ms] (DC-MC-Clients) delay:Delay [ms] 2 SF Msg/s Proc. Fetch. Total 10 25 500 2.5 17.3 20 50 1000 3.4 98 101.5 1 10 75 1500 4.2 250.8 255.1 100 2000 5.2 1177.7 1183 0 ■ Scalability limited by clients 10 0 500 1000 1500 2000 Load [msg/s] Doctoral Defense, 26.8.2011 Vlad Trifa 24
  28. 28. Main Contributions 1. Set of reusable patterns & best practices for physical Web ■ Eventing, streaming, querying constructs ■ Pervasive middleware services (discovery, search) ■ Location concepts directly integrated 2. Proof of concept implementations and evaluations ■ Entirely Web-based infrastructure for heterogeneous DSAs ■ Reasonable scalability for devices, users, and real-time data 3. End-to-end 1-line programming framework ■ Collection, processing, sharing, and storage ■ Seamless Web integrationDoctoral Defense, 26.8.2011 Vlad Trifa 25
  29. 29. Thanks for your attention! Questions?M. trifa@inf.ethz.chW. vladtrifa.comT. @vladounetB. webofthings.com
  30. 30. Part 5Backup slides
  31. 31. fears?
  32. 32. Subscriber POST Gateway (broker) ATOM Pull POST WMS Main Comet Subscriber broker WMS POST Web Hooks Gateway (broker) POST Subscriber Private sensor Local network Public network network (radio, Wi-Fi, etc.) (Ethernet LAN) (Internet)Doctoral Defense, 26.8.2011 Vlad Trifa 29
  33. 33. External query processor http://query.wisspr.net OSGi Framework JAVA QC 2. Raw Data 3. Stream HTTP/ 1. Register query output Wisspr main node AMQP [Query, CBK-URI] http://wisspr.net HTTP DC OSGi MC Client OSGi Framework HTTP 3. Stream outputDoctoral Defense, 26.8.2011 Vlad Trifa 30
  34. 34. http://www.faroutof.it real-time (raw) data streams LIVE Singapore! Web API this is youhttp://senseable.mit.edu/livesingapore
  35. 35. Web Stream details D1 Data Stream data=light,temperature& devices=D1,D2,D3 D2 t4 t3 t2 t1 Client {"time":123223, D3 "data": [{"D1":{"light":4, "temp":22}}, Devices {"D2":{"light":21, "temp":22}}, {"D3":{"light":200, "temp":33}} ] }Doctoral Defense, 26.8.2011 Vlad Trifa 32
  36. 36. Web stream with frequency and filtering Raw Data Stream L=22 L=25 L=25 L=18 L=28 L=22 sampling period YES NO YES L=25 L=22 Client Resulting Stream data=light,temperature& filter=light>20& frequency=2Doctoral Defense, 26.8.2011 Vlad Trifa 33
  37. 37. or this?http://liip.to/niwea
  38. 38. devices and servicesecosystem
  39. 39. nsport protocol to perform remote procedure calls instead of being directly integrated ine Web [244], in which case there would be no need for any additional API or descriptions ource/function. This situation gave birth to numerous debates about ROA versus SOA5 . Attribute OOA SOA ROA Granularity objects services data (resources) Main focus marshaling creation of payload addressing (URI) Addressing object instance unique endpoint individual resources Replies cacheable No No Yes API language-specific application-specific generic Lightweightness +++ + ++ Flexibility + ++ +++ Scalability +++ ++ +++ Loose-coupling + ++ +++ Simplicity +(+) + +++ Standard + ++ +++ Tools available +++ +++ + Security +++ ++ ++ Verbosity + +++ ++ Ambiguity + ++ ++ble 2.1: Overall feature comparison of different architectural styles (+ means low, ++ meadium, +++ means high). Doctoral Defense, 26.8.2011 Vlad Trifa 36