1. A Model-Driven,
Component Generation
Approach for the WoT
Thesis

2. Overview
• Vision
• Historical and Technological Background
• The xWoT
• A component approach for the xWoT
• Meta-Modeling
• The xWoT Compiler
• Methodology
• Outlook

3. INTRODUCTION
& Vision

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

5. BACKGROUND
Historical and Technological

6. REST vs. ROA
REST
• Client-Server
• Statelessness
• Cache
• Uniform Interface
• Layered System
• Code-on-demand
ROA
• Concepts
• Resources
• Representations
• URIs
• Properties
• Uniform Interface
• Addressability
• Statelessness
• Connectedness

7. Software Components
• According to Cox the solution to the software crisis in the
early 80’s.
• A software component is a unit of composition with
contractually specified interfaces and explicit context
dependencies only. A software component can be
deployed independently and is subject to composition by
third parties. (Szyperski)

8. Meta-Model
• Given
• α:S→M
• Then
• ∃ SUS1, SUS2 ∈
S|α(SUS1) =
α(SUS2) ⇏SUS1 =
SUS2

9. Meta-Model
• Given
• α′ : M → MM
• Then
• ∃ m1,m2 ∈ M |
α′(m1) = α′(m2)
⇏ m1 = m2

10. The xWoT
An Extension for the WoT

11. WoT Problems
• 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.

12. Formal Definition
• The extended WoT is a web made of sensors, actuators and tags
forming the classical WoT plus services respecting RESTful
principles.
• The aim of the xWoT is to introduce a standard approach on how to
design the building blocks for novel applications and mashups
exploiting the capabilities offered by smart things and other virtual
goods. To achieve this goal, the xWoT introduces a component-
based methodology which is underlined by a meta-model guiding the
developers during crucial architectural decisions. Finally, since the
architecture respects the xWoT’s meta-model, component skeletons
are generated out of the specifications.

13. COMPONENTS
Reusable xWoT Components

14. Example

15. Expected Output
• One component representing the floor.
• One component for each instantiated door.

16. SmartDoor Component
http://service1.com/door/ GET
http://service1.com/door/oc/ GET / PUT
http://service1.com/door/oc/pub/ various
http://service1.com/door/lu/ GET / PUT
http://service1.com/door/lu/pub/ various
SmartFloor
http://service2.com/floor/ GET
http://service2.com/floor/{id} GET
http://service2.com/floor/{id}/oc GET / PUT
http://service2.com/floor/{id}/oc/pub/ various
http://service2.com/floor/{id}/lu/ GET / PUT
http://service2.com/floor/{id}/lu/pub/ various

17. META-MODELING
The xWoT Meta-Model

18. Partial xWoT Meta-Model

19. Full xWoT Meta-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..*

20. Smart Door Example (UC)

21. Smart Door Example (HW)

22. Smart Door Example (M)

23. Smart Door Example (M)

24. Smart Door Example (M)

25. Smart Door Example (M)

26. Smart Door Example (M)

27. COMPILER
A Model Compiler for the xWoT

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

29. Smart Door Example (rev)

30. Smart Door Example (rev)

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

32. Model Compiler
• Takes as input an xWoT model and automatically
generates a REST service for each component.
• Each components contains code skeletons to be filled in
by the developer.

33. Smart Door Example (rev)

34. Reusability
• The Compiler takes care of the reusability of the
generated components.
• For each Composite, the compiler takes care to create a
new RESTful service (if necessary)
• The Compiler takes care of the Application Scenario
Service

35. Smart Room Example (UC)

36. Smart Room Example (UC)

37. METHODOLOGY

38. Three Steps
• Entity Modeling (blue)
• Data Modeling (green)
• Implementation (yellow)

39. Methodology
Implement HTTP
Responses
Define Entity
Model Entity
Physical
2
Virtual
REST
Skeleton
Model
Physical Entity
Model
Virtual Entity
Refine
Virtual Entity
Create Sever
Skeleton
Link Code to
Hardware
Build
Hardware
Model Representations
Create
XSD
Create Code
Artifacts
Model Database
Create
ERM
Forward
Engineer
DB
Create
Code
Artifacts

40. Entity Modeling
• Derive an xWoT
compatible Model from
the Use-Case diagrams.
• Refine the generated
enhanced Model.
• Compile the xWoT
Model to Code
Skeletons.

41. Data Modeling
• Describe Inputs and Outputs in a
generic way (XML Schemas,
Database Definition)
• Derive implementations from
these schemas.

42. Implementation
• Create one Application Scenario Service.
• Create one Service for each Component.
• Implement the Hardware.
• Fill in the missing parts in the generated skeletons.
• Link the Hardware to the REST service.

43. CONCLUSION
& Outlook

44. Future Work
• Filtering of events for WebHook clients with a DSL.
• What about Discovery?
• What about Semantics?
• Intelligent Discovery
• Late Binding in Mashup Applications