Program splitting device and program splitting method

Abstract

To provide a program dividing device and a program dividing method for maintaining consistency in data processing for dividing a program and for dividing a program while suppressing a decrease in performance after the division.SOLUTION: In a program dividing system, a program dividing device 3 for dividing a division object program correlated with transaction into multiple unit programs and creating a new program specifies a call relationship among multiple unit programs and information showing a start position of transaction in the division object program on the basis of the division object program, specifies contents of data access performed by the division object program, and creates a new program by adding information for division to a unit program when determining division of transaction in accordance with the unit program on the basis of a start position on the basis of the call relationship, information showing the start position, and contents of data access.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] The present invention relates to a program splitting device and a program splitting method.

Background Art

[0002] In recent years, influenced by the concept of cloud-native and the agile development process, so-called microservices have attracted attention. Microservice transformation is one of the methods to migrate a monolithic current system's program into a system composed of a collection of multiple small service programs (microservices), which contributes to improving maintainability.

[0003] However, when microservices are adopted, there is a possibility that a transaction (a series of processing groups) that was complete in a monolithic system may be fragmented when split into microservices. As a result, there is a risk that data consistency cannot be maintained between microservices.

[0004] Therefore, for example, Patent Document 1 discloses analyzing the transactions of an existing system using program dependency relationships and generating units of microservices so that the transactions are not fragmented in order to achieve data consistency between microservices.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] However, creating microservices on a transactional basis, as in Patent Document 1, may hinder the maintainability of the microservices because transactions may not correspond to business units, or logic may be duplicated.

[0007] Furthermore, Patent Document 1 does not allow for the division of microservices so that a transaction spans across microservices. In this case, it is conceivable to construct a transaction by building it up from multiple fragmented (separated) transactions (distributed transactions).

[0008] However, distributed transactions require more than just splitting the code; code modifications may be necessary to maintain data integrity. On the other hand, code modifications can degrade performance, so it is preferable to have as few code fragments as possible.

[0009] This invention has been made in view of these circumstances, and its purpose is to provide a program partitioning device and a program partitioning method that can partition a program while maintaining the integrity of data processing and suppressing performance degradation after partitioning. [Means for solving the problem]

[0010] One of the present inventions for solving the above problems is a program partitioning device that partitions a program to be partitioned, which is associated with a predetermined transaction, into a plurality of unit programs to create a new program, comprising: a storage device for storing the program to be partitioned; a program analysis process that identifies the call relationships between the plurality of unit programs and information indicating the starting position of the transaction in the program to be partitioned, based on the program to be partitioned; and the program to be partitioned Each of the two or more unit programs in Data Access Whether or not it writes data to a shared resource A shared resource analysis process to identify, When the aforementioned data access is identified as writing data to a shared resource, Based on the identified call relationship and the information indicating the identified starting position, the transaction is 2 or more The division is performed based on the specified starting position, corresponding to the division of the unit program. and The process for analyzing the location of transaction fragmentation to determine the fragmentation location, and the information for fragmenting the transaction in accordance with the multiple unit programs when it is determined that the transaction should be fragmented. 2 or more This program partitioning device includes a control device that performs transaction partitioning processing, which creates the new program by adding it to a unit program. [Effects of the Invention]

[0011] According to the present invention, program partitioning can be performed while maintaining data processing integrity and suppressing performance degradation after partitioning. Other configurations and effects will be clarified by the following description of the embodiments. [Brief explanation of the drawing]

[0012] [Figure 1] This figure shows an example of the configuration of the program partitioning system according to this embodiment. [Figure 2] This diagram illustrates the configuration of the program to be divided for the purpose of explaining this embodiment. [Figure 3] This is a sequence diagram illustrating the transactions in the program being partitioned. [Figure 4] This diagram illustrates the functions of the program partitioning system and an example of the information managed by the program partitioning system 1. [Figure 5] This figure shows an example of the current system source code. [Figure 6] This figure shows an example of current system database information. [Figure 7] This figure shows an example of microservice design information. [Figure 8] This figure shows an example of the hardware configuration of each information processing device in a program partitioning system. [Figure 9] This flowchart illustrates an example of program partitioning. [Figure 10] It is a diagram showing an example of a method-related information management table. [Figure 11] It is a diagram showing an example of a transaction information management table. [Figure 12] It is a diagram showing an example of a CRUD information management table. [Figure 13] It is a diagram showing an example of a transaction list. [Figure 14] It is a diagram showing an example of a distributed transaction list. [Figure 15] It is a diagram showing another example of a distributed transaction list. [Figure 16] It is a diagram showing an example of a transaction segmentation location list. [Figure 17] It is a flowchart for explaining the details of the transaction segmentation location analysis process. [Figure 18] It is a flowchart for explaining the details of the transaction segmentation location analysis process. [Figure 19] It is a diagram showing an example of source code for a microservice with a handler and a request set. [Figure 20] It is a diagram for explaining an example of microservice source code. <tmp <tmp [Figure 21] It is a diagram showing an example of the configuration of each microservice generated by microservice conversion according to the program division process of this embodiment. <tmp <tmp

Embodiments for Carrying Out the Invention

[0013] <tmp Hereinafter, embodiments of the present invention will be described. <tmp FIG. 1 is a diagram showing an example of the configuration of a program division system 1 according to this embodiment. The program division system 1 includes a current system management device 2 and a program division device 3. Between the current system management device 2 and the program division device 3, for example, the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or a dedicated line <tmp They may be connected by a wired or wireless communication network 5, or they may be connected directly by a communication line.

[0014] The current system management device 2 stores a predetermined program. This program is, for example, an application for providing a predetermined service.

[0015] The program partitioning device 3 supports so-called microservices, which involves dividing the above-mentioned services into multiple parts and reconfiguring them.

[0016] Specifically, the program partitioning device 3 assists in the process of creating a new program by dividing the above-mentioned program (hereinafter referred to as the program to be partitioned) into multiple unit programs (hereinafter referred to as microservices in this embodiment) in units of a transaction, which is a series of processing groups.

[0017] (Class structure of the program to be split) Figure 2 is a diagram illustrating the structure of the program to be divided 20 for explaining this embodiment. The program to be divided 20 is composed of classes, which are groups of processes. In other words, the program to be divided 20 consists of class AA(21), class BB(22), class CC(23), class DD(24), and class EE(25). Furthermore, in the program to be divided 20, there is a call relationship in which class AA(21) calls class BB(22) and class EE(25), class BB(22) calls class CC(23), and class CC(23) calls class DD(24).

[0018] (Transactions of the program to be partitioned) Figure 3 is a sequence diagram illustrating transactions in the program 20 to be partitioned. As will be described later, each class is composed of methods, which are predetermined processing units. Class AA (21) has method AA.aaa (211). Class BB (22) has method BB.bbb (221). Class CC (23) has method CC.ccc (231). Class DD (24) has method DD.ddd (241). Class EE (25) has method EE.eee (251). Note that the combination of classes listed above as processing groups and the methods that constitute those groups are just examples, and other types of combinations are also possible.

[0019] The program to be partitioned, 20, consists of transaction A(31) and transaction B(32). Transaction A(31) consists of methods AA.aaa(211), BB.bbb(221), and EE.eee(251). Transaction B(32) consists of methods CC.ccc(231) and DD.ddd(241). The program to be partitioned, 20, starts with method AA.aaa(211) of transaction A(31).

[0020] In transaction A(31), the first method initiated in that transaction (starting method), method AA.aaa(211), calls methods BB.bbb(221) and EE.eee(251). In transaction B(32), the starting method, method CC.ccc(231), calls method DD.ddd(241).

[0021] Furthermore, the method BB.bbb(221) of transaction AA(31) calls the method CC.ccc(231) of transaction B(32), which is a different transaction from transaction A(31).

[0022] Next, Figure 4 is a diagram illustrating an example of the functions provided by the program partitioning system 1 and the information managed by the program partitioning system 1.

[0023] The current system management device 2 stores the current system source code 200, which is the source code of the program to be partitioned 20; the current system DB information 100, which is a file that stores the configuration of the shared resources (in this embodiment, a database) accessed by the methods of the program to be partitioned 20; and the microservice design information 300, which is information regarding the configuration of the microservices obtained by partitioning the program to be partitioned 20. Note that this information may be stored by the program partitioning device 3, or the program partitioning device 3 may obtain it from other information processing systems.

[0024] (Current system source code) Here, Figure 5 shows an example of the current system source code 200 (however, the part related to database access is omitted). As mentioned above, in the current system source code 200 (program 20 to be divided), class AA has method AA.aaa(201). Class BB has method BB.bbb(202). Class CC has method CC.ccc(203). Class DD has method DD.ddd(204). Class EE has method EE.eee(205).

[0025] Method AA.aaa(201) has calling parts 206 and 207 that call other methods (method BB.bbb(202), method EE.eee(205)).

[0026] Furthermore, since the method AA.aaa(201) is a start method, it has information indicating the starting position of a transaction (hereinafter referred to as the start annotation). Specifically, the method AA.aaa(201) has a first start annotation 208 (@Transactional) that indicates that the method AA.aaa(201) is a method for starting a new transaction when no transaction currently exists (not being executed) (however, it does not start a new transaction if another transaction is already running).

[0027] Next, method BB.bbb(202) has a caller 209 that calls another method (method CC.ccc(203)). Method CC.ccc(203) has a caller 210 that calls another class (method DD.ddd(204)).

[0028] Furthermore, the method CC.ccc(203) is an initiation method and therefore has an initiation annotation. However, this initiation method is different from that of the method AA.aaa(201). Specifically, the method CC.ccc(203) has a second initiation annotation 211 (@Transactional(propagation=Propagation.REQUIRES_NEW)) which indicates that it is a method for starting a new transaction (however, it starts a new transaction whether or not another transaction exists).

[0029] (Current system database information) Next, Figure 6 shows an example of the current system DB information 100. The figure also shows an example of the current system source code 200, which describes the methods for accessing the database shown in this current system DB information 100.

[0030] The current system DB information 100 stores the content or type of data processing (access) performed by each database. In the example shown in the figure, it stores the definition 101 (select) of the process of selecting (reading) data in the database, and the definition 102 (update) of the process of updating (writing) data in the database. The data processing is an example; for instance, there may also be processes for adding or deleting data. Furthermore, the current system DB information 100 stores the details 103 and 104 of the processes corresponding to the definitions 101 and 102 described above.

[0031] When such current system DB information 100 is set, the methods of the current system source code 200 include, for example, database access units 105 and 106 that perform the access defined in the current system DB information 100 to the database defined in the current system DB information 100.

[0032] (Microservice design information) Next, Figure 7 shows an example of microservice design information 300. Microservice design information 300 is information that stores the configuration of each microservice generated by microservice implementation. Specifically, microservice design information 300 has data items including a microservice name 301 in which the name of each microservice is set, and a method name 302 in which the names of each method constituting that microservice are set. The contents of microservice design information 300 may be set by the user, or a predetermined program may automatically create it.

[0033] In this embodiment, as shown in Figure 7, we will implement microservices by retaining AA.aaa and BB.bbb as microservice A among the methods of the current system, and separating CC.ccc, DD.ddd, and EE.eee as a new microservice B.

[0034] Next, as shown in Figure 4, the program partitioning device 3 comprises the following functional units: a method analysis unit 311 (program analysis unit), a microservice source code generation unit 312, a CRUD analysis unit 313 (shared resource analysis unit), a transaction partitioning location analysis unit 314, and a transaction partitioning unit 315.

[0035] The method analysis unit 311 identifies, based on the program to be partitioned 20, information on the call relationships between methods of multiple unit programs (i.e., microservices) (hereinafter referred to as method relationship information) and information indicating the location of the method that initiates a transaction in the program to be partitioned 20 (starting method) (starting annotation; specifically, the first starting annotation or the second starting annotation).

[0036] The method analysis unit 311 stores method relationship information in the method relationship information management table 400, and the transaction information indicated by the start annotation (hereinafter referred to as transaction information) in the transaction information management table 500. Details of these databases will be described later.

[0037] The CRUD analysis unit 313 identifies the content of the data access performed by each method of the program 20 to be divided. The CRUD analysis unit 313 stores the identified data access information (hereinafter referred to as CRUD information) in the CRUD information management table 600. Details of the CRUD information management table 600 will be described later.

[0038] The transaction fragmentation location analysis unit 314 determines whether to associate the transaction with a microservice and fragment it based on the start annotation (location of the start method), based on the call relationships (method relationship information), start annotations, and data access details identified by the method analysis unit 311, and the CRUD analysis unit 313.

[0039] Furthermore, the transaction fragmentation location analysis unit 314 analyzes the transaction fragmentation location. The information is stored in the transaction partition location list 700. The transaction partition location analysis unit 314 also generates a distributed transaction list 800, which is a list of transactions (distributed transactions) that are partitioned by the partition locations. Details of the transaction partition location list 700 will be described later.

[0040] The microservice source code generation unit 312 acquires microservice design information 300, which stores each method that constitutes the microservice. Then, the microservice source code generation unit 312 creates microservice source code 900 by adding call information to one microservice for calling the other microservice from the other microservice. In this embodiment, this call information is REST This is assumed to be API code. Details will be provided later.

[0041] When the transaction partitioning location analysis unit 314 determines that a transaction should be partitioned, the transaction partitioning unit 315 adds information (partitioning logic) to the microservice (microservice source code 900) to partition the transaction so that it corresponds to multiple microservices, thereby creating a microservice source code 1000, which is a program that has been converted into microservices from the program to be partitioned 20 (current system source code 200).

[0042] Specifically, when the transaction partitioning unit 315 determines that a transaction should be partitioned, it creates microservice source code 1000 by adding information (partitioning logic) for partitioning the transaction to correspond to multiple microservices to one of the unit programs to which the above-mentioned call information has been added.

[0043] Next, Figure 8 shows an example of the hardware configuration of each information processing device (current system management device 2, program processing device 3) in the program partitioning system 1. Each information processing device includes a control device 91 such as a CPU (Central Processing Unit), a main memory 92 such as RAM (Random Access Memory) or ROM (Read Only Memory), an auxiliary storage device 93 such as an HDD (Hard Disk Drive) or SSD (Solid State Drive), and a keyboard. The system consists of an input device 94 such as a keyboard, mouse, or touch panel, an output device 95 such as a display or touch panel, and a communication module composed of a NIC (Network Interface Card), wireless communication module, USB (Universal Serial Interface) module, or serial communication module. It is equipped with a signaling device 96.

[0044] The functions of each information processing unit in the program partitioning system 1 described above are realized by the control device 91 reading programs from the main memory 92 or auxiliary memory 93. Furthermore, each program can be recorded and distributed, for example, on a portable or fixed recording medium. These programs, in whole or in part, may be realized using virtual information processing resources provided using virtualization technology, process space isolation technology, etc., such as virtual servers provided by a cloud system. Also, all or part of these programs may be realized by services provided by a cloud system via an API (Application Programming Interface), etc. Next, we will explain the processing performed by the program partitioning system 1.

[0045] <Program splitting process> Figure 9 is a flowchart illustrating an example of the processing (program splitting process) performed by the program splitting system 1. The program splitting process is initiated, for example, when the program splitting device 3 acquires the current system source code 200.

[0046] First, the method analysis unit 311 of the program partitioning device 3 analyzes the current system source code 200 and creates a method relationship information management table 400 and a transaction information management table 500 (s11).

[0047] Specifically, for example, the method analysis unit 311 creates a method relationship information management table 400 by identifying the calling part of each method in the current system source code 200 and the called part specified by the calling part.

[0048] Furthermore, the method analysis unit 311 creates a transaction information management table 500 by identifying the first start annotation and the second start annotation from each method of the current system source code 200.

[0049] (Method Relationship Information Management Table) Here, Figure 10 shows an example of a method relationship information management table 400. The method relationship information management table 400 has data items including a calling method 401 in which the name of the calling method is set, and a called method 402 in which the name of the called method is set.

[0050] (Transaction information management table) Figure 11 shows an example of the transaction information management table 500. The transaction information management table 500 has data items including: a method name 501 in which the name of each method in the current system source code 200 is set; a first start method 502 in which information (hereinafter referred to as the first flag) indicating whether or not the method is the start method in a new transaction to be started if no transaction exists (hereinafter referred to as the first start method) (○, ×); and a second start method 503 in which information (hereinafter referred to as the second flag) indicating whether or not the method is the start method in a new transaction to be started even if a transaction already exists (hereinafter referred to as the second start method) (○, ×). In other words, the first flag is set for methods in which a first start annotation or a second start annotation exists. The second flag is set for methods in which a second start annotation exists.

[0051] Next, as shown in Figure 9, the CRUD analysis unit 313 of the program partitioning device 3 acquires the current system DB information 100, and based on the acquired current system DB information 100 and the current system source code 200, identifies the databases accessed by each method of the current system source code 200 and the content of those accesses, and creates a CRUD information management table 600 (s13).

[0052] For example, the CRUD analysis unit 313 identifies the database access units 105 and 106 that make database calls among the methods of the current system source code 200, and obtains the name of the database and the content (type) of the data access indicated by the identified database access units 105 and 106 from the DB information 100.

[0053] (CRUD information management table) Figure 12 shows an example of a CRUD information management table 600. The CRUD information management table 600 has data items including a method 601 in which the name of each method is set, a DB table 602 in which the name of the database accessed by that method is set, and a CRUD 603 in which the content or type of data access to that database is set. Note that CRUD 603 includes information indicating that the data access is a data write (new addition) ("C"), information indicating that the data access is a data read (selection) ("R"), and information indicating that the data access is a data write (update). Information indicating that the data access is a write (delete) ("U"), information indicating that the data access is a write (delete) ("D"), etc., are set.

[0054] Next, as shown in Figure 9, the transaction splitting location analysis unit 314 of the program splitting device 3 determines whether or not to split the transaction related to the start annotation based on the method relationship information management table 400 and transaction information management table 500 created in s11 and the CRUD information management table 600 created in s13, and executes a transaction splitting location analysis process s15 to analyze the location of the split.

[0055] Specifically, the transaction partition analysis unit 314 creates a transaction list 1300, which stores a list of the call relationships of each method belonging to each transaction and the database access details accessed by each method, and a distributed transaction list 800, which is data in which microservice information is added to the transaction list 1300.

[0056] Then, the transaction fragmentation analysis unit 314 identifies the fragmentation points in each transaction based on the distributed transaction list 800. The transaction fragmentation analysis unit 314 then creates a transaction fragmentation list 700 that stores the information of the fragmentation points.

[0057] (Transaction list) Figure 13 shows an example of a transaction list 1300. The transaction list 1300 has data items including a transaction ID 1301 in which the transaction identifier is set, a method 1302 in which the method belonging to that transaction is set, a caller 1303 in which the method that calls that method (calling method) is set, a DB table 1304 in which the database accessed by that method is set, and a CRUD 1305 in which the content or type of the access is set.

[0058] (Distributed transaction list) Figure 14 shows an example of a distributed transaction list 800. This distributed transaction list 800 has various data items, including a transaction ID 801 in which the transaction identifier is set, a microservice name 802 in which the microservice corresponding to that transaction is set, a method 803 in which the method belonging to the transaction is set, a caller 804 in which the method that calls that method (calling method) is set, a DB table 805 in which the database accessed by that method is set, and a CRUD 806 in which the content or type of the access is set.

[0059] In this example, in each microservice corresponding to transaction A (microservice A being converted from the current system, and microservice B being separated and partitioned from the current system (microservice A)), both the current system being converted to microservices and the different microservices in microservice B are performing data writing or updating to the database. In other words, multiple microservices are performing the process of writing data to the database.

[0060] (Distributed transaction list) Figure 15 shows another example of the distributed transaction list 800. In this distributed transaction list 800, each microservice corresponding to transaction A (microservices to be converted from the current system (microservice A), and microservice B to be separated and partitioned from the current system) The current system being refactored (microservice A) reads data from the database, while microservice B writes or updates data to the database. In other words, a single microservice handles the process of writing data to the database.

[0061] (List of transaction fragmentation points) Figure 16 shows an example of a transaction partition location list 700. The transaction partition location list 700 has data items including a number 701 which sets the sequential number of the partition location in the transaction, a microservice name 702 which sets the name of the microservice corresponding to the transaction in which the partition location exists, a transaction start method name 703 which sets the transaction start method due to partitioning at that location, a calling microservice name 704 which sets the microservice that is calling the method in the method call between the partitioned transactions, a partition calling method name 705 which sets the method being called by that microservice, a called microservice name 706 which sets the microservice that is being called in the method call between the partitioned transactions, and a partition called method name 707 which sets the method being called by that microservice.

[0062] <Transaction fragmentation analysis process> Here, Figures 17 and 18 are flowcharts that explain the details of the transaction fragmentation analysis process s15 (divided into two figures due to space limitations).

[0063] First, as shown in Figure 17, the transaction fragmentation analysis unit 314 selects one of the methods of the current system source code 200 by retrieving one record from the transaction information management table 500 (s151).

[0064] The transaction partition analysis unit 314 determines whether the selected method (hereinafter referred to as the selected method) is the first start method (s152). Specifically, the transaction partition analysis unit 314 determines whether the first start method 502 of the record obtained in s151 indicates the first start method (○).

[0065] If the selected method is the first start method (s152:Yes), the transaction partition analysis unit 314 executes the process in s153. If the selected method is not the first start method (s152:No), the transaction partition analysis unit 314 executes the process in s155.

[0066] In s153, the transaction partition analysis unit 314 sets information indicating that the selection method will be the starting method for a distributed transaction. Specifically, the transaction partition analysis unit 314 creates a record of the transaction related to the selection method in the transaction list 1300, sets the selection method in the method 1302 of the created record, and sets "-" (no caller) in the caller 1303.

[0067] Furthermore, the transaction partition analysis unit 314 sets information about the database accessed by the selection method and the details of that access (s154). Specifically, the transaction partition analysis unit 314 retrieves the record related to the selection method from the CRUD information management table 600, sets the contents of the DB table 602 of the retrieved record to the DB table 1304 of the record in the created transaction list 1300, and sets the contents of the CRUD 603 of the retrieved record to the CRUD 1305 of the record in the created transaction list 1300. After that, the process in s155 is performed.

[0068] In s155, the transaction partition analysis unit 314 checks whether there are any unselected methods in the current system source code 200. If there are unselected methods, it repeats the process in s151 to select them. If there are no unselected methods, the transaction partition analysis unit 314 executes the process in s156.

[0069] In s156, the transaction fragmentation analysis unit 314 obtains one of the transactions in the current system source code 200 by obtaining one record from the transaction list 1300 created above.

[0070] The transaction fragmentation analysis unit 314 sets status information (s157) indicating that there may be other methods in the transaction selected in s156 (hereinafter referred to as the selected transaction). Here, the transaction fragmentation analysis unit 314 sets the variable "newMethod" to "true".

[0071] The transaction partition analysis unit 314 has the variable "newMethod" set to "true". Check whether it is true or false (s158). The variable "newMethod" is set to "true". If (s158:Yes), the transaction partition analysis unit 314 executes the process in s159; if the variable "newMethod" is set to "false" (s158:No), the transaction partition analysis unit 314 executes the process in s160.

[0072] In s160, the transaction fragmentation analysis unit 314 checks whether there are any unselected transactions in the current system source code 200. If there are unselected transactions, it repeats the process in s156 to select their method. If there are no unselected transactions, the transaction fragmentation analysis unit 314 executes the process in s169, which will be described later.

[0073] In s159, the transaction partition analysis unit 314 sets status information indicating that there are no other possible methods. Here, the transaction partition analysis unit 314 sets the variable "newMethod" to "false". After that, the processing in s161 is performed.

[0074] In s161, the transaction fragmentation analysis unit 314 selects one of the methods in the selected transaction by obtaining one of the records related to the selected transaction in the transaction list 1300.

[0075] Furthermore, in s162, the transaction fragmentation analysis unit 314 has not yet set any information indicating that it will be a transaction method, and selects one of the methods called from the method selected in s161 (hereinafter referred to as the first selected method) by obtaining one record from the transaction information management table 500.

[0076] Then, the transaction partition analysis unit 314 determines whether the method selected in s162 (hereinafter referred to as the second selected method) is the second start method (s163). Specifically, the transaction partition analysis unit 314 determines whether the second start method 503 of the record obtained in s162 indicates the second start method (○).

[0077] If the second selection method is the second start method (s163:Yes), the transaction partition analysis unit 314 executes the process in s167. If the second selection method is not the second start method (s163:No), the transaction partition analysis unit 314 executes the process in s164.

[0078] In s164, the transaction fragmentation analysis unit 314 sets information indicating that the second selection method is a transaction method. Specifically, the transaction fragmentation analysis unit 314 creates a record of the transaction related to the second selection method in the transaction list 1300, sets the second selection method in the method 1302 of the created record, and sets the method calling the second selection method (for example, the second start method) in the caller 1303.

[0079] Furthermore, the transaction partition analysis unit 314 sets information about the database accessed by the second selection method and the details of that access (s165). Specifically, the transaction partition analysis unit 314 retrieves the record related to the second selection method from the CRUD information management table 600, sets the contents of the DB table 602 of the retrieved record to the DB table 1304 of the record in the created transaction list 1300, and sets the contents of the CRUD 603 of the retrieved record to the CRUD 1305 of the record in the created transaction list 1300. Then, the transaction partition analysis unit 314 sets the variable "newMethod" to indicate if there are other methods in the selected transaction. Set to "true" to indicate that it is possible. (s166). Then the process in s167 is performed.

[0080] In s167, the transaction partition analysis unit 314 checks whether there are any other methods that have not been set to indicate that they will be a transaction method and are being called from the first selected method. If such a method exists, it repeats the process in s162 to select that method. If there are no other methods that have not been set to indicate that they will be a distributed transaction method and are being called from the first selected method, the transaction partition analysis unit 314 executes the process in s168.

[0081] In s168, the transaction fragmentation analysis unit 314 checks whether there are any unselected methods in the selected transaction. If there are, it repeats the process in s161. If there are no unselected methods in the selected transaction, it repeats the process from s158 onwards.

[0082] Next, as shown in Figure 18, the transaction fragmentation analysis unit 314 creates a distributed transaction list 800 by adding microservice information to the transaction list 1300 created above (s169, s170).

[0083] Specifically, the transaction partition analysis unit 314 creates a new database, the distributed transaction list 800, by adding the data item for the microservice name 802 and its empty information to the transaction list 1300. Then, the transaction partition analysis unit 314 retrieves the method 803 of each record in the transaction list 1300, and sets the content of the microservice name 301 of the record in the microservice design information 300 where the method indicated by the retrieved method 803 is set as the method name 302, to the microservice name 802 of each record in the distributed transaction list 800.

[0084] Then, the transaction fragmentation analysis unit 314 selects one of the distributed transactions by obtaining the contents of each record related to a transaction in the distributed transaction list 800 (s171).

[0085] The transaction fragmentation analysis unit 314 analyzes the distributed transaction selected in s171. In this process, it is determined whether multiple microservices are performing the process of writing data to the database (s172).

[0086] Specifically, the transaction partition analysis unit 314 refers to the CRUD806 of each record obtained in s171 and determines whether data related to writing or updating is set in CRUD806 for multiple records.

[0087] If multiple microservices are writing data to the database (s172:Yes), the transaction partition analysis unit 314 executes s173. If multiple microservices are not writing data to the database (s172:No), the transaction partition analysis unit 314 executes s174.

[0088] In s173, the transaction partition analysis unit 314 adds information about the microservice and its method that wrote or updated data to the database, as identified in s172, to the transaction partition list 700. For example, the transaction partition analysis unit 314 retrieves the contents of each record referenced in s172 and adds the retrieved contents to a new record in the transaction partition list 700. After that, the processing in s174 is performed.

[0089] In s174, the transaction fragmentation analysis unit 314 checks whether there are any unselected distributed transactions. If there are, it repeats the process in s171 to select those unselected distributed transactions. If there are no unselected distributed transactions, the transaction fragmentation analysis process s15 terminates.

[0090] On the other hand, as shown in Figure 9, the microservice source code generation unit 312 creates microservice source code 900 by applying predetermined call information (code) for calling one microservice from another to the current system source code 200, based on the method relationship information management table 400 and transaction information management table 500 created in s11 (s19).

[0091] For example, first, the microservice source code generation unit 312 identifies each method of the microservice to be separated from the current system based on the microservice design information 300 and the method relationship information management table 400. Then, for each identified method, the microservice source code generation unit 312 identifies a handler that indicates that it will accept calls from other microservices, and creates microservice source code 900 with the identified code set in the respective method parts.

[0092] Furthermore, the microservice source code generation unit 312 identifies methods that call each of the identified methods based on the microservice design information 300 and the method relationship information management table 400. The microservice source code generation unit 312 then identifies requests for calling other microservices corresponding to each handler set above, and creates microservice source code 900 by setting the identified code in the part of the method that calls each of the identified methods. Note that the handler and request codes are registered in advance in a predetermined database, for example.

[0093] (Source code for microservices) Figure 19 shows an example of source code 900 for a microservice with handlers and requests configured. First, in microservice B (1920), which is separated from the current system 1910 that has been microserviced, the methods CC.ccc (1901), DD.ddd (1902), and EE.eee are called from the methods of the current system. The handlers CCHandler(1904), DDHandler(1905), and EEHandler(1906), which are associated with (1903), are set accordingly.

[0094] Furthermore, of the methods CC.ccc(1901), DD.ddd(1902), and EE.eee(1903) of microservice B(1920), the current system 1910 calls CC.ccc(1901) and EE.eee(1903). Therefore, in the current system 1910, the caller methods AA.aaa and BB.bbb, which correspond to CC.ccc(1901) and EE.eee(1903), are configured with corresponding requests httpRequest(1907) and(1908), respectively.

[0095] In the example shown in the diagram, the request and handler are implemented using a REST API (API call), but this is not intended to be the only way to implement them.

[0096] Next, as shown in Figure 9, the transaction partitioning unit 315 creates microservice source code 1000 by partitioning the transaction at the partition points indicated by the transaction partition point list 700 created in s15, based on the microservice source code 900 created in s19, thereby creating a distributed transaction.

[0097] For example, the transaction partitioning unit 315 creates microservice source code 1000 by adding code indicating that it is a distributed transaction start method before the start method of the microservice source code 900 indicated by the transaction start method name 703 of each record in the transaction partitioning location list 700.

[0098] Figure 20 illustrates an example of microservice source code 1000 (for reference, an example of transaction partitioning location list 700 is also shown). As shown in the figure, if the current system (microservice A) is set as microservice name 702 in transaction partitioning location list 700, method AA.aaa is set as transaction start method name 703, the current system is set as calling microservice name 704, method AA.aaa is set as partitioning caller method name 705, microservice B is set as called destination microservice name 706, and method EE.eee is set as partitioning call destination method name 707, then immediately before class AA.aaa(2001), which is the start method of the current system (microservice A) in microservice source code 1000, the first partitioning logic, annotation 2002 (@MsaTransactional), which is the first partitioning logic to partition the transaction to correspond to a microservice, is placed. The annotation is added. Additionally, the second annotation 2003 (@MsaBranch), which is the second partitioning logic for partitioning transactions to correspond to microservices, is added to the EEHandler(2004) hand, which corresponds to the EE.eee method of the distributed transaction microservice that is called after partitioning in the microservice source code 1000.

[0099] In this example, we have explained the case of adding annotations, but other logic that distributed transactions should implement (for example, rollback logic) can also be added (e.g., Saga pattern, Two Phase Commit).

[0100] Figure 21 shows an example of the configuration of each microservice generated as a result of the program partitioning process in this embodiment.

[0101] First, with the adoption of microservices, the microservice to which methods AA.aaa and BB.bbb belong (Microservice A) and the microservice to which method EE.eee belong The microservice (Service B) will be separated.

[0102] Here, class AA (method AA.aaa) of microservice A based on the current system calls class EE (method EE.eee) of another microservice (microservice B), so handler 2101 is set in class EE and a request for REST communication 2102 is set in class AA. Similarly, class BB (method BB.bbb) of microservice A based on the current system calls class CC (method CC.ccc) of another microservice (microservice B), so handler 2103 is set in class CC and a request for REST communication 2104 is set in class BB.

[0103] Furthermore, due to the microservices architecture, a call from AA.aaa to EE.eee (handler 2101) will span across microservices. Therefore, separation logics 2105 and 2106 are set in the call from AA.aaa to EE.eee (handler 2101). Similarly, due to the microservices architecture, a call from BB.bbb to CC.ccc (handler 2103) will span across microservices. Therefore, separation logics 2107 and 2108 are set in the call from BB.bbb to CC.ccc (handler 2103).

[0104] As described above, the program partitioning device 3 of this embodiment determines whether or not to partition a transaction in accordance with a microservice based on the call relationships between microservices, start annotations, and the content of data access performed by the program to be partitioned 20. If it determines that the transaction should be partitioned based on the start annotation, it creates a microservice program by adding partitioning logic to the microservice.

[0105] In this way, the program partitioning device 3 determines whether or not to partition a transaction based on the start annotation, corresponding it to a microservice, according to the call relationships between microservices and the content of data access. Therefore, it is possible to partition transactions only where necessary (by adopting a distributed transaction method) so that problems do not occur with data access by transactions (for example, so that data integrity can be guaranteed by transactions).

[0106] As described above, the program partitioning device 3 of this embodiment makes it possible to partition a program while maintaining the integrity of data processing and suppressing performance degradation after partitioning.

[0107] Furthermore, the program partitioning device 3 of this embodiment identifies whether the data access performed by two or more microservices in the program to be partitioned 20 involves writing data to the database, and if it determines that the data access involves writing data to the database, it determines to partition the transaction according to the microservice.

[0108] This prevents data inconsistencies that could arise from different microservices writing data to the database (for example, through logic such as rollback).

[0109] Furthermore, the program partitioning device 3 of this embodiment adds call information (for example, code for performing REST communication) to one of the microservices for calling the other microservice from the other microservice, and creates a microservice program by adding partitioning logic to the microservice to which this call information has been added.

[0110] This allows microservices-based programs to function correctly even when there are calls that span across microservices.

[0111] Furthermore, the program partitioning device 3 of this embodiment determines whether to divide a transaction based on the location of the starting method, corresponding the transaction to a microservice, based on the call relationships between the methods of the microservice, the starting method, and the content of the data access performed by each method of the program to be partitioned 20. If it determines that the transaction should be divided, it creates a microservice program by adding the division logic to the location of the starting method.

[0112] In this way, by identifying and splitting transaction fragments based on the method, it is possible to ensure consistent data processing.

[0113] The present invention is not limited to the embodiments described above, and can be implemented using any components without departing from its spirit. The embodiments and modifications described above are merely examples, and the present invention is not limited to these as long as the features of the invention are not impaired. Furthermore, although various embodiments and modifications have been described above, the present invention is not limited to these. Other embodiments conceivable within the scope of the technical idea of ​​the present invention are also included within the scope of the present invention.

[0114] For example, some of the hardware components of each device in this embodiment may be provided in other devices.

[0115] Furthermore, each program of each device may be provided in other devices, a program may consist of multiple programs, or multiple programs may be integrated into a single program. [Explanation of symbols]

[0116] 3 Program division device, 20 Programs to be divided, 311 Method analysis unit, 312 Microservice source code generation unit, 313 analysis unit, 314 transaction fragmentation location analysis unit, 315 transaction fragmentation unit

Claims

1. A program partitioning device that divides a program to be partitioned, which is associated with a predetermined transaction, into multiple unit programs to create a new program, A storage device for storing the program to be divided, and A program analysis process that identifies the call relationships between the plurality of unit programs and information indicating the starting position of the transaction in the program to be divided, based on the program to be divided. A shared resource analysis process that determines whether the data access performed by each of the two or more unit programs in the program to be divided involves writing data to a shared resource, When it is determined that the aforementioned data access involves writing data to a shared resource, a transaction splitting location analysis process determines, based on the identified call relationship and the information indicating the identified starting position, that the transaction should be split according to the division of the two or more unit programs, with the identified starting position as the basis for the splitting. A control device that, when it determines that the transaction should be divided, executes a transaction division process that creates a new program by adding information to two or more unit programs to divide the transaction in accordance with the multiple unit programs. A program splitting device equipped with the following features.

2. The control device is A microservice source code generation process is executed which adds call information to one of the unit programs for calling the other unit program from the other unit program. In the transaction splitting process, if it is determined that the transaction should be split, a new program is created by adding information to one of the unit programs to which the call information has been added, which is used to split the transaction so that it corresponds to the multiple unit programs. The program splitting device according to claim 1.

3. The aforementioned storage device stores the program to be divided, which is composed of methods that are units of processing. The control device is In the program analysis process described above, based on the program to be divided, the call relationships between the methods of the multiple unit programs and information indicating the location of the method that initiates the transaction in the program to be divided are identified. In the shared resource analysis process, it is determined whether the data access performed by each method of the program to be partitioned involves writing data to the shared resource. When it is determined that the aforementioned data access involves writing data to a shared resource, the transaction splitting location analysis process determines, based on the identified call relationship and the location of the identified method, that the transaction should be split according to the division of the two or more unit programs, with the location of the identified method as the basis. In the transaction splitting process, if it is determined that the transaction should be split, the new program is created by adding information for splitting the transaction in accordance with the multiple unit programs to the location of the specified method in the two or more divided unit programs. The program splitting device according to claim 1.

4. A program partitioning method that divides a program to be partitioned, which is associated with a predetermined transaction, into multiple unit programs to create a new program, Information processing device, The program to be divided is stored, A program analysis process that identifies the call relationships between the plurality of unit programs and information indicating the starting position of the transaction in the program to be divided, based on the program to be divided. A shared resource analysis process that determines whether the data access performed by each of the two or more unit programs in the program to be divided involves writing data to a shared resource, When it is determined that the aforementioned data access involves writing data to a shared resource, a transaction splitting location analysis process determines, based on the identified call relationship and the information indicating the identified starting position, that the transaction should be split according to the division of the two or more unit programs, with the identified starting position as the basis for the splitting. If it is determined that the transaction should be divided, the system executes a transaction division process that creates a new program by adding information to two or more unit programs that allows the transaction to be divided in accordance with the multiple unit programs. Program division method.

5. The aforementioned information processing device A microservice source code generation process is executed which adds call information to one of the unit programs for calling the other unit program from the other unit program. In the transaction splitting process, if it is determined that the transaction should be split, a new program is created by adding information to one of the unit programs to which the call information has been added, which is used to split the transaction so that it corresponds to the multiple unit programs. The program splitting method according to claim 4.

6. The aforementioned information processing device stores a program to be divided, which is composed of methods that are units of processing. The aforementioned information processing device In the program analysis process described above, based on the program to be divided, the call relationships between the methods of the multiple unit programs and information indicating the location of the method that initiates the transaction in the program to be divided are identified. In the shared resource analysis process, it is determined whether the data access performed by each method of the program to be partitioned involves writing data to the shared resource. When it is determined that the aforementioned data access involves writing data to a shared resource, the transaction splitting location analysis process determines, based on the identified call relationship and the location of the identified method, that the transaction should be split according to the division of the two or more unit programs, with the location of the identified method as the basis. In the transaction splitting process, if it is determined that the transaction should be split, the new program is created by adding information for splitting the transaction in accordance with the multiple unit programs to the location of the specified method in the two or more divided unit programs. The program splitting method according to claim 4.

Images