## 4 Architecture of the Application and Implementation of the Solution  
This research aims to help developers choose the best combination of components depending on their use case, by providing actual results using different sizes of records in scenarios. Each combination will be a separate and independent project, as they must not interfere with each other. This way, a safer evaluation can be conducted. In the future, it can be changed to choose the corresponding framework configuration file and to execute the specific test, because the entities that the solution exposes are used in all the different approaches. Code reuse can be achieved through this method of development, which is a great principle for an application. All implementations must follow a standard for the data model because, otherwise, the results might become irrelevant. The standard is the Java Persistence API, on top of which all the selected frameworks are mapped. The solution is based on two main components: the ORM framework and the RDBMS. The responsibility of the ORM framework is mapping Java objects and database models. Also, it controls the flow of data between the application and the database [38]. For testing purposes, the chosen framework was JUnit [39]. This is the most popular testing extension in the Java community. JUnit 5 introduced modular architecture, which brings only the necessary dependencies into the testing code, making it smaller and more efficient. It is constantly being updated by the team that develops it. The tests are easily extendable using third-party extensions, and for this, it was particularly useful to add the Spring extension, in the context of the Spring Data JPA tests. To improve the testing, Java Microbenchmark Harness (JMH) [40] was added to the project to check if warming-up the Java Virtual Machine will reduce the execution times. It can also be used for extracting code optimization paths or measuring the execution of different methods. The architecture of the testing application is described in Figure 1, demonstrating how different combinations of the implementation are created:A combination that will be subject to testing is represented by one component from the left side (ORM framework) plus one on the right side (RDBMS), both with and without warm-up. The color legend is as follows:  
* BLUE \(\rightarrow\) JPA with all RDBMS;
* GREEN \(\rightarrow\) Hibernate with all RDBMS;
* ORANGE \(\rightarrow\) Spring Data JPA with all RDBMS. Each testing scenario is mapped with an arrow. This way, all the possibilities of these technologies are covered, and it provides more reliable results. The Java application can be considered the central part because it is the entry point from which the project will start. The current research expands on our previously published papers, looks for optimization possibilities, and investigates the critical regions. The application we designed represents a soccer betting service model. The user can create a different number of tickets, each with bets and corresponding matches. The entities of the project are ticket, bet, and match. Figure 2 presents the data model with the relationship between entities. There are a single-to-many relationships between match and bet. Figure 3 shows the data model in use for testing. Figure 1: Research methodology. Figure 2: Testing architecture including the combinations framework—RDBMS. The tables have several attributes:  
* Ticket. * Ticket id -> the unique identifier for a ticket;
* Status -> one of the following values: WON (if all the bets are successful), LOST (if at least one bet is wrong), PENDING (otherwise);
* Sum -> represents the amount placed on the ticket as the betting value. * Bet. * Bet id -> the unique identifier for a bet;
* Match id -> the identifier of the match the bet is placed on;
* Ticket id -> the identifier of the ticket the bet belongs to;
* Result choice -> one of the following: 1 (host wins), 2 (visitor wins), X (even).