Successfully reported this slideshow.

Vlad Trifa - Final PhD Thesis Defense at ETH Zurich

9

Share

Upcoming SlideShare
RESTifyng Physical Products
RESTifyng Physical Products
Loading in …3
×
1 of 40
1 of 40

Vlad Trifa - Final PhD Thesis Defense at ETH Zurich

9

Share

Download to read offline

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.

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.

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Vlad Trifa - Final PhD Thesis Defense at ETH Zurich

  1. 1. Building Blocks for a Participatory Web of Things: Devices, Infrastructures, and Programming Frameworks Doctoral Defense – 26 August 2011 Vlad 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 logistics Doctoral 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 processing Doctoral 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 & faster Doctoral 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 1 Web-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 layer Doctoral 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 2 Distributed 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 Discovery Doctoral 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 router Doctoral 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 router Doctoral 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 ../spot Doctoral Defense, 26.8.2011 Vlad Trifa 15
  19. 19. Part 3 Web-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 sockets Doctoral 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 sensing applications. 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 communication Doctoral Defense, 26.8.2011 Vlad Trifa 19
  23. 23. Part 4 End-to-end Event-driven Applications
  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 SC Doctoral 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 coupling Doctoral 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 integration Doctoral Defense, 26.8.2011 Vlad Trifa 25
  29. 29. Thanks for your attention! Questions? M. trifa@inf.ethz.ch W. vladtrifa.com T. @vladounet B. webofthings.com
  30. 30. Part 5 Backup 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 output Doctoral Defense, 26.8.2011 Vlad Trifa 30
  34. 34. http://www.faroutof.it real-time (raw) data streams LIVE Singapore! Web API this is you http://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=2 Doctoral Defense, 26.8.2011 Vlad Trifa 33
  37. 37. or this? http://liip.to/niwea
  38. 38. devices and services ecosystem
  39. 39. nsport protocol to perform remote procedure calls instead of being directly integrated in e 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, ++ mea dium, +++ means high). Doctoral Defense, 26.8.2011 Vlad Trifa 36

×