A Microservice Architecture for Multimobility in a Smart City

Cristian Lai, Francesco Boi, Alberto Buschettu and Renato Caboni

CRS4, Center for Advanced Studies, Research and Development in Sardinia,

Loc. Piscina Manna, Ed. 1 09050, Pula (CA), Italy

Keywords:

Internet of Things, Smart City, Transportation, Multimobility.

Abstract:

In this paper we present a microservice architecture designed to build IoT services available on the Web. The

high potential of microservice architectures will impact the design of complex systems more signiﬁcantly

in the coming years. We propose a draft of architecture that we have used to develop an application for

multimobility services in a smart city using an ecosystem of devices. Such application, designed for a real

case study, is extremely heterogeneous in terms of IoT devices and implements a wide range of services for

citizens. It aims to give a contribution to reducing trafﬁc generated by private vehicles in the city and to help

drivers going towards high trafﬁc areas by presenting real-time mobility data from different sources. The

evaluation of the architecture carried out in this study allows to understand how it behaves under an increasing

number of devices and users connected to the platform, particularly in terms of response time alterations

caused by a large number of requests.

1 INTRODUCTION

During the recent years the amount of connected

devices available in everyday life has signiﬁcantly

grown as crucial part of the Internet of Things (IoT).

ICT is evolving toward more scalable architectures

and those based on microservices are paving the

way for modern applications (Ba

skarada et al., 2018;

Dragoni et al., 2018; Kalske et al., 2018). This pa-

per presents a microservice architecture speciﬁcally

designed and developed for the IoT. This architecture

is capable of integrating both physical and logical de-

vices as well as of managing typical operations such

as device registration, data storage and data retrieval.

Smart cities are more and more enriched with so-

phisticated services (Zanella et al., 2014), especially

for citizens mobility. Multimobility combines differ-

ent modalities of transportation, e.g., private car, bus,

carsharing and bikesharing. The shift from homoge-

neous to multimodal mobility is growing in popular-

ity, especially in urban centers with recurring prob-

lems associated with congestion, parking, and an

overall lack of space (Shaheen et al., 2016). Ev-

eryday, citizens shift among multiple transportation

modalities. Those who move by car may decide to

park and proceed by bus or otherwise. This is why

their main issues are related to ﬁnding a parking slot,

catching the bus on time or choosing the suitable al-

ternative. Other sources of information, such as traf-

ﬁc data, are not associated directly to any transporta-

tion service for the citizens but they rather supply data

that users can consult or that can be exploited oth-

erwise. Every single element, i.e., a parking area, a

bus stop, a car or bike sharing station, takes part of

an extremely sophisticated network of miscellaneous

connected IoT devices that can grow incrementally.

Within a scalable system, a single device is handled

by a dedicated microservice.

A real case study has been set up in the metropoli-

tan area of Cagliari. Drivers moving by car in the

city centre have the available information necessary

to elude high trafﬁc intensity areas avoiding time and

fuel wasting and also preventing increase of trafﬁc.

In the IoT the volume of devices can be remark-

able. It should be noted that by 2020 the IoT could

reach 20 billion internet-connected things and it will

increment revenues for products and services suppli-

ers up to $300 billion (Hung, 2017). In light of this,

scalability is a non-functional feature of the software

which requires special attention. Scalable IoT sys-

tems ensure indeed adequate response times for data

delivery to/from devices and data reading (Bondi,

2000). Microservice architectures, by nature, take

into account and handle scalability (Hasselbring and

Steinacker, 2017), but need additional efforts to cal-

ibrate the necessary number of instances of each mi-

croservice, to scale each microservice independently

and to synchronize data among them. We have mea-

Lai, C., Boi, F., Buschettu, A. and Caboni, R.

A Microservice Architecture for Multimobility in a Smart City.

DOI: 10.5220/0007830506570664

In Proceedings of the 14th International Conference on Software Technologies (ICSOFT 2019), pages 657-664

ISBN: 978-989-758-379-7

657

sured system performances, under an increasing num-

ber of devices registered to the platform and an in-

creasing number of connected users, to address scala-

bility. We have evaluated the ability of the system to

guarantee adequate performance in case of high data

volume (resilience) and an appropriate SLA (Service

Level Agreements).

This paper is organized as follows. Section II re-

views state of the art service oriented architectures.

Section III describes the microservice architecture de-

signed and developed for mobility services in smart

cities. Section IV illustrates the implementation of a

real case study. In Section V the evaluation of the im-

plemented architecture is described. Finally, Section

VI provides conclusions and future perspectives.

2 STATE OF THE ART

The enormous amount of connected devices has en-

abled a widespread diffusion of large IoT systems.

Infrastructures, platforms and software applications

are offered often as services using cloud technolo-

gies (Perera et al., 2013). In IoT systems a central-

ized architecture is responsible for offering one or

more services to the user while the necessary data

is produced by a set of devices deployed in different

locations. This generates an amount of data easily

available, used to create vertical applications. In the

IoT, a single standard or implementation has not yet

been established, but several competing paradigms

are candidates to become the main reference. There

are several middleware that act as layers of abstrac-

tion between heterogeneous IoT devices and IoT sys-

tems enabling interactions between heterogeneous de-

vices. The cloud-based ThingSpeak platform (Lai

et al., 2018; Abdul-Rahman and Graves, 2016), is

an open source IoT application and API (Applica-

tion Programming Interface) for storing and retriev-

ing data from ”things” using the HTTP protocol. The

ThingSpeak API allows for numeric data process-

ing such as time scaling, averaging, median, sum-

ming and rounding and it is used as a middleware

to manage low-level network operations, data collec-

tion and real-time data annotation/transformation. It

is useful for several real life IoT applications such

as smart home applications and IoT agriculture, but

it is mostly oriented to collect, analyze and trigger

reactions. Xively

allows to connect devices over

MQTT (Message Queuing Telemetry Transport) pro-

tocol. Used mainly in agriculture and domotics, it

supports many data formats and offers fast and re-

https://xively.com/

liable database intelligence. Each source of infor-

mation must be analyzed individually and the pri-

ority of each process must be scheduled individu-

ally. This can generate overloads and bottlenecks.

LinkSmart

(Harlamova et al., 2017; Kostelnik et al.,

2011), a service-oriented middleware, uses the SOA

(Service-Oriented Architecture) architecture to gen-

erate services in home automation, healthcare and

smart agriculture contexts. LinkSmart allows inte-

gration with existing systems and services through

widespread standards and solves security problems

through virtualization. OpenHAB

(Open Home Au-

tomation Bus) is an open-source middleware, born

as an extension of the Eclipse SmartHome project

and designed for smart environments development,

such as smart ofﬁces and smart homes. Any Open-

HAB instance contains modules called bundles that

run within a single OpenHAB instance.

Many are successful state of art technologies but

are monolithic applications built as a single unit,

hence not offering the ﬂexibility required to deal with

heterogeneous devices efﬁciently. Often, they con-

sist of three main parts: a client-side user interface, a

database and a server-side application. Changes to the

system require building and deploying a new version

of each component. On the contrary, microservice ar-

chitectures are divided into a number of small inde-

pendent services, each of which implements a certain

feature. A scalable architecture achieves a more efﬁ-

cient management of available resources by allocating

only to those modules that are actually overstressed,

rather than unconditionally to all the sub-components

(Dragoni et al., 2018; Krylovskiy et al., 2015).

3 MICROSERVICE

ARCHITECTURE

The microservice architecture discussed in this pa-

per combines a variety of IoT devices and services.

Namely CMC-IoT, is a fork and extends CMC-Core

our ﬁrst open source project implementing a general

purpose microservice architecture. CMC-IoT is the

foundation of our ﬁrst web application designed for

citizen multimobility in a smart city, called SmartMo-

bility.

https://www.linksmart.eu/

http://www.openhab.org/

https://github.com/smartenv-crs4

ICSOFT 2019 - 14th International Conference on Software Technologies

658

3.1 CMC-Core

CMC-Core provides independently deployable and

loosely coupled basic services. Each microser-

vice runs in its own process, communicates with

lightweight mechanisms, such as HTTP resource API

(Fowler and Lewis, 2014) and manages signiﬁcant

operations. The microservices composing CMC-Core

are the following:

• Cmc Auth is a token generator that protects

microservices from unauthorized access using a

token-based authentication technique. Cmc Auth

generates different types of tokens enabling ac-

cess to speciﬁc endpoints of a protected microser-

vice. The three types of tokens that can be gen-

erated are: i) Microservice Token, to access any

resource made available by microservices and to

allow communication and exchange data among

them; ii) User Token, to access resources for user-

related services; iii) Application Token, to access

resources from general purpose third-party appli-

cations.

• Cmc App manages resources and applications

sign-up and the subsequent sign-in phase. When

resources or applications sign-in, Cmc App asks

for an Application Token to Cmc Auth. Cmc

App releases the token to the applicant that con-

sequently can access any protected microservice

(MS, see Fig. 1). Moreover, CMC Auth man-

ages any authorization rule to access a speciﬁc mi-

croservice.

• Cmc User manages user access to protected mi-

croservices. Users can sign-in with credentials to

obtain a user token. This token can be used only

by the owner of speciﬁc resources related to the

protected microservices.

Figure 1: CMC-Core. A typical use case.

In Fig. 1, the microservices MS1, MS2 and MS3

grant access to a third-party application. The applica-

tion is authorized to call these microservices through

an Application Token. When the token expires, the

application or user must sign-in again. The same pro-

cedure is used to authenticate and authorize user ac-

cess to one or more microservices.

CMC-Core offers only the presented basic ser-

vices but can be easily extended with new features

using the available plugins. With this approach CMC-

IoT has been developed, starting from the architecture

of CMC-Core, to have a complete system more suit-

able for IoT and smart city applications.

3.2 CMC-IoT

CMC-Iot is compound of the following additional mi-

croservices:

• Cmc Devices manages the device functionalities

providing the REST CRUD (Create Read Up-

date Delete) operations. Each device must have a

unique id to be unambiguously identiﬁed (for ex-

ample the mac-address), a category and a physical

connector. Optionally also its geolocation and a

nickname can be speciﬁed. A connector allows di-

rect interaction with CMC-IoT. For those devices

unable to perform HTTP operations, a middle-

ware (see Fig. 2) is required to mediate the com-

munication to CMC-IoT. Devices can read from

and write to Cmc Device using a REST API. Ex-

ternal systems are synchronized with Cmc De-

vices for events such as new available data, ad-

dition of a new device to the platform. The most

common protocols such as MQTT

, COAP (Con-

strained Application Protocol) (Thangavel et al.,

2014) and others are directly supported by Cmc

Devices. In case of user related devices (e.g.,

wearable and home smart objects) User Tokens

guarantee access to Cmc Devices. General pur-

pose devices, not directly associated to any par-

ticular user (e.g., public trafﬁc data, parking, open

data), use Application Tokens.

• Cmc History stores and retrieves historical data

produced by devices. Moreover, it allows to ﬁl-

ter and search data by device id, time, device cat-

egory, type of connector and others. In case of

device failure last available data can be recovered.

• Cmc Persistence is a scheduler for general pur-

pose devices that do not directly provide their data

to CMC-IoT. It performs data reading using Cmc

Devices and data saving through Cmc History.

Once a device has been added to CMC Devices

and a User Token or Application Token has been

released, data can be sent through token authorized

http://mqtt.org/

A Microservice Architecture for Multimobility in a Smart City

659

Figure 2: CMC IoT.

write operations and then read by other authorized de-

vices, applications or users. Cmc Devices uses the

core features of CMC-Core to validate tokens and to

authorize queries on registered devices.

4 CASE STUDY

We have considered a real case study in the city of

Cagliari, located in the Sardinia island, Italy. The aim

is to contribute to the reduction of trafﬁc generated by

private vehicles in the city. SmartMobility, the appli-

cation developed during this project, helps drivers go-

ing towards high trafﬁc areas by presenting in a clear

way and on the same platform real-time mobility data

from different sources. SmartMobility is made up by

the following macro components:

• CMC-IoT (see Section 3.2);

• data sources: any piece of hardware or software

(including external services such as Web-APIs

and portals) producing relevant data (see Section

4.2);

• Web portal: the user interface presenting the ac-

quired data in an easy and understandable way to

the user (see Section 4.3). Even though the best

solution is a mobile APP, so far we have decided

to develop a web application. This allows to de-

sign a complete user interface and quickly mock

up a running system. Moreover, the web appli-

cation with responsive capabilities can be used in

mobile devices.

4.1 Scenario

Before entering the city centre the driver, using the

SmartMobility application, can check available free

parking spots in the monitored parking areas that are

close to his destination. In this way he/she does not

have to drive around the city looking for a free park-

ing spot. Once a parking lot has been identiﬁed and

chosen, the user can choose the fastest path to reach it

according to real-time trafﬁc information in the main

city roads shown in SmartMobility. The driver can

again check on the application the availability of mo-

bility services around the parking area, such as bus

stops and sharing services, and their reliability so that

he/she can choose the one most suitable for his/her

needs or alternatively walk to the ﬁnal destination.

4.2 Data Sources

SmartMobility collects data from different data

sources:

• real-time trafﬁc information: the municipality of

Cagliari has created an infrastructure of inductive-

loop trafﬁc detectors (commonly referred to as

trafﬁc sensors) that can detect vehicles passing by.

These sensors are installed in the main roads con-

necting the suburbs to the city center. Data re-

turned by REST APIs contain the ﬂow of vehi-

cles per unite of time and the average speed. This

information is used to estimate trafﬁc ﬂow at the

time the user is supposed to pass so that he/she

have the necessary information to elude high traf-

ﬁc zones;

• parking space vacancy detection system: an au-

tomatic system installed in open-access parking

lots. Our system uses cameras and image pro-

cessing for detecting vacant and occupied parking

spaces. SmartMobility is constantly updated on

parking availability so that users can directly drive

to the area closest to their destination where most

likely they will ﬁnd a free parking spot, avoiding

in this way time and fuel wasting, and reducing

trafﬁc congestion;

• public transport information: most of the public

transport companies in Cagliari and its extended

area have offered data of their bus services for this

project. Bus service information includes avail-

able bus lines, bus stops, the timeschedule and the

reliability of each line;

• carsharing: a private company offers the fast-

growing carsharing service in the city of Cagliari.

They provide their service data through web ser-

vices. Available information includes the current

status of each carsharing parking area (number

and models of the available cars, booked reserva-

tions etc.);

• bikesharing: data include the geographical posi-

tion of each dock and the number of available

bikes in it. Due to temporarily unavailability, data

have been simulated keeping the same format.

Each data type has its own format and procedure

for being retrieved. To communicate with such het-

ICSOFT 2019 - 14th International Conference on Software Technologies

660

erogeneous data sources, CMC Devices uses differ-

ent types of connectors, one for each kind. A single

CMC Devices instance manages many devices in or-

der to avoid computational overhead. CMC Persis-

tence periodically retrieves carsharing data from the

proper endpoint while CMC History stores last month

trafﬁc data to predict the current trafﬁc ﬂow. In our ar-

chitecture, the microservices are deployed in Docker

containers that provide the needed ﬂexibility and keep

the overhead sufﬁciently low, compared to traditional

virtual machine solutions.

4.3 Web Portal

The SmartMobility web portal contains all the ele-

ments compounding the UI (User Interface) and cor-

responding to the variety of devices and services man-

aged by CMC-IoT. The UI shows a map containing

the geographical location of the devices (bus stops,

parking lots, trafﬁc. sensors, bike docks and car shar-

ing parkings) composing the different mobility ser-

vices. On the UI, graphic elements of the same kind

are grouped together. The user selects the services

in which he/she is interested from a drop-down menu

(see Fig. 3).

Figure 3: Available services in SmartMobility.

On the map the relevant elements are shown fol-

lowing a layered approach. Each item presents ad-

ditional information. For example, when selecting a

parking lot not only the overall parking capacity and

current availability, but also further information re-

lated to the other mobility services in the area close

to it is shown in real-time. The bus stop selection pro-

vides the available lines, the timeschedules and ser-

vice reliability information. Clicking on a carsharing

or bikesharing station displays the number of avail-

able vehicles in it. Fig. 4 shows an example in the

case of the carsharing service.

The web interface is developed using the enter-

prise open source software Entando

. Entando is an

open source Digital Experience Platform (DXP) for

https://www.docker.com

http://www.entando.com

Figure 4: Additional information, carsharing.

vertical portals. The namesake enterprise is also part-

ner of CRS4 in the project that partially supported this

work (see Section 6). Extensions available in the plat-

form have been exploited to create the software plu-

gin modules needed for the integration with CMC-IoT

and for the web portal development. The web portal

is updated in real-time when new data are available

on CMC-IoT. The result is pleasant visualization of

smart city data on the graphical interface.

5 EVALUATION

We have identiﬁed a pattern of actions the user is sup-

posed to perform on the web portal according to the

scenario in Section 4.1.

1. Identify the parking lots.

2. Find the trafﬁc sensors close to a chosen parking

lot.

3. Find the bus stops, carsharing and bikesharing sta-

tions around the identiﬁed parking lot.

The supposed actions generate requests to CMC-

IoT, referred to as user requests.

Tests simulating the pattern have been deﬁned

and performed to understand how CMC-IoT behaves

when the number of devices and user requests in-

crease. During these tests we have measured the re-

sponse time of user requests and the number of failed

requests. CMC-IoT has been run on a virtual machine

with 8 GB of RAM memory, 4 cores and Ubuntu

18.04 as operating system.

5.1 Pattern of User Actions

The pattern detailed in the Algorithm 1 simulates hu-

man interaction with the SmartMobility application

according to the scenario of Section 4.1.

First, the algorithm simulates the user destination

by randomly choosing a point in the city centre. Then

it proceeds with looking for the parking lots close to

the destination within a given radius. After randomly

A Microservice Architecture for Multimobility in a Smart City

661

Algorithm 1: Algorithm simulating human interaction

with the SmartMobility application according to the

scenario described in Section 4.1. User’s actions

generate requests to CMC-IoT to retrieve data of the

desired mobility services. r is the searching radius. The

notation el

←− l

means randomly choose an element

from the list of sensors l

of type i.

p ← random point in the city centre;

r ← 500m;

← get from CMC-IoT the parking areas

around p within r;

if l

0 then

←− l

;

read el

most recent data from CMC-IoT;

p ← (el

geographical position);

← get from CMC-IoT the trafﬁc

sensors around p within r;

if l

0 then

←− l

;

read el

current data from CMC-IoT;

end

r ← 200m;

← get from CMC-IoT the bus stops

around p within r;

if l

0 then

←− l

;

read el

data from CMC-IoT;

end

r ← 500m;

← get from CMC-IoT the bikesharing

docks around p within r;

if l

0 then

←− l

;

read el

current data from CMC-IoT;

end

r ← 300m;

← get from CMC-IoT the carsharing

stations around p within r;

if l

0 then

←− l

;

read el

current data from CMC-IoT;

end

choosing a parking lot from the retrieved ones, the al-

gorithm detects all the other mobility services, includ-

ing trafﬁc sensors around it and within a maximum

distance. As already explained in the scenario, this

allows the driver to choose the fastest path to reach

the parking area and the best alternative to move from

the parking lot where the driver’s car has been parked

to the ﬁnal destination of the user.

The searching radius has been empirically chosen

for each device type in order to prevent the pattern

from returning empty lists: the larger the radius, the

more likely it is to ﬁnd a sensor of that type around

the given geographical point. However it still might

happen that no device of that type is found: in this

case the pattern will skip the next requests depending

on this result and continue with the others, if any, or

terminate.

5.2 Test Conﬁguration

Starting from a basic test conﬁguration compound of:

• 440 data sources (5 parking lots, 300 bus stops,

100 trafﬁc sensors, 30 carsharing parking areas

and 5 bikesharing docks);

• 10 users;

we perform four rounds of tests, each one consist-

ing of four test runs (see table 1). Within the same

round the number of devices is kept constant while

the number of users is increased ten times at each test

run. In the next round the number of devices is in-

creased ten times and the number of users starts back

from 10 as in the basic test conﬁguration. At each test

run each user performs the pattern 50 times.

Table 1: Table summarizing the number of devices and

users for each test run. Each row is a single round of tests

having the same number of devices. Columns are test runs

with the same number of users.

Round Test run

1 2 3 4

devices users devices users devices users devices users

1 440 10 440 10

440 10

2 4400 10 4400 10

4400 10

3 44000 10 44000 10

44000 10

4 440000 10 440000 10

440000 10

5.3 Measures

At each test run we collect the following data:

• average CPU usage of the virtual machine running

CMC-IoT;

• average memory usage of the virtual machine run-

ning CMC-IoT;

• number of failed requests;

• response time of user requests: the average of

time intervals between the moment the client per-

forms a request and the time it gets a response, ac-

cording to the technique explained in (Hoxmeier

and Dicesare, 2000).

The operations depicted in the Algorithm 1 are

performed by the Apache JMeter

testing tool . It

https://jmeter.apache.org

ICSOFT 2019 - 14th International Conference on Software Technologies

662

allows to perform the requests to CMC-IoT and to

store for each request the desired response informa-

tion, such as response code and response time, on

the user-side hardware. The average CPU usage and

average memory usage are monitored with NetData

on the server-side (the virtual machine running CMC-

IoT).

5.4 Results

Figure 5: Average response time of user requests for each

test run.

According to JMeter all requests are successful

and no failure occurs. Fig. 5 shows the average re-

sponse time of user requests for each test in logarith-

mic scale. Each bar is the average response time of

user requests for the corresponding test run. Results

of runs having the same number of users are grouped

together, while results of test runs with the same num-

ber of devices have the same color. It is clear from

the graph how the average response time of the re-

quests increases with the number of users and with the

number of devices. However in the group with 10000

users, we have an unexpected behaviour: within this

group the test run with 440x1000 devices (the green

bar in the last group) has an average response time

smaller than the test runs (within the same group) with

440x10 (the blue bar) and 440x100 (the red bar) de-

vices. Furthermore compared to the group of 1000

users, the test runs having a number of devices equal

to 440x1, 440x10 and 440x1000 have a smaller av-

erage response time even of they have a larger num-

ber of users. Additional investigations will be carried

out in future works to understand this behaviour but

the hypothesis is that more computational power is

needed to simulate such a large number of users.

As for the server, used memory is around 4 GB

and it remains constant among all the tests. This indi-

cates more instances of the microservices can be cre-

ated even with this hardware conﬁguration. The graph

for the CPU percentage usage is reported in Fig. 6.

https://my-netdata.io

Figure 6: Average CPU usage percentage for each test run.

6 CONCLUSIONS

IoT in smart cities is becoming pervasive and will in-

crease even more in the coming years. The network of

connected devices requires more efﬁcient infrastruc-

tures, platforms and services in the IoT ecosystem.

Microservices, in contrast to aged monolithic archi-

tectures, have been proved to be a valid and robust so-

lution for modern complex scenarios, and have been

recognized to accelerate the evolution of software ap-

plication models.

Our application is a demo validating the effec-

tiveness of the drafted microservice architecture in a

real case study. All the devices and services included

in this speciﬁc implementation compound a compre-

hensive miscellaneous system. The potential of the

adopted microservice architecture allows to design

modular systems that can grow incrementally without

continuous redesign, development and deployment of

the entire application. The system is divided into

small and lightweight services, purposely built to per-

form a very cohesive business function. Every sin-

gle element, i.e., a parking area, a bus stop, a car

or bike sharing station could be added as well as re-

moved independently, while the system can be fur-

ther enriched with new services. Both these actions

can be performed by modifying only the directly in-

terested modules without affecting the others. Ser-

vices independence allows to reach for an extremely

sophisticated network of connected IoT devices. On

the contrary, in monolithic applications scaling highly

demanded services requires a comprehensive effort in

the whole system. All services are scaled at the same

time, with resources allocated even for services barely

used. Presently SmartMobility has been developed as

a web portal. In the future we intend to design a more

suitable APP for mobile devices that will perfectly ﬁt

the user experience.

Several tests have been performed to determine

performances under an increasing number of requests

per unit of time. Goals of these tests are to under-

A Microservice Architecture for Multimobility in a Smart City

663

stand how many concurrent requests the presented

microservice architecture can handle given limited

hardware resources and how scalability should be ad-

dressed. Regarding the scalability, as a follow up, ad-

ditional tests will aim at ﬁnding out which services are

more stressed and according to the results a proper al-

gorithm for managing scalability will be studied and

implemented. In future works scalability will be prop-

erly automated according to these results and each mi-

croservice will be instantiated according to its work-

load and independently from the others. When mul-

tiple instances are present, workload distribution and

data synchronization among different instances must

be addressed too.

ACKNOWLEDGEMENTS

This work has been partially supported under the

ERDF (European Regional Development Fund), PO

Sardegna FESR 2007-2013, PIA 2013 (project: n.295

PIA ENTANDO).

REFERENCES

Abdul-Rahman, A. I. and Graves, C. A. (2016). Internet

of things application using tethered msp430 to things-

peak cloud. In SOSE, pages 352–357. IEEE Computer

Society.

skarada, S., Nguyen, V., and Koronios, A. (2018). Ar-

chitecting microservices: Practical opportunities and

challenges. Journal of Computer Information Sys-

tems, pages 1–9.

Bondi, A. B. (2000). Characteristics of scalability and their

impact on performance. In Proceedings of the 2Nd In-

ternational Workshop on Software and Performance,

WOSP ’00, pages 195–203, New York, NY, USA.

ACM.

Dragoni, N., Lanese, I., Larsen, S. T., Mazzara, M.,

Mustaﬁn, R., and Saﬁna, L. (2018). Microservices:

How to make your application scale. In Petrenko,

A. K. and Voronkov, A., editors, Perspectives of Sys-

tem Informatics, pages 95–104, Cham. Springer Inter-

national Publishing.

Fowler, M. and Lewis, J. (2014). Microservices.

Harlamova, M., Kirikova, M., and Sandkuhl, K. (2017). A

survey on challenges of semantics application in the

internet of things domain. Applied Computer Systems,

21(1):13–21.

Hasselbring, W. and Steinacker, G. (2017). Microservice

architectures for scalability, agility and reliability in

e-commerce. In 2017 IEEE International Conference

on Software Architecture Workshops (ICSAW), pages

243–246.

Hoxmeier, J. A. and Dicesare, C. (2000). System response

time and user satisfaction : An experimental study of

browser-based applications.

Hung, M. (2017). Leading the iot. Technical report, Gart-

ner.

Kalske, M., M

akitalo, N., and Mikkonen, T. (2018). Chal-

lenges when moving from monolith to microservice

architecture. In Garrig

os, I. and Wimmer, M., edi-

tors, Current Trends in Web Engineering, pages 32–

47, Cham. Springer International Publishing.

Kostelnik, P., Sarnovsky, M., and Furdik, K. (2011). The

semantic middleware for networked embedded sys-

tems applied in the internet of things and services do-

main. Scalable Computing: Practice and Experience,

12(3):307–315.

Krylovskiy, A., Jahn, M., and Patti, E. (2015). Designing

a smart city internet of things platform with microser-

vice architecture. In 2015 3rd International Confer-

ence on Future Internet of Things and Cloud, pages

25–30.

Lai, C., Pintus, A., and Serra, A. (2018). Using the web

of data in semantic sensor networks. In Barolli, L.

and Terzo, O., editors, Complex, Intelligent, and Soft-

ware Intensive Systems CISIS 2017. Advances in In-

telligent Systems and Computing, vol 611. Springer,

Cham, pages 106–116.

Perera, C., Zaslavsky, A., Christen, P., and Georgakopou-

los, D. (2013). Sensing as a service model for

smart cities supported by internet of things. Transac-

tions on Emerging Telecommunications Technologies,

25(1):81–93.

Shaheen, S., Stocker, A., and Bhattacharyya, A. (2016).

Multimobility and sharing economy. Technical Report

E-C120, Transportation Research Board, 500 Fifth

Street, NW, Washington, DC 20001.

Thangavel, D., Ma, X., Valera, A., Tan, H.-X., and Keng-

Yan Tan, C. (2014). Performance evaluation of mqtt

and coap via a common middleware.

Zanella, A., Bui, N., Castellani, A., Vangelista, L., and

Zorzi, M. (2014). Internet of things for smart cities.

IEEE Internet of Things Journal, 1(1):22–32.

ICSOFT 2019 - 14th International Conference on Software Technologies

664