As we previously mentioned, WoT employs REST principles to expose the services
of smart devices available on the Web by using two different approaches. In the
first approach, an embedded HTTP server is deployed directly on the devices and
the functionality of these devices is provided as RESTful resources. The second
approach is adopted whenever a device does not have hardware resources enough
to run an embedded server, or when it is not necessary that such device is directly
accessed via Web. For these cases, another, more powerful device can be used as
a bridge to expose the services provided by the constrained device via a RESTful
interface. Such device consists of a WoT gateway. In the SmartSensor project both
approaches were implemented. However, as mentioned, independently of either hav-
ing a server embedded in the sensors or not, the gateway is always used for mediating
the interaction of WSNs with the Internet (for the purposes of converting the adopted
For the first approach, an embedded Web server is directly implemented on each
sensor node making it an autonomous and Web-enabled device. The use of servers
embedded in physical objects enables the functionality of these objects to be avail-
able as Web resources. However, the technologies used in the creation of traditional
Web services are not designed to be used on devices that are severe restricted in
resources and battery powered (eg, wireless sensors) [ 4 ]. Therefore, so that Web
servers are used in embedded devices, they must meet a number of requirements.
In Ref. [ 4 ] a set of requirements and standards for the implementation of embedded
servers were presented. An example of a requirement to be met in a standardized way
is the compression of HTTP protocol messages [ 1 ]. For the definition of a generic
architecture for embedded servers, the SmartSensor project followed a bottom-up
approach, in which such an architecture was derived from an existing implementa-
tion of a embedded server deployed in a specific sensor platform, the SUN Spot.
The implementation used as a reference for the SmartSensor design is described
in the WebOfThings project. 8 From the analysis of the components of this existing
architecture, a platform-independent generalization was performed and adopted in
the SmartSensor logical architecture to guide the possible implementation of a server
embedded in other sensor platforms.
The embedded Web server is basically a very lean version of an HTTP server,
capable of handling HTTP request messages and generating reply messages server.
Thus, it natively supports the four main operations of the HTTP protocol (GET,
POST, PUT, DELETE, i.e the verbs of REST). In this case, the Communication
component in the sensor nodes encompasses the typical classes of an HTTP engine,
including a request dispatcher and a response builder [ 2 ].
For the second approach, the Communication component includes the classes
and interfaces native for each sensor platform, which are responsible for the com-
munication tasks. Such classes should participate in the completion of three tasks:
(i) sending messages advertising the capabilities of the device; (ii) receiving