Networking Reference
In-Depth Information
order to create multiple value-added applications, the so-called physical mashups
[ 5 , 10 ].
The main requirements for a IoT middleware to enable the development of dif-
ferent applications domains include:
￿
fully interoperability support across heterogeneous devices in order to allow the
things (smart objects) communicate with users, Internet services and among each
other [ 15 ]. This is a challenge for realizing IoT due to the huge number of devices
integrated in an IoT platform and their diversity in terms of data formats, protocols,
nature of components, etc.
￿
the provision of a high-level Application Programming Interface(API) to transpar-
ently access the heterogeneous objects, hiding the specificities of the integrated
devices. Such API may facilitate the creation of physical mashups.
According to Bandyopadhyay et al. [ 2 ], interoperation, device discovery andman-
agement, context detection, among others, are the main functional components of
an IoT middleware. In addition, an application abstraction component is essential
to support the communication with local and remote applications. Security and pri-
vacity, as well as the management of a massive data volume are other important
functions of an IoT middleware.
In summary, an IoTmiddleware is a software artifact between the application layer
and the infrastructure support (communication, processing, and sensing) offering a
standardized means to acess data and services provided by the smart objects via a
high level interface. Such a middleware also promotes the reuse of generic services
that can be composed and configured to make easier the development of applications
in a highly distributed and heterogeneous environment. Some works [ 2 , 16 ] state
that the middleware act as a glue between the applications and the heterogeneous
devices.
In the following subsections we briefly presents some IoT middleware proposals.
2.2.1 UBIWARE
UBIWARE [ 16 ] is a agent-based middleware that represents each resource as a soft-
ware agent. An agent is in charge of monitoring the condition of the resource, and
enabling the interoperation of the resource with other elements. The main principles
of UBIWARE is to allow automatic discovery, orchestration, choreography, invo-
cation and execution of different Business Intelligence services. Communication,
resource discovery and resource usage are performed via the correspondent agent.
The UBIWARE agent architecture consists of three layers [ 13 ]: (i) the Behavior
Engine implemented in Java, (ii) a declarative middle-layer (Behavior Models cor-
responding to different roles the agent plays), and (iii) sensors and actuators, which
are Java components.
Behavior models are represented in a high-level rule-based language, the Semantic
Agent Programming Language (SAPL) [ 12 ], which is proposed by the UBIWARE
 
Search MirCeyron ::




Custom Search