A Middleware based on Service Oriented Architecture for Heterogeneity
Issues within the Internet of Things (MSOAH-IoT)
Yasser Mesmoudi a,⇑
, Mohammed Lamnaour a
, Yasser El Khamlichi a
, Abderrahim Tahiri a
,
Abdellah Touhafi b
, An Braeken b
a
Computer Engineering Department, National School of Applied Sciences of Tetuan, Abdelmalek Essaadi University, Tetuan, Morocco
b
Department of Electronics and Informatics, Faculty of Engineering Sciences, Vrije Universiteit Brussel, Brussels, Belgium
a r t i c l e i n f o
Article history:
Received 24 July 2018
Revised 9 November 2018
Accepted 21 November 2018
Available online xxxx
Keywords:
Middleware
Smart gateway
SOA
RESTfull webservices
IoT
a b s t r a c t
Nowadays, many Internet of Things (IoT) applications have been emerging as innovative solutions for
daily life issues, in different fields such as smart cities, environmental surveillance, health care, traffic
monitoring, etc. However, most of these solutions are built in a vertical way using proprietary solutions,
which increase heterogeneity problems. To solve this issue, many research works have focused on mid-
dleware solutions. Nevertheless, such approaches have some kind of limitations. Throughout this work,
we have designed and implemented a middleware based on service oriented architecture, capable to deal
with the heterogeneity issues. The solution was implemented in three steps starting by collecting data
from many heterogeneous sensors hardware using REST API, then heterogeneous networking interfaces
have been introduced and finally the middleware have been tested on gateways working on different
operating systems.
Ó 2018 The Authors. Production and hosting by Elsevier B.V. on behalf of King Saud University. This is an
open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).
1. Introduction
The use of networked sensing devices is growing at a fast pace.
This phenomenon entails an increasing volume of data, hetero-
geneity of devices, data formats and measurement procedures.
Managing the sensor nodes and valorizing the accompanying vol-
ume of data is today’s challenge. The network of those sensing
devices which enables things to connect and exchange data is
called Internet of Things (IoT). Each and every day, many new sens-
ing devices are made, they are implemented on smart-phones,
smart-watches or simply on sensor nodes that can be called smart
objects or things. Recently, several vertical IoT solutions have been
developed for particular domains of interest like smart home,
smart buildings, automotive, smart environment, smart health
etc. In the best case, these solutions handle the whole process,
from data collection and processing to the provisioning of data
on open cloud based platforms used by application developers.
Examples of big industry player’s ecosystems are: IoTivity (Intel
+ partners), AgileIoT (Huawei), AllJoyn (Qualcomm), Homekit
(Apple), Brillo (Google). In order not to be locked in one of these
systems, open standards or at least publicly documented Applica-
tion Program Interfaces (APIs) are needed. Today, new technology
cannot be sold as a component because the market is not ready yet.
Consequently, if one is interested in combining features from those
different ecosystems, they need to be able to discover and have
access to the data sources and understand the semantics used by
those heterogeneous systems.
As described in a summary extracted from the most influential
articles (Liu et al., 2017), most of these solutions do not support
heterogeneity of different communication technologies and use
diverse formats of exchanged data. Hence, there is a need for devel-
oping a middleware as intermediate software layer between the
hardware side and the application one. In order to efficiently
exploit the capabilities of the current communication technologies
and provide more flexible, reconfigurable and efficient networks,
the proposed middleware model should provide data compatibil-
ity, bandwidth management, ensure connectivity between hetero-
geneous devices and solve security problems.
Our middleware architecture is a service oriented based on
REST API, which permit support various smart objects using differ-
ent networking interfaces (IP and NOT IP based) and OS systems, as
https://doi.org/10.1016/j.jksuci.2018.11.011
1319-1578/Ó 2018 The Authors. Production and hosting by Elsevier B.V. on behalf of King Saud University.
This is an open access article under the CC BY-NC-ND license (http://creativecommons.org/licenses/by-nc-nd/4.0/).
⇑ Corresponding author.
E-mail address: mesmoudi.yasser@gmail.com (Y. Mesmoudi).
Peer review under responsibility of King Saud University.
Production and hosting by Elsevier
Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx
Contents lists available at ScienceDirect
Journal of King Saud University –
Computer and Information Sciences
journal homepage: www.sciencedirect.com
Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues
within the Internet of Things (MSOAH-IoT), Journal of King Saud University –
Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011

well as unifying various data formats that is used to provide the
information needed to the end user working on different platforms.
The recommended middleware can be implemented on different
gateways, in our case a Raspberry PI equipped with different net-
working interfaces, making this gateway smart so that it can man-
age communications at the edge of the network and deals with
heterogeneity issues cited above. The rest of the paper is organized
as follow: Section 2 provides middleware concepts and preliminar-
ies, and then related work is presented in Section 3. Section 4
describes software and hardware architecture of our middleware.
Section 5 focuses on the implementation scenarios of our middle-
ware and discusses the result. Finally, section 6 concludes the
paper.
2. IoT middleware concepts and preliminaries
Generally, the middleware performs the role of an interpreter
that fills up the gap between the high level requirements of
different IoT applications and the complexity of different opera-
tions in the underlying sensor node hardware (Bhuyan et al.,
2014).
The design of an IoT middleware needs to meet several chal-
lenges (Cecílio and Furtado, 2014; Ajana et al., 2015):
Managing limited battery power and resources: middleware
designed for smart objects should provide a suitable mecha-
nism for the use of limited memory and ensure efficient power
consumption.
Scalability, mobility and dynamic network topology: Middle-
ware should maintain the required performance while the net-
work environment is growing.
Heterogeneity: The heterogeneity among the hardware, com-
munication devices and configuration operations, have to be
handled by the middleware.
Real world integration: Middleware should provide real time
services to be adapted to the eventual changes and data
update.
Data Aggregation: The aggregation of data within the network
ensures that redundant data is not generated, saving costs
through memory usage and energy through processing time.
Application knowledge: The middleware must include mecha-
nisms for injecting application knowledge of IoT infrastructure.
Quality of Service (QoS): is important on the application level as
well as on the network level, since it defines the accuracy of
data, coverage and tolerance.
Security: It is necessary to achieve data confidentiality and
integrity, since the collected information transmitted over the
network can be easily hacked by malicious intrusions.
Fault tolerance: The integration of recovery methods in the sys-
tem is necessary for enabling failure-resistant networks.
Following (Cecílio and Furtado, 2014), middleware approaches
can be classified into two main groups, based on how they work:
those that run only inside the network (classical approaches) and
others that integrate and process data which works only outside
the network.
2.1. WSN middleware approaches within the network
Based on (Razzaque et al., 2016; Cecílio and Furtado, 2014;
Alshinina and Elleithy, 2017) WSN middleware approaches inside
the network are classified as presented in Fig. 1.
There are several middleware for each approach such as Cougar
(Yao and Gehrke, 2002) and SINA (Shen et al., 2001) for Database
approach, Agila (Fok et al., 2005) and Impala (Liu and Martonosi,
2003) for Modular approach, Maté (Levis and Culler, 2002) and
SwissQM (Mueller et al., 2007) for Virtual Machine approach, Mires
(Souto et al., 2005) and TinySOA (Rezgui and Eltoweissy, 2007) for
Message-Oriented approach and MiLAN (Murphy and Heinzelman,
2002) For Application Driven Apprach.
Studies in (Ajana et al., 2015; Bhuyan et al., 2014; Cecílio and
Furtado, 2014; Delicato et al., 2014) describe the advantages and
hinders of each middleware like those cited previously and
conclude that classical approaches were developed for specific
platforms. They do not offer heterogeneity support and interoper-
ability among heterogeneous parts of the network. Consequently,
developing and deploying end-to-end applications for sensor net-
works remains highly complex.
2.2. WSN middleware approaches outside the network
Internet-Based Integration of Sensor Data: Traditionally, sensor
networks are not IP based. Their integration into IP-based WAN
infrastructures requires the deployment of proxies at the edge of
both networking domains that transform between non-IP commu-
nication in the sensor network and IP communication in the
Internet.
Several research projects were developed such as GSN (Aberer
et al., 2006), Borealis (Abadi et al., 2005), IrisNet (Gibbons et al.,
2003), Hourglass (Shneidman et al., 2004), HiFi (Franklin et al.,
2005), SStreaMWare (Gurgen et al., 2008), EdgeServers (Rooney
et al., 2006), and ESP framework (Kobialka et al., 2007). These mid-
dlewares were developed to integrate sensor data into the Internet.
Consequently, they are only focused on wrapping data coming
from sensor sources for sharing and processing over the Internet.
Those works provide heterogeneity outside the network (Cecílio
and Furtado, 2014).
IP-Based Homogeneous Middleware: There have been several
efforts to implement the Internet protocol stack on small con-
strained devices. The 6LoWPAN (Mulligan, 2007) ports the IPv6
protocol to small devices. This enables running services on the
application layer directly on sensor nodes, which enables the inte-
gration of a Service-Oriented Architecture (SOA) into the design of
middleware (Cecílio and Furtado, 2014).
2.3. The Service oriented middleware
The Service oriented middleware (SOM) architecture is the best
platform to develop IoT applications to address hardware chal-
lenges such as QoS, security, and heterogeneity (Alshinina and
Elleithy, 2017). (For instance) The SOM logically views the network
as a service provider for consumer applications; it permits end
users to communicate with the network components and provides
Fig. 1. Middleware architecture classification.
2 Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx
Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues
within the Internet of Things (MSOAH-IoT), Journal of King Saud University –
Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011

developers with a flexible programming model to build efficient
systems (Delicato et al., 2014).
Researchers point out that SOA enables organizations to create
new applications dynamically to meet changing business needs; its
functionality is considered as an important benefit (Xu, 2011).
The SOM architecture should provide different functionalities
supporting the system. However, most of the approaches do not
provide all of them, including: interoperability heterogeneity, scal-
ability, security, data aggregation and QoS support. Data or service
aggregation is supported in approaches like OASiS, oneM2M
(Marino et al., 2017), Fiware (López-Riquelme et al., 2017), InerIoT
(mila, n.d.), MiSense, SensorsMW (Anastasi et al., 2010), and ESOA.
The security mechanisms have been taken into account through
approaches like SOMM (Faghih and Moghaddam, 2011), ESOA,
and SAWM (Sheikhha and Moghaddam, 2012).
The most disseminated technology for service implementation
is Web Services technology. It is often used to connect and access
sensors and actuators through the Internet. Two standards in this
area have emerged; the Representational State Transfer (REST)-
based approach and Simple Object Access Protocol (SOAP) based
web services. REST utilizes the common Hypertext Transfer Proto-
col (HTTP) methods (get, post) to transfer data, and SOAP uses mes-
sages to communicate among services. The structure of the
messages and the way to handle those are predefined in the web
service specification.
As mentioned in (Guinard et al., 2009), Web services are to be
preferred for professional enterprise application integration sce-
narios with a longer lifespan and advanced QoS requirements. Con-
versely, thanks to their simplicity, lightweightness and uniform
interface, RESTful services are preferred for tactical, ad-hoc inte-
gration over the Web. Since the Web services technology uses
XML as the encoding system, data is easily exchanged between
computing systems with incompatible architectures and incom-
patible data formats. Another lightweight protocol that shows effi-
ciency instead of XML format is called JavaScript Object Notation
(JSON) (Smith, 2015).
As mentioned in (Al-Fuqaha et al., 2015), IoT devices can be
classified into two major categories: resource-constrained devices
and resource-rich devices. Resource-rich devices, on which we will
focus in our research work, are those that have the hardware and
software capabilities to support the TCP/IP protocol suite. Thus,
IoT applications are based on a variety of application-level proto-
cols, such as the Constrained Application Protocol (CoAP (Daud
and Suhaili, 2016)), Message Queue Telemetry Transport (MQTT),
MQTT (Luoto and Systä, 2017) for Sensor Networks (MQTT-SN),
Extensible Messaging and Presence Protocol (XMPP (Ferrera
et al., 2017)), as described in Table 1.
Those resources are communicating according to network com-
munication models such as Request/Response and Publish/sub-
scribe. In the request and response architecture, client resource
or software requests data or services, meanwhile a server com-
puter or software responds to the request by providing the data
or service. Whereas, in the Publish and subscribe architecture, a
central source called the broker receives and distributes all data,
here clients can publish/subscribe data to/from the broker to get
the data. On the other hand, devices that do not have the required
resources to support TCP/IP cannot easily interoperate with
resource-rich devices that support the TCP/IP suite which will be
treated in our proposed model.
3. Related work
In a different category of related work, Morabito et al. (2018)
propose a new model of IoT Gateway called LEGIoT: Lightweight
Edge Gateway for the IoT architecture, which relies on the modular
characteristic of micro-services and the flexibility of lightweight
virtualization technologies to guarantee an extensible and flexible
solution at the edge of the network.
(Trifa et al., 2009) propose an approach which makes the nodes
to become part of a web of things and interact with them using the
RESTfull architecture. It is based on lightweight and extensible
software components that enable Web-based interactions with
all kinds of embedded devices. For non-request/response commu-
nication model, (Cirani et al., 2013) proposed a constrained version
of the Session initialization protocol (CoSIP) which allows con-
strained devices to instantiate communication sessions in a light-
weight and standard way. It can be adopted in several
application scenarios, such as service discovery and publish/sub-
scribe applications. (Bai et al., 2016) proposes the design and
implementation of an IoT multi-interface gateway, which can
transform the information into data in order to be recognized by
various smart objects using heterogeneous wireless technologies
such as Bluetooth, Wi-Fi, ZigBee and IR.
(Rahmani et al., 2018) propose a smart e-health gateway that
supports various wireless protocols and take care of inter-device
communication. This gateway is implementing several features
such as acting as a repository (i.e., local database) in order to tem-
porarily store sensors’ and users’ data, and incorporating it with
data fusion, aggregation, and interpretation techniques. It is also
providing local pre-processing of sensors’ data, security mecha-
nism and interoperability. Table 2 presents an overview of some
approaches characteristics cited above.
All the previous works has tried to deal with the heterogeneity
issues, whether it was communication technologies or circulating
data format, in their own way. In the next section we will present
our model in details.
4. Proposed middleware architecture
4.1. Software architetcure
The design of our middleware should be capable to:
- Deal with the problem of heterogeneous communication
technologies,
- Generalize the implemented code for the most used platforms,
- Treat the problem of heterogeneous circulating data.
Fig. 2 demonstrates that the proposed architecture can handle
various networking interfaces such as Bluetooth; WiFi; Zigbee
etc, platforms such as TinyOs, Contiki etc and format data collected
from each sensor node/smart object monitoring different activities
such as smart home (in our case), healthcare, traffic monitoring etc.
Table 1
IoT protocols for application level.
MQTT CoAP XMPP
(Luoto and Systä, 2017) (Daud and Suhaili,
2016)
(Ferrera et al., 2017)
Client-Server
publish/subscribe
messaging transport
protocol
Request-respond
based
Client-Server
publish/subscribe
messaging transport
protocol
For M2M connections and
the IoT
RESTful, designed for
constrained M2M
For asynchronous and
long live connection
Lightweight, open, simple
and designed so as to
be easy to implement
Low header overhead
and parsing
complexity
Open Binary protocol.
Quality of Service (QoS) Built-in discovery,
Support for URIs and
Content-type headers
Instant messaging,
group chat, VOIP, etc.
On top of TCP (ensures
reliability)
usually over UDP On top of TCP
Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx 3
Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues
within the Internet of Things (MSOAH-IoT), Journal of King Saud University –
Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011

As we can see, when a person gets into his house, his smartphone is
automatically connected to the gateway via WiFi, so they can check
through a mobile app all the available smart things with their
offered services. The user may check the temperature in the living
room (10°) measured by the sensor node which is accessible via
Bluetooth and working on ‘TinyOS’ and turn ON the air conditioner
which is accessible via WiFi by a simple click.
In order to save time and get a warm shower, they can open the
smart tap accessible through the 6LowPAN technology in the bath-
room. Then, before sleeping and while checking e-mails on the PC;
connected with Ethernet and has ‘windows’ as an Operating sys-
tem; in the bedroom, they remember not to turn off the TV which
is accessible via WiFi and works on ‘WebOS’, so they can also do it
by a simple click. Finally, they turn off by their own phone, the
light of the bedroom by manipulating the smart bulb connected
via WiFi working on Contiki. The above scenario describes briefly
the result obtained by implementing our model. Next, we will
see in details how the proposed middleware works.
Fig. 3 demonstrates how the middleware can make the commu-
nication between heterogeneous devices possible through the fol-
lowing implemented methods:
Phase 1: Service deployment
In this phase, the initialization method deploys a web service to
discover and initiate connections with all devices connected
through WiFi. In addition to that, it opens a web socket for devices
connected through Bluetooth. In the first case we use Apache Tom-
cat software, which is an open source implementation of the Java
Servlet, JavaServer Pages and Java WebSocket technologies, to
install a web server and to deploy a web service in order to dis-
cover each detected smart object on the Wifi network. In the sec-
ond case, we create a script that permits to detect smart devices
using Bluetooth and initialize connections through sockets.
Initialization (): This method allows the middleware to create a
communication link using current communication interfaces
(for example Web services for WiFi connection and Web socket
for Bluetooth).
Phase 2: Core development
This phase describes the core of our middleware which contains
the following methods:
ThingDiscovery (): allows the middleware to get information of
available smart object in order to create a database which con-
tains several device information, such as communication inter-
face, UUID (Xu et al., 2014), name, operating system, and the
proposed services etc. We use a MAC address and an IP address
as a UUID, respectively for Bluetooth and WiFi connections in
order to ensure unique connexion. Table 3 shows an example
of table structure.
ServiceAvailable (): This method allows to consult saved ser-
vices from database, through specific applications for each
end user platform (web application in our case).
Phase 3: Web application
In this phase we develop a web application to manipulate smart
things and available services in the network besides managing the
application.
Table 2
Overview of similar approaches characteristics.
LEGIoT WoT CoSIP Multi-Interface Smart E-health
(Morabito et al., 2018) (Trifa et al., 2009) (Cirani et al., 2013) (Bai et al., 2016) (Rahmani et al., 2018)
Micro-services. RESTfull architecture. Constrained version of
SIP.
IoT multi-interface
gateway.
Inter-device communication.
Flexibility of lightweight
virtualization
technologies.
Lightweight and extensible
software components.
Sessions in a
lightweight and
standard way.
Heterogeneous wireless
technologies.
Data fusion, aggregation, and interpretation
techniques.
Extensible and flexible
solution.
Interacting with a sensor
node through a URI.
Adopted in several
application scenarios.
Transform the information
into a recognized data.
Acting as a repository, local pre-processing,
security mechanism and interoperability.
Edge of the network. Cloud. Edge of the network. Edge of the network. Edge of the network.
Fig. 2. Middleware implementation scenario.
4 Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx
Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues
within the Internet of Things (MSOAH-IoT), Journal of King Saud University –
Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011

LoadingService (): This method provides specific implementa-
tion (for example get/set methods) for service seeker using
specific environment (specific end user browser).
4.2. Software implementation
The proposed middleware is developed by using the Java
Platform Enterprise Edition (Java EE) architecture that permits to
build distributed web and enterprise applications. This
architecture helps to focus on presentation and application issues,
rather than on systems issues, thus interoperability between sys-
tems is ensured. The Java EE tools and features help to create appli-
cations that are structured around modules with different
purposes. Different tools used in the development of our middle-
ware are listed below:
JAX- RS (Java API for RESTful Web Services): is a Java program-
ming language API for creating RESTful web services. It provides
portable APIs for developing, exposing and accessing Web
applications designed and implemented in compliance with
principles of REST architectural style (Patni, 2017).
JSF framework 2.2: Java Server Faces is a Java-based web appli-
cation framework intended to simplify development and inte-
gration of web-based user interfaces. Developers can build
web applications by assembling reusable UI components in a
Fig. 3. The proposed Middleware architecture.
Table 3
Example of the connected device information table structure.
Com Int UUID Name OS Proposed Service
WiFi 192.168.43.2 Torch Android Light
BLE 00:21:13:00:CA:87 DHT11 Arduino Temperature
Fig. 4. Scenario 1 architecture.
Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx 5
Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues
within the Internet of Things (MSOAH-IoT), Journal of King Saud University –
Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011

page, connecting these components to an application data
source and wiring client-generated events to server-side
event-handlers (Juneau, 2018).
JSON or JavaScript Object Notation API is a specification that
exposes an implementation for data stores and data structures
and permits to optimize HTTP requests, both in terms of the
number of requests and the size of data packages exchanged
between clients and servers (Smith, 2015).
SQLite is a relational database management system contained
in a C programming library. In contrast to many other database
management systems, it is embedded into the end of the pro-
gram, does not have a separate server process and reads/writes
directly to ordinary disk files. Since we work with limited
resource components, such as memory capacity and CPU, we
use SQLite for storage (Feiler, 2015).
By using the Raspberry Pi as a gateway to host the proposed
middleware, and Arduino which is an open-source electronics plat-
form that senses the environment, we allow the middleware to col-
lect data from different smart objects connected through different
networking interfaces such as Wi-Fi, Bluetooth and Zigbee.
Fig. 5. List of services available in the network – Scenario 1.
Fig. 6. Details of IoT devices and services – Scenario 1.
Fig. 7. Scenario 2 architecture.
6 Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx
Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues
within the Internet of Things (MSOAH-IoT), Journal of King Saud University –
Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011

Arduino is an easy-to-use hardware and software that connects to
computer via USB, receives inputs from a variety of digital and ana-
log sensors, and affects its surroundings by controlling lights,
motors, and other actuators. Arduino is accessible and can be cus-
tomized by writing code in the Arduino programming language.
5. Results discussion
In order to present the developed middleware we propose three
scenarios, in the first one the middleware installed on a Raspberry
Pi as a gateway should collect data from various smart objects con-
nected via Wi-Fi. Consequently, this proves that data exchange is
ensured between heterogeneous smart objects. Then, in the second
case the installed middleware should handle data coming from
various smart objects connected through different networking
interfaces. While in the third one, we use a personal computer
working on windows as a gateway to prove that our middleware
deal with the operating system heterogeneity.
5.1. Scenario 1
In this step, we test the heterogeneity between various sensors
used in order to prove that heterogeneity of hardware is supported
by the developed middleware. Thus, we connect on Arduino plat-
form a temperature sensor DHT11, a red LED and a Wi-Fi module
to exchange data with the gateway, besides we use a Smartphone
equipped with a WiFi module and a pedometer that permit to cal-
culate the number of walks. The goal is to list all available services
on the network, such as temperature, switching on or off light and
the number of walks, and manipulate the connected objects. Fig. 4
describes the smart objects and equipment used in the first sce-
nario. The Id of all connected objects on the Wi-Fi network is the
IP address.
In Fig. 5, we list all services available on the network loaded by
the developed middleware, using the web application developed to
consult specific information of the smart objects connected and
manipulate them. Then details and commands are accessible as
demonstrated by Fig. 6.
5.2. Scenario 2
In this step, we address the networking interface heterogeneity
issue using the proposed middleware. Thus we connect on the first
Arduino platform a temperature sensor DHT11 that will send data
using the Bluetooth module HC-06, in the second one a red LED is
connected and can be switched on/off via Wi-Fi module; then like
the previous scenario, we use a Smartphone equipped with a WiFi
module and a pedometer that permits calculate the number of
walks. Smart objects are identified on Wi-Fi network using Ip
address and on Bluetooth using their Mac address. Fig. 7 describes
all equipments used in the second scenario.
Fig. 8 shows all services available on the WIFI and Bluetooth
network loaded by our middleware. The web application shows
also all details and commands to manipulate the detected objects.
Hence, heterogeneity is ensured for smart object hardware as well
as for networking interfaces. Fig. 9 show details about a smart
objet and if it can be manipulated.
5.3. Scenario 3
In order to prove that interoperability is ensured, we decide to
install our middleware on a Personal computer that uses Windows
and search for available services on the WiFi and Bluetooth net-
work. We keep all the equipments used in the previous scenario;
Fig. 10 shows the implemented architecture.
The main goal of using a web application for consulting and
commanding things over the network, and a JAVA based web ser-
vices to collect and exchange data, is besides extending the net-
work lifetime since the REST Api consumes low energy, to solve
interoperability issue between systems such Windows, Linux, IoS,
Fig. 8. List of services available in the network – Scenario 2.
Fig. 9. Details of IoT devices and services – Scenario 2.
Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx 7
Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues
within the Internet of Things (MSOAH-IoT), Journal of King Saud University –
Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011

and Android, so the developed middleware can be installed on dif-
ferent gateway. Thus, we prove that our middleware is portable
and compatible with different systems.
Before we conclude, we provide a summary of our work pro-
gression in Table 4.
6. Conclusions
All in all, nowadays, IoT applications have been introduced in
every filed, because of the facility and low cost of their implemen-
tation. Consequently, many IoT objects equipped with heteroge-
neous sensors and networking interfaces can exist in the same
network. Thus, a large amount of data with different format is gen-
erated and must be managed, so it can be easily provided to devel-
opers and end user application.
Furthermore, most of IoT middlewares are developed in a verti-
cal way for particular domain applications, so they can just handle
a part of these issues but not all of them. In this paper, we are pre-
senting existed approaches of IoT middlewares, as well as develop-
ing a middleware based on service oriented architecture that
search for connected devices from different networking interfaces
and make its offered services available through web service using
REST API. Via different uses cases we’ve proved that our middle-
ware manages and processes data generated from heterogeneous
IoT devices connected in Bluetooth or WiFi network. The first case,
the middleware exchanged data between different kinds of IoT
objects in the same WiFi network. In the second one, we consider
the same previous scenario but, in this case, things are connected
via different technologies; for instance Bluetooth or WiFi.
Finally, by Using JAVA technology we activate network inter-
faces, we make connected IoT devices available as web services
and we offer a web application for the end user. Thus, our middle-
ware is portable and compatible with Linux and windows plat-
forms. In the future work and in order to prove that full
interoperability is ensured we focus on adapting our middleware
for Android and iOS platforms.
References
Abadi, D.J., Ahmad, Y., Balazinska, M., Cetintemel, U., Cherniack, M., Hwang, J.-H.,
Lindner, W., Maskey, A., Rasin, A., Ryvkina, E., 2005. The design of the borealis
stream processing engine. In: CIDR Conference, pp. 277–289.
Aberer, K., Hauswirth, M., Salehi, A., 2006. The Global Sensor Networks middleware
for efficient and flexible deployment and interconnection of sensor networks.
Tech. Rep. LSIRREPORT- 2006-006.
Ajana, M.E.K., Harroud, H., Boulmalf, M., Elkoutbi, M., 2015. Middleware
architecture in WSN. In: Wireless Sensor and Mobile Ad-Hoc Networks.
Springer, New York, NY, pp. 69–94. https://doi.org/10.1007/978-1-4939-2468-
4_4.
Al-Fuqaha, A., Khreishah, A., Guizani, M., Rayes, A., Mohammadi, M., 2015. Toward
better horizontal integration among IoT services. IEEE Commun. Mag. 53, 72–
79. https://doi.org/10.1109/MCOM.2015.7263375.
Alshinina, R., Elleithy, K., 2017. Performance and challenges of service-oriented
architecture for wireless sensor networks. Sensors 17, 536. https://doi.org/
10.3390/s17030536.
Anastasi, G.F., Bini, E., Romano, A., Lipari, G., 2010. A service-oriented architecture
for QoS configuration and management of Wireless Sensor Networks. In:
Presented at the Proceedings of the 15th Conference on Emerging Technologies
Factory Automation (ETFA 2010). IEEE, pp. 1–8. https://doi.org/10.1109/
ETFA.2010.5641336.
Bai, Z., Kuo, C.-H., Wang, T.-C., 2016. Design and implementation of an IoT multi-
interface gateway for establishing a digital art interactive system. Int. J. Ad Hoc
Ubiquitous Comput. 21, 157–170. https://doi.org/10.1504/IJAHUC.2016.
075376.
Bhuyan, B., Sarma, H.K.D., Sarma, N., 2014. A survey on middleware for wireless
sensor networks. J. Wirel. Netw. Commun. 4, 7–17.
Fig. 10. Scenario 3 architecture.
Table 4
Work progress summary.
Heterogeneity
Issues
Operating System
Windows Linux Android iOS
Supported Supported In progress In progress
Network Interfaces
WiFi Bluetooth ZigBee LoRA
Supported Supported In progress In progress
Hardware
Asynchronous Streaming
Temperature Supported Acoustic In progress
Humidity Supported Video In progress
8 Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx
Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues
within the Internet of Things (MSOAH-IoT), Journal of King Saud University –
Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011

Cecílio, J., Furtado, P., 2014. Existing middleware solutions for wireless sensor
networks. In: Wireless Sensors in Heterogeneous Networked Systems,
Computer Communications and Networks. Springer, Cham, pp. 39–59. https://
doi.org/10.1007/978-3-319-09280-5_4.
Cirani, S., Picone, M., Veltri, L., 2013. CoSIP: a constrained session initiation protocol
for the internet of things. In: Advances in Service-Oriented and Cloud
Computing, Communications in Computer and. Springer, Berlin, Heidelberg,
pp. 13–24. https://doi.org/10.1007/978-3-642-45364-9_2.
Daud, M.A., Suhaili, W.S.H., 2016. CoAP and HTTP protocol: a study on which
protocol suits IoT in terms of performance. In: Computational Intelligence in
Information Systems, Advances in Intelligent Systems and Computing.
Presented at the International Conference on Computational Intelligence in
Information System. Springer, Cham, pp. 165–174. https://doi.org/10.1007/978-
3-319-48517-1_15.
Delicato, F.C., Pires, P.F., Zomaya, A.Y., 2014. Middleware platforms: state of the art,
new issues, and future trends. In: The Art of Wireless Sensor Networks, Signals
and Communication Technology. Springer, Berlin, Heidelberg, pp. 645–674.
https://doi.org/10.1007/978-3-642-40009-4_19.
Faghih, M.M., Moghaddam, M.E., 2011. SOMM: a new service oriented middleware
for generic wireless multimedia sensor networks based on code mobility.
Sensors 11, 10343–10371. https://doi.org/10.3390/s111110343.
Feiler, J., 2015. Understanding What SQLite Is. In: Introducing SQLite for Mobile
Developers. Apress, Berkeley, CA, pp. 9–14. https://doi.org/10.1007/978-1-
4842-1766-5_2.
Ferrera, E., Conzon, D., Brizzi, P., al, et,, 2017. XMPP-based infrastructure for IoT
network management and rapid services and applications development. Ann.
Telecommun. 72, 443–457.
Fok, C.-L., Roman, G.-C., Lu, C., 2005. Rapid development and flexible deployment of
adaptive wireless sensor network applications. In: Distributed Computing
Systems, 2005. ICDCS 2005. Proceedings. 25th IEEE International Conference
On. IEEE, pp. 653–662.
Franklin, M.J., Jeffery, S.R., Krishnamurthy, S., Reiss, F., Rizvi, S., Wu, E., Cooper, O.,
Edakkunni, A., Hong, W., 2005. Design Considerations for High Fan-In Systems:
The HiFi Approach. In: Proceedings of Second Biennial Conference on Innovative
Data Systems Research (CIDR), pp. 24–27.
Gibbons, P.B., Karp, B., Ke, Y., Nath, S., Seshan, S., 2003. IrisNet: an architecture for a
worldwide sensor Web. IEEE Pervasive Comput. 2, 22–33. https://doi.org/
10.1109/MPRV.2003.1251166.
Guinard, D., Trifa, V., Pham, T., Liechti, O., 2009. Towards physical mashups in the
Web of Things. Presented at the Proceedings of the Sixth International
Conference on Networked Sensing Systems (INSS), pp. 1–4. https://doi.org/
10.1109/INSS.2009.5409925.
Gurgen, L., Roncancio, C., Labbé, C., Bottaro, A., Olive, V., 2008. SStreaMWare: a
service oriented middleware for heterogeneous sensor data management. In:
Proceedings of the 5th International Conference on Pervasive Services, ICPS ’08.
ACM, New York, NY, USA, pp. 121–130. https://doi.org/10.1145/1387269.
1387290.
Juneau, J., 2018. The Basics of JavaServer Faces. In: Java EE 8 Recipes. Apress,
Berkeley, CA, pp. 103–189. https://doi.org/10.1007/978-1-4842-3594-2_3.
Kobialka, T., Buyya, R., Leckie, C., Kotagiri, R., 2007. A Sensor Web Middleware with
Stateful Services for Heterogeneous Sensor Networks, in: Intelligent Sensors,
Sensor Networks and Information ISSNIP 2007. Presented at the 3rd
International Conference on Intelligent Sensors, IEEE, pp. 491–496.
https://doi.org/10.1109/ISSNIP.2007.4496892
Levis, P., Culler, D., 2002. MatÉ: A Tiny Virtual Machine for Sensor Networks. In:
Proceedings of the 10th International Conference on Architectural Support for
Programming Languages and Operating Systems. ASPLOS X. ACM, New York,
NY, USA, pp. 85–95. https://doi.org/10.1145/605397.605407.
Liu, F., Tan, C.-W., Lim, E.T., Choi, B., 2017. Traversing knowledge networks: an
algorithmic historiography of extant literature on the Internet of Things (IoT). J.
Manag. Anal. 4, 3–34.
Liu, T., Martonosi, M., 2003. Impala: A middleware system for managing autonomic,
parallel sensor systems. ACM Sigplan Notices. ACM, 107–118.
López-Riquelme, J.A., Pavón-Pulido, N., Navarro-Hellín, H., Soto-Valles, F., Torres-
Sánchez, R., 2017. A software architecture based on FIWARE cloud for Precision
Agriculture. Agric. Water Manag. Special Issue: Adv. ICTs for Water Manag.
Agric. 183, 123–135. https://doi.org/10.1016/j.agwat.2016.10.020.
Luoto, A., Systä, K., 2017. IoT Application Deployment Using Request-Response
Pattern with MQTT. In: Current Trends in Web Engineering, Lecture Notes in
Computer Science. Presented at the International Conference on Web
Engineering,. Springer, Cham, pp. 48–60. https://doi.org/10.1007/978-3-319-
74433-9_4.
Marino, F., Maggiani, L., Nao, L., Pagano, P., Petracca, M., 2017. Towards
softwarization in the IoT: Integration and evaluation of t-res in the oneM2M
architecture. In: Presented at the Proceedings of The 3rd IEEE Conference on
Network Softwarization (NetSoft). IEEE5, p. 1. https://doi.org/10.1109/
NETSOFT.2017.8004202.
mila, n.d. INTER-Iot - Interoperability Internet of Things [WWW Document].
INTERIOT. URL http://www.inter-iot-project.eu/ (accessed 7.18.18).
Morabito, R., Petrolo, R., Loscrì, V., Mitton, N., 2018. LEGIoT: a lightweight edge
gateway for the internet of things. Future Gener. Comput. Syst. 81, 1–15.
https://doi.org/10.1016/j.future.2017.10.011.
Mueller, R., Alonso, G., Kossmann, D., 2007. SwissQM: Next Generation Data
Processing in Sensor Networks. In: Proceedings of the 3rd Biennial Conference
on Innovative Data Systems Research CIDR07. 9, p. 1.
Mulligan, G., 2007. The 6LoWPAN Architecture, in: Proceedings of the 4th
Workshop on Embedded Networked Sensors, EmNets ’07. ACM, New York,
NY, USA, pp. 78–82. https://doi.org/10.1145/1278972.1278992
Murphy, A., Heinzelman, W., 2002. Milan: Middleware linking applications and
networks. Univ. Rochester Tech Rep TR-795, 1–16.
Patni, S., 2017. Introduction to JAX-RS. In: Pro RESTful APIs. Apress, Berkeley, CA, pp.
49–62. https://doi.org/10.1007/978-1-4842-2665-0_4.
Rahmani, A.M., Gia, T.N., Negash, B., Anzanpour, A., Azimi, I., Jiang, M., Liljeberg, P.,
2018. Exploiting smart e-Health gateways at the edge of healthcare Internet-of-
Things: a fog computing approach. Future Gener. Comput. Syst. 78, 641–658.
https://doi.org/10.1016/j.future.2017.02.014.
Razzaque, M.A., Milojevic-Jevric, M., Palade, A., Clarke, S., 2016. Middleware for
Internet of Things: A Survey. IEEE Internet Things J. 3, 70–95. https://doi.org/
10.1109/JIOT.2015.2498900.
Rezgui, A., Eltoweissy, M., 2007. Service-oriented sensor–actuator networks:
promises, challenges, and the road ahead. Comput. Commun., Sensor-
Actuated Networks 30, 2627–2648. https://doi.org/10.1016/j.comcom.2007.
05.036.
Rooney, S., Bauer, D., Scotton, P., 2006. Techniques for integrating sensors into the
enterprise network. IEEE Trans. Netw. Serv. Manag. 3, 43–52. https://doi.org/
10.1109/TNSM.2006.4798306.
Sheikhha, F., Moghaddam, M.E., 2012. Service-Oriented Wireless Multimedia Sensor
Network Middleware Using Infra-Red Cameras. In: Presented at the Proceedings
of the Third FTRA International Conference on Mobile, Ubiquitous, and
Intelligent Computing, pp. 230–235. https://doi.org/10.1109/MUSIC.2012.47.
Shen, C.-C., Srisathapornphat, C., Jaikaeo, C., 2001. Sensor information networking
architecture and applications. IEEE Pers. Commun. 8, 52–59. https://doi.org/
10.1109/98.944004.
Shneidman, J., Pietzuch, P., Ledlie, J., Roussopoulos, M., Seltzer, M., Welsh, M., 2004.
Hourglass: An infrastructure for connecting sensor networks and applications.
Citeseer.
Smith, B., 2015. Beginning JSON. Apress.
Souto, E., Guimarães, G., Vasconcelos, G., Vieira, M., Rosa, N., Ferraz, C., Kelner, J.,
2005. Mires: a publish/subscribe middleware for sensor networks. Pers.
Ubiquitous Comput 10, 37–44. https://doi.org/10.1007/s00779-005-0038-3.
Trifa, V., Wieland, S., Guinard, D., Bohnert, T.M., 2009. Design and implementation of
a gateway for web-based interaction and management of embedded devices.
Submitt. DCOSS, 1–14.
Xu, L.D., 2011. Enterprise systems: state-of-the-art and future trends. IEEE Trans.
Ind. Inform. 7, 630–640. https://doi.org/10.1109/TII.2011.2167156.
Xu, L.D., He, W., Li, S., 2014. Internet of Things in Industries: A Survey. IEEE Trans.
Ind. Inform. 10, 2233–2243. https://doi.org/10.1109/TII.2014.2300753.
Yao, Y., Gehrke, J., 2002. The cougar approach to in-network query processing in
sensor networks. SIGMOD Rec 31, 9–18. https://doi.org/10.1145/601858.
601861.
Y. Mesmoudi et al. / Journal of King Saud University – Computer and Information Sciences xxx (xxxx) xxx 9
Please cite this article as: Y. Mesmoudi, M. Lamnaour, Y. El Khamlichi et al., A Middleware based on Service Oriented Architecture for Heterogeneity Issues
within the Internet of Things (MSOAH-IoT), Journal of King Saud University –
Computer and Information Sciences, https://doi.org/10.1016/j.jksuci.2018.11.011