Building Blocks for a Participatory Web of Things:
Devices, Infrastructures, and Programming Frameworks
Doctoral Defense – 26 August 2011
Vlad Trifa

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

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

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

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

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

Part 1
Web-enabled Devices

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

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

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

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

Part 2
Distributed Infrastructures

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

Service 1: HTTP-based Devices and Resources Discovery
Doctoral Defense, 26.8.2011 Vlad Trifa 14

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

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

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

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

Part 3
Web-based Messaging

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

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

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

Part 4
End-to-end Event-driven
Applications

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

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

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

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

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

Thanks for your attention!
Questions?
M. trifa@inf.ethz.ch
W. vladtrifa.com
T. @vladounet
B. webofthings.com

Part 5
Backup slides

fears?

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

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

http://www.faroutof.it
real-time
(raw) data streams
LIVE Singapore!
Web API
this is you
http://senseable.mit.edu/livesingapore

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

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

or this?
http://liip.to/niwea

devices and services
ecosystem

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