See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/334126912

MsM: A microservice middleware for smart WSN-based IoT application

Article · June 2019

DOI: 10.1016/j.jnca.2019.06.015

CITATIONS READS

38 309

5 authors, including:

Ayoub Benayache Azeddine Bilami

Batna 2 University University of Batna 2
8 PUBLICATIONS 51 CITATIONS 80 PUBLICATIONS 729 CITATIONS

SEE PROFILE SEE PROFILE

Sami Barkat Pascal Lorenz

Université Batna 2 University of Haute Alsace, France
4 PUBLICATIONS 38 CITATIONS 193 PUBLICATIONS 2,778 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Ayoub Benayache on 06 November 2019.

The user has requested enhancement of the downloaded file.

 Journal of Network and Computer Applications 144 (2019) 138–154

Contents lists available at ScienceDirect

Journal of Network and Computer Applications

journal homepage: www.elsevier.com/locate/jnca

MsM: A microservice middleware for smart WSN-based IoT application

Ayoub Benayache a, *, Azeddine Bilami a, Sami Barkat a, Pascal Lorenz b, Hafnaoui Taleb a, b
a
Faculty of Mathematics and Computer Science, Computer Science Department, LaSTIC Laboratory, University of Batna 2, Batna, 05078, Algeria
b
IRIMAS/GRTC Laboratory, University of Haute Alsace, 34 Rue du Grillenbreit, F68000, Colmar, France

A R T I C L E I N F O A B S T R A C T

Keywords: Actually, wireless sensor networks represent a substantial part in IoT. However, their limitation requires a special
Internet of things consideration in IoT applications. For their integration with the internet, it is necessary to adapt such networks
Wireless sensor network using different middleware, with taking into account various challenges such as heterogeneity and
Middleware
interoperability.
Monolithic design
Microservice design
Previously Service Oriented Architecture (SOA) was the suitable design, but with a better practice, a new
Artificial neural network design called microservice becomes the leader due to its high performance and its suitability for IoT applications.
In this paper, we first survey the most important middleware that have been proposed to handle WSN through
IoT. Also, we discuss the most crucial microservices that handle different integration factors by making them
supported by the proposed middleware. Our proposal is inspired from artificial neural network architecture to
allow dynamic service interaction; it supports unlimited services with a regard to various device capabilities
separately of the cloud technologies. Moreover, the evaluation of our design clearly shows that our middleware
allows a lightweight WSN integration with IoT regarding to their limitations and requirements.

1. Introduction To permit an efficient exploitation and perfect device integration with

the internet, we tackle the problem of constrained resources; here de-
In recent years, the technological development has greatly improved velopers should use specialized and adapted tools (soft/hard solutions)
human life from several aspects; becoming more intelligent by using that lead to the emergence of other problems like heterogeneity, inter-
various smart devices through the internet of things (IoT) (Rayes and operability, security, etc. The majority of WSN-based IoT projects are
Salam, 2016). IoT is known as the expansion of the standard internet to suffering from such problems since many system components are mostly
connect billions of devices; it allows data exchanging between any con- different; each has its own distinguished features. Hence, an intermediate
nected objects (user/service/device), from anywhere and at any time. tool (middleware) should be established to allow interactions between
These characteristics make the IoT strongly required in various applica- devices without big changes in the system architecture. We agree with
tions and domains such as healthcare, industrial, building, trans- authors stating in Ngu et al. (2017) and Razzaque et al. (2016) that the
portation, security…. etc. On the other hand, this excessive use leads to middleware is the best choice for assuring a complete integration be-
the occurrence of many problems and challenges related to the device tween different system parts (WSN/IoT). According to the application
capabilities, user needs, and application requirements. domain, various definitions could be given to the middleware term.
Many works are proposed but they still suffer from a range of im- Generally, they are mixing (soft/hard) solutions to handle the occurred
perfections and deficiencies, this because most of them interest on how problems while hiding complexity and technical details, filling the gap
assuring various functionalities with less thinking about their in- between incompatible system components, and enabling a high
teractions, maintaining or integrating of new ones. Recently, software abstraction at many levels of the system architecture.
development brought great attention to the IoT area. This paper focuses Using middleware becomes a necessity in professional business,
on IoT applications and their development with a consideration to the regarding to its desired purpose. The middleware could be manifested in
constrained network devices that are generally organized in wireless several forms: services, processes, API, operating systems, protocols,
sensor networks (WSNs). platforms etc. Recently, many middleware architectures for WSNs have

* Corresponding author.
E-mail addresses: [email protected] (A. Benayache), [email protected] (A. Bilami), [email protected] (S. Barkat), pascal.lorenz@
uha.fr (P. Lorenz), [email protected] (H. Taleb).

https://doi.org/10.1016/j.jnca.2019.06.015
Received 31 October 2018; Received in revised form 8 February 2019; Accepted 27 June 2019
Available online 30 June 2019
1084-8045/© 2019 Elsevier Ltd. All rights reserved.
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

been designed and implemented; they have adopted several program- To the best of our knowledge, this paper is the first that deals with the
ming paradigms and development styles, commonly, developers select integration of WSNs in the IoT using microservice approach through
the most appropriate ones regarding to the requirements and the avail- neural network, separately from the cloud computing approach.
able tools as discussed earlier. Several works have addressed the issue The remainder of this paper is organized as follows: section 2 in-
related to applications that exploit WSN devices. Many of them are based troduces similar works related to middleware development styles (i.e. the
on the middleware as examples MiLAN (Murphy and Heinzelman, 2002), monolithic and the microservice styles) and presents the research gap in
LinkSmart (Kostelník et al., 2011),TinyDDS (Boonma and Suzuki, 2014), the domain in addition to the motivation that leads to the proposed
TinySOA (Avil
es-L
opez and García-Macías, 2009) and many others. They middleware. Section 3 provides the details of our new middleware ar-
adopted various programming approaches as publish/subscribe (Corsaro chitecture and its implementation. Section 4 presents a comparative
et al., 2006), service oriented architecture (Al-Jaroodi and Mohamed, study of our proposition with the existing middleware systems. Finally,
2012) etc. The usage of IoT becomes larger than before while adopting Section 5 concludes the paper.
web services. It considers everything as consumable service over the web
using SOAP protocol or Restful API, etc. These technologies are originally 2. Background and related works
based on the SOA. However, developers seek another way to develop and
maintain the applications, by making them more extensible and more The increase of the IoT benefits in our life led researchers to look for
flexible because of the huge number of heterogeneous devices and the optimal solutions that help to develop systems and applications whatever
development of applications becomes more complicated. their requirements. In the literature, many solutions are proposed, they
The microservice approach emerged as a new design that derived are classified into various approaches depending on the target, and the
from SOA one. In the beginning, developers only focused on cloud development tools, and also on the agile development method (Cockburn
computing applications, but recently, some IoT WSN-based works and Highsmith, 2001; Zimmermann, 2016). The latest classification
adopted this approach in specific applications that mainly interact with divided these solutions into two major patterns depending on the
cloud and fog architecture. The aim of our work is a new middleware development style: the traditional monolithic architecture (Namiot and
design based on microservice architecture. It is called MsM, which allows Sneps-Sneppe, 2014) and the microservice architecture (Sun et al., 2017)
a complete WSNs integration with the internet and deals with them as as illustrated in Fig. 1.
services. To achieve our objectives, we studied the microservice archi-
tecture itself; it has not yet a standard definition, therefore we tried to
propose a general model inspired from the artificial neural network 2.1. The monolithic design
(Hagan et al., 1995) to allow dynamic service interaction. The proposed
model allows the design and the development of an extensible, distrib- In the monolithic architecture pattern (Redbooks, 2015; Villamizar
uted, and adaptable middleware system for lightweight WSN device et al., 2015), the whole system is structured in one big application. This
integration. design uses few programming languages to create a single process
Through our design, we have reached the following functions: composed of several classes, methods, and packages depending on the
programming paradigm. Mostly, the application is executed on one

Exploit microservice benefits to provide a best WSN integration server side regardless to the three-tier architecture and the application
without requiring cloud services. requirements. As mentioned by Guidi et al. (2017), the application ser-

Create new middleware that is capable to generate web and other IoT vices and modules in the monolithic design, even if they are in-
application style as to control and monitor remotely different WSN dependents (Sun et al., 2017), can't be executed independently; their
devices. With a minimum of programming and without any expertise interaction are based on sharing resources (memory, files, database, and
in most cases, middleware permits to create either a simple or a physical devices). In this case, the development complexity increases
complex microservice based on the existing ones. when the application is extended or maintained.

Propose an architecture that aims to create a network of many tiny Currently, the monolithic architecture is the basis of the majority of
middleware while sharing their micro services. existing IoT applications; the services in this case are highly coupled,

Enable different inter and intra communications between micro- what requires more expertise and more coordination between de-
service (input/output). velopers, in order to handle several issues in the only one (middleware/

Use artificial neural network to enable microservice unit and global framework) solution. Authors classified these solutions into many sub-
testing which was the challenge of the microservice architecture. classes and approaches; usually they focus on various criteria such as
networking management, communications control, data treatment and

Fig. 1. Development approaches (Chaitanya Jawale, n.d.).

139
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Table 1 2.2. The microservice design

Middleware/framework development approaches.
Middleware and Proposed middleware and framework solution. Microservice (Namiot and Sneps-Sneppe, 2014; Sun et al., 2017) is a
framework approach new paradigm of software development; it is used to address distributed
Event based approach PRISMA (Silva et al., 2014) Mires (Souto et al., 2006) applications, such as web applications and Cloud computing. The aim of
Service-oriented Linksmart (Hydra) (Kostelník et al., 2011) this architecture is to decompose the whole system into small indepen-
approach TinySOA (Avil
es-L

opez and García-Macías, 2009) dent components, which can be interconnected to share services. The
CHOReOS(Hamida et al., 2013) design offers higher service decoupling than provided in SOA. Until now,
Virtual machine VMSTAR (Koshy and Pandey, 2005)
approach MagnetOS(Razzaque et al., 2016)
microservice has high-level architecture abstraction and uses several
Tuple-space approach LIME (Murphy et al., 2000) programming languages, communication APIs, development tools… etc.
TinyLIME (Curino et al., 2005) Microservice architecture (Krylovskiy et al., 2015) has got success
Agent- based approach Impala (Martonosi and Liu, 2003), Agilla (Fok et al., after a large experience and best practice in the distributed applications
2009),Ubiware (Katasonov and Cochez, 2012)
development. Technically, it presents small tasks to serve others by
Database approach TinyDB (Madden et al., 2004), GSN (Aberer et al., 2006)
Application-driven Adaptive Middleware (Huebscher and McCann, 2004), establishing simple communication protocol like http, http-rest
approach MiLAN (Murphy and Heinzelman, 2002) (request/response) or mqtt (publish/subscribe). This architecture suf-
Cloud approach Cloud-WBAN (Bhardwaj and Sharma, 2018a), fers from the high abstraction-level and coordination between the de-
Cloudlet-based WBANs framework (Bhardwaj and velopers. Thus, decomposing an application with the ability of its
Sharma, 2018b)
maintaining, developers have to consider certain properties and concerns
as service instantiation, load balancing, real-time execution, service
orchestration and chirography (Zte et al., n.d.; Benghazi et al., 2010; Pahl
and Zhu, 2006)… etc.
Like the previous design, microservice gets more attention in some
storing, services registration, and discovery. Authors in Ngu et al. (2017) IoT applications which most of them are based on cloud computing, as
and Razzaque et al. (2016) surveyed these approaches. Service oriented those used in the following projects: Microsoft azure IoT (Microsoft,
architecture SOA has been widely used (Al-Jaroodi and Mohamed, 2017), DevOps (Callanan and Spillane, 2016), AWS IoT (“FAQ sur AWS
2012), it is known as a solution where components are considered as IoT – Amazon Web Services,” n.d.), Lelylan (“Lelylan Dev Center.
loosely coupled services provided to satisfy a predefined functionality. Building the Connected Home.,” n.d.) and Mainflux (Draskovic and Isi-
As an example of such web service, the one which is implemented dorovic, 2017). The ‘Dimmer’ middleware, presented in Krylovskiy et al.
using SOAP (W3C, 2000) and RPCXML (Cerami, 2002), it enables het- (2015), is a smart city platform that displays an adaptation of LinkSmart
erogeneity, interoperability and standardization from several aspects middleware with some new features that preserve a few microservice
related to (software/hardware) objects. Another approach is resource concepts. In depth, it is SOA based platform from the programming view.
oriented architected (ROA) (Guinard et al., 2010). Like SOA, ROA is Authors in Vresk and Cavrak (2016) propose a new architecture to
based on web services which are considered as web resources (universal interconnect heterogeneous devices to the IoT using cloud computing
resources identifier URI) that use RESTful design (Kübert et al., 2011) as architecture. Also, in Sun et al. (2017), a microservice open framework
development method. ROA looks more lightweight than SOA; it is the for IoT applications is described; it is more improved than the previous,
most targeted on the web of things (WoT) (Guinard and Trifa, 2016). with the need of potential requirements for constrained WSN devices.
Modular or agent based approach (Maamar et al., 2005), adopts agent The early framework uses a Docker technology, Kubernetes (Bernstein,
programming model where each object can generate a piece of code to 2014) as container, ActiveMQ (Snyder et al., 2011) as messaging server
realize some task. and many other tools that require high performance and resources
This approach needs generally specific tools and configurations, it capability for optimal functioning.
doesn't enable the heterogeneity problem, but it is suitable for artificial As mentioned before, microservice is still new and limited to special
intelligence and data analysis applications. Message oriented approach applications; our contribution focuses on how to define general micro-
MOA (Salem and Nader, 2006) is a design where the exchange of mes- service architecture for WSN-based IoT applications.
sages is performed by different communication styles such as reques-
t/response (e.g. HTTP, COAP (Shelby et al., 2014)), or publish/subscribe
(MQTT/MQTT-SN (Stanford-Clark and Truong, 2013) AMQP (Luzuriaga 2.3. Research gap and motivations
et al., 2015) WAMP (Karagiannis et al., 2015)). MOA uses different data
format (json, XML, binary, txt, etc.). These communication models are Many architectures have been proposed to tackle this subject. Un-
not specific to this approach, other models can be used but with new fortunately, most of them suffer from a range of imperfections and de-
different views. Moreover, they are differentiated to handle quality of ficiencies, because they are interested only in how assuring various
service and security as shown by the application-oriented architecture functionalities, with less thinking about their maintenance or integration
(Murphy and Heinzelman, 2002). Indeed, more approaches have been with new ones. In addition, using cloud services with WSNs needs special
proposed, such as database approach (Salem and Nader, 2006), compo- treatment and had limitations for public usage. With microservice, ser-
nents based approach (Picco and Zachariadis, 2005) and many others vice integration becomes easier and could counter most of the previous
that have been evolved during these last years. solutions shortcoming.
Table 1 below resumes the most significant ones. From another aspect As we mentioned, the best middleware should handle in best way the
as mentioned in Ngu et al. (2017), there are three different classifications maximum challenges and problems. Using a multitude of heterogeneous
of these solutions, namely, service oriented approach, cloud based objects causes the emergence of those problems at different levels (WSNs,
approach, and actor based approach. The last one is also based on the IoT, and the middleware itself). These challenges must be considered in
cloud with few differences related to service provider. any system development, and the middleware must handle their inter-
During the development of middleware or framework solution, de- influence. In our work, we are interested in the following challenges:
velopers can combine different solutions to achieve their goals. Through Devices heterogeneity, system interoperability, security and data pri-
this principle, microservice architecture, as a new generation of software vacy, microservice management (deployment, invocation, reusing, real-
development, is emerging from best practice and good experience in the time updating etc.), making easy application configuration and reprog-
field. raming, system testing and validation through adopting the ANN
mechanism.

140
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 2. Natural neural network vs. artificial neural network.

3. Proposed middleware architecture 1 exi

Sigmoid:f ðxÞ ¼ ; SoftMax: gðxi Þ ¼ PK for i ¼ 0; 1; 2; …K
1 þ ex j¼0 e
xj

The proposed microservice model for the development of our mid-

dleware architecture uses the ANN (Artificial Neural Network) concept to They are used to provide output values (0.0–1.0). Concerning the
achieve a lightweight and intelligent microservice network. Adopting softmax, the sum of all the computed values will be equal to one. Thus,
microservice architecture requires different APIs and communication we use these values to distinguish the microservice states according to
protocols to enable service interconnectivity and availability over net- the entered parameters.
works and platforms as mentioned previously; however, the microservice When micro-services require establishing communications between
structure leads to many difficulties such as heterogeneity and interop- them, in that case, multitude microservice alternatives, dynamic states
erability. Microservice architecture has no standard definition due to and QoS levels constitute the best criteria to consider for choosing the
several reasons, including that each service is highly decoupled with the best interconnectivity. This is done through neural network classification
others, difficulty to test microservice, etc. Consequently, our middleware (sigmoid and softmax activation functions) to ensure efficient resources
should handle these issues using a suitable artificial intelligence mech- management. Other functions are cited in literature for various classifi-
anism. The artificial neural network (ANN) is adopted because it pos- cation types and statistics analysis, but this work is interested just in the
sesses the appropriate features to meet the needed requirements. mentioned ones. Fig. 2 illustrates both the biological and the artificial
neural network.
3.1. Artificial neural network architecture

3.2. Microservice model architecture

Artificial Intelligence (AI) is necessary in almost data processing; it is
highly required to serve people in huge real-life applications and in
In our design, the interactions between microservices are managed as
various human life domains like industry, agriculture, healthcare, auto-
neural network. Hence, we use the ANN concept to create an intelligent
mation, cyber physical system, ubiquitous system, etc. briefly in most IoT
network of microservices. Firstly, we propose a new adapted micro-
known applications. This influence was never been without efficient use
service architecture as an intelligent Microservice Network (IMSN). Like
of the knowledge despite the volume of data traffic, its source, its
ANN, IMSN is also a group of interconnected entities (microservices) able
instantaneous exchanging over networks and its treatment (filtering,
to communicate using different protocols and mechanisms. It is based on
classification, etc.).
inter and intra communications in the both sides (input, output). In our
Artificial neural network is a processing element network inspired
proposition, we consider the microservice core as a hidden layer that
from the biological nervous system. Biologically, neural network con-
deals with the incoming data from the inputs, and then routes the new
tains a large number of interconnected neurons by means of axons; the
data result through the outputs to the next destination (end user or
message unit is an electrical signal received through the inputs; after a
another microservice). Fig. 3 illustrates a microservice design; it handles
processing task, the neuron forwards the message to the next neuron via
different communication protocols such as MQTT, HTTPs, HTTP, COAP,
the output and so on. Regarding to its behavior, the artificial neural
SOCKET, SERIAL, AMQP, ZMQ, web socket, shared memory, IPC,
network has the same functioning model as neural network. Robert
pipes…. etc.
Hecht-Nielsen defines it as “…a computing system made up of a number
The proposed architecture deals perfectly with the microservice fea-
of simple, highly interconnected processing elements, which process in-
tures. Hence, it offers several methods to use based on two types of
formation by their dynamic state response to external inputs”. ANN is an
microservice, the simple and the compound one. The first one handles a
information-processing paradigm; it is formed with highly inter-
simple functionality, and the second is a composite of sub-microservices.
connected nodes (processing units) working together to solve specific
By this way, we enable the reuse of different microservices with different
problems according to the functionalities of nodes and their data inputs.
inputs to get different data results synchronously or asynchronously. The
ANNs are with several types, the feedback and the feed-forward are the
architecture permits also to redefine new advanced microservice rela-
most important ones. Both of them support multiple inputs and outputs.
tively to developer's needs, using multitude communication mechanisms
However, the first one permits feedback loop with content addressable
that provide a high interconnection service between microservices
memories, while the second does not. In our work, we used the original
whatever their locations or requirements or even their comportments.
ANN algorithms such as back-propagation and multilayer for basic and
For reusability purpose, we consider any communication microservice as
complex microservice to handle testing and classification issues. Whereas
a part of the architecture of the microservice itself, specifically at both
for micro-service testing a sigmoid and softmax activation functions are
input and output side. By adopting this technique, we respond to many
adopted:
challenges related to the heterogeneity and interoperability.
Regardless to its advantages, we checked some drawbacks of micro-
service architecture as mentioned by Richards (2018). Briefly, the paper

141
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 3. A microservice architecture.

discusses the way to deal with additional complexity achieved in a problems.

distributed environment, where the difficulties become more compli- The adopted solution enables MsM middleware to generate services
cated, especially when they are built by different developer teams who in accordance with our microservice model in order to assure that all of
deploy various services with different types. This leads to the increase of them follow the same design; this permits an easy standardization and
memory consumption and to more difficult testing issue. Our IMSN ar- provides high abstraction level at the overall middleware system. It al-
chitecture considers these points intelligently; it offers the ability of lows also a flexible way to service development, updating, upgrading,
selecting the best microservice in terms of QoS (delay, bandwidth, se- various interconnection methods, coordination, orchestration and cho-
curity… etc.), memory consumption and processing performance. In reography in remotely way, without putting much care and full knowl-
order to deal with constrained objects, deployed in the internet, this edge about the other services. Finally, this leads to high loose coupling,
selection is highly required. which is the main idea of SOA design, but with more features and
ANN is highly adequate to be used in many contexts such as machine advantages.
learning, self-learning, software testing (Vanmali et al., 2002); we adopt The following Fig. 5 illustrates the general middleware architecture
it to test the whole system through individual unit tests of each micro- and its components: a microservice definition registry, a repository that
service before forwarding its results. Fig. 4 below illustrates our IMSN contains the source code of all the local microservices, and the main core
architecture. of the middleware presented as scheduler that runs all the microservices
according to their parameters with some predefined execution strategies.
3.3. Middleware architecture (structural vision)
3.3.1. Microservice registry
This represents a database that consists of all the service types which
IMSN makes our middleware so lightweight and convenient to meet
are adopted in IMSN to deal with a similar structure and ensure a high-
most of software development exigencies and to support constrained
level abstracted homogeneity despite the fact of heterogeneity in the
device requirements for large scale; contrarily to previously used solu-
depth.
tions where, if various programming tools (languages and patterns) and
In details, the microservice registry shows the configurations related
multitude technologies (communications and systems) are exploited, IoT
to all the middleware microservices. Hence, these configurations are a set
and WSNs will suffer more from the heterogeneity and interoperability

Fig. 4. IMSN architecture.

142
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 5. Middleware architecture (structural view).

of settings and relevant parameters required in the running of the the root, its information, dependences, requirements and utilities.
microservice. Table 2 shows a set of service classes and their micro- The internet and the cloud services are other components of the
services provided by our middleware. middleware architecture. These components are considered as an
external part, whose services are located at outside of the architecture.
3.3.2. Microservice repository
It is considered as the principal directory and the container of all 3.3.3. Microservice core service
service source codes or the executable files. It contains the full packages The principal work consists in taking into consideration the entire
and libraries, sdk, APIs, and anything needed in the implementation of all registered and runtime configuration for each microservice. This is very
microservices and their relevant requirements. Contrary to the formal complicated due to the multitude of parameters. To mitigate the
definition of the microservice, this component presents the technical increased difficulties, we use the container mechanism strategy as a
definition of the whole system. Therefore, it is considered as a middle- pattern to formulate the running of each microservice according to pre-
ware root seen as a black box containing services that can only be used defined strategies and the desired configurations. The requirements are
via a catalog, which is the microservice registry relating for each object in adapted considering different conditions such as synchronous and
asynchronous policies, sequential or multi-threading execution, and
simple data processing or streaming. The ANN is adopted as a mechanism
Table 2 for smart interconnection of microservices, to ensure best performances
Middleware basis services enabled. regarding to the limitation of constrained devices. The interconnections
Services classes Microservices are based on the exploitation of different communication paradigms
(inter or intra) as links to coordinate between the microservice's
Communication Mqtt, https, http, coap, AMQP, soap, Rest-API, IPC, socket,
serial, shared memory,
endpoints.
serial-socket, ØMQ, RPC, RMI, web-socket, ftp, etc. call
method from its class. 3.4. Middleware implementation
Security Encryptions-decryptions (RSA, DES, AES, etc.); compression
(audio, video, text), SSL, IPsec, VPN, etc.
Our proposition aims to support the general architecture of internet of
Devices manager Device manager:
Wi-Fi, GPRS, Lora, 4G, 3G, WIMAX (settings). things IoT-A (Architecture et al., 2013). The European Lighthouse and its
Sensors, RFID, GPS, etc. partners worked to adopt this architecture as the general one and refer-
Proxies and gateways: ence model for the internet of things. Fig. 6 illustrates the functional view
For any constrained IP capabilities like Bluetooth, ZigBee,
of the IoT-A.
RF433, serial bus and
many old technologies, Proxies to support embedded OS
Like any IoT middleware or framework, the system should handle a
(TinyOs, Contiki, Arduino, etc.) set of essential functionalities; IoT-A provides most of them like
Data manager Event manager: usage or storing communication, security, device manager, data processing and many
Data conversion: (string, binary, json, xml, other format) others according to the soft/hard and the user requirements. Similarly,
Data filtering: data analytic, data formatting, data mining
this work discusses and explains the important tasks handled and
Applications Geo-location, users manager, monitoring, storage, cloud
manager services, implemented in MsM.
UI manager, actuator control, etc.

143
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 6. IoT-A reference architecture, functional view (Architecture et al., 2013).

3.4.1. Middleware implementation: functional view compression and authentication strategies…. etc.
MsM is built with the adopting of unified service model. The hidden
tasks of our system with their important functionalities are grouped into 3.4.1.3. Device management. This class includes two subclasses repre-
classes. Fig. 7 illustrates our middleware design from the functional senting two categories of devices. The first one, based on IP stack pro-
aspect. tocol which is able to reach the internet directly without any other device
Our system supports the bidirectional interactions (monitoring and intervention, contrarily to the second one, which cannot reach the
control) between the physical object considered in our work as WSN and internet without the use of gateways or proxies. Moreover, these device
the end user applications (mobile, web, desktop…. etc.). Obviously, these classes support different sensor and actuator types, vendors and func-
interactions involve an efficient communication service depending on tionalities. The proposed middleware handles these devices through
communication protocols with their QoS and security strategies. In the firmware and configuration ability to ensure the full control. According
following, we describe all the service classes used in our system. to various application domains, electronic companies and vendors pro-
vide a huge number of devices; they are required in many domains
3.4.1.1. Communication management. With this class, we provide the (environment, industrial, healthcare… etc.) and with different func-
most communication mechanisms for the user to select its own tionalities and targets such as measuring temperature, pressure, gas,
communication strategy. These mechanisms are distinguished into video or audio capture, heartbeat… etc. Through device management,
various communication models (request/response) like http, https, and we assure for each device its microservices registration and discovery.
coap protocols, (publish/subscribe) like mqtt and AMQP protocols,
(inter/intra) like socket, IPC, pipeline, etc. this class permits the 3.4.1.4. Data management. After receiving data, the middleware needs
communication from the physical devices to the user applications in to select method for data treatment according to the requirements and
bidirectional manner, regardless of the type and the system actors. capabilities of the triplet (users, applications and devices). This class
offers three subclasses, the first one is the event manager; it receives the
3.4.1.2. Security and privacy management. The security and the privacy incoming data from the other microservices or from the outside (sensor
become vital challenges when dealing with personal data and informa- data, user data…) whatever the used communication mechanism, and
tion, especially when the system uses major sensitive data issued from then treats the data in next appropriate level. The second one is
domains like military, healthcare, industrial and others… Moreover, responsible for making comprehensible the received data for the other
since our architecture exploits different communication protocols and service or even for the end-user, it supports various data structures,
devices capabilities, we have to take into consideration the use of coding and formatting, for example from utf-8 to ASCII or from json to
different security and privacy strategies to handle all vulnerabilities xml or vice versa. The third subclass is the data-filtering manager; it
detected in the communication system besides the data itself. extracts the interested data using different mechanisms as projection and
On the other hand, considering the communicators, the physical de- joining in databases, regular expressions, or by using data mining tech-
vices are mostly constrained compared with other actors. They cannot niques. Finally, the system delivers directly data as results to the user or
use the same strategy due to the great disparity between the communi- another microservice according to the application requirements.
cants. In this class, the middleware ensures the security on multi levels
and with various heterogeneous actors through different secured 3.4.1.5. Application management. This class includes the required
communication protocols, encryption/decryption algorithms, microservices for each application; it helps users to build multitude of IoT

144
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 7. Middleware architecture (functional view).

applications for various domains with commons services. In our platform, 3.4.2. Middleware implementation: technical view
we provide a dashboard to configure those microservices and to monitor Unlike the few designed microservice-based IoT middleware, our
all their input and output types (simple text values, charts, video, audio, proposal is completely implemented using standard tools. It is unnec-
etc.). In addition, we allow the control of all physical devices using essary to use cloud tools such as Docker and container technologies.
customized control panels. There are many other advanced microservice Because of their potential requirements, the user should bear in mind the
interfaces to interact with external services, for example with the cloud limited WSN resources while using Docker or other cloud software. Thus,
services (SAAS, PAAS, and IAAS), in potential data processing and stor- to meet the constrained devices challenges, we select the suitable and
age to compensate the shortcoming of the constrained devices. The adaptable tools for each system component and then configure them as
platform provides also localization services to determine device's posi- microservices. In addition to the configuration, we have to mention the
tions and movements, manual (user, service and application) manage- role of the programming language paradigm and its efficiency in system
ment. Adopting our approach, allows creation of complex microservices development.
from the existing ones, by the adjustment of the compound microservice The proposed system is based on Python language for its powerful
configurations and saving as new microservices in the microservice features, stated in many software production fields. Python provides
registry for future uses. potential libraries and tools to solve various problems especially those
With regards to the application scalability, and as mentioned in related to data processing, machine learning, and artificial neural
(Valley et al., n.d.), the application can scale in 3D ways by splitting network. Python allows the system to deal with other microservices
different things as functional decomposition, by cloning through hori- programmed with c, java, and many others… etc. Besides these advan-
zontal duplication and splitting similar things through data partitioning. tages, Python facilitates system maintenance. The selected framework
The microservice architecture, unlike the other monolithic architectures, Django allows an easy development of professional web applications
supports the three-dimension scalability as presented in Fig. 8. with possible reusability and pluggability of its components.
Besides the microservice capabilities, MsM architecture supports Since the current Internet integrates various tools and technologies
more than the original microservice scalability. The platform is even including M2M architecture, cloud, SDN, fogs… etc., the middleware has
adaptable to support more than the existing microservice categories, to be concerned with all software and hardware characteristics to achieve
hence it appears that using MsM leads to more complexity, but actually, best system performance. The lightweight propriety is guaranteed in
the flexible microservice communication mechanism permits to manage MsM middleware based on uniform microservice definition, it allows
easily the extension or the supplement without affecting the other system intelligent network configuration by collaborating and sharing the
components. Consequently, this gives high system robustness. optimal micro-services.
For system prototype implementation, we use various tools depend-
ing on best performance given in processing and memory consumption.

145
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 8. Microservice dimension scalability (Valley et al., n.d.).

For communication side, in order to support MQTT protocol, we use Our middleware system is a web/sensor-based application; it is able
Mosquitto broker, and as clients, we adopt several publishers and sub- to establish bidirectional data exchanging whatever the end-user device.
scribers developed in java, python, and JS. To support COAP, we use java This great support of different hardware and software architectures al-
mjcoap library, AMQP and its server, the RabbitMQ broker that supports lows users to develop and deploy their various applications prototypes
different communication protocols like STOMP, XMPP, mqtt… etc. for such domains.
Pipeline, IPC and many other intra communication protocols developed For registration and discovery microservice, we opt for the rest-api
using python libraries. Due to the powerful microservice architecture, since it is used in many development tools and applications. In our sys-
RPC and RMI are supported regardless the used language. Moreover, tem, microservice discovery extends to other middleware in order to
concerning the security and the privacy microservices, we use SSL pro- share their microservices. Moreover, the microservice registration can
tocol, RSA and AES as encryption algorithms. Fig. 9 shows a registered follow two models, the local one, where each middleware possesses a
microservice in the middleware which is presented in xml form. local microservice registry, and a global one in which a workspace reg-
In data processing class, we use mostly our own scripts and algorithms istry is used and shared with all the related middleware. In Fig. 11, a
that use a set of subclasses: event manager, data structuration and data sequence/activity diagram is provided, showing through different steps
filtering. The first one treats different incoming data from the internal/ how our system works.
external microservice. Data structuration or formatting permits to give an The following small piece of code in Fig. 12 demonstratesthe way to
understood view to data for the other microservices; this structural view develop an application in our system; it uses blockly programing method
allows the user through the third subclass (data filtering) to extract just for the tested scenario. This latter will be presented in detail in the next
the interested data from the raw one. section.
In this class, we find various data types; some microservices need a
special data format to show their results. Fig. 10 displays a simple data 4. Performance evaluation and discussion
conversion microservice used in our system prototype. We use various
data conversion for the following formats (json, xml, text, bin… etc.). In order to evaluate our middleware architecture, we have tested the
For the user application class, many tools are provided to develop the developed system prototype with data collection scenario used in many
frontend and the backend of the whole application. Table 3 summarizes a IoT (WSN-based) applications. The tested scenario uses Contiki (Velinov
list of the important tools used in this class: and Mileva, 2016; Durmaz et al., 2017) embedded system, which is

Fig. 9. A registered microservice information.

146
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 10. Data conversion microservice.

Table 3 requirements.
Some microservice development tools. Relating to the quantitative evaluation, we tackled some important
Service Tools parameters that are significant for the studied middleware, we focused
specifically on the comparison between the service registration and ser-
Localization Google Map, with GPS
Mailing Google-APIs vice discovery.
Storage PostgreSQL, MySQL, Reddit, MongoDB
Cloud OpenStack, Docker a) Service registration:
Big Data Spark, Hadoop
Charting JS libraries (CanvasJS, chartJS, etc.)
Audio, Video Audio5js, MP4box, etc.
To evaluate this feature, we concentrate on strategies that are used to
store local or remote services' information such as heterogeneity, flexi-
bility, human intervention level required in the process, the number of
recommended for many constrained devices. features that supported by the middleware (e.g. communication pro-
We cope with a simulated WSN over the internet through cooja tocols, data formative, services orchestration… etc.). A configuration
simulator; this simulator looks like a sensor application deployed in real effort is needed to register services and their response time… etc.
environment to generate huge number of data. In our system, we have to
determine the interaction of each component in real scenario using some b) Service discovery:
microservice configuration. To start with, we have to indicate the needed
device services and collected data models, then, we enable the proxy We evaluate the discovery strategies while considering the following
microservice presented as border router; cooja tool aims to establish an criteria: autonomy support, quality of discovering and conformity. We
interconnection between the simulator (sensors) and the system on also study the level of human intervention in the process, the required
which the simulator is installed. Next, when the middleware system effort to discover services, reliability and the response time of a number
recognizes the data model, it will select the appropriate microservice in of different services (in our study we use a range from 5 to 1000 services),
order to get data from the proxy service and setup both the suited and intelligence, adaptability and other features that are presented in Table 4.
required data conversion and structuration. According to the application
and the user configuration, a set of data processing microservices extracts 4.1. Intelligence
the useful data and forwards it to the next application service (e.g.
monitoring or storing). Finally, as desired by the end user, an application Intelligence is an important feature in our middleware. Both Link-
service manager shows the collected data using the monitoring Smart and OpenIoT cannot handle it. However, MsM provides the ability
microservice. to exploit different benefits and advantages of ANN, especially when
Fig. 13 illustrates the architecture of the data collection scenario dealing with smart devices in smart environments. This allows MsM
using cooja simulator as WSN environment and the microservice chart as middleware to select the best microservices according to determined
web application to display the received sensor data. criteria. The multitude of microservices leads to create a big problem of
We have several testing strategies to demonstrate each property. The overloading, which causes more energy consumption, wasting memory
qualitative and the quantitative evaluation are used to demonstrate the and bandwidth and the increase of communication delays… etc. Conse-
middleware's advantages. We compare the performances and capabilities quently, optimization strategies are desired to handle those issues, au-
of MsM with two well-known middleware, namely OpenIoT (Fleisch thors in Bhardwaj and Sharma (2015) propose ant colony algorithms to
et al., 2015) and LinkSmart (Kostelník et al., 2011). optimize route discovering. These can be used to optimize number of
Table 4 describes the nominated qualitative evaluation metrics. We micro services and build complex ones. In our work, the adoption of
classify them into three classes of requirements (middleware, IoT and neural network strategies limits these problems, where it resolves
WSN infrastructure, and the user/application). As mentioned in Razza- software-testing problem perfectly with small pieces of microservices. It
que et al. (2016), most of the studied requirements are directly related to is mentioned in Al-Masri and Mahmoud (2009) and Honamore et al.
one or more characteristics of the IoT. Considering the middleware re- (2016) that the discovering of the best services was successful for 95% of
quirements, we classified their metrics into three sub classes, the general cases using ANN mechanism. By adopting the same strategies in our
architecture requirements and the functional or non-functional ones. The middleware, we achieve various objectives, such as the selection of best
second category (infrastructures) presents networks and device re- microservices with the use of different parameters to avoid service
quirements. The last one is dedicated to end-users and the application overloading as illustrated in Fig. 14.

147
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 11. Sequence/activity diagram of middleware functioning.

4.2. Service registration be interconnected.

According to the achieved results of the service registration, all the

considered middleware permits a semi-automated service registration. In 4.3. Service discovery
each platform, a human intervention is required to accomplish the
registration. As mentioned in Palade et al. (2018) concerning the LinkSmart and OpenIoT are based on centralized architecture.
required time to perform service registration in such studied middleware: Otherwise, MsM middleware uses a distributed unstructured peer-to-peer
1 h for LinkSmart, 3 h for OpenIoT while just few minutes are required for architecture, and it is able to act as a centralized one. It offers the pos-
our middleware because of the integration of the suited services and the sibility of dealing with different micro-middleware while setting up a
use of the interested functionalities as microservices. network of sub-middleware to share their proposed microservices with
From another side, related to the service implementation, in Link- different topologies (hierarchical, flat, etc.). These features allow a high
Smart, the delay of the service implementation is due to the necessary use availability and fault tolerance.
of the registration capability that is offered by the network manager. In All the compared middleware are semi-autonomous discovery; they
OpenIoT, the required time to implement connectors is considered in the provide different modules and programmed functions to discover pub-
measure, while in MsM middleware, the service implementation may be lished services. Moreover, based on machine learning, our middleware
done by configuration or by coordination between the existing micro- can learn from previous experiences and converge to the full-autonomous
services, using blockly programming technique or by an external devel- discovery, registration and the use of complex microservices.
opment. This latter could be integrated in the system as stated before. It requires 2 h with LinkSmart to develop functions that control the
The assessment does not include learning time for services and network manager and deal with the returned results of discovered ser-
microservices development. Fig. 15 shows the registration average time vices. OpenIoT takes approximately just 3 min to handle the desired user
of each middleware. OpenIoT can take from 35 to 50 ms, LinkSmart takes interfaces (Palade et al., 2018). In our middleware, each microservice
from 230 to 240 ms, while it takes just 20–40 ms in MsM middleware needs approximately 30 s to be setup with its selected parameters, which
since it deals with small microservices, (this delay is due to microservice were simply dragged from block panel to the programming one (Blockly
heterogeneity). Concerning the heterogeneity, LinkSmart supports only programming). Dealing with discovered services requires 2 h with
the registration of one resource type (i.e. SOAP services), while OpenIoT LinkSmart to develop functions that control the network manager and
and our proposed middleware support unlimited number of resources to manage their returned results. OpenIoT takes approximately 3 min,
which permits the handling of the desired user interfaces, LinkSmart and

148
Fig. 12. Application development using blocky programming API.

Fig. 13. Modeling data collection in our middleware.

149
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Table 4
Qualitative comparison and evaluation results.

150
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 14. Microservice rate selection using neural network approach.

Fig. 15. Middleware service registry response time.

OpenIoT middleware do not check the reliability of the discovered ser- important role to switch intelligently between supported protocols ac-
vices, but it is still possible with our middleware while using cording to the desired QoS parameters. Fig. 17 shows our middleware
software-testing mechanism and dedicated neural network algorithms latency evaluation with different message size (8, 32, 128, 512, and 2048
like the back-propagation one. Other possible strategy consists in Kbytes) for the following protocols (mqtt, coap, http, web-socket, DDS,
selecting the best microservice that attains the highest accuracy like it intra communication, 0MQ (TCP)). Most of the used protocols increase
was mentioned in Bhanot et al. (2018), where authors have proposed a slightly the latency when the payload size increases, but with large
mechanism that recognizes the ratio of data division to get the maximum amount of data exchanging, the mentioned problems appear and thus our
accuracy. ANN strategy shows its maximum effectiveness.
Discovery response time is presented in Fig. 16; it demonstrates that
both LinkSmart and our middleware have stable convergence and high 5. Conclusion and future work
performance compared with OpenIoT. This latter does not support
scaling challenge, which limits its usage to the applications that require a In this paper, we proposed new middleware architecture for suitable
large number of devices. These results are obtained using different and easy integration of WSNs and IoT. Many limitations and great
numbers of services (i.e.50, 100, 200, 500 and 1000 simulated services challenges appeared on both fields and need to be tackled with innova-
and microservices). tive solutions. Consequently, we propose the new microservice approach
that provides high loosely coupled services, scalability, heterogeneity
4.4. Latency evaluation and other features.
Microservice allows the design of high-performing middleware to
Our middleware exploits different communications protocols for data achieve the targeted objectives. The global architecture is inspired from
exchanging and service sharing. Hence, the middleware latency depends artificial neural network; it allows the connection of smart microservices
on the used protocol that has dynamic state and performance according with all the components of the system. The combination of ANN and
to the network environment, packet size, nodes and network over- microservices provides a uniform definition for all IoT micro-services and
loading, service load balancing, etc. Therefore, our ANN strategy plays an leads to the design of a lightweight middleware that handles various IoT

151
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Fig. 16. Middleware services discovery response time.

Fig. 17. Latency of Some provided protocols in our middleware.

services and solves the heterogeneity and interoperability problems. References

Furthermore, MsM allows the management of new and existing services;
their configurations become possible without any care about their tech- Aberer, K., Hauswirth, M., Salehi, A., 2006. The Global Sensor Networks Middleware for
Effcient and Fexible Deployment and Interconnection of Sensor Networks. Report, Ec.
nical details or their location, it also provides a better scalability and Polytech. Fed. Lausanne, pp. 1–21.
service maintenance without affecting the whole system. By adopting the Al-Jaroodi, J., Mohamed, N., 2012. Service-oriented middleware: a survey. J. Netw.
ANN design, our system exploits different algorithms that grant software Comput. Appl. https://doi.org/10.1016/j.jnca.2011.07.013.
Al-Masri, E., Mahmoud, Q.H., 2009. Discovering the best web service: a neural network-
testability, detects data fault and system bugs, and service load balancing. based solution. In: Conf. Proc. - IEEE Int. Conf. Syst. Man Cybern., pp. 4250–4255. htt
As an evaluation of our new architecture, a middleware prototype is ps://doi.org/10.1109/ICSMC.2009.5346817.
proposed and compared with other middleware solutions in terms of Architecture, T.I., Bui, N., Jardak, C., Magerkurth, C., 2013. Internet-of-Things
Architecture.
different qualitative and quantitative metrics. The results show better Avil
es-L

opez, E., García-Macías, J.A., 2009. TinySOA: a service-oriented architecture for
performances compared to other middleware. wireless sensor networks. Serv. Oriented Comput. Appl. 3, 99–108. https://doi.
In perspective of this work, we plan to create an open microservice org/10.1007/s11761-009-0043-x.
Benghazi, K., Noguera, M., Rod
riguez-Doḿinguez, C., Pelegrina, A.B., Garrido, J.L., 2010.
IoT framework that provides the possibility of interaction with other
Real-time web services orchestration and choreography. In: CEUR Workshop Proc,
middleware and frameworks. Besides, we project to generalize our vol. 601, pp. 142–153. https://doi.org/10.1109/MC.2003.1236471.
microservice design to other various domains. Bernstein, D., 2014. Containers and cloud: from LXC to docker to kubernetes. IEEE Cloud
Comput. 1, 81–84. https://doi.org/10.1109/MCC.2014.51.
Bhanot, K., Peddoju, S.K., Bhardwaj, T., 2018. A model to find optimal percentage of
Acknowledgments training and testing data for efficient ECG analysis using neural network. Int. J. Syst.
Assur. Eng. Manag. 9, 12–17. https://doi.org/10.1007/s13198-015-0398-7.
This work was supported by the Laboratory of Systems and Infor- Bhardwaj, T., Sharma, S.C., 2015. Internet of things: route search optimization applying
ant colony algorithm and theory of computation. In: Advances in Intelligent Systems
mation Communication Technologies (L@stic), University of Batna2 and Computing, pp. 293–304. https://doi.org/10.1007/978-81-322-2217-0_25.
Algeria. Bhardwaj, T., Sharma, S.C., 2018a. Cloud-WBAN: an experimental framework for Cloud-
enabled Wireless Body Area Network with efficient virtual resource utilization.

152
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Sustain. Comput. Inf. Syst. 20, 14–33. https://doi.org/10.1016/j.suscom.2018.08.00 Martonosi, M., Liu, T., 2003. Impala : a middleware system for managing autonomic,
8. parallel sensor systems. ACM Sigplan Not. 38, 107–118. https://doi.org/10.1145/
Bhardwaj, T., Sharma, S.C., 2018b. An autonomic resource provisioning framework for 966049.781516.
efficient data collection in cloudlet-enabled wireless body area networks: a fuzzy- Microsoft, 2017. Microsoft Azure Cloud Computing Platform & Services. Microsoft
based proactive approach. Soft Comput. https://doi.org/10.1007/s00500 Website [WWW Document]. https://azure.microsoft.com/en-us/. (Accessed 24 July
-018-3587-x. 2017).
Boonma, P., Suzuki, J., 2014. TinyDDS: an Interoperable and Configurable Publish/ Murphy, A., Heinzelman, W., 2002. Milan: Middleware Linking Applications and
Subscribe Middleware for Wireless Sensor Networks, pp. 206–231. https://doi.org/ Networks. Univ. Rochester, Tech. Rep. TR-795 1–16.
10.4018/978-1-60566-697-6.ch009. Murphy, A.L., Picco, G.P., Roman, G.-C., 2000. LIME: a middleware for physical and
Callanan, M., Spillane, A., 2016. DevOps: making it easy to do the right thing. IEEE Softw. logical mobility. In: Proceedings 21st International Conference on Distributed
33, 53–59. https://doi.org/10.1109/MS.2016.66. Computing Systems, pp. 524–533. https://doi.org/10.1109/ICDSC.2001.918983.
Cerami, B.E., 2002. The WSDL Specification Chapter 6 WSDL Essentials Basic WSDL Namiot, D., Sneps-Sneppe, M., 2014. On micro-services architecture. Int. J. Open Inf.
Example : HelloService. wsdl WSDL Invocation Tools , Part I, pp. 4–10. Technol. 2, 24–27.
Chaitanya Jawale, n.d. From The CEO's Desk: To Microservice or Not To Microservice Is Ngu, A.H., Gutierrez, M., Metsis, V., Nepal, S., Sheng, Q.Z., 2017. IoT middleware: a
Not The Question… - Opcito Technologies [WWW Document]. URL https:// survey on issues and enabling technologies. IEEE Internet Things J. 4, 1–20. htt
www.opcito.com/microservice-not-microservice-not-question/ (Accessed 29 May ps://doi.org/10.1109/JIOT.2016.2615180.
2018). Pahl, C., Zhu, Y., 2006. A semantical framework for the orchestration and choreography
Cockburn, A., Highsmith, J., 2001. Agile software development: the people factor. of web services. Electron. Notes Theor. Comput. Sci. 151, 3–18. https://doi.org/10
Computer (Long. Beach. Calif) 34, 131–133. https://doi.org/10.1109/2.963450. .1016/j.entcs.2005.07.033.
Corsaro, A., Roma, S., Querzoni, L., Scipioni, S., Tucci-piergiovanni, S., Virgillito, A., Palade, A., Cabrera, C., Li, F., White, G., Razzaque, M.A., Clarke, S., 2018. Middleware for
La, R., 2006. Quality of Service in Publish/Subscribe Middleware, pp. 1–22. internet of things: an evaluation in a small-scale IoT environment. J. Reliab. Intell.
Curino, C., Giani, M., Giorgetta, M., Giusti, A., Murphy, A.L., Picco, G. Pietro, 2005. Environ. https://doi.org/10.1007/s40860-018-0055-4.
Mobile data collection in sensor networks: the tinylime. Percom 1, 446–469. Picco, G. Pietro, Zachariadis, S., 2005. Reconfigurable component-based approach to
Draskovic, D., Isidorovic, J., 2017. Mainflux Open Source Internet of Things Platform networked embedded systems. Discovery 806–810. https://doi.org/10.1109
[WWW Document]. Mainflux - Internet Things Solut. https://www.mainflux.com/. /PIMRC.2005.1651554.
(Accessed 24 July 2017). Rayes, A., Salam, S., 2016. Internet of Things-From Hype to Reality: the Road to
Durmaz, C., Challenger, M., Dagdeviren, O., 2017. Modelling contiki-based IoT systems. Digitization, Internet of Things from Hype to Reality: the Road to Digitization. htt
In: 6th Symp. Lang. Appl. Technol. (SLATE 2017), pp. 1–13. https://doi.org/ ps://doi.org/10.1007/978-3-319-44860-2.
10.4230/OASIcs.SLATE.2017.5. Razzaque, M.A., Milojevic-Jevric, M., Palade, A., Cla, S., 2016. Middleware for internet of
FAQ sur AWS IoT – Amazon Web Services [WWW Document], n.d. URL https://aws.ama things: a survey. IEEE Internet Things J. 3, 70–95. https://doi.org/10.1109/JIOT.201
zon.com/fr/iot-platform/faqs/ (Accessed 24 July 2017). 5.2498900.
Fleisch, E., Weinberger, M., Wortmann, F., 2015. Business models and the internet of Redbooks, I., 2015. Microservices from Theory to Practice, Ibm.
things. In: Business Models and the Internet of Things, pp. 6–10. https://doi. Richards, C., 2018. Microservices Patterns With Examples in Java.
org/10.1007/978-3-319-16546-2. Salem, H., Nader, M., 2006. Middleware challenges and approaches for wireless. Sensor
Fok, C.-L., Roman, G.-C., Lu, C., 2009. Agilla: a mobile agent middleware for self-adaptive Netw. 7, 1–23. https://doi.org/10.1109/MDSO.2006.19.
wireless sensor networks. ACM Trans. Autonom. Adapt. Syst. 4, 1–26. https://doi.o Shelby, Z., Hartke, K., Bormann, C., 2014. The Constrained Application Protocol (CoAP).
rg/10.1145/1552297.1552299. https://doi.org/10.17487/rfc7252.
Guidi, C., Lanese, I., Mazzara, M., Montesi, F., 2017. Microservices : a Language-Based Silva, J.R., Delicato, F.C., Pirmez, L., Pires, P.F., Portocarrero, J.M.T., Rodrigues, T.C.,
Approach, pp. 1–8. Batista, T.V., 2014. PRISMA: a publish-subscribe and resource-oriented middleware
Guinard, Dominique D., Trifa, V., 2016. Building the Web of Things. for wireless sensor networks. In: Adv. Int. Conf. Telecommun. AICT 2014–July,
Guinard, D., Trifa, V., Wilde, E., 2010. A resource oriented architecture for the web of pp. 87–97.
things. In: 2010 Internet of Things (IOT). IEEE, pp. 1–8. https://doi.org/10.11 Snyder, B., Bosanac, D., Davies, R., 2011. ActiveMQ in Action. Online, p. 406.
09/IOT.2010.5678452. Souto, E., Guimar~aes, G., Vasconcelos, G., Vieira, M., Rosa, N., Ferraz, C., Kelner, J., 2006.
Hagan, M.T., Demuth, H.B., Beale, M.H., 1995. Neural network design. Bost. Mires: a publish/subscribe middleware for sensor networks. Personal Ubiquitous
Massachusetts PWS 2, 734. https://doi.org/10.1007/1-84628-303-5. Comput. 10, 37–44. https://doi.org/10.1007/s00779-005-0038-3.
Hamida, A. Ben, Kon, F., Lago, N., Zarras, A., Pilios, D., Vassiliadis, P., Georgantas, N., Stanford-Clark, A., Truong, H.L., 2013. MQTT for Sensor Networks (MQTT-SN) Protocol
Issarny, V., Mathioudakis, G., 2013. QoS-aware Adaptive Choreographies to Cite This Specification. IBM.
Version : HAL Id : Hal-00912882 Integrated CHOReOS Middleware - Enabling Large- Sun, L., Li, Y., Memon, R.A., 2017. An open IoT framework based on microservices
Scale , QoS-Aware Adaptive Choreographies. architecture. China Commun. 14, 154–162. https://doi.org/10.1109/CC.2017.78681
Honamore, S., Dev, K., Honmore, R., 2016. Reliability prediction of web services using 63.
HMM and ANN models. Procedia Comput. Sci. 93, 41–47. In: https://doi.org/10.10 Valley, S., Group, P., Partner, G., Partners, M., n.d. The Art of Scalability Scalable Web
16/j.procs.2016.07.179. Architecture, Processes, and Organizations for the Modern Enterprise Martin.
Huebscher, M.C., McCann, J.A., 2004. Adaptive middleware for context-aware Vanmali, M., Last, M., Kandel, A., 2002. Using a neural network in the software testing
applications in smart-homes. In: Proc. 2nd Work. Middlew. Pervasive Ad-Hoc process. Int. J. Intell. Syst. 17, 45–62. https://doi.org/10.1002/int.1002.
Comput, pp. 111–116. https://doi.org/10.1145/1028509.1028511. Velinov, A., Mileva, A., 2016. Running and testing applications for Contiki OS using cooja
Karagiannis, V., Chatzimisios, P., Vazquez-Gallego, F., Alonso-Zarate, J., 2015. A survey simulator. In: Int. Conf. Inf. Technol. Dev. Educ, pp. 279–285.
on application layer protocols for the internet of things. Trans. IoT Cloud Comput. 3, Villamizar, M., Garc
es, O., Castro, H., Verano, M., Salamanca, L., Gil, S., 2015. Evaluating
11–17. https://doi.org/10.5281/ZENODO.51613. the Monolithic and the Microservice Architecture Pattern to Deploy Web Applications
Katasonov, A., Cochez, M., 2012. UBIWARE Platform - RAB Overview. Industirial Ontol. in the Cloud Evaluando el Patr
on de Arquitectura Monolítica y de Micro Servicios
Gr. Univ. Jyv€askyl€
a, p. 42. Para Desplegar Aplicaciones en la Nube. In: 10th Comput. Colomb. Conf,
Koshy, J., Pandey, R., 2005. VMSTAR: synthesizing scalable runtime environments for pp. 583–590. https://doi.org/10.1109/ColumbianCC.2015.7333476.
sensor networks. In: Proc. 3rd Int. Conf. Embed. Networked Sens. Syst, pp. 243–254. Vresk, T., Cavrak, I., 2016. Architecture of an interoperable IoT platform based on
https://doi.org/10.1145/1098918.1098945. microservices. In: 2016 39th Int. Conv. Inf. Commun. Technol. Electron.
Kostelník, P., Sarnovský, M., Furdík, K., 2011. The semantic middleware for networked Microelectron. MIPRO 2016 - Proc, pp. 1196–1201. https://doi.org/10.1109
embedded systems applied in the internet of things and services domain. Scalable /MIPRO.2016.7522321.
Batna2 12, 307–315. https://doi.org/10.12694/scpe.v12i3.726. W3C, 2000. Simple Object Access Protocol (SOAP) 1.1. W3C Work. Gr.
Krylovskiy, A., Jahn, M., Patti, E., 2015. Designing a smart city internet of things platform Zimmermann, O., 2016. Microservices tenets: agile approach to service development and
with microservice architecture. In: Proc. - 2015 Int. Conf. Futur. Internet Things deployment. Comput. Sci. Res. Dev. 1–10. https://doi.org/10.1007/s00450-016-0
Cloud, FiCloud 2015 2015 Int. Conf. Open Big Data, OBD 2015 25–30. https://doi.o 337-0.
rg/10.1109/FiCloud.2015.55. Zte, H.Z., Engineer, S., Management, N., Ptl, O.C.S., n.d. Microservice Powered
Kübert, R., Katsaros, G., Wang, T., 2011. A RESTful implementation of the WS-agreement Orchestration Why Microservice at OPEN-O Challenges of Microservice MSB (
specification. In: Proc. Second Int. Work. RESTful Des. (WS-REST ’11), pp. 67–72. Microservice Bus ) Solution.
https://doi.org/10.1145/1967428.1967444.
Lelylan Dev Center. Building the Connected Home. [WWW Document], n.d. URL http
Ayoub Benayache is a PhD student in Computer systems and networks at Batna 2 Uni-
://dev.lelylan.com/ (Accessed 24 July 2017).
versity. Ayoub received his Master's degree and License's degree at the same university, His
Luzuriaga, J.E., Perez, M., Boronat, P., Cano, J.C., Calafate, C., Manzoni, P., 2015.
research interest in how to integrate heterogonous devices, wireless networks and pro-
A comparative evaluation of AMQP and MQTT protocols over unstable and mobile
tocols in the internet of things.
networks. In: 2015 12th Annu. IEEE Consum. Commun. Netw. Conf. CCNC 2015,
pp. 931–936. https://doi.org/10.1109/CCNC.2015.7158101.
Maamar, Z., Mostefaoui, S.K., Yahyaoui, H., 2005. Toward an agent-based and context- Azeddine Bilami received his Ph.D. from the department of computer science at the
oriented approach for Web services composition. IEEE Trans. Knowl. Data Eng. 17, university of Batna, Algeria in 2005. He is currently serving as a full professor at the same
686–697. https://doi.org/10.1109/TKDE.2005.82. department. Prof. Bilami has published papers in many international journals and con-
Madden, S.R., Franklin, M.J., Hellerstein, J.M., 2004. TinyDB : an Acquisitional Query ferences (IJSNet, IJCA, Robotics and Autonomous Systems, IJIIC, IAJIT, NGNS, IASTED,
Processing System for Sensor Networks, vol. 1. PPAM…) His research Interests are wireless and mobile networks, high-performance in-
terconnects for parallel architectures and multiprocessors, system-on-chip architectures,
TCP/IP and Internet.

153
A. Benayache et al. Journal of Network and Computer Applications 144 (2019) 138–154

Sami Barkat is a PhD student in Computer systems and networks at Batna 2 University., Technical Committee on Information Infrastructure and Networking (2016–2017). He has
Sami obtained his Master's degree and License's degree at the same university, His research served as Co-Program Chair of IEEE WCNC0 2012 and ICC0 2004, Executive Vice-Chair of
interest in heterogeneous communication interfaces, wireless networks and protocols in ICC0 2017, Panel sessions co-chair for Globecom'16, tutorial chair of VTC0 2013 Spring and
machine-to-machine and the internet of things WCNC0 2010, track chair of PIMRC0 2012 and WCNC0 2014, symposium Co-Chair at
Globecom 2007–2011, ICC 2008–2010, ICC0 2014 and '2016. He has served as Co-Guest
Editor for special issues of IEEE Communications Magazine, Networks Magazine, Wire-
Pascal Lorenz ([email protected]) received his M.Sc. (1990) and Ph.D. (1994) from the
less Communications Magazine, Telecommunications Systems and LNCS. He is associate
University of Nancy, France. Between 1990 and 1995 he was a research engineer at
Editor for International Journal of Communication Systems (IJCS-Wiley), Journal on Se-
WorldFIP Europe and at Alcatel-Alsthom. He is a professor at the University of Haute-
curity and Communication Networks (SCN-Wiley) and International Journal of Business
Alsace, France, since 1995. His research interests include QoS, wireless networks and
Data Communications and Networking, Journal of Network and Computer Applications
high-speed networks. He is the author/co-author of 3 books, 3 patents and 200 interna-
(JNCA-Elsevier).
tional publications in refereed journals and conferences. He was Technical Editor of the
IEEE Communications Magazine Editorial Board (2000–2006), IEEE Networks Magazine
since 2015, IEEE Transactions on Vehicular Technology since 2017, Chair of IEEE ComSoc Hafnaoui Taleb obtained his license and master degree in network and systems at the
France (2014–2018), Financial chair of IEEE France (2017–2019), Chair of Vertical Issues University of Batna in Algeria, now he is preparing his PhD at the university of Haute-
in Communication Systems Technical Committee Cluster (2008–2009), Chair of the Alsace in France and at the University of Batna 2 in Algeria. His research interests centre
Communications Systems Integration and Modeling Technical Committee (2003–2009), around the intersection of integrating Wireless Networks in the Cloud Computing, which
Chair of the Communications Software Technical Committee (2008–2010) and Chair of the involves other research domains.

154

View publication stats