A model driven approach to automatically generate WoT compatible code skeletons to hook up smart devices and bring the to the WoT.

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