A component based architecture for the Web of Things
-
Upload
andreas-ruppen -
Category
Science
-
view
1.818 -
download
3
Transcript of A component based architecture for the Web of Things
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