2020 International Conference on Decision Aid Sciences and Application (DASA)
InteroEvery : Microservice Based Interoperable
System
Badr El Khalyly 1
Laboratory of Information Technology and Modeling
Hassan II University, Faculty of sciences Ben M'sik,
Casablanca, Morocco
badrelkhalyly92@gmail.com
Allae Erraissi 2
Laboratory of Information Technology and Modeling
Hassan II University, Faculty of sciences Ben M'sik,
Casablanca, Morocco
allae.erraissi-etu@etu.univh2c.ma
Abstract—The advent of Connected objects has been causing
a significant technological revolution. Researchers, Designers,
and developers have been mobilized to develop solutions that
can reach final users in several domains. Solutions that can
make the interaction between users and objects easier and
handier. Therefore, so many efforts have been made to facilitate
device control. A heavy synergy has been carried out as well to
connect objects as a part of the Machine-to-Machine pattern.
Fitting together objects have to take into consideration the
heterogeneity of communication protocols. Brands and
companies produce devices that enable the use of different
protocols from physical to application layer. Each brand adopts
certain protocols in its product that may differ from other
brand’s products. This issue meets the challenge of
interoperability. The building of Applications and solutions that
can monitor objects follow many architectural styles. Nowadays,
the trend of architectural style is microservices. The
Deployment of these applications can be performed on three
levels: Edge – Fog – Cloud. This deployment level mobilizes the
integrators to create and innovate deployment and integration
strategies. This paper will fit together these paradigms to create
a solution that will meet the need for interoperability concerning
the needs of final users.
Keywords—Interoperability, Microservices, Internet of
Things, Model Driven Engineering.
I. INTRODUCTION
There is an increasing demand for applications on the part
of companies. The business logic of applications that perform
the data processing and monitoring may change following the
domain requirements. Companies that produce things –
sensors and actuators – are not obliged to change and adapt
the protocols that are implemented in these things to
communicate with other devices. The systems that monitor
and perform parameters and data processing have to develop
a logic that adapts the incoming data from devices and make
a transformation model to be sent to other devices. The system
in question has to ensure the interoperability of heterogeneous
devices. Heterogeneous devices means devices that use
communication protocols that differ from communication
protocols of other devices. The incoming information from
such a sensor can be used to power several actuators. It is
relevant to have a system that creates virtual objects for
sensors to address the incoming information to be used by
other devices. This paper aims to connect heterogeneous
objects that use different application protocols by proposing a
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE
978-1-7281-9677-0/20/$31.00 ©2020 IEEE 320
Mouad Banane3
Laboratory of Information Technology and Modeling
Hassan II University, Faculty of sciences Ben M'sik,
Casablanca, Morocco
mouad.banane-etu@etu.univh2c.ma
Abdessamad Belangour4
Laboratory of Information Technology and Modeling
Hassan II University, Faculty of sciences Ben M'sik
Casablanca, Morocco
belangour@gmail.com
microservice-based IoT system that ensures applicative
interoperability between different objects. This paper shall
focus on the applicative interoperability, which means
connecting devices that use different protocols from IoT stack
application level. The paper is organized as follows: this work
shall talk about the scientific efforts in the microservices-
based platforms, and the scientific efforts that have been made
in applied interoperability to the Internet of things (Section 2).
The paper describes the system components and talk about
microservice patterns that are used in this distribution (Section
3). Then, the work describes as well the application lifecycle
through an experimental example to show the machine to
machine behavior covered by InteroEvery.
II. RELATED WORK
In the literature, there are several papers [1] [2] [3] [4] [5]
[6] [7] that tackle microservices-based Internet of things
platforms. Their common purpose is to propose an
architecture that helps the final user to control the objects with
loosely coupled solutions. The heterogeneity of device
protocols pushed authors to carry out an architecture that fit
devices together. In [8] paper, authors talk about different
interoperability levels. The paper [9] talks about Taxonomies
and Open Challenges in Interoperability regarding the area of
Internet of Things. Authors talk in this paper about Device
interoperability - Network interoperability - Syntactical
interoperability - Semantic interoperability - Platform
interoperability – Cross-domain interoperability. They talk as
well about Interoperability handling approaches in IoT such
as Adapters/gateways - Virtual networks/ overlay-based
solutions - Networking technologies - Semantic web
technologies – Other open challenges. In the paper [10], the
authors propose a solution to interoperability. In their
architecture, they defined a multi-protocol proxy. This
component handles multiple heterogeneous protocols in one
service. This solution is complex because if a user want to
change the logic of the protocol handle, he has to change the
whole code of the multi-protocol proxy. In the paper [11]
authors propose a multilevel interoperability solution that
connects heterogeneous objects that communicate with
different protocols at a different level: Technological –
Syntactic – Semantic - Organizational. This solution is not
based on microservices. The changing of one of the
components will affect the rest of the whole system. No work
talks about microservice-based IoT applicative
interoperability platform, which links devices that use
 2020 International Conference on Decision Aid Sciences and Application (DASA)
heterogeneous application layer protocol. (i.e. AMQP, COAP,
MQTT).
This work is to propose an architecture of the Microservice
IoT platform to meet the need of applicative interoperability.
The principal purpose of this architecture is to connect
heterogeneous devices without modifying them or adapting
the edge code source that is deployed and uploaded on these
devices and allowing the developers to modify the business
logic of microservices without impacting the rest of the
system. This work answers the following question: How can
use microservices to create an interoperable system?
III. THIS PROPOSED SYSTEM
It is a platform that allows the interoperability of pairs of
objects that communicate with heterogeneous protocols at the
application level based on microservices (for example a sensor
communicating in AMQP with an actuator communicating in
MQTT). The principle is to build a weakly coupled system in
order to meet interoperability requirements. This solution also
makes it possible not to modify or touch the content of
physical objects. Companies are not obliged to modify the
protocols or contents of their objects to be able to
communicate with other objects. The system will retrieve the
information from an object that sends the information via a
specific protocol and performs a transformation in order to
send it to other objects that communicate with a different
protocol. The system stakeholders are as follows:
Manufacturer - User - System administrator.
A. System purpose
This solution is intended for different users in different
types of ecosystems. In each ecosystem, this solution can be
used to ensure M2M behavior [12]. The requirements of an
interoperable system to constitute a weakly coupled system
demand the adoption of a microservice ecosystem. These will
Figure 1: Diagram of components of InteroEvery.
321
ensure the granularity of each service, as well as the
customization of each microservice, and the facilitation of
continuous integration. This system will connect objects
without modifying the edge computing level. That means the
user can connect heterogeneous devices without modifying or
touching the source code of the devices that control actuators
and sensors. This system will just gather information from
sensors that use such an application protocol and perform an
adaptation to send it to the actuators that could use different
application protocols.
B. System stakeholder
The Manufacturer: it is the company or the company that
manufactures this object. Its role is limited to providing the
metadata of the Manufactured product. He is not required to
change the content of his product so that it adapts or so that he
can communicate with other products. It is not necessary to
change the protocol of the application layer (i.e.: MQTT[13],
REST[14], COAP[15], XMPP[16], STOMP[17],
AMQP[18]).
The local user of the ecosystem: It is the user who sets the
solution and registers the objects and chooses the pairs of
objects that are intended to communicate. The system
administrator: It is the user who manages authentication and
authorization, and feeds the system reference data.
C. Description of system components
The offered solution ensures interoperability at the
application level based on microservices. The microservices
that make up the system are JWT authentication micro-service
- object registration micro-service - Interoperability micro-
service - Object connectivity monitoring micro-service -
Adaptation micro-service - Agents launched by adaptation
micro-service.
 2020 International Conference on Decision Aid Sciences and Application (DASA)
The system is also composed of a set of data sources: a
data source of the registration microservice - an
interoperability microservice data source. The system uses a
universal Broker that links the interoperability microservice to
the different adaptation microservices based on choreography
patterns.
1) Object
The physically connected objects are divided into two
categories: Sensors and actuators. The sensor is used to
provide physical quantities. The actuators operate according
to the values perceived by the sensors forming an intelligent
agent. The sensors have categories like (example:
Temperature - Humidity - Gas - Proximity sensor etc.) this
categorization allows the system user to determine the types
of data that capture and expose as (celsius - degree - cm). The
actuators are also categorized (MotorDC - Bulb - Display) and
determine the category of sensors whereby they communicate,
in other words, the actuators anticipate information provided
by the sensors. These metadata will constitute the distributed
data source model for the registry microservice. This
information must be provided by the manufacturer as an
effective actor in this system and inserted by the user
(Architect - Urban planner - Single user).
2) Authentication Microservice
This service authenticates system users. Authentication is
based on the JSON Web Token (JWT) [19]. The data source
for this Microservice is as follows:
Figure 2: Database Schema of A Microservice.
All interfaces are linked to the micro-service by
implementing the "Client-side UI composition" pattern. This
pattern [20] states that the front-end implements the part of the
screen for the service that is linked to.
3) Repository Microservice
This microservice allows the objects to be recorded, either
by uploading the metadata files provided by the manufacturer
or by the user of the system who fills in a web form. This
information is stored in the database whose scheme is
explained as indicated below:
Figure 3: Database Schema of Registry Microservice.
The information about registered things will be used by the
interoperability Microservices via a REST request. The
scheme of the microservice database of registry is as follows:
Thing" relation belongs to a type that determines whether
the object is a sensor or actuator. The "Thing" relationship
322
belongs to a "Category" such as Temperature - Humidity - DC
Motor - Ultrasonic Sensor.
4) Interoperability Microservice
Database per service [21] as its principle indicates,
stipulates that each microservice has its database. This implies
that each microservice must keep its granularity. Required
information from the microservice B database, it is necessary
to develop a query command for µS A to interoperate
microservice B and the latter provides the required
information. This Database per service pattern is applied for
both Interoperability & Registry microservices. This
microservice allows the coupling of objects/agents by
combining objects. This microservice allows you to select an
actuator and display the list of sensors that the actuator
expects. This microservice retrieves the list of recorded data
sensors from the recording microservice using a Database per
service. The user selects for each actuator a sensor proposed
by the system that corresponds to the type mentioned in the
metadata of the objects in the microservice database. The
Database per service application is demonstrated in the
following diagram:
Figure 4: Communication between Registry Microservice &
Interoperability Microservice.
The selected couple is recorded in the database of this
microservice. Then, taking into account the couples of
protocols constituted, a REST request is sent to the
appropriate micro service. For example, if an object pair is
created: actuator operating in MQTT, and a sensor operating
in REST, a request is sent to the MQTT/REST adaptation
micro-service. This microservice is the orchestrator of other
adaptation microservices. The scheme of the microservice
database is as follows:
Figure 5: Database Schema of Interoperability Microservice.
 2020 International Conference on Decision Aid Sciences and Application (DASA)

The data source consists of a single table that provides
information on the connected sensor and actuator torque. This
micro-service is accessible through a graphical interface.
5) Adaptation Microservice
This microservice performs the creation of virtual objects
for the pairs of objects formed in the interoperability
microservice in order to interconnect them. This microservice
is run as a runtime script that retrieves the physical quantities
from the sensor and sends it to the actuator to make it work.
The Interoperability Micro-Service and the Adaptation Micro-
Services form a choreography as shown in this figure below:

Figure 6: Adaptation Microservices - Parts of choreography controlled by Interoperability Microservice.

As part of the choreography, this microservice is

subscribed to the MQTT topic that has been provided by the
system and listens to the publications of the interoperability
microservices. The Interoperability Microservice provides
the Adaptation Microservice with information on protocols,
URLs, and topics of the two objects that user wants to
combine. For example, for an object pair: actuator operating
in MQTT, and a sensor operating in REST, Adaptation
Microservice MQTT/REST creates a client that calls the
remaining URL of sensor, recovers the physical quantity, and
sends it to the MQTT topic to which the actuator is
subscribed. That actuator acts according to the values that are
Figure 7: Mounting Arduino Uno with DHT11.
gathered from the sensor.
IV. PROOF OF CONCEPT
As a proof of concept, in order to validate this approach a
tool is developed as a feasibility prototype.
The microservices of the architecture are developed using
Spring Boot, Rest, RabbitMQ as a broker, and Angular for the
frontEnd part. MySql Database Management System is used
to create the data sources for each microservice. Two objects
are used to validate this approach with the implemented
system: a DHT11 temperature sensor communicating in
REST. And a ServoMotor actuator communicating in MQTT.
These two objects are linked to an ARDUINO
microcontroller on which the temperature capture program Figure 8: Mounting Arduino Uno with ServoMotor.
and the program that runs the ServoMotor actuator are
respectively uploaded. It is the object manufacturer who is DHT11 sensor is supposed to connect to with the
supposed to program these Arduino cards. servoMotor actuator. DHT11 exposes a REST API that is
accessible through a URL and which returns as a response to
the temperature values.

323
 2020 International Conference on Decision Aid Sciences and Application (DASA)
ServoMotor expects numerical temperature values
received and sent by DHT11 so that it can rotate according to
these values. The manufacturers of DHT11 and ServoMotor
have provided information about their products.
A. Registration of objects
First, user starts by entering information about the actuator
in the graphical user interface linked to the recording
microservice as follows:
Figure 9: Recording screen for actuator.
In the actuator registration section, user registers the name
of the type it belongs to - in this case it is ServoMotor - and as
it works in this case in MQTT user mentions the broker URL
and the topic it is subscribed to. User also registers the type of
sensor from which this actuator expects the values to come
from. After recording the information about the ServoMotor
actuator, user record the information about the sensor which
exposes a REST API which returns the temperature values
that the actuator expects to operate.
Figure 10: Recording screen for sensor.
The sensor name "DHT11", the sensor category
"Temperature", the protocol with "REST", the URL and the
port "localhost/9096" are stored. The information on the
ServoMotor actuator and the DHT11 sensor is stored by the
microservice registry in its own database "dbmetadata" in
accordance with the "database per service" principle:
B. Connecting objects
After the registration phase, the system redirects the user
to the interoperability microservice. This microservice is
responsible for the construction of the couple of objects that
user wants to connect in this case - the ServoMotor actuator
and the DHT11 sensor.
324
The system provides a graphical user interface for the
interoperability microservice as follows:
Figure 11: Interoperability microservice screen.
Select the actuator you want to connect: Respecting the
database per service pattern stipulates that no microservice has
the right to access the data source of other microservices. If,
for example, microservice A requests information from the
data source of another microservice B, microservice A is
obliged to go through the query or invocation of the API of
microservice B and the latter returns the requested information
to microservice A. Following this pattern, the interoperability
microservice queries the recording microservice and asks it
for the list of sensors belonging to the category expected by
the selected actuator.
Figure 12: Interoperability microservice screen - Actuator
selection.
C. Launch of suitable adaptation microservice
By clicking on Connect, the sensor/actuator combination
is registered in the interoperability database, then it calls up
the appropriate matching microservice in this case it is the
MQTT/REST microservice and sends it the information about
the sensor and the actuator that user wants to connect.
Figure 13: Interoperability Microservice Display -
Sensor/Actuator Linkage Established.
This MQTT/REST adaptation microservice uses the
REST API of the sensor, retrieves the temperature values, and
publishes them in the topic to which the "ServoMotor"
actuator is subscribed to run it. This can be seen in the
database :
Clicking on disconnect interrupts the connection between
the sensor and the actuator, as shown in the following figure:
 2020 International Conference on Decision Aid Sciences and Application (DASA)
V. CONCLUSION
In this paper, the need to link objects that are
heterogeneous at the application level is described. How can
micro-service be used to interconnect objects that
communicate with application layer protocols that differ from
each other? For this reason, the need for interoperability at the
application level is identified. This work started by defining
the levels of interoperability. Each level of interoperability
belongs to a layer of the Internet stack of objects. As the goal
of this approach is to use micro-services, micro-services are
defined, their objective, their architectural contribution, and
their intervention to create a weakly coupled system. Next,
this proposal for an interoperable system based on
microservices is advocated. The components of this system,
microservices, data sources, and front-end components are
highlighted. The patterns used in this system is described to
demonstrate the system's respect for the micro-service
paradigm.
REFERENCES
[1] Del Esposte ADM, Kon F, Costa FM, Lago N InterSCity: A Scalable
Microservice-based Open Source Platform for Smart Cities
[2] Krylovskiy A, Jahn M, Patti E (2015) Designing a Smart City Internet
of Things Platform with Microservice Architecture. In: Proceedings -
2015 International Conference on Future Internet of Things and Cloud,
FiCloud 2015 and 2015 International Conference on Open and Big
Data, OBD 2015. Institute of Electrical and Electronics Engineers Inc.,
pp 25–30
[3] Thramboulidis K, Vachtsevanou DC, Solanos A Cyber-Physical
Microservices An IoT-based Framework for Manufacturing Systems
[4] Herrera-Quintero LF, Banse K, Vega-Alfonso J, Venegas-Sanchez A
(2016) Smart ITS sensor for the transportation planning using the IoT
and Bigdata approaches to produce ITS cloud services. In: 2016 8th
Euro American Conference on Telematics and Information Systems,
EATIS 2016. Institute of Electrical and Electronics Engineers Inc.
[5] BANICA L, STEFAN C, HAGIU A (2017) Leveraging The
Microservice Architecture For Next-Generation Iot Applications. Sci
Bull - Econ Sci 16:26–32
[6] Cherradi G, El Bouziri A, Boulmakoul A, Zeitouni K (2017) Real-
Time HazMat Environmental Information System: A micro-service
based architecture. In: Procedia Computer Science. Elsevier B.V., pp
982–987
[7] Jarwar MA, Kibria MG, Ali S, Chong I (2018) Microservices in web
objects enabled IoT environment for enhancing reusability. Sensors
(Switzerland) 18:. https://doi.org/10.3390/s18020352
325
[8] M. Noura, M. Atiquzzaman, and M. Gaedke, “Interoperability in
Internet of Things: Taxonomies and Open Challenges,” Mob. Networks
Appl., vol. 24, no. 3, pp. 796–809, Jun. 2019, doi: 10.1007/s11036-018-
1089-9.
[9] M. Noura, M. Atiquzzaman, and M. Gaedke, “Interoperability in
Internet of Things: Taxonomies and Open Challenges,” Mob. Networks
Appl., vol. 24, no. 3, pp. 796–809, Jun. 2019, doi: 10.1007/s11036-018-
1089-9.
[10] I. P. Zarko et al., “Towards an IoT framework for semantic and
organizational interoperability,” Aug. 2017, doi:
10.1109/GIOTS.2017.8016253.
[11] P. Desai, A. Sheth, and P. Anantharam, “Semantic Gateway as a
Service Architecture for IoT Interoperability,” in Proceedings - 2015
IEEE 3rd International Conference on Mobile Services, MS 2015, Aug.
2015, pp. 313–319, doi: 10.1109/MobServ.2015.51.
[12] J. Latvakoski et al., “A survey on M2M service networks,” Computers,
vol. 3, no. 4. MDPI AG, pp. 130–173, Dec. 01, 2014, doi:
10.3390/computers3040130.
[13] S. Appel, K. Sachs, and A. Buchmann, “Towards benchmarking of
AMQP,” in Proceedings of the 4th ACM International Conference on
Distributed Event-Based Systems, DEBS 2010, 2010, pp. 99–100, doi:
10.1145/1827418.1827438.
[14] V. Wang, F. Salim, P. Moskovits, V. Wang, F. Salim, and P.
Moskovits, “Using Messaging over WebSocket with STOMP,” in The
Definitive Guide to HTML5 WebSocket, Apress, 2013, pp. 85–108.
[15] D. Schuster et al., “Creating Applications for Real-Time Collaboration
with XMPP and Android on Mobile Devices,” in Handbook of
Research on Mobile Software Engineering, IGI Global, 2012, pp. 824–
844.
[16] A. Alhaj Ali, “Constrained Application Protocol (CoAP) for theIoT
Safety Standards View project IoT Seminar View project Constrained
Application Protocol (CoAP) for the IoT,” 2018, doi:
10.13140/RG.2.2.33265.17766.
[17] F. Doglio and F. Doglio, “Architecting a REST API,” in Pro REST API
Development with Node.js, Apress, 2015, pp. 65–78.
[18] M. V. Masdani and D. Darlis, “A comprehensive study on MQTT as a
low power protocol for internet of things application,” in IOP
Conference Series: Materials Science and Engineering, Dec. 2018, vol.
434, no. 1, doi: 10.1088/1757-899X/434/1/012274.
[19] K. Shingala, “JSON Web Token (JWT) based client authentication in
Message Queuing Telemetry Transport (MQTT),” Mar. 2019,
Accessed: Aug. 21, 2020. [Online]. Available:
http://arxiv.org/abs/1903.02895.
[20] “Client-side UI composition pattern - Architectural Patterns [Book].”
https://www.oreilly.com/library/view/architectural-
patterns/9781787287495/a47b6a3d-ae41-4232-939a-
61536e8844fa.xhtml (accessed Aug. 21, 2020).
[21] “Database per service.”
https://microservices.io/patterns/data/database-per-service.html
(accessed Aug. 21, 2020).