Workshop Slides■ All slides will be

Available After the Worksohp on

■ http://webofthings.org/events/wot/

10/27/15

A COMPONENT BASED APPROACH FOR THE WEB OF

THINGS

10/27/15

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

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

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

Building Blocks

■ (Software) Components as bricks of the xWoT.

■ Components are key to re-usability.

■ Components need to follow guidelines and best-practices.

Mashup

xWoTComponent

xWoTComponent

ActuatorsSensors

Tags Algorihms

xWoT Meta Model

10/27/15

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

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: EStringmethod: MethodOperationoutput: MethodOutputinput: MethodInput

Method

style: MethodStyleMethodParam

style: MethodStyleVEntityParam

name: EStringtype: EString

ParamTEMPLATEQUERY

MethodStyleXMLJSONMULTIPARTRELATEDFORMNONE

MethodInputXMLJSONMULTIPARTRELATEDFORMNONE

MethodOutputGETPUTPOSTDELETE

MethodOperation

0..* 0..*

0..*

10/27/15

SMART DOORExample Use-Case

10/27/15

Smart Door Example (UC)

10/27/15

Smart Door Example (M)

10/27/15

Smart Door Example (M)

10/27/15

Smart Door Example (M)

10/27/15

Smart Door Example (M)

10/27/15

Smart Door Example (M)

10/27/15

COMPILERA Model Compiler for the xWoT

10/27/15

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

Smart Door Example (rev)

10/27/15

Smart Door Example (rev)

10/27/15

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

Smart Door Example (rev)

10/27/15

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

Smart Room Example (Revisited)

10/27/15

Smart Room Example (Revisited)

10/27/15

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