A RESTful architecture for integrating decomposable delayed services within t...
A model-driven, component generation approach for the xWoT
1. 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
2. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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
3. Outline Introduction A Meta-Model for an eXtended WoT 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
4. Outline Introduction A Meta-Model for an eXtended WoT 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 fledged application
protocol 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 in
2000.
5. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
REST
REST Principles
Client-Server Architecture.
Stateless Interactions.
Cache.
Uniform Interface.
Layered System.
Code-on-demand.
Fielding’s REST principles
6. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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 defines criteria which
make a given web-service REST compliant.
7. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
Resource Oriented Architectures
Principles
Resources
Addressability
Statelessness
Connectedness
Uniform Interface
ROA principles
11. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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.
12. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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 difficult.
Many isolated "islands" of connected devices.
14. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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.
15. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
Web of Things
Introduction
16. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
Web of Things
Definition
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 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
17. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
Simple WoT Application
Thermistor Application
Movie
19. Outline Introduction A Meta-Model for an eXtended WoT 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
20. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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.
21. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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.
22. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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?
What architectures are behind the RESTful interfaces?
are questions still open.
23. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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?
What architectures are behind the RESTful interfaces?
How the WoT space is divided into resources?
are questions still open.
24. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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?
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.
25. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
WoT
State of Play and Open Questions
26. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
WoT
State of Play and Open Questions
27. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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.
28. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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).
29. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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 first-class citizens
of the WoT, we argue that the same should be true for
Algorithms, Decomposable Delayed Services and
Business Processes.
30. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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.
32. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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 defined interface with the outer world.
By that a smart-device is twofold.
33. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
Components I
Component based architecture is a widely accepted
approach for designing loosely coupled systems.
A component has a well defined 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.
34. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
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.
35. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
Components III
36. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
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).
37. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWot Building Blocks
Mashup Applications II
38. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWot Building Blocks
Mashup Applications II
39. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
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.
40. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
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.
Guiding the structure of a component’s outer interface.
41. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
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.
Guiding the structure of a component’s outer interface.
Defining a clear vocabulary.
42. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
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.
Guiding the structure of a component’s outer interface.
Defining a clear vocabulary.
Providing guidelines for application architects.
43. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
Summary
The above considerations leave us with a three layered
approach.
44. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
Summary
The above considerations leave us with a three layered
approach.
From bottom up these are:
45. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
Summary
The above considerations leave us with a three layered
approach.
From bottom up these are:
The Meta-Model structuring the
46. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
Summary
The above considerations leave us with a three layered
approach.
From bottom up these are:
The Meta-Model structuring the
Components, which when combined form
47. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
Summary
The above considerations leave us with a three layered
approach.
From bottom up these are:
The Meta-Model structuring the
Components, which when combined form
Mashup-Applications.
48. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Building Blocks
Summary
The above considerations leave us with a three layered
approach.
From bottom up these are:
The Meta-Model structuring the
Components, which when combined form
Mashup-Applications.
If the bottom two layers follow clearly defined patterns, the
creation of mashup-applications is greatly simplified.
49. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
xWoT Trinity Revisited
3-layered Approach
50. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
Meta-Modeling
Definition I
3-layered approach.
From bottom-up:
Subjects under study (SUS). These are called endeavors.
51. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
Meta-Modeling
Definition I
3-layered approach.
From bottom-up:
Subjects under study (SUS). These are called endeavors.
Models describing endeavors.
52. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
Meta-Modeling
Definition I
3-layered approach.
From bottom-up:
Subjects under study (SUS). These are called endeavors.
Models describing endeavors.
Models describing models.
53. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
Meta-Modeling
Definition 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 a
class diagram) and their relations.
54. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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.
55. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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 first 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.
56. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
WoT Meta-Model
Formalization II
57. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
WoT Meta-Model
Validation I
Smart Light Bulb
58. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
WoT Meta-Model
Benefits 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 fine 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.
59. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
WoT Meta-Model
Benefits 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 defined 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.
60. Outline Introduction A Meta-Model for an eXtended WoT 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
61. Outline Introduction A Meta-Model for an eXtended WoT Conclusion
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.
62. 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
63. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Caregiving
Past
[Source:http://www.flickr.com/photos/21734563@N04/2170058921/] Back
64. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Caregiving
Today
[Source: http://jordanpaulmorris.blogspot.ch/2012_01_01_archive.html] Back
65. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Caregiving
Tomorrow
[Source:http://jasonmillar.ca/ethicstechnologyandsociety/2012/03/28/its-time-to-move-beyond-ehealth/] Back
66. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Caregiving
Tomorrow
[Source:http://jasonmillar.ca/ethicstechnologyandsociety/2012/03/28/its-time-to-move-beyond-ehealth/] Back
67. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Caregiving
Tomorrow
[Source:http://jasonmillar.ca/ethicstechnologyandsociety/2012/03/28/its-time-to-move-beyond-ehealth/] Back
68. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Caregiving
Tomorrow
[Source:http://jasonmillar.ca/ethicstechnologyandsociety/2012/03/28/its-time-to-move-beyond-ehealth/] Back
69. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Smart Alert for a medical laboratory
Improved Workflow
Back
70. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Smart Alert for a medical laboratory
Improved Workflow
71. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Smart Alert for a medical laboratory
Improved Workflow
Back
72. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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
73. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
Additional Resources
Resourcemodel
Back
74. 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
75. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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
76. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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 fulfill the operations. Think
of Basic Authentication.
Back
77. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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 traffic.
Back
78. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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
79. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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
80. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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
81. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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 surfing 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
82. 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
83. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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
84. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
ROA
Key Principles of REST Architecture
Addressability
Every resource must be uniquely accessible.
The same data can be exposed by several resources
however, each resource has a unique identification 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
85. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
ROA
Key Principles of REST Architecture
Statelessness
The interaction between a client and the server is stateless.
Upon each request, the client has to send all the
necessary information to fulfill the request.
This greatly simplifies the server logic.
Different clients can implement different behaviors based
on client-sessions.
Back
86. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
ROA
Key Principles of REST Architecture
Connectedness
Hypertext as the Engine of Application State (HATEOAS).
All subsequent resources can be discovered through links
contained in the representation of the first 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
87. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
ROA
Key Principles of REST Architecture
Uniform Interface
Use HTTP verbs to define 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
88. 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
89. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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 first 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.
90. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
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.
91. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
The history of the Web II
Evolution of the Web
92. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
The history of the Web I
Evolution of the Web
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.
93. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
The history of the Web I
Evolution of the Web
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.
94. Example: eHealth REST as Roy T. Fielding Resource Oriented Architectures History of Web
The history of the Web II
Evolution of the Web
(j) Twitter (k) Youtube
(l) Facebook