This contribution presents the integration of the cloud-native paradigm into the distributed simulation of reference nets. This is done to reap the bene ts of cloud-based environments and by that to increase the scaling capabilities of such simulations on an architectural level. In contrary to most Petri net formalisms, reference net simulations are able to allocate net instances at runtime, like objects are instantiated in object oriented programming. Therefore, reference nets are not static in size and well suitable to natively model dynamic systems with changing demands and net structures. During the architectural discussion the key concepts of operability, observability, agility, and resilience are addressed. Further, a proof-of-concept implementation illustrates the potential of such cloudbased systems. It utilizes the simulator Renew and the Java Spring framework.
The interaction of large sets of agents in hierarchical structures is omnipresent in the real-world. While humans are certainly agents in this notion, machines and organizational entities can be as well. Through simulation of these kinds of interactions, information about real-world scenarios can be deduced. In the context of reference nets, a high-level Petri net formalism, that supports concepts similar to object-oriented programming, several publications regarding simulation of hierarchical agents exist.
While several important questions have been addressed by these publications, the simulations usually ran on a single physical machine and by that, we are restricted in its size. While the simulation of traditional Petri nets is usually static in size with the exception of token count in some cases, the size of a reference net simulation cannot be determined at compile time. This is due to their concept of net instances, which may be created dynamically during runtime. Therefore, scalability is an interesting issue to be solved in the context Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). of simulating reference nets. It addresses the ability to dynamically extend the simulation to more physical notes in an automated and unsupervised fashion.
There has been research to execute a reference net simulation over
multiple machines using the Distribute plugin for the simulator Renew [
Cloud nativity is a paradigm to construct applications, that do not rely on the possibility for operators to be able to access the systems they are running on. With increasing independence on the underlying infrastructure, the application is able to spread to additional physical nodes more easily.
Cloud native applications are also popular in the community of microservice applications. These are usually run in cloud environments, that are constructed and destructed dynamically and applications are deployed automatically.
This paper contributes software architecture related solutions to incorporate the paradigm of cloud nativity into reference net simulators, especially the Renew simulator. Our foreseen bene ts are a more exible use of the simulator, abstraction from speci c protocols like e.g. Java RMI, and better incorporation into scalable environments. Our contribution is focused on the backend-part of the simulator. Therefore any graphical representations or consumers are referred to and used for motivation in the following sections, but are not part of the core contribution. As an exception, we use the ready-made user interface of Spring Boot Admin1 in the evaluation part of this contribution.
In chapter 2 we explain the basics. The general strategy on how to approach an integration is covered by chapter 3. Following that, chapter 4 describes the conceptual integration of Cloud Native Renew. In chapter 5 we elucidate our implementation. Lastly, chapter 6 serves as an evaluation of our work, and chapter 7 represents a nal conclusion. 1.1
When attempting the simulation of large-scale systems scalability of the simulating software components is bene cial. Using a paradigm such as cloud nativity can directly improve this aspect of software. Without dependence on system access to the infrastructure running the simulation, as well as robustness towards other components and agility of the software, many manual steps can be necessary to incorporate additional physical nodes into the simulation.
in March 2021
The requirement for the introduction of scalable reference nets originated from the construction of dynamic multi-agent multi-platform systems. The overall approach is far too large to su ciently summarize here. The gist of the approach is the introduction of a platform management system, that is able to proactively summon heterogeneous reference net based agent platforms into existence and deploy speci c functionality to it, as well as to move agents between these kind of platforms.
Looking from the Petri net point of view, there should be no di culty in ring concurrent transitions on physically distant nodes. However, due to the complexity of the simulation of systems described with reference nets, this can be di cult to achieve. A cloud native simulator also favors more universal protocols for information retrieval, such as HTTP, and by that enables the simulation to be accessible in di erent ways from di erent software and systems.
With a universal interface to the software, it is e.g. possible to easily split simulation and representation of the simulation. Additionally, a cloud native simulator could be used without installing it on a local system rst, enabling even low spec clients like e.g. netbooks to run complex simulations easily. Also, it is possible to interact with the simulation without a local Java environment installation.
Another useful factor is the ability for the simulator to report other states of the simulator, which would otherwise be di cult to determine from the system's point of view, that is running the simulator. Examples for these states are the number of simulated net instances, loaded plugins of the simulator, liveliness of the simulated reference net, and so on. These could be accessed in the same fashion as external attributes such as CPU load or memory consumption. 1.2
Several research papers have been published concerning the integration of Petri
nets and service-oriented structures, like [
The combination of container technology and Petri nets has been discussed
in [
Introducing the topic, we now explain the core concepts reference nets, Renew,
and cloud nativity.
Reference nets are colored Petri nets that convey the object-oriented mindset
and combine the concept of nets-within-nets [
Renew [
Renew features a "remoting" layer between the simulation core and the user
interface. It is based on Java RMI3 and has been introduced in Renew 1.6 in
[
Upon starting a remote-enabled simulation, a second instance of Renew may connect to the running simulation over RMI. It is then possible to control the simulation from the second instance as if it was running locally. This includes starting, stopping, resuming, stepping, and terminating a simulation, as well as ring transitions manually. It is also possible to view instantiated net instances, as well as the current marking and transition rings. Renew Remoting, however, is limited to a connection to a single simulator.
The Distribute plugin was introduced by Michael Simon [
It alters the core of the simulation algorithm in various ways. The details
are less important for the considerations in this contribution and are therefore
omitted. The publication [
A recent contribution to the Renew simulator is the support of modularity. It is employed using the Java Jigsaw project, which was released with Java 9. Its main bene ts are improved encapsulation within the application by using explicitly de ned interfaces between modules. Module dependencies are also de ned as a directed acyclic graph instead of arbitrary connections.
As an additional step, modular Renew also uses so-called module layers, which provide a means to apply existing module principles to code, that is loaded at runtime. Module layers also provide the base for the ability to dynamically unload plugins, which is interesting in the context of hot-swapping implementations within a running application. By now, each Renew plugin resides in its own module, which is loaded inside a separate layer.
Modular Renew can also be downloaded from the project's website as "preview of Renew 4.0". 2.6
Cloud nativity is an approach in software development of growing importance, which utilizes cloud computing to create scalable applications in dynamic environments.
Cloud nativity's strength is to even function on an unknown system's
infrastructure without the need for operators to manually access it. There are several
de nitions of cloud nativity. As it ts our intended architecture the best, we will
refer to the one presented in [
Firstly, a cloud native system is resilient, when the failure of one component of the system doesn't cause other components to fail also. This is really valuable, as a chain reaction could take down the entire system.
The system is also agile, as quick changes according to new requirements can easily be made. A part of this capability is rooted in the architecture: the system consists of microservices and uses containerization for deployment. Containers are used to package all software needed into one executable package and should be provided using a continuous integration pipeline. This allows the project to be independent of the environment. Also, agile development approaches are used to enable quick reactions to changing demand.
The application should publish interfaces to administrate the application and by that provide operability. Using them, an administrator can perform con guration tasks or administration of users, without the need to rely on underlying systems.
And lastly, observability is given by the provision of information about ongoing processes, for example, health metrics and log data. 3
To realize the integration of cloud nativity with reference net simulations, we rst outline the shortcomings in the current architecture of Renew and its relevant plugins in regards to cloud nativity. We do so by covering the four aspects of observability, operability, agility, and resilience separately. To achieve a successful integration, the addressed problems need to be solved. From within each aspect, we will construct speci c requirements to be met.
Observability is mainly realized by the Remote plugin. The run of a single simulation can be observed through an additional client and the Java RMI protocol. This includes live transitions rings, markings, and an event log. System information and meta-information about the simulator are not included. Consuming the information requires an additional Renew simulator, which again requires an underlying Java virtual machine. Certain situations in a remote simulation, like deadlocks, can be observed manually by an observer knowledgeable in Petri nets, but not automatically.
We can now formulate the requirements for the integration: 1. The rst and most important goal is to introduce a universal interface for the aforementioned functionalities, that can be used without the need to rely on a local Java installation and Renew software. This also means to decouple it from graphical user interface components. 2. Observability should cover the entire distributed simulation, not just singular parts of it. 3. The environment (system resources) of a remote simulator should be observable through the interface.
Operability is also mainly realized by the Remote plugin. Upon attaching to a remote simulation the simulation may be halted, stepped, terminated, etc. This, however, is also only possible with a local installation of Renew and over Java RMI. To a degree, the Distribute plugin could also be used to "operate" a remote simulation by ring certain distributed synchronous (send) channels. The operation, however, is only implicit as it is only limited to the inner workings of the simulation itself. Operability was also not the intended use of the Distribute plugin and it would require an additional local Renew simulation.
Requirements regarding operability are therefore: 4. Operability also requires a more exible interface. This interface should be identical to the one from observability. 5. The simulator should be extensible by new net de nitions and not just net instances. Modi cation of existing net de nitions on the other hand potentially leads to non-trivial and large complications and therefore will not be addressed in this context. 6. The simulator should be extensible with additional functionality, that might be required to run speci c net de nitions.
Agility is available in several aspects of Renew. In regards to agile
development, Renew is developed using the Scrum@Scale approach4. It is also
integrated with extensive continuous integration support and by that using
automated pipelines for building. Concerning portability, the publication [
As the aspects are well covered through other works in the context of the Renew simulator, we can only express one requirement: 7. The simulator needs to utilize all the features referenced in the "Agility" section simultaneously.
Resilience is mainly relevant in regards to the distribution and inclusion of external services. The Distribute plugin is built on top of Java RMI and therefore requires a single RMI registry for all nodes in the overall deployment. The registry needs to be present during the start of each simulator participating in the simulation. It also must not disconnect during the simulation and net instances of past runs might still be known to the registry leading to inconsistencies. These problems can be alleviated by restarting the registry before an actual simulation, though. Further, relying on external services is not generally addressed on the simulator implementation level. This is due to the fact, that the ecosystem was more or less closed for external services so far. But introducing a exible and universal interface, as motivated earlier, opens the possibility to incorporate other external (web)services into the simulation runtime. These services should not be addressed directly, to avoid cascading failures or local corruption.
Overall we were able to de ne the following requirements for the resilience of a cloud native reference net simulation: 8. Failures of global system components must not lead to cascading failures. 9. Failures of local nodes must not endanger the overall simulation. 10. Simulation processes must not directly rely on external services, the structure of their delivered data, or on the quality of their delivered data.
In this section we will present the concepts we propose to address the requirements explained in the last section. We believe, that these su ce to achieve a thorough integration of cloud nativity and the reference net simulator Renew. The aspects observability, operability, and resilience will again be addressed one by one. As agility is already well covered, it will not be addressed separately in the conceptual section. An overview of the utilized tools and methods will follow in section 5, which will present our prototype.
We will design the overall system with the global architecture displayed in gure 1 in mind. Several aspects and necessities are only elaborated on further into this section, however, it will be helpful to deliver the bigger picture early on to explain some aspects more easily. Note, that speci c infrastructure elements, like physical nodes, are omitted in this diagram, as the goal of the combination of cloud nativity and the Renew simulator is an infrastructure-agnostic simulation environment in the rst place.
The gure shows several separate services, that are required or at least recommended in the deployment of cloud native Renew. Note, that this paper only discusses the cloud native Renew plugin, which is shown in bold font. However, to understand certain implications and design choices it is helpful to be able to see the bigger picture. Elements, that are drawn on top of each other, like for example the cloud native Renew plugin and the Renew simulation core are two parts of the same service, while separate elements are separate services. Not showing the infrastructure also implies, that these services can each run on a di erent machine or all together on one single machine or something in between.
Some of the prominent parts are the several Renew simulation cores, that are shown in green, alongside their orange colored plugins. There are just two Renew simulation cores depicted in the gure due to tidiness. As scalability is one of the claims for this contribution, it is intended to be run with much more than just two instances of Renew. The three dots on the right-hand side of the gure also indicate this.
As the cloud native Renew plugin is designed to o er an interface to incorporate external services, two of them have been drawn into the gure as an example. Note, that this is for future-proofness, as there are no incorporated external services as of now, as also mentioned in the approach section. For convenient access to all operability and observability aspects, the central pinkcolored control panel can be used. There is no speci c implementation of this for reference nets, but as we will show within the evaluation section, depending on the way the aspects of operability and observability are introduced into the simulation, ready-made tool suites can be used.
Further, one of the additional aspects is the distributed message broker shown
in light blue. It acts as the central message passing system in the deployment and
is mainly used by an updated Distribute Renew plugin. Additionally, there
are some special external services displayed and labeled as consumers. These are
able to extract information recorded by the Renew simulation cores from the
message broker and consume them in several individual ways. An example for a
consumer is a web-based GUI, like the one introduced for reference nets by [
Finally, at the bottom of the gure "Renew Petri net Saga executor(s)" are shown in light green. These are intended for eventual consistency in the distributed ring process and are described later on in more detail in section 4.3 about the introduction of resilience into the system. 4.1
The rst aspect to introduce is observability. Using Renew remote it is possible to use the Renew simulator to connect to a remotely running simulation. This is done using the Java RMI protocol and requires a local Renew simulator. While this solution provides excellent observability of a single simulation it does not provide a exible interface. This means, that some kind of Java environment is required to consume the interface. It also does not provide means to check on loaded plugins and system states of the remote simulation. Renew remote is also tightly coupled to the graphical user interface of Renew, which again relies on the existence of some kind of output screen, and by that, it might encounter unforeseen di culties in non-graphical container-based deployments.
To acquire a su cient degree of observability a universal interface is required to access speci c information. We argue that HTTP is a good choice in this regard, as it is in fact universally employed and wide-spread, stateless, and su cient in terms of expressiveness. All relevant system information, that is required by the control panel should be available. This includes memory consumption, available persistent space on the system, and processor load. As processor load might experience spiking during the invocation of the request to the information HTTP endpoint it is also desirable to be able to request average load within the last seconds. Also, general information on the healthiness of the process is of interest to be able to decide, whether the speci c simulation core might require restarting or even manual attention.
The application should present these kinds of health metrics within a single or multiple HTTP endpoints.
Reference net simulations on Renew can di er from each other in regard to the loaded plugins by the simulator. Incorporating an additional simulation node into a running simulation will only be successful if the node in question is aware of all used classes and is capable of the required functionality. It is not explicitly necessary to match the plugin pro le of the remaining simulation cores, but the simulator should provide a minimum baseline of capabilities to ful ll its role in the simulation. Therefore currently loaded plugins should be announced upon start on the message bus and also should be available as information to the control panel. Certainly, the plugins themselves might hold data, that is of interest like the core simulator plugin holds information over liveliness and net instance count of the simulation. A uni ed interface for plugins to supply this information is required for the internal passing of information from the plugins to the HTTP endpoint.
Finally, to be able to trace certain error states of the simulator, it would be desirable to acquire the stdout logging output of the application. Almost every infrastructure solution nowadays can supply these from the infrastructure itself, but to stay within the requirements of being totally independent on the underlying infrastructure, the simulator should also be able to supply its stdout log upon request.
The last and largest part to support observability of the simulation addresses the access to ring events of a running simulation. The remote plugin supplies this only for one simulator, but a global transparent simulation feed of the overall simulation is more desirable. Construction of a simulation feed for reference nets is not easy though. Due to the nature of the tokens, that, in fact, may be references to arbitrary Java objects, describing them is non-trivial.
As displayed in gure 1, displaying the global architecture, a central event log system will be available for external consumers and inter-simulation communication. This event log will store information about the simulation and will be fed by each individual simulator. Consumers then can access the log and display the simulation e.g. in a user interface or consume the process otherwise, like waiting for a certain transition ring. 4.2
As outlined in the approach section, the Remote plugin for Renew supports basic operability with the Java RMI protocol. In the last section, we have shown, that a web-based interface over the HTTP protocol will bene t the application in terms of exibility and requirements on the clients. Therefore we need to redesign the operability presented from within the Renew Remote plugin to match the new interface. A basic operability interface needs to at least provide means to start, stop, step, resume and terminate a simulation.
Further, in the context of service-based deployments, it will be desirable to extend a running service without the need to shut it down rst. Also, the supply of net de nitions to run should be possible easy. Renew utilizes a construct called shadow net systems. A shadow net is a net de nition, that is stripped from all of its information, that is non-critical for actual execution. Single or multiple shadow nets can form a shadow net system, which is a set of these. Shadow nets also o er the ability to run net compilers on nets to prepare them for execution. They also use binary serialization, when saved in contrary to regular reference nets, which use a text-based solution and are by that larger in size.
As a shadow net is independent of its graphical representation and holds all information to construct a net instance from it to execute, it perfectly ts for the supplying of running reference net simulator services with new net de nitions. It is also possible to verify a shadow net system at least for basic validity by parsing the shadow net system object structure, which we will do. The system should also be able to distinguish between submitting simulation candidates using shadow net systems and commands to actually instantiate a new simulation.
Net de nitions alone can o er the possibility to run the arbitrary workload on a remote and distributed reference net simulator. Reference nets are Turingcomplete and able to express any programmable functionality. However, often functionality can be reused, which is done in the shape of plugins for the simulator. Renew plugins can be compiled to jar les and can be loaded by the loader plugin, which is the central component of Renew.
An interface providing operability should be able to accept additional plugins, as well as loading them into the simulation code. We are aware of the security implications of this behavior, as a potential attacker could just upload malware and execute it most easily. This also applies to the upload of net de nitions, as they are Turing-complete, as stated before. As for now, however, we do not address this aspect in this contribution and assume all involved parties are trustworthy. For future versions, there is currently undergoing research and implementation work is done in our workgroup regarding net de nition signing and plugin signing prior to loading to tackle these problems.
While loading a plugin (or generally speaking a jar library) is straightforward in Java, unloading them is not. Therefore we need to assume, that supplied classes are not yet existent under the speci ed name (classpath). Unloading might become possible using the Java module system, which was outlined earlier.
Another aspect of operability is the in uence on the simulation environment.
As this has already been addressed in the publication [
One of the major concerns regarding resilience is the avoidance of single points of failure and the avoidance of cascading failures. As outlined earlier, the Distribute plugin is one problematic part, especially the used RMI registry and RMI calls. The left part of Table 1 shows what parts of the algorithms in the Distribute plugin use which approaches.
Approach so far
Algorithm part
New approach
Registry Direct via RMI call local
Net instance referencing
Firing
Binding Uni cation
Message broker Direct via HTTP local
We argue, that both, RMI registry and RMI calls can be replaced by using a stateless protocol like HTTP and a persistent message broker system, which is replicated (sharded). Stateless protocols demand much less constrained environments than Java RMI does. It also can be inspected more easily for debugging and monitoring considerations.
With the introduction of a message broker system, the referencing to remote
instances can be modeled just as with an RMI registry. The advantages are,
however, that using general message brokers can be accessed more exibly and
do not require a speci c running Java application. It also persists the net
instance information and does not require ongoing communication to the service
hosting the remote net instance. To di erentiate between separate simulations,
we propose to apply a UUID5 identi er to each simulation upon start. The
identi er is then passed to new simulation participants using the infrastructure (see
RenewKube [
Upon retrieval of remote net instances, the distributed binding search should be triggered over HTTP by directly contacting the Renew instance, that the net instance is hosted on. This can be done in an easy fashion, as binding search is a read-only operation 7. When a binding is found it can be red. The Distribute plugin uses RMI calls for this and by freezing the related parts, as described earlier, it e ectively handles distributed transition ring in a similar manner, as a distributed commit protocol. This behavior, however, introduces the possibility for cascading failures, or more likely non-responsiveness of several
are as low as 1 in 2122 and by that negligible.
plex and requires evaluation of possible bindings. It uses so-called state recorders to e ectively create an overall read-only operation. system components, once a badly timed outage happens during distributed ring. Therefore we argue to introduce an approach featuring eventual consistency and availability orientation.
One of these approaches is the Saga pattern [
This overall concept covers the challenges introduced by the Distribute plugin but external services are yet to cover. Upon relying on external services, the central processes of the simulator should never directly rely on the availability of the service or the integrity of the delivered data. Therefore we argue to introduce a convention to apply so-called Anti-Corruption-Layer (ACLs) in front of external services. These encapsulate the interface towards the service and behave in a deterministic and foreseeable way towards the core implementations. The bene cial aspects of this are stronger encapsulation of the external behavior and resilience against potentially malicious behavior of the service. 5
As outlined in the conceptual section, the implementation of the cloud nativity aspects requires the introduction of new functionality, as well as adjustments to existing functionality. Adjustments mainly address the Distribute plugin and resilience considerations along with integration problems with message broker systems. The implementation of both would exceed the scope of a single paper. Therefore, we only present an implementation for the introduction of new functionality, mainly regarding observability and operability. These are also the aspects, that serve as a foundation for the introduction of resilience later on.
Since the implementation of a web service is quite complex, we decided to use the Spring framework for our prototype. The procedure and problems that occurred, as well as their solutions, are described in the following sections. 5.1
Java Spring is a framework that is often used for web applications. In addition, Spring Boot is a variant of the framework that allows a "ready to run" version, with minimal features for web functionality, to be set up quickly. This further reduces the already shortened implementation time. Besides the faster implementation time, it is also much easier to integrate a Spring context into Renew than to implement all elements needed for a minimal web application. More on that in the "Integration with Renew " section. Because of the minimal version of Spring we are using, we can easily integrate all the features that Spring provides and add only the functionality we need. A currently used extension is Spring Boot Admin, which provides a control panel and an interface for health metrics. Other interesting extensions o ered by the framework include database integration and Object-Relation-mapping through Hibernate, as well as an integrated cloud architecture.
Java Spring also allows us to use the concept of dependency injection. This
concept gives the possibility of providing a kind of blueprint for objects of a
class that we can then pass to the required location. If an object of this speci c
class is needed, one can be inserted by injection of the required object [
As mentioned before we used the Java Spring framework which we integrated into Renew. Figure 2 shows that we put Spring in a separate module layer to create a system where Spring is integrated in Renew. This way we can guarantee that all Spring functionalities that do not support a module system can work without any problems.
In our attempt to integrate Spring with Renew, we created a new plugin and added a new Spring Boot project to it. After some adjustments to the module properties according to the Renew speci cations, we were able to identify two core problems.
Primarily all Spring modules and libraries were not present in the project. The problem comes from the fact that the Java module system is not thoroughly integrated into Spring and this con icts with the modular order given by Renew. Furthermore, Spring Boot creates a fat jar that contains all dependencies and necessary libraries if Spring is a standalone application. However, the Renew loader can do little with it. To integrate the contents in the build process of Renew we made adjustments to the location settings, where we were able to place the contents of the fat jar separately where Renew organizes the modules and libraries.
The other problem occurs after deploying the required modules and libraries, Spring does not have access to them. Due to the module layer structure, the dependencies for Spring and our module are on di erent layers, and thus cannot have access to each other. Our solution was to implement a new module layer only for Spring and its required modules, as shown in gure 2.
Since for many internal Renew operations, certain outputs or errors are issued for certain behavior, we had to introduce a system in which we can react to various internal events. Generally, we use the HTTP status codes, as well as a JSON response with more detailed information as return value for each request. We obtained this by implementing our own response class that provides reliable responses independent of the internal Renew process.
To ful ll observability aspects, we implemented a log output and a status overview as a health metric. For the implementation of the log output, we redirected the two Java output streams System.out and System.err, and formatted the contents of the streams for the respective endpoints. The health metrics are provided by Spring Actuator and include simple information about the system where Spring, i.e. Renew, is running on. After some additions to this given implementation, it is now possible to receive information like memory, CPU usage, RAM usage, and their corresponding averages about the host system. Furthermore, we also provide an overview of all loaded Renew plugins and created another plugin that acts as a communicator between all other Renew plugins and Spring. This new plugin gives all components the ability to display a message in the health metric. We decided to create a new plugin for this because if we had provided this functionality in our cloud native layer, there could be a circular dependency on plugins in the module system. Another solution would have been to integrate it directly into the Spring plugin, but then Spring would need to know the implementation details of the plugins it uses. However, both other approaches are in contradiction to the architecture of Renew.
In consideration of the operability aspect, we have created a possibility to upload reference nets, as well as a way to control these nets. When uploading the nets, we accept a le and check whether it is the correct le format by attempting to parse its shadow net structure. If this is the case, the le is deposited in the appropriate path. We also implemented an endpoint to upload additional Renew plugins, which then can be loaded into the running simulator at runtime. As outlined earlier, we do not check for malware yet in both cases. For the control of the simulation, we currently provide four commands: "run" for starting a simulation, "step" for stepping a simulation, "stop" for stopping a simulation, and "term" for terminating a simulation. Here we used the given functionality of the simulator plugin in Renew and mapped them to the corresponding HTTP endpoint. A key problem is that at the time of receiving the request and sending a corresponding response, only the submission of the command into the simulator can be guaranteed, due to the multi-threaded and concurrent behavior of the simulation core of Renew. 6
For evaluation purposes, the implementation was run on a physical machine running Windows 10 20H2 with 32 GB memory and an AMD Ryzen 9 3900X 12-core CPU. The speci c evaluation criteria introduced in section 3 were used. As motivated earlier, we have split the implementation between the cloud native Renew plugin and the upgrades to the Distribute plugin. As the latter is addressed in another upcoming contribution, the evaluation also only covers the aspects realized within the cloud native Renew plugin itself. The implementation of the cloud native Renew plugin can also be downloaded from the projects website8. An overview of the ful lled requirements can be found in table 2. 9
10 Ful lled?
X X X X X X X (X) (X) (X)
With the implementation, the simulation can be run on a server. It is possible to use the endpoint "/simulation/start" to start a simulation over HTTP. It is not required to have a local installation of Renew or Java to do so, but it is still necessary to have any HTTP client installed. We thereby meet requirement 1. The simulator also supports control of the simulation via the respective endpoints. Commands to control the simulation can be submitted via HTTP, which ful lls requirement 4. Further, it is possible to upload new net de nitions as shadow net system, which subsequently can be instantiated with the start simulation endpoint, ful lling requirement 5. Additionally, Renew plugins can be uploaded and loaded during runtime through the web interface, ful lling requirement 6.
Health metrics can indicate the correct functioning of the simulator. We enriched these with environment information (meeting requirement 3) and a means for di erent parts of the application to present custom status data. As each simulator implements these endpoints, we can use a centralized monitoring system to access all states simultaneously, ful lling requirement 2. For our evaluation, we ran the tool-suite Spring Boot Admin to consume the endpoints emitted by the simulators. The tool-suite corresponds to the "Control Panel" in gure 1. A view of the user interface of Spring Boot Admin for our simulator is visible in gure 3.
The evaluation of the agility aspects of requirement 7 is not straightforward,
as it requires other dependent projects. Mainly the contribution presented in [
The remaining requirements can be evaluated in regards to the cloud native Renew plugin on its own, but are more interesting when applied to the upcoming redesign of the Distribute plugin, as it is the central part, that is in need of resilience optimizations. However, for completeness, we consider them in the context of the cloud native Renew plugin as well. As the endpoints are emitted regardless of other components, failures (including the control panel) do not a ect other components (requirement 8) and the simulation (requirement 9). As there are no incorporated external services yet, requirement 10 is ful lled trivially.
Overall we could achieve a very solid detachment from local system access, resulting in a reference net simulator, that is well suited to be run in cloud environments. Upon completion of the remaining projects addressed throughout the evaluation and paper, a thorough evaluation in a real cloud environment can be conducted. The outlook section 7 will point to follow-up research topics in this regard. All shown limitations refer to our implementation. When using the simulation controls, there is currently no feedback about the success or failure of the operation. This is due to the concurrent nature of the simulator and the fact, that HTTP server calls should not be implemented in a blocking fashion. Later this can be solved using polling, webhooks, or websockets.
Detailed feedback about the simulation run is also not yet available in the shape of a simulation feed. This also has implications on the Distribute plugin, as distributed ring and recording of rings share similarities and should be implemented together.
There is also no cleanup mechanic implemented yet. Therefore very long
runs of plugins might require restarting of the containerized application to free
up space. This can be achieved using RenewKube [
Overall the contribution resembles groundwork for scalable applications, by having a simulator, that can be run without machine-local interaction and without need to access the underlying system. These aspects enable all kinds of automation, by accessing respective endpoints. While introducing an increased complexity, the interfaces are now much more streamlined and consumable by a variety of tools.
Within the prototype implementation new dependencies on third party libraries have been introduced, to severely speed up the development process and to avoid repeated work on solved problems at the risk of the possibility of discontinuation of said dependencies. The method also introduces an overhead in generating messages on the universal interface. However, as it also paves the way for scabale applications, this e ect is expected to be compensated by the now possible sizes of reference net applications.
In the larger context of the multi-agent applications mentioned in the motivation section, the cloud native plugin for Renew will serve as essential platform extension to enable interoperability with an abstract platform management (compound) system. 7
The conceptual integration of the cloud nativity paradigm into the Renew simulator for reference nets was presented. While cloud nativity is a heavily used term, especially in marketing departments, the here used interpretation is based on the concepts of operability, observability, agility, and resilience. Necessary changes to the architecture have been motivated and include the introduction of an HTTP-based interface for monitoring and control features, the usage of agile development, deployment via CI/CD, and usage of containerization. An implementation of the aspects relevant to the here presented "cloud native plugin" for Renew has been presented. It includes most of the observability and operability aspects. Within the evaluation, it was shown, that the implementation met all the relevant requirements. Overall we could provide a future proof improvement over the dated Renew Remoting plugin and related solutions.
Further work will include the implementation of the aspects concerning other
projects with relations to cloud native Renew, especially those regarding the
Distribute plugin and resilience aspects. Additionally, overall integration of all
related projects (Resilient Distribute, Petri net Sagas, RenewKube [