Development Of Service-Oriented Architecture-Based Microservices Management As A Data Integration Service (Case Study: Udayana University)

sistem


Introduction
Since 2015, Udayana University has utilized IMISSU (Integrated Management Information System, the Strategic of UNUD), a Single Sign-On (SSO)-based information system [1]. All of Udayana University's developed information systems still employ the Monolithic Architecture model. Monolithic architecture is a conventional information system development model in which all functionality from web servers, databases, and business processes is encapsulated within a single application, making it impossible to execute each module independently [2].
Long-term issues arise when the system already has a large amount of data and is experiencing rapid data growth, and the resulting data must be able to support other information systems. As depicted in Figure 1, the data integration process between information systems at Udayana University continues to rely on the traditional method of joining tables between databases and making numerous connections to the database directly in the program, thereby reducing the performance of the information system. The addition of server capacity is the solution that must be chosen to improve the performance of the information system in light of its performance decline. Service Oriented Architecture (SOA) is a method of data integration. SOA is an architectural approach capable of managing distributed applications in heterogeneous environments with rapid development and low cost [3]. According to Larrucea [4], microservices are small applications with a single purpose that can be independently implemented, scaled, and tested.
Using the SOA methodology, changes to the data integration process are implemented based on the preceding problem description by creating a small service on each information system. The created services are then stored in microservices management, which is converted into REST API writing format to become one-stop web services. By implementing a web services architecture, it is possible to address the monolithic architecture's weaknesses [5].

Research Method / Proposed Method
This research employs development research methods, also known as Research & Development, by looking for information to be used as reference material to develop information that has been received to increase technology, theory, and information as necessary.

Data Source
In this study, the primary data source is collected directly in the field by the authors [6]; these data are collected as primary data. The available data sources include existing web services about academic systems, personnel, finances, and planning. Table 1 demonstrates some examples of web services.

Implementation Plan
In general, the SOA implementation steps in a system are divided into 3 phases, namely the Initiation Phase, the Develop Road Map Phase, the Implementation and Testing Phases [7]. As shown in Figure 2, the initiation phase identifies current conditions and reviews the literature on the work to be achieved. The Develop Roadmap stage shows SOA requirements with designs on the backend and frontend. The implementation and testing phase explains how to implement services and test each service according to the needs and is suitable for use by users who use or client services.  Step of Implementation This microservices management will be constructed using the Service Oriented Architecture (SOA) concept, thereby transforming small services into a Microservices Management System. This system will eventually interact with web services on other information systems as an intermediary between service providers and service consumers. With this communication design, the Microservices Management System will meet the service client' s needs.
As depicted in Figure 3, the Microservices Management Information System comprises three (three) entities: web services at each data provider, clients as data requestors, and Information Systems as intermediaries between web services and clients.

SOA Architecture Structure
As shown in Figure 4, the design structure produced by implementing Service Oriented Architecture (SOA) consists of two major components: the Backend Service and the Frontend GUI. On the Backend Service side, an Authorization Server regulates user authorization and authentication processes. The API Gateway controls route endpoints, verifies input parameters, handles errors, records logs, and modifies response data. The Frontend section is a visually accessible information system. This information system regulates API management and user management.

Testing
The testing phases of this study employed three test models: system performance testing, white box testing method, and system feasibility test cases utilizing questionnaire distribution.
For white box testing, this study used the Basis Path method. In the technique of basis path testing, the test was conducted by generating a test case based on the cyclomatic complexity value. The value of cyclomatic complexity was derived from a flowchart based on the microservices management information system flowchart. The test case results were then used to create a result table that calculates the number of valid or appropriate scenario tests versus those that are invalid or not in accordance with the results [8].
The subsequent testing phase involved testing the data input control in accordance with Character checks (U1), Numeric Value Checks (U2), Check Digit (U3), Limit Tests (U4), Reasonableness Tests (U5), Internal Compatibility (U6), Cross Checks with data in other applications (U7), Table Look Ups (U8), Existence of Required Data (U9), Confirmation Screens (U10), dan Field lengths and Overflow checks (U11). Tests were conducted to determine whether the system performed input validation.
The last test used usability testing, which according to ISO 9241-11, is a test process to find out the extent to which the product is easy and can be used and operated by users in terms of achieving a specified goal with conditions of effectiveness, efficiency, and satisfaction in a particular context of use [9]. In this study, the usability testing process employed 2 (two) methods, namely Single Ease Question (SEQ) and System Usability Scale (SUS). The concept in this study comes from a literature review in the form of articles, scientific journals, research reports, and books that are used as references in this study.

Service Oriented Architecture (SOA)
Microservices are the smallest components of the software or specialized applications for a specific task that collaborate to accomplish high-level objectives [10]. With an API (Application Programming Interface) interface, applications are organized so that they are separated into small independent services, have specific functions (high cohesion), and do not depend on other program components (loose coupling) [11].
Microservices architecture consists of simply dividing applications into small services based on their individual requirements so that they can function uniquely. The application is designed so that each function operates independently, and each function can use the technology stack based on its requirements, which means that different technologies will be utilized in a single large application [12].

REST API
REST (Representational State Transfer) is a technical or architectural rule that performs the process of communicating data and information through an interface such as HTTP. The REST API works very much like a regular web application. The client can send a request to the server via the HTTP protocol, and after that, the server responds by giving a response back to the client. REST was created and developed by Roy Fielding, the founder of the Apache HTTP Server Project [13].

State of The Art
Several previous studies have examined the success of data integration and the use of Service-Oriented Architecture (SOA) in data integration development. The first study by Dewi titled "Analisis Dampak Integrasi Data Terhadap Kecepatan Pelayanan Publik di Kota Surabaya" In the study, the author innovated public services by implementing e-Government to integrate population data for residents of Surabaya City. In the integration process, 10 data were presented in JSON format and used as entry data in other information systems, resulting in a population data filling process speed of 80.7% [14].
The second study by Megargel & Shankarararman titled "Digital Banking Accelerator: A Service-Oriented Architecture Starter Kit for Banks." In the study, the obstacle in designing a banking system service was the inability to update existing information systems. The study proposed using the Digital Banking Accelerator (DBA) as a "starter kit" with the SOA method. The study found that SOA-based services used for digital bank startups are more innovative and efficient [15].
The third study by Raj & Ravichandra titled "Microservices: A perfect SOA based solution for Enterprise Applications compared to Web Services." In this study, Service-Oriented Architecture has had a significant impact on how software applications are built. The study discussed the main weaknesses of web services and the benefits of microservices through SOA-based services. The study found that microservices are more suitable for developing SOAbased applications than using web services, at 36% [16].

Result and Discussion
The results and discussion resulted in the program's design are divided into two main structures: the Backend as the main service running the API and the Frontend as the API documentation display.

Service Data Flow
The initial phase of microservices management development begins with creating an API Group for all API endpoint conversion results. As shown in Figure 5, the process begins with converting all data source endpoints into endpoints with the first segment URL as a group and the second segment URL as a function of the API.  When a user or client makes a request, traveling data flow is initiated. Every user registered with the Microservices Management Information System is validated to possess a credential key consisting of a Client ID and Client Secret, which is used to authorize API Gateway access. The process depicted in Figure 6 can be described as follows: 1. The user performs the authentication process by sending an encrypted credential key as Authorization Basic to the Authentication Server. 2. The Authentication Server receives a response by sending an Access Token to the user. 3. The user sends request data to the API endpoint that is intended for the API Gateway, accompanied by inserting an access token in the header. 4. API Gateway sends the user token as Authorization Bearer to Authentication Server.
The response generated by the Authentication Server is in the form of token validation, which the API Gateway then receives. 5. If the validation result is invalid, then the API Gateway will display a response code "401" with the status "Unauthorized". The API Gateway will forward the user request to the source Webservice if the token validation is valid. 6. The response generated by the source Webservice is then modified by adding the response code, process time, and status.

Interface Implementation
Before using this API service, the user must understand how to obtain the access token. Figure 7 shows information such as the URL to be accessed, the method to be used, the header parameters to be embedded, and the body variables to be embedded. The "Try it out!" button allows users to test the system by entering the encrypted authorization value and login password.

System Performance Analysis
The microservices management system is analyzed to determine the system's capacity to support process performance. Components are tested for data accuracy, processing time, and data security during the analysis stages to identify efficiency.

1) Data Accuracy
Data accuracy on microservices is measured by analyzing several functionalities such as response code, response headers, API time-outs, JSON validation, and text in JSON responses. Figure 9 shows the output generated in the modified success response.  2) Processing Time According to Juliver [17], APIs with an average response time of 0.1 and 1 second are considered high-performance. Twenty attempts are made against a single API endpoint to conduct process time trials. In the Microservices Management System, source and endpoint web services were subjected to testing. The processing time difference between the source web services and microservices management ranged from a minimum of 0.147 seconds to a maximum of 0.569 seconds, with an average processing time difference of 0.199 seconds. SOA processing, where an Authentication Server controls the authorization and user authentication processes and the API Gateway controls route endpoints, input parameters, error handling, recording logs, and modifying response data, slows down the processing time for microservices management data. Figure 10 depicts a comparison chart of API processing time between data source web services and microservices management.

3) Data Security
The process of all data traffic and transactions in microservices management is carried out using a security protocol with OAuth2 authentication. As shown in Figure 11, each user has a Client ID and Client Secret, where the credential key given is a 32-digit random value between A-Z, a-z, and 0-9 [18].

Figure 11. Authorization Key in User
Before the user makes a hit request for token access to the Authentication Server, the authorization key value is obtained by encrypting the Client ID and Client Secret with the Base64 method and then placing it in the header. The response from the Authentication Server will include an access token with an expiration date of 3600 seconds. Figure 12 represents the authentication server's response when the user successfully authorizes the token. { "access_token": "0745fd5bcab3e864c96141942b89406a78735d72", "expires_in": 3600, "token_type": "Bearer", "scope": "app", "refresh_token": "8b61a709c669d985218a68de725bf1c7f031d592" }

Testing Results
The first test was conducted using the white box method to determine the risk level posed by the microservices management system [19]. The obtained cyclomatic complexity value is then used to determine the level of risk using the categories CC 1-10 for low risk, 11-20 for moderate risk, 21-50 for high risk, and >50 for extremely high risk [20]. As shown in Table 2, the test determined that all risks were minimal.  Hit API 6 Low Figure 13 shows the input validation test, which aims to prevent the web service from processing invalid parameters and thereby increasing server load by executing invalid parameters.

Figure 13. Input Parameter Validation Flow
The experiment was conducted by executing 15 input samples with improper parameter modifications. From the 15 input experiments conducted, it was determined that the web service source of the data regarding the suitability of the expectations contributed only 3 out of 15 or 20% of the total value. Table 3 shows experiments on the microservices system of data sources met expectations 14 times out of 15, or 93.33 percent of the time. The following experiment utilized Single Ease Question (SEQ) and System Usability Scale (SUS) with 15 programmer respondents. Respondents were asked to complete eight tasks, and Figure 14 depicts the overall relative efficiency value.  Table 4 shows the respondents were then asked to complete the SUS questionnaire, which yielded a score of 81. Based on the data, the microservices management system's usability was rated as acceptable and adequate, with a B score on a scale from excellent to