Networking Reference
In-Depth Information
byWSNs usually differs from the Internet protocol stack; (ii) sensor nodes often have
very limited hardware resources, not supporting the full implementation of HTTP
protocol; (iii) direct access of applications to the sensor nodes in order to request
their data via Web would quickly drain energy resources of those nodes, making the
network energy efficiency quite poor and decreasing its operating lifetime; (iv) in
most RSSF applications, the data provided by one individual sensor node is almost
always irrelevant to the end user, who is usually more interested in the aggregated
data monitored by a group of nodes; thus addressing individual nodes and processing
Web requests on a node basis makes little sense for such applications. Therefore, the
use of the HTTP protocol internally to the nodes of a sensor network is only justified
as a standard format to access and query sensor generated data, providing a uniform
interface for such access and allowing interoperability among nodes from different
networks (or nodes in a same heterogeneous WSN).
As we previously mentioned, in the WoT paradigm followed by SmartSensor,
WSN is considered as a service, which can be accessed as any other Web resource.
The basic service provided by a WSN is the delivery of data collected by sensors to
the client applications. Such delivery depends on the discovery of sensing capabilities
available in the network nodes, on the data requests issues by the applications (data
consumers) and on the strategy of the provider nodes to communicate their data to the
application. Considering this general scenario of aWSNoperation, the functionalities
of SIM are executed in a series of phases that are intertwined with the WSN working
itself. These phases are: (i) service discovery; (ii) submission of application requests;
and (iii) data collection and delivery. The identification of the WSN operation phases
guided the specification of SIM logical architecture as well as the implementation
of its components both in the gateway side and in the sensor nodes side. In the
WoT paradigm, an abstraction of the WSN data delivery service is provided to the
application, so that the network can be accessed and eventually configured according
to each application needs, like any other resource available in the Web. For this
purpose, a uniform interface to access the WSN is provided, adopting the REST
architectural principles implemented via HTTP protocol.
Regarding the Programming and Execution Module (PEM), its main purpose is
to allow end users to quickly compose value-added services, and to efficiently search
for services provided by Web-enabled WSNs. PEM encompasses Publishing and
Discovery , Data Manager , and EMML Scripts Manager components (Fig. 3.3 ). The
services offered by a WSN are published and discovered through a gateway, and
described by using XML.
PEM offers a Domain Specific Language (DSL) for programming Web mashup
applications specifically tailored for the WSN environment. The adopted DSL is
an extension of the Enterprise Mashup Markup language (EMML) [ 5 ]. EMML is
a declarative language for developing Web mashups that provides portability and
interoperability of developed programs, also allowing the integration of data from
different sources. EMML is an open language based on XML, made available in
the public domain by the Open Mashup Alliance (OMA) [ 18 ]. Applications cre-
ated by using EMML produce new data that can be used in other applications and
other mashups, thus allowing a high degree of reusability. This language allows the
Search MirCeyron ::




Custom Search