Journal of information and communication convergence engineering 2023; 21(4): 268-280
Published online December 31, 2023
https://doi.org/10.56977/jicce.2023.21.4.268
© Korea Institute of Information and Communication Engineering
Correspondence to : Jaewon Oh (E-mail: jwoh@catholic.ac.kr)
School of Computer Science and Information Engineering, The Catholic University of Korea, Bucheon 14662, Republic of Korea
This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons.org/licenses/by-nc/3.0/) which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited.
Several companies have migrated their existing monolithic web applications to microservice architectures. Consequently, research on the identification of microservices from monolithic web applications has been conducted. Meanwhile, the use-case model plays a crucial role in outlining the system’s functionalities at a high level of abstraction, and studies have been conducted to identify microservices by utilizing this model. However, previous studies on microservice identification utilizing use-cases did not consider the components executed in the presentation layer. Unlike existing approaches, this paper proposes a technique that considers all three layers of web applications (presentation, business logic, and data access layers). Initially, the components used in the three layers of a web application are extracted by executing all the scenarios that constitute its use-cases. Thereafter, the usage rate of each component is determined for each use-case and the component is allocated to the use-case with the highest rate. Then, each use-case is realized as a microservice. To verify the proposed approach, microservice identification is performed using open-source web applications.
Keywords Monolithic applications, Microservices, Microservice identification, Use-cases, Web application reengineering
These days, there has been a continuous increase in the amount of data that needs to be processed by web applications (web apps), and the requirements for web apps are becoming more and more complex [1]. Under these circumstances, the modularization of web apps makes it easier to maintain increasingly complex web apps, and it can improve their performance [2]. Hence, various approaches, such as a method to partition web apps into layers [3] and a method to transform web apps into service-oriented architectures [4], have been proposed as methods for the modularization of web apps [4-19]. In addition, to achieve modularization, several companies (including Netflix, Amazon, and eBay) have recently migrated their monolithic web apps to microservice architectures [5]. In this context, the term
Hence, to alleviate the difficulties in the transformation process, research has focused on methods to automatically identify microservices within monolithic web apps [9-16,18, 19]. However, in many prior studies, components such as database tables and views in the data access and presentation layers of web apps were overlooked in the identification of microservices. As a result, existing techniques were not sufficient to ensure that each of the identified microservices can properly perform its function as a web app.
To address these problems, this paper proposes a method for transforming monolithic web apps into microservice architectures by achieving the following three research objectives.
Microservice identification utilizing the use-case model: To transform a monolithic web app into a microservice architecture, it is essential to determine the parts of the web app that are converted into microservices. The main goal of this transformation is to ensure that each identified microservice provides a single function. To accomplish this, we utilize a use-case model outlining the functional requirements of a system. In other words, our approach extracts a use-case model from a monolithic web app and maps each use-case to a microservice.
Identification of microservices composed of all three web app layers: A web app generally comprises three layers: presentation, business logic, and data access [20]. Similarly, when constructing a web app based on the microservice architecture it is essential to ensure that each microservice can function as a small independent web app [6]. Consequently, each microservice must encompass all components running in these three layers for complete web app functionality. Considering this aspect of microservices in the identification process, this paper introduces a microservice identification technique that, through dynamic analysis, considers all components executed in the three layers of web apps. It ensures the inclusion of these components in the identified microservices. It is worth noting that, unlike prior studies utilizing use-cases for microservice identification, this paper accounts for components executed in the presentation layer.
Evaluation: To assess the applicability and effectiveness of the proposed technique, it is essential to compare it with various existing microservice identification techniques. The comparison between our approach and existing methods is made using five types of open-source web apps. Additionally, an evaluation is conducted using an accuracy metric widely used in machine learning.
This paper makes the following contributions by accomplishing the aforementioned research objectives. First, it decomposes a monolithic web app based on its functions by utilizing use-cases for microservice identification. Second, all three layers of the web apps are considered. Third, this paper demonstrates that our approach outperforms existing methods.
The remainder of this paper is organized as follows. Section II describes related studies. Section III presents a method for microservice identification. In Section IV, the effectiveness of our approach is evaluated. Finally, Section V provides conclusions and directions for future research.
According to a related study [7], microservice identification methods or Service Identification Approaches (SIAs) can be divided into six types: wrapping, genetic algorithms, Formal Concept Analysis (FCA), clustering, custom heuristics, and general guidelines. In particular, clustering and custom heuristics have been the preferred approaches in recent studies [7].
In SIAs, microservices can be identified using various input data. In [7], the input data were classified into three categories: executable models (source code, databases, etc.), non-executable models (execution traces, use-cases, etc.), and domain artifacts (ontologies, documents, etc.).
Our approach uses classes, tables, and views as executable models, and execution traces and use-cases as non-executable models. Consequently, it is necessary to review studies that utilize these two types of models.
First, studies that identify microservices using use-cases include the following. Dmitry et al. [12] introduced a method using use-cases to partition a monolithic web app into components with a single function. This technique is similar to ours, as it identifies microservices by dividing web apps based on use-cases. However, their method lacked evaluation using real web apps, and it did not account for tables and views.
In a study by Bajaj et al. [13], relationships between usecases and those between use-cases and tables were extracted. The relationships were then analyzed to identify microservices. However, as this technique focuses on microservice identification at the use-case level, it does not take into account classes and views.
In the approach presented by Tyszberowicz et al. [15], the functional requirements of the system were analyzed using use-cases. Based on this analysis, they proposed a method for identifying microservices by partitioning web apps by function. This method is similar to our approach in that it considers tables in the process of identifying microservices. However, they did not consider views such as JSP.
Furthermore, Kalia et al. [18] proposed a method to extract execution traces based on use-cases and subsequently analyze the traces to depict the call relationships between classes in a graph. This study is similar to our approach in that class information is obtained from execution traces. However, their method is constrained since table and view information cannot be obtained.
Second, it is necessary to review studies that consider not only classes but also tables and views. Some previous studies [9-11,21-23] considered both classes and tables to identify microservices.
Levcovitz et al. [9] introduced a method to represent components including database tables and business logic, and call relationships between components, in the form of a graph through static analysis of monolithic web apps. A limitation of their approach, in contrast to ours, is the inability to identify dynamically generated tables due to its reliance on static analysis. Moreover, it does not consider cases where multiple microservices share tables.
Kamimura et al. [10] proposed a method to represent classes and tables as nodes and call relationships between nodes as edges through static analysis of the source code of web apps. This technique considers only web apps that use Object Relational Mapping (ORM1) in the process of identifying tables; therefore, it can not be used to identify tables in the case of apps not using ORM.
Mazlami et al. [11] presented a method for utilizing the information from version control systems to identify microservices. Their approach generates a graph where classes and tables are nodes, and the relationships between nodes are edges. The graph is then clustered to identify microservices. At that time, edges are generated based on the change history of classes obtained from the version control system, from information on contributors who changed the classes, or from information on source code similarity between classes obtained by static analysis of the source code. However, this method is limited to apps using ORM, rendering it unable to identify tables in apps without ORM.
Del Grosso et al. [21] proposed a technique to identify microservices by dynamically extracting SQL queries to obtain database tables and fields and clustering the queries with the obtained information. This method is similar to ours in that it uses dynamic analysis to extract SQL queries. However, because their approach identifies microservices using only SQL queries, it does not consider classes and views.
Recent studies [22,23] have expanded their focus beyond classes to include tables and views. These studies highlight that certain components in web apps are overlooked by existing microservice identification methods. Thus, those studies proposed the following process to solve the problem. In the first step, any existing microservice identification method is executed. In the subsequent step, the components not considered by the existing method are classified as microservices by reusing the identification results of the previous step. The tables and views are classified in the subsequent step. While these studies directly classify all components into microservices, these studies reuse the results of other microservice identification techniques for this classification. In addition, these studies statically analyze the source code, unlike this paper.
This paper introduces a method for transforming a monolithic web app into a microservice architecture where each identified microservice functions as an independent web app with its unique purpose. A use-case represents a function provided by a system at a high level of abstraction from the user’s perspective [12,13]. Therefore, this paper proposes a microservice identification approach that realizes each usecase as a microservice.
As depicted in Fig. 1, the proposed approach consists of three steps: identifying use-cases and their scenarios, extracting components based on these scenarios, and clustering the components according to the use-cases. In this figure, the system consists of two use-cases (
A use-case is a set of scenarios, each of which is a series of steps through which a web app is used. Consequently, the identification of use-cases also requires the identification of their scenarios. This paper proposes the following method for identifying use-cases and their scenarios.
First, use-cases and their scenarios can be statically identified by referring to the web app documentation. Documents for web apps can be found in various locations. For example, for open-source apps publicly available in an open-source repository (e.g., GitHub2), a file with a description of the web app (e.g., HELP.html and README.md) is sometimes provided. In such cases, use-cases and their scenarios can be identified through static analysis of the file.
Fig. 2 shows the process of extracting use-cases by referring to the HELP.html file in the open-source web app called JPetStore63. The use-case called
Second, use-cases and scenarios can be dynamically identified through the execution of a web app. Analyzing documents for the extraction of use-cases and scenarios may encounter limitations due to insufficient information in the documents or the absence of relevant documents. In such cases, use-cases and scenarios can be identified by executing a web app.
For example, in the scenario identification step of Fig. 2, the
A scenario is one of the operational flows within a web app. Thus, an execution trace can be extracted for each scenario. In this context, the execution trace refers to a list of components used during scenario execution. The Aspect Oriented Programming (AOP) technique [24,25] can be used to extract such execution traces. As shown in Fig. 3, when employing AOP in Java web app, execution traces can be generated by detecting the execution of the classes and methods constituting the web app. In this figure, the web app consists of components (
AspectJ [24] is one of the technologies supporting AOP in Java apps and is a library that can be used to extract execution traces. As shown in Fig. 4, the execution traces can be extracted by adding to a Java web app the special construct called an
When executing a
This paper considers database tables in the data access layer of web apps. For this purpose, it is essential to identify tables accessed during the execution of the scenarios.
In general, we can obtain information on tables by analyzing SQL queries. The methods used to generate SQL queries in web apps can be divided into three types. First, it is possible to completely generate SQL queries at compile time if the developer directly writes them in the source code. Second, while an app is executed, SQL queries can be dynamically generated by utilizing user input. Third, SQL queries can be statically or dynamically generated using database frameworks (e.g., MyBatis4 and Spring Data JPA5).
Regarding the above methods, approaches to extracting SQL queries can be divided into two types. The first method uses static analysis. In a study by Meurice et al. [26], static analysis of source code was performed to identify a method of a class that accesses database tables. The SQL query, treated as a value in the method argument, is then statically extracted. There is a limitation in the technique proposed by Meurice et al., which assumes the source code includes static information on tables; therefore, it does not consider cases in which tables are dynamically generated.
The second type of approach uses dynamic analysis. In a study by Cleve et al. [27], the execution of a method of a class used to access database tables was identified, and the argument value of this method was dynamically extracted to obtain a SQL query. If this approach is used, cases in which tables are generated dynamically can be considered.
Our approach is a dynamic analysis technique. Nevertheless, it is different from the study by Cleve et al. in that our approach considers cases in which SQL queries are generated by using database frameworks.
According to one previous study [28], most Java database frameworks are implemented based on the Java Database Connectivity (JDBC)6Application Programming Interface (API); therefore, access to tables can be discerned by tracing the execution of the JDBC API. In our approach, AspectJ is used to detect the execution of classes. Similarly, to detect access to tables, the JDBC API with a SQL query as its argument is specified within the pointcut of the aspect class. Subsequently, when the execution of this API is detected dynamically, the SQL query used as the argument value of this API can be extracted. These JDBC methods can be found on the website for Kieker7, one of the dynamic analysis tools.
Line 2 in Fig. 5 shows the class
Our approach uses line 6 of Fig. 4 to detect the
Web apps generally employ views to display the outcomes of business logic. In Java web apps, views can be written using two methods. The first is the standard method of utilizing JSP and HTML. The second uses presentation frameworks (such as Stripes9).
Therefore, to identify views, it is necessary to use a technique that is suitable for the presentation method applied to web apps. In this paper, the following two approaches described below are used to identify views.
First, when employing JSP and HTML in a standard Java web app, views are identified as follows. The JSP is executed after being converted into a servlet class by the web server. Since the final JSP form is a servlet class, the JSP can be identified if the final servlet class is specified within the pointcut of the aspect class, as shown in line 5 of Fig. 4.
HTML can not be identified using AspectJ because it is not a Java class. In this case, the interceptor pattern [29] can be used to detect HTML. In other words, this pattern allows the interceptor written as a Java class to run before HTML page
Second, in web apps that employ presentation frameworks such as FreeMarker10, a distinct class method is used to execute JSP and HTML. By specifying this particular method within the AspectJ pointcut, views such as JSP and HTML can be identified. For instance, in FreeMarker, the
In JPetStore6, which uses Stripes as its presentation framework, the constructor of the
In this paper, each use-case is realized as a microservice. Specifically, the clustering of a web app’s components is conducted based on its use-cases, and a set of components belonging to each cluster (i.e., a use-case) is implemented as a single microservice. In this phase, to identify the components that belong to microservices, this paper uses information obtained in Section Ⅲ.A and Ⅲ.B, defined as follows.
Definition 1: The information used for microservice identification is as follows.
-
-
-
-
This paper assumes that a microservice should serve a single function; hence, it is considered an appropriate approach to separate the components based on use-cases. From this perspective, the method for allocating components to usecases is shown in Fig. 6.
This algorithm computes the usage rate of each component for each use-case and allocates the component to the use-case with the highest usage rate. The usage rate of a component for a use-case is determined by the ratio of scenarios using the component within the use-case (see line 5 in Fig. 6). For example, for a specific use-case, if a particular component is used in all scenarios belonging to the use-case, the usage rate is one and if the component is used in half of the scenarios, the usage rate is 0.5. A high usage rate of a component for a use-case indicates that the component is a key component of the use-case. Thus, the usage rate serves as an appropriate criterion for allocating a component to the specific use-case.
If two or more use-cases have the same usage rate (lines 11-16), the number of times the component is used is calculated, and the component is allocated to the use-case with the most uses. The number of uses of a component for a usecase is the number of scenarios in which the component is used from among all the scenarios constituting the use-case.
If the number of uses is primarily considered, rather than the usage rate, even though a component is used in all the scenarios of use-case
Fig. 7 illustrates a segment of the microservice identification process for JPetStore6. To determine the appropriate use-case for allocating the
This section describes experiments conducted to evaluate the proposed approach. It addresses the following research questions.
RQ1: Is our approach more effective than existing methods?
RQ2: Are tables and views appropriately allocated to microservices?
The performance of the proposed approach was assessed using the open-source web apps listed in Table 1. These apps were chosen for several reasons. First, they are publicly available in well-known open-source repositories, and JPetStore6 and PetClinic have been used in previous studies [10,11,14, 18]. Second, they were selected to evaluate the effectiveness of our approach across different types of web apps (e.g., JPet- Store2, JPetStore6, PetClinic) using various frameworks as well as standard Java web apps (e.g., ShoppingApp). Third, because PetClinic is an open-source web app with a microservice version currently available, it enables an objective evaluation of the results of microservice identification.
Table 1 . Subject applications
Name | The number of components: Class(LOC), View(Type), Table | Technologies used: Application framework, Presentation framework, Database technology | Number of use-cases | Number of scenarios | Description |
---|---|---|---|---|---|
JPetStore2a) | 48(1602), 21(JSP)&2(HTML), 13 | Springb), Spring Web MVCc), iBatisd) | 4 | 30 | Shopping mall for pet animals |
JPetStore6 | 24(1406), 20(JSP)&2(HTML), 13 | Spring, Stripes, MyBatis | 4 | 28 | Shopping mall for pet animals |
PetClinice) | 25(782), 12(HTML), 7 | SpringBootf), Thymeleafg), JPAh) | 3 | 21 | Animal hospital management system |
ShoppingAppi) | 22(1353), 13(JSP), 4 | N/A, N/A, JDBC | 4 | 21 | Fashion shopping mall |
DayTraderj) | 108(10376), 24(JSP)&19(HTML) &15(XHTML), 6 | N/A, N/A, JPA | 5 | 46 | Stock trading system |
c)https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/mvc.html
In this paper, we evaluate the effectiveness of our approach by comparing it to multiple baseline approaches. The approaches compared with our proposed technique are described below.
MEM: This technique introduced by Mazlami et al. [11], operates by taking a monolithic web app uploaded to a version control system, such as Git11, as input. The resulting output is a graph representing classes as nodes and illustrating relationships between nodes as edges. In the graph, edges are generated based on the change history of classes obtained from the version control system, information on the contributors who modified the classes, or information on the source code similarity between classes that can be obtained by static analysis. Following the generation of this graph, Kruskal’s algorithm [31] is employed to derive a Minimum Spanning Tree (MST) [32] for microservice identification. In the experiment described in this paper, edges were generated using information on source code similarity.
Bunch: Introduced by Mitchell et al. [33], this technique initiates by extracting call relationships between components at the source code level through static analysis of a web app. Subsequently, a Module Dependency Graph (MDG) is generated based on the results. This MDG represents components as nodes and represents the relationships between components as edges. Then, using the MDG as input, clustering is performed using the Hill-Climbing algorithm [34] to identify microservices.
Mono2Micro: Introduced by Kalia et al. [18], this technique initiates by extracting execution traces based on usecases. These traces are analyzed to represent call relationships between classes in the form of a graph. Clustering is then executed using a hierarchical clustering algorithm [35] for microservice identification.
Our task in this paper is to cluster multiple components of a monolithic web app into two or more microservices. This problem can be regarded as a multiclass classification problem for classifying each component as one of multiple microservices.
To assess the quality of the identified microservices in web apps, it is crucial to establish the ground truth. The performance of identification algorithms is evaluated by comparing their results against the ground truth. The method used to generate the ground truth is detailed in the following section. In terms of evaluation metrics, this paper utilizes the accuracy metric [36], which is commonly used to evaluate the performance of multiclass classification algorithms.
The ground truth in this study resulted from the identification of microservices based on their functions through the expertise of web app professionals, utilizing both static and dynamic analyses of monolithic web apps. The process of generating ground truth is as follows. Web app experts are divided into two groups. The first group identifies microservices. The second group verifies the identified microservices. These two groups repeat the above steps until they agree on the result of the microservice identification task.
In this paper, ground truth is represented as
-
Finally, the accuracy [36] for the entire microservice app is defined as follows:
Accuracy: the ratio of correctly classified components in
It is necessary to evaluate the effectiveness of the proposed approach through a comparison with existing approaches.
Therefore, the evaluation was conducted as follows:
Microservice identification was conducted using four types of techniques: the proposed approach, MEM, Bunch, and Mono2Micro. Only the proposed approach considers tables and views; the other three do not. However, to compare the four approaches more appropriately, all the components unclassified by these algorithms were randomly allocated to microservices. Following this adjustment, the accuracy of the identification result from each method was measured to evaluate the quality of the identification method.
Table 2 presents the results. Below the name of each web app in this table, the total numbers of components, classes, views, and tables classified as microservices are listed. However, these numbers differ from those listed in Table 1. This difference arises due to the inability to categorize some components into specific microservices. These components have the following characteristics. These components are the basic components that each microservice should have. For example, the
Table 2 . Comparison of our approach with baseline approaches
Approach | Web app (Total number of components, Number of classes, Number of views, Number of tables) | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
JPetStore2 (73, 44, 16, 13) | JPetStore6 (53, 23, 17, 13) | PetClinic (32, 18, 7, 7) | ShoppingApp (37, 21, 12, 4) | DayTrader (131, 85, 40, 6) | ||||||||||
Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | |||||
Mono2Micro | 48, 38, 3, 7 | 0.66, 0.86, 0.19, 0.54 | 30, 18, 8, 4 | 0.57, 0.78, 0.47, 0.31 | 15, 10, 4, 1 | 0.47, 0.56, 0.57, 0.14 | 21, 16, 4, 1 | 0.57, 0.76, 0.33, 0.25 | 58, 46, 10, 2 | 0.44, 0.54, 0.25, 0.33 | ||||
Bunch | 45, 37, 5, 3 | 0.62, 0.84, 0.31, 0.23 | 29, 19, 6, 4 | 0.55, 0.83, 0.35, 0.31 | 20, 14, 3, 3 | 0.62, 0.78, 0.43, 0.43 | 20, 14, 5, 1 | 0.54, 0.67, 0.42, 0.25 | 58, 45, 10, 3 | 0.44, 0.53, 0.25, 0.50 | ||||
MEM | 35, 25, 4, 6 | 0.48, 0.57, 0.25, 0.46 | 25, 13, 8, 4 | 0.47, 0.57, 0.47, 0.31 | 17, 11, 3, 3 | 0.53, 0.61, 0.43, 0.43 | 15, 11, 3, 1 | 0.41, 0.52, 0.25, 0.25 | 59, 45, 12, 2 | 0.45, 0.53, 0.30, 0.33 | ||||
Proposed approach | 59, 35, 13, 11 | 0.81, 0.80, 0.81, 0.85 | 46, 20, 15, 11 | 0.87, 0.87, 0.88, 0.85 | 27, 16, 7, 4 | 0.84, 0.89, 1.00, 0.57 | 30, 17, 10, 3 | 0.81, 0.81, 0.83, 0.75 | 83, 50, 27, 6 | 0.63, 0.59, 0.68, 1.00 |
The
Because the existing approaches consider classes only, the performance of the proposed and existing approaches are first compared from the class component perspective. The
The performance of the proposed approach and existing approaches can be compared from the view component and the table component perspectives. The
For ShoppingApp, JSP is employed for views, and the business logic accessing tables is written in the JSP source code. These features pose a challenge for techniques that do not consider views, as they can not gather information on the business logic embedded in the JSP. However, our approach allows us to obtain better identification results by considering these views. Table 2 shows that the
For DayTrader, the
Consequently, some classes or views are not executed in DayTrader, leading to the proposed approach being unable to classify these components accurately as microservices. If static analysis techniques such as the Bunch and the MEM are used, components related to unexecuted use-cases and scenarios can be identified. However, the Mono2Micro and our approach, which are both dynamic analysis techniques, can not identify the components mentioned above. Consequently, our approach exhibits a lower performance in the DayTrader experiment compared to experiments on other web apps. Nevertheless, in the DayTrader experiment, the
The performance described above, assessed in comparison with the ground truth identified by web app experts, indicates that the microservice apps identified using our approach align closely with those identified by experts from a functional perspective. In short, our identification technique can properly partition web apps by function, as intended by experts. The experimental results described above indicate that the proposed approach can be effectively used to identify microservices.
It is crucial to assess whether tables and views are assigned appropriately to microservices when those microservices are identified using the proposed approach. To conduct this evaluation, experiments were conducted as described below.
The components of the five types of web apps were classified as microservices using the proposed approach. To determine whether the views and tables were appropriately considered using our technique, the following three groups were generated. One group was produced in which the classification results for tables and views were removed from the original classification results; another group was produced in which only the classification results for tables were removed; and a third group in which only classification results for views were removed. Subsequently, in these three groups, each component with removed classification result is randomly assigned to a microservice. An accuracy metric was employed to compare the original classification results with the classification results of the three groups.
The results are presented in Table 3. The configurations of the
Table 3 . Comparison with and without considering tables and views
Approach | Web app (Total number of components, Number of classes, Number of views, Number of tables) | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
JPetStore2 (73, 44, 16, 13) | JPetStore6 (53, 23, 17, 13) | PetClinic (32, 18, 7, 7) | ShoppingApp (37, 21, 12, 4) | DayTrader (131, 85, 40, 6) | ||||||||||
Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | |||||
Without table & view | 43, 35, 5, 3 | 0.59, 0.80, 0.31, 0.23 | 29, 20, 5, 4 | 0.55, 0.87, 0.29, 0.31 | 22, 16, 3, 3 | 0.69, 0.89, 0.43, 0.43 | 23, 17, 5, 1 | 0.62, 0.81, 0.42, 0.25 | 63, 50, 10, 3 | 0.48, 0.59, 0.25, 0.50 | ||||
Without view | 49, 35, 3, 11 | 0.67, 0.80, 0.19, 0.85 | 35, 20, 4, 11 | 0.66, 0.87, 0.24, 0.85 | 21, 16, 1, 4 | 0.66, 0.89, 0.14, 0.57 | 24, 17, 4, 3 | 0.65, 0.81, 0.33, 0.75 | 66, 50, 10, 6 | 0.50, 0.59, 0.25, 1.00 | ||||
Without table | 53, 35, 13, 5 | 0.73, 0.80, 0.81, 0.38 | 40, 20, 15, 5 | 0.75, 0.87, 0.88, 0.38 | 25, 16, 7, 2 | 0.78, 0.89, 1.00, 0.29 | 28, 17, 10, 1 | 0.76, 0.81, 0.83, 0.25 | 79, 50, 27, 2 | 0.60, 0.59, 0.68, 0.33 | ||||
Proposed approach | 59, 35, 13, 11 | 0.81, 0.80, 0.81, 0.85 | 46, 20, 15, 11 | 0.87, 0.87, 0.88, 0.85 | 27, 16, 7, 4 | 0.84, 0.89, 1.00, 0.57 | 30, 17, 10, 3 | 0.81, 0.81, 0.83, 0.75 | 83, 50, 27, 6 | 0.63, 0.59, 0.68, 1.00 |
First, the performance of the proposed approach and the other three groups is compared from a total component perspective. The
Second, the performance of the proposed approach and the other three groups might be compared from the class component perspective. However, this comparison is meaningless. As mentioned earlier, the
Third, the performance of the proposed approach and the other three groups is compared from the view component perspective. The average percentage of views among all the components in the five web apps was 32%. A comparison between the group without the classification results for views and the proposed approach demonstrates superior results with the proposed approach. For JPetStore6, in which the percentage of views is high at 37%, the
Finally, the performance of the proposed approach and the other three groups is compared from a table component perspective. The average percentage of tables among all the components in the five web apps is 11%. For JPetStore6, in which the percentage of tables is a large rate of 22%, when the group without the classification results for tables is compared with the proposed approach, the
The experimental results described above demonstrate that the tables and views can be appropriately assigned to microservices using the proposed approach.
This paper introduces a novel approach for transforming monolithic web apps into microservices by utilizing usecases as fundamental units. Each microservice identified using this method has a specific function. Additionally, in contrast to other methods for identifying microservices, this paper considers all three layers of web apps. As a result, our approach showed better performance than existing approaches.
In future work, we plan to verify the applicability of our approach to web apps developed using languages other than Java. In addition, we intend to further validate our approach by applying it to large-scale web apps.
This work was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIT) (NRF-2021R1F1A1048842). This study was supported by the Research Fund, 2021 of The Catholic University of Korea. This paper is a revised and expanded version of a Master's thesis [37] written by one of the authors.
received a B.S. degree in 2023 from the School of Computer Science and Information Engineering in the Catholic University of Korea. He is currently a M.S. student at the School of Computer Science and Information Engineering of the Catholic University of Korea. His current research interests include software engineering and web engineering.
received a B.S. degree in 2021 and a M.S. degree in 2023 from the School of Computer Science and Information Engineering in the Catholic University of Korea. His research interests include microservices, web engineering, and software engineering.
received the PhD degree in computer science from the University of Auckland, New Zealand, in 2011. Previously, she received the bachelor’s degree from the Universiti Teknologi Malaysia and the master’s degree from the University of Southampton, United Kingdom. She is an associate professor and currently, the head of the Software Engineering and Information System Department, Faculty of Computer Science and Information Technology, Universiti Putra Malaysia. Her research interests include software engineering, model-driven engineering, design critics in software engineering, and software project management.
received the bachelor's degree in computer from Universiti Kebangsaan Malaysia, in 1993, and the master's degree in software engineering and the Ph.D. degree in artificial intelligence from Universiti Putra Malaysia (UPM).
received his BSc, MSc, and PhD in Computer Science from Seoul National University, Korea in 1997, 1999, and 2004 respectively. He was a senior research engineer at Samsung Electronics Company from 2004 to 2007. Currently, he is a full professor at the School of Computer Science and Information Engineering of the Catholic University of Korea. His current interests include web engineering, software evolution, and software engineering.
Journal of information and communication convergence engineering 2023; 21(4): 268-280
Published online December 31, 2023 https://doi.org/10.56977/jicce.2023.21.4.268
Copyright © Korea Institute of Information and Communication Engineering.
Si-Hyun Kim 1, Daeil Jung1, Norhayati Mohd Ali 2, Abu Bakar Md Sultan 2, and Jaewon Oh1*
1School of Computer Science and Information Engineering, The Catholic University of Korea, Bucheon 14662, Republic of Korea
2Faculty of Computer Science and Information Technology, Universiti Putra Malaysia, Serdang 43400, Malaysia
Correspondence to:Jaewon Oh (E-mail: jwoh@catholic.ac.kr)
School of Computer Science and Information Engineering, The Catholic University of Korea, Bucheon 14662, Republic of Korea
This is an Open Access article distributed under the terms of the Creative Commons Attribution Non-Commercial License (http://creativecommons.org/licenses/by-nc/3.0/) which permits unrestricted non-commercial use, distribution, and reproduction in any medium, provided the original work is properly cited.
Several companies have migrated their existing monolithic web applications to microservice architectures. Consequently, research on the identification of microservices from monolithic web applications has been conducted. Meanwhile, the use-case model plays a crucial role in outlining the system’s functionalities at a high level of abstraction, and studies have been conducted to identify microservices by utilizing this model. However, previous studies on microservice identification utilizing use-cases did not consider the components executed in the presentation layer. Unlike existing approaches, this paper proposes a technique that considers all three layers of web applications (presentation, business logic, and data access layers). Initially, the components used in the three layers of a web application are extracted by executing all the scenarios that constitute its use-cases. Thereafter, the usage rate of each component is determined for each use-case and the component is allocated to the use-case with the highest rate. Then, each use-case is realized as a microservice. To verify the proposed approach, microservice identification is performed using open-source web applications.
Keywords: Monolithic applications, Microservices, Microservice identification, Use-cases, Web application reengineering
These days, there has been a continuous increase in the amount of data that needs to be processed by web applications (web apps), and the requirements for web apps are becoming more and more complex [1]. Under these circumstances, the modularization of web apps makes it easier to maintain increasingly complex web apps, and it can improve their performance [2]. Hence, various approaches, such as a method to partition web apps into layers [3] and a method to transform web apps into service-oriented architectures [4], have been proposed as methods for the modularization of web apps [4-19]. In addition, to achieve modularization, several companies (including Netflix, Amazon, and eBay) have recently migrated their monolithic web apps to microservice architectures [5]. In this context, the term
Hence, to alleviate the difficulties in the transformation process, research has focused on methods to automatically identify microservices within monolithic web apps [9-16,18, 19]. However, in many prior studies, components such as database tables and views in the data access and presentation layers of web apps were overlooked in the identification of microservices. As a result, existing techniques were not sufficient to ensure that each of the identified microservices can properly perform its function as a web app.
To address these problems, this paper proposes a method for transforming monolithic web apps into microservice architectures by achieving the following three research objectives.
Microservice identification utilizing the use-case model: To transform a monolithic web app into a microservice architecture, it is essential to determine the parts of the web app that are converted into microservices. The main goal of this transformation is to ensure that each identified microservice provides a single function. To accomplish this, we utilize a use-case model outlining the functional requirements of a system. In other words, our approach extracts a use-case model from a monolithic web app and maps each use-case to a microservice.
Identification of microservices composed of all three web app layers: A web app generally comprises three layers: presentation, business logic, and data access [20]. Similarly, when constructing a web app based on the microservice architecture it is essential to ensure that each microservice can function as a small independent web app [6]. Consequently, each microservice must encompass all components running in these three layers for complete web app functionality. Considering this aspect of microservices in the identification process, this paper introduces a microservice identification technique that, through dynamic analysis, considers all components executed in the three layers of web apps. It ensures the inclusion of these components in the identified microservices. It is worth noting that, unlike prior studies utilizing use-cases for microservice identification, this paper accounts for components executed in the presentation layer.
Evaluation: To assess the applicability and effectiveness of the proposed technique, it is essential to compare it with various existing microservice identification techniques. The comparison between our approach and existing methods is made using five types of open-source web apps. Additionally, an evaluation is conducted using an accuracy metric widely used in machine learning.
This paper makes the following contributions by accomplishing the aforementioned research objectives. First, it decomposes a monolithic web app based on its functions by utilizing use-cases for microservice identification. Second, all three layers of the web apps are considered. Third, this paper demonstrates that our approach outperforms existing methods.
The remainder of this paper is organized as follows. Section II describes related studies. Section III presents a method for microservice identification. In Section IV, the effectiveness of our approach is evaluated. Finally, Section V provides conclusions and directions for future research.
According to a related study [7], microservice identification methods or Service Identification Approaches (SIAs) can be divided into six types: wrapping, genetic algorithms, Formal Concept Analysis (FCA), clustering, custom heuristics, and general guidelines. In particular, clustering and custom heuristics have been the preferred approaches in recent studies [7].
In SIAs, microservices can be identified using various input data. In [7], the input data were classified into three categories: executable models (source code, databases, etc.), non-executable models (execution traces, use-cases, etc.), and domain artifacts (ontologies, documents, etc.).
Our approach uses classes, tables, and views as executable models, and execution traces and use-cases as non-executable models. Consequently, it is necessary to review studies that utilize these two types of models.
First, studies that identify microservices using use-cases include the following. Dmitry et al. [12] introduced a method using use-cases to partition a monolithic web app into components with a single function. This technique is similar to ours, as it identifies microservices by dividing web apps based on use-cases. However, their method lacked evaluation using real web apps, and it did not account for tables and views.
In a study by Bajaj et al. [13], relationships between usecases and those between use-cases and tables were extracted. The relationships were then analyzed to identify microservices. However, as this technique focuses on microservice identification at the use-case level, it does not take into account classes and views.
In the approach presented by Tyszberowicz et al. [15], the functional requirements of the system were analyzed using use-cases. Based on this analysis, they proposed a method for identifying microservices by partitioning web apps by function. This method is similar to our approach in that it considers tables in the process of identifying microservices. However, they did not consider views such as JSP.
Furthermore, Kalia et al. [18] proposed a method to extract execution traces based on use-cases and subsequently analyze the traces to depict the call relationships between classes in a graph. This study is similar to our approach in that class information is obtained from execution traces. However, their method is constrained since table and view information cannot be obtained.
Second, it is necessary to review studies that consider not only classes but also tables and views. Some previous studies [9-11,21-23] considered both classes and tables to identify microservices.
Levcovitz et al. [9] introduced a method to represent components including database tables and business logic, and call relationships between components, in the form of a graph through static analysis of monolithic web apps. A limitation of their approach, in contrast to ours, is the inability to identify dynamically generated tables due to its reliance on static analysis. Moreover, it does not consider cases where multiple microservices share tables.
Kamimura et al. [10] proposed a method to represent classes and tables as nodes and call relationships between nodes as edges through static analysis of the source code of web apps. This technique considers only web apps that use Object Relational Mapping (ORM1) in the process of identifying tables; therefore, it can not be used to identify tables in the case of apps not using ORM.
Mazlami et al. [11] presented a method for utilizing the information from version control systems to identify microservices. Their approach generates a graph where classes and tables are nodes, and the relationships between nodes are edges. The graph is then clustered to identify microservices. At that time, edges are generated based on the change history of classes obtained from the version control system, from information on contributors who changed the classes, or from information on source code similarity between classes obtained by static analysis of the source code. However, this method is limited to apps using ORM, rendering it unable to identify tables in apps without ORM.
Del Grosso et al. [21] proposed a technique to identify microservices by dynamically extracting SQL queries to obtain database tables and fields and clustering the queries with the obtained information. This method is similar to ours in that it uses dynamic analysis to extract SQL queries. However, because their approach identifies microservices using only SQL queries, it does not consider classes and views.
Recent studies [22,23] have expanded their focus beyond classes to include tables and views. These studies highlight that certain components in web apps are overlooked by existing microservice identification methods. Thus, those studies proposed the following process to solve the problem. In the first step, any existing microservice identification method is executed. In the subsequent step, the components not considered by the existing method are classified as microservices by reusing the identification results of the previous step. The tables and views are classified in the subsequent step. While these studies directly classify all components into microservices, these studies reuse the results of other microservice identification techniques for this classification. In addition, these studies statically analyze the source code, unlike this paper.
This paper introduces a method for transforming a monolithic web app into a microservice architecture where each identified microservice functions as an independent web app with its unique purpose. A use-case represents a function provided by a system at a high level of abstraction from the user’s perspective [12,13]. Therefore, this paper proposes a microservice identification approach that realizes each usecase as a microservice.
As depicted in Fig. 1, the proposed approach consists of three steps: identifying use-cases and their scenarios, extracting components based on these scenarios, and clustering the components according to the use-cases. In this figure, the system consists of two use-cases (
A use-case is a set of scenarios, each of which is a series of steps through which a web app is used. Consequently, the identification of use-cases also requires the identification of their scenarios. This paper proposes the following method for identifying use-cases and their scenarios.
First, use-cases and their scenarios can be statically identified by referring to the web app documentation. Documents for web apps can be found in various locations. For example, for open-source apps publicly available in an open-source repository (e.g., GitHub2), a file with a description of the web app (e.g., HELP.html and README.md) is sometimes provided. In such cases, use-cases and their scenarios can be identified through static analysis of the file.
Fig. 2 shows the process of extracting use-cases by referring to the HELP.html file in the open-source web app called JPetStore63. The use-case called
Second, use-cases and scenarios can be dynamically identified through the execution of a web app. Analyzing documents for the extraction of use-cases and scenarios may encounter limitations due to insufficient information in the documents or the absence of relevant documents. In such cases, use-cases and scenarios can be identified by executing a web app.
For example, in the scenario identification step of Fig. 2, the
A scenario is one of the operational flows within a web app. Thus, an execution trace can be extracted for each scenario. In this context, the execution trace refers to a list of components used during scenario execution. The Aspect Oriented Programming (AOP) technique [24,25] can be used to extract such execution traces. As shown in Fig. 3, when employing AOP in Java web app, execution traces can be generated by detecting the execution of the classes and methods constituting the web app. In this figure, the web app consists of components (
AspectJ [24] is one of the technologies supporting AOP in Java apps and is a library that can be used to extract execution traces. As shown in Fig. 4, the execution traces can be extracted by adding to a Java web app the special construct called an
When executing a
This paper considers database tables in the data access layer of web apps. For this purpose, it is essential to identify tables accessed during the execution of the scenarios.
In general, we can obtain information on tables by analyzing SQL queries. The methods used to generate SQL queries in web apps can be divided into three types. First, it is possible to completely generate SQL queries at compile time if the developer directly writes them in the source code. Second, while an app is executed, SQL queries can be dynamically generated by utilizing user input. Third, SQL queries can be statically or dynamically generated using database frameworks (e.g., MyBatis4 and Spring Data JPA5).
Regarding the above methods, approaches to extracting SQL queries can be divided into two types. The first method uses static analysis. In a study by Meurice et al. [26], static analysis of source code was performed to identify a method of a class that accesses database tables. The SQL query, treated as a value in the method argument, is then statically extracted. There is a limitation in the technique proposed by Meurice et al., which assumes the source code includes static information on tables; therefore, it does not consider cases in which tables are dynamically generated.
The second type of approach uses dynamic analysis. In a study by Cleve et al. [27], the execution of a method of a class used to access database tables was identified, and the argument value of this method was dynamically extracted to obtain a SQL query. If this approach is used, cases in which tables are generated dynamically can be considered.
Our approach is a dynamic analysis technique. Nevertheless, it is different from the study by Cleve et al. in that our approach considers cases in which SQL queries are generated by using database frameworks.
According to one previous study [28], most Java database frameworks are implemented based on the Java Database Connectivity (JDBC)6Application Programming Interface (API); therefore, access to tables can be discerned by tracing the execution of the JDBC API. In our approach, AspectJ is used to detect the execution of classes. Similarly, to detect access to tables, the JDBC API with a SQL query as its argument is specified within the pointcut of the aspect class. Subsequently, when the execution of this API is detected dynamically, the SQL query used as the argument value of this API can be extracted. These JDBC methods can be found on the website for Kieker7, one of the dynamic analysis tools.
Line 2 in Fig. 5 shows the class
Our approach uses line 6 of Fig. 4 to detect the
Web apps generally employ views to display the outcomes of business logic. In Java web apps, views can be written using two methods. The first is the standard method of utilizing JSP and HTML. The second uses presentation frameworks (such as Stripes9).
Therefore, to identify views, it is necessary to use a technique that is suitable for the presentation method applied to web apps. In this paper, the following two approaches described below are used to identify views.
First, when employing JSP and HTML in a standard Java web app, views are identified as follows. The JSP is executed after being converted into a servlet class by the web server. Since the final JSP form is a servlet class, the JSP can be identified if the final servlet class is specified within the pointcut of the aspect class, as shown in line 5 of Fig. 4.
HTML can not be identified using AspectJ because it is not a Java class. In this case, the interceptor pattern [29] can be used to detect HTML. In other words, this pattern allows the interceptor written as a Java class to run before HTML page
Second, in web apps that employ presentation frameworks such as FreeMarker10, a distinct class method is used to execute JSP and HTML. By specifying this particular method within the AspectJ pointcut, views such as JSP and HTML can be identified. For instance, in FreeMarker, the
In JPetStore6, which uses Stripes as its presentation framework, the constructor of the
In this paper, each use-case is realized as a microservice. Specifically, the clustering of a web app’s components is conducted based on its use-cases, and a set of components belonging to each cluster (i.e., a use-case) is implemented as a single microservice. In this phase, to identify the components that belong to microservices, this paper uses information obtained in Section Ⅲ.A and Ⅲ.B, defined as follows.
Definition 1: The information used for microservice identification is as follows.
-
-
-
-
This paper assumes that a microservice should serve a single function; hence, it is considered an appropriate approach to separate the components based on use-cases. From this perspective, the method for allocating components to usecases is shown in Fig. 6.
This algorithm computes the usage rate of each component for each use-case and allocates the component to the use-case with the highest usage rate. The usage rate of a component for a use-case is determined by the ratio of scenarios using the component within the use-case (see line 5 in Fig. 6). For example, for a specific use-case, if a particular component is used in all scenarios belonging to the use-case, the usage rate is one and if the component is used in half of the scenarios, the usage rate is 0.5. A high usage rate of a component for a use-case indicates that the component is a key component of the use-case. Thus, the usage rate serves as an appropriate criterion for allocating a component to the specific use-case.
If two or more use-cases have the same usage rate (lines 11-16), the number of times the component is used is calculated, and the component is allocated to the use-case with the most uses. The number of uses of a component for a usecase is the number of scenarios in which the component is used from among all the scenarios constituting the use-case.
If the number of uses is primarily considered, rather than the usage rate, even though a component is used in all the scenarios of use-case
Fig. 7 illustrates a segment of the microservice identification process for JPetStore6. To determine the appropriate use-case for allocating the
This section describes experiments conducted to evaluate the proposed approach. It addresses the following research questions.
RQ1: Is our approach more effective than existing methods?
RQ2: Are tables and views appropriately allocated to microservices?
The performance of the proposed approach was assessed using the open-source web apps listed in Table 1. These apps were chosen for several reasons. First, they are publicly available in well-known open-source repositories, and JPetStore6 and PetClinic have been used in previous studies [10,11,14, 18]. Second, they were selected to evaluate the effectiveness of our approach across different types of web apps (e.g., JPet- Store2, JPetStore6, PetClinic) using various frameworks as well as standard Java web apps (e.g., ShoppingApp). Third, because PetClinic is an open-source web app with a microservice version currently available, it enables an objective evaluation of the results of microservice identification.
Table 1 . Subject applications.
Name | The number of components: Class(LOC), View(Type), Table | Technologies used: Application framework, Presentation framework, Database technology | Number of use-cases | Number of scenarios | Description |
---|---|---|---|---|---|
JPetStore2a) | 48(1602), 21(JSP)&2(HTML), 13 | Springb), Spring Web MVCc), iBatisd) | 4 | 30 | Shopping mall for pet animals |
JPetStore6 | 24(1406), 20(JSP)&2(HTML), 13 | Spring, Stripes, MyBatis | 4 | 28 | Shopping mall for pet animals |
PetClinice) | 25(782), 12(HTML), 7 | SpringBootf), Thymeleafg), JPAh) | 3 | 21 | Animal hospital management system |
ShoppingAppi) | 22(1353), 13(JSP), 4 | N/A, N/A, JDBC | 4 | 21 | Fashion shopping mall |
DayTraderj) | 108(10376), 24(JSP)&19(HTML) &15(XHTML), 6 | N/A, N/A, JPA | 5 | 46 | Stock trading system |
c)https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/mvc.html.
h)https://docs.oracle.com/javaee/7/tutorial/partpersist.htm.
In this paper, we evaluate the effectiveness of our approach by comparing it to multiple baseline approaches. The approaches compared with our proposed technique are described below.
MEM: This technique introduced by Mazlami et al. [11], operates by taking a monolithic web app uploaded to a version control system, such as Git11, as input. The resulting output is a graph representing classes as nodes and illustrating relationships between nodes as edges. In the graph, edges are generated based on the change history of classes obtained from the version control system, information on the contributors who modified the classes, or information on the source code similarity between classes that can be obtained by static analysis. Following the generation of this graph, Kruskal’s algorithm [31] is employed to derive a Minimum Spanning Tree (MST) [32] for microservice identification. In the experiment described in this paper, edges were generated using information on source code similarity.
Bunch: Introduced by Mitchell et al. [33], this technique initiates by extracting call relationships between components at the source code level through static analysis of a web app. Subsequently, a Module Dependency Graph (MDG) is generated based on the results. This MDG represents components as nodes and represents the relationships between components as edges. Then, using the MDG as input, clustering is performed using the Hill-Climbing algorithm [34] to identify microservices.
Mono2Micro: Introduced by Kalia et al. [18], this technique initiates by extracting execution traces based on usecases. These traces are analyzed to represent call relationships between classes in the form of a graph. Clustering is then executed using a hierarchical clustering algorithm [35] for microservice identification.
Our task in this paper is to cluster multiple components of a monolithic web app into two or more microservices. This problem can be regarded as a multiclass classification problem for classifying each component as one of multiple microservices.
To assess the quality of the identified microservices in web apps, it is crucial to establish the ground truth. The performance of identification algorithms is evaluated by comparing their results against the ground truth. The method used to generate the ground truth is detailed in the following section. In terms of evaluation metrics, this paper utilizes the accuracy metric [36], which is commonly used to evaluate the performance of multiclass classification algorithms.
The ground truth in this study resulted from the identification of microservices based on their functions through the expertise of web app professionals, utilizing both static and dynamic analyses of monolithic web apps. The process of generating ground truth is as follows. Web app experts are divided into two groups. The first group identifies microservices. The second group verifies the identified microservices. These two groups repeat the above steps until they agree on the result of the microservice identification task.
In this paper, ground truth is represented as
-
Finally, the accuracy [36] for the entire microservice app is defined as follows:
Accuracy: the ratio of correctly classified components in
It is necessary to evaluate the effectiveness of the proposed approach through a comparison with existing approaches.
Therefore, the evaluation was conducted as follows:
Microservice identification was conducted using four types of techniques: the proposed approach, MEM, Bunch, and Mono2Micro. Only the proposed approach considers tables and views; the other three do not. However, to compare the four approaches more appropriately, all the components unclassified by these algorithms were randomly allocated to microservices. Following this adjustment, the accuracy of the identification result from each method was measured to evaluate the quality of the identification method.
Table 2 presents the results. Below the name of each web app in this table, the total numbers of components, classes, views, and tables classified as microservices are listed. However, these numbers differ from those listed in Table 1. This difference arises due to the inability to categorize some components into specific microservices. These components have the following characteristics. These components are the basic components that each microservice should have. For example, the
Table 2 . Comparison of our approach with baseline approaches.
Approach | Web app (Total number of components, Number of classes, Number of views, Number of tables) | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
JPetStore2 (73, 44, 16, 13) | JPetStore6 (53, 23, 17, 13) | PetClinic (32, 18, 7, 7) | ShoppingApp (37, 21, 12, 4) | DayTrader (131, 85, 40, 6) | ||||||||||
Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | |||||
Mono2Micro | 48, 38, 3, 7 | 0.66, 0.86, 0.19, 0.54 | 30, 18, 8, 4 | 0.57, 0.78, 0.47, 0.31 | 15, 10, 4, 1 | 0.47, 0.56, 0.57, 0.14 | 21, 16, 4, 1 | 0.57, 0.76, 0.33, 0.25 | 58, 46, 10, 2 | 0.44, 0.54, 0.25, 0.33 | ||||
Bunch | 45, 37, 5, 3 | 0.62, 0.84, 0.31, 0.23 | 29, 19, 6, 4 | 0.55, 0.83, 0.35, 0.31 | 20, 14, 3, 3 | 0.62, 0.78, 0.43, 0.43 | 20, 14, 5, 1 | 0.54, 0.67, 0.42, 0.25 | 58, 45, 10, 3 | 0.44, 0.53, 0.25, 0.50 | ||||
MEM | 35, 25, 4, 6 | 0.48, 0.57, 0.25, 0.46 | 25, 13, 8, 4 | 0.47, 0.57, 0.47, 0.31 | 17, 11, 3, 3 | 0.53, 0.61, 0.43, 0.43 | 15, 11, 3, 1 | 0.41, 0.52, 0.25, 0.25 | 59, 45, 12, 2 | 0.45, 0.53, 0.30, 0.33 | ||||
Proposed approach | 59, 35, 13, 11 | 0.81, 0.80, 0.81, 0.85 | 46, 20, 15, 11 | 0.87, 0.87, 0.88, 0.85 | 27, 16, 7, 4 | 0.84, 0.89, 1.00, 0.57 | 30, 17, 10, 3 | 0.81, 0.81, 0.83, 0.75 | 83, 50, 27, 6 | 0.63, 0.59, 0.68, 1.00 |
The
Because the existing approaches consider classes only, the performance of the proposed and existing approaches are first compared from the class component perspective. The
The performance of the proposed approach and existing approaches can be compared from the view component and the table component perspectives. The
For ShoppingApp, JSP is employed for views, and the business logic accessing tables is written in the JSP source code. These features pose a challenge for techniques that do not consider views, as they can not gather information on the business logic embedded in the JSP. However, our approach allows us to obtain better identification results by considering these views. Table 2 shows that the
For DayTrader, the
Consequently, some classes or views are not executed in DayTrader, leading to the proposed approach being unable to classify these components accurately as microservices. If static analysis techniques such as the Bunch and the MEM are used, components related to unexecuted use-cases and scenarios can be identified. However, the Mono2Micro and our approach, which are both dynamic analysis techniques, can not identify the components mentioned above. Consequently, our approach exhibits a lower performance in the DayTrader experiment compared to experiments on other web apps. Nevertheless, in the DayTrader experiment, the
The performance described above, assessed in comparison with the ground truth identified by web app experts, indicates that the microservice apps identified using our approach align closely with those identified by experts from a functional perspective. In short, our identification technique can properly partition web apps by function, as intended by experts. The experimental results described above indicate that the proposed approach can be effectively used to identify microservices.
It is crucial to assess whether tables and views are assigned appropriately to microservices when those microservices are identified using the proposed approach. To conduct this evaluation, experiments were conducted as described below.
The components of the five types of web apps were classified as microservices using the proposed approach. To determine whether the views and tables were appropriately considered using our technique, the following three groups were generated. One group was produced in which the classification results for tables and views were removed from the original classification results; another group was produced in which only the classification results for tables were removed; and a third group in which only classification results for views were removed. Subsequently, in these three groups, each component with removed classification result is randomly assigned to a microservice. An accuracy metric was employed to compare the original classification results with the classification results of the three groups.
The results are presented in Table 3. The configurations of the
Table 3 . Comparison with and without considering tables and views.
Approach | Web app (Total number of components, Number of classes, Number of views, Number of tables) | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
JPetStore2 (73, 44, 16, 13) | JPetStore6 (53, 23, 17, 13) | PetClinic (32, 18, 7, 7) | ShoppingApp (37, 21, 12, 4) | DayTrader (131, 85, 40, 6) | ||||||||||
Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | |||||
Without table & view | 43, 35, 5, 3 | 0.59, 0.80, 0.31, 0.23 | 29, 20, 5, 4 | 0.55, 0.87, 0.29, 0.31 | 22, 16, 3, 3 | 0.69, 0.89, 0.43, 0.43 | 23, 17, 5, 1 | 0.62, 0.81, 0.42, 0.25 | 63, 50, 10, 3 | 0.48, 0.59, 0.25, 0.50 | ||||
Without view | 49, 35, 3, 11 | 0.67, 0.80, 0.19, 0.85 | 35, 20, 4, 11 | 0.66, 0.87, 0.24, 0.85 | 21, 16, 1, 4 | 0.66, 0.89, 0.14, 0.57 | 24, 17, 4, 3 | 0.65, 0.81, 0.33, 0.75 | 66, 50, 10, 6 | 0.50, 0.59, 0.25, 1.00 | ||||
Without table | 53, 35, 13, 5 | 0.73, 0.80, 0.81, 0.38 | 40, 20, 15, 5 | 0.75, 0.87, 0.88, 0.38 | 25, 16, 7, 2 | 0.78, 0.89, 1.00, 0.29 | 28, 17, 10, 1 | 0.76, 0.81, 0.83, 0.25 | 79, 50, 27, 2 | 0.60, 0.59, 0.68, 0.33 | ||||
Proposed approach | 59, 35, 13, 11 | 0.81, 0.80, 0.81, 0.85 | 46, 20, 15, 11 | 0.87, 0.87, 0.88, 0.85 | 27, 16, 7, 4 | 0.84, 0.89, 1.00, 0.57 | 30, 17, 10, 3 | 0.81, 0.81, 0.83, 0.75 | 83, 50, 27, 6 | 0.63, 0.59, 0.68, 1.00 |
First, the performance of the proposed approach and the other three groups is compared from a total component perspective. The
Second, the performance of the proposed approach and the other three groups might be compared from the class component perspective. However, this comparison is meaningless. As mentioned earlier, the
Third, the performance of the proposed approach and the other three groups is compared from the view component perspective. The average percentage of views among all the components in the five web apps was 32%. A comparison between the group without the classification results for views and the proposed approach demonstrates superior results with the proposed approach. For JPetStore6, in which the percentage of views is high at 37%, the
Finally, the performance of the proposed approach and the other three groups is compared from a table component perspective. The average percentage of tables among all the components in the five web apps is 11%. For JPetStore6, in which the percentage of tables is a large rate of 22%, when the group without the classification results for tables is compared with the proposed approach, the
The experimental results described above demonstrate that the tables and views can be appropriately assigned to microservices using the proposed approach.
This paper introduces a novel approach for transforming monolithic web apps into microservices by utilizing usecases as fundamental units. Each microservice identified using this method has a specific function. Additionally, in contrast to other methods for identifying microservices, this paper considers all three layers of web apps. As a result, our approach showed better performance than existing approaches.
In future work, we plan to verify the applicability of our approach to web apps developed using languages other than Java. In addition, we intend to further validate our approach by applying it to large-scale web apps.
This work was supported by the National Research Foundation of Korea (NRF) grant funded by the Korea government (MSIT) (NRF-2021R1F1A1048842). This study was supported by the Research Fund, 2021 of The Catholic University of Korea. This paper is a revised and expanded version of a Master's thesis [37] written by one of the authors.
Table 1 . Subject applications.
Name | The number of components: Class(LOC), View(Type), Table | Technologies used: Application framework, Presentation framework, Database technology | Number of use-cases | Number of scenarios | Description |
---|---|---|---|---|---|
JPetStore2a) | 48(1602), 21(JSP)&2(HTML), 13 | Springb), Spring Web MVCc), iBatisd) | 4 | 30 | Shopping mall for pet animals |
JPetStore6 | 24(1406), 20(JSP)&2(HTML), 13 | Spring, Stripes, MyBatis | 4 | 28 | Shopping mall for pet animals |
PetClinice) | 25(782), 12(HTML), 7 | SpringBootf), Thymeleafg), JPAh) | 3 | 21 | Animal hospital management system |
ShoppingAppi) | 22(1353), 13(JSP), 4 | N/A, N/A, JDBC | 4 | 21 | Fashion shopping mall |
DayTraderj) | 108(10376), 24(JSP)&19(HTML) &15(XHTML), 6 | N/A, N/A, JPA | 5 | 46 | Stock trading system |
c)https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/mvc.html.
h)https://docs.oracle.com/javaee/7/tutorial/partpersist.htm.
Table 2 . Comparison of our approach with baseline approaches.
Approach | Web app (Total number of components, Number of classes, Number of views, Number of tables) | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
JPetStore2 (73, 44, 16, 13) | JPetStore6 (53, 23, 17, 13) | PetClinic (32, 18, 7, 7) | ShoppingApp (37, 21, 12, 4) | DayTrader (131, 85, 40, 6) | ||||||||||
Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | |||||
Mono2Micro | 48, 38, 3, 7 | 0.66, 0.86, 0.19, 0.54 | 30, 18, 8, 4 | 0.57, 0.78, 0.47, 0.31 | 15, 10, 4, 1 | 0.47, 0.56, 0.57, 0.14 | 21, 16, 4, 1 | 0.57, 0.76, 0.33, 0.25 | 58, 46, 10, 2 | 0.44, 0.54, 0.25, 0.33 | ||||
Bunch | 45, 37, 5, 3 | 0.62, 0.84, 0.31, 0.23 | 29, 19, 6, 4 | 0.55, 0.83, 0.35, 0.31 | 20, 14, 3, 3 | 0.62, 0.78, 0.43, 0.43 | 20, 14, 5, 1 | 0.54, 0.67, 0.42, 0.25 | 58, 45, 10, 3 | 0.44, 0.53, 0.25, 0.50 | ||||
MEM | 35, 25, 4, 6 | 0.48, 0.57, 0.25, 0.46 | 25, 13, 8, 4 | 0.47, 0.57, 0.47, 0.31 | 17, 11, 3, 3 | 0.53, 0.61, 0.43, 0.43 | 15, 11, 3, 1 | 0.41, 0.52, 0.25, 0.25 | 59, 45, 12, 2 | 0.45, 0.53, 0.30, 0.33 | ||||
Proposed approach | 59, 35, 13, 11 | 0.81, 0.80, 0.81, 0.85 | 46, 20, 15, 11 | 0.87, 0.87, 0.88, 0.85 | 27, 16, 7, 4 | 0.84, 0.89, 1.00, 0.57 | 30, 17, 10, 3 | 0.81, 0.81, 0.83, 0.75 | 83, 50, 27, 6 | 0.63, 0.59, 0.68, 1.00 |
Table 3 . Comparison with and without considering tables and views.
Approach | Web app (Total number of components, Number of classes, Number of views, Number of tables) | |||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
JPetStore2 (73, 44, 16, 13) | JPetStore6 (53, 23, 17, 13) | PetClinic (32, 18, 7, 7) | ShoppingApp (37, 21, 12, 4) | DayTrader (131, 85, 40, 6) | ||||||||||
Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | Hit | Accuracy | |||||
Without table & view | 43, 35, 5, 3 | 0.59, 0.80, 0.31, 0.23 | 29, 20, 5, 4 | 0.55, 0.87, 0.29, 0.31 | 22, 16, 3, 3 | 0.69, 0.89, 0.43, 0.43 | 23, 17, 5, 1 | 0.62, 0.81, 0.42, 0.25 | 63, 50, 10, 3 | 0.48, 0.59, 0.25, 0.50 | ||||
Without view | 49, 35, 3, 11 | 0.67, 0.80, 0.19, 0.85 | 35, 20, 4, 11 | 0.66, 0.87, 0.24, 0.85 | 21, 16, 1, 4 | 0.66, 0.89, 0.14, 0.57 | 24, 17, 4, 3 | 0.65, 0.81, 0.33, 0.75 | 66, 50, 10, 6 | 0.50, 0.59, 0.25, 1.00 | ||||
Without table | 53, 35, 13, 5 | 0.73, 0.80, 0.81, 0.38 | 40, 20, 15, 5 | 0.75, 0.87, 0.88, 0.38 | 25, 16, 7, 2 | 0.78, 0.89, 1.00, 0.29 | 28, 17, 10, 1 | 0.76, 0.81, 0.83, 0.25 | 79, 50, 27, 2 | 0.60, 0.59, 0.68, 0.33 | ||||
Proposed approach | 59, 35, 13, 11 | 0.81, 0.80, 0.81, 0.85 | 46, 20, 15, 11 | 0.87, 0.87, 0.88, 0.85 | 27, 16, 7, 4 | 0.84, 0.89, 1.00, 0.57 | 30, 17, 10, 3 | 0.81, 0.81, 0.83, 0.75 | 83, 50, 27, 6 | 0.63, 0.59, 0.68, 1.00 |