=Paper=
{{Paper
|id=Vol-2405/05_paper
|storemode=property
|title=A Microservice Reference Case Study for Design-Runtime Interaction in MDE
|pdfUrl=https://ceur-ws.org/Vol-2405/06_paper.pdf
|volume=Vol-2405
|authors=Daniele Di Pompeo,Michele Tucci,Alessandro Celi,Romina Eramo
|dblpUrl=https://dblp.org/rec/conf/staf/Pompeo0CE19
}}
==A Microservice Reference Case Study for Design-Runtime Interaction in MDE==
https://ceur-ws.org/Vol-2405/06_paper.pdf
A Microservice Reference Case Study for
Design-Runtime Interaction in MDE?
Daniele Di Pompeo, Michele Tucci, Alessandro Celi, and Romina Eramo
Department of Information Engineering, Computer Science and Mathematics,
University of L'Aquila, Italy
{firstname.lastname}@univaq.it
Abstract. Model-Driven Engineering techniques may achieve major sup-
port to the software development of nowadays complex systems when
they allow managing relationships between a running system and its de-
sign models. These relationships can be exploited for dierent goals, such
as the software evolution due to new functional requirements. In order to
address this challenge, researchers need to better understand the nature
of the available runtime information and related correspondences as well
as how leveraging such knowledge. Typically, to this end, they rely on
reference applications.
In this paper, we present a reference case study for design-runtime inter-
action in MDE. It is based on Train Ticket, a microservice-based web ap-
plication, and its monitoring infrastructure. Also, the case study provides
its software modeling artifacts designed in UML, a dataset of monitoring
logs, and the de nition of design-runtime correspondence as traceability
links. We invite researchers to consider this case study as a reference for
extending or new contribution to this topic.
Keywords: MDE · Design-runtime interaction · Microservice architec-
ture
1 Introduction
Software is the foundation of today's life, managing everything from mobile/web
applications to airplanes in ight, but ensuring increasingly complex and error-
free systems has become a challenging task. While practitioners are forced to
use and investigate dierent development techniques to tackle advances in pro-
ductivity and quality, software engineering has to rely on automated approaches
to keep low the development costs while tackling the rapid changes of software
capabilities that expose dierent (non-)functional properties.
In order to manage software complexity, ever more companies are considering
Model-Driven Engineering (MDE) [15] approaches, with the perceived bene t
of enabling developers to work at a higher level of abstraction and to rely on
automation throughout the development process. Nevertheless, MDE solutions
?
This research was supported by the ECSEL-JU through the MegaM@Rt2 project
(grant agreement No 737494).
Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
24 Di Pompeo et al.
need to be further developed to scale up for real-life industrial projects [8]. To
this intent, one of the major challenges is to work on achieving a more e cient
integration between the design and runtime aspects of systems. For instance,
through observation and instrumentation, logs and metrics can be collected and
related to the original software design in order to comprehend, extrapolate and
analyze the inner behavior of running software system [10].
In support of this, a recent European project1 has been founded and sup-
ported by both industry and academic partners. As part of its continuous system
engineering approach [3], the project notably aims at providing a runtime-design
time feedback loop that could be deployed and used in dierent industrial do-
mains. Such a feedback from runtime to architectural design level can certainly
be exploited to let the developers have some sort of control and manipulation
possibilities over elements they would not be able to access otherwise.
Methods and tools have been proposed for monitoring system execution and
measuring several aspects of the running systems (eg., performance). However,
many of them do not envisage a solid integration with architectural design mod-
els [8]. In order to address this challenge, researchers need to better understand
the nature of the available runtime information and related correspondences
as well as how leveraging such knowledge. Typically, to this end, they rely on
reference applications.
In this paper, we present a reference case study for design-runtime interaction
in MDE. It is based on Train Ticket, a microservice-based web application,
and its monitoring infrastructure. Also, the case study provides its software
modeling artifacts designed in the UML language [2], a dataset of monitoring
logs, and the de nition of design-runtime correspondence as traceability links.
We invite researchers to consider this case study as a reference for extending or
new contribution to this topic.
2 The Train Ticket application
Recently, microservice architectures have become more relevant in the software
engineering community due to their production exibility. Among the few com-
plex approaches available within the software engineering community, Xiang et
al. [17] presented a benchmark that involves the Train Ticket system. Train
Ticket is a microservice web-based application composed by 40 microservices,
each one with a speci c aim, developed with dierent programming languages,
such as Java and Go. The application is composed of several scenarios (e.g.,
users can search speci c destinations or can book a train ticket) and supports
dierent kind of users with dierent kind of permissions (e.g., a guest user, or
an admin one).
Figure 1 shows the Train Ticket logical architecture. Each rectangle repre-
sents a microservice, whereas the topmost and the leftmost boxes depict in-
frastructural microservices, such as Service Discovery. In particular, Gateway is
in charge of catching an HTTP request and sending the message to the right
1
MegaM@Rt2 project: https://megamart2-ecsel.eu/
A Microservice Case Study for Design-Runtime Interaction in MDE 25
microservice, Service Discovery and Registry are in charge of managing mi-
croservices, whereas the Load Balance microservice is in charge of distributing
the tra c by following pre-de ned rules, e.g., round robin.
Fig. 1. Train Ticket architecture.
The Java-based part of the application were developed through the spring-
cloud framework 2 that provides the needed features. Additionally, a distributed
tracing system is used to collect real time information, for instance Xiang et
al. used Spring Cloud Sleuth 3 distributed tracing solution, which is the o cial
tracer within spring framework. In this work, we used Zipkin 4 and Elastic-
search 5 in our environment. Zipkin shows a graphical time-based representation
of traces, whereas elastic search is a clustered database.
In the rest of the paper, we consider the Train Ticket design models and the
trace/log artifacts to produce a reference case study for design-runtime interac-
tions 6 .
3 Train Ticket Design Modeling
The Train Ticket architecture and software design have been obtained by means
of a both manual and automatic reverse engineering from the source code. It
is modeled by means of UML; in particular, the multi-views UML modeling
is composed of the static views (i.e., Component and Class diagrams) and the
dynamic views (i.e., Sequence and State Machine Diagrams).
2
Spring Cloud: https://spring.io/projects/spring-cloud
3
Spring Cloud Sleuth: https://spring.io/projects/spring-cloud-sleuth
4
Zipkin: https://zipkin.io/
5
Elasticsearch: https://www.elastic.co/
6
Please, refer to the following repository for the complete resources:
https://github.com/SEALABQualityGroup/train-ticket
26 Di Pompeo et al.
Altough in this case study the design models were reverse engineered from the
source code, the same approach can be applied to models created at design-time,
with the assumption that the implementation exactly follows the design.
In order to design the Train Ticket microservice architecture, we map each
microservice into a UML Component. Figure 2 depicts a simpli ed version of the
Component Diagram; in particular, we refer to the components that are involved
in the Rebook ticket scenario (it allows to modify a ticket booking). As said,
each UML Component describes a microservice, thus component's name maps
one-to-one with the name of the microservice. Additionally, for each Component
the operation discovered by the tracing analysis have been reported. We have
also highlighted relations among microservices by means of UML Usage relations,
i.e., the dashed arrows labelled with use.
Fig. 2. Simpli ed Component Diagram of Train Ticket
A sample of the dynamic view of the application is depicted in Figures 3
and 4. In particular, Figure 3 shows a fragment of the Sequence Diagram of the
Rebook ticket scenario, whereas Figure 4 shows a State Machine Diagram of the
Travel Service microservice. In fact, each state machine represents the internal
behavior of a component, thus the aforementioned state machine represents the
internal behavior of the Travel Service microservice to accomplish the Rebook
ticket request. Each state represents the invoked method, the arrows represent
the event that have been triggered, while the Stand by state has been added to
represent the microservice waiting state.
4 Runtime Information Mining
The monitoring infrastructure mentioned in Section 2 generates and collects
runtime information in the form of traces, following the OpenTracing speci ca-
tion [1]. A trace consists of a series of casually related events that are triggered by
a request as it moves through a distributed system. These events are called spans
and they represent a timed operation occurring in a component. Spans contain
references to other spans, which allow a trace to be assembled as a complete
work ow.
A Microservice Case Study for Design-Runtime Interaction in MDE 27
According to the OpenTracing speci cation, a span always contains a set
of basic information: the name of the operation, the name of the component
providing the operation, the start timestamp and duration (or, alternatively, the
nish timestamp), the role of the span in the request and a set of user-de ned
annotations called tags. In the case study we are considering, spans also contain
additional information such as: the IP address and port number of the service,
the Java class and method implementing the operation as well as the unique
identi er of the Spring Cloud instance. Figure 5 reports an example of a raw log
containing spans that are generated by the Train Ticket application and stored
in the Elasticsearch database.
Fig. 3. A fragment of Sequence Diagram of the Rebook Ticket scenario
Fig. 4. State Machine Diagram of Travel Service microservice
4.1 Logs interpretation
Depending on the intended use, it may be necessary to analyze runtime informa-
tion to compute complex metrics that the designer may want to link to design
28 Di Pompeo et al.
models. For instance, when considering the duration of a span as the response
time of an operation, it may be required to calculate the average response time
in a time interval. Other examples of performance metrics may be the average
response time of traces corresponding to a speci c scenario or the number of
times an operation is invoked in a time interval. In the eld of dependability as-
sessment, the designer may want to link errors and components in design models
to establish their reliability and understand error propagation in the distributed
system. To this extent, it is possible to include the HTTP status code of each
request as a tag in the spans. Status codes corresponding to speci c errors can
be aggregated by error type or by time interval, obtaining, in this way, a metric
that can be related to system components.
Fig. 5. A fragment of the raw log in Elasticsearch
Fig. 6. A sample of Log Model
The detection of changes in the considered metrics may represent another
use case for log analysis. Non-functional metrics, such as the ones previously
described, may change over time due to a variety of reasons, including system
A Microservice Case Study for Design-Runtime Interaction in MDE 29
evolution and changes in deployment con gurations. As an example, the detec-
tion of deviations from the average response time of a scenario can guide the
designer in localizing the components that may have caused the deviation. In
this respect, being able to link metrics to design elements may represent a pivotal
asset to maintain and evolve complex distributed systems.
4.2 Logs representation
In order to obtain a model-based representation of the previously described raw
logs, we used a speci c metamodel [4] that allows to specify Log models. A Log
is characterized by a set of Traces representing the requests the system served
during the monitoring period. Each Trace consists of a set of Spans representing
execution events. A Span is de ned by the following attributes: a timestamp at
which the execution started, its duration in microseconds, and kind specifying
the role of the call in the scenario (SERVER, CLIENT, or unde ned for internal
calls). Each Span has a reference to a Service, that is the component providing
the operation, and a reference to the mapped EndPoint. Figure 6 shows a sample
of a Log Model obtained from the raw log in Figure 5.
Log Models conforming to the Log Metamodel are automatically generated
by means of a Java transformation. Such transformation queries Elasticsearch to
access raw logs in text format and subsequently transforms them in XMI-encoded
EMF 7 models.
5 Design-Runtime Interactions via Traceability Links
In the previous section, we showed how it is possible to obtain runtime log
models in a suitable format. These models can now be used along with the UML
model to de ne design-runtime interactions. While dierent approaches exist to
specify and implement such interactions, we propose a solution based on the
JTL (Janus Transformation Language) framework [9]. It is an Eclipse EMF-
based framework designed to mantain consistency between software artefacts.,
furthermore its traceability engine [12] allows to specify correspondences between
elements that are de ned at metamodel level as a set of relations between two
domains.
1 transformation Log2UML ( log : Log , uml : UML ) {
2 ...
3 top relation Trace2UseCase {
4 checkonly domain log t : Log :: Trace { spans = s: Log :: Span {} };
5 checkonly domain uml uc : UML :: UseCase {
6 ownedBehavior = ob : UML :: Interaction { message = m: UML :: Message {} }
7 };
8 where { Span2Message (s , m ); }
9 }
10 relation Span2Message {
11 checkonly domain log s : Log :: Span { endpoint = ep : Log :: EndPoint {} };
12 checkonly domain uml m : UML :: Message { signature = s: UML :: Operation {} };
13 where { EndPoint2operation ( ep , s ); }
14 }
15 relation EndPoint2Operation {
7
Eclipse Modeling Framework: https://www.eclipse.org/modeling/emf/
30 Di Pompeo et al.
16 n : String ;
17 checkonly domain log ep : Log :: EndPoint { name = n };
18 checkonly domain uml s : UML :: Operation { name = n };
19 }
20 top relation Service2Component {
21 n : String ;
22 checkonly domain log s : Log :: Service { name = n };
23 checkonly domain uml c : UML :: Component { name = n };
24 checkonly domain uml l : UML :: Lifeline { name = n };
25 }
26 ...
27 }
Listing 1. Log2UML correspondences speci cation
For instance, Listing 1 reports an excerpt of the correspondences between
Log and UML metamodels in the JTL syntax.; in detail:
- the top relation Trace2UseCase (Lines 3-9) creates a correspondence between
a trace and a scenario by relating Trace elements in the Log domain and
UseCase elements in the UML domain.
- the Span2Message relation (Lines 10-14) maps a Span element to the cor-
responding UML Message by relating variables ep and s of type EndPoint
and Operation, respectively.
- the EndPoint2Operation relation (Lines 15-19) creates a correspondence be-
tween an EndPoint of a Span and the UML Operation matching the same
name;
- the top relation Service2Component (Lines 20-25) maps a Service element
in Log to both the UML Component and Lifeline with the same name.
Fig. 7. Traceability model between the Train Ticker Log and UML model
The JTL traceability engine is able to produce a design-runtime traceability
model by executing the correspondences speci cation in Listing 1. The resulting
traceability model is conform to the Traceability Metamodel presented in [12].
Figure 7 shows a fragment of the traceability model (in the middle) connecting a
Train Ticket Log model (left-hand side) and the UML model (right-hand side).
A dataset containing logs and traceability models obtained from extensive mon-
itoring is publicly available 8 . Links among elements on both sides are depicted
as arrows in the gure and implemented as EMF inter-model references.
8
https://github.com/SEALABQualityGroup/traceability-datasets
A Microservice Case Study for Design-Runtime Interaction in MDE 31
6 Related Work
Achieving an e cient integration between the design and runtime aspects of com-
plex systems proved to be an interesting challenge for MDE methods and tools,
as advocated during the rst edition of the Model-Driven Engineering for Design-
Runtime Interaction in Complex Systems (MDE@DeRun 2018) workshop [8]. In
this context, we identify such lack of existing approaches that explicitly exploit
design-runtime interaction with the aim at improving software design.
As mentioned in Section 1, the European project MegaM@Rt2 aims at pro-
viding a runtime-design time feedback loop in the development of complex sys-
tems. Within the project, we presented the following contributions on this topic.
In [4] design-runtime relationships have been de ned and used to support the
performance improvement of a running system; the approach has been applied
to an e-commerce web application designed by means of UML software mod-
els pro led with MARTE. In [11] the authors present a model-based approach
that analyzes runtime data and automatically infers potential design issues that
might need to be xed in order to solve detected system malfunctioning. The
approach is applied in the context of a real railway industrial system.
With the aim to extend the applicability of software models produced in MDE
approaches to the runtime environment, the modeling community proposed the
use of models at runtime (known as Models@run.time) [7, 6] . Such models should
represent the system and its current/updated state and behavior to support
adaptive systems, e.g., to drive subsequent adaptation decisions, to x design
errors or to explore new design decisions.
In the software engineering community, other approaches have introduced
reference case studies with speci c aims, e.g., for performance analysis [16]. Von
Kistowsk et al. [16] have presented a micro-service reference application for per-
formance benchmarking, and modelling. In particular, Teastore is a Java mi-
croservice oriented application and the authors exploit the Palladio Component
Model (PCM) [5] as modelling formalism; thus they can apply dierent non-
functional analyses by exploiting runtime data information. Herold et al. [13]
have presented a UML reference model for a bank system. They have produced
dierent diagrams, such as a Component Diagram, Sequence Diagrams for dif-
ferent scenarios as Larman described in [14]. Similarly to the above mentioned
works, we provided the modeling of a given application. While they focused on
performance analysis scope, we reversed the software architecture by exploit-
ing runtime traces (i.e., log) and we de ned traceability links between design
elements and runtime data.
7 Conclusion
In this paper, we present a reference case study for design-runtime interaction
in MDE. We presented the Train Ticket microservice-based web application and
its monitoring infrastructure. The proposed case study is composed of a set of
software modeling artifacts designed in UML, a dataset of monitoring logs, and a
set of design-runtime correspondence de ned as traceability links. The complete
32 Di Pompeo et al.
resources of the case study have been made available with the scope to provide
a reference case both for a better understanding of the related challenges and
for extending or new contribution to this topic.
References
1. The OpenTracing project, https://opentracing.io/
2. Uni ed modeling language. OMG (2015), http://www.omg.org/spec/UML/2.5/,
version 2.5
3. Afzal, W., Brunelière, H., Di Ruscio, D., Sadovykh, A., Mazzini, S., Cariou, E.,
Truscan, D., Cabot, J., Gómez, A., Gorroñogoitia, J., Pomante, L., Smrz, P.: The
megam@rt2 ECSEL project: Megamodelling at runtime - scalable model-based
framework for continuous development and runtime validation of complex systems.
MICPRO 61, 8695 (2018)
4. Arcelli, D., Cortellessa, V., Di Pompeo, D., Eramo, R., Tucci, M.: Exploiting archi-
tecture/runtime model-driven traceability for performance improvement. In: ICSA.
pp. 8190 (2019)
5. Becker, S., Koziolek, H., Reussner, R.H.: The Palladio component model for model-
driven performance prediction. Systems and Software 82(1), 322 (Jan 2009)
6. Bencomo, N., Götz, S., Song, H.: Models@run.time: a guided tour of the state of
the art and research challenges. Software & Systems Modeling (2019)
7. Blair, G., Bencomo, N., France, R.B.: Models@run.time. Computer 42(10), 2227
(2009)
8. Bruneliere, H., Eramo, R., Gomez, A., Besnard, V., Bruel, J.M., Gogolla, M.,
Kastner, A., Rutle, A.: Model-Driven Engineering for Design-Runtime Interac-
tion in Complex Systems: Scienti c Challenges and Roadmap - Report on the
MDE@DeRun 2018 workshop. In: Proc. of STAF Collocated Workshops (2018)
9. Cicchetti, A., Di Ruscio, D., Eramo, R., Pierantonio, A.: JTL: A bidirectional and
change propagating transformation language. In: SLE Proc. pp. 183202 (2010)
10. Cito, J., Leitner, P., Bosshard, C., Knecht, M., Mazlami, G., Gall, H.C.: Perfor-
manceHat: augmenting source code with runtime performance traces in the IDE.
In: Proc. of ICSE Companion. pp. 4144 (2018)
11. Eramo, R., Marchand de Kerchove, F., Colange, M., Tucci, M., Ouy, J., Brune-
liere, H., Di Ruscio, D.: Model-driven design-runtime interaction in safety critical
systemdevelopment: an experience report. In: (ECMFA) (2019), to appear
12. Eramo, R., Pierantonio, A., Tucci, M.: Improved traceability for bidirectional
model transformations. In: MDETools, MODELS. vol. 2245, pp. 306315 (2018)
13. Herold, S., Klus, H., Welsch, Y., Deiters, C., Rausch, A., Reussner, R., Krogmann,
K., Koziolek, H., Mirandola, R., Hummel, B., Meisinger, M., Pfaller, C.: CoCoME
- The Common Component Modeling Example, pp. 1653 (2008)
14. Larman, C.: Applying UML and patterns: an introduction to object oriented anal-
ysis and design and interative development. Pearson Education India (2012)
15. Schmidt, D.C.: Model-driven engineering. IEEE Computer 39(2), 2531 (2006)
16. von Kistowski, J., Eismann, S., Schmitt, N., Bauer, A., Grohmann, J., Kounev, S.:
Teastore: A micro-service reference application for benchmarking, modeling and
resource management research. In: (MASCOTS). pp. 223236 (Sep 2018)
17. Zhou, X., Peng, X., Xie, T., Sun, J., Xu, C., Ji, C., Zhao, W.: Benchmarking
microservice systems for software engineering research. In: ICSE Companion Pro-
ceedings. pp. 323324 (2018)