特許 7606133 ＡＰＩアダプタ生成装置及びＡＰＩアダプタ生成方法並びにＡＰＩアダプタ生成プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-17

(45)【発行日】2024-12-25

(54)【発明の名称】ＡＰＩアダプタ生成装置及びＡＰＩアダプタ生成方法並びにＡＰＩアダプタ生成プログラム

(51)【国際特許分類】

   G06F 8/30 20180101AFI20241218BHJP

【ＦＩ】

G06F8/30

【請求項の数】 8

(21)【出願番号】P 2023512573

(86)(22)【出願日】2021-04-07

(86)【国際出願番号】 JP2021014763

(87)【国際公開番号】W WO2022215194

(87)【国際公開日】2022-10-13

【審査請求日】2023-09-12

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100083806

【弁理士】

【氏名又は名称】三好 秀和

(74)【代理人】

【識別番号】100129230

【弁理士】

【氏名又は名称】工藤 理恵

(72)【発明者】

【氏名】武 直樹

(72)【発明者】

【氏名】加藤 能史

(72)【発明者】

【氏名】大谷 未稚

(72)【発明者】

【氏名】斎藤 清隆

(72)【発明者】

【氏名】近藤 悟

(72)【発明者】

【氏名】三好 優

【審査官】今川 悟

(56)【参考文献】

【文献】国際公開第２０２０／０２６７７８（ＷＯ，Ａ１）

【文献】国際公開第２０１９／１６３７９３（ＷＯ，Ａ１）

【文献】特開２０１６－２０７２０２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ８／３０

(57)【特許請求の範囲】

【請求項1】

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

【請求項2】

前記変換ルール算出部は、前記オーケストレータのデータモデル及び前記管理対象のＡＰＩ仕様を、リソース及びパラメータの少なくとも一方の単位でスキーママッチングを行い、前記モデル変換ルールを算出する請求項１に記載のＡＰＩアダプタ生成装置。

【請求項3】

前記変換ルール算出部は、前記管理対象のＡＰＩ仕様に含まれる複数のリソースを、可変寄与率、及び依存関係グラフ情報を用いてマッチングして一つのリソースに集約し、
リソース集約後の前記管理対象のＡＰＩ仕様のデータスキーマと、前記オーケストレータのデータスキーマに基づいてスキーママッチングを行う請求項１または２に記載のＡＰＩアダプタ生成装置。

【請求項4】

前記生成部は、所定のソースコードのテンプレートを設定し、前記管理対象のＡＰＩ仕様のリソース、パラメータ名、パラメータ値の少なくとも一つを、前記テンプレートに書き込むことにより前記所定のソースコードを書き換えて前記ＡＰＩ呼出ロジック部を生成する請求項１～３のいずれか１項に記載のＡＰＩアダプタ生成装置。

【請求項5】

前記オーケストレータに含まれるオーケストレータＡＰの情報から、インスタンス情報及び構成情報グラフを抽出する情報抽出部と、
前記構成情報グラフに基づいて、前記オーケストレータＡＰに含まれる各リソース間の類似度を算出する類似度算出部と、
を更に備え、
前記変換ルール算出部は、前記インスタンス情報、及び前記類似度に基づいて、前記モデル変換ルールを生成する請求項１～４のいずれか１項に記載のＡＰＩアダプタ生成装置。

【請求項6】

前記スキーママッチングは、Graph-Based手法、Instance-based手法、及び、前記Instance-based手法とスキーマ情報を組み合わせた「Hybrid」手法、のうちの少なくとも一つを用いる請求項１～５のいずれか１項に記載のＡＰＩアダプタ生成装置。

【請求項7】

コンピュータが行うＡＰＩアダプタ生成方法であって、
オーケストレータのデータモデルと、管理対象のＡＰＩ仕様を取得するステップと、
前記オーケストレータのデータスキーマ、及び前記ＡＰＩ仕様のデータスキーマに基づいてスキーママッチングを行い、モデル変換ルールを算出するステップと、
前記モデル変換ルールに基づいて、ＡＰＩアダプタ実行ロジックを記述したＡＰＩ呼出ロジック部のソースコードを書き換えるステップと、
前記ソースコードが書き換えられたＡＰＩ呼出ロジック部に基づいて、前記管理対象のＡＰＩアダプタを生成するステップと、
を備えたＡＰＩアダプタ生成方法。

【請求項8】

請求項１～６のいずれか１項に記載のＡＰＩアダプタ生成装置としてコンピュータを機能させるＡＰＩアダプタ生成プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ＡＰＩアダプタ生成装置及びＡＰＩアダプタ生成方法並びにＡＰＩアダプタ生成プログラムに関する。

【背景技術】

【0002】

複数の卸パートナサービスを組み合わせてサービスを構築、運用するために、複数サービスを連携するオーケストレータが用いられている。オーケストレータでは、新規に卸サービス（管理対象サービス）を追加する場合、及び既存サービスの仕様変更が行われる場合には、低コスト且つ短期間でＡＰＩアダプタを追加、変更することが求められる。

【0003】

非特許文献１には、利用する各種サービス毎のＡＰＩの仕様差分を吸収するＡＰＩアダプタを自動生成する技術について開示されている。また、非特許文献２には、ＡＰＩアダプタと卸サービス間の制御信号やデータ信号についての試験の一部を自動化することが開示されている。

【先行技術文献】

【非特許文献】

【0004】

【文献】武 他, “Web APIアダプタ開発容易化に関する一考察,”2017.9, 電子情報通信学会 NWS研究会

【文献】金丸翔,池谷友基,高橋謙輔,豊嶋剛,「APIアダプタのC-PlaneおよびU-Planeの包括的な試験自動化手法の提案」,信学技報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかし、ＡＰＩアダプタを生成する工程には、設計工程、実装工程、及び試験工程があり、上述した非特許文献１に開示された技術では、上記設計工程の自動化について記載されておらず、設計工程についてはユーザが手動で実施する必要がある。このため、ＡＰＩアダプタの追加、仕様変更について低コスト化及び期間の短縮化を図ることが難しいという問題があった。

【0006】

本発明は、上記事情に鑑みてなされたものであり、その目的とするところは、ＡＰＩアダプタの追加、仕様変更を低コスト且つ短期間で実施することが可能なＡＰＩアダプタ生成装置及びＡＰＩアダプタ生成方法並びにＡＰＩアダプタ生成プログラムを提供することにある。

【課題を解決するための手段】

【0007】

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

【0008】

本発明の一態様のＡＰＩアダプタ生成方法は、コンピュータが行うＡＰＩアダプタ生成方法であって、オーケストレータのデータモデルと、管理対象のＡＰＩ仕様を取得するステップと、前記オーケストレータのデータスキーマ、及び前記ＡＰＩ仕様のデータスキーマに基づいてスキーママッチングを行い、モデル変換ルールを算出するステップと、前記モデル変換ルールに基づいて、ＡＰＩアダプタ実行ロジックを記述したＡＰＩ呼出ロジック部のソースコードを書き換えるステップと、前記ソースコードが書き換えられたＡＰＩ呼出ロジック部に基づいて、前記管理対象のＡＰＩアダプタを生成するステップと、を備える。

【0009】

本発明の一態様は、上記ＡＰＩアダプタ生成装置としてコンピュータを機能させるためのＡＰＩアダプタ生成プログラムである。

【発明の効果】

【0010】

本発明によれば、ＡＰＩアダプタの追加、使用変更を低コスト且つ短期間で実施することが可能になる。

【図面の簡単な説明】

【0011】

【図1】図１は、実施形態に係るＡＰＩアダプタ生成装置が採用されるネットワークシステムの構成を示すブロック図である。

【図2】図２は、実施形態に係るＡＰＩアダプタ生成装置、及びＡＰＩアダプタの構成を示すブロック図である。

【図3】図３は、第１実施形態に係るＡＰＩアダプタ生成装置の構成を示すブロック図である。

【図4】図４は、オープンＡＰＩスペック形式で記述されたＡＰＩ仕様をＵＭＬ形式のデータモデルに変換する例を示す説明図である。

【図5A】図５Ａは、Ａ社及びＢ社による管理対象サービスのＡＰＩアダプタを生成する際の、各社のデータモデルＭ１、Ｍ２のリソース設計、パラメータ設計を示す説明図である。

【図5B】図５Ｂは、Ａ社及びＢ社による管理対象サービスのＡＰＩアダプタを生成する際の、各社のデータモデルＭ１、Ｍ２のパラメータ値の変換を示す説明図である。

【図5C】図５Ｃは、オーケストレータＡＰとオーケストレータの関係を示す説明図である。

【図6A】図６Ａは、複数のＡＰＩをまとめて管理する場合の、ＡＰＩの実行順序を示す説明図である。

【図6B】図６Ｂは、Ｃ社、Ｄ社、Ｅ社による管理対象サービスを追加する際の、各データモデルのロジック設計を示す説明図である。

【図7A】図７Ａは、データモデルＭ１のリソース及びパラメータを、オーケストレータのデータモデルＭ３のリソース及びパラメータに変換する際の対応関係を示す説明図である。

【図7B】図７Ｂは、図７Ａに示したリソース及びパラメータを記述したソースコードを示す説明図である。

【図8A】図８Ａは、データモデルＭ１のパラメータ値を、オーケストレータのデータモデルＭ３のパラメータ値に変換する際の対応関係を示す説明図である。

【図8B】図８Ｂは、図８Ａに示したパラメータ値を記述したソースコードを示す説明図である。

【図9】図９は、第１実施形態に係るＡＰＩアダプタ生成装置の処理手順を示すフローチャートである。

【図10】図１０は、第２実施形態に係るＡＰＩアダプタ生成装置の構成を示すブロック図である。

【図11】図１１は、データモデルＭ１１～Ｍ１３のリソース及びパラメータを、オーケストレータのデータモデルＭ１４のリソース及びパラメータに変換する際の対応関係を示す説明図である。

【図12】図１２は、第２実施形態に係り、変換ルールに従ってデータモデルのソースコードを生成する手順を示す説明図である。

【図13】図１３は、図１１に示したリソース及びパラメータを記述したソースコードを示す説明図である。

【図14】図１４は、第３実施形態に係るＡＰＩアダプタ生成装置の構成を示すブロック図である。

【図15A】図１５Ａは、第３実施形態に係り、オーケストレータＡＰとオーケストレータの関係を示す説明図である。

【図15B】図１５Ｂは、図１５Ａに示したリソース及びパラメータを記述したソースコードを示す説明図である。

【図15C】図１５Ｃは、図１５Ｂに示したソースコードのインスタンス情報を示す説明図である。

【図15D】図１５Ｄは、図１５Ｂに示したソースコードの構成情報を示す説明図である。

【図16A】図１６Ａは、複数のオーケストレータＡＰ２０３ａ、２０３ｂ、２０３ｃのデータモデルを示す説明図である。

【図16B】図１６Ｂは、オーケストレータＡＰの基本的なデータモデルの構成情報グラフを示す説明図である。

【図16C】図１６Ｃは、パラメータ５１、５２、５３の類似性に基づいて、コンピューティングリソース５０を生成する説明図である。

【図17】図１７は、本実施形態のハードウェア構成を示すブロック図である。

【発明を実施するための形態】

【0012】

[ネットワークシステムの構成]
以下、本発明の実施形態について説明する。図１は、実施形態に係るＡＰＩアダプタ生成装置が採用されるネットワークシステム２００の構成を示すブロック図である。初めに、図１を参照してネットワークシステム２００について説明する。

【0013】

図１に示すネットワークシステム２００において、サービスプロバイダ２０２に接続されたエンドユーザ２０１は、希望するサービスを要求すると、ネットワークまたはクラウド上に設定されている複数の卸サービス事業者２２０（２２０ａ～２２０ｄ）から提供される管理対象サービスを受け取ることができる。

【0014】

なお、本実施形態では、２つの卸サービス事業者２２０ａ、２２０ｂが既にネットワークシステム２００に存在しており、新たに２つの卸サービス事業者２２０ｃ、２２０ｄを追加する例について説明する。卸サービス事業者２２０ａ、２２０ｄは、ネットワークによる管理対象サービスを提供する。卸サービス事業者２２０ｂ、２２０ｃは、クラウドによる管理対象サービスを提供する。

【0015】

以下では、卸サービス事業者を特定して示す場合には「卸サービス事業者２２０ａ」のようにサフィックスを付して示し、特定しない場合及び総称して示す場合には「卸サービス事業者２２０」のようにサフィックスを付さずに示すことにする。他の符号についても同様とする。

【0016】

サービスプロバイダ２０２と各卸サービス事業者２２０との間には、オーケストレータ２１０、及び各卸サービス事業者２２０に対応したＡＰＩアダプタ２１１（２１１ａ～２１１ｄ）が設けられている。

【0017】

オーケストレータ２１０は、サービスプロバイダ２０２から提供されるオーケストレータＡＰ２０３を取得し、各卸サービス事業者２２０のネットワーク、及びクラウド、アプリを組み合わせたサービスを一括で連携する。

【0018】

即ち、各卸サービス事業者２２０が提供する管理対象サービスは、各卸サービス事業者２２０ごとにその仕様が異なっている。このため、サービスプロバイダ２０２が複数の管理対象サービスを組み合わせて新たなサービスを提供する場合には、上記仕様の相違を吸収し、複数の管理対象サービスを連携させる必要がある。オーケストレータ２１０は、この連携を行う。

【0019】

オーケストレータＡＰ２０３は、後述するノースバウンドＡＰＩ２０４を利用して生成されるアプリケーションである。オーケストレータＡＰ２０３は、構築設定ＡＰ及び自律運用ＡＰを含む。オーケストレータＡＰ２０３は、例えばカタログである。カタログは、複数の管理対象サービスを連携させるために必要な各管理対象サービスの仕様を記述したデータファイルである。

【0020】

サービスプロバイダ２０２と、オーケストレータ２１０との間には、ノースバウンドＡＰＩ２０４が設けられている。ノースバウンドＡＰＩ２０４は、サービスプロバイダ２０２と、オーケストレータ２１０を接続するインターフェースである。

【0021】

各卸サービス事業者２２０と、オーケストレータ２１０との間には、サウスバウンドＡＰＩ２１２が設けられている。サウスバウンドＡＰＩ２１２は、各卸サービス事業者２２０とオーケストレータ２１０を接続するインターフェースである。

【0022】

オーケストレータ２１０は、内部ＡＰＩ２１３（図２参照）を介して、各卸サービス事業者２２０に対応して設置されたＡＰＩアダプタ２１１に接続されている。ＡＰＩアダプタ２１１は、各卸サービス事業者２２０ごとに生成され、各卸サービス事業者２２０が提供するＡＰＩ仕様差分を吸収する。

【0023】

オーケストレータ２１０は、サービスプロバイダ２０２が発行したオーダを、各卸サービス事業者２２０用のＡＰＩアダプタ２１１が処理できる単位である「単体オーダ」に分解し、各卸サービス事業者２２０（２２０ａ～２２０ｄ）のＡＰＩアダプタ２１１（２１１ａ～２１１ｄ）に送信する。

【0024】

各ＡＰＩアダプタ２１１は、オーケストレータ２１０のデータモデルと、各卸サービス事業者２２０のデータモデルを相互に変換する機能を有している。

【0025】

上述したように、２つの卸サービス事業者２２０ａ、２２０ｂが既に設置されているネットワークシステム２００において、２つの卸サービス事業者２２０ｃ、２２０ｄにより提供される管理対象サービスを新たに追加する場合には、ＡＰＩアダプタ２１１ｃ、２１１ｄを生成する必要がある。即ち、図１に示すように、既存のＡＰＩアダプタ２１１ａ、２１１ｂに加えて、新規にＡＰＩアダプタ２１１ｃ、２１１ｄを生成する必要がある。

【0026】

本実施形態では、ＡＰＩアダプタ２１１ｃ、２１１ｄの生成の少なくとも一部を自動化することより、作業者の労力を軽減し且つ低コスト化を図る。以下詳細に説明する。

【0027】

図２は、図１に示したＡＰＩアダプタ２１１の詳細な構成を示すブロック図である。図２に示すように、ＡＰＩアダプタ２１１は、オーダ受付部２３１と、ＡＰＩ呼出ロジック部２３２と、サウスバウンドＡＰＩ実行部２３３を備える。ＡＰＩアダプタ２１１は、本実施形態に係るＡＰＩアダプタ生成装置１００に接続されている。

【0028】

オーダ受付部２３１は、オーケストレータ２１０に送信されるオーダＮ１を受け付け、オーダＮ１の内容を取得する。オーダ受付部２３１は、オーケストレータ２１０への応答処理を行う。具体的には、オーダ受付部２３１は、連携オーダ受付／応答処理として、オーケストレータ２１０との間で予め決められた手順に従って、オーダＮ１の受信からオーダＮ１の実行完了までの状態管理および通知、実行結果の流通を行う。

【0029】

オーダ受付部２３１は、オーダ内容の取得処理として、ＡＰＩ呼出ロジック部２３２の要請を受け、詳細なオーダ内容（カタログなど）を取得する。

【0030】

ＡＰＩ呼出ロジック部２３２は、サウスバウンドＡＰＩ２１２の起動条件をチェックし、予め設定された実行順序に従ってサウスバウンドＡＰＩ２１２を起動する。

【0031】

ＡＰＩ呼出ロジック部２３２は、オーケストレータ２１０からのオーダＮ１からサウスバウンドＡＰＩ２１２の実行に必要なパラメータを取り出し、サウスバウンドＡＰＩ実行部２３３に送信する。ＡＰＩ呼出ロジック部２３２は、サウスバウンドＡＰＩ２１２の実行結果をサウスバウンドＡＰＩ実行部２３３から取得する。ＡＰＩ呼出ロジック部２３２は、取得した前記実行結果をオーケストレータ２１０に流通するための適切なデータ形式に変換する。

【0032】

サウスバウンドＡＰＩ実行部２３３は、ＡＰＩ呼出ロジック部２３２から、サウスバウンドＡＰＩ２１２の実行に必要なデータを取得し、データ形式を変更して各卸サービス事業者２２０に送信する。

【0033】

サウスバウンドＡＰＩ実行部２３３は、各卸サービス事業者２２０からのレスポンスを受信し、適切な形式に変換してＡＰＩ呼出ロジック部２３２に返却する。

【0034】

サウスバウンドＡＰＩ実行部２３３は、各卸サービス事業者２２０との間で、各卸サービス事業者２２０のサウスバウンドＡＰＩ２１２を通して、個々のサウスバウンドＡＰＩ２１２に対応したリクエスト送信とレスポンス受信を行う。

【0035】

前述したように、図１に示したネットワークシステム２００において、新規に卸サービス事業者２２０ｃ、２２０ｄによる管理対象サービスが追加される場合には、オーケストレータ２１０に接続されるＡＰＩアダプタ２１１ｃ、２１１ｄを新規に生成する必要がある。

【0036】

本実施形態では、ＡＰＩアダプタ生成装置１００を設けることにより、ＡＰＩ呼出ロジック部２３２の設計の少なくとも一部を自動化し、ＡＰＩアダプタ２１１の生成を行う。

【0037】

ＡＰＩアダプタ２１１を生成する際には、設計、実装、試験を実施する必要がある。また、設計の工程には、「リソース設計」、「パラメータ設計」、「ロジック設計」が含まれる。実装の工程には、ＡＰＩ呼出ロジック部２３２の実装が含まれる。本実施形態では、「リソース設計」、「パラメータ設計」、「ロジック設計」の少なくとも一部を自動化する。また、ＡＰＩ呼出ロジック部２３２の実装を自動化する。

【0038】

［第１実施形態］
次に、本実施形態に係るＡＰＩアダプタ生成装置１００の具体的な構成について説明する。図３は、第１実施形態に係るＡＰＩアダプタ生成装置１００、及びその周辺機器の詳細な構成を示すブロック図である。

【0039】

図３に示すように、本実施形態に係るＡＰＩアダプタ生成装置１００は、データモデル記憶部１１と、ＡＰＩ仕様記憶部１２と、ＡＰＩスキーマ変換部１３と、スキーマ情報記憶部１４と、外部情報記憶部１５を備えている。ＡＰＩアダプタ生成装置１００は、変換ルール算出部１６と、変換ルール記憶部１７と、変換ルール可視化部１８と、呼出ロジック部生成部１９（生成部）と、ＡＰＩ実行部生成部２０と、ＡＰＩアダプタ生成部２１と、ＡＰＩアダプタ記憶部２２を備えている。ＡＰＩアダプタ生成装置１００には、確認画面３３が接続されている。

【0040】

データモデル記憶部１１は、オーケストレータ２１０から入力されるオーケストレータデータモデル３１を取得して記憶する。

【0041】

ＡＰＩ仕様記憶部１２は、管理対象となるデータモデルのサウスバウンドＡＰＩ仕様３２（管理対象モデルのＡＰＩ仕様）を取得して記憶する。

【0042】

ＡＰＩスキーマ変換部１３は、ＡＰＩ仕様記憶部１２に記憶されているサウスバウンドＡＰＩ仕様３２を、スキーマの形式に変換する。図４は、オープンＡＰＩスペック形式で記述されたＡＰＩ仕様Ｐ１をＵＭＬ（Unified Modeling Language）形式のデータモデルＰ２に変換する例を示す説明図である。図４の符号ａ１、ａ２に示すスキーマ情報を例えば「WAPIml」により、ＵＭＬなどのデータモデルＰ２に変換する。

【0043】

スキーマ情報記憶部１４は、ＡＰＩスキーマ変換部１３で変換されたスキーマ情報を記憶する。

【0044】

外部情報記憶部１５は、オントロジーなどの外部から送信された情報を記憶する。

【0045】

変換ルール算出部１６は、既存のスキーママッチングを利用してデータモデルの変換ルールを算出する。変換ルール算出部１６では、ＡＰＩアダプタ２１１を生成する際の、リソース設計、パラメータ設計、ロジック設計を行う。

【0046】

変換ルール算出部１６は、サウスバウンドＡＰＩ２１２の仕様から導出できるデータスキーマと、オーケストレータ２１０におけるデータスキーマの変換ルールを導出する部分に、スキーママッチングの技術を適用することにより、モデル変換を自動化する。以下、「リソース設計及びパラメータ設計の工程」及び「ロジック設計の工程」について具体的に説明する。

【0047】

（リソース設計及びパラメータ設計の工程）
図５Ａ、図５Ｂ、図５Ｃを参照して、リソース設計及びパラメータ設計の詳細について説明する。図５Ａは、Ａ社及びＢ社による管理対象サービスのＡＰＩアダプタを生成する際の、各社のデータモデルＭ１、Ｍ２のリソース設計、パラメータ設計を示す説明図である。図５Ｂは、Ａ社及びＢ社による管理対象サービスのＡＰＩアダプタを生成する際の、各社のデータモデルＭ１、Ｍ２のパラメータ値の変換を示す説明図である。図５Ｃは、オーケストレータＡＰとオーケストレータの関係を示す説明図である。

【0048】

リソース設計及びパラメータ設計を実施するためには、Ａ社及びＢ社が管理する管理対象サービスのデータモデルＭ１、Ｍ２と、オーケストレータ２１０のデータモデルＭ３の変換ルールを定義する必要がある。また、リソース、パラメータ単位の変換ルール、及びパラメータ値の変換ルールが必要である。

【0049】

例えば、図５Ａに示すように、Ａ社のデータモデルＭ１及びＢ社のデータモデルのリソース、及びパラメータを変換し、オーケストレータ２１０のデータモデルＭ３を生成する。具体的に、データモデルＭ１の「EC2Instance」、及びデータモデルＭ２の「Ｖirtual Machines」を、データモデルＭ３の「ＶＭ」に変換する。また、データモデルＭ１の「Instance Type」、及びデータモデルＭ２の「vmsize」を、データモデルＭ３の「hardware Spec」に変換する。

【0050】

また、図５Ｂに示すように、Ａ社のデータモデルＭ１及びＢ社のデータモデルＭ２のパラメータ値を変換し、オーケストレータ２１０のデータモデルＭ３を生成する。具体的に、オーケストレータ２１０のデータモデルＭ３を、独自に定義した「Large」、「Medium」、「Small」の３つに簡素化して設定する。データモデルＭ１のパラメータ値「m1.small」を「Small」に変換し、「a1.medium」を「Medium」に変換し、「m4.large」を「Large」に変換する。データモデルＭ２のパラメータ値「Dsv3」を「Small」に変換する。

【0051】

上記の変換ルールを設定することにより、図５Ｃに示すように、オーケストレータ２１０は、オーケストレータＡＰ２０３としてデータモデル「ＶＭ」が与えられた際に、クラウドベンダを意識することなく使用することができる。即ち、オーケストレータＡＰ２０３からは、図５Ａ、図５Ｂに示したデータモデルＭ１、及びデータモデルＭ２は同様のデータモデル「ＶＭ」として取り扱うことができる。

【0052】

具体的に、図５Ａ、図５Ｂに示したデータモデルの変換を、スキーママッチングを用いて変換する。スキーママッチングとして、例えば、「Graph-Based」手法を用いることができる。「Graph-Based」手法では、パラメータの名称のみならず、スキーマのグラフ／木構造を考慮した上でパラメータをマッチングすることが可能である。

【0053】

更に、データのスキーマのみならず、実際のデータ値（インスタンス）を使用する「Instance-based」手法や、このInstance-based」手法とスキーマ情報を合わせて使用する「Hybrid」手法を用いることも可能である。

【0054】

（ロジック設計の工程）
次に、図６Ａ、図６Ｂを参照して、ロジック設計の詳細について説明する。図６Ａは、ＡＰＩの実行順序を示す説明図である。図６Ｂは、データモデルＭ１１を有する卸サービス事業者２２０であるＣ社、データモデルＭ１２を有する卸サービス事業者２２０であるＤ社、及びデータモデルＭ１３を有する卸サービス事業者２２０であるＥ社による管理対象サービスを追加する際の、各データモデルＭ１１～Ｍ１３のロジック設計を示す説明図である。

【0055】

管理対象サービスにおける複数のリソースをまとめて一つの単位で管理する場合には、ＡＰＩの実行順序、パラメータの流通関係を定義する必要がある。例えば、図６Ａに示すように、「ＶＰＣ」→「Subnet」→「ＥＣ２」の順に、ＡＰＩの実行順序を定義する。

【0056】

また、図６Ｂに示すように、Ｃ社、Ｄ社、Ｅ社の各データモデルＭ１１～Ｍ１３において、パラメータの流通関係を、図中の矢印Ｚ１、Ｚ２のように定義する。その結果、各データモデル間における流通関係が定義されたオーケストレータ２１０のデータモデルＭ１４が生成される。

【0057】

このように、変換ルール算出部１６では、データモデルの変換ルールを算出し、ＡＰＩアダプタ２１１を生成する際の、リソース設計、パラメータ設計、ロジック設計を行う。また、後述する呼出ロジック部生成部１９では、上記リソース設計、パラメータ設計、ロジック設計の結果に基づいて、ＡＰＩ呼出ロジック部２３２を生成する。

【0058】

図３に戻って、変換ルール記憶部１７は、変換ルール算出部１６で算出されたモデル変換ルールを記憶する。

【0059】

変換ルール可視化部１８は、変換ルール記憶部１７に記憶されているモデル変換ルールを確認画面３３に出力することで、モデル変換ルールをユーザが確認できるように可視化する。例えば、モデル変換ルールのデータを確認画面３３に送信し、このデータを確認画面３３にて表示することにより、モデル変換ルールをユーザに認識させる。

【0060】

呼出ロジック部生成部１９は、変換ルール算出部１６で算出されたリソース設計、パラメータ設計、ロジック設計の結果に基づいて、ＡＰＩ呼出ロジック部２３２を自動生成する。呼出ロジック部生成部１９は、変換ルール算出部１６で算出されたモデル変換ルールに従って、テンプレートのソースコードを書き換える。

【0061】

以下、ソースコードの生成手順を図７Ａ、図７Ｂ、図８Ａ、図８Ｂを参照して説明する。図７Ａは、図５Ａに示したデータモデルＭ１のパラメータを、オーケストレータ２１０のデータモデルＭ３のパラメータに変換する際の対応関係を示す説明図、図７Ｂは、図７Ａに示すパラメータを記述したソースコードを示す説明図である。

【0062】

図７Ａに示すように、データモデルＭ１の符号ｘ１に示す「EC2Instance」を符号ｘ２に示す「ＶＭ」に変更し、符号ｘ３に示す「InstanceType」を符号ｘ４に示す「hardwareSpec」に変更する場合には、図７Ｂの符号ｙ１に示す「ec2」、符号ｙ２に示す「vm」、符号ｙ３に示す「instance type」、符号ｙ４に示す「hardwareSpec」のようにソースコードを記述する。

【0063】

即ち、予め図７Ｂに示すようなソースコードのテンプレートを用意しておき、このテンプレートに変更データを書き込むことにより、必要とするデータモデル間を変換するソースコードを生成することができる。

【0064】

図８Ａは、図５Ｂに示したデータモデルＭ１のパラメータ値を、オーケストレータ２１０のデータモデルＭ３のパラメータ値に変換する際の対応関係を示す説明図である。図８Ｂは、図８Ａに示すパラメータ値を記述したソースコードを示す説明図である。

【0065】

図８Ａに示すように、データモデルＭ１の符号ｘ１１に示す「M4.large」を、符号ｘ１２に示す「Large」に変更する場合には、図８Ｂのソースコード３０１の符号ｙ１１に示す「m4.large、符号ｙ１２に示す「large」を記述する。また、何らかの計算ロジックが必要な場合には、ソースコード３０２に示すような関数に変換する。

【0066】

図３に戻って、ＡＰＩ実行部生成部２０は、ＡＰＩ仕様記憶部１２に記憶されているサウスバウンドＡＰＩ仕様３２に基づいて、ＡＰＩアダプタ２１１におけるサウスバウンドＡＰＩ実行部２３３（図２参照）を生成する。サウスバウンドＡＰＩ実行部２３３の生成には、例えば「Swagger Codegen/Open API Generator」等の既存ツールを活用することができる。

【0067】

ＡＰＩアダプタ生成部２１は、呼出ロジック部生成部１９で生成された呼出ロジック部２３２、及びサウスバウンドＡＰＩ実行部２３３に基づいて、ＡＰＩアダプタ２１１を生成する。また、必要に応じて記憶されているＡＰＩアダプタ２１１を外部に出力する。

【0068】

ＡＰＩアダプタ記憶部２２は、ＡＰＩアダプタ生成部２１で生成されたＡＰＩアダプタ２１１を記憶する。

【0069】

［第１実施形態の動作］
次に、第１実施形態に係るＡＰＩアダプタ生成装置１００の処理手順を、図９に示すフローチャートを参照して説明する。初めに、図９のステップＳ１１において、データモデル記憶部１１は、オーケストレータ２１０から出力されるオーケストレータデータモデル３１を取得し、データモデル記憶部１１に記憶する。

【0070】

ステップＳ１２において、ＡＰＩ仕様記憶部１２は、オーケストレータ２１０から出力されるサウスバウンドＡＰＩ仕様３２を取得し、ＡＰＩ仕様記憶部１２に記憶する。

【0071】

ステップＳ１３において、ＡＰＩスキーマ変換部１３は、ＡＰＩ仕様記憶部１２に記憶されているサウスバウンドＡＰＩ仕様３２をスキーマの形式に変換する。変換後のスキーマ情報をスキーマ情報記憶部１４に記憶する。

【0072】

ステップＳ１４において、変換ルール算出部１６は、データモデル記憶部１１に記憶されているオーケストレータデータモデル３１、スキーマ情報記憶部１４に記憶されているスキーマ情報、及び外部情報記憶部１５に記憶されている外部情報に基づき、モデル変換ルールを算出する。変換ルール算出部１６は、算出したモデル変換ルールを変換ルール記憶部１７に記憶する。

【0073】

ステップＳ１５において、変換ルール可視化部１８は、必要に応じて変換ルール記憶部１７に記憶されている変換ルールを確認画面３３に出力する。操作者は、確認画面３３を見ることにより、変換ルールを認識することができる。

【0074】

ステップＳ１６において、呼出ロジック部生成部１９は、変換ルール記憶部１７に記憶されているモデル変換ルールに基づき、ＡＰＩアダプタのソースコードを書き換えて、ＡＰＩ呼出ロジック部２３２を生成する。これにより、ＡＰＩ呼出ロジック部２３２を自動生成することができる。

【0075】

ステップＳ１７において、ＡＰＩ実行部生成部２０は、ＡＰＩ仕様記憶部１２に記憶されているサウスバウンドＡＰＩアダプタの仕様に基づいて、図２に示すサウスバウンドＡＰＩ実行部２３３を生成する。

【0076】

ステップＳ１８において、ＡＰＩアダプタ生成部２１は、ＡＰＩ実行部生成部２０で生成されたサウスバウンドＡＰＩ実行部２３３、及び、呼出ロジック部生成部１９で生成されたＡＰＩ呼出ロジック部２３２に基づいて、最終的なＡＰＩアダプタ２１１を生成する。生成されたＡＰＩアダプタ２１１は、ＡＰＩアダプタ記憶部２２に記憶される。

【0077】

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

【0078】

上記の構成により、第１実施形態に係るＡＰＩアダプタ生成装置１００では、オーケストレータ２１０に対して、新規の管理対象サービスを有する卸サービス事業者２２０が追加される際に、新規にＡＰＩアダプタ２１１を設計する際の設計工程を容易に実施することが可能となる。具体的に、ＡＰＩアダプタ２１１の生成に要する労力、時間、コストを低減することが可能となる。

【0079】

第１実施形態では、呼出ロジック部生成部１９は、所定のソースコードのテンプレートを設定し、管理対象のＡＰＩ仕様のリソース、パラメータ名、パラメータ値の少なくとも一つを、テンプレートに書き込むことによりソースコードを生成し、ＡＰＩ呼出ロジック部を生成する。このため、ＡＰＩ呼出ロジック部２３２を簡単な操作で生成することが可能になる。

【0080】

［第２実施形態］
次に、本実施形態の第２実施形態について説明する。前述した第１実施形態では、新規にネットワークシステム２００に接続される管理対象サービスのデータモデルに対し、テンプレートを用いてＡＰＩアダプタ２１１を生成した。第２実施形態では、複数のサービスモデルのリソースを一つにまとめ、多対一の対応によりマッチングを行い、ＡＰＩアダプタ２１１を生成する例について説明する。

【0081】

第２実施形態では、多対一の対応によるマッチングを行う際に、リソース単位とパラメータ単位でマッチングの寄与率を可変にする。または、サウスバウンドＡＰＩのスキーマ情報から生成した依存関係グラフを利用して、確度の高い多対一のマッチングを行う。

【0082】

図１０は、第２実施形態に係るＡＰＩアダプタ生成装置１００ａの構成を示すブロック図である。図１０に示すＡＰＩアダプタ生成装置１００ａは、前述の図３に示したＡＰＩアダプタ生成装置１００と対比して、依存関係グラフ生成部２３、及び依存関係グラフ記憶部２９を備えている点で相違する。以下では、図３に示す構成要素と同一の構成要素については同一符号を付し、構成説明を省略する。

【0083】

図１０に示す依存関係グラフ生成部２３は、サウスバウンドＡＰＩ２１２のスキーマ情報から、事前にリソース間の依存関係を抽出しグラフ表現を生成する。図１１は、卸サービス事業者２２０であるＣ社、Ｄ社、Ｅ者の各データモデルＭ１１～Ｍ１３のリソース及びパラメータを、オーケストレータのデータモデルＭ１４のリソース及びパラメータに変換する際の対応関係を示す説明図である。

【0084】

依存関係グラフ生成部２３は、図１１の符号ｘ３２、ｘ３４に示すように、サウスバウンドＡＰＩ仕様３２から抽出したスキーマ情報から符号ｘ３２、ｘ３４に示すリソース間の依存関係を分析してグラフを生成する。

【0085】

依存関係グラフ記憶部２９は、依存関係グラフ生成部２３で生成された依存関係グラフを記憶する。

【0086】

変換ルール算出部１６は、前述した第１実施形態の機能に加え、事前準備として複数のリソースをまとめて一つ集約する際に、図１１に示すように、各社のデータモデルＭ１１～Ｍ１３を一つにまとめる。具体的に、複数のリソースをまとめて一つに集約する際に、推定の精度を向上させ、且つ、多対一のマッチングを可能にするため、リソース単位とパラメータ単位のマッチング寄与率を設定する。更に、該寄与率を可変にする。

【0087】

具体的に、下記の（１）式によりパラメータｉとｊがマッチングする確率「Ｍ(i,j)」を算出する。

【0088】

Ｍ(i,j)＝ｋ*Ｒ(i,j)＋（１－ｋ）*Ｐ(i,j) …（１）
（１）式において、「Ｍ(i,j)」は既存のスキーママッチングを採用したときの、パラメータｉとパラメータｊがマッチングする確率を示す。「Ｒ(i,j)」は、パラメータｉ，ｊが属するリソースどうしのマッチング確率を示す。「Ｐ(i,j)」は、パラメータのみでのマッチング確率を示す。「ｋ」は可変の数値であり「Ｒ(i,j)」の寄与率を示す。

【0089】

（１）式において、リソース単位でのマッチングとパラメータ単位でのマッチングの重みを調整可能とする。即ち、上記寄与率ｋの数値を調整可能とする。

【0090】

また、上述したサウスバウンドＡＰＩ２１２のスキーマ情報から生成した依存関係のグラフを利用して、確度の高い多対一のマッチングができるようにする。

【0091】

変換ルール算出部１６は、初めに、リソース単位でのマッチング情報の寄与率ｋを下げてマッチングを実施する。変換ルール算出部１６は、上記のマッチングが取れた場合には、パラメータが属しているリソースを確認する。依存関係グラフ上で、繋がっていればそれら全てに、多対一でマッチングしたものとする。マッチング候補のリソースが複数ある場合には、依存関係グラフ上でより近い距離でつながっている方を選択する。

【0092】

図１２は、第２実施形態に係るＡＰＩアダプタ生成装置１００ａによるコード変換処理の手順を示す説明図である。図１２に示すように、変換ルール記憶部１７に記憶されるモデル変換ルールは、前述した（１）式に示した「Ｒ(i,j)」の寄与率「ｋ」を設定し、マッチングの重みを調整できるようにする。

【0093】

図１２のＳＴ１において、依存関係グラフ生成部２３は、サウスバウンドＡＰＩ仕様３２から抽出したスキーマ情報に基づいて、複数のリソース間の依存関係を分析して依存関係グラフを生成する。

【0094】

ＳＴ２において、変換ルール算出部１６は、トポロジカルソートなどのアルゴリズムを用いて、複数のソースコードの実行順序を算出する。

【0095】

ＳＴ３において、呼出ロジック部生成部１９は、依存関係グラフ、及び（１）式に示した重み付けに基づいて、ＡＰＩアダプタ２１１のソースコードを書き換える。

【0096】

上記のように、変換ルール算出部１６は、可変寄与率「ｋ」及び依存関係グラフを活用してマッチング方式を算出している。

【0097】

次に、図１１及び図１３を参照して、具体的なソースコードの書き換えについて説明する。前述したように、図１１は、Ｃ社、Ｄ社、Ｅ社の各データモデルＭ１１～Ｍ１３のリソース及びパラメータを、オーケストレータのデータモデルＭ１４のリソース及びパラメータに変換する際の対応関係を示す説明図である。また、図１３は、図１１に示したリソース及びパラメータを記述したソースコードを示す説明図である。

【0098】

図１１に示したデータモデルＭ１１、Ｍ１２、Ｍ１３をオーケストレータ２１０のデータモデルＭ１４に変換する際に、符号ｘ３１に示す「cidrBlock」を、図１３に示すソースコードの符号ｙ３１に示す「vpc_cidrBlock」に記述する。また、図１１の符号ｘ１２に示すリソース間の依存関係を、図１３の符号ｙ３２に示す「vcp.id」に記述する。図１１の符号ｘ３３に示す「cidrBlock」を、図１３の符号ｙ３３に示す「subnet_cidrBlock」に記述する。

【0099】

図１１の符号ｘ３４に示すリソース間の依存関係を、図１３の符号ｙ３４に示す「subnet.id」に記述する。図１１の符号ｘ３５に示す「networkSegment」を、図１３の符号ｙ３５に示す「vm.networkSegment」に記述する。図１１の符号ｘ３６に示す「subnetSegment」を、図１３の符号ｙ３６に示す「vm.subnetSegment」に記述する。

【0100】

図１３に示す符号ｙ３７は、マッチングした全てのリソースの定義を示している。符号ｙ３８は、算出した実行順序で生成されたリソースを示している。

【0101】

上述のように、各データモデルＭ１～Ｍ３の重み付けを考慮して、ＡＰＩアダプタのソースコードへ落とし込むことが可能になる。

【0102】

このように、第２実施形態に係るＡＰＩアダプタ生成装置１００ａでは、複数のリソースをまとめて一つに集約する場合において、確度の高いマッチングを行うことが可能となる。

【0103】

具体的に、変換ルール算出部１６は、管理対象のＡＰＩ仕様に含まれる複数のリソースを、可変寄与率ｋ、及び依存関係グラフ情報を用いてマッチングして一つのリソースに集約する。

【0104】

変換ルール算出部１６は、リソース集約後の管理対象のＡＰＩ仕様のデータスキーマと、オーケストレータ２１０のデータスキーマに基づいてスキーママッチングを行い、ＡＰＩアダプタのモデル変換ルールを生成する。その結果、確度の高い多対一のマッチングが可能となり、新規のＡＰＩアダプタ２１１を容易に生成することが可能となる。

【0105】

[第３実施形態の説明]
次に、本実施形態の第３実施形態について説明する。オーケストレータ２１０のデータモデルの抽象度が高くなると、リソース名、パラメータ名とその構造との乖離が大きくなり、マッチングが難しくなる。既存のスキーママッチングの手法では、スキーマ情報に加えて、インスタンス情報も加味するハイブリッド手法により精度の向上が図られているが、オーケストレータ２１０に適用する場合には、インスタンス情報の取得が難しい。

【0106】

第３実施形態では、オーケストレータ２１０が有するオーケストレータＡＰ２０３に含まれるインスタンス情報、及び構成情報を活用してマッチング精度の向上を図る。

【0107】

図１４は、第３実施形態に係るＡＰＩアダプタ生成装置１００ｂの構成を示すブロック図である。図１４では、図３に示したＡＰＩアダプタ生成装置１００に対して、追加する構成要素のみを示している。即ち、第３実施形態に係るＡＰＩアダプタ生成装置１００ｂは、図３に示した各構成要素１１～２１に加えて、図１４に示す構成要素２４～２８を備えている。以下、各構成要素２４～２８について説明する。

【0108】

図１４に示すオーケストレータＡＰ収集部２４は、オーケストレータ２１０からオーケストレータＡＰ２０３を収集する。オーケストレータＡＰ２０３はノースバウンドＡＰＩ２０４を用いて生成される。オーケストレータＡＰ２０３は、例えばカタログである。

【0109】

ＡＰ情報抽出部２５は、収集したオーケストレータＡＰ２０３から、サウスバウンドＡＰＩ２１２のインスタンス情報、オーケストレータＡＰの構成情報グラフを抽出する。「構成情報グラフ」とは、後述する図１６Ｂに示すように、例えば、アプリ、コンピューティングリソース、ネットワークなどのデータ構造を示す。

【0110】

インスタンス情報記憶部２６は、ＡＰ情報抽出部２５で抽出したサウスバウンドＡＰＩ２１２のインスタンス情報を記憶する。

【0111】

構成情報グラフ記憶部２７は、ＡＰ情報抽出部２５で抽出したオーケストレータＡＰ構成情報グラフを記憶する。具体的に、図１５Ａに示すように、各オーケストレータＡＰ２０３ａ～２０３ｃに含まれるシステムの構成情報を、構成情報グラフとして記憶する。

【0112】

類似度算出部２８は、構成情報グラフ記憶部２７に記憶されている構成情報グラフに基づいて、リソース間の類似度を算出する。

【0113】

変換ルール算出部１６は、前述したオーケストレータデータモデル、スキーマ情報、外部情報に加えて、サウスバウンドＡＰＩ２１２のインスタンス情報、オーケストレータＡＰ構成情報グラフ、及びリソース間の類似度に基づいて、ソースコードの変換ルールを算出する。

【0114】

図１５Ａは、オーケストレータＡＰ２０３とオーケストレータ２１０の関係を示す説明図である。図１５Ｂは、図１５Ａに示したオーケストレータＡＰ２０３のデータモデルに含まれるリソース及びパラメータを記述したソースコードを示す説明図である。図１５Ｃは、図１５Ｂに示したソースコードのインスタンス情報を示す説明図である。図１５Ｄは、図１５Ｂに示したソースコードの構成情報を示す説明図である。

【0115】

変換ルール算出部１６は、図１５Ｂの符号ｘ２１、ｘ２２、ｘ２３に示すインスタンス情報、及び構成情報を取得し、図１５Ｃの符号ｙ２１、ｙ２２、ｙ２３に示すように、各「ｉｄ」に記述するデータを書き込む。また、図１５Ｄの符号Ｑ１に示すように、構成情報を設定する。

【0116】

また、変換ルール算出部１６は、オーケストレータＡＰ２０３に含まれるシステムの構成情報グラフの類似性を用いて、同種の概念である可能性が高いものに対して、マッチング確率が高くなるように設定する。

【0117】

図１６Ａは、複数のオーケストレータＡＰ２０３ａ、２０３ｂ、２０３ｃのデータモデルの構成情報グラフを示す説明図である。図１６Ｂは、オーケストレータＡＰ２０３の基本的なデータモデルの構成情報グラフを示す説明図である。図１６Ｃは、各オーケストレータＡＰ２０３に含まれるパラメータ５１、５２、５３の類似性に基づいて、コンピューティングリソース５０を生成する説明図である。

【0118】

類似度算出部２８は、図１６Ｂに示す「アプリ」、「コンピューティングリソース」、「ネットワーク」の構造と、図１６Ａに示す各オーケストレータＡＰ２０３ａ、２０３ｂ、２０３ｃの構成情報を対比してリソース間の類似度を算出する。

【0119】

例えば、図１６Ａに示すように、３種類のオーケストレータＡＰ２０３ａ、２０３ｂ、２０３ｃが、それぞれ「ＶＭ５１」、「コンテナ５２」、「サーバレス５３」のパラメータを有する場合には、図１６Ｃに示すように、各パラメータ５１、５２、５３の類似性に基づいて、コンピューティングリソース５０を設定する。

【0120】

具体的な算出方法として、パラメータｉとパラメータｊがマッチングする確率を「Ｍ´(i,j)」とし、下記（２）式により設定する。

【0121】

Ｍ´(i,j)＝（１-ａ）・Ｍ(i,j)＋ａ・Ｓ(i,j) …（２）
（２）式において、「Ｍ(i,j)」は既存のスキーママッチングを採用したときの、パラメータｉとパラメータｊがマッチングする確率を示す。「Ｓ(i,j)」は、構成情報グラフにおけるリソース間の類似度を加味したパラメータｉ、ｊの類似度を示す。「ａ」は、構成情報グラフの類似度の寄与率を示す。こうすることにより、複数のオーケストレータＡＰ２０３において、同種の概念である可能性の高い場合にマッチング確率が高くなるように設定できる。

【0122】

このように、第３実施形態に係るＡＰＩアダプタ生成装置１００ｂでは、上記（２）式を用いてスキーママッチングを実施することにより、複数のオーケストレータＡＰ２０３が与えられた場合において、新規のＡＰＩアダプタ２１１を簡便且つ高精度に生成することができる。

【0123】

また、第３実施形態に係るＡＰＩアダプタ生成装置１００ｂでは、オーケストレータＡＰ２０３の情報に含まれる構成情報グラフに基づいて、各オーケストレータＡＰ２０３に含まれる各リソース間の類似度を算出している。算出した類似度、及びインスタンス情報に基づいて、モデル変換ルールを生成し、ＡＰＩ呼出ロジック部２３２を生成している。その結果、新規のＡＰＩアダプタ２１１を間便且つ高精度に生成することができる。

【0124】

上記説明した各実施形態のＡＰＩアダプタ生成装置１００、１００ａ、１００ｂには、図１７に示すように例えば、ＣＰＵ（Central Processing Unit、プロセッサ）９０１と、メモリ９０２と、ストレージ９０３（HDD：HardDisk Drive、SSD：SolidState Drive）と、通信装置９０４と、入力装置９０５と、出力装置９０６とを備える汎用的なコンピュータシステムを用いることができる。メモリ９０２およびストレージ９０３は、記憶装置である。このコンピュータシステムにおいて、ＣＰＵ９０１がメモリ９０２上にロードされた所定のプログラムを実行することにより、ＡＰＩアダプタ生成装置１００、１００ａ、１００ｂの各機能が実現される。

【0125】

なお、ＡＰＩアダプタ生成装置１００、１００ａ、１００ｂは、１つのコンピュータで実装されてもよく、あるいは複数のコンピュータで実装されても良い。また、ＡＰＩアダプタ生成装置１００、１００ａ、１００ｂは、コンピュータに実装される仮想マシンであっても良い。

【0126】

なお、ＡＰＩアダプタ生成装置１００、１００ａ、１００ｂ用のプログラムは、ＨＤＤ、ＳＳＤ、ＵＳＢ（Universal Serial Bus）メモリ、ＣＤ (Compact Disc)、ＤＶＤ (Digital Versatile Disc)などのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。

【0127】

なお、本発明は上記実施形態に限定されるものではなく、その要旨の範囲内で数々の変形が可能である。

【符号の説明】

【0128】

１１ データモデル記憶部
１２ ＡＰＩ仕様記憶部
１３ ＡＰＩスキーマ変換部
１４ スキーマ情報記憶部
１５ 外部情報記憶部
１６ 変換ルール算出部
１７ 変換ルール記憶部
１８ 変換ルール可視化部
１９ 呼出ロジック部生成部（生成部）
２０ ＡＰＩ実行部生成部
２１ ＡＰＩアダプタ生成部
２２ ＡＰＩアダプタ記憶部
２３ 依存関係グラフ生成部
２４ オーケストレータＡＰ収集部
２５ ＡＰ情報抽出部
２６ インスタンス情報記憶部
２７ 構成情報グラフ記憶部
２８ 類似度算出部
２９ 依存関係グラフ記憶部
３１ オーケストレータデータモデル
３２ サウスバウンドＡＰＩ仕様
３３ 確認画面
１００、１００ａ、１００ｂ ＡＰＩアダプタ生成装置
２００ ネットワークシステム
２０１ エンドユーザ
２０２ サービスプロバイダ
２０３ オーケストレータＡＰ
２１０ オーケストレータ
２１１（２１１ａ～２１１ｄ） ＡＰＩアダプタ
２２０（２２０ａ～２２０ｄ）卸サービス事業者
２３１ オーダ受付部
２３２ ＡＰＩ呼出ロジック部
２３３ サウスバウンドＡＰＩ実行部

【図1】

【図2】

【図3】

【図4】

【図5A】

【図5B】

【図5C】

【図6A】

【図6B】

【図7A】

【図7B】

【図8A】

【図8B】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15A】

【図15B】

【図15C】

【図15D】

【図16A】

【図16B】

【図16C】

【図17】