1.
Workshop Slides
■ All slides will be
Available After the
Worksohp on
■ http://webofthings.org/
events/wot/
10/27/15

2.
A COMPONENT BASED
APPROACH FOR THE WEB OF
THINGS
10/27/15

3.
What’s missing
■ Data integration: treat algorithms and other restful
services as first class citizens.
■ Event architecture: define a common event
architecture suitable for a wide range of applications.
■ Building blocks: introduce components as the building
blocks of the xwot.
10/27/15

4.
Data Integration
■ Classic WoT
– Smart devices
– Sensors, Actuators
■ Classic Web
– Google
– Facebook
– Yahoo Weather API
■ eXtended WoT as
combination of
– Classic WoT &
– Classic Web
Everything that is machine
consumable -> xWoT
10/27/15

5.
Events
■ Today: use of IoTaaS platforms like Xively.
■ Problem: smart-devices are no longer WoT compliant.
Instead the IoTaaS platform is.
■ Events must propagate in an (energy) efficient manner.
– Webhooks: spare events, alerting
– WebSockets: many events, live monitoring
10/27/15

6.
Building Blocks
■ (Software) Components as
bricks of the xWoT.
■ Components are key to re-
usability.
■ Components need to follow
guidelines and best-
practices.
Mashup
xWoT
Component
xWoT
Component
Actuators
Sensors
Tags
Algorihms
xWoT Meta Model
10/27/15

7.
Vision
■ Instead of finding better approaches on how to combine smart
devices we have to re-think how to build smart devices.
– The current WoT needs to be extended to take into
consideration algorithms and handle events gracefully.
– Re-usable and easy to deploy components, taking care of
aspects like events (and discovery in the future) are the way out
of the “things-crisis”.
– Adopt model driven architecture.
– Allow models to be enhanced semantically.
10/27/15

8.
Full xWoT Model
Virtual Entity
Resource
Actuator
Resource
Sensor
Resource
Service
Resource
1..*
Publisher
Resource
Context
Resource
Physical Entity
Entity
0..1 1
DeviceTag SensorActuator
1..*
name: EString
method: MethodOperation
output: MethodOutput
input: MethodInput
Method
style: MethodStyle
MethodParam
style: MethodStyle
VEntityParam
name: EString
type: EString
Param
TEMPLATE
QUERY
MethodStyle
XMLJSON
MULTIPARTRELATED
FORM
NONE
MethodInput
XMLJSON
MULTIPARTRELATED
FORM
NONE
MethodOutput
GET
PUT
POST
DELETE
MethodOperation
0..* 0..*
0..*
10/27/15

9.
SMART DOOR
Example Use-Case
10/27/15

10.
Smart Door Example (UC)
10/27/15

11.
Smart Door Example (M)
10/27/15

12.
Smart Door Example (M)
10/27/15

13.
Smart Door Example (M)
10/27/15

14.
Smart Door Example (M)
10/27/15

15.
Smart Door Example (M)
10/27/15

16.
COMPILER
A Model Compiler for the xWoT
10/27/15

17.
Model Enhancer
■ Since there is a one-to-one mapping from the physical entity to
the virtual entity, for each physical model, its virtual side can be
generated.
■ The generated virtual side can be further refined manually.
■ Takes as input an xWoT model and generates a new, enhanced
xwot model.
■ Where additional information is needed, the compiler asks for
user input.
10/27/15

18.
Smart Door Example (rev)
10/27/15

19.
Smart Door Example (rev)
10/27/15

20.
Model Compiler
■ Once the model finished, it can be compiled into code skeletons.
■ The compiler takes care of:
– Resources hierarchy.
– Allowed methods.
■ It can generate:
– Python code (autobahn)
– Node.Js
– Etc.
10/27/15

21.
Smart Door Example (rev)
10/27/15

22.
Reusability
■ The compiler takes care of:
– The reusability of the generated components.
– To create a new restful service for each composite (according to
the composed flag).
– Of the application scenario service
10/27/15

23.
Smart Room Example (Revisited)
10/27/15

24.
Smart Room Example (Revisited)
10/27/15

25.
Future Work
■ Bring the different projects together
– S2mashup
– Semantics
– Discovery
– Meta-model
■ Propose a fully integrated tool for developers as well
as for end users to either create new smart things or
exploit deployed ones.
10/27/15