WO2022215194A1 - Ａｐｉアダプタ生成装置及びａｐｉアダプタ生成方法並びにａｐｉアダプタ生成プログラム - Google Patents

Ａｐｉアダプタ生成装置及びａｐｉアダプタ生成方法並びにａｐｉアダプタ生成プログラム Download PDF

Info

Publication number
WO2022215194A1
WO2022215194A1 PCT/JP2021/014763 JP2021014763W WO2022215194A1 WO 2022215194 A1 WO2022215194 A1 WO 2022215194A1 JP 2021014763 W JP2021014763 W JP 2021014763W WO 2022215194 A1 WO2022215194 A1 WO 2022215194A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
orchestrator
adapter
unit
conversion rule
Prior art date
Application number
PCT/JP2021/014763
Other languages
English (en)
French (fr)
Inventor
直樹 武
能史 加藤
未稚 大谷
清隆 斎藤
悟 近藤
優 三好
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2023512573A priority Critical patent/JPWO2022215194A1/ja
Priority to PCT/JP2021/014763 priority patent/WO2022215194A1/ja
Priority to US18/554,256 priority patent/US20240118946A1/en
Publication of WO2022215194A1 publication Critical patent/WO2022215194A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code

Definitions

  • the present invention relates to an API adapter generation device, an API adapter generation method, and an API adapter generation program.
  • An orchestrator that links multiple services is used to build and operate services by combining multiple wholesale partner services.
  • the orchestrator is required to add or change API adapters at low cost and in a short period of time when new wholesale services (services to be managed) are added or specifications of existing services are changed.
  • Non-Patent Document 1 discloses a technique for automatically generating an API adapter that absorbs API specification differences for each service used.
  • Non-Patent Document 2 discloses automating part of the test for control signals and data signals between an API adapter and a wholesale service.
  • the process of generating an API adapter includes a design process, an implementation process, and a test process. must be manually performed by the user. For this reason, there is a problem that it is difficult to reduce costs and shorten the period for adding API adapters and changing specifications.
  • the present invention has been made in view of the above circumstances, and its object is to provide an API adapter generation apparatus and an API adapter generation apparatus that can add API adapters and change specifications in a short period of time at low cost. It is to provide a method and an API adapter generation program.
  • An API adapter generation device 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, A conversion rule calculation unit that calculates a model conversion rule, a generation unit that rewrites source code of an API call logic unit describing API adapter execution logic based on the model conversion rule, and an API call logic in which the source code is rewritten. an API adapter generation unit that generates the managed API adapter based on the part.
  • An API adapter generation method is a computer-performed API adapter generation method comprising: a step of obtaining a data model of an orchestrator; an API specification to be managed; a data schema of the orchestrator; a step of performing schema matching based on a data schema of an API specification to calculate a model conversion rule; a step of rewriting source code of an API calling logic portion describing API adapter execution logic based on the model conversion rule; and generating the API adapter to be managed based on the API calling logic part whose source code has been rewritten.
  • One aspect of the present invention is an API adapter generation program for causing a computer to function as the API adapter generation device.
  • FIG. 1 is a block diagram showing the configuration of a network system that employs an API adapter generation device according to an embodiment.
  • FIG. 2 is a block diagram showing configurations of an API adapter generation device and an API adapter according to the embodiment.
  • FIG. 3 is a block diagram showing the configuration of the API adapter generation device according to the first embodiment.
  • FIG. 4 is an explanatory diagram showing an example of converting an API specification written in an open API specification format into a UML format data model.
  • 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 managed services.
  • FIG. 5B is an explanatory diagram showing the conversion of the parameter values of the data models M1 and M2 of the companies A and B when generating API adapters for managed services.
  • FIG. 5C is an explanatory diagram showing the relationship between the orchestrator AP and the orchestrator.
  • FIG. 6A is an explanatory diagram showing the execution order of APIs when multiple APIs are collectively managed.
  • FIG. 6B is an explanatory diagram showing the logic design of each data model when adding services to be managed by companies C, D, and E.
  • FIG. FIG. 7A is an explanatory diagram showing the correspondence when converting the resources and parameters of the data model M1 into the resources and parameters of the data model M3 of the orchestrator.
  • FIG. 7B is an explanatory diagram showing source code describing the resources and parameters shown in FIG. 7A.
  • FIG. 8A is an explanatory diagram showing the correspondence when converting the parameter values of the data model M1 into the parameter values of the data model M3 of the orchestrator.
  • FIG. 8B is an explanatory diagram showing source code describing the parameter values shown in FIG. 8A.
  • FIG. 9 is a flow chart showing the processing procedure of the API adapter generation device according to the first embodiment.
  • FIG. 10 is a block diagram showing the configuration of an API adapter generation device according to the second embodiment.
  • FIG. 11 is an explanatory diagram showing the correspondence when converting the resources and parameters of the data models M11 to M13 into the resources and parameters of the data model M14 of the orchestrator.
  • FIG. 12 is an explanatory diagram showing the procedure for generating the source code of the data model according to the conversion rule according to the second embodiment.
  • FIG. 13 is an explanatory diagram showing source code describing the resources and parameters shown in FIG.
  • FIG. 14 is a block diagram showing the configuration of an API adapter generation device according to the third embodiment.
  • FIG. 15A is an explanatory diagram showing the relationship between the orchestrator AP and the orchestrator according to the third embodiment.
  • FIG. 15B is an explanatory diagram showing source code describing the resources and parameters 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.
  • FIG. 15A is an explanatory diagram showing the relationship between the orchestrator AP and the orchestrator according to the third embodiment.
  • FIG. 15B is an explanatory diagram showing source code describing the resources and parameters shown in FIG.
  • FIG. 16A is an explanatory diagram showing a data model of a plurality of orchestrator APs 203a, 203b, 203c.
  • FIG. 16B is an explanatory diagram showing a configuration information graph of the basic data model of the orchestrator AP.
  • FIG. 16C is an illustration of generating a computing resource 50 based on the similarity of parameters 51, 52, 53.
  • FIG. 17 is a block diagram showing the hardware configuration of this embodiment.
  • FIG. 1 is a block diagram showing the configuration of a network system 200 that employs an API adapter generation device according to an embodiment. First, the network system 200 will be described with reference to FIG.
  • a plurality of wholesale service providers 220 (220a to 220d) set on a network or cloud can receive managed services provided.
  • 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.
  • Wholesale service providers 220a, 220d provide network managed services.
  • Wholesale service providers 220b and 220c provide cloud-based managed services.
  • an orchestrator 210 and API adapters 211 (211a to 211d) corresponding to each wholesale service provider 220 are provided.
  • the orchestrator 210 acquires the orchestrator AP 203 provided by the service provider 202, and collectively cooperates with services that combine networks, clouds, and applications of each wholesale service provider 220.
  • each wholesale service provider 220 has different specifications for each wholesale service provider 220 .
  • Orchestrator 210 performs this coordination.
  • the orchestrator AP 203 is an application generated using the 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.
  • a catalog is a data file that describes the specifications of each managed service required for linking multiple managed services.
  • a northbound API 204 is provided between the service provider 202 and the orchestrator 210 .
  • Northbound API 204 is an interface that connects service provider 202 and orchestrator 210 .
  • 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 .
  • the orchestrator 210 is connected to an API adapter 211 installed corresponding to each wholesale service provider 220 via an internal API 213 (see FIG. 2).
  • the API adapter 211 is generated for each wholesale service provider 220 and absorbs API specification differences provided by each wholesale service provider 220 .
  • the orchestrator 210 decomposes the order issued by the service provider 202 into "single orders", which are units that can be processed by the API adapter 211 for each wholesale service provider 220, and distributes the order to each wholesale service provider 220 (220a to 220d). to the API adapter 211 (211a to 211d).
  • Each API adapter 211 has a function to mutually convert the data model of the orchestrator 210 and the data model of each wholesale service provider 220 .
  • API adapters 211c and 211d As described above, in the network system 200 in which the two wholesale service providers 220a and 220b are already installed, when newly adding a managed service provided by the two wholesale service providers 220c and 220d, 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.
  • FIG. 2 is a block diagram showing the detailed configuration of the API adapter 211 shown in FIG. As shown in FIG. 2, the API adapter 211 includes an order reception unit 231, an API calling logic unit 232, and a southbound API execution unit 233. The API adapter 211 is connected to the API adapter generation device 100 according to this embodiment.
  • the order reception unit 231 receives the order N1 transmitted to the orchestrator 210 and acquires the contents of the order N1.
  • the order reception unit 231 performs response processing to the orchestrator 210 . Specifically, as cooperative order reception/response processing, the order reception unit 231 follows a predetermined procedure with the orchestrator 210 to manage and notify the state from the reception of the order N1 to the completion of the execution of the order N1; Distribute execution results.
  • the order reception unit 231 receives a request from the API call logic unit 232 and acquires detailed order contents (catalog, etc.) as an order content acquisition process.
  • the API call logic unit 232 checks the activation conditions of the southbound API 212 and activates the southbound API 212 according to a preset execution order.
  • the API call logic unit 232 extracts the parameters necessary 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 calling logic unit 232 converts the acquired execution result into a data format suitable for distribution to the orchestrator 210 .
  • the southbound API execution unit 233 acquires data necessary 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.
  • the southbound API execution unit 233 receives the response from each wholesale service provider 220, converts it into an appropriate format, and returns it to the API call logic unit 232.
  • the southbound API execution unit 233 communicates with each wholesale service provider 220 through the southbound API 212 of each wholesale service provider 220 to send requests and receive responses corresponding to individual southbound APIs 212 .
  • the API adapter generation device 100 by providing the API adapter generation device 100, at least part of the design of the API calling logic unit 232 is automated, and the API adapter 211 is generated.
  • 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 part of "resource design”, “parameter design”, and “logic design” is automated. Also, the implementation of the API call logic unit 232 is automated.
  • FIG. 3 is a block diagram showing the detailed configuration of the API adapter generation device 100 and its peripherals according to the first embodiment.
  • the API adapter generation device 100 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. A portion 15 is provided.
  • the API adapter 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, and an API adapter.
  • a generation unit 21 and an API adapter storage unit 22 are provided.
  • a confirmation screen 33 is connected to the API adapter generation device 100 .
  • the data model storage unit 11 acquires and stores the orchestrator data model 31 input from the orchestrator 210 .
  • the API specification storage unit 12 acquires and stores the southbound API specification 32 of the data model to be managed (API specification of the model to be managed).
  • 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 written in an open API specification format into a data model P2 in UML (Unified Modeling Language) format. Schema information indicated by symbols a1 and a2 in FIG. 4 is converted into a data model P2 such as UML by, for example, "WAPIml".
  • the schema information storage unit 14 stores the schema information converted by the API schema conversion unit 13.
  • the external information storage unit 15 stores externally transmitted information such as an ontology.
  • the conversion rule calculation unit 16 uses existing schema matching to calculate conversion rules for the data model.
  • the conversion rule calculation unit 16 performs resource design, parameter design, and logic design when generating the API adapter 211 .
  • the conversion rule calculation unit 16 automates model conversion by applying schema matching technology to the data schema that can be derived from the specifications of the southbound API 212 and the part that derives the data schema conversion rule in the orchestrator 210 .
  • the “resource design and parameter design process” and the “logic design process” will be specifically described below.
  • 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 managed services.
  • FIG. 5B is an explanatory diagram showing the conversion of the parameter values of the data models M1 and M2 of the companies A and B when generating API adapters for managed services.
  • FIG. 5C is an explanatory diagram showing the relationship between the orchestrator AP and the orchestrator.
  • the data model M3 of the orchestrator 210 is generated by converting the resources and parameters of the data model M1 of company A and the data model of company B. Specifically, “EC2Instance” of the data model M1 and “Virtual Machines” of the data model M2 are converted to "VM” of the data model M3. Also, “Instance Type” of the data model M1 and “vmsize” of the data model M2 are converted into “hardware Spec" of the data model M3.
  • the parameter values of the data model M1 of company A and the data model M2 of company B are converted to generate the data model M3 of the orchestrator 210 .
  • the data model M3 of the orchestrator 210 is simplified and set to three independently defined "Large”, “Medium”, and “Small”. Convert the parameter value "m1.small” of the data model M1 to "Small”, convert “a1.medium” to “Medium”, and convert “m4.large” to "Large”. Convert the parameter value "Dsv3" of the data model M2 to "Small".
  • the orchestrator 210 can be used without being aware of the cloud vendor when the data model "VM" is given as the orchestrator AP 203. . That is, from the orchestrator AP 203, the data model M1 and the data model M2 shown in FIGS. 5A and 5B can be treated as a similar data model "VM".
  • the data model conversion shown in FIGS. 5A and 5B is converted using schema matching.
  • schema matching for example, a “Graph-Based” technique can be used.
  • Graph-Based it is possible to match parameters after considering not only the name of the parameter but also the graph/tree structure of the schema.
  • FIG. 6A is an explanatory diagram showing the execution order of APIs.
  • FIG. 6B is a diagram showing the data by company C, which is the wholesale service provider 220 with the data model M11, company D, which is the wholesale service provider 220 with the data model M12, and company E, which is the wholesale service provider 220 with the data model M13.
  • FIG. 10 is an explanatory diagram showing the logic design of each data model M11 to M13 when adding a service to be managed;
  • the API execution order is defined in the order of "VPC" ⁇ "Subnet" ⁇ "EC2".
  • the conversion rule calculation unit 16 calculates the conversion rules of the data model and performs resource design, parameter design, and logic design when generating the API adapter 211 . Further, the call logic section generation section 19, which will be described later, generates the API call logic section 232 based on the results of the resource design, parameter design, and logic design.
  • the conversion rule storage unit 17 stores the model conversion rules calculated by the conversion rule calculation unit 16.
  • the conversion rule visualization unit 18 outputs the model conversion rules stored in the conversion rule storage unit 17 to the confirmation screen 33, thereby visualizing the model conversion rules so that the user can check them. For example, by transmitting model conversion rule data to the confirmation screen 33 and displaying this data on the confirmation screen 33, the user is made to recognize the model conversion rule.
  • the call logic section generation section 19 automatically generates the API call logic section 232 based on the resource design, parameter design, and logic design results calculated by the conversion rule calculation section 16 .
  • the call logic section generation section 19 rewrites the template source code according to the model conversion rule calculated by the conversion rule calculation section 16 .
  • FIG. 7A is an explanatory diagram showing the correspondence when converting the parameters of the data model M1 shown in FIG. 5A into the parameters of the data model M3 of the orchestrator 210
  • FIG. 7B is a source describing the parameters shown in FIG. 7A
  • FIG. 4 is an explanatory diagram showing a code
  • FIG. 8A is an explanatory diagram showing the correspondence 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 describing the parameter values shown in FIG. 8A.
  • the API execution unit generation unit 20 generates the southbound API execution unit 233 (see FIG. 2) in the API adapter 211 based on the southbound API specifications 32 stored in the API specification storage unit 12. do.
  • An existing tool such as "Swagger Codegen/Open API Generator” can be used to generate the southbound API execution unit 233 .
  • the API adapter generation unit 21 generates the API adapter 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, it outputs the stored API adapter 211 to the outside as needed.
  • the API adapter storage unit 22 stores the API adapter 211 generated by the API adapter generation unit 21.
  • step S ⁇ b>11 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 .
  • step S ⁇ b>12 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 .
  • 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 schema information after conversion is stored in the schema information storage unit 14 .
  • step S14 the conversion rule calculation unit 16 calculates 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 schema information stored in the external information storage unit 15. Model conversion rules are calculated based on the external information available.
  • the conversion rule calculation unit 16 stores the calculated model conversion rule in the conversion rule storage unit 17 .
  • 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.
  • the operator can recognize the conversion rule by viewing the confirmation screen 33 .
  • step S16 the call logic section generation section 19 rewrites the source code of the API adapter based on the model conversion rule stored in the conversion rule storage section 17 to generate the API call logic section 232. Thereby, the API calling logic part 232 can be automatically generated.
  • step S17 the API execution unit generation unit 20 generates the southbound API execution unit 233 shown in FIG. 2 based on the specifications of the southbound API adapter stored in the API specification storage unit 12.
  • step S18 the API adapter generation unit 21 generates the final A typical API adapter 211 is generated.
  • the generated API adapter 211 is stored in the API adapter storage unit 22 .
  • the API adapter generation device 100 acquires the data model of the orchestrator 210 and the API specification of the managed model, and based on the data schema of the orchestrator 210 and the data schema of the API specification, A conversion rule calculation unit 16 that performs schema matching and calculates a model conversion rule, and a call logic unit generation unit 19 (generation and an API adapter generation unit 21 that generates an API adapter for a managed model based on the API call logic unit whose source code has been rewritten.
  • the API adapter generation device 100 when the wholesale service provider 220 having a new managed service is added to the orchestrator 210, the API adapter 211 is newly added to the orchestrator 210. It becomes possible to easily implement the design process when designing. Specifically, it is possible to reduce the labor, time, and cost required to generate the API adapter 211 .
  • the call logic part generation part 19 sets a template of a predetermined source code, and writes at least one of a resource of the API specification to be managed, a parameter name, and a parameter value into the template. and generate an API call logic part. Therefore, it becomes possible to generate the API call logic part 232 with a simple operation.
  • the API adapter 211 is generated using a template for the data model of the managed service newly connected to the network system 200 .
  • the second embodiment an example will be described in which resources of a plurality of service models are grouped into one, and matching is performed by many-to-one correspondence to generate the API adapter 211 .
  • the matching contribution rate is made variable for each resource and each parameter.
  • a dependency graph generated from the schema information of the southbound API is used to perform highly accurate many-to-one matching.
  • FIG. 10 is a block diagram showing the configuration of the API adapter generation device 100a according to the second embodiment.
  • the API adapter generation device 100a shown in FIG. 10 differs from the API adapter generation device 100 shown in FIG. .
  • the same components as those shown in FIG. 3 are denoted by the same reference numerals, and the description of the configuration is omitted.
  • the dependency graph generation unit 23 shown in FIG. 10 extracts dependencies between resources in advance from the schema information of the southbound API 212 and generates a graph representation.
  • FIG. 11 shows the correspondence relationship when converting the resources and parameters of the data models M11 to M13 of the wholesale service providers 220 C, D, and E into the resources and parameters of the orchestrator data model M14. It is an explanatory diagram showing.
  • the dependency graph generation unit 23 analyzes the dependencies between resources indicated by symbols x32 and x34 from the schema information extracted from the southbound API specification 32 and generates a graph, as indicated by symbols x32 and x34 in FIG. .
  • the dependency graph storage unit 29 stores the dependency graph generated by the dependency graph generation unit 23.
  • the conversion rule calculation unit 16 integrates the data models M11 to M13 of each company as shown in FIG. Summarize into one. Specifically, when aggregating multiple resources into one, in order to improve estimation accuracy and enable many-to-one matching, set the matching contribution rate for each resource and parameter. . Furthermore, the contribution rate is made variable.
  • the probability "M(i,j)" that parameters i and j match is calculated by the following formula (1).
  • M(i,j) k*R(i,j)+(1 ⁇ k)*P(i,j) (1)
  • M(i,j) indicates the probability that parameter i and parameter j match 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 only with parameters.
  • k is a variable numerical value and indicates the contribution rate of "R(i,j)".
  • the conversion rule calculation unit 16 first performs matching by reducing the contribution rate k of matching information in resource units.
  • the conversion rule calculation unit 16 confirms the resource to which the parameter belongs when the above matching is obtained.
  • On the dependency graph if they are connected, they are all matched on a many-to-one basis. If there are multiple matching candidate resources, select the one that is connected with the shortest distance on the dependency graph.
  • FIG. 12 is an explanatory diagram showing the procedure of code conversion processing by the API adapter generation device 100a according to the second embodiment.
  • 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 equation (1), Allow weights to be adjusted.
  • the dependency graph generation unit 23 analyzes dependencies between multiple resources based on the schema information extracted from the southbound API specification 32 and generates a dependency graph.
  • the conversion rule calculation unit 16 uses an algorithm such as topological sort to calculate the execution order of multiple source codes.
  • the call logic section generation section 19 rewrites the source code of the API adapter 211 based on the dependency graph and the weighting shown in formula (1).
  • the conversion rule calculation unit 16 uses the variable contribution rate "k" and the dependency graph to calculate the matching method.
  • FIG. 11 illustrates the correspondence relationship when converting the resources and parameters of the data models M11 to M13 of Company C, Company D, and Company E into the resources and parameters of the data model M14 of the orchestrator. It is a diagram. Also, FIG. 13 is an explanatory diagram showing a source code describing the resources and parameters shown in FIG.
  • Symbol y37 shown in FIG. 13 indicates the definition of all matching resources.
  • Symbol y38 indicates a resource generated in the calculated execution order.
  • the API adapter generation device 100a can perform highly accurate matching when a plurality of resources are aggregated into one.
  • 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.
  • 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 becomes possible, and a new API adapter 211 can be easily generated.
  • matching accuracy is improved by utilizing instance information and configuration information included in the orchestrator AP 203 of the orchestrator 210 .
  • FIG. 14 is a block diagram showing the configuration of the API adapter generation device 100b according to the third embodiment.
  • FIG. 14 shows only components added to the API adapter generation device 100 shown in FIG. That is, the API adapter generation device 100b according to the third embodiment includes components 24 to 28 shown in FIG. 14 in addition to the components 11 to 21 shown in FIG. Each component 24 to 28 will be described below.
  • the orchestrator AP collection unit 24 shown in FIG. 14 collects orchestrator APs 203 from the orchestrator 210 .
  • Orchestrator AP 203 is created using Northbound API 204 .
  • Orchestrator AP 203 is, for example, a catalog.
  • the AP information extraction unit 25 extracts the instance information of the southbound API 212 and the configuration information graph of the orchestrator AP from the collected orchestrator AP 203 .
  • a “configuration information graph” indicates a data structure of, for example, applications, computing resources, networks, etc., as shown in FIG. 16B described later.
  • the instance information storage unit 26 stores the instance information of the southbound API 212 extracted by the AP information extraction unit 25.
  • 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, system configuration information included in each of the orchestrator APs 203a to 203c is stored as a configuration information graph.
  • the similarity calculator 28 calculates the similarity between resources based on the configuration information graph stored in the configuration information graph storage unit 27 .
  • the conversion rule calculation unit 16 converts the source code based on the instance information of the southbound API 212, the orchestrator AP configuration information graph, and the degree of similarity between resources in addition to the above-described orchestrator data model, schema information, and external information. Calculate conversion rules.
  • FIG. 15A is an explanatory diagram showing the relationship between the orchestrator AP 203 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 AP 203 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.
  • the conversion rule calculation unit 16 acquires the instance information and configuration information indicated by symbols x21, x22, and x23 in FIG. 15B, and, as indicated by symbols y21, y22, and y23 in FIG. write. Also, configuration information is set as indicated by symbol Q1 in FIG. 15D.
  • the conversion rule calculation unit 16 uses the similarity of the system configuration information graphs included in the orchestrator AP 203 to set the matching probability to be high for concepts that are highly likely to be of the same type. .
  • FIG. 16A is an explanatory diagram showing a configuration information graph of data models of a plurality of 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 AP203.
  • FIG. 16C is an explanatory diagram of generating the computing resource 50 based on the similarity of the parameters 51, 52, 53 included in each orchestrator AP 203.
  • the similarity calculation unit 28 compares the structure of "application”, “computing resource”, and “network” shown in FIG. 16B with the configuration information of each orchestrator AP 203a, 203b, 203c shown in FIG. Calculate the similarity.
  • the probability that parameter i and parameter j match is set as "M'(i,j)" and is set by the following formula (2).
  • M'(i,j) (1-a)*M(i,j)+a*S(i,j) (2)
  • M(i,j) indicates the probability that parameter i and parameter j match when existing schema matching is adopted.
  • S(i,j) indicates the degree of similarity between parameters i and j in the configuration information graph, taking into consideration the degree of similarity between resources.
  • "a” indicates the contribution rate of the similarity of the configuration information graph.
  • the new API adapter 211 can be generated easily and with high accuracy.
  • the API adapter generation device 100b calculates the degree of similarity between each resource included in each orchestrator AP 203 based on the configuration information graph included in the information of the orchestrator AP 203 .
  • a model conversion rule is generated based on the calculated similarity and instance information, and the API call logic part 232 is generated.
  • the new API adapter 211 can be generated conveniently and with high accuracy.
  • the API adapter generation devices 100, 100a, and 100b of the above-described embodiments include, for example, a CPU (Central Processing Unit, processor) 901, a memory 902, and a storage 903 (HDD: HardDisk Drive, SSD (Solid State Drive), a communication device 904, an input device 905, and an output device 906, a general-purpose computer system can be used.
  • Memory 902 and storage 903 are storage devices.
  • CPU 901 executes a predetermined program loaded on memory 902 to realize each function of API adapter generation devices 100, 100a, and 100b.
  • API adapter generation devices 100, 100a, and 100b may be implemented by one computer, or may be implemented by a plurality of computers. Also, the API adapter generation devices 100, 100a, and 100b may be virtual machines implemented in computers.
  • Programs for the API adapter generation devices 100, 100a, and 100b are stored in computer-readable recording media such as HDD, SSD, USB (Universal Serial Bus) memory, CD (Compact Disc), and DVD (Digital Versatile Disc). or distributed over a network.
  • computer-readable recording media such as HDD, SSD, USB (Universal Serial Bus) memory, CD (Compact Disc), and DVD (Digital Versatile Disc).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

オーケストレータ（２１０）のデータモデルと、管理対象のＡＰＩ仕様を取得し、オーケストレータのデータスキーマ、及びＡＰＩ仕様のデータスキーマに基づいてスキーママッチングを行い、モデル変換ルールを算出する変換ルール算出部（１６）と、モデル変換ルールに基づいて、ＡＰＩアダプタ実行ロジックを記述したＡＰＩ呼出ロジック部２３２のソースコードを書き換える呼出ロジック部生成部（１９）と、ソースコードが書き換えられたＡＰＩ呼出ロジック部に基づいて、管理対象のＡＰＩアダプタを生成するＡＰＩアダプタ生成部（２１）を備える。

Description

ＡＰＩアダプタ生成装置及びＡＰＩアダプタ生成方法並びにＡＰＩアダプタ生成プログラム
　本発明は、ＡＰＩアダプタ生成装置及びＡＰＩアダプタ生成方法並びにＡＰＩアダプタ生成プログラムに関する。
　複数の卸パートナサービスを組み合わせてサービスを構築、運用するために、複数サービスを連携するオーケストレータが用いられている。オーケストレータでは、新規に卸サービス（管理対象サービス）を追加する場合、及び既存サービスの仕様変更が行われる場合には、低コスト且つ短期間でＡＰＩアダプタを追加、変更することが求められる。
　非特許文献１には、利用する各種サービス毎のＡＰＩの仕様差分を吸収するＡＰＩアダプタを自動生成する技術について開示されている。また、非特許文献２には、ＡＰＩアダプタと卸サービス間の制御信号やデータ信号についての試験の一部を自動化することが開示されている。
武 他, "Web APIアダプタ開発容易化に関する一考察,"2017.9, 電子情報通信学会 NWS研究会 金丸翔,池谷友基,高橋謙輔,豊嶋剛,「APIアダプタのC-PlaneおよびU-Planeの包括的な試験自動化手法の提案」,信学技報
　しかし、ＡＰＩアダプタを生成する工程には、設計工程、実装工程、及び試験工程があり、上述した非特許文献１に開示された技術では、上記設計工程の自動化について記載されておらず、設計工程についてはユーザが手動で実施する必要がある。このため、ＡＰＩアダプタの追加、仕様変更について低コスト化及び期間の短縮化を図ることが難しいという問題があった。
　本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、ＡＰＩアダプタの追加、仕様変更を低コスト且つ短期間で実施することが可能なＡＰＩアダプタ生成装置及びＡＰＩアダプタ生成方法並びにＡＰＩアダプタ生成プログラムを提供することにある。
　本発明の一態様のＡＰＩアダプタ生成装置は、オーケストレータのデータモデルと、管理対象のＡＰＩ仕様を取得し、前記オーケストレータのデータスキーマ、及び前記ＡＰＩ仕様のデータスキーマに基づいてスキーママッチングを行い、モデル変換ルールを算出する変換ルール算出部と、前記モデル変換ルールに基づいて、ＡＰＩアダプタ実行ロジックを記述したＡＰＩ呼出ロジック部のソースコードを書き換える生成部と、前記ソースコードが書き換えられたＡＰＩ呼出ロジック部に基づいて、前記管理対象のＡＰＩアダプタを生成するＡＰＩアダプタ生成部と、を備える。
　本発明の一態様のＡＰＩアダプタ生成方法は、コンピュータが行うＡＰＩアダプタ生成方法であって、オーケストレータのデータモデルと、管理対象のＡＰＩ仕様を取得するステップと、前記オーケストレータのデータスキーマ、及び前記ＡＰＩ仕様のデータスキーマに基づいてスキーママッチングを行い、モデル変換ルールを算出するステップと、前記モデル変換ルールに基づいて、ＡＰＩアダプタ実行ロジックを記述したＡＰＩ呼出ロジック部のソースコードを書き換えるステップと、前記ソースコードが書き換えられたＡＰＩ呼出ロジック部に基づいて、前記管理対象のＡＰＩアダプタを生成するステップと、を備える。
　本発明の一態様は、上記ＡＰＩアダプタ生成装置としてコンピュータを機能させるためのＡＰＩアダプタ生成プログラムである。
　本発明によれば、ＡＰＩアダプタの追加、使用変更を低コスト且つ短期間で実施することが可能になる。
図１は、実施形態に係るＡＰＩアダプタ生成装置が採用されるネットワークシステムの構成を示すブロック図である。 図２は、実施形態に係るＡＰＩアダプタ生成装置、及びＡＰＩアダプタの構成を示すブロック図である。 図３は、第１実施形態に係るＡＰＩアダプタ生成装置の構成を示すブロック図である。 図４は、オープンＡＰＩスペック形式で記述されたＡＰＩ仕様をＵＭＬ形式のデータモデルに変換する例を示す説明図である。 図５Ａは、Ａ社及びＢ社による管理対象サービスのＡＰＩアダプタを生成する際の、各社のデータモデルＭ１、Ｍ２のリソース設計、パラメータ設計を示す説明図である。 図５Ｂは、Ａ社及びＢ社による管理対象サービスのＡＰＩアダプタを生成する際の、各社のデータモデルＭ１、Ｍ２のパラメータ値の変換を示す説明図である。 図５Ｃは、オーケストレータＡＰとオーケストレータの関係を示す説明図である。 図６Ａは、複数のＡＰＩをまとめて管理する場合の、ＡＰＩの実行順序を示す説明図である。 図６Ｂは、Ｃ社、Ｄ社、Ｅ社による管理対象サービスを追加する際の、各データモデルのロジック設計を示す説明図である。 図７Ａは、データモデルＭ１のリソース及びパラメータを、オーケストレータのデータモデルＭ３のリソース及びパラメータに変換する際の対応関係を示す説明図である。 図７Ｂは、図７Ａに示したリソース及びパラメータを記述したソースコードを示す説明図である。 図８Ａは、データモデルＭ１のパラメータ値を、オーケストレータのデータモデルＭ３のパラメータ値に変換する際の対応関係を示す説明図である。 図８Ｂは、図８Ａに示したパラメータ値を記述したソースコードを示す説明図である。 図９は、第１実施形態に係るＡＰＩアダプタ生成装置の処理手順を示すフローチャートである。 図１０は、第２実施形態に係るＡＰＩアダプタ生成装置の構成を示すブロック図である。 図１１は、データモデルＭ１１～Ｍ１３のリソース及びパラメータを、オーケストレータのデータモデルＭ１４のリソース及びパラメータに変換する際の対応関係を示す説明図である。 図１２は、第２実施形態に係り、変換ルールに従ってデータモデルのソースコードを生成する手順を示す説明図である。 図１３は、図１１に示したリソース及びパラメータを記述したソースコードを示す説明図である。 図１４は、第３実施形態に係るＡＰＩアダプタ生成装置の構成を示すブロック図である。 図１５Ａは、第３実施形態に係り、オーケストレータＡＰとオーケストレータの関係を示す説明図である。 図１５Ｂは、図１５Ａに示したリソース及びパラメータを記述したソースコードを示す説明図である。 図１５Ｃは、図１５Ｂに示したソースコードのインスタンス情報を示す説明図である。 図１５Ｄは、図１５Ｂに示したソースコードの構成情報を示す説明図である。 図１６Ａは、複数のオーケストレータＡＰ２０３ａ、２０３ｂ、２０３ｃのデータモデルを示す説明図である。 図１６Ｂは、オーケストレータＡＰの基本的なデータモデルの構成情報グラフを示す説明図である。 図１６Ｃは、パラメータ５１、５２、５３の類似性に基づいて、コンピューティングリソース５０を生成する説明図である。 図１７は、本実施形態のハードウェア構成を示すブロック図である。
　[ネットワークシステムの構成]
　以下、本発明の実施形態について説明する。図１は、実施形態に係るＡＰＩアダプタ生成装置が採用されるネットワークシステム２００の構成を示すブロック図である。初めに、図１を参照してネットワークシステム２００について説明する。
　図１に示すネットワークシステム２００において、サービスプロバイダ２０２に接続されたエンドユーザ２０１は、希望するサービスを要求すると、ネットワークまたはクラウド上に設定されている複数の卸サービス事業者２２０（２２０ａ～２２０ｄ）から提供される管理対象サービスを受け取ることができる。
　なお、本実施形態では、２つの卸サービス事業者２２０ａ、２２０ｂが既にネットワークシステム２００に存在しており、新たに２つの卸サービス事業者２２０ｃ、２２０ｄを追加する例について説明する。卸サービス事業者２２０ａ、２２０ｄは、ネットワークによる管理対象サービスを提供する。卸サービス事業者２２０ｂ、２２０ｃは、クラウドによる管理対象サービスを提供する。
　以下では、卸サービス事業者を特定して示す場合には「卸サービス事業者２２０ａ」のようにサフィックスを付して示し、特定しない場合及び総称して示す場合には「卸サービス事業者２２０」のようにサフィックスを付さずに示すことにする。他の符号についても同様とする。
　サービスプロバイダ２０２と各卸サービス事業者２２０との間には、オーケストレータ２１０、及び各卸サービス事業者２２０に対応したＡＰＩアダプタ２１１（２１１ａ～２１１ｄ）が設けられている。
　オーケストレータ２１０は、サービスプロバイダ２０２から提供されるオーケストレータＡＰ２０３を取得し、各卸サービス事業者２２０のネットワーク、及びクラウド、アプリを組み合わせたサービスを一括で連携する。
　即ち、各卸サービス事業者２２０が提供する管理対象サービスは、各卸サービス事業者２２０ごとにその仕様が異なっている。このため、サービスプロバイダ２０２が複数の管理対象サービスを組み合わせて新たなサービスを提供する場合には、上記仕様の相違を吸収し、複数の管理対象サービスを連携させる必要がある。オーケストレータ２１０は、この連携を行う。
　オーケストレータＡＰ２０３は、後述するノースバウンドＡＰＩ２０４を利用して生成されるアプリケーションである。オーケストレータＡＰ２０３は、構築設定ＡＰ及び自律運用ＡＰを含む。オーケストレータＡＰ２０３は、例えばカタログである。カタログは、複数の管理対象サービスを連携させるために必要な各管理対象サービスの仕様を記述したデータファイルである。
　サービスプロバイダ２０２と、オーケストレータ２１０との間には、ノースバウンドＡＰＩ２０４が設けられている。ノースバウンドＡＰＩ２０４は、サービスプロバイダ２０２と、オーケストレータ２１０を接続するインターフェースである。
　各卸サービス事業者２２０と、オーケストレータ２１０との間には、サウスバウンドＡＰＩ２１２が設けられている。サウスバウンドＡＰＩ２１２は、各卸サービス事業者２２０とオーケストレータ２１０を接続するインターフェースである。
　オーケストレータ２１０は、内部ＡＰＩ２１３（図２参照）を介して、各卸サービス事業者２２０に対応して設置されたＡＰＩアダプタ２１１に接続されている。ＡＰＩアダプタ２１１は、各卸サービス事業者２２０ごとに生成され、各卸サービス事業者２２０が提供するＡＰＩ仕様差分を吸収する。
　オーケストレータ２１０は、サービスプロバイダ２０２が発行したオーダを、各卸サービス事業者２２０用のＡＰＩアダプタ２１１が処理できる単位である「単体オーダ」に分解し、各卸サービス事業者２２０（２２０ａ～２２０ｄ）のＡＰＩアダプタ２１１（２１１ａ～２１１ｄ）に送信する。
　各ＡＰＩアダプタ２１１は、オーケストレータ２１０のデータモデルと、各卸サービス事業者２２０のデータモデルを相互に変換する機能を有している。
　上述したように、２つの卸サービス事業者２２０ａ、２２０ｂが既に設置されているネットワークシステム２００において、２つの卸サービス事業者２２０ｃ、２２０ｄにより提供される管理対象サービスを新たに追加する場合には、ＡＰＩアダプタ２１１ｃ、２１１ｄを生成する必要がある。即ち、図１に示すように、既存のＡＰＩアダプタ２１１ａ、２１１ｂに加えて、新規にＡＰＩアダプタ２１１ｃ、２１１ｄを生成する必要がある。
　本実施形態では、ＡＰＩアダプタ２１１ｃ、２１１ｄの生成の少なくとも一部を自動化することより、作業者の労力を軽減し且つ低コスト化を図る。以下詳細に説明する。
　図２は、図１に示したＡＰＩアダプタ２１１の詳細な構成を示すブロック図である。図２に示すように、ＡＰＩアダプタ２１１は、オーダ受付部２３１と、ＡＰＩ呼出ロジック部２３２と、サウスバウンドＡＰＩ実行部２３３を備える。ＡＰＩアダプタ２１１は、本実施形態に係るＡＰＩアダプタ生成装置１００に接続されている。
　オーダ受付部２３１は、オーケストレータ２１０に送信されるオーダＮ１を受け付け、オーダＮ１の内容を取得する。オーダ受付部２３１は、オーケストレータ２１０への応答処理を行う。具体的には、オーダ受付部２３１は、連携オーダ受付／応答処理として、オーケストレータ２１０との間で予め決められた手順に従って、オーダＮ１の受信からオーダＮ１の実行完了までの状態管理および通知、実行結果の流通を行う。
　オーダ受付部２３１は、オーダ内容の取得処理として、ＡＰＩ呼出ロジック部２３２の要請を受け、詳細なオーダ内容（カタログなど）を取得する。
　ＡＰＩ呼出ロジック部２３２は、サウスバウンドＡＰＩ２１２の起動条件をチェックし、予め設定された実行順序に従ってサウスバウンドＡＰＩ２１２を起動する。
　ＡＰＩ呼出ロジック部２３２は、オーケストレータ２１０からのオーダＮ１からサウスバウンドＡＰＩ２１２の実行に必要なパラメータを取り出し、サウスバウンドＡＰＩ実行部２３３に送信する。ＡＰＩ呼出ロジック部２３２は、サウスバウンドＡＰＩ２１２の実行結果をサウスバウンドＡＰＩ実行部２３３から取得する。ＡＰＩ呼出ロジック部２３２は、取得した前記実行結果をオーケストレータ２１０に流通するための適切なデータ形式に変換する。
　サウスバウンドＡＰＩ実行部２３３は、ＡＰＩ呼出ロジック部２３２から、サウスバウンドＡＰＩ２１２の実行に必要なデータを取得し、データ形式を変更して各卸サービス事業者２２０に送信する。
　サウスバウンドＡＰＩ実行部２３３は、各卸サービス事業者２２０からのレスポンスを受信し、適切な形式に変換してＡＰＩ呼出ロジック部２３２に返却する。
　サウスバウンドＡＰＩ実行部２３３は、各卸サービス事業者２２０との間で、各卸サービス事業者２２０のサウスバウンドＡＰＩ２１２を通して、個々のサウスバウンドＡＰＩ２１２に対応したリクエスト送信とレスポンス受信を行う。
　前述したように、図１に示したネットワークシステム２００において、新規に卸サービス事業者２２０ｃ、２２０ｄによる管理対象サービスが追加される場合には、オーケストレータ２１０に接続されるＡＰＩアダプタ２１１ｃ、２１１ｄを新規に生成する必要がある。
　本実施形態では、ＡＰＩアダプタ生成装置１００を設けることにより、ＡＰＩ呼出ロジック部２３２の設計の少なくとも一部を自動化し、ＡＰＩアダプタ２１１の生成を行う。
　ＡＰＩアダプタ２１１を生成する際には、設計、実装、試験を実施する必要がある。また、設計の工程には、「リソース設計」、「パラメータ設計」、「ロジック設計」が含まれる。実装の工程には、ＡＰＩ呼出ロジック部２３２の実装が含まれる。本実施形態では、「リソース設計」、「パラメータ設計」、「ロジック設計」の少なくとも一部を自動化する。また、ＡＰＩ呼出ロジック部２３２の実装を自動化する。
　［第１実施形態］
　次に、本実施形態に係るＡＰＩアダプタ生成装置１００の具体的な構成について説明する。図３は、第１実施形態に係るＡＰＩアダプタ生成装置１００、及びその周辺機器の詳細な構成を示すブロック図である。
　図３に示すように、本実施形態に係るＡＰＩアダプタ生成装置１００は、データモデル記憶部１１と、ＡＰＩ仕様記憶部１２と、ＡＰＩスキーマ変換部１３と、スキーマ情報記憶部１４と、外部情報記憶部１５を備えている。ＡＰＩアダプタ生成装置１００は、変換ルール算出部１６と、変換ルール記憶部１７と、変換ルール可視化部１８と、呼出ロジック部生成部１９（生成部）と、ＡＰＩ実行部生成部２０と、ＡＰＩアダプタ生成部２１と、ＡＰＩアダプタ記憶部２２を備えている。ＡＰＩアダプタ生成装置１００には、確認画面３３が接続されている。
　データモデル記憶部１１は、オーケストレータ２１０から入力されるオーケストレータデータモデル３１を取得して記憶する。
　ＡＰＩ仕様記憶部１２は、管理対象となるデータモデルのサウスバウンドＡＰＩ仕様３２（管理対象モデルのＡＰＩ仕様）を取得して記憶する。
　ＡＰＩスキーマ変換部１３は、ＡＰＩ仕様記憶部１２に記憶されているサウスバウンドＡＰＩ仕様３２を、スキーマの形式に変換する。図４は、オープンＡＰＩスペック形式で記述されたＡＰＩ仕様Ｐ１をＵＭＬ（Unified Modeling Language）形式のデータモデルＰ２に変換する例を示す説明図である。図４の符号ａ１、ａ２に示すスキーマ情報を例えば「WAPIml」により、ＵＭＬなどのデータモデルＰ２に変換する。
　スキーマ情報記憶部１４は、ＡＰＩスキーマ変換部１３で変換されたスキーマ情報を記憶する。
　外部情報記憶部１５は、オントロジーなどの外部から送信された情報を記憶する。
　変換ルール算出部１６は、既存のスキーママッチングを利用してデータモデルの変換ルールを算出する。変換ルール算出部１６では、ＡＰＩアダプタ２１１を生成する際の、リソース設計、パラメータ設計、ロジック設計を行う。
　変換ルール算出部１６は、サウスバウンドＡＰＩ２１２の仕様から導出できるデータスキーマと、オーケストレータ２１０におけるデータスキーマの変換ルールを導出する部分に、スキーママッチングの技術を適用することにより、モデル変換を自動化する。以下、「リソース設計及びパラメータ設計の工程」及び「ロジック設計の工程」について具体的に説明する。
　（リソース設計及びパラメータ設計の工程）
　図５Ａ、図５Ｂ、図５Ｃを参照して、リソース設計及びパラメータ設計の詳細について説明する。図５Ａは、Ａ社及びＢ社による管理対象サービスのＡＰＩアダプタを生成する際の、各社のデータモデルＭ１、Ｍ２のリソース設計、パラメータ設計を示す説明図である。図５Ｂは、Ａ社及びＢ社による管理対象サービスのＡＰＩアダプタを生成する際の、各社のデータモデルＭ１、Ｍ２のパラメータ値の変換を示す説明図である。図５Ｃは、オーケストレータＡＰとオーケストレータの関係を示す説明図である。
　リソース設計及びパラメータ設計を実施するためには、Ａ社及びＢ社が管理する管理対象サービスのデータモデルＭ１、Ｍ２と、オーケストレータ２１０のデータモデルＭ３の変換ルールを定義する必要がある。また、リソース、パラメータ単位の変換ルール、及びパラメータ値の変換ルールが必要である。
　例えば、図５Ａに示すように、Ａ社のデータモデルＭ１及びＢ社のデータモデルのリソース、及びパラメータを変換し、オーケストレータ２１０のデータモデルＭ３を生成する。具体的に、データモデルＭ１の「EC2Instance」、及びデータモデルＭ２の「Ｖirtual Machines」を、データモデルＭ３の「ＶＭ」に変換する。また、データモデルＭ１の「Instance Type」、及びデータモデルＭ２の「vmsize」を、データモデルＭ３の「hardware Spec」に変換する。
　また、図５Ｂに示すように、Ａ社のデータモデルＭ１及びＢ社のデータモデルＭ２のパラメータ値を変換し、オーケストレータ２１０のデータモデルＭ３を生成する。具体的に、オーケストレータ２１０のデータモデルＭ３を、独自に定義した「Large」、「Medium」、「Small」の３つに簡素化して設定する。データモデルＭ１のパラメータ値「m1.small」を「Small」に変換し、「a1.medium」を「Medium」に変換し、「m4.large」を「Large」に変換する。データモデルＭ２のパラメータ値「Dsv3」を「Small」に変換する。
　上記の変換ルールを設定することにより、図５Ｃに示すように、オーケストレータ２１０は、オーケストレータＡＰ２０３としてデータモデル「ＶＭ」が与えられた際に、クラウドベンダを意識することなく使用することができる。即ち、オーケストレータＡＰ２０３からは、図５Ａ、図５Ｂに示したデータモデルＭ１、及びデータモデルＭ２は同様のデータモデル「ＶＭ」として取り扱うことができる。
　具体的に、図５Ａ、図５Ｂに示したデータモデルの変換を、スキーママッチングを用いて変換する。スキーママッチングとして、例えば、「Graph-Based」手法を用いることができる。「Graph-Based」手法では、パラメータの名称のみならず、スキーマのグラフ／木構造を考慮した上でパラメータをマッチングすることが可能である。
　更に、データのスキーマのみならず、実際のデータ値（インスタンス）を使用する「Instance-based」手法や、このInstance-based」手法とスキーマ情報を合わせて使用する「Hybrid」手法を用いることも可能である。
　（ロジック設計の工程）
　次に、図６Ａ、図６Ｂを参照して、ロジック設計の詳細について説明する。図６Ａは、ＡＰＩの実行順序を示す説明図である。図６Ｂは、データモデルＭ１１を有する卸サービス事業者２２０であるＣ社、データモデルＭ１２を有する卸サービス事業者２２０であるＤ社、及びデータモデルＭ１３を有する卸サービス事業者２２０であるＥ社による管理対象サービスを追加する際の、各データモデルＭ１１～Ｍ１３のロジック設計を示す説明図である。
　管理対象サービスにおける複数のリソースをまとめて一つの単位で管理する場合には、ＡＰＩの実行順序、パラメータの流通関係を定義する必要がある。例えば、図６Ａに示すように、「ＶＰＣ」→「Subnet」→「ＥＣ２」の順に、ＡＰＩの実行順序を定義する。
　また、図６Ｂに示すように、Ｃ社、Ｄ社、Ｅ社の各データモデルＭ１１～Ｍ１３において、パラメータの流通関係を、図中の矢印Ｚ１、Ｚ２のように定義する。その結果、各データモデル間における流通関係が定義されたオーケストレータ２１０のデータモデルＭ１４が生成される。
　このように、変換ルール算出部１６では、データモデルの変換ルールを算出し、ＡＰＩアダプタ２１１を生成する際の、リソース設計、パラメータ設計、ロジック設計を行う。また、後述する呼出ロジック部生成部１９では、上記リソース設計、パラメータ設計、ロジック設計の結果に基づいて、ＡＰＩ呼出ロジック部２３２を生成する。
　図３に戻って、変換ルール記憶部１７は、変換ルール算出部１６で算出されたモデル変換ルールを記憶する。
　変換ルール可視化部１８は、変換ルール記憶部１７に記憶されているモデル変換ルールを確認画面３３に出力することで、モデル変換ルールをユーザが確認できるように可視化する。例えば、モデル変換ルールのデータを確認画面３３に送信し、このデータを確認画面３３にて表示することにより、モデル変換ルールをユーザに認識させる。
　呼出ロジック部生成部１９は、変換ルール算出部１６で算出されたリソース設計、パラメータ設計、ロジック設計の結果に基づいて、ＡＰＩ呼出ロジック部２３２を自動生成する。呼出ロジック部生成部１９は、変換ルール算出部１６で算出されたモデル変換ルールに従って、テンプレートのソースコードを書き換える。
　以下、ソースコードの生成手順を図７Ａ、図７Ｂ、図８Ａ、図８Ｂを参照して説明する。図７Ａは、図５Ａに示したデータモデルＭ１のパラメータを、オーケストレータ２１０のデータモデルＭ３のパラメータに変換する際の対応関係を示す説明図、図７Ｂは、図７Ａに示すパラメータを記述したソースコードを示す説明図である。
　図７Ａに示すように、データモデルＭ１の符号ｘ１に示す「EC2Instance」を符号ｘ２に示す「ＶＭ」に変更し、符号ｘ３に示す「InstanceType」を符号ｘ４に示す「hardwareSpec」に変更する場合には、図７Ｂの符号ｙ１に示す「ec2」、符号ｙ２に示す「vm」、符号ｙ３に示す「instance type」、符号ｙ４に示す「hardwareSpec」のようにソースコードを記述する。
　即ち、予め図７Ｂに示すようなソースコードのテンプレートを用意しておき、このテンプレートに変更データを書き込むことにより、必要とするデータモデル間を変換するソースコードを生成することができる。
　図８Ａは、図５Ｂに示したデータモデルＭ１のパラメータ値を、オーケストレータ２１０のデータモデルＭ３のパラメータ値に変換する際の対応関係を示す説明図である。図８Ｂは、図８Ａに示すパラメータ値を記述したソースコードを示す説明図である。
　図８Ａに示すように、データモデルＭ１の符号ｘ１１に示す「M4.large」を、符号ｘ１２に示す「Large」に変更する場合には、図８Ｂのソースコード３０１の符号ｙ１１に示す「m4.large、符号ｙ１２に示す「large」を記述する。また、何らかの計算ロジックが必要な場合には、ソースコード３０２に示すような関数に変換する。
　図３に戻って、ＡＰＩ実行部生成部２０は、ＡＰＩ仕様記憶部１２に記憶されているサウスバウンドＡＰＩ仕様３２に基づいて、ＡＰＩアダプタ２１１におけるサウスバウンドＡＰＩ実行部２３３（図２参照）を生成する。サウスバウンドＡＰＩ実行部２３３の生成には、例えば「Swagger Codegen/Open API Generator」等の既存ツールを活用することができる。
　ＡＰＩアダプタ生成部２１は、呼出ロジック部生成部１９で生成された呼出ロジック部２３２、及びサウスバウンドＡＰＩ実行部２３３に基づいて、ＡＰＩアダプタ２１１を生成する。また、必要に応じて記憶されているＡＰＩアダプタ２１１を外部に出力する。
　ＡＰＩアダプタ記憶部２２は、ＡＰＩアダプタ生成部２１で生成されたＡＰＩアダプタ２１１を記憶する。
　［第１実施形態の動作］
　次に、第１実施形態に係るＡＰＩアダプタ生成装置１００の処理手順を、図９に示すフローチャートを参照して説明する。初めに、図９のステップＳ１１において、データモデル記憶部１１は、オーケストレータ２１０から出力されるオーケストレータデータモデル３１を取得し、データモデル記憶部１１に記憶する。
　ステップＳ１２において、ＡＰＩ仕様記憶部１２は、オーケストレータ２１０から出力されるサウスバウンドＡＰＩ仕様３２を取得し、ＡＰＩ仕様記憶部１２に記憶する。
　ステップＳ１３において、ＡＰＩスキーマ変換部１３は、ＡＰＩ仕様記憶部１２に記憶されているサウスバウンドＡＰＩ仕様３２をスキーマの形式に変換する。変換後のスキーマ情報をスキーマ情報記憶部１４に記憶する。
　ステップＳ１４において、変換ルール算出部１６は、データモデル記憶部１１に記憶されているオーケストレータデータモデル３１、スキーマ情報記憶部１４に記憶されているスキーマ情報、及び外部情報記憶部１５に記憶されている外部情報に基づき、モデル変換ルールを算出する。変換ルール算出部１６は、算出したモデル変換ルールを変換ルール記憶部１７に記憶する。
　ステップＳ１５において、変換ルール可視化部１８は、必要に応じて変換ルール記憶部１７に記憶されている変換ルールを確認画面３３に出力する。操作者は、確認画面３３を見ることにより、変換ルールを認識することができる。
　ステップＳ１６において、呼出ロジック部生成部１９は、変換ルール記憶部１７に記憶されているモデル変換ルールに基づき、ＡＰＩアダプタのソースコードを書き換えて、ＡＰＩ呼出ロジック部２３２を生成する。これにより、ＡＰＩ呼出ロジック部２３２を自動生成することができる。
　ステップＳ１７において、ＡＰＩ実行部生成部２０は、ＡＰＩ仕様記憶部１２に記憶されているサウスバウンドＡＰＩアダプタの仕様に基づいて、図２に示すサウスバウンドＡＰＩ実行部２３３を生成する。
　ステップＳ１８において、ＡＰＩアダプタ生成部２１は、ＡＰＩ実行部生成部２０で生成されたサウスバウンドＡＰＩ実行部２３３、及び、呼出ロジック部生成部１９で生成されたＡＰＩ呼出ロジック部２３２に基づいて、最終的なＡＰＩアダプタ２１１を生成する。生成されたＡＰＩアダプタ２１１は、ＡＰＩアダプタ記憶部２２に記憶される。
　[第１実施形態の効果]
　このように、第１実施形態に係るＡＰＩアダプタ生成装置１００は、オーケストレータ２１０のデータモデルと、管理対象モデルのＡＰＩ仕様を取得し、オーケストレータ２１０のデータスキーマ、及びＡＰＩ仕様のデータスキーマに基づいてスキーママッチングを行い、モデル変換ルールを算出する変換ルール算出部１６と、モデル変換ルールに基づいて、ＡＰＩアダプタ実行ロジックを記述したＡＰＩ呼出ロジック部のソースコードを書き換える呼出ロジック部生成部１９（生成部）と、ソースコードが書き換えられたＡＰＩ呼出ロジック部に基づいて、管理対象モデルのＡＰＩアダプタを生成するＡＰＩアダプタ生成部２１と、を備える。
　上記の構成により、第１実施形態に係るＡＰＩアダプタ生成装置１００では、オーケストレータ２１０に対して、新規の管理対象サービスを有する卸サービス事業者２２０が追加される際に、新規にＡＰＩアダプタ２１１を設計する際の設計工程を容易に実施することが可能となる。具体的に、ＡＰＩアダプタ２１１の生成に要する労力、時間、コストを低減することが可能となる。
　第１実施形態では、呼出ロジック部生成部１９は、所定のソースコードのテンプレートを設定し、管理対象のＡＰＩ仕様のリソース、パラメータ名、パラメータ値の少なくとも一つを、テンプレートに書き込むことによりソースコードを生成し、ＡＰＩ呼出ロジック部を生成する。このため、ＡＰＩ呼出ロジック部２３２を簡単な操作で生成することが可能になる。
　［第２実施形態］
　次に、本実施形態の第２実施形態について説明する。前述した第１実施形態では、新規にネットワークシステム２００に接続される管理対象サービスのデータモデルに対し、テンプレートを用いてＡＰＩアダプタ２１１を生成した。第２実施形態では、複数のサービスモデルのリソースを一つにまとめ、多対一の対応によりマッチングを行い、ＡＰＩアダプタ２１１を生成する例について説明する。
　第２実施形態では、多対一の対応によるマッチングを行う際に、リソース単位とパラメータ単位でマッチングの寄与率を可変にする。または、サウスバウンドＡＰＩのスキーマ情報から生成した依存関係グラフを利用して、確度の高い多対一のマッチングを行う。
　図１０は、第２実施形態に係るＡＰＩアダプタ生成装置１００ａの構成を示すブロック図である。図１０に示すＡＰＩアダプタ生成装置１００ａは、前述の図３に示したＡＰＩアダプタ生成装置１００と対比して、依存関係グラフ生成部２３、及び依存関係グラフ記憶部２９を備えている点で相違する。以下では、図３に示す構成要素と同一の構成要素については同一符号を付し、構成説明を省略する。
　図１０に示す依存関係グラフ生成部２３は、サウスバウンドＡＰＩ２１２のスキーマ情報から、事前にリソース間の依存関係を抽出しグラフ表現を生成する。図１１は、卸サービス事業者２２０であるＣ社、Ｄ社、Ｅ者の各データモデルＭ１１～Ｍ１３のリソース及びパラメータを、オーケストレータのデータモデルＭ１４のリソース及びパラメータに変換する際の対応関係を示す説明図である。
　依存関係グラフ生成部２３は、図１１の符号ｘ３２、ｘ３４に示すように、サウスバウンドＡＰＩ仕様３２から抽出したスキーマ情報から符号ｘ３２、ｘ３４に示すリソース間の依存関係を分析してグラフを生成する。
　依存関係グラフ記憶部２９は、依存関係グラフ生成部２３で生成された依存関係グラフを記憶する。
　変換ルール算出部１６は、前述した第１実施形態の機能に加え、事前準備として複数のリソースをまとめて一つ集約する際に、図１１に示すように、各社のデータモデルＭ１１～Ｍ１３を一つにまとめる。具体的に、複数のリソースをまとめて一つに集約する際に、推定の精度を向上させ、且つ、多対一のマッチングを可能にするため、リソース単位とパラメータ単位のマッチング寄与率を設定する。更に、該寄与率を可変にする。
　具体的に、下記の（１）式によりパラメータｉとｊがマッチングする確率「Ｍ(i,j)」を算出する。
　Ｍ(i,j)＝ｋ*Ｒ(i,j)＋（１－ｋ）*Ｐ(i,j)　　　　…（１）
　（１）式において、「Ｍ(i,j)」は既存のスキーママッチングを採用したときの、パラメータｉとパラメータｊがマッチングする確率を示す。「Ｒ(i,j)」は、パラメータｉ，ｊが属するリソースどうしのマッチング確率を示す。「Ｐ(i,j)」は、パラメータのみでのマッチング確率を示す。「ｋ」は可変の数値であり「Ｒ(i,j)」の寄与率を示す。
　（１）式において、リソース単位でのマッチングとパラメータ単位でのマッチングの重みを調整可能とする。即ち、上記寄与率ｋの数値を調整可能とする。
　また、上述したサウスバウンドＡＰＩ２１２のスキーマ情報から生成した依存関係のグラフを利用して、確度の高い多対一のマッチングができるようにする。
　変換ルール算出部１６は、初めに、リソース単位でのマッチング情報の寄与率ｋを下げてマッチングを実施する。変換ルール算出部１６は、上記のマッチングが取れた場合には、パラメータが属しているリソースを確認する。依存関係グラフ上で、繋がっていればそれら全てに、多対一でマッチングしたものとする。マッチング候補のリソースが複数ある場合には、依存関係グラフ上でより近い距離でつながっている方を選択する。
　図１２は、第２実施形態に係るＡＰＩアダプタ生成装置１００ａによるコード変換処理の手順を示す説明図である。図１２に示すように、変換ルール記憶部１７に記憶されるモデル変換ルールは、前述した（１）式に示した「Ｒ(i,j)」の寄与率「ｋ」を設定し、マッチングの重みを調整できるようにする。
　図１２のＳＴ１において、依存関係グラフ生成部２３は、サウスバウンドＡＰＩ仕様３２から抽出したスキーマ情報に基づいて、複数のリソース間の依存関係を分析して依存関係グラフを生成する。
　ＳＴ２において、変換ルール算出部１６は、トポロジカルソートなどのアルゴリズムを用いて、複数のソースコードの実行順序を算出する。
　ＳＴ３において、呼出ロジック部生成部１９は、依存関係グラフ、及び（１）式に示した重み付けに基づいて、ＡＰＩアダプタ２１１のソースコードを書き換える。
　上記のように、変換ルール算出部１６は、可変寄与率「ｋ」及び依存関係グラフを活用してマッチング方式を算出している。
　次に、図１１及び図１３を参照して、具体的なソースコードの書き換えについて説明する。前述したように、図１１は、Ｃ社、Ｄ社、Ｅ社の各データモデルＭ１１～Ｍ１３のリソース及びパラメータを、オーケストレータのデータモデルＭ１４のリソース及びパラメータに変換する際の対応関係を示す説明図である。また、図１３は、図１１に示したリソース及びパラメータを記述したソースコードを示す説明図である。
　図１１に示したデータモデルＭ１１、Ｍ１２、Ｍ１３をオーケストレータ２１０のデータモデルＭ１４に変換する際に、符号ｘ３１に示す「cidrBlock」を、図１３に示すソースコードの符号ｙ３１に示す「vpc_cidrBlock」に記述する。また、図１１の符号ｘ１２に示すリソース間の依存関係を、図１３の符号ｙ３２に示す「vcp.id」に記述する。図１１の符号ｘ３３に示す「cidrBlock」を、図１３の符号ｙ３３に示す「subnet_cidrBlock」に記述する。
　図１１の符号ｘ３４に示すリソース間の依存関係を、図１３の符号ｙ３４に示す「subnet.id」に記述する。図１１の符号ｘ３５に示す「networkSegment」を、図１３の符号ｙ３５に示す「vm.networkSegment」に記述する。図１１の符号ｘ３６に示す「subnetSegment」を、図１３の符号ｙ３６に示す「vm.subnetSegment」に記述する。
　図１３に示す符号ｙ３７は、マッチングした全てのリソースの定義を示している。符号ｙ３８は、算出した実行順序で生成されたリソースを示している。
　上述のように、各データモデルＭ１～Ｍ３の重み付けを考慮して、ＡＰＩアダプタのソースコードへ落とし込むことが可能になる。
　このように、第２実施形態に係るＡＰＩアダプタ生成装置１００ａでは、複数のリソースをまとめて一つに集約する場合において、確度の高いマッチングを行うことが可能となる。
　具体的に、変換ルール算出部１６は、管理対象のＡＰＩ仕様に含まれる複数のリソースを、可変寄与率ｋ、及び依存関係グラフ情報を用いてマッチングして一つのリソースに集約する。
　変換ルール算出部１６は、リソース集約後の管理対象のＡＰＩ仕様のデータスキーマと、オーケストレータ２１０のデータスキーマに基づいてスキーママッチングを行い、ＡＰＩアダプタのモデル変換ルールを生成する。その結果、確度の高い多対一のマッチングが可能となり、新規のＡＰＩアダプタ２１１を容易に生成することが可能となる。
　[第３実施形態の説明]
　次に、本実施形態の第３実施形態について説明する。オーケストレータ２１０のデータモデルの抽象度が高くなると、リソース名、パラメータ名とその構造との乖離が大きくなり、マッチングが難しくなる。既存のスキーママッチングの手法では、スキーマ情報に加えて、インスタンス情報も加味するハイブリッド手法により精度の向上が図られているが、オーケストレータ２１０に適用する場合には、インスタンス情報の取得が難しい。
　第３実施形態では、オーケストレータ２１０が有するオーケストレータＡＰ２０３に含まれるインスタンス情報、及び構成情報を活用してマッチング精度の向上を図る。
　図１４は、第３実施形態に係るＡＰＩアダプタ生成装置１００ｂの構成を示すブロック図である。図１４では、図３に示したＡＰＩアダプタ生成装置１００に対して、追加する構成要素のみを示している。即ち、第３実施形態に係るＡＰＩアダプタ生成装置１００ｂは、図３に示した各構成要素１１～２１に加えて、図１４に示す構成要素２４～２８を備えている。以下、各構成要素２４～２８について説明する。
　図１４に示すオーケストレータＡＰ収集部２４は、オーケストレータ２１０からオーケストレータＡＰ２０３を収集する。オーケストレータＡＰ２０３はノースバウンドＡＰＩ２０４を用いて生成される。オーケストレータＡＰ２０３は、例えばカタログである。
　ＡＰ情報抽出部２５は、収集したオーケストレータＡＰ２０３から、サウスバウンドＡＰＩ２１２のインスタンス情報、オーケストレータＡＰの構成情報グラフを抽出する。「構成情報グラフ」とは、後述する図１６Ｂに示すように、例えば、アプリ、コンピューティングリソース、ネットワークなどのデータ構造を示す。
　インスタンス情報記憶部２６は、ＡＰ情報抽出部２５で抽出したサウスバウンドＡＰＩ２１２のインスタンス情報を記憶する。
　構成情報グラフ記憶部２７は、ＡＰ情報抽出部２５で抽出したオーケストレータＡＰ構成情報グラフを記憶する。具体的に、図１５Ａに示すように、各オーケストレータＡＰ２０３ａ～２０３ｃに含まれるシステムの構成情報を、構成情報グラフとして記憶する。
　類似度算出部２８は、構成情報グラフ記憶部２７に記憶されている構成情報グラフに基づいて、リソース間の類似度を算出する。
　変換ルール算出部１６は、前述したオーケストレータデータモデル、スキーマ情報、外部情報に加えて、サウスバウンドＡＰＩ２１２のインスタンス情報、オーケストレータＡＰ構成情報グラフ、及びリソース間の類似度に基づいて、ソースコードの変換ルールを算出する。
　図１５Ａは、オーケストレータＡＰ２０３とオーケストレータ２１０の関係を示す説明図である。図１５Ｂは、図１５Ａに示したオーケストレータＡＰ２０３のデータモデルに含まれるリソース及びパラメータを記述したソースコードを示す説明図である。図１５Ｃは、図１５Ｂに示したソースコードのインスタンス情報を示す説明図である。図１５Ｄは、図１５Ｂに示したソースコードの構成情報を示す説明図である。
　変換ルール算出部１６は、図１５Ｂの符号ｘ２１、ｘ２２、ｘ２３に示すインスタンス情報、及び構成情報を取得し、図１５Ｃの符号ｙ２１、ｙ２２、ｙ２３に示すように、各「ｉｄ」に記述するデータを書き込む。また、図１５Ｄの符号Ｑ１に示すように、構成情報を設定する。
　また、変換ルール算出部１６は、オーケストレータＡＰ２０３に含まれるシステムの構成情報グラフの類似性を用いて、同種の概念である可能性が高いものに対して、マッチング確率が高くなるように設定する。
　図１６Ａは、複数のオーケストレータＡＰ２０３ａ、２０３ｂ、２０３ｃのデータモデルの構成情報グラフを示す説明図である。図１６Ｂは、オーケストレータＡＰ２０３の基本的なデータモデルの構成情報グラフを示す説明図である。図１６Ｃは、各オーケストレータＡＰ２０３に含まれるパラメータ５１、５２、５３の類似性に基づいて、コンピューティングリソース５０を生成する説明図である。
　類似度算出部２８は、図１６Ｂに示す「アプリ」、「コンピューティングリソース」、「ネットワーク」の構造と、図１６Ａに示す各オーケストレータＡＰ２０３ａ、２０３ｂ、２０３ｃの構成情報を対比してリソース間の類似度を算出する。
　例えば、図１６Ａに示すように、３種類のオーケストレータＡＰ２０３ａ、２０３ｂ、２０３ｃが、それぞれ「ＶＭ５１」、「コンテナ５２」、「サーバレス５３」のパラメータを有する場合には、図１６Ｃに示すように、各パラメータ５１、５２、５３の類似性に基づいて、コンピューティングリソース５０を設定する。
　具体的な算出方法として、パラメータｉとパラメータｊがマッチングする確率を「Ｍ´(i,j)」とし、下記（２）式により設定する。
　Ｍ´(i,j)＝（１-ａ）・Ｍ(i,j)＋ａ・Ｓ(i,j)　　　…（２）
　（２）式において、「Ｍ(i,j)」は既存のスキーママッチングを採用したときの、パラメータｉとパラメータｊがマッチングする確率を示す。「Ｓ(i,j)」は、構成情報グラフにおけるリソース間の類似度を加味したパラメータｉ、ｊの類似度を示す。「ａ」は、構成情報グラフの類似度の寄与率を示す。こうすることにより、複数のオーケストレータＡＰ２０３において、同種の概念である可能性の高い場合にマッチング確率が高くなるように設定できる。
　このように、第３実施形態に係るＡＰＩアダプタ生成装置１００ｂでは、上記（２）式を用いてスキーママッチングを実施することにより、複数のオーケストレータＡＰ２０３が与えられた場合において、新規のＡＰＩアダプタ２１１を簡便且つ高精度に生成することができる。
　また、第３実施形態に係るＡＰＩアダプタ生成装置１００ｂでは、オーケストレータＡＰ２０３の情報に含まれる構成情報グラフに基づいて、各オーケストレータＡＰ２０３に含まれる各リソース間の類似度を算出している。算出した類似度、及びインスタンス情報に基づいて、モデル変換ルールを生成し、ＡＰＩ呼出ロジック部２３２を生成している。その結果、新規のＡＰＩアダプタ２１１を間便且つ高精度に生成することができる。
　上記説明した各実施形態のＡＰＩアダプタ生成装置１００、１００ａ、１００ｂには、図１７に示すように例えば、ＣＰＵ（Central Processing Unit、プロセッサ）９０１と、メモリ９０２と、ストレージ９０３（HDD：HardDisk Drive、SSD：SolidState Drive）と、通信装置９０４と、入力装置９０５と、出力装置９０６とを備える汎用的なコンピュータシステムを用いることができる。メモリ９０２およびストレージ９０３は、記憶装置である。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、ＡＰＩアダプタ生成装置１００、１００ａ、１００ｂの各機能が実現される。
　なお、ＡＰＩアダプタ生成装置１００、１００ａ、１００ｂは、１つのコンピュータで実装されてもよく、あるいは複数のコンピュータで実装されても良い。また、ＡＰＩアダプタ生成装置１００、１００ａ、１００ｂは、コンピュータに実装される仮想マシンであっても良い。
　なお、ＡＰＩアダプタ生成装置１００、１００ａ、１００ｂ用のプログラムは、ＨＤＤ、ＳＳＤ、ＵＳＢ（Universal Serial Bus）メモリ、ＣＤ (Compact Disc)、ＤＶＤ (Digital Versatile Disc)などのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
　なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。　
　１１　データモデル記憶部
　１２　ＡＰＩ仕様記憶部
　１３　ＡＰＩスキーマ変換部
　１４　スキーマ情報記憶部
　１５　外部情報記憶部
　１６　変換ルール算出部
　１７　変換ルール記憶部
　１８　変換ルール可視化部
　１９　呼出ロジック部生成部（生成部）
　２０　ＡＰＩ実行部生成部
　２１　ＡＰＩアダプタ生成部
　２２　ＡＰＩアダプタ記憶部
　２３　依存関係グラフ生成部
　２４　オーケストレータＡＰ収集部
　２５　ＡＰ情報抽出部
　２６　インスタンス情報記憶部
　２７　構成情報グラフ記憶部
　２８　類似度算出部
　２９　依存関係グラフ記憶部
　３１　オーケストレータデータモデル
　３２　サウスバウンドＡＰＩ仕様
　３３　確認画面
　１００、１００ａ、１００ｂ　ＡＰＩアダプタ生成装置
　２００　ネットワークシステム
　２０１　エンドユーザ
　２０２　サービスプロバイダ
　２０３　オーケストレータＡＰ
　２１０　オーケストレータ
　２１１（２１１ａ～２１１ｄ）　ＡＰＩアダプタ
　２２０（２２０ａ～２２０ｄ）卸サービス事業者
　２３１　オーダ受付部
　２３２　ＡＰＩ呼出ロジック部
　２３３　サウスバウンドＡＰＩ実行部

Claims (8)

  1. 　オーケストレータのデータモデルと、管理対象のＡＰＩ仕様を取得し、前記オーケストレータのデータスキーマ、及び前記ＡＰＩ仕様のデータスキーマに基づいてスキーママッチングを行い、モデル変換ルールを算出する変換ルール算出部と、
    　前記モデル変換ルールに基づいて、ＡＰＩアダプタ実行ロジックを記述したＡＰＩ呼出ロジック部のソースコードを書き換える生成部と、
    　前記ソースコードが書き換えられたＡＰＩ呼出ロジック部に基づいて、前記管理対象のＡＰＩアダプタを生成するＡＰＩアダプタ生成部と、
    　を備えたＡＰＩアダプタ生成装置。
  2. 　前記変換ルール算出部は、前記オーケストレータのデータモデル及び前記管理対象のＡＰＩ仕様を、リソース及びパラメータの少なくとも一方の単位でスキーママッチングを行い、前記モデル変換ルールを算出する請求項１に記載のＡＰＩアダプタ生成装置。
  3. 　前記変換ルール算出部は、前記管理対象のＡＰＩ仕様に含まれる複数のリソースを、可変寄与率、及び依存関係グラフ情報を用いてマッチングして一つのリソースに集約し、
    　リソース集約後の前記管理対象のＡＰＩ仕様のデータスキーマと、前記オーケストレータのデータスキーマに基づいてスキーママッチングを行う請求項１または２に記載のＡＰＩアダプタ生成装置。
  4. 　前記生成部は、所定のソースコードのテンプレートを設定し、前記管理対象のＡＰＩ仕様のリソース、パラメータ名、パラメータ値の少なくとも一つを、前記テンプレートに書き込むことにより前記所定のソースコードを書き換えて前記ＡＰＩ呼出ロジック部を生成する請求項１～３のいずれか１項に記載のＡＰＩアダプタ生成装置。
  5. 　前記オーケストレータに含まれるオーケストレータＡＰの情報から、インスタンス情報及び構成情報グラフを抽出する情報抽出部と、
    　前記構成情報グラフに基づいて、前記オーケストレータＡＰに含まれる各リソース間の類似度を算出する類似度算出部と、
    　を更に備え、
    　前記変換ルール算出部は、前記インスタンス情報、及び前記類似度に基づいて、前記モデル変換ルールを生成する請求項１～４のいずれか１項に記載のＡＰＩアダプタ生成装置。
  6. 　前記スキーママッチングは、Graph-Based手法、Instance-based手法、及び、前記Instance-based手法とスキーマ情報を組み合わせた「Hybrid」手法、のうちの少なくとも一つを用いる請求項１～５のいずれか１項に記載のＡＰＩアダプタ生成装置。
  7. 　コンピュータが行うＡＰＩアダプタ生成方法であって、
    　オーケストレータのデータモデルと、管理対象のＡＰＩ仕様を取得するステップと、
    　前記オーケストレータのデータスキーマ、及び前記ＡＰＩ仕様のデータスキーマに基づいてスキーママッチングを行い、モデル変換ルールを算出するステップと、
    　前記モデル変換ルールに基づいて、ＡＰＩアダプタ実行ロジックを記述したＡＰＩ呼出ロジック部のソースコードを書き換えるステップと、
    　前記ソースコードが書き換えられたＡＰＩ呼出ロジック部に基づいて、前記管理対象のＡＰＩアダプタを生成するステップと、
    　を備えたＡＰＩアダプタ生成方法。
  8. 　請求項１～６のいずれか１項に記載のＡＰＩアダプタ生成装置としてコンピュータを機能させるＡＰＩアダプタ生成プログラム。
PCT/JP2021/014763 2021-04-07 2021-04-07 Ａｐｉアダプタ生成装置及びａｐｉアダプタ生成方法並びにａｐｉアダプタ生成プログラム WO2022215194A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2023512573A JPWO2022215194A1 (ja) 2021-04-07 2021-04-07
PCT/JP2021/014763 WO2022215194A1 (ja) 2021-04-07 2021-04-07 Ａｐｉアダプタ生成装置及びａｐｉアダプタ生成方法並びにａｐｉアダプタ生成プログラム
US18/554,256 US20240118946A1 (en) 2021-04-07 2021-04-07 Api adapter generator, api adapter generation method, and api adapter generation program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/014763 WO2022215194A1 (ja) 2021-04-07 2021-04-07 Ａｐｉアダプタ生成装置及びａｐｉアダプタ生成方法並びにａｐｉアダプタ生成プログラム

Publications (1)

Publication Number Publication Date
WO2022215194A1 true WO2022215194A1 (ja) 2022-10-13

Family

ID=83545283

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/014763 WO2022215194A1 (ja) 2021-04-07 2021-04-07 Ａｐｉアダプタ生成装置及びａｐｉアダプタ生成方法並びにａｐｉアダプタ生成プログラム

Country Status (3)

Country Link
US (1) US20240118946A1 (ja)
JP (1) JPWO2022215194A1 (ja)
WO (1) WO2022215194A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016207202A (ja) * 2015-04-23 2016-12-08 富士通株式会社 クエリメディエータ、多言語データティアのクエリ方法、多言語データティアのクエリ方法を実行するためのコンピュータプログラム
WO2019163793A1 (ja) * 2018-02-20 2019-08-29 日本電信電話株式会社 Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム
WO2020026778A1 (ja) * 2018-08-02 2020-02-06 日本電信電話株式会社 Ａｐｉアダプタ作成装置、ａｐｉアダプタ作成方法およびａｐｉアダプタ作成プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016207202A (ja) * 2015-04-23 2016-12-08 富士通株式会社 クエリメディエータ、多言語データティアのクエリ方法、多言語データティアのクエリ方法を実行するためのコンピュータプログラム
WO2019163793A1 (ja) * 2018-02-20 2019-08-29 日本電信電話株式会社 Ａｐｉアダプタ、ａｐｉアダプタ作成方法、およびプログラム
WO2020026778A1 (ja) * 2018-08-02 2020-02-06 日本電信電話株式会社 Ａｐｉアダプタ作成装置、ａｐｉアダプタ作成方法およびａｐｉアダプタ作成プログラム

Also Published As

Publication number Publication date
JPWO2022215194A1 (ja) 2022-10-13
US20240118946A1 (en) 2024-04-11

Similar Documents

Publication Publication Date Title
US10713664B1 (en) Automated evaluation and reporting of microservice regulatory compliance
US8751620B2 (en) Validating deployment patterns in a networked computing environment
US8694822B2 (en) Disaster recovery in a networked computing environment
US8843889B2 (en) Managing application template artifacts in a networked computing environment
US8924561B2 (en) Dynamically resizing a networked computing environment to process a workload
US10680902B2 (en) Virtual agents for facilitation of network based storage reporting
US11645438B2 (en) Generating a template-driven schematic from a netlist of electronic circuits
US9977653B2 (en) Discovery and modeling of deployment actions for multiple deployment engine providers
JP2017519314A (ja) 製品、材料及び製造工程の統合化された設計向けのモデルを活用した計算プラットフォーム
US8874513B2 (en) Transitioning application replication configurations in a networked computing environment
US11378942B2 (en) Progressive guidance of digital twin model assembly
CN113448678A (zh) 应用信息生成方法、部署方法及装置、系统、存储介质
WO2019160008A1 (ja) アプリケーション分割装置、方法およびプログラム
US10657230B2 (en) Analysis of output files
WO2022215194A1 (ja) Ａｐｉアダプタ生成装置及びａｐｉアダプタ生成方法並びにａｐｉアダプタ生成プログラム
Aggarwal et al. Reliability growth analysis for multi-release open source software systems with change point
JP2014174609A (ja) ハードウェア構成見積システム、ハードウェア構成見積方法及びハードウェア構成見積プログラム
CN104424012A (zh) 用于提供自定义虚拟装置的方法和设备
US11750443B2 (en) System configuration derivation device, method, and computer-readable recording medium
Svorobej et al. Towards automated data-driven model creation for cloud computing simulation
US11182606B2 (en) Converting chart data
CN104021027A (zh) 提供虚拟装置的方法和设备
US10713153B1 (en) Method and system for testing an extended pattern using an automatic pattern testing engine
Ramisetty et al. Ontology integration for advanced manufacturing collaboration in cloud platforms
Wang et al. Parallel Monte Carlo method with MapReduce for option pricing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21935998

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2023512573

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 18554256

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21935998

Country of ref document: EP

Kind code of ref document: A1