This paper introduces an integration of the Saga pattern for eventual data consistency in microservice deployments with concurrency supplied by labeled P/T work ow nets. Main bene ts are improved speeds due to parallelization and providing methods of veri cation on successful runs due to the well-studied underlying formalism of Petri nets. The Saga pattern o ers an availability-oriented alternative to classic distributed transaction and locking mechanisms. Use cases are large systems, that use the shared-nothing data model, which is typically fullled by microservice applications. Sagas are traditionally de ned by a sequence of local transactions, but often concurrency between transactions is possible. This paper presents a solution to model concurrent Sagas with P/T work ow nets, called Petri net Sagas. As a proof-ofconcept an implementation shows, how to translate Petri net Sagas to reference nets and to execute them using the Renew simulation core. The implementation is available as a library for the Java programming language.
The development of large-scale systems went through large changes of paradigms
throughout the last decade. From the deployment of large monolithic
applications on a bare-metal server the architectural design of applications was heavily
in uenced by cloud technology, which was commercialized in the 2010s. One of
these architectural design shifts introduced the heavy use of the microservice
pattern. For an extended introduction see e.g. [
Microservices decompose an application into small and independent parts, which are usually managed by separate development teams each. A lot of bene ts can be reaped by utilizing microservices, e.g. scaling up the overall development workforce more easily. With the higher exibility, new drawbacks are Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). introduced though. Microservice architectures usually use a shared-nothing data model, meaning that every service features its own data model and database and redundancy of data is inevitable.
Microservice applications may span over hundreds or more individual
services. Therefore traditional database consistency technologies like distributed
commits, that utilize locking and focus on providing consistency over
availability, might not be feasible in this architecture anymore. This is due to frequent
and complex queries and an increased chance of node failure due to the higher
count of components in the system. According to the CAP-theorem [
The Saga pattern is usually implemented using state machines in mind, de
ning a process step by step. Possible concurrency is not utilized and therefore the
approach misses out on the potential for speed-ups. Only very few approaches
exist, that apply parallelism to the Saga pattern, like e.g. [
Petri net Sagas are simple (labeled) P/T (work ow-)nets, that need to be
provided by the developer specifying the Saga. In our underlying proof-of-concept
implementation, the Petri net Saga is translated into a reference net [
Our main contributions within this paper are the easy to use de nition of Petri net Sagas along with the translation mechanics to Reference nets for failure aware, concurrent, and transparent execution of Petri net Sagas. We thereby aid the development of Saga based consistency implementations by providing a mean to use a graphical representation of a Saga in the shape of a workow net. The method also alleviates the complexity of implementing concurrent steps by hand within a Saga, especially in the Java programming language, as our proof-of-concept implementation is also Java-based. Java is one of the main programming languages in microservice environments after web technology languages like JavaScript1. 1 see e.g. https://tsh.io/state-of-microservices/#programming-languages
Integrating services and providing eventual data consistency across multiple heterogeneous services can be a daunting task to achieve. Introducing additional concurrency usually increases the complexity even further. Therefore relying on a well-researched Petri Net formalism can help to design e cient and responsive microservice applications.
While simple Sagas can be described easier with less complex formalisms, Petri nets o er the possibility to describe more sophisticated procedures and by that are more future proof for further research. An additional motivation is the possibility to use model checking methods on Petri nets. Veri cation is only sparsely discussed in the context of the Saga pattern on some websites and online forums. There are to our best knowledge no citable sources related to Saga pattern veri cation.
The data, that is required by di erent services and might be required to be passed along is also not explicitly addressed by the Saga pattern. Using Petri nets as a base enables the notion of places and markings to model this kind of relations.
In summary, the goals of this paper are to provide a Petri net-based extension to the Saga pattern. This is done to enable concurrency and data allocation directly in the persistence model as well as providing ways to run formal veri cations on the persistence operation more easily. 1.2
To follow along the ideas presented in this contribution an example will be helpful. The example will focus on an large online book store, that is realized as a microservice application. Seven departments are considered: Order management, an inventory control system, pricing, a payment provider, accounting, ful llment and nally customer noti cations. Each department features an own system, with own data models and databases. The processing of purchases and by that interaction of the department systems is orchestrated by a classic sequential Saga, that will be described later in more detail. 2
The required basics for the addressed context are described brie y. The core aspects in the shape of microservices and the Saga pattern itself are introduced. This section also contains a basic introduction to reference nets, as they are a less generally known formalism of high-level Petri nets and di er in quite some aspects from other formalisms. 2.1
The term microservice is not globally uniquely de ned. As it, therefore, leaves room for interpretation, this section explains microservices as they are understood in the context of this paper. A microservice architecture consists of loosely coupled components and follows the Unix philosophy to "make each program do one thing well". They require additional infrastructure components and severely increase the overall complexity of the system. Individual microservices are small2 and rather easy to maintain and are usually tied to one speci c development team. However, microservices are no silver bullet and their use should always be considered thoroughly beforehand.
Microservices use a shared-nothing data model, meaning every microservice
manages its very own database. Multiple data models, as well as database
technologies, can coexist in microservice deployments. Despite this freedom, eventual
consistency must be guaranteed for the overall system to achieve meaningful
results. Technologies like e.g. X/OPEN DTP (e.g. [
This is usually tackled by relying on availability-oriented methods like the here discussed Saga pattern for data consistency. 2.2
A Saga [
Example: Online book store For a more real-world view the earlier introduced example is considered. The scenario involves a customer, who orders a book and pays using a credit card. When the customer clicks an "order now" button in the interface, rst an order id is generated and saved by the order service ( rst transaction). The book then needs to be reserved in the system managing available supplies with the order id (second transaction) and the current price needs to be fetched for payment processing (third transaction). After that, the credit card needs to be charged the amount required to pay for the book and shipping by an external payment provider (fourth transaction). After successful payment, the order gets transferred to the accounting system to be archived ( fth transaction) and to a ful llment service to enqueue the shipping 2 There is no explicit size requirement. However, due to the limit to one functionality, microservices tend to be much smaller in size than multi-purpose or monolithic applications. process (sixth transaction). Finally, the user receives a receipt via e-mail by the noti cation service (seventh transaction).
A Saga de nes the steps from the rst to the seventh transaction. Observe, that transactions one, two, and three are all reversible, as an order id may be deleted again and an item reservation may be canceled to make it available again. Reversing a credit card charge by the external payment provider is not that easy, hence it is considered the pivot-transaction in this case. It decides, whether the whole Saga fails or succeeds. Transaction ve to seven are all repeatable and have no non-technical reasons to fail. Upon technical failures, e.g. if the respective service is unresponsive, it will be repeated until it succeeds. The whole example is also shown as a linear P/T net in gure 1. Note, that the syntax for describing the services and commands, separated with a double colon ("::"), is not speci c to general Sagas, but used later in the here contributed Petri net Sagas and is already used here as well for consistency reasons.
Even in this small example, possible concurrency can easily be spotted. For example (if this is within the corporate guidelines) the user might get a receipt e-mail independent of the enqueueing of the shipping process or accounting and ful llment might be noti ed at the same time. Also, the current price can be fetched regardless of the progress in generating an order ID and reserving the item, to name some possibilities. This example will be shown again later within the paper with applied concurrency.
Execution of a Saga There are two major approaches on how to implement
the execution of Sagas. The related literature (e.g. [
Choreography is a classic fully decentralized approach, where each service only knows whom to contact next to proceed with a speci c Saga. Because services proactively call subsequent services the overall system is coupled more tightly. This also complicates changes to the Saga and deployments.
Orchestration in contrast relies on a centralized coordinator, that holds all
knowledge over the entire Saga process and the network coordinates of all
involved services. Maintainability and more loose coupling (every service is only
called within a Saga but never calls) are bought by introducing a single point of
failure into the system. Despite being the "impure" alternative, the
orchestration approach is often the preferred one in real-world applications. The reasons
are, that downtimes are more uncommon than the aforementioned deployment
problems and modern infrastructure solutions may provide backup solutions in
case of a node failure.
2.3
The prototype implementation of the presented contribution uses the reference
net formalism [
Reference nets incorporate the "Nets within Nets"/"Object Nets" approach
[
In gure 2 a simple example of a reference net is given to illustrate the concept. The syntax is the Java-based one used by the Renew simulator.
t1 may re twice, generating a new net instance of net2 each time. t2 then may re synchronously with t4 swapping one token each between the net instance net1 and one of the net instances of net2. After all rings, the net locks with two tokens each of color 3, 9, or 12 in place p3 and one token of color 5 in one net instance's place p7 and of color 7 in the other net instance's place p7. 3
Several related elds of research with respective publications exist. To our best
knowledge, there is no direct approach to support eventual data consistency
with concurrent operations across micro or web services using Petri nets as base
formalism. A direct overview over Saga implementations is given by [
There, however, have been some considerations regarding the implementation
of parallelized Sagas. They are related to process calculi, like [
Some research integrating services with Petri nets or using them in other
service-related work have been presented. [
[
Work related to running Petri nets in the cloud or Petri net-based cloud and
web- and microservice technologies has also been presented. [
From a consistency point of view, most research does not incorporate the shared-nothing data model. A respective example is the research area concerning sharded or replicated databases. 4
To incorporate Sagas with a Petri net-based formalism multiple aspects need to be considered. As the intended user group extends to developers, who are not experts in the eld of Petri nets, the formalism needs to be kept simple to remain appealing. Also, as veri cation possibility is one of the claims, using a formalism with a thorough veri cation tool support is desirable. Further, being a graphical representation of a process a clean representation of the Saga, that minimizes boilerplate elements, is desired.
While choreography based Sagas may seem more appealing from a scalable system point of view, it has already been motivated in section 2.2, that most realworld applications use orchestration-based Sagas instead. To address this and also because running a net simulation on a centralized node avoids distributed net simulation issues, in this paper Petri net Sagas are only presented with the orchestration application type in mind. Possible extension to choreography based applications is discussed in the outlook in section 8. 4.1
As the example in gure 1 shows, simple P/T nets may be su cient to model a Saga. To address the speci c service and desired endpoint a label should be added to each transition. Using P/T nets yields the direct bene t of using the most widely known kind of Petri net formalism. Developers, who are unfamiliar with the concept of Petri nets, can rely on various courses and literature to acquire the basics required. Also, there are numerous P/T net editor tools to generate nets with. P/T nets are not Turing-complete and being a simple vector addition system gives lots of mathematical possibilities. Veri cation on P/T nets is well studied and established tools are available. Despite being well suited for successful Petri net Sagas, P/T nets have insu cient means to model di erent results from a single transition ring. This drawback, however, is not problematic, as will be addressed in more detail in section 4.2. 4.2
The rst problem to address is the possibility for transactions to fail. It is important at this point to di erentiate between transactions and the transitions displaying them.
Methods to make a transition fail do exist, putting its consumed tokens back
into its preset places. This behavior was introduced by [
Another problem occurs, when one concurrent branch of the Saga fails early and synchronization in the Saga later on may never happen. To illustrate this, consider the (sequential) Saga from the example in gure 1 alongside its discussed ideas for concurrency. The stock service will require the order id generated by the order service. However, the price service is independent of any order id and thus may re concurrently with both the stock service and the order service transactions. If for some reason, the order service fails and gets rolled back, the stock service transaction will never be invoked. Still, the result of the price service awaits the result of the stock service to join and proceed with invoking the payment adapter service pivot-transaction, which will never occur. Therefore some kind of global failure handling needs to be implemented into each concurrent transaction and their results. A process, that is deterministically computable and error-prone if done by hand and therefore undesirable to do directly in the P/T net.
Failures of compensatable transactions are sparsely discussed in literature. As an additional feature we therefore decided, that pre-pivot-transitions of Petri net Sagas are also allowed to fail and rollback the Saga, giving the developer more freedom in implementations. It is, however, recommended to model transactions, that have an actual chance to fail, that is non-negligible, as pivot-transactions.
As failure handling transitions essentially do not add to the expressiveness of the model, we decided to let Petri net Sagas only explicitly model the successful cases and deduce the failure handling from these during execution. The model including the failure paths is still interesting though when considering veri cation purposes of the net. More thoughts on this are discussed in section 5.8 in the context of our implementation.
As Sagas describe a course of actions to pursue a speci c goal, modeling them
with work ow nets [
Executing (local) transactions during any step of a Saga usually requires some kind of data from previous transaction(s), or else they could be run concurrently. We assume the concurrent execution of di erent transactions implies no data dependencies exist between the transactions. Therefore a transaction is only dependent on the data of transactions, that are invoked before itself.
Also as individual microservices implement their functionality in their own domain, large exchanges of data between microservices can be assumed to be uncommon. Therefore it is su cient to provide each transaction invocation with a set of results that occurred before its invocation in the current Saga.
Possible additions may explicitly state required data but for now, we will use this rather simple approach.
As the speci c required data can be deduced from the structure of the Petri net Saga it is not necessary to explicitly model the data. It is already expressed by the command ow black tokens moving through the Petri net Saga during execution. 4.4
Overall a P/T net representation of a successful Saga run was chosen to model the Saga because it is su cient to model every aspect of the Saga, while the remaining aspects can be deduced implicitly. Labels hold information over the addressed service and the service endpoint (command) delimited by a double colon ("::"). The pivot-transaction is also speci cally labeled with the "::pivot" su x. The P/T net cannot be simulated directly, due to possibly failing transactions discussed earlier and therefore direct veri cation on the P/T net only holds for cases of successful runs. However, depending on the implementation, additional veri cation means are available. Section 5.8 addresses this topic in the context of the here presented implementation. Fig. 3. Petri net Saga displayed as a la
Petri net Sagas also feature spe- belled P/T net. ci c "init" and " nish" transitions to enable the implementation to add initialization and cleanup steps around the execution of the Saga.
An example Petri net Saga (work ow net) of the concurrent version of the sequential Saga presented in section 2.2 is shown in gure 3. The colors were chosen to represent the di erent transaction types as well as clarity on the relocation of transitions and arcs from the linear example. However, using colors is not mandatory, as they do not bear any semantic meaning for the Petri net Saga de nition itself. 5
To illustrate the concept of Petri net Sagas, the general approach to implement an execution environment for them will be presented. The section is oriented towards our proof-of-concept implementation. Figure 4 shows the general approach on how Petri net Sagas are processed by our implementation. 5.1
We decided to execute the Saga by translating the P/T net representation into
a higher Petri net formalism rst: Reference nets. We did so to enable the
possibility to be able to also supply more complicated Saga de nitions using reference
nets. With reference nets it is also possible to easily model transaction failures
while staying inside the reference net semantics. Further the powerful simulator
Renew based on the Java programming language is available to directly execute
reference nets as code. Finally, veri cation tasks can still be done to some degree
on the more complex reference net variant, due to recent publications, like [
Using reference nets, however, introduces the requirement to transform P/T net Saga de nitions into their reference net counterparts. During the translation, additional places and transitions get added to express the failure, repeatable, and rollback behavior to the net model. This is crucial for the advanced veri cation thoughts presented at the end of the section.
After being translated to a reference net representation the net will be simulated by an embedded Renew simulator. During the simulation, the net will promote calls to an abstract interface for Saga framework interaction. As di erent implementations of the Saga pattern exist, this is held as general as possible. Behind the general interface, a speci c implementation handles the calls and passes them to the speci c framework it is written for. Upon reaching the marking with just one token in the nishing place (in the work ow net sense) or the "rolled back" place, which will be introduced later in this section, the simulation terminates.
The basic syntax of the Petri net Saga is identical to the one presented in gure 3 and discussed in section 4.4. 5.2
The Petri net Saga is expected to be supplied in the PNML3 format. To construct the speci c inscriptions, transitions, and places required to model the reference net version of the Petri net Saga, a speci c data format was constructed. It is based on a simple net data structure featuring net, place, transition, and arc objects and adds Saga speci c content like pivot-transitions and mirror transitions (for reversible pre-pivot-transactions).
The data is then transformed into its reference net counterpart, which is discussed in detail in the next section. To be fed into the Renew simulation core the data is then transferred back into a reference net speci c variant of PNML. The reference net representation is not intended to be shown to the developer by default. However, it can be saved during the process to aid in troubleshooting and debugging scenarios. It is also possible to directly supply advanced reference net-based de nitions and skip the transformation part. 5.3
Reference net transformation tools like the Renew Metamodelling and
Transformation approach [
The transformation process itself consists of ve parts: creation of the transitions for compensating transactions, transformation of the labels, addition of guards and data passing and nally detecting failures. To be easier to follow, it will be described alongside the book store example. Figure 5 shows the nished and translated reference net from gure 3. The net is much more complex and displays detailed processing.
The procedure for the example starts with the work ow net representation depicted in gure 3. First the entire net structure prior to the pivot transition is copied and its arcs are reversed. The result can be observed in the upper right part of gure 5. This leads to an additional net part, that is able to execute the compensatable transactions in reverse order (or concurrently if no order was de ned by the original Saga net).
In the lower part of the net for repeatable transactions (depicted as light blue transitions) additional red repetition transitions are added to retry transactions after failures.
After that all the labels are converted into Renew-speci c calls: "step" calls in the original part of the net, and "rollback" calls in the newly copied part from the last step. These can be seen in the transaction inscriptions. During the transformation of the labels data passing ("result" inscriptions on the arcs) and guards are added, that handle possible failures and decide which route to take throughout the net. An example for such a translation is:
price service::get current price ! action result2 = Saga.step("price service", "get current price", [result1]);
Once data handling and guarding is nished, global running and failure indicators can be added. These are shown as red and green places and transitions in the upper left part of the gure. The "running" and failed place use so-called test arcs (without a tip), that are read-only, non-consuming and non-blocking for concurrent operations. Alongside these indicators, red failure handler transitions are added, that can be observed in the gure as vertical array of red transitions between the two groups of yellow transitions.
Note, that the red "failed" places with double outline are so called virtual places and have by de nition the same identity as the "failed" place with just one outline. Virtual places are used here to keep the net less cluttered but bear no semantic meaning. There are always two possibilities for failures: one, if the last transaction prior to this one failed, and one, if another transaction on a di erent concurrent branch failed. Synchronous channels are used for tidiness here ("this:stop()"). 5.4
Due to their nature reference nets can be executed directly by the simulator.
The execution engine is given in our implementation by using the simulation
core of the Renew simulator. It is embedded into the Petri net Saga library
and invisible to the programmer and administrator, except for its log outputs
and attached libraries. For further information in regards to the usage of the
simulator please refer to the Renew user guide [
Di erent available implementations of the Saga pattern exist. They are usually supplied in the shape of a framework and di er in functionality and licensing. An implementation speci c to one framework is possible but limiting. Therefore a general-purpose interface is put in front of the implementation for a speci c framework. The actually used framework can thus be swapped when developing with Petri net Sagas.
Available implementations are e.g. the Eventuate framework4 and the Axon
framework5, which both are commercial. Micro-pro le-lra6 is an open source
implementation and is based on the Narayana7 project. A survey on these
frameworks can be found in [
The implementation expects the usage of a supplied class to pass data from one Saga step to the next. The interface can then be extended for a speci c framework by implementing the behavior before the actual invocation of the Petri net Saga, after its completion, and the callbacks from the actual step or rollback actions. 5.6
The intended use of our Petri net Saga implementation is as a Java library in the development of microservice applications. Note, that enforcing consistency using the Saga pattern is just one aspect of a microservice deployment. Therefore, if considered in a larger scope, this work only addresses the orchestration of Sagas being done based on Petri nets. Other components like commands, services and service descriptors, message systems, etc., that are not Saga-related, need to be implemented and supplied separately to realize an entire microservice deployment.
The participants of a speci c Saga do not need to be aware of the usage of Petri net Sagas instead of conventional ones. This is due to the fact, that participants in orchestration-based Sagas - as described at the beginning of this contribution - are always only contacted by the orchestrator and do not possess information about the global process. However, they still need to implement the speci c command method or class used by the respective Saga framework. 5.7
Being one of the available frameworks for handling Saga patterns, the Eventuate framework is one of the most advanced ones and most dedicated to the Saga use case. Despite using an All rights reserved license, it follows the visible source8 4 https://eventuate.io/ - All URLs have been checked in January 2021 5 https://axoniq.io/ 6 https://github.com/eclipse/micropro le-lra 7 https://github.com/jbosstm/narayana/tree/master/rts/lra 8 https://github.com/eventuate-tram/eventuate-tram-sagas approach. For the aforementioned reasons, we implemented a sample adapter between our general-purpose interface and the Eventuate framework.
Evenutate is tightly coupled to microservice frameworks such as the Spring Framework or Micronaut. It also relies (as one possibility) on Apache Kafka9, which again relies on Apache Zookeeper10. Eventuate also utilizes a local backing database for the orchestrator. Globally seen, this setup is well known in microservice environments.
Despite its restrictive licensing, the code is designed to be very open for
additions, usually using interfaces instead of direct references. The context of
dependency injection[
Running veri cation tools and considerations on the Petri net Saga itself o ers possibilities to express information about successful runs of the Petri net Saga. The translation to reference nets presented within this implementation, however, o ers the possibility to discuss all possible runs. This is in most cases more desirable. Performing the transformation without restrictions on inscriptions and on the reference nets concepts changes the formalism to reference nets.
Reference nets are Turing-complete in their general form. However, there has
been the interesting recent contribution MoMoC [
Another attempt could be made by changing the semantics of the P/T Petri
net Saga in a way, that transition ring is controlled by the behavior of the
system instead of arbitrary rings of activated transitions. This would yield the
possibility to construct P/T nets similar to the presented reference net
translation, that models failures in separate transitions. Depending on the system
successfully or unsuccessfully completing a transaction the respective transition
could be red. In [
Our implementation can be downloaded from the project's website11. This section will brie y describe the implementation of custom use cases, as well as the implementation of the example presented throughout this paper.
10 https://zookeeper.apache.org/ 11 https://paose.informatik.uni-hamburg.de/paose/wiki/PetriNetSagas 6.1
First and foremost a PNML le describing the Petri net Saga needs to be supplied, like the one supplied by the example application. Additionally, as the implementation is based on Eventuate Tram Sagas, the respective Eventuate libraries, as well as the Petri net Saga libraries need to be supplied to the application. A Java Spring12 and Gradle13 based empty sample project containing all required dependencies can be found at the download location as well.
To use the framework several classes need to be implemented to specify the respective actions to be executed when invoking the commands of the Saga. A custom result type extending our base type needs to be created and command classes need to be registered with the command registry. This also involves de ning a custom aggregation implementation to aggregate multiple results of previous concurrent invocations. Participants need to register themselves under the service descriptor names with our command handle registry. If the setup of remote participants is not intended the service descriptor local could be used, though - if used exclusively - it de es the bene ts of using a Saga framework in the rst place. For further assistance with the Eventuate part of the implementation, please refer to the repositories and tutorials under its aforementioned website.
Handling a request with a Petri net Saga usually consists of instantiating the initial result (data) object of the request and creating a Petri net Saga by invoking the reference net Saga instance factory. 6.2
Finally, an example of how to use our implementation of Petri net Sagas is presented. To set up the example on a local machine as well, please refer to the setup instructions at the download location. To run the example of our Petri net Saga implementation a Linux environment is recommended, as well as Docker and the tool docker-compose, although these are not strictly necessary, as well as a Java JDK, which again is necessary.
We will reuse the example shown in gure 3 in section 4.3. The example is based - like the empty sample project - on the Spring framework and Gradle. It uses Apache Kafka, Apache Zookeeper, the Eventuate Tram CDC service, Zipkin14 and Mysql as backing services, which can be launched conveniently using docker-compose. The example itself de nes a total of seven custom command classes and a total of seven participating services. Each command just prints to the command line, that it has been invoked and then returns. The example de nes a single Saga with reference to the PNML net le. Results are aggregated just by combining their success-states with an AND-operation.
Upon starting, the consecutive and - where applicable concurrent - invocation of the steps can be observed in the log output. 12 https://spring.io/ 13 https://gradle.org/ 14 https://zipkin.io/
Based on the experiences with the prototype implementation our rst evaluation of the method can be discussed.
The approach integrated rather well with the Saga pattern, at least with the Eventuate implementation, though the central management core needed to be reimplemented accordingly. Sagas are already designed with concurrency between di erent Sagas and Saga instances in mind. However, feedback time for a user or process usually depends on the execution of one speci c Saga related to the request, and not multiple concurrent Sagas. Other Sagas executed by the system remain hidden by the transparency of the system. In the book store example presented throughout the paper this results in just four sequential steps instead of the original seven. Being a method of introducing concurrency, the performance gain depends heavily on the possibility to parallelize the process.
Traditional Saga systems hold some unused potential, as the robustness towards concurrency in the overall system is present, but not used within an individual Saga. Introducing the possibility of concurrency into a model designed as a sequential system implies several aspects to consider. By backing the Saga with a formal Petri net model we were able to mitigate these troublesome details to a degree. This provides a solid base for describing concurrent Sagas and successfully realizes the addressed potential.
On the downside, by our choice to express Petri net Sagas with labeled P/T nets, the possibilities to model data passings are (in this rst version) limited. They need to be covered by the Petri net Saga implementation and also the nal implementation of the system using the Petri net Saga library. Also, adding another layer of dependencies to the equation of a microservice system further increased its complexity.
Overall, we see the concept and the implementation as very promising and already plan certain use cases with its implementation in the context of the Renew simulator itself. 8
A novel method of de ning concurrent Sagas based on P/T work ow nets has been presented. The method is intended to be used in persistence operations in availability-oriented microservice deployments. We have motivated, that performance and response time for single Sagas can be improved by using the method and outlined the use of veri cation methods on the underlying formal Petri net model. In addition to the presented concept, a sample implementation based on translation to reference nets and execution using a Renew simulation core and the Eventuate Tram Sagas framework has been contributed.
Further research may include support for choreography-based solutions. The main challenges will include failure detection in concurrent branches.
Another extension could model speci c data portions required by each transaction invocation. Depending on the use case this might reduce the passed data between orchestrator and local transaction invocation. The restriction to P/T nets of manageable size might be di cult to hold under these circumstances and the use of colored nets (by folding) might become more suitable.
In further research, the here presented concepts can be applied to distributed
synchronous channels of distributed reference net simulations. The synchronous
channels may only hold at most one action15 inscription to be compatible with
the pivot-transaction model. This enables a much better scaling of distributed
reference net simulations [