A model-driven, component generation approach for the xWoT

Outline Introduction A Meta-Model for an eXtended WoT Conclusion

A model-driven, component generationapproach for an eXtended Web of Things

Sneak Peak

A. Ruppen1

1University of FribourgDepartment of Informatics

Software Engineering Group

DIUF Symposium — FribourgJune, 2013


1 IntroductionRESTROAIoT and WoT

2 A Meta-Model for an eXtended WoTIntroductioneXtended WoTBuilding BlocksThe meta-model

3 Conclusion


Outline



3 Conclusion


REST - Representational State TransferWhat is REST

REST stands for Representational State Transfer.It is neither a new protocol nor a format but an architecturalstyle for delivering services over a network.The base idea is to use HTTP as a fully fledged applicationprotocol rather than only as a transport protocol.By that it uses the OSI stack as defined.The term goes back to Roy T. Fieldings dissertation in2000.


RESTREST Principles

Client-Server Architecture.Stateless Interactions.Cache.Uniform Interface.Layered System.Code-on-demand.

Fielding’s REST principles


Resource Oriented ArchitecturesROA is not REST

ROA vs. RESTREST and ROA are not the same. This terminology wasintroduced by Richardson & Ruby and defines criteria whichmake a given web-service REST compliant.


Resource Oriented ArchitecturesPrinciples

ResourcesAddressabilityStatelessnessConnectednessUniform Interface

ROA principles


IoT and WoT


IoT and WoT


IoT and WoT


IoT and WoT IIntroduction

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


IoT and WoT IIIntroduction

However, now it is possible to act on a thing or sense athing.The IoT relays on connected smart devices (the things).However, it does not enforce any architecture or otherstructure.This lead to a highly heterogeneous situation wherecommunication is difficult.Many isolated "islands" of connected devices.


IoT and WoTExample


Internet of ThingsDefinition

IoT - WikipediaThe Internet of Things refers to uniquely identifiable objects andtheir virtual representations in an Internet-like structure.

The term goes back to Kevin Ashton in 1999 and theAuto-ID Center.Interaction on the physical side should also reflect on thevirtual side and vice-versa.


Web of ThingsIntroduction


Web of ThingsDefinition

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 first classcitizens in the web.Communication is possible between smart-devices issuedfrom different sources due to the usage of RESTfulweb-services.Furthermore, the construction of mashup application isencouraged and eased.

eHealth Example


Simple WoT ApplicationThermistor Application

Movie

movies/request_temp_sensor.ogv


Mashup Applications


Outline



3 Conclusion


WoTState of Play

The WoT has been studied for quite some time now.Research has show how to exploit the resources availablein the WoT.Different approaches have been proposed to further easethe construction of mashup applications.Some research efforts have shown how to integrateresources not having a RESTful interface.Semantics have been discussed and different approachesimplemented.


WoTOpen Questions

How resources can be put together has been well studied.All resources must have a RESTful interface.But:

How resources are structured?

What architectures are behind the RESTful interfaces?How the WoT space is divided into resources?What are the building blocks of the WoT?

are questions still open.


WoTOpen Questions


How resources are structured?What architectures are behind the RESTful interfaces?

How the WoT space is divided into resources?What are the building blocks of the WoT?



WoTOpen Questions


How resources are structured?What architectures are behind the RESTful interfaces?How the WoT space is divided into resources?

What are the building blocks of the WoT?



WoTOpen Questions


How resources are structured?What architectures are behind the RESTful interfaces?How the WoT space is divided into resources?What are the building blocks of the WoT?



WoTState of Play and Open Questions


WoTState of Play and Open Questions


eXtended WoTMotivation I

Why an eXtended WoT?It is foreseeable that in a not-so-far future, there will bemore devices participating on the Web than humans.These smart-devices are producing huge amounts of data.Therefore, we need a mechanism to aggregate the databefore 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 accessthe resource.


eXtended WoTMotivation II

A resource may exist without having access to the physicalside (eg. Patient Resource).Increasing need for adding purely virtual goods likeMarketplace applications, algorithms, business processes(code re-use).

Today Sensors, Actuators and Tags are first-class citizensof the WoT, we argue that the same should be true forAlgorithms, Decomposable Delayed Services andBusiness Processes.


eXtended WoTMotivation II

A resource may exist without having access to the physicalside (eg. Patient Resource).Increasing need for adding purely virtual goods likeMarketplace applications, algorithms, business processes(code re-use).Today Sensors, Actuators and Tags are first-class citizensof the WoT, we argue that the same should be true forAlgorithms, Decomposable Delayed Services andBusiness Processes.


eXtended WoTDefinition

The eXtended WoT embraces the WoT as it is defined todaybut adds virtual only goods to it. The latter have the sameprivileges as sensors, actuators and tags and are treated asfirst class citizens of the xWoT.Finally, a client is not able to decide whether a given piece ofinformation is returned by a physical device or through analgorithm. Such virtual goods range from simple algorithms(unit conversion) to decomposable, possibly delayed servicesand business processes.


eXtended WoT Trinity


xWoT Building BlocksSensors, Actuators and Tags

Smart-devices (aka Things) are the building blocks of theWoT.They are made of:

some electronics (device side) andsome communication capabilities (smart side)

Additionally, we can look at a smart-device as having:an inner structure made of sensors, actuators, tags andalgorithms anda well defined interface with the outer world.

By that a smart-device is twofold.


xWoT Building BlocksComponents I

Component based architecture is a widely acceptedapproach for designing loosely coupled systems.A component has a well defined interface with the outerworld.Its inner guts remain hidden.Over its interface, a component can communicate withother pieces of software however, how a componentachieves a given task is not important.By that a component is twofold.Components can be used to model WoT applications.


xWoT Building BlocksComponents II

Sensors, actuators, tags and algorithms being looselycoupled it seems natural to structure them following thecomponent based architectures.Components allow for a clear division of the space intoindependent entities.Each entity can be exchanged with a new one, as long asthe RESTful interface remains the same.As such a component represent the smallestdistinguishable entity of the WoT.


xWoT Building BlocksComponents III


xWoT Building BlocksMashup Applications I

Components can be combined in various manners to givebirth 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 itup in a new way to create new applications.How this can be achieved has been well studied for quitesome time now.Approaches may be as simple as doing all the necessary"connections" by hand or they may integrated advanceddesign tools where smart-devices can be combined in adrag-n-drop manner (Yahoo Pipes).


xWot Building BlocksMashup Applications II


xWot Building BlocksMashup Applications II


xWoT Building BlocksMeta-Model

Instead of looking what is above the components level wecan look at how components are structured.This involves simultaneously its inner guts as well as itsouter interface.The meta-model takes care of

Structuring the inner guts of each component.

Guiding the structure of a component’s outer interface.Defining a clear vocabulary.Providing guidelines for application architects.




Structuring the inner guts of each component.Guiding the structure of a component’s outer interface.

Defining a clear vocabulary.Providing guidelines for application architects.




Structuring the inner guts of each component.Guiding the structure of a component’s outer interface.Defining a clear vocabulary.

Providing guidelines for application architects.




Structuring the inner guts of each component.Guiding the structure of a component’s outer interface.Defining a clear vocabulary.Providing guidelines for application architects.


xWoT Building BlocksSummary

The above considerations leave us with a three layeredapproach.

From bottom up these are:

The Meta-Model structuring theComponents, which when combined formMashup-Applications.

If the bottom two layers follow clearly defined patterns, thecreation of mashup-applications is greatly simplified.



The above considerations leave us with a three layeredapproach.From bottom up these are:






The Meta-Model structuring the

Components, which when combined formMashup-Applications.





The Meta-Model structuring theComponents, which when combined form

Mashup-Applications.













xWoT Trinity Revisited3-layered Approach


Meta-ModelingDefinition I

3-layered approach.From bottom-up:

Subjects under study (SUS). These are called endeavors.

Models describing endeavors.Models describing models.

Take UML as example.UML can model endeavors.UML is also its own meta-model.UML identifies the main components (for example in aclass diagram) and their relations.




Subjects under study (SUS). These are called endeavors.Models describing endeavors.

Models describing models.





Subjects under study (SUS). These are called endeavors.Models describing endeavors.Models describing models.





Subjects under study (SUS). These are called endeavors.Models describing endeavors.Models describing models.



Meta-ModelingDefinition II

As a model aims to describe common structures for a class ofSUS, which can then be translated into different instances ofcode, a meta-model defines the common structures andavailable elements of all models.

Definition - WikipediaMetamodeling, or meta-modeling in software engineering andsystems engineering among other disciplines, is the analysis,construction and development of the frames, rules, constraints,models and theories applicable and useful for modeling apredefined class of problems.


WoT Meta-ModelFormalization I

Preliminary ConsiderationsThe meta-model is tailored for the WoT, therefore we areonly 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) andServices related to algorithms of interest for the WoT.

We call the first category of services Physical Services andthe second Virtual Services.Suppose that the space is already divided intocomponents, each one representing an entity of interest.


WoT Meta-ModelFormalization II


WoT Meta-ModelValidation I

Smart Light Bulb


WoT Meta-ModelBenefits I

The Meta-Model allows the instantiation of concretemodels as shown in the example.From the model, executable code can be generated.The generated code is based on Java using the Jerseyframework.Currently the tools are still a little bit rough around theedges but, they work fine for a proof-of-concept.Using the meta-model as a base for all future model allowsfor a better structure of the different components.The meta-model takes care of the inner guts and the outerinterface of each container.


WoT Meta-ModelBenefits II

The meta-model introduces a standard way of naming thedifferent bricks composing the WoT.The meta-model clearly shows the relation between thesebricks.Having a well defined structure of the building blocksmakes the creation of mashup applications easier.The meta-model does not destroy the loose couplingbetween different WoT components, instead it supportsmashup-applications by providing standards on how tostructure the building blocks.


Outline



3 Conclusion


Conclusion

The WoT as we know it today has proven its usability overthe past few years and many problems have beenaddressed.However most of them related to the "top" part of our3-layered model.The WoT has to grow up and needs to embrace somestandards.One of these standards is the meta-model and thecomponent driven approach to structure the underlyingbricks.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: theWoT 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


CaregivingPast

[Source:http://www.flickr.com/photos/21734563@N04/2170058921/] Back


CaregivingToday

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


CaregivingTomorrow

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


CaregivingTomorrow



CaregivingTomorrow



CaregivingTomorrow



Smart Alert for a medical laboratoryImproved Workflow

Back



Back



Back


The original SystemDesign Considerations

The system deployed at the hospital before starting thisproject was composed of two parts:

A windows client andthe AMLS! (AMLS!)

At least the AMLS! had to be maintained by the newsystem.The system has to adapt to new devices easily.The implementation should be platform-independent.

Back


Additional ResourcesResourcemodel

Back


Outline

4 Example: eHealth



7 History of Web


RESTREST Principles

Client-Server ArchitectureSeparation from the user interface from data. This has manyadvantages: many clients can use the service at the same time.Servers can scale accordingly to the number of clients. Thedevelopment of the client and the server is independent.

Back


RESTREST Principles

Stateless InteractionsThe server does not store any information about the client.Upon each request a client has to send all the necessaryinformation the server may need to fulfill the operations. Thinkof Basic Authentication.

Back


RESTREST Principles

CacheA client can not tell whether the information comes directly fromthe server or from any instance between him and the serverholding an up-to-date copy of this piece of information. Thisgreatly reduces the network traffic.

Back


RESTREST Principles

Uniform InterfaceEach service uses the same set of operations a client canperform. This eliminates the need to build specific clients forspecific services. All speak the same language which greatlysimplifies service consumption.

Back


RESTREST Principles

Layered SystemEach service is separated into different layers and participantsonly see its direct interacting partner. A user only sees theweb-server whereas the web-server sees the database layerand so on. This is today a common approach in n-tierapplications.

Back


RESTREST Principles

Code-on-DemandSome of the client logic is already prepared and the client candownload these pieces of code. This is the only optional RESTprinciple. It was also adopted for other technologies like JavaWebstart.

Back


RESTImplementation 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 surfing on the web, we use REST-like interactions everyday.Not all interactions are strict REST: PHP for example usesequally POST and PUT for parameter transmission.

Back


Outline

4 Example: eHealth



7 History of Web


ROAKey Principles of REST Architecture

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

Back



AddressabilityEvery resource must be uniquely accessible.The same data can be exposed by several resourceshowever, each resource has a unique identification overwhich it can be addressed.URIs are organized in a hierarchical manner and can bemeaningful.This allows a client to "guess" the URI of related andsimilar resources.

Back



StatelessnessThe interaction between a client and the server is stateless.Upon each request, the client has to send all thenecessary information to fulfill the request.This greatly simplifies the server logic.Different clients can implement different behaviors basedon client-sessions.

Back



ConnectednessHypertext as the Engine of Application State (HATEOAS).All subsequent resources can be discovered through linkscontained in the representation of the first retrievedresource.This principle is highly related to how the web works today:Upon landing on one side, a user can continue browsingand discover related content by clicking on links.

Back



Uniform InterfaceUse HTTP verbs to define the action to execute on a givenresource.HTTP "methods should always do what they are ought todo".Use these verbs correctly (POST vs PUT).Respect idempotence of GET, PUT and DELETE.Respect safety of GET.

Back


Outline

4 Example: eHealth



7 History of Web


The history of the WebThe Web

The Web is based on HTTP (Hypertext Transfer Protocol).The history of HTTP goes back to Tim Berners Lee andthe CERN.It’s first version was 0.7 and was part of the set of protocolsfor 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 theWeb as we know it today.Currently HTTP is at version 1.1, based on RFC (Requestfor comment) 2616.One of the main contributors is Roy T. Fielding.


The history of the Web IEvolution of the Web

Since the beginning we have seen 3 major “types” of the Web.

Web 1.0The Web 1.0 is the Web as proposed by Tim B. Lee. It’spurpose is to transmit static documents over the network. Thecontent was mainly simple HTML documents on servers.


The history of the Web IIEvolution of the Web



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



Web 2.0Social acceptance and broadband internet connections lead tonew approaches on how data is consumed and produced. Theuser becomes active is the primary source of new content. Theweb grows and many services are for free in exchange ofinformation gathered directly from the user. Social aspectsgrow in interest.


The history of the Web IIEvolution of the Web

(j) Twitter (k) Youtube

(l) Facebook

Documents

A model-driven, component generation approach for the xWoT