A model-driven, component generation approach for the xWoT

Outline Introduction A Meta-Model for an eXtended WoT Conclusion
A model-driven, component generation
approach for an eXtended Web of Things
Sneak Peak
A. Ruppen1
1University of Fribourg
Department of Informatics
Software Engineering Group
DIUF Symposium — Fribourg
June, 2013

1 Introduction
REST
ROA
IoT and WoT
2 A Meta-Model for an eXtended WoT
Introduction
eXtended WoT
Building Blocks
The meta-model
3 Conclusion

Outline
1 Introduction
REST
ROA
IoT and WoT
2 A Meta-Model for an eXtended WoT
Introduction
eXtended WoT
Building Blocks
The meta-model
3 Conclusion

REST - Representational State Transfer
What is REST
REST stands for Representational State Transfer.
It is neither a new protocol nor a format but an architectural
style for delivering services over a network.
The base idea is to use HTTP as a fully ﬂedged application
protocol rather than only as a transport protocol.
By that it uses the OSI stack as deﬁned.
The term goes back to Roy T. Fieldings dissertation in
2000.

REST
REST Principles
Client-Server Architecture.
Stateless Interactions.
Cache.
Uniform Interface.
Layered System.
Code-on-demand.
Fielding’s REST principles

Resource Oriented Architectures
ROA is not REST
ROA vs. REST
REST and ROA are not the same. This terminology was
introduced by Richardson & Ruby and deﬁnes criteria which
make a given web-service REST compliant.

Resource Oriented Architectures
Principles
Resources
Addressability
Statelessness
Connectedness
Uniform Interface
ROA principles

IoT and WoT

IoT and WoT I
Introduction
The IoT started with RFID tags.
The idea was to tag everydays objects and give them a
virtual counterpart.
With the recent mass-availability of cheap powerful devices
with limited network capabilities the IoT gained in interest.
It is not anymore just about RFID tags but also about
sensors and actuators.
The aim is still to make objects smart and giving them a
virtual representation.

IoT and WoT II
Introduction
However, now it is possible to act on a thing or sense a
thing.
The IoT relays on connected smart devices (the things).
However, it does not enforce any architecture or other
structure.
This lead to a highly heterogeneous situation where
communication is difﬁcult.
Many isolated "islands" of connected devices.

IoT and WoT
Example

Internet of Things
Definition
IoT - Wikipedia
The Internet of Things refers to uniquely identifiable objects and
their virtual representations in an Internet-like structure.
The term goes back to Kevin Ashton in 1999 and the
Auto-ID Center.
Interaction on the physical side should also reflect on the
virtual side and vice-versa.

Web of Things
Introduction

Web of Things
Deﬁnition
The Web of Things (WoT) stands on top of the IoT.
It adds REST as a standard to the IoT.
As a consequence, smart-devices become ﬁrst class
citizens in the web.
Communication is possible between smart-devices issued
from different sources due to the usage of RESTful
web-services.
Furthermore, the construction of mashup application is
encouraged and eased.
eHealth Example

Simple WoT Application
Thermistor Application
Movie

Mashup Applications

WoT
State of Play
The WoT has been studied for quite some time now.
Research has show how to exploit the resources available
in the WoT.
Different approaches have been proposed to further ease
the construction of mashup applications.
Some research efforts have shown how to integrate
resources not having a RESTful interface.
Semantics have been discussed and different approaches
implemented.

WoT
Open Questions
How resources can be put together has been well studied.
All resources must have a RESTful interface.
But:
How resources are structured?
are questions still open.

WoT
Open Questions
But:
What architectures are behind the RESTful interfaces?

WoT
Open Questions
But:
How the WoT space is divided into resources?

WoT
Open Questions
But:
How the WoT space is divided into resources?
What are the building blocks of the WoT?

WoT
State of Play and Open Questions

eXtended WoT
Motivation I
Why an eXtended WoT?
It is foreseeable that in a not-so-far future, there will be
more devices participating on the Web than humans.
These smart-devices are producing huge amounts of data.
Therefore, we need a mechanism to aggregate the data
before consuming it.
Service-only resources play a major role in the near future.
We don’t always have access to the tag in order to access
the resource.

eXtended WoT
Motivation II
A resource may exist without having access to the physical
side (eg. Patient Resource).
Increasing need for adding purely virtual goods like
Marketplace applications, algorithms, business processes
(code re-use).

eXtended WoT
Motivation II
A resource may exist without having access to the physical
side (eg. Patient Resource).
Increasing need for adding purely virtual goods like
Marketplace applications, algorithms, business processes
(code re-use).
Today Sensors, Actuators and Tags are ﬁrst-class citizens
of the WoT, we argue that the same should be true for
Algorithms, Decomposable Delayed Services and
Business Processes.

eXtended WoT
Definition
The eXtended WoT embraces the WoT as it is defined today
but adds virtual only goods to it. The latter have the same
privileges as sensors, actuators and tags and are treated as
first class citizens of the xWoT.
Finally, a client is not able to decide whether a given piece of
information is returned by a physical device or through an
algorithm. Such virtual goods range from simple algorithms
(unit conversion) to decomposable, possibly delayed services
and business processes.

eXtended WoT Trinity

xWoT Building Blocks
Sensors, Actuators and Tags
Smart-devices (aka Things) are the building blocks of the
WoT.
They are made of:
some electronics (device side) and
some communication capabilities (smart side)
Additionally, we can look at a smart-device as having:
an inner structure made of sensors, actuators, tags and
algorithms and
a well deﬁned interface with the outer world.
By that a smart-device is twofold.

Components I
Component based architecture is a widely accepted
approach for designing loosely coupled systems.
A component has a well deﬁned interface with the outer
world.
Its inner guts remain hidden.
Over its interface, a component can communicate with
other pieces of software however, how a component
achieves a given task is not important.
By that a component is twofold.
Components can be used to model WoT applications.

Components II
Sensors, actuators, tags and algorithms being loosely
coupled it seems natural to structure them following the
component based architectures.
Components allow for a clear division of the space into
independent entities.
Each entity can be exchanged with a new one, as long as
the RESTful interface remains the same.
As such a component represent the smallest
distinguishable entity of the WoT.

Components III

Mashup Applications I
Components can be combined in various manners to give
birth to new creative applications (Winds of Fukushima,
EPCIS etc).
Such combinations are called Mashup-Applications.
The idea behind is to take what is already there and mix it
up in a new way to create new applications.
How this can be achieved has been well studied for quite
some time now.
Approaches may be as simple as doing all the necessary
"connections" by hand or they may integrated advanced
design tools where smart-devices can be combined in a
drag-n-drop manner (Yahoo Pipes).

xWot Building Blocks
Mashup Applications II

Meta-Model
Instead of looking what is above the components level we
can look at how components are structured.
This involves simultaneously its inner guts as well as its
outer interface.
The meta-model takes care of
Structuring the inner guts of each component.

Meta-Model
outer interface.
Guiding the structure of a component’s outer interface.

Meta-Model
outer interface.
Deﬁning a clear vocabulary.

Meta-Model
outer interface.
Deﬁning a clear vocabulary.
Providing guidelines for application architects.

Summary
The above considerations leave us with a three layered
approach.

Summary
approach.
From bottom up these are:

Summary
approach.
The Meta-Model structuring the

Summary
approach.
Components, which when combined form

Summary
approach.
Mashup-Applications.

Summary
approach.
Mashup-Applications.
If the bottom two layers follow clearly deﬁned patterns, the
creation of mashup-applications is greatly simpliﬁed.

xWoT Trinity Revisited
3-layered Approach

Meta-Modeling
Deﬁnition I
3-layered approach.
From bottom-up:
Subjects under study (SUS). These are called endeavors.

Meta-Modeling
Deﬁnition I
3-layered approach.
From bottom-up:
Models describing endeavors.

Meta-Modeling
Deﬁnition I
3-layered approach.
From bottom-up:
Models describing models.

Meta-Modeling
Deﬁnition I
3-layered approach.
From bottom-up:
Models describing models.
Take UML as example.
UML can model endeavors.
UML is also its own meta-model.
UML identiﬁes the main components (for example in a
class diagram) and their relations.

Meta-Modeling
Definition II
As a model aims to describe common structures for a class of
SUS, which can then be translated into different instances of
code, a meta-model defines the common structures and
available elements of all models.
Definition - Wikipedia
Metamodeling, or meta-modeling in software engineering and
systems engineering among other disciplines, is the analysis,
construction and development of the frames, rules, constraints,
models and theories applicable and useful for modeling a
predefined class of problems.

WoT Meta-Model
Formalization I
Preliminary Considerations
The meta-model is tailored for the WoT, therefore we are
only dealing with RESTful Web-Services.
It takes into consideration an xWoT, as presented before.
This leaves us with two types of services:
Services tied to a device (or a conglomerate of devices) and
Services related to algorithms of interest for the WoT.
We call the ﬁrst category of services Physical Services and
the second Virtual Services.
Suppose that the space is already divided into
components, each one representing an entity of interest.

WoT Meta-Model
Formalization II

WoT Meta-Model
Validation I
Smart Light Bulb

WoT Meta-Model
Beneﬁts I
The Meta-Model allows the instantiation of concrete
models as shown in the example.
From the model, executable code can be generated.
The generated code is based on Java using the Jersey
framework.
Currently the tools are still a little bit rough around the
edges but, they work ﬁne for a proof-of-concept.
Using the meta-model as a base for all future model allows
for a better structure of the different components.
The meta-model takes care of the inner guts and the outer
interface of each container.

WoT Meta-Model
Beneﬁts II
The meta-model introduces a standard way of naming the
different bricks composing the WoT.
The meta-model clearly shows the relation between these
bricks.
Having a well deﬁned structure of the building blocks
makes the creation of mashup applications easier.
The meta-model does not destroy the loose coupling
between different WoT components, instead it supports
mashup-applications by providing standards on how to
structure the building blocks.

Conclusion
The WoT as we know it today has proven its usability over
the past few years and many problems have been
addressed.
However most of them related to the "top" part of our
3-layered model.
The WoT has to grow up and needs to embrace some
standards.
One of these standards is the meta-model and the
component driven approach to structure the underlying
bricks.
The WoT should not be separated from the rest of the web.
Instead it should be part of the web.
The idea of an eXtended WoT is supporting this vision: the
WoT embraces not only Things but also virtual goods.

Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Outline
4 Example: eHealth
5 REST as Roy T. Fielding
6 Resource Oriented Architectures
7 History of Web

Caregiving
Past
[Source:http://www.ﬂickr.com/photos/21734563@N04/2170058921/] Back

Caregiving
Today
[Source: http://jordanpaulmorris.blogspot.ch/2012_01_01_archive.html] Back

Caregiving
Tomorrow
[Source:http://jasonmillar.ca/ethicstechnologyandsociety/2012/03/28/its-time-to-move-beyond-ehealth/] Back

Smart Alert for a medical laboratory
Improved Workﬂow
Back

Smart Alert for a medical laboratory
Improved Workﬂow

The original System
Design Considerations
The system deployed at the hospital before starting this
project was composed of two parts:
A windows client and
the AMLS! (AMLS!)
At least the AMLS! had to be maintained by the new
system.
The system has to adapt to new devices easily.
The implementation should be platform-independent.
Back

Additional Resources
Resourcemodel
Back

REST
REST Principles
Client-Server Architecture
Separation from the user interface from data. This has many
advantages: many clients can use the service at the same time.
Servers can scale accordingly to the number of clients. The
development of the client and the server is independent.
Back

REST
REST Principles
Stateless Interactions
The server does not store any information about the client.
Upon each request a client has to send all the necessary
information the server may need to fulﬁll the operations. Think
of Basic Authentication.
Back

REST
REST Principles
Cache
A client can not tell whether the information comes directly from
the server or from any instance between him and the server
holding an up-to-date copy of this piece of information. This
greatly reduces the network trafﬁc.
Back

REST
REST Principles
Uniform Interface
Each service uses the same set of operations a client can
perform. This eliminates the need to build specific clients for
specific services. All speak the same language which greatly
simplifies service consumption.
Back

REST
REST Principles
Layered System
Each service is separated into different layers and participants
only see its direct interacting partner. A user only sees the
web-server whereas the web-server sees the database layer
and so on. This is today a common approach in n-tier
applications.
Back

REST
REST Principles
Code-on-Demand
Some of the client logic is already prepared and the client can
download these pieces of code. This is the only optional REST
principle. It was also adopted for other technologies like Java
Webstart.
Back

REST
Implementation and Usage
The most known implementation of REST is HTTP.
HTTP respects all of the mentioned principles.
Every web-browser is a REST client.
By surﬁng on the web, we use REST-like interactions every
day.
Not all interactions are strict REST: PHP for example uses
equally POST and PUT for parameter transmission.
Back

ROA
Key Principles of REST Architecture
Resource
"A resource is anything that is important enough to be
referenced as a thing in itself" (Richardson)
It is the atomic entity of a RESTful web-service and by that
the smallest item that can be addressed.
It can be seen like an object in OOP.
Back

ROA
Addressability
Every resource must be uniquely accessible.
The same data can be exposed by several resources
however, each resource has a unique identiﬁcation over
which it can be addressed.
URIs are organized in a hierarchical manner and can be
meaningful.
This allows a client to "guess" the URI of related and
similar resources.
Back

ROA
Statelessness
The interaction between a client and the server is stateless.
Upon each request, the client has to send all the
necessary information to fulﬁll the request.
This greatly simpliﬁes the server logic.
Different clients can implement different behaviors based
on client-sessions.
Back

ROA
Connectedness
Hypertext as the Engine of Application State (HATEOAS).
All subsequent resources can be discovered through links
contained in the representation of the ﬁrst retrieved
resource.
This principle is highly related to how the web works today:
Upon landing on one side, a user can continue browsing
and discover related content by clicking on links.
Back

ROA
Uniform Interface
Use HTTP verbs to deﬁne the action to execute on a given
resource.
HTTP "methods should always do what they are ought to
do".
Use these verbs correctly (POST vs PUT).
Respect idempotence of GET, PUT and DELETE.
Respect safety of GET.
Back

The history of the Web
The Web
The Web is based on HTTP (Hypertext Transfer Protocol).
The history of HTTP goes back to Tim Berners Lee and
the CERN.
It’s ﬁrst version was 0.7 and was part of the set of protocols
for the world wide web project.
At that time only HTML (HyperText Markup Language)
documents could be transmitted.
Since then HTML and HTTP are the building block of the
Web as we know it today.
Currently HTTP is at version 1.1, based on RFC (Request
for comment) 2616.
One of the main contributors is Roy T. Fielding.

The history of the Web I
Evolution of the Web
Since the beginning we have seen 3 major “types” of the Web.
Web 1.0
The Web 1.0 is the Web as proposed by Tim B. Lee. It’s
purpose is to transmit static documents over the network. The
content was mainly simple HTML documents on servers.

The history of the Web II

Web 1.5
The Web 1.5 is dominated by CGI (Common Gateway
Interface) Scripts allowing dynamic content to be served. The
most prominent implementation of this approach is PHP
(Personal Home Page Tool). Also Javascript emerged as client
side scripting language and allows all sorts of unreasonably
usage to “enhance” the look of web-pages.

Web 2.0
Social acceptance and broadband internet connections lead to
new approaches on how data is consumed and produced. The
user becomes active is the primary source of new content. The
web grows and many services are for free in exchange of
information gathered directly from the user. Social aspects
grow in interest.

The history of the Web II
(j) Twitter (k) Youtube
(l) Facebook

A model-driven, component generation approach for the xWoT

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (8)

Similar to A model-driven, component generation approach for the xWoT

Similar to A model-driven, component generation approach for the xWoT (20)

More from Andreas Ruppen

More from Andreas Ruppen (10)

A model-driven, component generation approach for the xWoT