=Paper=
{{Paper
|id=Vol-3618/dc_paper_2
|storemode=property
|title=Dealing with the evolution of event-based choreographies of BPMN fragments
|pdfUrl=https://ceur-ws.org/Vol-3618/dc_paper_2.pdf
|volume=Vol-3618
|authors=Jesús Ortiz
|dblpUrl=https://dblp.org/rec/conf/er/Ortiz23
}}
==Dealing with the evolution of event-based choreographies of BPMN fragments==
https://ceur-ws.org/Vol-3618/dc_paper_2.pdf
Dealing with the evolution of event-based
choreographies of BPMN fragments
Jesús Ortiz
Universitat Politècnica de València, PROS Research Centre, Valencia, Spain
Abstract
Business processes (BPs) are commonly used by organizations to describe their goals.
However, the existent decentralization found in many organizations forces them to build such
BPs by coordinating distributed and fragmented BPs. Within this context, microservices arise
as a very interesting and convenient way to address the implementation of such processes due
to their low coupling character. In this case, the coordination of such fragmented BPs is usually
achieved by means of event-based choreographies. Though, one of the main challenges to be
faced by choreographies is their evolution due to the complexity that introduces the need of
integrating changes among autonomous and independent partners. To this end, this thesis work
faces the challenge of evolving a microservice composition that is globally defined in a BPMN
collaboration diagram but executed through a choreography of BPMN fragments. To do so, it
presents a characterization of the changes that can be performed from the local perspective of
a microservice and the creation of a catalogue of adaptation rules that can be applied to the rest
of microservices to maintain the functional integrity of the composition. In addition, a
microservice architecture supporting this composition approach is proposed, which includes a
MAPE-K loop component for the selection of the adaptation rules when a change is introduced.
Finally, a protocol is defined for the application of the adaptation rules in order to ensure the
propagation of the changes and the adaptations rules to the rest of participants.
Keywords 1
Microservice, composition, BPMN, MAPE-K, evolution.
1. Introduction
Business processes (BPs) are the key instrument to organizing and understanding the interrelationships
of the different activities required to produce an outcome to the market [1]. However, when these
activities are performed in a decentralized way, e.g., by different departments within the same
organization, the decoupling characteristic of microservices makes them a very interesting and
convenient way to implement such processes. Microservice architectures [2] propose the decomposition
of applications into small independent building blocks (the microservices) that focus on single business
capabilities.
Therefore, microservices need to be composed to support the BPs of organizations. To this end, to
keep a lower coupling and independence among microservices for deployment and evolution, these
compositions are usually implemented by means of event-based choreographies. However,
choreographies split the control flow of the composition among the different participant microservices,
making it hard to analyze and understand when requirement changes. To improve this problem, [5]
proposed an approach based on the choreography of BPMN fragments. In this approach, business
process engineers create a microservice composition through a BPMN collaboration diagram. Then,
this diagram is split into BPMN fragments which are executed through an event-based choreography.
ER2023: Companion Proceedings of the 42nd International Conference on Conceptual Modeling: ER Forum, 7th SCME,
Project Exhibitions, Posters and Demos, and Doctoral Consortium, November 06-09, 2023, Lisbon, Portugal
jortiz@pros.upv.es (J. Ortiz)
0000-0002-9352-1045 (J. Ortiz)
© 2023 Copyright for this paper by its authors.
Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Wor
Pr
ks
hop
oceedi
ngs
ht
I
tp:
//
ceur
-
SSN1613-
ws
.or
0073
g
CEUR Workshop Proceedings (CEUR-WS.org)
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
This composition approach is supported by a microservice architecture to achieve that both descriptions
of a composition, the global composition view and the split view, coexist in the same system. However,
this solution introduces a new challenge to be faced: how to evolve a microservice composition that is
globally defined in a BPMN collaboration diagram but executed through a choreography of BPMN
fragments. This work does not adequately support the evolution from the local perspective of a BPMN
fragment since changes that have an impact in other microservices are not considered.
To this end, in this thesis work we face this problem by characterizing the local changes that can be
introduced from the local perspective of a BPMN fragment and defining a catalogue of adaptation rules
that are applied when a change introduces inconsistencies in the composition, in order to maintain the
functional integrity of the composition. In addition, a microservice that implements a MAPE-K loop is
introduced in the presented architecture that supports this composition approach. This microservice
automatically selects the adaptations rules that must be applied from the catalogue. Additionally, a
protocol to facilitate the propagation of local changes and adaptation rules to the rest of microservices
is also presented. The contributions of this work are focused on improving the problem of automating
the redesign of the processes of a microservice composition, in this case, implemented as a
choreography of BPMN fragments, which currently remains as a manual and cognitively demoing task,
making it time-consuming, labor-intensive and error-prone [4].
The rest of the paper is organized as follows: Section 2 presents an overview of the work this thesis
relies on. Then, section 3 presents the catalogue of adaptation rules required to keep the functional
integrity of the choreography, and section 4 the microservice architecture designed to support the
evolution challenge previously identified. Then, section 5 analyses the related work, and finally,
conclusions are commented on in Section 6.
2. Previous work and contribution
This section presents an overview of the approach proposed in [5] to create a microservice composition
as an event-based choreography of BPMN fragments. This approach proposes to create a microservice
composition in two main steps (see Figure 1): (1) business process engineers create the global
composition view of the composition in a BPMN collaboration diagram following an orchestration
approach, and (2) the BPMN collaboration diagram is split into BPMN fragments that are deployed into
separated microservice and executed through an event-based choreography. Each BPMN fragment is
sent to its corresponding microservice and managed autonomously by its microservice development
team.
As a representative example, a scenario based on the e-commerce domain is defined, which
describes the process of placing an order in an online shop. The different tasks that make up this process
are distributed by responsibilities in four different lanes: Customers, Inventory, Payment and Shipment
(see top of Figure 1).
After creating the global composition view of the composition, the BPMN collaboration diagram is
split by responsibilities into independent BPMN fragments that will be managed by different
microservices (see bottom of Figure 1). This split is performed automatically by a tool developed in [5]
where each BPMN fragment is created as a pool with the tasks that are defined in the corresponding
lane and a list of Catch/Throwing Events that are automatically added to support the event-based
choreography. The microservices managing each fragment are endowed with a process engine that
oversees the execution of their respective BPMN fragment to execute (1) the tasks defined in the pool
(what we call functional requirements), and (2) the Catch/Throwing Events to either receive or publish
asynchronous events in a communication bus to support the collaboration with the rest of participants
(what we call coordination requirements). Thus, the microservice composition is executed by means of
an event-based choreography of BPMN fragments in which microservice wait for specific events to
execute their corresponding piece of work.
This solution introduces two main benefits: First, it facilitates the analysis of the control flow since
a BPMN diagram that represents the entire composition (e.g., the global composition view) is available.
Second, it provides a high level of decoupling among the microservices that participate in the
composition. However, this solution introduces a new challenge to be faced: how to evolve a
microservice composition that is globally defined in a BPMN collaboration diagram but executed
through a choreography of BPMN fragments. This work allows the introduction of changes from two
perspectives: from a global perspective, i.e., modifying the BPMN diagram that represents the global
composition view (top-down evolution); and from a local perspective, i.e., modifying the BPMN
fragment of one microservice (bottom-up evolution). While the top-down evolution is natively
supported by the tool presented in [5], the bottom-up evolution is limited to some specific changes,
specifically to the changes that can be managed in isolation, without affecting other microservices.
Figure 1: A microservice composition based on BPMN fragments
To address this challenge, in this thesis we face the evolution of a microservice composition from a
bottom-up perspective when a participant introduces a local change in its individual BPMN fragment
that affects other microservices. When changes are introduced in this scenario, additional aspects must
be guaranteed due to the complexity introduced by the interaction of autonomous and independent
partners. Therefore, adaptations to maintain the integrity of the choreography should be suggested to
the affected partners. Additionally, following the proposed microservice composition approach, a
change introduced from the local perspective of a microservice needs to be integrated with both, the
BPMN fragments of the rest of the microservices and the BPMN collaboration diagram that represents
the global composition view. Allowing local changes in a microservice reinforces the independence
among development teams that is demanded by this type of architecture. Note that a change may affect
a functional requirement (e.g., modifying a BPMN task) or a coordination requirement (e.g., modifying
a Catch/Throwing Event). While local changes in functional requirements only affect the internal
behavior of a microservice and do not require the adaptations of the rest of participants, local changes
in coordination requirements can have an impact on the composition, eventually causing its failure
(e.g., affecting the participation of the rest of microservices). For instance (see bottom of Figure 1), if
the Customers microservice deletes the Throwing Event that sends the message Customer Checked, the
Inventory microservice, which is waiting for it, will never start, and the microservice composition will
never continue. Therefore, changes in these types of requirements imply coordinated actions in two or
more microservice in such a way a correct communication between microservice is ensured.
Consequently, this thesis work faces the challenge of supporting the bottom-up evolution of a
microservice composition, focusing on the coordination requirements found in distributed
compositions. To do so, the contributions of this work are:
1. The characterization of the changes that can be performed from the local perspective of a
microservice and the creation of a catalogue of adaptation rules that can be applied to the rest of
microservices in order to maintain the functional integrity of the composition.
2. The proposal of an extended microservice architecture that integrates a MAPE-K loop for the
selection of adaptation rules when local changes are introduced.
3. The definition of a protocol for the application of the adaptation rules that allows the acceptance
of developers, when needed, to guarantee the propagation of the changes and the adaptations to the
rest of the participants of the composition.
3. Catalogue of adaptation rules
A catalogue of adaptation rules that describe how a local change must be managed to maintain, when
possible, the functional integrity of the choreography, has been defined. To guarantee the functional
integrity, it must be ensured that all microservices must be able to participate in the choreography and
therefore, there must be at least one Throwing Event that sends a message to be received by a Catching
Event. However, the rules that are included in the catalogue do not ensure properties such as deadlock-
free and fault-tolerance in a composition. These problems have been extensively researched by the BPM
community [16, 17] and to face them, the change patterns identified in [3] are proposed, in order to
ensure the correctness of the composition after the change and the adaptation rule are applied.
A total amount of 14 adaptations rules have been defined and they have been collected in the
following catalogue of adaptation rules [6]. The rules can be defined as a set of modifications actions
that are applied to the BPMN fragments affected by the introduced change, i.e., those BPMN fragments
that, due to the local change, can no longer participate in the composition. Therefore, the adaptation
rules apply the required modifications to maintain the participation of the affected BPMN fragments in
the choreography. Based on [7], every add, delete, and update modification that can be applied in a
coordination requirement has been identified. 6 out 14 rules are defined to support delete changes, 6
out of 14 rules are defined to support update changes, and finally, the 2 remaining rules are defined to
support add changes. Only these types of modifications have been identified as they are challenging by
themselves, and any further change can be written as a combination of them. All modifications
identified have been applied in four different case studies2, and the adaptation actions required to
maintain the functional integrity of the composition have been analyzed. This was done following an
iterative and incremental process [18] in such a way the adaptation rules were progressively developed
and tested in the case studies, refining previous definitions when some errors or objections were
detected.
In this paper, due to space limitations, only one of the rules of the catalogue is presented, specifically
Adaptation Rule #1. This rule faces the removal of a Throwing Event in a BPMN fragment. This type
of change modifies a BPMN fragment by removing a BPMN element that is used to send a message to
inform other microservices that a piece of work has been done. Thus, it affects all the microservices
that include a Catching Event to receive the deleted message, which will never start or continue since
their execution depends on the triggering of such message. Therefore, to support this local change,
Adaptation Rule #1 adapts the affected microservices to start listening to the message triggered just
before the deleted one.
As a representative example, the example presented in Section 2 is used to show how Adaptation
Rule #1 is applied (see Figure 2). If the Throwing Event Customer Checked of the Customers
2
The considered case studies can be found in: https://github.com/microserviceresearch/ml-microservice-composition-
evolution/tree/main/CaseStudies
microservice is removed, the Inventory microservice, which is waiting for it, will never start. To allow
the Inventory microservice to complete its tasks, it is modified to wait for the message previously caught
by the modified fragment, i.e., to wait for the Process Purchase Order message instead. This adaptation
of the affected local fragment maintains the functional integrity of the choreography (i.e., all the tasks
executed before the local change are executed afterwards). However, two microservices that initially
worked sequentially (e.g., first Customers checks the customer information, and then Inventory checks
the availability of the purchased products) are now executed in parallel (e.g., after the adaptation, the
start of the Customers microservice and the Inventory microservice are executed when the client sends
the message Process Purchase Order).
Figure 2: Example of Adaptation Rule #1
4. Supporting microservice architecture
In this section, an extension to [5], a microservice architecture that supports a microservice composition
based on the choreography of BPMN fragments, is described (see Figure 3). The objective of this
extended architecture is to support not just the development and deployment of a microservice
composition based on BPMN fragments, but also its further evolution. For this purpose, new
components are introduced into the architecture to automate, as much as possible, the application of
adaptation rules to maintain the integrity of the composition when a change in a coordination
requirement is done from the local perspective of one microservice.
The microservice architecture has been extended by introducing a MAPE-K control loop component,
which is typically used to manage the adaptations of autonomic systems [19]. A MAPE-K control loop
consists of four phases: the 1) Monitoring phase; the 2) Analysis phase; the 3) Planning phase; and the
4) Execution phase. In addition, the MAPE-K control loop includes a Knowledge Base that stores
properties to describe the past and present state of the system and its environment [20].
Initially, the architecture presented in [5] was designed with the following three components: (1) the
business microservices that participate in the composition. Following the example of Section 2, we have
the Customers, Inventory, Payment and Shipment microservices. (2) the Global Manager microservice
that oversees the management of the BPMN collaboration diagram that represents the global
composition view, and (3) an event bus that supports the exchange of messages among microservices at
execution time. To support the evolution of the composition, the architecture has been revisited as
follows: (4) the MAPE-K Controller microservice that controls the three first phases of the MAPE-K
loop has been introduced, (5) the Global Manager microservice has been endowed with the adaptation
rules and a new component that oversees the execution phase of the MAPE-K loop; and (6) the
Knowledge Base component to register the local changes that occur in the system has also been
included.
Figure 3: Representation of the architecture
The MAPE-K Controller is the component that oversees the first three phases of the MAPE-K loop,
i.e., the Monitoring phase, the Analysis phase, and the Planning phase. The Global Manager is in charge
of the last phase of the MAPE-K loop (i.e., the Execution phase), and is endowed with the catalogue of
adaptation rules. Each rule is considered as an endogenous model transformation [21], i.e., a
transformation between two models (the original BPMN fragment and the adapted one) expressed in
the same language. In this work, we have used a direct manipulation approach based on the Java BPMN
parser provided by the Camunda platform. We have selected this option since it is supported by other
Java tools that facilitate the integration of the adaptation rules with the previous microservice
architecture. Finally, the Knowledge Base component is defined to represent and store the local changes
that occur in the system to be able to react to them. Therefore, the Knowledge Base can be considered
as a collection of logs where the microservices indicate which element within their BPMN fragment
has been changed.
To properly understand the MAPE-K loop implemented in the architecture, additional details are
given first about the Knowledge Base and then about the MAPE-K phases:
Knowledge Base: In this work, we want to evolve a microservice composition that is implemented
as an event-based choreography of BPMN fragments when a local change is done from the local
perspective of one microservice. Thus, each time a microservice performs a local change in its BPMN
fragment, the change is published in the event bus (Step 1 in Figure 3). Then, the Knowledge Base
stores the published change indicating which element within the modified BPMN fragment has been
changed.
Monitoring phase: This phase identifies when a published local change can introduce
inconsistencies (Step 2 in Figure 3). In this work, an inconsistency occurs when a change in a
coordination requirement is made, since it can affect the participation of the microservices in the
choreography, eventually causing its failure. Changes in functional requirements can be managed
internally without affecting the rest of the partners, and therefore, they do not require the application of
any adaptation rule. The changes that can produce inconsistencies in coordination requirements are
analyzed in detail in [6].
Analysis phase: This phase collects and analyses all the necessary information to characterize a
local change in detail. The information required to perform such characterization is collected from the
local change registered in the Knowledge Base (Step 3 in Figure 3). This characterization of the local
change is done to be interpreted by a machine learning algorithm used in the Planning phase. When all
this information is collected, it is encoded as a feature vector [8]. For simplification purpose, only five
of the features that are collected are presented: (F1) the type of modified element (Throwing Event or
Catching Event); (F2) the type of change that has been done (we only consider three type of changes,
delete, update, or add); (F3) whether or not the change results in the publication of a new message in
the choreography; (F4) whether or not a Throwing Event of another BPMN fragment is affected; and
(F5) whether or not a Catching Event of another BPMN fragment is affected. As representative
example, Table 1 represent a partial characterization of the local change presented in Figure 2: the
modified element (F1) is a Throwing Event (represented by the value 1), the action done (F2) is a
deletion (represented by the value of 0); the change (F3) does not result in the publication of a new
message since is a deletion (represented by the value of 0); a BPMN Throwing Event (F4) is not affected
(represented by the value of 0), and a BPMN Catching Event (F5) is affected (represented by the value
of 1).
Table 1
A partial feature vector characterizing the delete change illustrated in Figure 2
F1 F2 F3 F4 F5 …
1 0 0 0 1
Planning phase: Once a local change has been characterized in a feature vector, the planning phase
must select one of the adaptation rules contained in the catalogue presented above to solve the
inconsistencies created by the change (Step 4 in Figure 3). To do so, we propose using an algorithm
based on machine learning techniques, which provides us with several benefits. Note that by manually
implementing an algorithm to predict an adaptation rule, we need to code a vast amount of complex
condition, which is a time-consuming and error-prone task. In addition, this makes its further redesign
difficult. Using a machine learning algorithm, this process is automatically done by a prediction model
that just needs to be trained with data. Also, we can re-train the prediction model or change the technique
used to predict either to improve the predictor’s performance or to add more adaptation rules in the
future. Thus, in the planning phase, the feature vector that characterizes the local change is processed
by a machine learning algorithm that selects an adaptation rule to face the change.
Execution phase: Once the machine learning algorithm has selected an adaptation rule to be applied,
the Global Manager microservice is informed (Step 5 in Figure 3) to apply it in the BPMN collaboration
diagram that represents the global composition view (Step 6). To do so, we apply a protocol (presented
in the next section) that classifies the adaptation rules into automatic adaptation or adaptation with
acceptance. Depending on this classification, the Global Manager applies the rule either automatically
or previous human acceptance (Step 7 in Figure 3).
5. Proposed evolution protocol
This section explains the proposed evolution protocol to facilitate the propagation of changes when
adaptation rules must be applied. Note that the impact of change propagation on running instances is
not addressed by the proposed protocol. The adaptations applied only affect the new instances created
after it. This decision is technologically supported by the default behavior of the BPMN engine that is
used to execute the microservice composition, which provides a versioning strategy to evolve the
process definition without affected running instances.
Broadly speaking, to define a protocol we need to describe the participants, the actions each
participant does within the protocol and the messages they exchange [9]. The participants involved in
the proposed protocol can be either software participants, represented by microservices which perform
actions automatically (i.e., the locally modified microservices and the affected ones), or human
participants, represented by process stakeholders who participate in the design and the decision-making
process required to apply the proposed evolution protocol (i.e., the developers of the microservices and
the BP engineer responsible for the Global Manager microservice). Regarding the actions and the
interchange messages considered by the protocol are shown in Figure 4. When an adaptation rule has
been selected, this can be classified as automatic adaptation or adaptation with acceptance.
On the one hand, an adaptation rule is classified as automatic adaptation when the adaptation
required to maintain the integrity of the choreography can be automatically applied in the BPMN
collaboration diagram that represents the global composition view since the functional and coordination
requirements are both maintained. Therefore, no human participation is required. Following the
protocol presented in Figure 4, when an adaptation rule is selected and classified as automatic
adaptation, the rule is applied on the BPMN collaboration diagram that represents the global
composition view, stored in the Global Manager, to afterwards, re-split the BPMN collaboration
diagram into BPMN fragments, and send the adapted fragments to the corresponding microservices to
be implemented. Finally, a commit message is sent to the modified microservice to inform that the
adaptation has been applied and consequently, it can implement the introduced change in its BPMN
fragment.
Figure 4: Phases of the evolution protocol
On the other hand, an adaptation rule is classified as adaptation with acceptance when the adaptation
required to maintain the integrity of the choreography can be automatically applied in the BPMN
collaboration diagram that represents the global composition view, but the adaptation implies some
alterations in the coordination requirements among microservices. For instance, the adaptation may
imply changing the execution order of some microservices (see the example explained in Figure 2). In
this case, functional requirements are kept (i.e., all the tasks remain after the change), but the flow of
these tasks changes. Thus, human participation is needed. Therefore, when the adaptation rule has been
selected and applied on the BPMN collaboration diagram that represents the global composition view,
stored in the Global Manager, the BP engineer must decide if the adaptation rule is accepted or not. If
the adaptation rule is rejected, the change is denied and the modified microservice and the Global
Manager must perform a rollback to return to their prior state before the introduction of the change. If
the adaptation is accepted the BPMN diagram is re-split into BPMN fragments, and they are sent to the
corresponding microservices. In order to implement the adaptation rule in each affected BPMN
fragment, the adaptation must be accepted by each microservice developer affected by the change. If
one of them rejects the adaptation, the change is denied and the modified microservice and the Global
Manager must perform a rollback to return to their previous state before the application of the change.
In addition, the Global Manager informs the rest of the affected microservices that the adaptation has
been rejected, and thus they cannot implement it. If everyone accepts the adaptation, a commit message
is sent to the modified microservice and the affected ones to inform them that the adaptation has been
accepted and consequently, the introduced change and the adaptation rule can be implemented.
6. Related work
In the area of service compositions, [10] provides a formal method for representing syntactic properties
of orchestrations and a set of axioms/invariants to align the orchestration model in a syntactic and
semantic way. In their work, the orchestration and the choreography are considered two different
elements with different representations and consequently, to propagate the changes it is required to
apply transformations between the two models. Our proposal implements an architecture to automate
the evolution process when a change is introduced from the perspective of one microservice, and we
also make it easier to understand the impact that the change and the adaptations have on the
composition, since we have a visual representation of the global composition and the BPMN fragments.
In the area of flexible business process [11] proposes an approach to model business scenarios as a
set of small fragments and the use of data objects states to combine them at runtime. Their work differs
from ours in that they cover major changes in fragments such as adding new one, while we consider
changes that affect specific elements inside the process of a BPMN fragment, such as tasks or
interaction elements (Throw/Catching Events).
Finally, in the area of change management, [12] proposes change propagation algorithms to ensure
behavioral and structural soundness of choreography partners in their processes. We go a step further
and propagate and adapt the changes to guarantee the participation of every partner in the composition.
[13] explains a negotiation phase to apply a change, but no mechanism is proposed to ensure that all
partners have applied the change. [14] presents an approach to apply incremental changes (modify, add,
and delete) to the participants of the choreography, but it does not consider mechanisms to ensure the
propagation of the changes. Our approach follows a protocol that ensures that local changes and
adaptations are propagated and implemented in the global composition and to each affected participant.
[15] defines a set of rules to ensure the correctness of change operations. Their work is a formalization
of event-based process and its refinement, but it is not clear how this refinement can be done from a
participant’s perspective. Furthermore, their proposal has not been put into practice, while our proposal
has been implemented.
7. Conclusions
This thesis work faces the challenge of supporting the bottom-up evolution of a microservice
composition, focusing on the coordination requirements found in distributed compositions. To do so,
we introduce a characterization of the changes that can be performed from the local perspective of a
microservice and the creation of a catalogue of adaptation rules that can be applied to the rest of
microservices in order to maintain the functional integrity of the composition. In addition, it proposes
an extension to an existing microservice architecture to integrate a MAPE-K loop for the selection of
adaptation rules when local changes are introduced. This new component is supported with a protocol
to allow the acceptance of developers, when necessary, when an adaptation rule is selected by the
MAPE-K component, and it also guarantees the propagation of the changes and the adaptations to the
rest of the participants of the composition.
To finish this thesis work, we are extending the characterization of the changes and the catalogue of
adaptation rules by considering new adaptation rules to support local changes that affect the data
exchanged by the microservice. Consequently, the MAPE-K component must be re-trained to integrate
new adaptation rules. In addition, we want to study the application of online machine learning
techniques so the classifier used in the planning phase of the MAPE-K loop can be automatically re-
trained from the different results obtained progressively. Finally, we also plan to validate the protocol
and the microservice architecture with more complex experiments to verify the effectiveness of the
tools developed in environments with multiple microservices.
Acknowledgements
This work is part of the R&D&I project PID2020-114480RB-I00 funded by
MCIN/AEI/10.13039/501100011033. It is also supported by the Research and Development Aid
Program (PAID-01-21) of the UPV.
References
[1] M. Weske, Business Process Management: Concepts, Languages, Architectures. Springer. (2007).
[2] J. Lewis and M. Fowler: Microservices, 2014. URL: https://martinfowler.com/articles/micro-
services.html (accessed April 2023).
[3] Weber, B., Reichert, M., & Rinderle-Ma, S., Change patterns and change support features–
enhancing flexibility in process-aware information systems, Data & knowledge engineering 66.3
(2008) 438-466.
[4] I. Beerepoot, C. Di Ciccio, H. A. Reijers, S. Rinderle-Ma, W. Bandara, A. Burattin and F. Zerbato,
The biggest business process management problems to solve before we die. Computers in Industry
146 (2023) 103837.
[5] P. Valderas, V. Torres, and V. Pelechano, A microservice composition approach based on the
choreography of BPMN fragments, Inf. and Soft. Technology 127 (2020) 106370.
[6] J. Ortiz, V. Torres, and P. Valderas, Formalisation of Evolution issues in Microservice
Compositions implemented as a choreography of BPMN Fragments, Research Report. URL:
https://microservicere-search.github.io/AdaptationRuleCatalogue.pdf (accessed May 2023).
[7] J. Ortiz, V. Torres, and P. Valderas, Microservice compositions based on the choreography of
BPMN fragments: facing evolution issues, Computing 105.2 (2022) 1-42.
[8] J. Miao, and L. Niu, A Survey on Feature Selection, In Procedia Computer Science 91 (2016) 919–
926.
[9] D. Butler, D. Aspinall, A. Gascón, On the formalisation of S-protocols and commitment schemes,
In Principles of Security and Trust (2019) 175–196.
[10] A. Wombacher, Alignment of choreography changes in BPEL processes, In IEEE International
Conference on Services Computing (2009) 1-8.
[11] M. Hewelt, and M. Weske, A hybrid approach for flexible case modelling and execution, in:
Proceedings of the 14th. Business Process Management Forum: BPM Forum, Rio de Janeiro,
Brazil, 2016, pp. 38-54.
[12] W. Fdhila, C. Indion, S. Rinderle, and M. Reichert, Dealing with change in process choreographies:
Design and implementation of propagation algorithms, Information systems 49 (2015) 1-24.
[13] W. Fdhila, C. Indiono, S. Rinderle-Ma and R. Vetschera, Multi-criteria decision analysis for
change negotiation in process collaborations, In IEEE 21st International Enterprise Distributed
Object Computing Conference (2017) 175-183.
[14] R. R. Mukkamala, T. Hildebrandt, and T. Slaats, Towards trustworthy adaptive case management
with dynamic condition response graphs, In 17th IEEE International Enterprise Distributed Object
Computing Conference (2013) 127-136.
[15] S. Debois, T. Hildebrandt, and T. Slaats, Safety, liveness and run-time refinement for modular
process-aware information systems with dynamic sub processes, in: Proceedings of the 20th.
Formal Methods: 20th International Symposium, Norway, 2015, pp. 143-160.
[16] F. Fakhfakh, H. H. Kacem, & A. H. Kacem, Ensuring the correctness of adaptive business
processes: a systematic literature review, International Journal of Computer Applications in
Technology 62.3 (2020) 189-199.
[17] A. J. V. Vaca, & R. M. Gasca. Opbus, Fault tolerance against integrity attacks in business
processes, In: Proceedings of the 3rd. Computational Intelligence in Security for Information
Systems, Berlin, Germany, 2010, pp. 213-222.
[18] C. Larman, V.R. Basili, Iterative and incremental development: A brief history, Computer 36.6
(2003), 47–56.
[19] S. Jahan, I. Riley, C. Walter, R. F. Gamble, M. Pasco, P. K. McKinley, & B. H. Cheng, MAPE-
K/MAPE-SAC: An interaction framework for adaptive systems with security assurance cases,
Future Generation Computer Systems 109 (2020) 197-209.
[20] D. Garlan, S. W. Cheng, & B. Schmerl, Increasing system dependability through architecture-
based self-repair, Architecting dependable systems (2003), 61-89.
[21] K. Czarnecki, S. Helsen, Classification of model transformation approaches, In: Proceedings of
the 2nd. OOPSLA Workshop on Generative Techniques in the Context of the Model Driven
Architecture, USA, 45.3, 2003, pp. 1–17.