API adapter generation device, API adapter generation method, and API adapter generation program

Abstract

The present invention comprises: a conversion rule calculation unit (16) that acquires a data model of an orchestrator (210) and an API specification of a management target, and calculates a model conversion rule by performing schema matching on the basis of the data schema of the orchestrator and the data schema of the API specification; a call logic unit generation unit (19) that rewrites, on the basis of the model conversion rule, the source code of an API call logic unit 232 in which API adapter execution logic is written; and an API adapter generation unit (21) that generates an API adapter of the management target on the basis of the API call logic unit that has had the source code rewritten.

Description

[Technical field]

[0001] The present invention relates to an API adapter generating device, an API adapter generating method, and an API adapter generating program. [Background technology]

[0002] In order to build and operate a service by combining multiple wholesale partner services, an orchestrator that links multiple services is used. When adding a new wholesale service (service to be managed) or when changing the specifications of an existing service, the orchestrator is required to add or change an API adapter at low cost and in a short period of time.

[0003] Non-Patent Document 1 discloses a technology for automatically generating an API adapter that absorbs the differences in API specifications for each service to be used. In addition, Non-Patent Document 2 discloses the automation of part of the testing of control signals and data signals between the API adapter and the wholesale service. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] Take, et al., “A Study on Facilitating Web API Adapter Development,” September 2017, Institute of Electronics, Information and Communication Engineers (IEICE) NWS Study Group [Non-Patent Document 2] Sho Kanamaru, Tomoki Ikeya, Kensuke Takahashi, Tsuyoshi Toyoshima, "Proposal of a Comprehensive Test Automation Method for C-Plane and U-Plane of API Adapter", IEICE Technical Report Summary of the Invention [Problem to be solved by the invention]

[0005] However, the process of generating an API adapter includes a design process, an implementation process, and a test process, and the technology disclosed in the above-mentioned Non-Patent Document 1 does not describe automating the design process, so the user must manually perform the design process. This causes a problem in that it is difficult to reduce costs and time required for adding an API adapter or changing specifications.

[0006] The present invention has been made in consideration of the above-mentioned circumstances, and has as its object to provide an API adapter generation device, an API adapter generation method, and an API adapter generation program that make it possible to add API adapters and change specifications at low cost and in a short period of time. [Means for solving the problem]

[0007] An API adaptor generation device of one aspect of the present invention includes a conversion rule calculation unit that acquires a data model of an orchestrator and an API specification to be managed, performs schema matching based on the data schema of the orchestrator and the data schema of the API specification, and calculates a model conversion rule, a generation unit that rewrites source code of an API call logic unit that describes API adapter execution logic based on the model conversion rule, and an API adapter generation unit that generates the API adapter to be managed based on the API call logic unit whose source code has been rewritten.

[0008] An API adapter generation method according to one aspect of the present invention is a computer-implemented API adapter generation method, comprising the steps of: acquiring a data model of an orchestrator and an API specification to be managed; performing schema matching based on the data schema of the orchestrator and the data schema of the API specification to calculate model conversion rules; rewriting source code of an API call logic section that describes API adapter execution logic based on the model conversion rules; and generating the API adapter to be managed based on the API call logic section whose source code has been rewritten.

[0009] One aspect of the present invention is an API adaptor generation program for causing a computer to function as the API adaptor generation device. Effect of the Invention

[0010] According to the present invention, it becomes possible to add and change the use of API adapters at low cost and in a short period of time. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram showing a configuration of a network system in which an API adaptor generation device according to an embodiment is employed. [Diagram 2] FIG. 2 is a block diagram showing the configuration of an API adaptor generation device and an API adaptor according to the embodiment. [Diagram 3] FIG. 3 is a block diagram showing the configuration of the API adaptor generation device according to the first embodiment. [Figure 4] FIG. 4 is an explanatory diagram showing an example of converting an API specification described in an open API specification format into a data model in a UML format. [Figure 5A] FIG. 5A is an explanatory diagram showing resource design and parameter design of data models M1 and M2 of companies A and B when generating API adapters for services to be managed by the companies. [Figure 5B] FIG. 5B is an explanatory diagram showing conversion of parameter values ​​of data models M1 and M2 of companies A and B when generating API adapters for services to be managed by the companies. [Figure 5C] FIG. 5C is an explanatory diagram showing the relationship between the orchestrator AP and the orchestrator. [Figure 6A] FIG. 6A is an explanatory diagram showing the execution order of APIs when a plurality of APIs are collectively managed. [Figure 6B] FIG. 6B is an explanatory diagram showing the logic design of each data model when adding managed services by companies C, D, and E. [Figure 7A] FIG. 7A is an explanatory diagram showing the correspondence relationship when converting resources and parameters of a data model M1 into resources and parameters of a data model M3 of the orchestrator. [Figure 7B] FIG. 7B is an explanatory diagram showing source code in which the resources and parameters shown in FIG. 7A are described. [Figure 8A] FIG. 8A is an explanatory diagram showing the correspondence relationship when converting parameter values ​​of a data model M1 into parameter values ​​of a data model M3 of the orchestrator. [Figure 8B] FIG. 8B is an explanatory diagram showing source code in which the parameter values ​​shown in FIG. 8A are described. [Figure 9] FIG. 9 is a flowchart showing a processing procedure of the API adaptor generation device according to the first embodiment. [Figure 10] FIG. 10 is a block diagram showing a configuration of an API adaptor generation device according to the second embodiment. [Figure 11] FIG. 11 is an explanatory diagram showing the correspondence relationship when converting resources and parameters of the data models M11 to M13 into resources and parameters of a data model M14 of the orchestrator. [Figure 12] FIG. 12 is an explanatory diagram showing a procedure for generating source code of a data model in accordance with the conversion rules according to the second embodiment. [Figure 13] FIG. 13 is an explanatory diagram showing source code in which the resources and parameters shown in FIG. 11 are described. [Figure 14] FIG. 14 is a block diagram showing a configuration of an API adaptor generation device according to the third embodiment. [Figure 15A] FIG. 15A is an explanatory diagram showing the relationship between the orchestrator AP and the orchestrator according to the third embodiment. [Figure 15B] FIG. 15B is an explanatory diagram showing source code in which the resources and parameters shown in FIG. 15A are described. [Figure 15C] FIG. 15C is an explanatory diagram showing instance information of the source code shown in FIG. 15B. [Figure 15D] FIG. 15D is an explanatory diagram showing configuration information of the source code shown in FIG. 15B. [Figure 16A] FIG. 16A is an explanatory diagram showing the data model of multiple orchestrator APs 203a, 203b, and 203c. [Figure 16B] FIG. 16B is an explanatory diagram showing a configuration information graph of the basic data model of the orchestrator AP. [Figure 16C] FIG. 16C is an explanatory diagram of generating a computing resource 50 based on the similarity of parameters 51, 52, and 53. [Figure 17] FIG. 17 is a block diagram showing the hardware configuration of this embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] [Network system configuration] An embodiment of the present invention will be described below. Fig. 1 is a block diagram showing a configuration of a network system 200 in which an API adaptor generation device according to an embodiment is adopted. First, the network system 200 will be described with reference to Fig. 1.

[0013] In the network system 200 shown in FIG. 1, an end user 201 connected to a service provider 202 can receive managed services provided by multiple wholesale service providers 220 (220a to 220d) set up on the network or cloud when the end user requests a desired service.

[0014] In this embodiment, an example will be described in which two wholesale service providers 220a and 220b already exist in the network system 200, and two new wholesale service providers 220c and 220d are added. The wholesale service providers 220a and 220d provide a managed object service via a network. The wholesale service providers 220b and 220c provide a managed object service via the cloud.

[0015] In the following, when a wholesale service provider is specified, it will be indicated with a suffix such as "wholesale service provider 220a", and when it is not specified or is referred to collectively, it will be indicated without a suffix such as "wholesale service provider 220". The same applies to other symbols.

[0016] Between the service provider 202 and each wholesale service provider 220, an orchestrator 210 and API adaptors 211 (211a to 211d) corresponding to each wholesale service provider 220 are provided.

[0017] The orchestrator 210 acquires an orchestrator AP 203 provided by a service provider 202, and collectively coordinates services that combine the networks, clouds, and applications of each wholesale service provider 220.

[0018] That is, the specifications of the managed services provided by each wholesale service provider 220 are different for each wholesale service provider 220. Therefore, when the service provider 202 combines multiple managed services to provide a new service, it is necessary to absorb the above-mentioned differences in specifications and link the multiple managed services. The orchestrator 210 performs this linking.

[0019] The orchestrator AP 203 is an application generated by using a northbound API 204 described later. The orchestrator AP 203 includes a construction setting AP and an autonomous operation AP. The orchestrator AP 203 is, for example, a catalog. The catalog is a data file that describes the specifications of each managed service required to link multiple managed services.

[0020] A northbound API 204 is provided between the service provider 202 and the orchestrator 210. The northbound API 204 is an interface that connects the service provider 202 and the orchestrator 210.

[0021] A southbound API 212 is provided between each wholesale service provider 220 and the orchestrator 210. The southbound API 212 is an interface that connects each wholesale service provider 220 and the orchestrator 210.

[0022] The orchestrator 210 is connected to an API adaptor 211 installed corresponding to each wholesale service provider 220 via an internal API 213 (see FIG. 2). The API adaptor 211 is generated for each wholesale service provider 220, and absorbs differences in API specifications provided by each wholesale service provider 220.

[0023] The orchestrator 210 breaks down the order issued by the service provider 202 into "individual orders" that can be processed by the API adapter 211 for each wholesale service provider 220, and transmits them to the API adapter 211 (211a to 211d) of each wholesale service provider 220 (220a to 220d).

[0024] Each API adaptor 211 has a function of converting between the data model of the orchestrator 210 and the data model of each wholesale service provider 220, and vice versa.

[0025] As described above, in the network system 200 in which the two wholesale service providers 220a and 220b are already installed, when new managed services provided by the two wholesale service providers 220c and 220d are to be added, it is necessary to generate API adapters 211c and 211d. That is, as shown in Fig. 1, it is necessary to generate new API adapters 211c and 211d in addition to the existing API adapters 211a and 211b.

[0026] In this embodiment, at least a part of the generation of the API adaptors 211c and 211d is automated, thereby reducing the labor of the worker and reducing costs. This will be described in detail below.

[0027] Fig. 2 is a block diagram showing a detailed configuration of the API adaptor 211 shown in Fig. 1. As shown in Fig. 2, the API adaptor 211 includes an order receiving unit 231, an API call logic unit 232, and a southbound API execution unit 233. The API adaptor 211 is connected to the API adaptor generation device 100 according to this embodiment.

[0028] The order receiving unit 231 receives the order N1 transmitted to the orchestrator 210 and acquires the contents of the order N1. The order receiving unit 231 performs a response process to the orchestrator 210. Specifically, as a coordinated order reception / response process, the order receiving unit 231 performs status management and notification from the reception of the order N1 to the completion of execution of the order N1, and distributes the execution results, in accordance with a procedure determined in advance with the orchestrator 210.

[0029] The order receiving unit 231, upon receiving a request from the API call logic unit 232 as an order content acquisition process, acquires detailed order content (catalog, etc.).

[0030] The API call logic unit 232 checks the start conditions of the southbound API 212 and starts the southbound API 212 according to a preset execution order.

[0031] The API call logic unit 232 extracts parameters required for executing the southbound API 212 from the order N1 from the orchestrator 210, and transmits them to the southbound API execution unit 233. The API call logic unit 232 acquires the execution result of the southbound API 212 from the southbound API execution unit 233. The API call logic unit 232 converts the acquired execution result into an appropriate data format for distribution to the orchestrator 210.

[0032] The southbound API execution unit 233 obtains data required for executing the southbound API 212 from the API call logic unit 232 , changes the data format, and transmits it to each wholesale service provider 220 .

[0033] The southbound API execution unit 233 receives responses from each wholesale service provider 220 , converts them into an appropriate format, and returns them to the API call logic unit 232 .

[0034] The southbound API execution unit 233 transmits requests and receives responses corresponding to the individual southbound APIs 212 between each wholesale service provider 220 and the wholesale service provider 220 via the southbound APIs 212 of each wholesale service provider 220 .

[0035] As described above, in the network system 200 shown in FIG. 1, when new services to be managed by wholesale service providers 220c, 220d are added, it is necessary to newly generate API adapters 211c, 211d to be connected to the orchestrator 210.

[0036] In this embodiment, by providing an API adaptor generation device 100, at least a part of the design of the API call logic unit 232 is automated, and the API adaptor 211 is generated.

[0037] When generating the API adaptor 211, it is necessary to carry out design, implementation, and testing. Furthermore, the design process includes "resource design," "parameter design," and "logic design." The implementation process includes implementation of the API call logic unit 232. In this embodiment, at least a part of the "resource design," "parameter design," and "logic design" is automated. Furthermore, the implementation of the API call logic unit 232 is automated.

[0038] [First embodiment] Next, a specific configuration of the API adaptor generation device 100 according to this embodiment will be described below. Fig. 3 is a block diagram showing the detailed configuration of the API adaptor generation device 100 according to the first embodiment and its peripheral devices.

[0039] 3, API adaptor generation device 100 according to this embodiment includes a data model storage unit 11, an API specification storage unit 12, an API schema conversion unit 13, a schema information storage unit 14, and an external information storage unit 15. API adaptor generation device 100 includes a conversion rule calculation unit 16, a conversion rule storage unit 17, a conversion rule visualization unit 18, a call logic unit generation unit 19 (generation unit), an API execution unit generation unit 20, an API adaptor generation unit 21, and an API adaptor storage unit 22. A confirmation screen 33 is connected to API adaptor generation device 100.

[0040] The data model storage unit 11 acquires and stores the orchestrator data model 31 input from the orchestrator 210.

[0041] The API specification storage unit 12 acquires and stores the southbound API specification 32 of the data model to be managed (the API specification of the model to be managed).

[0042] The API schema conversion unit 13 converts the southbound API specification 32 stored in the API specification storage unit 12 into a schema format. Fig. 4 is an explanatory diagram showing an example of converting an API specification P1 described in an open API spec format into a data model P2 in a UML (Unified Modeling Language) format. The schema information shown by symbols a1 and a2 in Fig. 4 is converted into a data model P2 such as UML by, for example, "WAPIml".

[0043] The schema information storage unit 14 stores the schema information converted by the API schema conversion unit 13 .

[0044] The external information storage unit 15 stores information transmitted from the outside, such as ontology.

[0045] The conversion rule calculation unit 16 calculates conversion rules for a data model by using existing schema matching. The conversion rule calculation unit 16 performs resource design, parameter design, and logic design when generating an API adaptor 211.

[0046] The conversion rule calculation unit 16 automates model conversion by applying a schema matching technique to a data schema that can be derived from the specifications of the southbound API 212 and to a portion that derives conversion rules for the data schema in the orchestrator 210. The "resource design and parameter design process" and the "logic design process" will be specifically described below.

[0047] (Resource design and parameter design process) The details of the resource design and parameter design will be described with reference to Figures 5A, 5B, and 5C. Figure 5A is an explanatory diagram showing the resource design and parameter design of data models M1 and M2 of each company when generating API adapters for the managed services of companies A and B. Figure 5B is an explanatory diagram showing the conversion of parameter values ​​of data models M1 and M2 of each company when generating API adapters for the managed services of companies A and B. Figure 5C is an explanatory diagram showing the relationship between the orchestrator AP and the orchestrator.

[0048] To implement resource design and parameter design, it is necessary to define conversion rules for data models M1 and M2 of the managed services managed by companies A and B, and data model M3 of the orchestrator 210. Also, conversion rules for resources and parameters, and conversion rules for parameter values ​​are required.

[0049] 5A, the resources and parameters of the data model M1 of company A and the data model of company B are converted to generate a data model M3 of the orchestrator 210. Specifically, the "EC2 Instance" of the data model M1 and the "Virtual Machines" of the data model M2 are converted to "VM" of the data model M3. In addition, the "Instance Type" of the data model M1 and the "vmsize" of the data model M2 are converted to "hardware Spec" of the data model M3.

[0050] Also, as shown in FIG. 5B, the parameter values ​​of the data model M1 of company A and the data model M2 of company B are converted to generate a data model M3 of the orchestrator 210. Specifically, the data model M3 of the orchestrator 210 is simplified and set to three uniquely defined values: "Large", "Medium", and "Small". The parameter value "m1.small" of the data model M1 is converted to "Small", "a1.medium" is converted to "Medium", and "m4.large" is converted to "Large". The parameter value "Dsv3" of the data model M2 is converted to "Small".

[0051] By setting the above conversion rules, as shown in Fig. 5C, the orchestrator 210 can use the data model "VM" as the orchestrator AP 203 without being aware of the cloud vendor. That is, the orchestrator AP 203 can handle the data models M1 and M2 shown in Fig. 5A and 5B as the same data model "VM".

[0052] Specifically, the data model shown in Figures 5A and 5B is converted using schema matching. For example, a "Graph-Based" method can be used for schema matching. In the "Graph-Based" method, it is possible to match parameters taking into account not only the names of the parameters but also the graph / tree structure of the schema.

[0053] Furthermore, it is possible to use an "Instance-based" approach that uses not only the data schema but also actual data values ​​(instances), or a "Hybrid" approach that uses this "Instance-based" approach in combination with schema information.

[0054] (Logic design process) Next, the details of the logic design will be described with reference to Figures 6A and 6B. Figure 6A is an explanatory diagram showing the execution sequence of APIs. Figure 6B is an explanatory diagram showing the logic design of each of the data models M11 to M13 when adding managed services by Company C, which is a wholesale service provider 220 having data model M11, Company D, which is a wholesale service provider 220 having data model M12, and Company E, which is a wholesale service provider 220 having data model M13.

[0055] When managing multiple resources in a managed service as a single unit, it is necessary to define the API execution order and parameter distribution relationship. For example, as shown in Figure 6A, the API execution order is defined as "VPC" → "Subnet" → "EC2".

[0056] 6B, the parameter distribution relationships are defined as indicated by arrows Z1 and Z2 in the data models M11 to M13 of companies C, D, and E. As a result, a data model M14 of the orchestrator 210 is generated in which the distribution relationships between the data models are defined.

[0057] In this way, the conversion rule calculation unit 16 calculates the conversion rules for the data model, and performs resource design, parameter design, and logic design when generating the API adaptor 211. Furthermore, the call logic part generation unit 19, which will be described later, generates the API call logic part 232 based on the results of the resource design, parameter design, and logic design.

[0058] Returning to FIG. 3, the conversion rule storage unit 17 stores the model conversion rules calculated by the conversion rule calculation unit 16.

[0059] The conversion rule visualization unit 18 visualizes the model conversion rules stored in the conversion rule storage unit 17 so that the user can confirm them by outputting them to the confirmation screen 33. For example, data of the model conversion rules is transmitted to the confirmation screen 33 and the data is displayed on the confirmation screen 33, thereby allowing the user to recognize the model conversion rules.

[0060] The call logic part generation unit 19 automatically generates an API call logic part 232 based on the results of the resource design, parameter design, and logic design calculated by the conversion rule calculation unit 16. The call logic part generation unit 19 rewrites the source code of the template in accordance with the model conversion rules calculated by the conversion rule calculation unit 16.

[0061] The procedure for generating source code will be described below with reference to Figures 7A, 7B, 8A, and 8B. Figure 7A is an explanatory diagram showing the correspondence when converting the parameters of the data model M1 shown in Figure 5A into the parameters of the data model M3 of the orchestrator 210, and Figure 7B is an explanatory diagram showing the source code in which the parameters shown in Figure 7A are described.

[0062] As shown in Figure 7A, when changing "EC2Instance" indicated by symbol x1 in data model M1 to "VM" indicated by symbol x2 and changing "InstanceType" indicated by symbol x3 to "hardwareSpec" indicated by symbol x4, the source code is written as "ec2" indicated by symbol y1 in Figure 7B, "vm" indicated by symbol y2, "instance type" indicated by symbol y3, and "hardwareSpec" indicated by symbol y4.

[0063] That is, a source code template such as that shown in FIG. 7B is prepared in advance, and by writing change data into this template, it is possible to generate source code that converts between required data models.

[0064] Fig. 8A is an explanatory diagram showing the correspondence relationship when converting the parameter values ​​of the data model M1 shown in Fig. 5B into the parameter values ​​of the data model M3 of the orchestrator 210. Fig. 8B is an explanatory diagram showing source code in which the parameter values ​​shown in Fig. 8A are described.

[0065] As shown in FIG. 8A, when changing "M4.large" indicated by reference number x11 in data model M1 to "Large" indicated by reference number x12, "m4.large" indicated by reference number y11 and "large" indicated by reference number y12 in source code 301 in FIG. 8B are written. Furthermore, when some calculation logic is required, it is converted into a function as shown in source code 302.

[0066] Returning to Fig. 3, the API executor generation unit 20 generates a southbound API executor 233 (see Fig. 2) in the API adaptor 211 based on the southbound API specification 32 stored in the API specification storage unit 12. To generate the southbound API executor 233, an existing tool such as "Swagger Codegen / Open API Generator" can be used.

[0067] The API adaptor generation unit 21 generates an API adaptor 211 based on the call logic unit 232 generated by the call logic unit generation unit 19 and the southbound API execution unit 233. In addition, the API adaptor generation unit 21 outputs the stored API adaptor 211 to the outside as necessary.

[0068] The API adaptor storage unit 22 stores the API adaptor 211 generated by the API adaptor generation unit 21 .

[0069] [Operation of the first embodiment] Next, a processing procedure of the API adaptor generation device 100 according to the first embodiment will be described with reference to the flowchart shown in Fig. 9. First, in step S11 of Fig. 9, the data model storage unit 11 acquires the orchestrator data model 31 output from the orchestrator 210 and stores it in the data model storage unit 11.

[0070] In step S12, the API specification storage unit 12 acquires the southbound API specification 32 output from the orchestrator 210 and stores it in the API specification storage unit 12.

[0071] In step S13, the API schema conversion unit 13 converts the southbound API specification 32 stored in the API specification storage unit 12 into a schema format. The converted schema information is stored in the schema information storage unit .

[0072] In step S14, the conversion rule calculation unit 16 calculates a model conversion rule based on the orchestrator data model 31 stored in the data model storage unit 11, the schema information stored in the schema information storage unit 14, and the external information stored in the external information storage unit 15. The conversion rule calculation unit 16 stores the calculated model conversion rule in the conversion rule storage unit 17.

[0073] In step S15, the conversion rule visualization unit 18 outputs the conversion rules stored in the conversion rule storage unit 17 to the confirmation screen 33 as necessary. By looking at the confirmation screen 33, the operator can recognize the conversion rules.

[0074] In step S16, the call logic part generation unit 19 rewrites the source code of the API adapter based on the model conversion rules stored in the conversion rule storage unit 17 to generate the API call logic part 232. In this way, the API call logic part 232 can be automatically generated.

[0075] In step S17, the API executor generating unit 20 generates the southbound API executor 233 shown in FIG.

[0076] In step S18, the API adaptor generation unit 21 generates a final API adaptor 211 based on the southbound API execution unit 233 generated by the API execution unit generation unit 20 and the API call logic unit 232 generated by the call logic unit generation unit 19. The generated API adaptor 211 is stored in the API adaptor storage unit 22.

[0077] [Effects of the first embodiment] As described above, the API adaptor generation device 100 according to the first embodiment includes a conversion rule calculation unit 16 that acquires the data model of the orchestrator 210 and the API specification of the managed model, performs schema matching based on the data schema of the orchestrator 210 and the data schema of the API specification, and calculates model conversion rules, a call logic unit generation unit 19 (generation unit) that rewrites the source code of the API call logic unit that describes the API adapter execution logic based on the model conversion rules, and an API adaptor generation unit 21 that generates an API adapter for the managed model based on the API call logic unit whose source code has been rewritten.

[0078] With the above configuration, in the API adaptor generation device 100 according to the first embodiment, when a wholesale service provider 220 having a new managed service is added to the orchestrator 210, it becomes possible to easily carry out a design process for designing a new API adaptor 211. Specifically, it becomes possible to reduce the effort, time, and cost required for generating the API adaptor 211.

[0079] In the first embodiment, the call logic part generation unit 19 generates source code by setting a predetermined source code template and writing at least one of the resources, parameter names, and parameter values ​​of the API specification to be managed into the template, thereby generating an API call logic part. This makes it possible to generate the API call logic part 232 with a simple operation.

[0080] [Second embodiment] Next, a second embodiment of this embodiment will be described. In the above-described first embodiment, the API adaptor 211 is generated using a template for the data model of a management target service newly connected to the network system 200. In the second embodiment, an example will be described in which resources of multiple service models are consolidated into one, matching is performed in a many-to-one correspondence, and the API adaptor 211 is generated.

[0081] In the second embodiment, when performing many-to-one matching, the contribution rate of matching is made variable for each resource and parameter. Alternatively, a dependency graph generated from the schema information of the southbound API is used to perform highly accurate many-to-one matching.

[0082] Fig. 10 is a block diagram showing the configuration of an API adaptor generation device 100a according to the second embodiment. API adaptor generation device 100a shown in Fig. 10 differs from API adaptor generation device 100 shown in Fig. 3 described above in that it includes a dependency graph generation unit 23 and a dependency graph storage unit 29. In the following, the same components as those shown in Fig. 3 are given the same reference numerals, and description of the configuration will be omitted.

[0083] The dependency graph generator 23 shown in Fig. 10 extracts dependencies between resources in advance and generates a graph representation from the schema information of the southbound API 212. Fig. 11 is an explanatory diagram showing the correspondence when converting the resources and parameters of the data models M11 to M13 of the wholesale service providers 220, namely, companies C, D, and E, into the resources and parameters of the data model M14 of the orchestrator.

[0084] As indicated by reference characters x32 and x34 in FIG. 11, the dependency graph generating unit 23 analyzes the dependency relationships between resources indicated by reference characters x32 and x34 from the schema information extracted from the southbound API specification 32, and generates a graph.

[0085] The dependency graph storage unit 29 stores the dependency graph generated by the dependency graph generation unit 23 .

[0086] In addition to the functions of the first embodiment described above, the conversion rule calculation unit 16 consolidates data models M11 to M13 of each company into one as shown in Fig. 11 when consolidating multiple resources into one as advance preparation. Specifically, when consolidating multiple resources into one, in order to improve the estimation accuracy and enable many-to-one matching, matching contribution rates are set for each resource and each parameter. Furthermore, the contribution rates are made variable.

[0087] Specifically, the probability that parameters i and j match, “M(i,j)”, is calculated using the following formula (1).

[0088] M(i,j)=k*R(i,j)+(1-k)*P(i,j) …(1) In formula (1), "M(i,j)" indicates the probability that parameter i matches parameter j when existing schema matching is adopted. "R(i,j)" indicates the matching probability between resources to which parameters i and j belong. "P(i,j)" indicates the matching probability based on parameters alone. "k" is a variable number that indicates the contribution rate of "R(i,j)".

[0089] In formula (1), the weights of resource-based matching and parameter-based matching are made adjustable, i.e., the value of the contribution rate k is made adjustable.

[0090] In addition, a graph of dependencies generated from the above-mentioned schema information of the southbound API 212 is used to enable highly accurate many-to-one matching.

[0091] The conversion rule calculation unit 16 first performs matching by lowering the contribution rate k of the matching information on a resource basis. When the conversion rule calculation unit 16 has found the above match, it checks the resource to which the parameter belongs. If there is a connection on the dependency graph, it is considered that a many-to-one match has been made with all of them. When there are multiple resources that are candidates for matching, it selects the one that is more closely connected on the dependency graph.

[0092] Fig. 12 is an explanatory diagram showing the procedure of the code conversion process by the API adaptor generating device 100a according to the second embodiment. As shown in Fig. 12, the model conversion rule stored in the conversion rule storage unit 17 sets the contribution rate "k" of "R(i,j)" shown in the above-mentioned formula (1) so that the matching weight can be adjusted.

[0093] In ST1 of FIG. 12, the dependency graph generating unit 23 analyzes dependencies between a plurality of resources based on the schema information extracted from the southbound API specification 32, and generates a dependency graph.

[0094] In ST2, the conversion rule calculation unit 16 calculates the execution sequence of a plurality of source codes using an algorithm such as a topological sort.

[0095] In ST3, the call logic part generation part 19 rewrites the source code of the API adaptor 211 based on the dependency graph and the weighting shown in the formula (1).

[0096] As described above, the conversion rule calculation unit 16 calculates the matching method by utilizing the variable contribution rate "k" and the dependency relationship graph.

[0097] Next, the rewriting of the source code will be specifically described with reference to Fig. 11 and Fig. 13. As described above, Fig. 11 is an explanatory diagram showing the correspondence when converting the resources and parameters of the data models M11 to M13 of companies C, D, and E into the resources and parameters of the data model M14 of the orchestrator. Fig. 13 is an explanatory diagram showing the source code in which the resources and parameters shown in Fig. 11 are described.

[0098] When converting the data models M11, M12, and M13 shown in Fig. 11 into the data model M14 of the orchestrator 210, the "cidrBlock" indicated by the reference symbol x31 is written in the "vpc_cidrBlock" indicated by the reference symbol y31 of the source code shown in Fig. 13. In addition, the dependency relationship between resources indicated by the reference symbol x12 in Fig. 11 is written in the "vcp.id" indicated by the reference symbol y32 in Fig. 13. The "cidrBlock" indicated by the reference symbol x33 in Fig. 11 is written in the "subnet_cidrBlock" indicated by the reference symbol y33 in Fig. 13.

[0099] The dependency relationship between resources indicated by reference symbol x34 in Fig. 11 is described in "subnet.id" indicated by reference symbol y34 in Fig. 13. The "networkSegment" indicated by reference symbol x35 in Fig. 11 is described in "vm.networkSegment" indicated by reference symbol y35 in Fig. 13. The "subnetSegment" indicated by reference symbol x36 in Fig. 11 is described in "vm.subnetSegment" indicated by reference symbol y36 in Fig. 13.

[0100] 13, reference numeral y37 indicates definitions of all matched resources, and reference numeral y38 indicates resources generated in the calculated execution order.

[0101] As described above, it becomes possible to incorporate the weighting of each of the data models M1 to M3 into the source code of the API adapter.

[0102] In this way, in the API adaptor generation device 100a according to the second embodiment, when a plurality of resources are consolidated into one, it is possible to perform matching with a high degree of accuracy.

[0103] Specifically, the conversion rule calculation unit 16 matches a plurality of resources included in the API specifications to be managed using the variable contribution rate k and the dependency relationship graph information, and aggregates them into one resource.

[0104] The conversion rule calculation unit 16 performs schema matching based on the data schema of the API specifications to be managed after resource aggregation and the data schema of the orchestrator 210, and generates model conversion rules for the API adapter. As a result, highly accurate many-to-one matching is possible, making it possible to easily generate a new API adapter 211.

[0105] [Description of the Third Embodiment] Next, a third embodiment of the present embodiment will be described. When the abstraction level of the data model of the orchestrator 210 becomes high, the deviation between the resource name, the parameter name and the structure becomes large, and matching becomes difficult. In the existing schema matching method, the accuracy is improved by a hybrid method that takes into account instance information in addition to schema information, but when applied to the orchestrator 210, it is difficult to obtain the instance information.

[0106] In the third embodiment, the matching accuracy is improved by utilizing the instance information and configuration information included in the orchestrator AP 203 of the orchestrator 210.

[0107] Fig. 14 is a block diagram showing the configuration of an API adaptor generation device 100b according to the third embodiment. Fig. 14 shows only components that are added to API adaptor generation device 100 shown in Fig. 3. That is, API adaptor generation device 100b according to the third embodiment includes components 24-28 shown in Fig. 14 in addition to components 11-21 shown in Fig. 3. Each of components 24-28 will be described below.

[0108] 14 collects orchestrator APs 203 from the orchestrator 210. The orchestrator APs 203 are generated using a northbound API 204. The orchestrator APs 203 are, for example, a catalog.

[0109] The AP information extraction unit 25 extracts instance information of the southbound API 212 and a configuration information graph of the orchestrator AP from the collected orchestrator AP 203. The "configuration information graph" indicates, for example, a data structure of an application, a computing resource, a network, etc., as shown in FIG. 16B described later.

[0110] The instance information storage unit 26 stores the instance information of the southbound API 212 extracted by the AP information extraction unit 25.

[0111] The configuration information graph storage unit 27 stores the orchestrator AP configuration information graph extracted by the AP information extraction unit 25. Specifically, as shown in Fig. 15A, configuration information of the systems included in each of the orchestrator APs 203a to 203c is stored as a configuration information graph.

[0112] The similarity calculation unit 28 calculates the similarity between resources based on the configuration information graph stored in the configuration information graph storage unit 27 .

[0113] The conversion rule calculation unit 16 calculates conversion rules for source code based on the instance information of the southbound API 212, the orchestrator AP configuration information graph, and the similarity between resources in addition to the orchestrator data model, schema information, and external information described above.

[0114] Fig. 15A is an explanatory diagram showing the relationship between the orchestrator AP203 and the orchestrator 210. Fig. 15B is an explanatory diagram showing source code describing resources and parameters included in the data model of the orchestrator AP203 shown in Fig. 15A. Fig. 15C is an explanatory diagram showing instance information of the source code shown in Fig. 15B. Fig. 15D is an explanatory diagram showing configuration information of the source code shown in Fig. 15B.

[0115] The conversion rule calculation unit 16 obtains the instance information and configuration information indicated by the symbols x21, x22, and x23 in Fig. 15B, and writes data to be described in each "id" as indicated by the symbols y21, y22, and y23 in Fig. 15C. Also, the conversion rule calculation unit 16 sets the configuration information as indicated by the symbol Q1 in Fig. 15D.

[0116] In addition, the conversion rule calculation unit 16 uses the similarity of the configuration information graph of the system included in the orchestrator AP203 to set a high matching probability for concepts that are likely to be of the same type.

[0117] Fig. 16A is an explanatory diagram showing a configuration information graph of the data model of multiple orchestrator APs 203a, 203b, and 203c. Fig. 16B is an explanatory diagram showing a configuration information graph of the basic data model of the orchestrator AP 203. Fig. 16C is an explanatory diagram of generating a computing resource 50 based on the similarity of parameters 51, 52, and 53 included in each orchestrator AP 203.

[0118] The similarity calculation unit 28 calculates the similarity between resources by comparing the structures of "applications," "computing resources," and "networks" shown in FIG. 16B with the configuration information of each orchestrator AP203a, 203b, and 203c shown in FIG. 16A.

[0119] For example, as shown in FIG. 16A, if three types of orchestrator APs 203a, 203b, and 203c have parameters of "VM 51," "container 52," and "serverless 53," respectively, the computing resource 50 is set based on the similarity of each of the parameters 51, 52, and 53, as shown in FIG. 16C.

[0120] As a specific calculation method, the probability that parameter i and parameter j match is defined as "M'(i,j)" and is set by the following formula (2).

[0121] M´(i,j)=(1-a)·M(i,j)+a·S(i,j) …(2) In formula (2), "M(i,j)" indicates the probability that parameter i matches parameter j when existing schema matching is adopted. "S(i,j)" indicates the similarity between parameters i and j taking into account the similarity between resources in the configuration information graph. "a" indicates the contribution rate of the similarity of the configuration information graph. By doing so, it is possible to set multiple orchestrator AP203 so that the matching probability is high when there is a high possibility that the concepts are of the same type.

[0122] In this way, in the API adaptor generation device 100b according to the third embodiment, by performing schema matching using the above formula (2), when multiple orchestrator APs 203 are given, a new API adaptor 211 can be generated easily and with high accuracy.

[0123] Furthermore, in the API adaptor generation device 100b according to the third embodiment, the similarity between the resources included in each orchestrator AP 203 is calculated based on the configuration information graph included in the information of the orchestrator AP 203. Based on the calculated similarity and the instance information, a model conversion rule is generated, and an API call logic unit 232 is generated. As a result, a new API adaptor 211 can be generated conveniently and with high accuracy.

[0124] For the API adaptor generating devices 100, 100a, and 100b of the above-described embodiments, for example, a general-purpose computer system including a CPU (Central Processing Unit, processor) 901, a memory 902, a storage 903 (HDD: Hard Disk Drive, SSD: Solid State Drive), a communication device 904, an input device 905, and an output device 906, as shown in Fig. 17. The memory 902 and the storage 903 are storage devices. In this computer system, the CPU 901 executes a predetermined program loaded on the memory 902, thereby realizing each function of the API adaptor generating devices 100, 100a, and 100b.

[0125] The API adaptor generation devices 100, 100a, and 100b may be implemented in one computer or in multiple computers. Furthermore, the API adaptor generation devices 100, 100a, and 100b may be virtual machines implemented in a computer.

[0126] In addition, the programs for API adapter generation devices 100, 100a, and 100b can be stored on a computer-readable recording medium such as a HDD, SSD, USB (Universal Serial Bus) memory, CD (Compact Disc), or DVD (Digital Versatile Disc), or can be distributed via a network.

[0127] The present invention is not limited to the above-described embodiment, and various modifications are possible within the scope of the present invention. [Explanation of symbols]

[0128] 11 Data Model Storage 12 API specification storage section 13 API Schema Conversion 14 Schema information storage section 15 External information storage unit 16 Conversion rule calculation section 17 Conversion rule memory 18 Conversion rule visualization part 19 Call logic part generation part (generation part) 20 API execution unit generation unit 21 API Adapter Generation Unit 22 API Adapter Storage 23 Dependency graph generator 24 Orchestrator AP Collection Unit 25 AP information extraction section 26 Instance information storage unit 27 Configuration information graph storage unit 28 Similarity calculation part 29 Dependency graph storage 31 Orchestrator Data Model 32 Southbound API Specifications 33 Confirmation screen 100, 100a, 100b API adapter generator 200 Network System 201 End User 202 Service Provider 203 Orchestrator AP 210 Orchestrator 211(211a~211d) API adapter 220 (220a-220d) Wholesale service providers 231 Order Reception Department 232 API call logic part 233 Southbound API Execution Department

Claims

1. a conversion rule calculation unit that acquires a data model of an orchestrator and an API specification of a management target, performs schema matching based on the data schema of the orchestrator and the data schema of the API specification, and calculates a model conversion rule; a generation unit that rewrites source code of an API call logic unit that describes an API adapter execution logic based on the model conversion rules; an API adapter generation unit that generates an API adapter to be managed based on the API call logic unit whose source code has been rewritten; An API adapter generator comprising:

2. 2. The API adapter generation device according to claim 1, wherein the conversion rule calculation unit performs schema matching between the data model of the orchestrator and the API specification of the managed object in units of at least one of resources and parameters to calculate the model conversion rule.

3. the conversion rule calculation unit matches a plurality of resources included in the API specification of the management target using a variable contribution rate and dependency graph information, and aggregates them into one resource; 3. The API adapter generation device according to claim 1, further comprising: a data schema of the API specification of the managed object after resource aggregation; and a data schema of the orchestrator, the data schema of the managed object being matched with the orchestrator.

4. An API adapter generation device as described in any one of claims 1 to 3, wherein the generation unit sets a template of a specified source code, and rewrites the specified source code by writing at least one of the resources, parameter names, and parameter values ​​of the API specification to be managed into the template, thereby generating the API call logic unit.

5. an information extraction unit that extracts instance information and a configuration information graph from information of an orchestrator AP included in the orchestrator; a similarity calculation unit that calculates a similarity between each resource included in the orchestrator AP based on the configuration information graph; Further comprising:

5. The API adaptor generating device according to claim 1, wherein the conversion rule calculation unit generates the model conversion rule based on the instance information and the similarity.

6. An API adapter generation device according to any one of claims 1 to 5, wherein the schema matching uses at least one of a Graph-Based method, an Instance-based method, and a "Hybrid" method that combines the Instance-based method with schema information.

7. 1. A computer-implemented method for generating an API adapter, comprising: Obtaining a data model of an orchestrator and a managed API specification; performing schema matching based on the data schema of the orchestrator and the data schema of the API specification to calculate a model transformation rule; rewriting source code of an API call logic section describing an API adapter execution logic based on the model conversion rule; generating an API adapter to be managed based on the API calling logic portion whose source code has been rewritten; A method for generating an API adapter comprising:

8. 7. An API adaptor generating program that causes a computer to function as the API adaptor generating device according to claim 1.

Images