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

net/publication/317782761

Microservices Science and Engineering

Conference Paper · July 2017

CITATIONS READS

4 368

6 authors, including:

Manuel Mazzara Kevin Khanda

Innopolis University Innopolis University
253 PUBLICATIONS   1,919 CITATIONS    7 PUBLICATIONS   154 CITATIONS   

SEE PROFILE SEE PROFILE

Ruslan Mustafin Victor Rivera

Innopolis University Innopolis University
26 PUBLICATIONS   620 CITATIONS    57 PUBLICATIONS   197 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Social Network Analysis View project

Data Mining and Machine Learning for Knowledge Discovery and Predictive Analysis View project

All content following this page was uploaded by Manuel Mazzara on 22 June 2017.

The user has requested enhancement of the downloaded file.

 Microservices Science and Engineering

Manuel Mazzara1 , Kevin Khanda1 , Ruslan Mustafin1

Victor Rivera1 , Larisa Safina1 , and Alberto Sillitti1

Innopolis University, Russian Federation

{m.mazzara,k.khanda, r.mustafin, v.rivera, l.safina,
a.sillitti}@innopolis.ru

Abstract. In this paper we offer an overview on the topic of Microser-

vices Science and Engineering (MSE) and we provide a collection of bib-
liographic references and links relevant to understand an emerging field.
We try to clarify some misunderstandings related to microservices and
Service-Oriented Architectures, and we also describe projects and appli-
cations our team have been working on in the recent past, both regarding
programming languages construction and intelligent buildings.

1 Introduction

Innovative engineering is always looking for adequate instruments to design soft-

ware systems and support developers all along the development process to de-
ploy correct software. Microservices [1] recently demonstrated to be an effective
architectural paradigm to cope with software complexity, and in particular scal-
ability [2]. The success of the paradigm has been demonstrated in a number of
domains, including mission-critical systems [3].
Around the concept of microservice a number of activities emerged, both of
scientific or purely engineering interest. The field of Microservices Science and
Engineering (MSE) is not completely established at the moment, and neither it
is clearly defined. In this paper, we offer an overview intended as a collection of
bibliographic references and links to the field, focusing mostly on recent applica-
tions we have been working and on the activities of our team. We aim at focusing
on three major aspects: (1) the emerging of the Microservice architectural style
and its peculiarities (2) a language-based approach to support Microservice (3)
applications, for example in programming languages and intelligent buildings.
The paper is structured as follows. After this short introduction, in Section 2
we will discuss the main concepts of Microservice literature. In Section 3 we
will introduce the Jolie programming language, an open source project aimed at
supporting microservice development from a linguistic point of view. In Section 4
we will discuss the contribution of our research team to the development of the
Jolie programming language and in the field of Smart Building. Section 5 will
finally draw some conclusive remarks.
2 Manuel Mazzara et al.

2 What is a microservice?

Microservices [1] are not just small services, which means little by itself. It
is an architectural style that originated from Service-Oriented Architectures
(SOAs) [4] [5], that we will try to emphasize here. The main idea is to move
in the small (within an application) some of the concepts that worked in the
large, i.e. for cross-organization business-to-business workflow which makes use
of orchestration engines such as WS-BPEL (in turn inheriting some of the func-
tional principles from concurrency theory [6]).
When following the microservice paradigm, a system is structured by com-
posing small independent building blocks communicating exclusively via message
passing. These components are called microservices. The characteristic differen-
tiating the new style from monolithic architectures and classic Service-Oriented
is the emphasis on scalability, independence, and semantic cohesiveness of
each unit constituting the system.
Indeed, mainstream languages for development of server-side applications
(e.g. Java, C/C++, Python) still provide abstractions to break down the com-
plexity of programs into modules or components [7] [8] [9], but these languages
are designed for the creation of single executable artifacts. In monolithic archi-
tecture the modularization abstractions rely on the sharing of resources of the
same machine (memory, databases, files) and the components are therefore not
independently executable. In Figure 1, the classic monolithic organization is pic-
torially described: here the different layers of the system, from presentation to
access to persistence tools, and including the business logic, are split in terms
of responsibilities between different modules (here indicated by the vertical split
with numbers from 1 to 4). In fact, each module may take part in the imple-
mentation of functionalities related to each layer, the database is common, and
so the access to other resources such as memory.

Fig. 1. Monolith Architecture

 Microservices Science and Engineering 3

A notable problem of monoliths is maintainability and evolvability, all issues

related to change. In [1] a detailed description of these aspects is given, together
with our own definition of microservice which tries to shed some light in the cur-
rently intricate and young literature. Figure 2 shows how the componentization
is done in a microservice architecture: each own service has a dedicated persis-
tence tool and communication is via message passing. In this kind of organization
there is no vertical split through all the system layers and the deployment is inde-
pendent. The complexity is moved to the level of coordination of services (often
called orchestration [10]). Moreover, a number of additional problems need to
be addressed due to the distributed nature of this kind of approach (e.g., trust
and certification [11]).

Fig. 2. Microservices Architecture

The first set of question asked in this context typically is: how small? Is a
Microservice a very small service? What does it mean? How do we measure size
(Line of codes, size of executable, number of classes or modules, size of API, size
of team)?
A Microservice is not just a very small service. There is not a predefined
size limit that defines whether a service is a microservice or not. Indeed mi-
croservice is a somehow misleading definition. Each microservice is expected to
implement a single business capability, in fact a very limited system functional-
ity, bringing benefits in terms of service maintainability and extendability. Since
each microservice represents a single business capability, which is delivered and
updated independently, discovering bugs or adding minor improvements do not
have any impact on other services and on their releases. In common practice, it
is also expected that a single service can be developed and managed by a single
team [1].
The idea to have a team working on a single microservice is rather appealing:
to build a system with a modular and loosely coupled design, one should pay
attention to the organization structure and its communication patterns as they,
according to Conway’s Law [12], directly impact the produced design. So if one
creates an organization with each team working on a single service, such structure
4 Manuel Mazzara et al.

will make the communication more efficient not only on the team level, but within
the whole organization, improving the resulting design in terms of modularity.
Microservices’ approach is to keep teams small and communications efficient by
creating small cross-functional (DevOps) teams that are able to continuously
work on the same service and to be fully responsible for it (the “you build it,
you run it” principle [13]). The teams are organized around services, which in
turn are organized around business capabilities [14] The optimal team size for
microservices is best described by Jeff Bezos famous “two pizza team” rule, which
suggests that the size of a team should be no larger than what two pizzas can feed.
The rule itself does not give an exact number, however it is possible to estimate
it to be around 6-8 people. The drawback of such approach is that it is not
always practical from the financial point of view to maintain a dedicated team of
developers for a single service as it may lead to high development/maintenance
costs [15]. Furthermore, one should be careful when designing the high level
structure of the organization using microservices - increasing the number of
services will negatively impact on the overall organization efficiency, if no actions
are taken.
The second set of questions that often arises is instead: is this the same
story than SOA? What are the differences? Indeed there are some notable dif-
ferences. In SOA, services are not required to be self-contained with data and
User Interface, and their own persistence tools, eg. database. SOA has no fo-
cus on independent deployment units and related consequences, it is simply
an approach for business-to-business intercommunication. The idea of SOA was
to enable business-level programming through business processing engines and
languages such as WS-BPEL and BPMN that were built on top of the vast lit-
erature on business modelling [16]. Furthermore, the emphasis was all on service
orchestration more than service development and deployment.
Microservices have seen their popularity blossoming with an explosion of con-
crete applications seen in real-life software [17]. Several companies are involved
in a major refactoring of their back-end systems in order to improve scalabil-
ity [2]. In [3] a real world case study, concerning the migration of a mission
critical system from an existing monolithic architecture to microservices, has
been presented. This case study shows the will of major companies to cope with
scalability issues.

3 Jolie: a Language-based Approach

The notable success of the approach gave rise to both academic and commercial
interest, and ad-hoc programming languages arose to address the new architec-
tural style [18]. In principle, any general-purpose language could be used to pro-
gram microservices. However, some of them are more oriented towards scalable
applications and concurrency [19] . The Jolie (Java Orchestration Language In-
terpreter Engine) [18] programming language, for example, is based on the new
paradigm and it allows describing computation from a data-driven instead of
 Microservices Science and Engineering 5

process-driven perspective [20]. As another advantage, Jolie has already a large

community of users and developers [21].
Jolie is a functional programming language that combines a multiplicity of
aspects that are destined to revolution the way in which software is conceived,
designed and understood. Originated from a major formalization effort [22] for
workflow and service composition [23], the language does not integrate a notion
of correctness; it is simply built on it. The intuitiveness of the message-passing
paradigm supports the design phase and avoids side effects that are not trivial
to test. Four important concepts are identified to be first class entities in the
programming language in order to address the microservice architecture:

1. Interfaces: to support modular programming, services has to be deployed

as black boxes. In order to compose services in larger systems, interfaces
have to describe the provided functionalities and those required from the
environment.
2. Ports: since a microservice interacts with other services, a communication
port describes how its functionalities are made available to the network (in-
terface, communication technology, and data protocol). Ports should be spec-
ified separately from the implementation of a service. Input ports describe
the functionalities that the service provides to the rest of the system, while
output ports describe the functionalities that the service requires from the
rest of the system.
3. Workflows: structured protocols appear repeatedly in microservices and they
are not natively supported by mainstream languages. All possible operations
are always enabled (for example in Object-Oriented programming). Causal
dependencies are programmed by using a book-keeping variable, which is
error-prone, and it does not scale when the number of causality links in-
creases. A microservice language should provide abstractions for program-
ming workflows.
4. Processes: workflows define the blueprint of the behavior of a service. At
runtime a service may interact with multiple clients and other external ser-
vices, therefore there is need to support multiple concurrent executions of
its workflow. A process is a running instance of a workflow, and a service
may include many processes executing concurrently. Each process runs in-
dependently of the others, to avoid interference, and has its own private
state.

Let us illustrate the Jolie syntax with a simple example of the service printing
anything it receives. First we need to define the interface that other services will
use and list all available functions inside (as depicted in Figure 3).
6 Manuel Mazzara et al.

interface PrintInterface {
OneWay: print ( string )
}

Fig. 3. interface code

This interface declares the one-way function PrintInterface, meaning that

any service using this interface will be able to call or provide this function without
receiving or, correspondingly, providing the response. Then we define the printing
service itself, listing the service entry point’s name (PrintService), location,
protocol and interfaces it uses (see Figure 4). The behavior is described in the
main part of the service. The behavior is composed of the one function print,
printing the line it receives.

include ‘‘console.iol’’

include ‘‘printInterface.iol’’

outputPort PrintService {
Location: ‘‘socket://localhost:8000’’
Protocol: json
Interfaces: printInterface
}

main {
print( line ){
print@Console( line )()
}

Fig. 4. Server’s code

Finally, we define the client’s service, including the information needed for
calling the printing service and call to the printing function (print@PrintService)
 Microservices Science and Engineering 7

include ‘‘printInterface.iol’’

outputPort PrintService {
Location: ‘‘socket://localhost:8000’’
Protocol: json
Interfaces: printInterface
}

main {
print@PrintService(‘‘Hello, world!’’)
}

Fig. 5. Client’s code

After invoking both services, PrintService will print our “Hello, world!”
greetings.
Jolie is an open source project with an active community of developers. Our
team has been working on an extension of the type system [20] and the develop-
ment of static type checking with refinement types [24], as well as development
of the IDE [21]. One of the current projects relates to the augmenting of user
experience. We are trying to make the language easy to use, adding the inline
documentation, value scaffolding, autocompletion and other ergonomics improv-
ing features.
However, there are more ongoing projects aimed on ensuring Jolie type safety.
The approach is to implement the type checker from [25] follows the formal spec-
ification rules defined in [26]. The rules then are encoded on the Jolie interpreter
level and checked by means of Z3 SMT solver [27]. [28] follows a slightly different
approach, it is built on top of a proof assistant instead of a SMT solver, which
helps to ascertain the correctness of the specification. The type checker is written
as well-typed program by means of dependent types in Agda [29] programming
language.
From the architectural point of view, Jolie has the potential to lead to a
paradigm shift. Component-wise each building block is built as a microser-
vice [30] embedding business capabilities in isolation. Every microservice can
be reused, orchestrated, and aggregated with others [31]. This approach brings
simplicity in components management, reducing development and maintenance
costs, and supporting distributed deployments [32].

4 Applications in Smart Buildings

The ideal application scenario where scalability, minimality and cohesiveness

demonstrate their effectiveness is Smart Buildings. There are several different
devices on the market that have been used in the Internet of Things and smart
8 Manuel Mazzara et al.

buildings-related projects. None of these projects, however, was so far developed

using the Jolie programming language.
Our team at Innopolis has developed an infrastructure of sensors in the Uni-
versity building [33, 34]. This solution allows to monitor an equipped area and
therefore collect data that can be mined and analyzed for specific purposes. The
system is taking advantage of the Jolie programming language to coordinate
nodes and user interface. The nodes used in this system consist of Raspberry Pi
micro-computers [35], Texas Instruments Sensor Tags [36], door sensor and a web
camera. Currently, this system is able to collect and analyze room temperature,
pressure and illumination level. It is also able to distinguish and count people,
which are located in the covered area. Figure 6 shows the general project infras-
tructure where each sensor has a related service to transmit data, the Raspberry
Pi micro-computer is running services responsible to receive and transmit data
to the server, and the server presents the data.
The future plan is to design and realize an automatic Personal Assistant
which is capable to observe the data, learn about different users preferences, and
adapt the room conditions accordingly for the different phases of his/her work.
To develop this, it will be necessary to operate speech and visual recognition via
machine learning, and connect these functionalities to the existing system.

Fig. 6. Sensors infrastructure architecture

5 Conclusions

There is no free lunch someone said. Indeed, a Microservice architecture is, in

general, more complex than one based on monolith. This is the cost of growing
and scaling easily. Despite of this, companies of considerable size are migrating
their mission critical systems (of considerable size) into the new architectural
style demonstrating an early understanding of how critical scalability is, and
how costs would differently grow later [3].
In this paper, we presented the basic principles of Service Science and Engi-
neering (SSE), with the applications developed by our research team. We also
supported the idea that a language-based approach seems the best choice to cope
with microservice development. Summarizing, the following are the significant
advantages of microservices: (1) Smaller code base therefore simpler to develop,
 Microservices Science and Engineering 9

test, deploy, scale (2) easier for new developers and it allows fast start (3) Poly-
glot architecture (each service may use individual technology) (4) Evolutionary
design (remove, add, replace services).
We are actively collaborating with both the scientific world (to develop solid
theories and methodologies in order to improve software quality) and with com-
panies interested to migrate their systems. The next decade will see a growing
attention to the SSE field, and the development of further programming lan-
guages intended to address the paradigm. Changes to scene should be expected,
and these may be comparable to what Object-Oriented programming brought
in the last two decades of the previous century.

References
1. N. Dragoni, S. Giallorenzo, A. Lluch-Lafuente, M. Mazzara, F. Montesi,
R. Mustafin, and L. Safina, “Microservices: yesterday, today, and tomorrow,” in
Present and Ulterior Software Engineering, Springer, 2017.
2. N. Dragoni, I. Lanese, S. T. Larsen, M. Mazzara, R. Mustafin, and L. Safina,
“Microservices: How to make your application scale,” in A.P. Ershov Informatics
Conference (the PSI Conference Series, 11th edition), Springer, 2017.
3. N. Dragoni, S. Dustdar, S. T. Larsen, and M. Mazzara, “Microservices: Migration
of a mission critical system,” https://arxiv.org/abs/1704.04173.
4. M. MacKenzie et al., “Reference model for service oriented architecture 1.0,” OA-
SIS Standard, vol. 12, 2006.
5. Sillitti A., Vernazza T., and Succi G., “Service oriented programming: a new
paradigm of software reuse,” in 7th International Conference on Software Reuse,
Lecture Notes in Computer Science 2319, pp. 269–280, Springer Berlin Heidelberg,
2002.
6. R. Lucchi and M. Mazzara, “A pi-calculus based semantics for WS-BPEL,” J. Log.
Algebr. Program., vol. 70, no. 1, pp. 96–118, 2007.
7. Predonzani P., Sillitti A., and Vernazza T., “Components and data-flow applied
to the integration of web services,” in The 27th Annual Conference of the IEEE
Industrial Electronics Society (IECON01), 2001.
8. Clark J., Clarke C., De Panfilis S., De Panfilis S., Sillitti A., Succi G., and Vernazza
T., “Selecting components in large COTS repositories,” Journal of Systems and
Software, pp. 323 – 331, 2004.
9. Gross H.G., Melideo M., and Sillitti A., “Self certification and trust in component
procurement,” Journal of Science of Computer Programming, pp. 141 – 156, 2005.
10. M. Mazzara and S. Govoni, A Case Study of Web Services Orchestration, pp. 1–16.
Springer Berlin Heidelberg, 2005.
11. Damiani E., El Ioini N., Sillitti A., and Succi G., “WS-certificate,” in 2009 IEEE
International Workshop on Web Services Security Management, IEEE, 2009.
12. M. E. Conway, “How do committees invent,” Datamation, vol. 14, no. 4, pp. 28–31,
1968.
13. J. Gray, “A conversation with werner vogels,” ACM Queue, vol. 4, no. 4, pp. 14–22,
2006.
14. M. Fowler and J. Lewis, “Microservices,” ThoughtWorks. http://martinfowler.
com/articles/microservices. html [last accessed on February 17, 2015], 2014.
15. S. Jones, “Microservices is soa, for those who know what soa is.” http://service-
architecture.blogspot.co.uk/2014/03/microservices-is-soa-for-those-who-
know.html, 2014.
 10 Manuel Mazzara et al.

16. Z. Yan, M. Mazzara, E. Cimpian, and A. Urbanec, “Business process modeling:

Classifications and perspectives,” in Business Process and Services Computing: 1st
International Working Conference on Business Process and Services Computing,
BPSC 2007, September 25-26, 2007, Leipzig, Germany., p. 222, 2007.
17. S. Newman, Building microservices. O’Reilly Media, Inc., 2015.
18. F. Montesi, C. Guidi, and G. Zavattaro, “Service-Oriented Programming with
Jolie,” in Web Services Foundations, pp. 81–107, Springer, 2014.
19. C. Guidi, I. Lanese, M. Mazzara, and F. Montesi, “Microservices: a language-based
approach,” in Present and Ulterior Software Engineering, Springer, 2017.
20. L. Safina, M. Mazzara, F. Montesi, and V. Rivera, “Data-driven workflows for
microservices (genericity in jolie),” in Proc. of The 30th IEEE International Con-
ference on Advanced Information Networking and Applications (AINA), 2016.
21. A. Bandura, N. Kurilenko, M. Mazzara, V. Rivera, L. Safina, and A. Tchitchigin,
“Jolie community on the rise,” in SOCA, pp. 40–43, IEEE Computer Society, 2016.
22. “EU Project SENSORIA. Accessed April 2016.” http://www.sensoria-ist.eu/.
23. M. Mazzara, F. Abouzaid, N. Dragoni, and A. Bhattacharyya, “Toward design,
modelling and analysis of dynamic workflow reconfigurations - A process algebra
perspective,” in Web Services and Formal Methods - 8th International Workshop,
WS-FM, pp. 64–78, 2011.
24. A. Tchitchigin, L. Safina, M. Mazzara, M. Elwakil, F. Montesi, and V. Rivera,
“Refinement types in jolie,” in Spring/Summer Young Researchers Colloquium on
Software Engineering, SYRCoSE, 2016.
25. B. Mingela, N. Troshkov, M. Mazzara, L. Safina, and A. Tchitchigin, “Towards
static type-checking for jolie,” https://arxiv.org/pdf/1702.07146.pdf.
26. J. M. Nielsen, “A Type System for the Jolie Language,” Master’s thesis, Technical
University of Denmark, 2013.
27. L. de Moura and N. Bjrner, “Z3: An efficient smt solver,” in Tools and Algo-
rithms for the Construction and Analysis of Systems, 14th International Confer-
ence, TACAS 2008, Held as Part of the Joint European Conferences on Theory
and Practice of Software, ETAPS 2008, Budapest, Hungary, March 29-April 6,
2008. Proceedings, vol. 4963 of Lecture Notes in Computer Science, pp. 337–340,
Springer, 2008.
28. E. Akentev, A. Tchitchigin, L. Safina, and M. Mazzara, “Verified type-checker for
jolie,” https://arxiv.org/pdf/1703.05186.pdf.
29. C. U. of Technology. Accessed December 2016., “Agda.” http://wiki.portal.
chalmers.se/agda/pmwiki.php.
30. F. Montesi, “Process-aware web programming with Jolie,” Sci. Comput. Program.,
vol. 130, pp. 69–96, 2016.
31. F. Montesi, “JOLIE: a Service-oriented Programming Language,” Master’s thesis,
University of Bologna, 2010.
32. M. Fowler, “Microservice Trade-Offs.” http://martinfowler.com/articles/
microservice-trade-offs.html, (2015).
33. D. Salikhov, K. Khanda, K. Gusmanov, M. Mazzara, and N. Mavridis, “Jolie good
buildings: Internet of things for smart building infrastructure supporting concur-
rent apps utilizing distributed microservices,” in CCIT, pp. 48–53, 2016.
34. D. Salikhov, K. Khanda, K. Gusmanov, M. Mazzara, and N. Mavridis,
“Microservice-based iot for smart buildings,” in WAINA, 2017.
35. “Raspberri pi official site.” https://www.raspberrypi.org/, Last accessed June
2017.
36. “Texas instruments sensor tag official site.” http://www.ti.com/ww/en/wireless_
connectivity/sensortag/gettingStarted.html, Last accessed June 2017.

View publication stats