=Paper=
{{Paper
|id=Vol-2716/paper8
|storemode=property
|title=Characterization of Bottom-up Microservice Composition Evolution. An Approach Based on the Choreography of BPMN Fragments
|pdfUrl=https://ceur-ws.org/Vol-2716/paper8.pdf
|volume=Vol-2716
|authors=Jesús Ortiz,Victoria Torres,Pedro Valderas
|dblpUrl=https://dblp.org/rec/conf/er/OrtizTV20
}}
==Characterization of Bottom-up Microservice Composition Evolution. An Approach Based on the Choreography of BPMN Fragments==
https://ceur-ws.org/Vol-2716/paper8.pdf
Judith Michael, Victoria Torres (eds.): ER Forum, Demo and Posters 2020 101
Characterization of Bottom-up Microservice Composi-
tion Evolution. An Approach Based on the Choreography
of BPMN Fragments
Jesús Ortiz, Victoria Torres and Pedro Valderas
PROS Research Centre,
Universitat Politècnica de València, Spain
{jortiz, vtorres, pvalderas}@pros.upv.es
Abstract. Microservices need to be composed in order to provide their customers
with valuable services. To do so, event-based choreographies are used many
times since they help to maintain a lower coupling among microservices. How-
ever, this solution rises the composition complexity since the control flow is dis-
tributed across microservices and it is difficult to analyze and understand the big
picture of it. To improve this problem, a previous work presented an approach
that proposed creating the big picture of a composition in a BPMN model, split-
ting it into BPMN fragments, and distributing these fragments among micro-
services. A tool-supported architecture was also proposed to achieve that both
descriptions of a composition (the big picture and the split one) coexist in a sys-
tem. In the current work, we present a first step to face the problem of evolving
microservice compositions that are created and deployed with our approach. To
do so, we need to consider that we can evolve a microservice composition from
(1) its big picture (top-down approach) and (2) a particular BPMN fragment (bot-
tom-up approach). We pay special attention to the bottom-up approach and pre-
sent a characterization of the changes that can be done, analyze the impact that
each of them has on the global composition, and propose compensation actions
that maintain the integrity of the composition when possible.
Keywords: Microservices · Composition · Evolution · Bottom-Up
1 Introduction
Microservices [1] propose the decomposition of applications into small independent
building blocks. Each of these blocks (the microservices) focuses on a single business
capability. Microservices communicate to each other with lightweight mechanism and
can be deployed and evolved independently, which leads to more agile developments
and technological independence between them [2].
The fact of breaking down a system into microservices forces developer teams to
build microservice compositions in order to provide their customers with valuable ser-
vices [3]. With the aim of maintaining a lower coupling among microservices, these
compositions are many times implemented by means of event-based choreographies.
In these choreographies, microservices act autonomously based on the occurrence of
events that are observed in the environment. When a microservice has done its work, it
Copyright © 2020 for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
102 J. Ortiz, V. Torres and P. Valderas
triggers an event that another microservice is waiting for in order to execute its corre-
sponding tasks.
Although choreographies are encouraged to improve microservice decoupling, they
are usually hard-coded within each microservice and implicitly defined by the interac-
tion between microservices. This solution rises the composition complexity since the
control flow is distributed across microservices. Thus, if engineering decisions need to
be taken (e.g. change the microservice composition to support a new requirement), it is
difficult to analyse and understand the big picture of the composition’s flow. In [4] we
faced this problem by proposing a microservice composition approach based on the
choreography of BPMN fragments. This approach proposed a top-down strategy in or-
der to create a microservice composition: first, business process engineers created the
big picture of the microservice composition in a BPMN model; then, this model was
split into BPMN fragments which are distributed among the microservice that partici-
pate in the composition; finally, the microservice composition was executed through an
event-based choreography of BPMN fragments. A tool supported architecture was pro-
posed in order to achieve that the two versions of a composition (the big picture and the
split one) can coexist in a system. We obtained two main benefits: (1) the creation of
the big picture of a microservice composition in a BPMN model facilitated further anal-
ysis to take engineering decision; and (2) the execution of this model through an event-
based choreography of BPMN fragments provided a high degree of decoupling and
independence among microservices.
In this work, we present a first step to face the challenge of evolving microservice
compositions that have been created and deployed by our previous approach. To do so,
we need to consider that we have two options to evolve a microservice composition:
(1) a top-down approach, which implies the realization of global changes to modify the
big picture and the propagation of the changes to the fragments of the underlying mi-
croservices; and (2) a bottom-up approach which implies the realization of local
changes in the BPMN fragments of specific microservices, the integration of these
changes with the big picture, and the coordination with the rest of microservices. In
particular, we pay special attention to the bottom-up approach and characterize the
changes that can occur from the particular view of a microservice by charactering them,
analyzing the impact that each type has on the global composition, and proposing com-
pensation actions for each type of change to maintain the integrity of the composition
when possible. Our main goal is to use this characterization as a basis for the definition,
as further work, of a bottom-up evolution protocol for microservice architectures based
on our approach.
The rest of this paper is organized as follows: Section 2 analyzes the related work;
Section 3 introduces an overview of our approach to create microservices compositions
based on the choreography of BPMN fragments. Taking this approach as a basis, Sec-
tion 4 characterizes the evolution of microservices compositions paying special atten-
tion to the bottom-up strategy. And finally, conclusions and further work are com-
mented on in Section 5.
Characterization of Bottom-up Microservice Composition Evolution 103
2 Related work
The microservice research area is a field that it stills under development. It started as a
specification of systems based on service-oriented architectures (SOA). However, the
microservices-based architectures have specific approaches that differentiate them
from SOA, such as the creation of architectures composed of lightweight services, ap-
plications based on agile developments, DevOps methodology, automated infrastruc-
ture, decentralized data management and distributed governance.
In this paper, the changes that can take place on a choreography from a bottom-up
perspective are characterized. These changes are characterized to create a protocol that
will allow a choreographed microservices architecture to evolve from a bottom-up per-
spective. Research on choreographed microservices architectures focus on the design
and on the implementation of the architecture. Topics such as the maintenance of the
architecture, where its evolution is included, testing and requirements analysis are
poorly approached [3] [5] [6].
Most of the works that we found focus their efforts on developing an architecture
based on microservices, from a top-down or a bottom-up approach. Regarding the com-
position of microservices, there are some works that face this challenge. Some ap-
proaches propose their own language [7] [8] [9]. A minority of studies uses languages
already created such as UML [10], BPMN [11], BPEL [12], DIARy [13], Medley [14]
or Jolie [15]. Although they allow the creation of microservice compositions, little at-
tention is paid to their evolution. Our work faces this challenge by introducing an ap-
proach based on BPMN fragments that allows evolving a microservice composition by
following two strategies: top-down and bottom-up.
3 A composition microservice approach based on BPMN
fragments
In this section, we provide an overview of the approach presented in [4] to compose
microservices based on the choreography of BPMN fragments. The steps that this ap-
proach proposes to create a microservice composition are the following:
1. Define a BPMN model of the complete microservice composition.
2. Split this model into BPMN fragments that are distributed among microservices.
3. Deploy and execute BPMN fragments through an event-based choreography.
We are going to make use of the purchase order process shown in Figure 1 to illustrate
how this approach works. This figure presents the BPMN model describing the pur-
chase order in an online shop which is defined by the composition of three micro-
services (Customers, Inventory, and Payment). According to this model, the Customers
microservice checks the customer data and logs the request. If the customer data is not
valid then the order is cancelled. On the contrary, if customer data is valid the control
flow is transferred to the Inventory microservice. The Inventory microservice checks
the availability of the ordered items. If there is not enough stock to satisfy the order, the
process of the order is cancelled. On the contrary, the items are booked and the control
104 J. Ortiz, V. Torres and P. Valderas
flow of the process is transferred to the Payment microservice which processes the pay-
ment of the order. If the payment fails, the process of the order is cancelled and the
control flow is transferred to the Inventory microservice that releases the booked items.
If the payment succeeds, the control flow is transferred to the Inventory microservice
which updates the stock of the purchased items and pass the control flow to the Cus-
tomer microservice to update the customer record and finish the process of the order.
Step 1. The first step of our approach consists in the definition of a single BPMN
model describing the complete microservice composition. In particular, two types of
requirements need to be considered in these descriptions: business requirements, which
define the actions that each microservice must do in the context of a microservice com-
position; and coordination requirements, which define how microservices must com-
municate among them to achieve the goal of a composition.
To do so: (1) each microservices is represented by a BPMN pool, (2) the tasks of a
pool represent the actions that the corresponding microservice must do within the com-
position; and (3) to support decoupled communication among microservices at runtime
we consider some of the mechanisms proposed by BPMN to define an event-based
communication. These mechanisms are: catching and throwing intermediate/start/end
events as well as message flows to connect them. The composition presented in Figure
1 has been defined by using this approach.
Fig. 1. Step 1. Big picture of a microservice composition in BPMN
Step 2. Once the big picture of a microservice composition has been defined in a BPMN
model, we propose to split this model into several BPMN fragments and deploy them
into the corresponding microservices in such a way each fragment can be executed by
an independent microservice and in an event-based choreography. To do so, a model
transformation is applied in order to obtain a new BPMN model for each microservice
Characterization of Bottom-up Microservice Composition Evolution 105
that participates in the composition. As representative example, Figure 2 shows the
BPMN model obtained for the Customer microservice. This model includes the pool
that represents the Customers microservice in the big picture and a new collapsed pool
that represent an event bus which the microservice Customer sends messages to, and
receives messages from. The BPMN models created for the rest of the microservices
are analogous.
Fig. 2. Step 2. Split the big picture into BPMN fragments. Example of the Customers fragment
Step 3. Once the BPMN fragments of a microservice composition have been obtained,
each of them must be deployed into the microservice that is responsible for executing
it. Microservices just need to use a BPMN engine to execute the fragments. The most
important aspect to be considered is that an event-based choreography of BPMN frag-
ments can be achieved as it is illustrated in Figure 3.
Fig. 3. Step 3. Event-based choreography of BPMN fragments
Each microservice is in charge of executing its corresponding process fragment and
informing the others about it. Following with the running example, once the client
places an order in the online shop, the client application triggers the event “Process
Purchase Order” (1). The Customers microservice, which is listening to this event (de-
fined through the start event of its pool), reacts executing part of its associated BPMN
fragment and pauses its execution to trigger the event “Customer Checked” (2). Then,
106 J. Ortiz, V. Torres and P. Valderas
the Inventory microservice, which is listening to this event, executes its BPMN frag-
ment and generates the event that makes the Payment microservice to execute the next
process fragment (3) and (4). Afterwards, the Inventory microservice generates the
event “Stock update” (5), and the Customer microservice resumes its tasks and finishes
the composition by triggering the event “Order Processed” (6).
This composition approach is supported by a microservice infrastructure developed
to achieve that both descriptions of a composition (big picture and split one) coexist.
This infrastructure has been implemented1 by using Java/Spring technology and the
open source support provided by Netflix.
3.1 Evolution of microservice compositions
In order to evolve a microservice composition created with the above-presented ap-
proach we need to consider that we proposed a microservice architecture in which two
descriptions of a composition (the big picture and the split one) coexists. Thus, we have
two options to evolve a microservice composition: a top-down approach and a bottom-
up approach.
By following a top-down approach the microservice composition is evolved by busi-
ness process engineers from the BPMN model that represent the big picture. The com-
position is evolved from a global perspective, and the modifications introduced in the
big picture BPMN model are propagated to the corresponding BPMN fragments of each
microservice as introduced above. This evolution is supported by the tools that support
the above introduced composition approach.
By following a bottom-up approach the microservice composition evolves from the
BPMN fragment of an individual microservice. In this case, the composition is evolved
from the particular responsibilities of a specific microservice and additional synchroni-
zation efforts must be done in order to propagate these local changes to both the big
picture and the other microservices that participate in the composition. Note that allow-
ing local changes in a microservice composition reinforce the independence among de-
velopment teams that is demanded by this type of architecture. However, modifying a
microservice without considering how changes may affect the rest of microservices that
participate in the composition can produce coordination problems that make the com-
position fail. Next section analyzes this aspect in more detail.
4 Characterization of a bottom-up evolution of microservice
compositions
In this section, we characterize the changes that can occur in a bottom-up evolution of
a microservice composition, their impact on the global composition, and the compen-
sation actions required to maintain the integrity of the composition. Note that, as com-
mented above, the BPMN descriptions introduced in Section 3 allow us to capture the
following two types of requirements of a microservice composition:
1
https://github.com/pvalderas/microservices-composition-infrastructure
Characterization of Bottom-up Microservice Composition Evolution 107
Business requirements: These requirements define the actions that each micro-
service does in the context of a composition but independently from the rest of micro-
services. These requirements are represented by the BPMN tasks that are defined in the
fragment of each microservice. Changes in these requirements imply isolate changes in
the business responsibilities of the microservice(s). This means that microservice de-
velopers change the tasks defined in a BPMN fragment and maintain the BPMN ele-
ments that represent the coordination requirements.
To better understand the modifications that can be done in this case, Figure 4 shows
an example. The upper side of this figure shows the BPMN fragment of the Customers
microservice. All the elements that define coordination requirements and that are not
modified are displayed in grey. On the contrary, all the BPMN elements that define
business requirements are displayed in black. The bottom side of Figure 4 shows an
updated version of this BPMN fragment. This new version considers whether or not a
customer is a VIP one. In case it is not a VIP customer, some advertising is shown and
the possibility of registering as a VIP customer is offered.
Fig. 4. Example of local modifications of business requirements from a BPMN fragment
This type of change does not affect the participation of other microservices. Thus,
we just need to integrate the updated BPMN fragment into the big picture of the com-
position. To do so, this fragment must replace the corresponding pool in the big picture
BPMN model.
Coordination requirements: These requirements define how two or more micro-
services communicate among them to achieve the goal of the composition they partic-
ipate. These requirements are represented by the BPMN elements that define an event-
based communication, i.e. throwing and catching events as well as the message flows
that connect them.
108 J. Ortiz, V. Torres and P. Valderas
Changes in these requirements imply coordinated modifications in two or more mi-
croservices in such a way a correct communication is ensured. Next, we characterize
these changes by considering three type of actions:
1. Delete an event-based communication element from a BPMN Fragment.
2. Update an event-based communication element of a BPMN Fragment.
3. Create a new event-based communication element in a BPMN fragment.
Next, we classify and characterize these actions by analyzing the generated incon-
sistencies as well as the compensation actions that are required to correct these incon-
sistencies and guarantee a functional composition. This characterization constitutes a
first step in the creation of a protocol for the modification of microservice compositions.
Specifically, with this protocol we aim at managing local modifications in the context
of a choreographed global composition based on BPMN fragments. For this purpose,
we define different modification rules depending on the nature of the produced changes,
which are classified as:
(1) Automatic, when compensation actions to correct the inconsistencies gener-
ated by a modification action (delete, update or create of an event-based com-
munication element) can be created automatically since they have no impact
on the existing coordination or business requirements.
(2) Automatic with acceptance, when compensation actions can be built automat-
ically but the coordination among some microservices may change. In this
case compensation actions must be accepted by the affected microservices,
otherwise changes should be rollbacked in the modified microservice.
(3) Global modifications, when compensation actions imply important modifica-
tions in both coordination and business requirements. In this case, a further
analysis of the whole composition is needed, and local changes in the modified
microservice are marked as dirty until they are accepted or rejected from the
global perspective of the composition.
(4) Extension, when no compensation actions are required since microservice
modifications are conservative with the composition, not producing any in-
consistencies (i.e. coordination requirements are not changed but extended).
However, they introduce new coordination possibilities among microservices.
Note that the message events that support the communication among microservices
can be triggered either without data (they are just triggered to define the flow in which
microservices must perform their actions, see the running example) or with attached
data (in addition to define the flow of the microservice composition they include data
that a microservice need to perform some actions). In this paper, we consider only
events without data. The impact of modifying an event that is used to share data among
microservices will be considered in a further work.
4.1 Delete an event-based communication element
In this section, we characterize the actions of deleting an event-based communica-
tion element in a BPMN fragment. Two modifications are identified:
Characterization of Bottom-up Microservice Composition Evolution 109
#1 Delete a Message End Event or a Message Intermediate Throwing Event.
This change implies the removal of a BPMN element that sends an event to inform that
a specific path in its process has reach an end.
Generated inconsistency: Some microservices will never start since their execution
depend on the triggering of the event being just deleted.
Compensation actions: Modify the microservices that were waiting for the removed
event in order to wait for the event that triggered the modified microservice.
Example: An example of this modification is removing the BPMN Message Inter-
mediate Throwing Event “Customer Checked” of the BPMN Fragment of the Custom-
ers microservice (see Figure 2). If this event is removed, the microservice Inventory,
which is waiting for it, will never start and execute its tasks, and therefore, the micro-
service composition will never continue (see Figure 3). In order to allow the micro-
service Inventory to perform its tasks and maintain its participation in the composition
it can be modified to wait for the event that triggered the Customers microservice. Thus,
its Message Start Event must be modified to listen to the “Process Purchase Order”
event. This example is graphically represented in Figure 5.
Fig. 5. Example of local modifications of coordination requirements from a BPMN fragment
Impact of the modification and the compensation actions: Business requirements are
maintained since the tasks of the microservices are all performed. However, the flow
of the composition has changed. Two microservices that initially performed their tasks
in a sequential way (e.g. first Customers performed its tasks and later Inventory per-
formed its tasks) result in performing their tasks in a parallel way (e.g. after the modi-
fication, both Customers and Inventory microservices are executed when the “Process
Purchase Order” event is triggered).
Classification of change #1: Automatic with acceptance.
110 J. Ortiz, V. Torres and P. Valderas
#2 Delete a Message Start Event or a Message Intermediate Catching Event.
This change implies the removal of a BPMN element that defines the event that a mi-
croservice must listen to in order to execute some tasks.
Generated inconsistency: The modified microservice will no longer participate in
the microservice composition. As a consequence, the rest of microservice that were
waiting for the completion of the tasks of the modified microservice will not participate
in the composition either.
Compensation actions: There are no compensation actions that can be done to main-
tain the participation of the modified microservice. Regarding the rest of microservices,
those that were waiting for the events triggered by the modified microservice need to
be updated to listen to the event that triggered this microservice.
Example: An example of this modification is removing the BPMN Message Start
Event “Customer Checked” of the Inventory microservice (see Figure 1). If this micro-
service is no longer listening to this event, it will no longer participate in the composi-
tion. As a consequence, the event “Enough Items” will not be triggered and then, the
Payment microservice will not participate either. In order to maintain the participation
of the Payment microservice it must be modified to wait for the event that triggered the
Inventory microservice, i.e. “Customer Checked” (see Figure 3).
Impact of the modification and the compensation actions: business requirements are
changed. The tasks of a microservice are no longer performed in the composition.
Classification of change #2: Global modifications.
4.2 Update an event-based communication element
In this section, we characterize the actions of updating an event-based communication
element in a BPMN fragment. Two modifications are identified:
#3 Update a Message End Event or a Message Intermediate Throwing Event.
This change implies updating a BPMN element that sends an event to inform of the
ending of some tasks. In particular, updating this type of BPMN element implies up-
dating the event they trigger (e.g. changing the event name).
Generated inconsistency: We identify two scenarios:
(1) The modified microservice is updated to trigger a new event that does not
participate before in the context of the composition. Thus, the microservices
that was waiting for the old event will no longer participate in the composi-
tion.
(2) The modified microservice is updated to trigger an event that already partic-
ipate in the context of the composition. Thus, the microservices that was wait-
ing for the old event will no longer participate in the composition. In addition,
those microservices that were defined to catch the existing event may partic-
ipate in the composition more times than before.
Compensation actions: In both situations introduced above the microservices that
were waiting for the modified event must be updated in order to wait for the new version
of the event. There are no compensation actions to avoid the additional participations
of microservices that is produced in the second scenario.
Characterization of Bottom-up Microservice Composition Evolution 111
Example: An example of the first scenario is updating the BPMN Message End
Event “Payment Failed” defined in the Payment microservice (see Figure 1) in order
to trigger a new event called “Purchase Denied”. In this sense, the event “Payment
Failed” is no longer sent, and then, the microservice Inventory, which is waiting for it,
will never start, and the microservice composition will get stuck (see Figure 3). To
maintain the participation of the Inventory microservice in the composition, the Mes-
sage Intermediate Catching Event that is defined in its BPMN fragment to catch the
“Payment Failed” event must be modified to catch the new event “Purchased Denied”.
An example for the second scenario is updating the BPMN Message End Event
“Payment Failed” defined in the Payment microservice (see Figure 1) in order to trigger
the already existing event “Stock updated”. To maintain the participation of the Inven-
tory microservice in the composition the modification the microservice Inventory as
explained above can be done. However, the use of an existing event produces the mod-
ification of the coordination requirements creating a composition different from the
original one.
Impact of the modification and the compensation actions: In the first scenario, busi-
ness and coordination requirement are maintained. In the second, coordination require-
ments are changed, and business requirements may be affected from a global perspec-
tive since some microservices can be triggered more times than initially expected.
Classification of change #3: Scenario 1: Automatic. Scenario 2: Global modifica-
tions.
#4 Update a Message Start Event or a Message Intermediate Catching Event.
This change implies updating a BPMN element that defines the event that a micro-
service must listen to in order to execute some tasks. Updating this type of BPMN ele-
ment implies updating the event they are waiting for (e.g. changing the event name).
Generated inconsistency: We identify two scenarios:
(1) The modified microservice is updated to catch an event that is not triggered
in the context of the composition. Thus, the microservice will no longer par-
ticipate in the composition.
(2) The modified microservice is updated to catch another event that is already
triggered within the composition. Thus, the participation of the microservice
will continue but coordination requirements may change, and business re-
quirements may be also affected.
Compensation actions: Considering the above-introduced two scenarios:
(1) In the first scenario we identify two options:
i. If there are no other microservices listening to the event that the modified
microservice received, the microservice that sends the event can be mod-
ified to trigger the updated version.
ii. If there are other microservices listening to the modified event, no actions
can be made in the microservice that triggers the event, as they will affect
the participation of other microservices.
(2) There are no compensation actions to correct the second scenario.
Example: An example of the scenario 1.i is updating the BPMN Message Start Event
“Customer Checked” of the BPMN Fragment of the Inventory microservice (see Figure
112 J. Ortiz, V. Torres and P. Valderas
1). Instead of waiting for receiving the event “Customer Checked”, it will wait to re-
ceive the event “Check Inventory”. In this case, there are no other microservices listen-
ing to the event “Check Inventory”, so the microservice Customer can be modified to
trigger this event. If the event “Customer Checked” had been listened by more than one
microservices as it is described in scenario 1.ii the modification introduced above had
not able to be done. An example of the scenario 2 is updating the BPMN Message Start
Event “Customer Checked” of the Inventory microservice to wait for the event “Process
Purchase Order”. Consequently, the Customer and Inventory microservice will be exe-
cuted in parallel affecting to the coordination requirements.
Impact of the modification and the compensation actions: Considering the above-
introduced scenarios:
1.i Business and coordination requirements are all maintained.
1.ii As there are more microservices listening to the event that the modified micro-
service received, changes in the microservice that triggers the event cannot be done.
Thus, the modified microservice will no longer receive the event that triggers it and the
composition logic cannot be maintained.
2. Business requirements are all supported but coordination requirements change
which results in some alteration such as performing tasks in a parallel way (e.g. after
the modification in Scenario 2, both Customers and Inventory microservices perform
their tasks when the Process Purchase Order event is triggered).
Classification of change #4: Scenario 1.i: Automatic. Scenario 1.ii: Global modifi-
cations. Scenario 2: Automatic with acceptance.
4.3 Create an event-based communication element
In this section, we characterize the actions of creating an event-based communication
element in a BPMN fragment. Two modifications are identified:
#5 Create a Message End Event or a Message Intermediate Throwing Event.
This change implies the creation of a BPMN element that sends an event to inform of
the ending of some tasks.
Generated inconsistency: None. This modification introduces a new event into the
composition and adds the possibility of extending the composition.
Compensation actions: None.
Example: An example of this modification is creating a Message Intermediate
Throwing Event “Purchase Denied” in the BPMN Fragment of the Inventory micro-
service (see Figure 1). The new Intermediate Through Event will be inserted after the
“Release Product” task. This new event introduces the possibility of extending the com-
position. For instance, a Message Intermediate Catching Event can be added in the Cus-
tomer microservices to receive the new event “Purchase Denied”. This also involves
the creation of a Parallel Door in the Customer microservice to adapt the flow to the
events that the Customer microservices can receive. After this modification, the Cus-
tomer microservices can receive the “Purchase Denied” event or the “Stock Updated”
event and after receiving one of these events proceed with the following tasks. Option-
ally, new tasks can be added to the new branch created to offer new functionalities.
Characterization of Bottom-up Microservice Composition Evolution 113
Impact of the modification and the compensation actions: Business requirements can
be optionally changed. For instance, in the Customer microservice, new business re-
quirements can appear if they are added with a new branch after catching the new trig-
gered event. Coordination requirements can be also extended. For instance, before the
modification introduced above, the sequence of the composition was: Customer, Inven-
tory, Payment, Inventory and Customer ending with the sending of the “Order Pro-
cessed” event (see Figure 3). After the modification, there are two possible sequences,
the one mentioned before and a new one added: Customer, Inventory, Payment, Inven-
tory and Customer ending with new actions added to a newly created parallel branch.
Classification of change #5: Extension.
#6 Create a Message Start Event or a Message Intermediate Catching Event.
This change implies the creation of a BPMN element that defines the event that a mi-
croservice must listen to in order to execute some tasks.
Generated inconsistency: None. This modification does not affect to the composi-
tion, it extends a microservice with the possibility of receiving a new event.
Compensation actions: None.
Example: An example of this modification is creating the BPMN Message Interme-
diate Catching Event “Payment Failed” in the BPMN Fragment of the Customer mi-
croservice (see Figure 1). This modification introduces the possibility of extending
other microservices to trigger this event and then change coordination requirements.
For instance, the Inventory microservice can be extended with a new Message Interme-
diate Throwing Event “Purchase Denied” in the in order to trigger the new event that
can be cached by Customers.
Impact of the modification and the compensation actions: The impact of this change
is similar to the impact of the previous one. Business requirements can be optionally
changed. For instance, new business requirements can appear in the Customer micro-
service if they are added with a new branch after the new Message Intermediate Catch-
ing Event. Coordination requirements can also be extended if other microservices are
updated to trigger the new event.
Classification of change #6: Extension.
5 Conclusions and further work
In this work, we have presented an inception work aimed at the creation of a modifica-
tion protocol that allow us to manage local modifications within a microservice com-
position based on the choreography of BPMN fragments.
As a first step, we propose an initial characterization of the bottom-up modifications
that can be done in a microservice composition supported by our approach. Note that
this characterization needs to be improved in order to consider data interchange among
microservices. This improvement will be considered in the next stage of this research.
Regarding the modification protocol among microservices, we plan to investigate
how the two-phase commit protocol typically used in the management of distributed
database transactions can be applied in the context of a microservice composition. The
main idea is to create a protocol that, considering the characterization of modifications
114 J. Ortiz, V. Torres and P. Valderas
presented in this paper, allows developers of a microservice to communicate its local
changes to the rest of participants in a composition in such a way changes can be con-
firmed, if needed, either by the affected microservices or from a global perspective by
business process engineers.
References
1. Fowler, M., Lewis, J.: Microservices. ThoughtWorks (2014).
2. Fowler, M.: Microservices trade-offs. Available from: http://martinfowler.com/articles/mi-
croservice-trade-offs.htm, last accessed 2020/07/20
3. Dragoni, N., Giallorenzo, S., Lluch-Lafuente, A., Mazzara, M., Montesi, F., Mustafin, R.,
Safina, L.:Microservices: Yesterday, Today, and Tomorrow. Present and Ulterior Software
Engineering, 195-216 (2017)
4. IST
5. Di Francesco, P., Malavolta, I., & Lago, P. (2017, April). Research on architecting micro-
services: Trends, focus, and potential for industrial adoption. In 2017 IEEE International
Conference on Software Architecture (ICSA) (pp. 21-30). IEEE.
6. Cerny, T., Donahoo, M. J., & Trnka, M. (2018). Contextual understanding of microservice
architecture: current and future directions. ACM SIGAPP Applied Computing Review,
17(4), 29-45
7. Terzić, B., Dimitrieski, V., Kordić, S., Milosavljević, G., & Luković, I. (2018). Develop-
ment and evaluation of MicroBuilder: a Model-Driven tool for the specification of REST
Microservice Software Architectures. Enterprise Information Systems, 12(8-9), 1034-1057.
8. Oberhauser, R. (2016). Microflows: Lightweight automated planning and enactment of
workflows comprising semantically-annotated microservices. In Proceedings of the Sixth
International Symposium on Business Modeling and Software Design (BMSD 2016)
(pp.134-143).
9. Monteiro, D., Gadelha, R., Maia, P. H. M., Rocha, L. S., & Mendonça, N. C. (2018, Sep-
tember). Beethoven: an event-driven lightweight platform for microservice orchestration. In
European Conference on Software Architecture (pp. 191-199). Springer, Cham.
10. Cornax, M. C., Dupuy-Chessa, S., & Rieu, D. (2011, April). Bridging the gap between busi-
ness processes and service composition through service choreographies. In Working Con-
ference on Method Engineering (pp. 190-203). Springer, Berlin, Heidelberg.
11. Brüggemann, M. E., Vallon, R., Parlak, A., & Grechenig, T. (2014, August). Modelling
microservices in email-marketing concepts, implementation and experiences. In 2014 9th
International Conference on Software Paradigm Trends (ICSOFT-PT) (pp. 67-71). IEEE.
12. Mandell, D. J., & McIlraith, S. A. (2003, October). Adapting BPEL4WS for the semantic
web:
The bottom-up approach to web service interoperation. In International Semantic Web
Conference (pp. 227-241). Springer, Berlin, Heidelberg.
13. Zúñiga-Prieto, M., Insfran, E., Abrahao, S., & Cano-Genoves, C. (2016). Incremental inte-
gration of microservices in cloud applications.
14. Yahia, E. B. H., Réveillere, L., Bromberg, Y. D., Chevalier, R., & Cadot, A. (2016, June).
Medley: An event-driven lightweight platform for service composition. In International
Conference on Web Engineering (pp. 3-20). Springer, Cham.
15. Safina, L., Mazzara, M., Montesi, F., & Rivera, V. (2016, March). Data-driven workflows
for microservices: Genericity in jolie. In 2016 IEEE 30th International Conference on Ad-
vanced Information Networking and Applications (AINA) (pp. 430-437). IEEE.