# A Comparative Assessment of JVM Frameworks to Develop Microservices
## 3 Materials and Methods
### Adopted Model of Application  
The mentioned earlier evident lack of an adopted model for the application that would be widely used in the research community for comparative analysis has shown an apparent need to provide some standard for the application model and tests being carried out. These factors and the need for evaluation of the frameworks in the context of this paper influenced the preparation of own model for the testing application ([[https://github.com/latusikl/jvm-frameworks-comparative-assessment](https://github.com/latusikl/jvm-frameworks-comparative-assessment)]([https://github.com/latusikl/jvm-frameworks-comparative-assessment](https://github.com/latusikl/jvm-frameworks-comparative-assessment)), accessed on 30 December 2022).  
The application model definition was based on the API specification (in OpenAPI 3.0 format) that should be implemented in the microservice created with the given framework. A graphical representation of the API description is presented in Figure 1. All of the 11 endpoints provided in the specification can be divided into 4 main categories.  
The first category is so-called \"Greeting Operations\". It is a set of simple HTTP GET requests and Server-Sent Events that return the greeting message. The purpose of this category is to check how the application behaves during the load generated by operations that do not demand a noticeable amount of computing resources and do not need external resources such as data from other microservices, database access, queuing systems utilisation, etc.  
The second category is called \"Sorting Operations\". It is represented by a single endpoint that allows executing sorting of Integer arrays using one of three implemented sorting algorithms that have the same average time complexity:  
* Quicksort,  
Figure 1: Graphical version of API description.  
* Merge Sort,
* Heap Sort.  
The purpose of this operation category is to check how a given application behaves in case of a synchronous request that requires the execution of calculations that demands a noticeable amount of time and computational power.  
The third category, \"Notes Operation\", is a set of two endpoints that allows the creation and retrieval of the encrypted note using the AES (advanced encryption standard) algorithm. After encryption, note content is stored as a file in external object storage, e.g., AWS S3 or Google Cloud Storage. A note is saved and retrieved by executing HTTP requests between tested microservice and external resources using the framework's HTTP client.  
The goal for this category is to evaluate provided by the framework's HTTP clients that allow the execution of external calls. In the case of the system in the microservice architecture it plays a meaningful role and is commonly used to communicate with other parts of the system.  
The last category, \"Database Operations\", is a set of CRUD (create, read, update and delete) operations that give the possibility to manage a simple entity that contains primary user data. This operation involves the usage of an external resource--a data store. A relational SQL database was used for tests in favour of the NoSQL one. SQL databases are still one of the most commonly used and most popular, and even they are reincarnated with the NewSQL trend [30].  
The purpose of this category is to check how the frameworks handle object-relational mapping and database communication, as almost every microservice will probably involve some data persistence.