A Model-Driven, Component Generation Approach for the WoTThesis

Overview

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

INTRODUCTION& Vision

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.

BACKGROUNDHistorical and Technological

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

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)

Meta-Model

• Given• α:S→M

• Then• ∃ SUS1, SUS2 S|∈

α(SUS1) = α(SUS2) ⇏SUS1 = SUS2

Meta-Model

• Given• α′ : M → MM

• Then• ∃ m1,m2 M | α′∈

(m1) = α′(m2) ⇏ m1 = m2

The xWoTAn Extension for the WoT

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.

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.

COMPONENTSReusable xWoT Components

Example

Expected Output

• One component representing the floor.• One component for each instantiated door.

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

META-MODELINGThe xWoT Meta-Model

Partial xWoT Meta-Model

Full xWoT Meta-Model

Smart Door Example (UC)

Smart Door Example (HW)

Smart Door Example (M)

Smart Door Example (M)

Smart Door Example (M)

Smart Door Example (M)

Smart Door Example (M)

COMPILERA Model Compiler for the xWoT

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.

Smart Door Example (rev)

Smart Door Example (rev)

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.

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.

Smart Door Example (rev)

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

Smart Room Example (UC)

Smart Room Example (UC)

METHODOLOGY

Three Steps

• Entity Modeling (blue)• Data Modeling (green)• Implementation (yellow)

Methodology

Entity Modeling

• Derive an xWoT compatible Model from the Use-Case diagrams.

• Refine the generated enhanced Model.

• Compile the xWoT Model to Code Skeletons.

Data Modeling

• Describe Inputs and Outputs in a generic way (XML Schemas, Database Definition)

• Derive implementations from these schemas.

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.

CONCLUSION& Outlook

Future Work

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