Building Blocks for a Participatory Web of Things

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


Problem Statement

How to create an infrastructure
for facilitating the development
of asynchronous DSAs on top of
heterogeneous, mobile NEDs?


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


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?


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.


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.


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


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]

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.

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)


API, etc.)
1
LAN

Router
LAN (Ethernet) LAN

2
2. Gateway polls the DHCP
Gateway
allocation table on the router


API, etc.)
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


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


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

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.


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


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

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


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.

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]


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

Thanks for your attention!

Questions?

M. trifa@inf.ethz.ch
W. vladtrifa.com
T. @vladounet
B. webofthings.com

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)


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


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
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}}
]
}


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
filter=light>20&
frequency=2


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).

Building Blocks for a Participatory Web of Things

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Building Blocks for a Participatory Web of Things

Similar a Building Blocks for a Participatory Web of Things (20)

Último

Último (20)

Building Blocks for a Participatory Web of Things