JP2022036800A - Ａｐｉ選定システム及びａｐｉ選定方法 - Google Patents

Abstract

【課題】アプリケーション開発者が求めるＡＰＩとＡＰＩ開発者が定義したＡＰＩの対応付けを容易化する。
【解決手段】ＡＰＩ（Application Programming Interface）を選定するＡＰＩ選定システムは、ＡＰＩを該ＡＰＩが有する機能要件と対応付けて蓄積するＡＰＩリポジトリと、アプリケーション開発者が開発するアプリケーションが連携するＡＰＩに求められる機能要件及び非機能要件を定義するＡＰＩ要求定義の入力を前記アプリケーション開発者から受け付けて記憶部に保存する保存処理部と、前記保存処理部によって前記記憶部に保存された前記ＡＰＩ要求定義の機能要件と一致又は類似する機能要件を有する複数の候補ＡＰＩを前記ＡＰＩリポジトリから抽出する候補ＡＰＩ抽出処理を実行する候補ＡＰＩ抽出処理部とを有する。
【選択図】 図５

Description

本発明は、ＡＰＩ選定システム及びＡＰＩ選定方法に関する。

近年、頻繁に変化する顧客ニーズに応える迅速なアプリケーション開発が求められている。このため、短期間でサービスの改修、仕様変更、及びリリースを繰り返し、継続的にアプリケーションを改良するアプリケーション開発手法（継続的インテグレーション、継続的デリバリー）が重要とされている。

そしてアプリケーション開発において、用途や目的ごとに開発された小さなサービスを疎に結合して１つのアプリケーションを構成するマイクロサービスアーキテクチャが普及している。マイクロサービスアーキテクチャを用いたマイクロサービス開発では、サービスが提供しているＡＰＩ（Application Program Interface）を利用してサービスを呼び出すことで、サービス同士を結合し、サービスの機能を利用できる。

マイクロサービス開発においてＡＰＩが利用されことから、利用可能なＡＰＩの利用頻度と種類が増加している。マイクロサービス開発において、頻繁に行われるＡＰＩの追加や変更のサイクルに追随し、迅速かつ継続的にアプリケーションが利用するＡＰＩをより最適なものへ入れ替えることが望ましい。

このような利用可能なＡＰＩの利用頻度と種類の増加に伴い、ＡＰＩマーケットプレイスの普及が進んでいる。ＡＰＩマーケットプレイスは、ＡＰＩ開発者に便利な管理機能を提供し、ＡＰＩ利用者に多種多様なＡＰＩを提供するサービスである。ＡＰＩマーケットプレイスは、キーワード検索といった抽象的な表現を用いた検索方法によって、ユーザが求める機能や処理などを持つ可能性があるＡＰＩを抽出できる。

米国特許出願公開第２０１３／０１３２５８４号明細書

"RapidAPI"， [online]， [2020年7月2日検索]，インターネット<URL: https://rapidapi.com/>

複数のサービスＡＰＩ（アプリケーションがサービスを呼び出すために、サービスによって提供されるＡＰＩ）の組み合わせから構成されるアプリケーション（以降、ＡＰＩ連携型アプリケーション）の開発において、変化する顧客ニーズに合わせてアプリケーションを改善するためには、ＡＰＩ連携型アプリケーションに適用するＡＰＩの選定が重要となる。

そこで、ＡＰＩ連携型アプリケーションへ適用するＡＰＩの選定において、アプリケーション開発者は、ＡＰＩマーケットプレイスを活用し、ドキュメント確認、動作や性能のテスト等のＡＰＩに関するより具体的な調査を、選定した個々のＡＰＩに対して行う必要がある。

アプリケーション仕様やＡＰＩの変更や追加等の開発サイクルが迅速化する今後のＡＰＩ連携型アプリケーションの開発において、ＡＰＩ選定のために人手で行う作業の工数が膨大になることが予想される。これは、アプリケーション開発者が求めるＡＰＩについて、非機能要件やテスト要件等の様々な要求をＡＰＩ開発者が定義したＡＰＩに対応付けることが難しいためである。

本発明は上記の課題に鑑みてなされたもので、アプリケーション開発者が求めるＡＰＩとＡＰＩ開発者が定義したＡＰＩの対応付けを容易化することを目的とする。

上記目的を達成するために、本発明においては、ＡＰＩ（Application Programming Interface）を選定するＡＰＩ選定システムであって、ＡＰＩを該ＡＰＩが有する機能要件と対応付けて蓄積するＡＰＩリポジトリと、アプリケーション開発者が開発するアプリケーションが連携するＡＰＩに求められる機能要件及び非機能要件を定義するＡＰＩ要求定義の入力を前記アプリケーション開発者から受け付けて記憶部に保存する保存処理部と、前記保存処理部によって前記記憶部に保存された前記ＡＰＩ要求定義の機能要件と一致又は類似する機能要件を有する複数の候補ＡＰＩを前記ＡＰＩリポジトリから抽出する候補ＡＰＩ抽出処理を実行する候補ＡＰＩ抽出処理部とを有することを特徴とする。

本発明によれば、アプリケーション開発者が求めるＡＰＩとＡＰＩ開発者が定義したＡＰＩの対応付けを容易化できる。

本発明の実施例に係る動的ＡＰＩ選定システムの概要を説明するための図である。 マニフェストのうちのＡＰＩ要求定義の記述内容の一例を示す図である。 動的ＡＰＩ選定システムにＡＰＩを登録するためのＡＰＩ登録画面ＧＵＩの一例を示す図である。 動的ＡＰＩ選定システムに登録されているＡＰＩの設定変更及び削除を実行するためのＡＰＩ設定変更画面ＧＵＩの一例を示す図である。 本発明の実施例に係る動的ＡＰＩ選定システムの構成の一例を示すブロック図である。 アプリケーションリソースデータベースが有するＡＰＩ要求テーブルの構成の一例を示す図である。 ＡＰＩリポジトリが有するＡＰＩテーブルの構成の一例を示す図である。 アプリケーション管理ノードのマニフェスト保存処理の処理手順の一例を示すフローチャートである。 アプリケーション管理ノードのＡＰＩ選定・アプリケーションデプロイ処理の処理手順の一例を示すフローチャートである。 アプリケーション管理ノードの候補ＡＰＩ抽出処理の処理手順の一例を示すフローチャートである。 アプリケーション管理ノードのアプリケーションリソースデプロイ処理の処理手順の一例を示すフローチャートである。 アプリケーション管理ノードのアプリケーション動作テスト処理の処理手順の一例を示すフローチャートである。 アプリケーション管理ノードのアプリケーションリリーステスト処理の処理手順の一例を示すフローチャートである。 アプリケーション管理ノードのアプリケーションリソースアンデプロイ処理の処理手順の一例を示すフローチャートである。 アプリケーション管理ノードのアプリケーションリソース監視処理の処理手順の一例を示すフローチャートである。 ＡＰＩ管理ノードのＡＰＩ参照処理の処理手順の一例を示すフローチャートである。 ＡＰＩ管理ノードのＡＰＩ登録処理の処理手順の一例を示すフローチャートである。 ＡＰＩ管理ノードのＡＰＩ情報更新処理の処理手順の一例を示すフローチャートである。 ＡＰＩ管理ノードのＡＰＩ削除処理の処理手順の一例を示すフローチャートである。 ＡＰＩ管理ノードのＡＰＩリソースデプロイ処理の処理手順の一例を示すフローチャートである。 ＡＰＩ管理ノードのＡＰＩリソースアンデプロイ処理の処理手順の一例を示すフローチャートである。 ＡＰＩ選定システムを実現するコンピュータのハードウェアの一例を示す図である。

以下、本発明の実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲に係る発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。また、発明の構成に必須だが周知である構成については、図示及び説明を省略する場合がある。

以下の説明において、「ｘｘｘテーブル」といった表現により、入力に対して出力が得られる情報を説明することがあるが、この情報は、どのような構造のデータでもよい。従って、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。

また、以下の説明において、各テーブルの構成は一例であり、１つのテーブルは、２以上のテーブルに分割されてもよいし、２以上のテーブルの全部又は一部が１つのテーブルであってもよい。

また、以下の説明において、「プログラム」を主語として処理を説明する場合がある。プログラムは、プロセッサ部によって実行されることで、定められた処理を、適宜に記憶部及び／又はインターフェース部などを用いながら行うため、処理の主語が、プロセッサ部（或いは、そのプロセッサ部を有するコントローラのようなデバイス）又はｘｘｘ部とされてもよい。

プログラムは、計算機のような装置にインストールされてもよいし、例えば、プログラム配布サーバ又は計算機が読み取り可能な（例えば非一時的な）記録媒体にあってもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

また、「プロセッサ部」は、１又は複数のプロセッサである。プロセッサは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサでもよい。また、プロセッサは、シングルコアでもよいしマルチコアでもよい。また、プロセッサは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサでもよい。

また、以下の説明において、種々の対象の識別情報として、識別番号が使用されるが、識別番号以外の種類の識別情報（例えば、英字や符号を含んだ識別子）が採用されてもよい。

また、以下の説明において、同種の要素を区別しないで説明する場合には、参照符号（又は、参照符号のうちの共通符号）を使用し、同種の要素を区別して説明する場合は、要素の識別番号（又は参照符号）を使用することがある。また各図に示す各要素の数は一例であって、図示に限られるものではない。

（１）発明概要
図１は、本発明の実施例に係る動的ＡＰＩ（Application Program Interface）選定システムＳの概要を説明するための図である。動的ＡＰＩ選定システムＳは、ＡＰＩ連携型アプリケーションの開発において、アプリケーション開発者６のＡＰＩ要求に基づき動的にＡＰＩを選定する。

動的ＡＰＩ選定システムＳは、アプリケーション管理サーバ１１及びアプリケーションリソースデータベース１２を含むアプリケーション管理ノード１と、ＡＰＩ管理サーバ２１及びＡＰＩリポジトリ２２を含むＡＰＩ管理ノード２とを有する。

動的ＡＰＩ選定システムＳは、アプリケーションインスタンス３１及びＡＰＩゲートウェイ３２を含むアプリケーション実行環境３と、１以上のＡＰＩ４１を含むＡＰＩ実行環境４と連携して、アプリケーションをアプリケーション実行環境３へデプロイし、実行する。

また動的ＡＰＩ選定システムＳは、ＡＰＩ要求に基づいて、アプリケーションリソース状態の監視やＡＰＩ情報の収集を実行し動的にＡＰＩ選定を実行する。ＡＰＩ要求は、アプリケーション開発者６によってアプリケーションリソース構成定義ファイル（以降、マニフェスト７）内に記述される。マニフェスト７は、ＡＰＩに関するアプリケーションリソースの構成要求（ＡＰＩ要求定義）、及び、ＡＰＩ以外に関するアプリケーションリソースの構成要求（ＡＰＩ以外要求定義）を含むリソース定義情報が記述される。マニフェスト７の内容は、アプリケーション管理サーバ１１へ入力され、アプリケーションリソースデータベース１２に蓄積される。

ＡＰＩ情報９は、ＡＰＩ開発者８によってＡＰＩ登録画面ＧＵＩ（Graphical User Interface）９１（図３）を介してＡＰＩ管理サーバ２１に入力され、ＡＰＩリポジトリ２２に蓄積される。またＡＰＩ情報９は、ＡＰＩ開発者８によってＡＰＩ設定変更画面ＧＵＩ９２（図４）を介してＡＰＩ管理サーバ２１に入力され、動的ＡＰＩ選定システムＳ内に蓄積されているＡＰＩ設定の変更やＡＰＩ削除が行われる。

図２は、マニフェスト７のうちのＡＰＩ要求定義７１の記述内容の一例を示す図である。ＡＰＩ要求定義７１とは、ＡＰＩ連携型アプリケーション開発において、動的ＡＰＩ選定システムＳを用いる際に使用するマニフェスト７に定義されるリソース定義情報のうち、開発アプリケーションが求めるＡＰＩの要件である。ＡＰＩ要求定義７１の記述内容は、アプリケーションが呼び出すＡＰＩのエンドポイント（格納位置を示すＵＲＬ（Uniform Resource Locator）等の情報）の設定及びＡＰＩ要求等である。図２の場合、１～５行にエンドポイント設定が記述され、７～１８行にＡＰＩ要求が記述されている。

ＡＰＩ要求定義７１では、２行目のデータ項目ｋｉｎｄに記述された情報がＡＰＩの属性を表している。エンドポイント設定は、主に５行目のｔｙｐｅのデータ項目を有して構成される。ＡＰＩ要求は、主に１２行目のｒｅｐｏｓｉｔｏｒｙ、１３行目のｄｅｓｃｒｉｐｔｉｏｎ、１４行目のｉｎｐｕｔ、１５行目のｏｕｔｐｕｔ、１６行目のｓｕｃｃｅｓｓ＿ｒａｔｅ、１７行目のｌａｔｅｎｃｙ、１８行目のｒｅｌｅａｓｅの各データ項目を有して構成される。

エンドポイントのデータ項目について説明する。５行目のデータ項目ｔｙｐｅには、アプリケーションが呼び出すＡＰＩのエンドポイントの指定方法が指定される。図２の場合、ｄｙｎａｍｉｃと定義されていることから、エンドポイントはＡＰＩ要求定義７１に従って動的に指定され、動的にＡＰＩが選定されることを表している。

ＡＰＩ要求のデータ項目について説明する。１２行目のデータ項目ｒｅｐｏｓｉｔｏｒｙには、探索の対象となるＡＰＩを管理しているサーバ（ＡＰＩ管理サーバ２１）のＵＲＬが設定される。１３行のデータ項目ｄｅｓｃｒｉｐｔｉｏｎには、ＡＰＩを単語検索するために利用するキーワードが設定される。例えば、ＡＰＩが呼び出すサービスの目的に含まれていることを期待する単語や関連語が設定される。

１４行目のデータ項目ｉｎｐｕｔには、ＡＰＩに入力するデータの形式が設定される。図２の例では、入力のデータ形式は画像である。１５行目のデータ項目ｏｕｔｐｕｔには、ＡＰＩが出力するデータの形式が設定される。図２の例では、出力のデータ形式は数値である。１６行目のデータ項目ｓｕｃｃｅｓｓ＿ｒａｔｅには、ＡＰＩの処理結果に対する成功率の目標性能が設定される。１７行目のデータ項目ｌａｔｅｎｃｙには、ＡＰＩが与えられたデータに対する処理の遅延時間の目標性能値が設定される。１８行目のデータ項目ｒｅｌｅａｓｅには、ＡＰＩ連携型アプリケーションのデプロイ又はリリースに用いるアルゴリズムや処理方法が設定される。

図３は、動的ＡＰＩ選定システムＳにＡＰＩを登録するためのＡＰＩ登録画面ＧＵＩ９１の一例を示す図である。ＡＰＩ入力画面ＧＵＩ９１は、ＡＰＩ開発者８が、動的ＡＰＩ選定システムＳに、ＡＰＩ開発者８自身が開発したＡＰＩを登録するためのＧＵＩである。図３に示すように、ＡＰＩ情報９は、ＡＰＩ名９１１、ＡＰＩ説明９１２、ＡＰＩが利用される分野９１３、入力形式９１４、出力形式９１５、ＡＰＩ仕様定義ファイル９１６等の各項目の入力領域を有する。

ＡＰＩ名９１１及びＡＰＩ説明９１２は、テキストで入力される。分野９１３、入力形式９１４、及び出力形式９１５は、ドロップダウンリストからの選択によって入力される。ＡＰＩ仕様定義ファイル９１６は、ファイルのアップロードによって入力される。ＡＰＩ仕様定義ファイル９１６は、ＡＰＩ開発者８によってＳｗａｇｇｅｒファイル等で事前作成される。

ＡＰＩ入力画面ＧＵＩ９１内の「保存９１８ａ」ボタンが押下されると、ＡＰＩ入力画面ＧＵＩ９１を介して入力されたＡＰＩ情報９が動的ＡＰＩ選定システムＳに保存される。一方、画面ＧＵＩ９１内の「キャンセル９１８ｂ」ボタンが押下されると、ＡＰＩ入力画面ＧＵＩ９１を介して入力されたＡＰＩ情報９が破棄される。

図４は、動的ＡＰＩ選定システムＳに登録されているＡＰＩの設定変更及び削除を実行するためのＡＰＩ設定変更画面ＧＵＩ９２の一例を示す図である。ＡＰＩ設定変更画面ＧＵＩ９２は、ＡＰＩ開発者８が、動的ＡＰＩ選定システムＳに登録されているＡＰＩの設定変更もしくは削除を操作するためのＧＵＩである。図４に示すように、ＡＰＩ設定変更画面ＧＵＩ９２は、ＡＰＩ名９２１、ＡＰＩ説明９２２、ＡＰＩが利用される分野９２３、入力形式９２４、出力形式９２５、ＡＰＩ仕様定義ファイル９２６等の各項目の領域を有する。ＡＰＩ設定変更画面ＧＵＩ９２に表示される項目は、ＡＰＩ登録画面９１と同様である。

図４の場合、変更可能な項目は、ＡＰＩ説明９２２、分野９２３、入力形式９２４、出力形式９２５、ＡＰＩ仕様定義ファイル９２６である。ＡＰＩ説明９２２は、テキストで更新情報が入力される。分野９２３、入力形式９２４、出力形式９２５は、ドロップダウンリストから選択することによって入力される。ＡＰＩ仕様定義ファイル９２６は、ファイルのアップロードによって入力される。

ＡＰＩ仕様定義ファイル９２６は、ＡＰＩ開発者８によってＳｗａｇｇｅｒファイル等で事前に作成もしくは編集される。ＡＰＩ設定変更画面ＧＵＩ９２内の「保存９２８ａ」ボタンが押下されると、ＡＰＩ設定変更画面ＧＵＩ９２を介して入力されたＡＰＩ情報９の変更が動的ＡＰＩ選定システムＳに保存及び反映される。一方、画面ＧＵＩ９２内の「キャンセル９２８ｂ」ボタンが押下されると、ＡＰＩ設定変更画面ＧＵＩ９２を介して入力されたＡＰＩ情報９の変更が破棄される。また画面ＧＵＩ９２内の「ＡＰＩ削除９２９」ボタンが押下されると、該当のＡＰＩ情報９が動的ＡＰＩ選定システムＳから削除される。

（２）全体システム構成
図５は、本発明の実施例に係る動的ＡＰＩ選定システムの構成の一例を示すブロック図である。図５を用いて動的ＡＰＩ選定システムＳ、アプリケーション実行環境３、及びＡＰＩ実行環境４を含む全体システムＳ１の構成を説明する。図５に示すように、全体システムＳ１は、アプリケーション管理ノード１、ＡＰＩ管理ノード２、アプリケーション実行環境３、ＡＰＩ実行環境４、及びユーザ端末５が、ネットワークスイッチＮを介して接続されて構成される。

本実施例に係る動的ＡＰＩ選定システムＳ、アプリケーション実行環境３、及びＡＰＩ実行環境４は、アプリケーション管理ノード１、ＡＰＩ管理ノード２、アプリケーション実行環境３、及びＡＰＩ実行環境４を含んで構成されるが、ユーザ端末５も含む構成であってもよい。

アプリケーション管理ノード１は、アプリケーション管理サーバ１１及びアプリケーションリソースデータベース１２を有する計算機の集合である。アプリケーション管理サーバ１１は、ユーザ端末５から受け取ったマニフェスト７とアプリケーションリソースへの指示情報に基づいて、ＡＰＩ選定、アプリケーション実行環境３及びＡＰＩ実行環境４で実行するアプリケーションリソースの管理といった各処理を実行する計算機である。

アプリケーション管理サーバ１１は、マニフェスト保存処理部１１１、ＡＰＩ選定・アプリケーションデプロイ処理部１１２、候補ＡＰＩ抽出処理部１１３、アプリケーションリソースデプロイ処理部１１４、アプリケーション動作テスト処理部１１５、アプリケーションリリーステスト処理部１１６、アプリケーションリソース監視処理部１１７、アプリケーションリソースアンデプロイ処理部１１８を有する。アプリケーション管理サーバ１１のこれらの処理部の処理の具体的な説明は、図８～図１５を参照して後述する。

アプリケーションリソースデータベース１２は、リソース構成テーブル１２１及びＡＰＩ要求テーブル１２２を有する永続記憶装置である。アプリケーションリソースデータベース１２は、アプリケーション実行環境３及びＡＰＩ実行環境４で実行されるアプリケーションリソースの状態維持及び永続化のための、アプリケーションリソースの構成や設定、要求に関する情報を保持する。

アプリケーションリソースデータベース１２のリソース構成テーブル１２１の具体的な一例は、Ｋｕｂｅｒｎｅｔｅｓのｅｔｃｄであり、一貫性、高可用性を持ったキーバリューストアであって、アプリケーションリソース情報のデータストアとして利用する。アプリケーションリソースデータベース１２のＡＰＩ要求テーブル１２２の具体例は、図６に示し、具体的な説明は後述する。

ＡＰＩ管理ノード２は、ＡＰＩ管理サーバ２１及びＡＰＩリポジトリ２２を有する計算機の集合である。ＡＰＩ管理サーバ２１は、ＡＰＩ開発者８がＡＰＩリポジトリ２２に対してＡＰＩ登録、ＡＰＩ情報更新、ＡＰＩ削除を指示するためのＡＰＩ登録画面ＧＵＩ９１及びＡＰＩ設定変更画面ＧＵＩ９２の提供、ＡＰＩリポジトリ２２内のＡＰＩの管理、アプリケーション管理ノード１から受け取った指示情報に基づきＡＰＩ実行環境４で実行されるＡＰＩリソースの管理といった各処理を実行する計算機である。

ＡＰＩ管理サーバ２１は、ＡＰＩ参照処理部２１１、ＡＰＩ登録処理部２１２、ＡＰＩ情報更新処理部２１３、ＡＰＩ削除処理部２１４、ＡＰＩリソースデプロイ処理部２１５、ＡＰＩリソースアンデプロイ処理部２１６を有する。ＡＰＩ管理サーバ２１のこれらの処理部の処理の具体的な説明は、図１６～図２１を参照して後述する。

ＡＰＩリポジトリ２２は、ＡＰＩテーブル２２１を持つ永続記憶装置である。ＡＰＩテーブル２２１の具体例は、図７に示し、具体的な説明は後述する。

アプリケーション実行環境３は、本実施例におけるアプリケーションの実行環境を提供するためのプログラムが揃った環境である。アプリケーション実行環境３は、アプリケーション管理サーバ１１の指示情報に従い、処理を実行する。アプリケーション実行環境３は、アプリケーションの実体であるアプリケーションインスタンス３１、ＡＰＩゲートウェイ３２、アプリケーションを構成するコンテナの実行管理を行うコンテナ管理機能部３３、コンテナ管理機能部３３の指示に従いカーネルの機能等を用いながらコンテナの生成や直接操作等を実行するコンテナランタイム３４を有する。

ＡＰＩ実行環境４は、本実施例におけるＡＰＩ実行環境４を提供するためのプログラムが揃った環境である。ＡＰＩ実行環境４は、ＡＰＩ管理サーバ２１の指示情報に従い、ＡＰＩリソースを実行するための環境をＡＰＩ管理サーバ２１に提供する。ＡＰＩ実行環境４に、複数のＡＰＩリソース（図５ではＡＰＩ４１－１、ＡＰＩ４１－２）をデプロイすることが可能である。

ユーザ端末５は、ＡＰＩ開発者８が操作する計算機である。ユーザ端末５は、接続されている表示装置に、ＡＰＩ管理サーバ２１が提供するＡＰＩ登録画面ＧＵＩ９１及びＡＰＩ設定変更画面ＧＵＩ９２を表示させ、これらのＧＵＩを介して、ＡＰＩ情報の登録、参照、更新、削除等の操作を受け付ける。

ネットワークスイッチＮは、アプリケーション管理サーバ１１、ＡＰＩ管理サーバ２１、アプリケーション実行環境３、ＡＰＩ実行環境４、及びユーザ端末５が接続されるネットワークのスイッチである。ネットワークスイッチＮは、具体的には、例えばローカルネットワーク（例えばＬＡＮ（Local Area Network））におけるスイッチでよい。

なお図５は、アプリケーション管理サーバ１１、ＡＰＩ管理サーバ２１、アプリケーション実行環境３、ＡＰＩ実行環境４、及びユーザ端末５がそれぞれ物理的な計算機で実現される場合の各ノードの機能構成例を示したものである。しかし、これらは必ずしも全てが物理的な計算機で実現される必要はなく、少なくとも一部が仮想マシンやコンテナ等の仮想環境に置き換えて実現されてもよい。

（３）ＡＰＩ要求定義情報と登録情報
図６～図７を参照して、アプリケーションリソースデータベース１２が有するＡＰＩ要求テーブル１２２、及び、ＡＰＩリポジトリ２２が有するＡＰＩテーブル２２１とそのデータを説明する。

図６は、アプリケーションリソースデータベース１２が有するＡＰＩ要求テーブルの構成の一例を示す図である。ＡＰＩ要求テーブル１２２は、ＡＰＩ連携型アプリケーションが利用するＡＰＩの要求（ＡＰＩ要求定義情報）を管理するためのテーブルであり、アプリケーションで利用するＡＰＩ毎にエントリを有する。

図６の場合、ＡＰＩ要求テーブル１２２は、ＡＰＩ要求ＩＤ１２２１、ラベル１２２２、入力形式１２２３、出力形式１２２４、キーワード１２２５、テストデータ１２２６、成功率１２２７、遅延１２２８、リリース方式１２２９のデータ項目を有して構成される。

ＡＰＩ要求ＩＤ１２２１は、１つのＡＰＩの要求定義の識別子（レコードが登録される際に本システムが生成した識別子）である。ラベル１２２２は、該当レコードと結びついている（該当レコードのＡＰＩ要求を持つＡＰＩを呼び出している）アプリケーションリソースに付与されているラベル情報である。

入力形式１２２３は、ＡＰＩへ入力するデータのデータ形式である。出力形式１２２４は、ＡＰＩが出力するデータのデータ形式である。キーワード１２２５は、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１の説明２２１５に格納されているＡＰＩの処理内容の記述に含まれることが想定される単語のリストである。

入力形式１２２３は、マニフェスト７のデータ項目ｉｎｐｕｔ（図２の１４行目）から入力される。出力形式１２２４は、ＡＰＩ要求定義７１のデータ項目ｏｕｔｐｕｔ（図２の１５行目）から入力される。キーワード１２２５は、ＡＰＩ要求定義７１のデータ項目ｄｅｓｃｒｉｐｔｉｏｎ（図２の１３行目）から入力される。

テストデータ１２２６は、動作検証及び性能検証のためにＡＰＩに与えるテストデータのファイルが格納されているアドレスである。成功率１２２７は、動作検証及び性能検証で得た結果に対する成功率についての目標性能値である。遅延１２２８は、与えられたデータに対するＡＰＩの処理の遅延について目標性能値を格納する。リリース方式１２２９は、ＡＰＩ連携型アプリケーションのデプロイ又はリリースに用いるアルゴリズムや処理内容に関する情報である。

テストデータ１２２６は、ＡＰＩ要求定義７１のデータ項目ｒｅｐｏｓｉｔｏｒｙ（図２の１２行目）から入力される。成功率１２２７は、ＡＰＩ要求定義７１のデータ項目ｓｕｃｃｅｓｓ＿ｒａｔｅ（図２の１６行目）から入力される。遅延１２２８は、ＡＰＩ要求定義７１のデータ項目ｌａｔｅｎｃｙ（図２の１７行目）から入力される。リリース方式１２２９は、ＡＰＩ要求定義７１のデータ項目ｒｅｌｅａｓｅ（図２の１８行目）から入力される。

図６の場合、入力形式１２２３、出力形式１２２４、及びキーワード１２２５がＡＰＩの機能要件に分類され、テストデータ１２２６、成功率１２２７、遅延１２２８、及びリリース方式１２２９がＡＰＩの非機能要件に分類される。

図７は、ＡＰＩリポジトリ２２が有するＡＰＩテーブル２２１の構成の一例を示す図である。ＡＰＩテーブル２２１は、１又は複数のＡＰＩ開発者８が開発したＡＰＩを保持し、ＡＰＩ毎にエントリを有する。図７の場合、ＡＰＩテーブル２２１は、ＡＰＩ ＩＤ２２１１、ＡＰＩ名２２１２、入力形式２２１３、出力形式２２１４、及び説明２２１５のデータ項目を有して構成される。

ＡＰＩテーブル２２１の各データ項目について説明する。ＡＰＩ ＩＤ２２１１は、ＡＰＩの識別子である。ＡＰＩ名２２１２は、ＡＰＩの名前である。入力形式２２１３は、ＡＰＩに入力されるデータの要求形式である。出力形式２２１４は、ＡＰＩが出力するデータの形式である。説明２２１５は、ＡＰＩの処理内容を記述したものである。

（４）動的ＡＰＩ選定システムＳが実行する処理
本実施例に係るＡＰＩ連携型アプリケーションのための動的ＡＰＩ選定システムＳが実行する処理について説明する。なお、以降の説明では、全体システムＳ１のリソース構成が、図５に例示したリソース構成であることを想定している。

図８～図２１を用いて、アプリケーション管理ノード１のアプリケーション管理サーバ１１、及び、ＡＰＩ管理ノード２のＡＰＩ管理サーバ２１が実行する処理を説明する。

（４－１）アプリケーション管理サーバ１１の処理
図８～図１５は、アプリケーション管理ノード１のアプリケーション管理サーバ１１が主に実行する処理のフローチャートを示す。

（４－１－１）マニフェスト保存処理
図８は、アプリケーション管理ノード１のマニフェスト保存処理の処理手順の一例を示すフローチャートである。アプリケーション管理サーバ１１のマニフェスト保存処理部１１１は、入力データであるアプリケーションリソース構成定義ファイル（マニフェスト７）を受信し、データベースに保存する処理、マニフェスト７に基づいてＡＰＩを選定しアプリケーションをデプロイするＡＰＩ選定・アプリケーションデプロイ処理を呼び出す処理を実行する。

マニフェスト保存処理は、ユーザ端末５を介してマニフェスト７が入力されたことでアプリケーションリソースの作成が命令されたことを契機として実行される。

まずステップＳ１０１では、マニフェスト保存処理部１１１は、ユーザ端末５がマニフェスト保存処理の開始命令を実行したことを契機として、本処理を開始する。

次にステップＳ１０２では、マニフェスト保存処理部１１１は、ユーザ端末５を介してアプリケーション開発者６によって入力されたマニフェスト７を受け付ける。次に、ステップＳ１０３では、マニフェスト保存処理部１１１は、アプリケーションリソースデータベース１２にリソース構成の設定（リソース定義情報）を保存する。リソース定義情報は、マニフェスト７内で定義されているアプリケーションリソースに関する情報である。具体的には、マニフェスト保存処理部１１１は、マニフェスト７に定義されているリソース定義情報のうちのＡＰＩ要求定義７１をＡＰＩ要求テーブル１２２に書き込み、ＡＰＩ外要求外情報をリソース構成テーブル１２１に書き込む。

次にステップＳ１０４では、マニフェスト保存処理部１１１は、ＡＰＩ選定・アプリケーションデプロイ処理部１１２に、マニフェスト７を送信する。ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、受信したマニフェスト７に基づいてＡＰＩ選定・アプリケーションデプロイ処理を実行する。ＡＰＩ選定・アプリケーションデプロイ処理の詳細については図９を参照して後述する。ステップＳ１０５では、マニフェスト保存処理部１１１は、マニフェスト保存処理を終了する。

（４－１－２）ＡＰＩ選定・アプリケーションデプロイ処理
図９は、アプリケーション管理ノード１のＡＰＩ選定・アプリケーションデプロイ処理の処理手順の一例を示すフローチャートである。ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、入力されたマニフェスト７に基づいて、ＡＰＩの動的選定並びにアプリケーションリソース及びＡＰＩリソースのデプロイを実行する処理である。

まずステップＳ２０１では、ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、ＡＰＩ選定・アプリケーションデプロイ処理の開始命令とマニフェスト７を受信したことを契機として、本処理を開始する。

次にステップＳ２０２では、ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、候補ＡＰＩ抽出処理部１１３に、マニフェスト７内に定義されているＡＰＩ要求定義７１を送信する。候補ＡＰＩ抽出処理部１１３は、ＡＰＩ要求定義７１を受信すると、候補ＡＰＩを算出し、候補ＡＰＩリストを作成する候補ＡＰＩ抽出処理を実行する。候補ＡＰＩ抽出処理の詳細については、図１０を参照して後述する。

次にステップＳ２０３では、ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、アプリケーションリソースデプロイ処理部１１４に、マニフェスト７と、ステップＳ２０２で抽出された候補ＡＰＩリストを送信する。アプリケーションリソースデプロイ処理部１１４は、アプリケーション実行環境３にマニフェスト７の要求を満たすアプリケーションリソースをデプロイし、ＡＰＩ実行環境４に候補ＡＰＩリストに挙げられたＡＰＩリソースをデプロイするアプリケーションリソースデプロイ処理を実行する。アプリケーションリソースデプロイ処理の詳細については、図１１を参照して後述する。

次にステップＳ２０４では、ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、アプリケーション動作テスト処理部１１５に、アプリケーションリソースデプロイ処理（ステップＳ２０３）でデプロイされたアプリケーションリソースの情報、ＡＰＩリソースの情報、アプリケーション開発者６が入力したテストデータ、及び候補ＡＰＩリストを送信する。アプリケーション動作テスト処理部１１５は、候補ＡＰＩリストに挙げられたＡＰＩの動作テストを行い、正常に動作しないＡＰＩを候補ＡＰＩリストから除外することで、候補ＡＰＩリストを整理するアプリケーション動作テスト処理を実行する。アプリケーション動作テスト処理の詳細については、図１２を参照して後述する。

次にステップＳ２０５では、ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、アプリケーションリリーステスト処理部１１６に、アプリケーション動作テスト処理（ステップＳ２０４）でテストしたアプリケーションリソース及びＡＰＩリソースの情報を送信する。アプリケーションリリーステスト処理部１１６は、受信したアプリケーションリソース及びＡＰＩリソースの情報に基づく評価対象のＡＰＩへのトラフィックを徐々に増やすよう制御することで、最終的に最適なＡＰＩを一意に決定するアプリケーションリリーステスト処理を実行する。アプリケーションリリーステスト処理の詳細については、図１３を参照して後述する。アプリケーションリリーステスト処理は、アプリケーション動作テスト処理で使用された実行環境を引き続き使用して実行される。

次にステップＳ２０６では、ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、ＡＰＩリソースアンデプロイ処理部２１６に、候補ＡＰＩ抽出処理（ステップＳ２０２）で抽出された候補ＡＰＩリスト及びアプリケーションリリーステスト処理で決定された一意のＡＰＩの情報を送信する。ＡＰＩリソースアンデプロイ処理部２１６は、アプリケーションリソースデプロイ処理でＡＰＩ実行環境４にデプロイしたＡＰＩリソースのうちアプリケーションリリーステスト処理で決定された一意のＡＰＩリソース以外のＡＰＩリソースをアンデプロイするアプリケーションリソースアンデプロイ処理を実行する。ＡＰＩリソースアンデプロイ処理の詳細については、図２１を参照して後述する。

次にステップＳ２０７では、ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、ユーザ端末５に、アプリケーションリリーステスト処理（ステップＳ２０５）で算出した一意のＡＰＩの情報を送信する。ステップＳ２０８では、ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、ＡＰＩ選定・アプリケーションデプロイ処理を終了する。

（４－１－３）候補ＡＰＩ抽出処理
図１０は、アプリケーション管理ノード１の候補ＡＰＩ抽出処理の処理手順の一例を示すフローチャートである。候補ＡＰＩ抽出処理は、アプリケーション管理サーバ１１がＡＰＩ要求の情報を受信したことを契機として実行される。候補ＡＰＩ抽出処理部１１３は、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１のレコードからマニフェスト７のＡＰＩ機能要件に適合するＡＰＩを抽出する処理である。

まずステップＳ３０１では、候補ＡＰＩ抽出処理部１１３は、ＡＰＩ要求の情報を受信したことを契機として、本処理を開始する。

次にステップＳ３０２では、候補ＡＰＩ抽出処理部１１３は、ＡＰＩ管理サーバ２１にマニフェスト７のＡＰＩ要求のうち機能要件に関する情報とともにＡＰＩ参照処理の実行命令を送信する。

次にステップＳ３０３では、ＡＰＩ管理サーバ２１のＡＰＩ参照処理部２１１は、ＡＰＩ参照処理の実行命令を受信したことを契機として、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１からマニフェスト７のＡＰＩ要求に適合するＡＰＩのレコードを抽出する。具体的には、ＡＰＩ参照処理部２１１は、ＡＰＩ要求の機能要件の入力形式、出力形式、キーワードと、ＡＰＩテーブル２２１の各レコードの入力形式、出力形式、説明のそれぞれを比較し、情報が一致又は類似するレコードをＡＰＩ要求に適合しているＡＰＩ（候補ＡＰＩ）として抽出する。キーワードと説明の一致又は類似とは、説明の中にキーワードと一致する単語、又は、キーワードの類語が含まれていることをいう。ＡＰＩ管理サーバ２１は、抽出した候補ＡＰＩの情報をアプリケーション管理サーバ１１に送信する。ＡＰＩ参照処理部２１１のＡＰＩ参照処理の詳細については、図１６を参照して後述する。

次にステップＳ３０４では、候補ＡＰＩ抽出処理部１１３は、ＡＰＩ参照処理部２１１から受信した候補ＡＰＩの情報に基づいて、候補ＡＰＩリストを作成する。次にステップＳ３０５では、候補ＡＰＩ抽出処理部１１３は、候補ＡＰＩリストを出力する。ステップＳ３０６では、候補ＡＰＩ抽出処理部１１３は、候補ＡＰＩ抽出処理を終了する。

（４－１－４）アプリケーションリソースデプロイ処理
図１１は、アプリケーション管理ノード１のアプリケーションリソースデプロイ処理の処理手順の一例を示すフローチャートである。以下の処理は、アプリケーション管理サーバ１１がマニフェスト７と候補ＡＰＩリストを受信したことを契機として実行する。アプリケーションリソースデプロイ処理は、アプリケーション実行環境３もしくはＡＰＩ実行環境４に、マニフェスト７で定義されているアプリケーションリソースと候補ＡＰＩリストに挙げられているＡＰＩリソースをデプロイする処理である。

まずステップＳ４０１では、アプリケーションリソースデプロイ処理部１１４は、マニフェスト７と候補ＡＰＩリストを受信したことを契機に本処理を開始する。

次にステップＳ４０２において、アプリケーションリソースデプロイ処理部１１４は、マニフェスト７に基づいてＡＰＩ以外のアプリケーションリソースをアプリケーション実行環境３にデプロイする。

次にステップＳ４０３では、アプリケーションリソースデプロイ処理部１１４は、アプリケーション実行環境３にＡＰＩゲートウェイ３２をデプロイする。アプリケーション実行環境３にデプロイされたＡＰＩゲートウェイ３２は、アプリケーション実行環境３にデプロイされたアプリケーションリソースと、後の処理でＡＰＩ実行環境４にデプロイされるＡＰＩリソースを連携させる処理を行う計算機である。

次にステップＳ４０４では、アプリケーションリソースデプロイ処理部１１４は、ＡＰＩ管理サーバ２１に候補ＡＰＩリストとともに候補ＡＰＩリストのＡＰＩについてＡＰＩリソースデプロイ処理の実行命令を送信する。

次にステップＳ４０５では、ＡＰＩ管理サーバ２１のＡＰＩリソースデプロイ処理部２１５は、受信した候補ＡＰＩリストに基づいて、候補ＡＰＩリストで挙げられているＡＰＩをＡＰＩ実行環境４にデプロイするＡＰＩリソースデプロイ処理を実行する。ＡＰＩリソースデプロイ処理の詳細については、図２０を参照して後述する。ＡＰＩリソースデプロイ処理部２１５は、ＡＰＩリソースデプロイ処理の完了後、アプリケーションリソースデプロイ処理部１１４に、デプロイ完了情報を送信する。

次にステップＳ４０６では、アプリケーションリソースデプロイ処理部１１４は、候補ＡＰＩリストに挙げられているＡＰＩのデプロイ完了情報を受信する。次にステップＳ４０７では、アプリケーションリソースデプロイ処理部１１４は、アプリケーションリソースのデプロイ結果を出力する。ステップＳ４０８では、アプリケーションリソースデプロイ処理部１１４は、アプリケーションリソースデプロイ処理を終了する。

（４－１－５）アプリケーション動作テスト処理
図１２は、アプリケーション管理ノード１のアプリケーション動作テスト処理の処理手順の一例を示すフローチャートである。以下の処理は、アプリケーション管理サーバ１１のアプリケーション動作テスト処理部１１５が、デプロイ済みのアプリケーションリソースとＡＰＩリソースの情報、アプリケーション開発者６が入力したテストデータ、及び候補ＡＰＩリストを受信したことを契機として実行する。アプリケーション動作テスト処理は、ＡＰＩ実行環境４にデプロイされたＡＰＩがエラーなく正常に動作していることを確認するために行う検証の処理である。

まずステップＳ５０１では、アプリケーション動作テスト処理部１１５は、デプロイ済みのアプリケーションリソースとＡＰＩリソースの情報、アプリケーション開発者６が入力したテストデータ、及び候補ＡＰＩリストを受信したことを契機に、本処理を開始する。

次にステップＳ５０２では、アプリケーション動作テスト処理部１１５は、ＡＰＩゲートウェイ３２に、候補ＡＰＩリストで挙げられているＡＰＩのうちの未選択の１つのＡＰＩとアプリケーションリソースの連携命令を送信する。ＡＰＩゲートウェイ３２は、受信したＡＰＩとアプリケーションリソースの連携命令に従って連携処理を実行する。

次にステップＳ５０３では、アプリケーション動作テスト処理部１１５は、連携処理でＡＰＩと連携させたアプリケーションリソースに、テストデータを送信する。

次にステップＳ５０４では、アプリケーション動作テスト処理部１１５は、テストデータを送信したアプリケーションリソースの処理性能や処理時間等のパフォーマンスを観測し、観測値がマニフェスト７のＡＰＩ性能要件を満たしているかを確認する。ＡＰＩ性能要件とは、図６の例では、非機能要件のうちの成功率１２２７及び遅延１２２８である。アプリケーション動作テスト処理部１１５は、観測値がＡＰＩ性能要件を満たしていない場合（ステップＳ５０４ＮＯ）にステップＳ５０５へ処理を移す一方、観測値がＡＰＩ性能要件を満たしている場合（ステップＳ５０４ＹＥＳ）にはステップＳ５０６へ処理を移す。

ステップＳ５０５では、アプリケーション動作テスト処理部１１５は、ＡＰＩ性能要件を満たさないと判定されたＡＰＩのＩＤを候補ＡＰＩリストから削除する。次に、ステップＳ５０６では、アプリケーション動作テスト処理部１１５は、候補ＡＰＩリストに挙げられている全てのＡＰＩに対してステップＳ５０２～Ｓ５０５の処理を実行したかを確認する。アプリケーション動作テスト処理部１１５は、候補ＡＰＩリストに挙げられている全てのＡＰＩに対してステップＳ５０２～Ｓ５０５の処理を実行した場合（ステップＳ５０６ＹＥＳ）にステップＳ５０７へ処理を移す一方、実行していない場合（ステップＳ５０６ＮＯ）にステップＳ５０２に処理を戻す。

ステップＳ５０７では、アプリケーション動作テスト処理部１１５は、ＡＰＩ性能要件を充足しないＡＰＩが除外された候補ＡＰＩリストを出力する。次に、ステップＳ５０８では、アプリケーション動作テスト処理部１１５は、アプリケーション動作テスト処理を終了する。

（４－１－６）アプリケーションリリーステスト処理
図１３は、アプリケーション管理ノード１のアプリケーションリリーステスト処理の処理手順の一例を示すフローチャートである。アプリケーションリリーステスト処理は、アプリケーション管理サーバ１１がデプロイ済みのアプリケーションリソースとＡＰＩリソースの情報、候補ＡＰＩリストを受信したことを契機として実行される。アプリケーションリリーステスト処理は、アプリケーション動作テスト処理に引き続き、アプリケーション実行環境３にデプロイされたアプリケーション、及び、ＡＰＩ実行環境４にデプロイされたＡＰＩ性能要件を充足するＡＰＩに対して実行される。

アプリケーションリリーステスト処理部１１６は、アプリケーション実行環境３のアプリケーションリソースに接続されている複数のＡＰＩの全てに対してトラフィックを流して、ＡＰＩの性能を計測し、最良の計測値であるＡＰＩへのトラフィックが徐々に増えていくように制御することで、最終的に最良な性能を持つＡＰＩを一意に決定するために行う検証の処理である。ここで言う性能とは、開発対象のアプリケーションと連携するＡＰＩの性能を定量的に計測可能な指標である。

まずステップＳ６０１では、アプリケーション管理サーバ１１のアプリケーションリリーステスト処理部１１６は、デプロイ済みのアプリケーションリソースとＡＰＩリソースの情報、及び候補ＡＰＩリストを受信したことを契機に、本処理を開始する。

次にステップＳ６０２では、アプリケーションリリーステスト処理部１１６は、アプリケーション実行環境３のＡＰＩゲートウェイ３２に対して、ＡＰＩゲートウェイ３２を介してアプリケーションリソースと連携している全てのＡＰＩに均一量のトラフィックが流れるようにする制御命令を送信する。例えば、候補ＡＰＩリストにｎ個のＡＰＩが挙げられている場合、ｎ個の各ＡＰＩに対して均一に（１００／ｎ）％ずつのトラフィックが流れる制御が行われる。

次にステップＳ６０３では、アプリケーションリリーステスト処理部１１６は、ステップＳ６０２で均一量のトラフィックを流した各ＡＰＩの性能を計測し、計測値をメモリに保存する。

次にステップＳ６０４において、アプリケーションリリーステスト処理部１１６は、ステップＳ６０３でメモリに保存した候補ＡＰＩの性能の各計測値を比較し、性能がより高いＡＰＩに他のＡＰＩよりも多くのトラフィックが流れるようにする制御命令をＡＰＩゲートウェイ３２に送信する。例えば、候補ＡＰＩリストに挙げられているｎ個のＡＰＩうちの１つであるＡＰＩ（Ａ）の性能の計測値が最良であった場合、ＡＰＩ（Ａ）以外の（ｎ－１）個のＡＰＩに流すトラフィックをα％ずつ引き下げ、ＡＰＩ（Ａ）に流すトラフィックを（ｎ－１）×α％だけ引き上げる制御が行われる。

次にステップＳ６０５では、アプリケーションリリーステスト処理部１１６は、性能が最良なＡＰＩが一意に定まったかを確認する。ＡＰＩが一意に定まるとは、ＡＰＩゲートウェイ３２から候補ＡＰＩリストに挙げられている複数のＡＰＩのうち１つのＡＰＩに対して流されるトラフィックが、１００％になったことをいう。つまり、ＡＰＩゲートウェイ３２から１つのＡＰＩに対して１００％のトラフィックが流されるようになったことをいう。ＡＰＩが一意に定まった場合（ステップＳ６０５ＹＥＳ）にステップＳ６０６へ処理を移す一方、ＡＰＩが一意に定まっていない場合（ステップＳ６０５ＮＯ）にステップＳ６０４に処理を戻す。

次にステップＳ６０６では、アプリケーションリリーステスト処理部１１６は、ステップＳ６０５で一意に定まったとされたＡＰＩのＩＤを出力する。ステップＳ６０７では、アプリケーションリリーステスト処理部１１６は、アプリケーションリリーステスト処理を終了する。

（４－１－７）アプリケーションリソースアンデプロイ処理
図１４は、アプリケーション管理ノード１のアプリケーションリソースアンデプロイ処理の処理手順の一例を示すフローチャートである。アプリケーションリソースアンデプロイ処理は、アプリケーション管理サーバ１１がマニフェスト７又は候補ＡＰＩリストを受信したことを契機として実行される。アプリケーションリソースアンデプロイ処理は、アプリケーション実行環境３もしくはＡＰＩ実行環境４から、マニフェスト７で定義されているアプリケーションリソース又は候補ＡＰＩリストに挙げられているＡＰＩリソースをアンデプロイする処理である。

まずステップＳ７０１では、アプリケーション管理サーバ１１のアプリケーションリソースアンデプロイ処理部１１８は、マニフェスト７又はＡＰＩリストを受信したことを契機に本処理を開始する。

次にステップＳ７０２では、アプリケーションリソースアンデプロイ処理部１１８は、受信したマニフェスト７又は候補ＡＰＩリストに基づいて、ＡＰＩリソースアンデプロイ処理部２１６に対してＡＰＩリソースアンデプロイ命令を送信する。ＡＰＩリソースアンデプロイ処理部２１６は、ＡＰＩ実行環境４にデプロイされているＡＰＩをアンデプロイするＡＰＩリソースアンデプロイ処理を実行する。ＡＰＩリソースアンデプロイ処理の詳細については、図２１を参照して後述する。

次にステップＳ７０３では、アプリケーションリソースアンデプロイ処理部１１８は、ステップＳ７０１において入力されたデータがマニフェスト７であるかを確認する。アプリケーションリソースアンデプロイ処理部１１８は、入力データがマニフェスト７である場合（ステップＳ７０３ＹＥＳ）にステップＳ７０４へ処理を移す一方、入力データが候補ＡＰＩリストである場合（ステップＳ７０３ＮＯ）にステップＳ７０６に処理を移す。

次にステップＳ７０４では、アプリケーションリソースアンデプロイ処理部１１８は、アプリケーション実行環境３上のＡＰＩゲートウェイ３２をアンデプロイする。次にステップＳ７０５では、アプリケーションリソースアンデプロイ処理部１１８は、ステップＳ７０１で入力されたマニフェスト７に基づいてアプリケーション実行環境３上のアプリケーションリソースをアンデプロイする。

次にステップＳ７０６では、アプリケーションリソースアンデプロイ処理部１１８は、アンデプロイ結果をユーザ端末５に出力する。ステップＳ７０７では、アプリケーションリソースアンデプロイ処理部１１８は、アプリケーションリソースアンデプロイ処理を終了する。

（４－１－８）アプリケーションリソース監視処理
図１５は、アプリケーション管理ノード１のアプリケーションリソース監視処理の処理手順の一例を示すフローチャートである。アプリケーションリソース監視処理は、アプリケーション管理サーバ１１がアプリケーションリソース監視命令を受信したことを契機として実行される。アプリケーションリソース監視では、アプリケーションの状態、アプリケーションリソースデータベース１２、ＡＰＩリポジトリ２２の監視を行う。

アプリケーションリソース監視処理部１１７は、アプリケーションリソース監視処理を定期的（例えば１０秒に１回）に実行する。アプリケーションリソース監視処理は、下記（ａ）、（ｂ）、及び（ｃ）の条件を定期的に監視し、何れかの条件に該当することを検知したことを契機として、ＡＰＩ選定・アプリケーションデプロイ処理部１１２が、ＡＰＩ選定・アプリケーションデプロイ処理を実行するものである。
（ａ）アプリケーション実行環境３上にデプロイ済みのアプリケーションの性能の観測値が、マニフェスト７のＡＰＩ性能要件を満たさなくなったこと。
（ｂ）ＡＰＩリポジトリ２２のＡＰＩテーブル２２１において、レコードが新規登録、情報更新、又は削除されたこと（ＡＰＩの新規登録、更新、及び削除）。
（ｃ）アプリケーションリソースデータベース１２のＡＰＩ要求テーブル１２２において、レコードが新規登録、情報更新、又は削除されたこと（ＡＰＩ要求の新規登録、更新、及び削除）。

まずステップＳ８０Ｓ８０１では、アプリケーションリソース監視処理部１１７は、アプリケーションリソース監視命令を受信したことを契機に、本処理を開始する。

次にステップＳ８０２では、アプリケーションリソース監視処理部１１７は、アプリケーション実行環境３のアプリケーションリソースの動作状態等の情報を取得し、アプリケーションの状態に異常がないか、及び、アプリケーションのパフォーマンスがマニフェスト７のＡＰＩ性能要件を満たしているかを確認する。

アプリケーションリソース監視処理部１１７は、アプリケーションの状態に異常がなく、なおかつアプリケーションのパフォーマンスがマニフェスト７のＡＰＩ性能要件を満たしている場合（ステップＳ８０２ＹＥＳ）にステップＳ８０３へ処理を移す。一方、アプリケーションリソース監視処理部１１７は、アプリケーションの状態に異常がある、又は、アプリケーションのパフォーマンスがマニフェスト７のＡＰＩ性能要件を満たしていない場合（ステップＳ８０２ＮＯ）にステップＳ８０５に処理を移す。

ステップＳ８０３では、アプリケーションリソース監視処理部１１７は、ＡＰＩ管理サーバ２１を介して、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１においてレコードの追加、更新、又は削除があるかを確認する。

具体的には、アプリケーションリソース監視処理部１１７は、ＡＰＩ管理サーバ２１に、ＡＰＩリポジトリ２２の状態情報の要求命令を送信する。ＡＰＩ管理サーバ２１は、ＡＰＩリポジトリ２２の状態情報の要求命令を受信すると、ＡＰＩ参照処理部２１１を用いてＡＰＩリポジトリ２２のＡＰＩテーブル２２１においてレコードの追加、更新、又は削除がないかを確認し、アプリケーションリソース監視処理部１１７へ送信する。

アプリケーションリソース監視処理部１１７は、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１においてレコードの追加、更新、又は削除があるかの確認結果を受信し、確認結果に応じて次の処理を実行する。すなわち、アプリケーションリソース監視処理部１１７は、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１においてレコードの追加、更新、又は削除がない場合（ステップＳ８０３ＮＯ）にステップＳ８０４に処理を移す。一方、アプリケーションリソース監視処理部１１７は、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１においてレコードの追加、更新、又は削除がある場合（ステップＳ８０３ＹＥＳ）にステップＳ８０５に処理を移す。

ステップＳ８０４では、アプリケーションリソース監視処理部１１７は、アプリケーションリソースデータベース１２のリソース構成テーブル１２１及びＡＰＩ要求テーブル１２２でレコードの追加、更新、又は削除があるかを確認する。アプリケーションリソース監視処理部１１７は、アプリケーションリソースデータベース１２のリソース構成テーブル１２１及びＡＰＩ要求テーブル１２２においてレコードの追加、更新、又は削除がない場合（ステップＳ８０４ＮＯ）にステップＳ８０６へ処理を移す。一方、アプリケーションリソース監視処理部１１７は、アプリケーションリソースデータベース１２のリソース構成テーブル１２１及びＡＰＩ要求テーブル１２２においてレコードの追加、更新、又は削除がある場合（ステップＳ８０４ＹＥＳ）にステップＳ８０５に処理を移す。

ステップＳ８０５では、アプリケーションリソース監視処理部１１７は、ＡＰＩ選定・アプリケーションデプロイ処理の開始命令と、ステップＳ８０２～Ｓ８０４の何れかでＮＯと判定されたケースに該当するリソースのマニフェスト７をＡＰＩ選定・アプリケーションデプロイ処理部１１２に送信する。ＡＰＩ選定・アプリケーションデプロイ処理部１１２は、ＡＰＩ選定・アプリケーションデプロイ処理の開始命令と該当リソースのマニフェスト７を受信すると、図９を参照して説明したＡＰＩ選定・アプリケーションデプロイ処理を実行する。

ステップＳ８０５の完了後は、アプリケーションリソース監視処理部１１７は、ステップＳ８０２に処理を戻し、各ステップを繰り返し処理する。ステップＳ８０６では、アプリケーションリソース監視処理部１１７は、アプリケーションリソース監視処理を終了する。

上述のアプリケーションリソース監視処理によって、アプリケーションリソース監視処理を定期的に実施し、アプリケーションと連携させるＡＰＩを、類似性及び性能要件の充足度がより高いＡＰＩへと再選定することで、アプリケーション性能を継続的に改善する効果が期待できる。

（４－２）ＡＰＩ管理サーバ２１の処理
図１６～図２１は、ＡＰＩ管理ノード２のＡＰＩ管理サーバ２１が実行する処理のフローチャートである。

（４－２－１）ＡＰＩ参照処理
図１６は、ＡＰＩ管理ノード２のＡＰＩ参照処理の処理手順の一例を示すフローチャートである。ＡＰＩ参照処理は、図１０のステップＳ３０３の処理であり、ＡＰＩ管理サーバ２１のＡＰＩ参照処理部２１１がＡＰＩ参照要求を受信したことを契機として実行される。ＡＰＩ参照処理は、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１のレコードをＡＰＩ参照要求の送信元に提供する処理である。

まずステップＳ９０１では、ＡＰＩ管理サーバ２１のＡＰＩ参照処理部２１１は、ＡＰＩ参照要求を受信したことを契機に本処理を開始する。

次にステップＳ９０２では、ＡＰＩ参照処理部２１１は、処理の要求元より入力された参照要求の対象のＡＰＩに関する情報（ＡＰＩ関連情報）の入力を受け付ける。次にステップＳ９０３では、ＡＰＩ参照処理部２１１は、ステップＳ９０２で入力を受け付けたＡＰＩ関連情報を用いてステートメントを作成し、このステートメントを用いてＡＰＩリポジトリ２２のＡＰＩテーブル２２１から条件に合致するＡＰＩを抽出する。

次にステップＳ９０４では、ＡＰＩ参照処理部２１１は、ＡＰＩ参照の要求先に、ステップＳ９０３の処理で抽出したＡＰＩに関する情報を送信する。ステップＳ９０５では、ＡＰＩ参照処理部２１１は、ＡＰＩ参照処理を終了する。

（４－２－２）ＡＰＩ登録処理
図１７は、ＡＰＩ管理ノード２のＡＰＩ登録処理の処理手順の一例を示すフローチャートである。ＡＰＩ登録処理は、ＡＰＩ管理サーバ２１のＡＰＩ登録処理部２１２がＡＰＩ登録要求を受信したことを契機として実行される。ＡＰＩ登録処理は、ＡＰＩ登録画面ＧＵＩ９１（図３）を介して入力された情報に基づきＡＰＩリポジトリ２２のＡＰＩテーブル２２１に新規レコードを登録する処理である。

まずステップＳ１００１では、ＡＰＩ登録処理部２１２は、ＡＰＩ登録要求を受信したことを契機に本処理を開始する。次に、ステップＳ１００２では、ＡＰＩ登録処理部２１２は、要求元より入力された新規ＡＰＩのＡＰＩ情報９の入力を、ＡＰＩ登録画面ＧＵＩ９１を介して受け付ける。

次にステップＳ１００３では、ＡＰＩ登録処理部２１２は、ステップＳ１００２で入力を受け付けたＡＰＩ情報９を用いて、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１に新規レコードを追加するためのステートメントを作成する。次にステップＳ１００４では、ＡＰＩ登録処理部２１２は、ステップＳ１００３で作成されたステートメントを用いて、ＡＰＩリポジトリ２２のＡＰＩテーブル２２１に新規レコードを追加する。

次にステップＳ１００５では、ＡＰＩ登録処理部２１２は、ＡＰＩ登録処理の要求元に、ＡＰＩ登録の処理結果に関する情報を送信する。ステップＳ１００６では、ＡＰＩ登録処理部２１２は、ＡＰＩ参照処理を終了する。

（４－２－３）ＡＰＩ情報更新処理
図１８は、ＡＰＩ管理ノード２のＡＰＩ情報更新処理の処理手順の一例を示すフローチャートである。ＡＰＩ情報更新処理は、ＡＰＩ管理サーバ２１のＡＰＩ情報更新処理部２１３がＡＰＩ参照要求を受信したことを契機として実行される。ＡＰＩ情報更新処理は、ＡＰＩ設定変更画面ＧＵＩ９２（図４）を介して入力された情報に基づきＡＰＩリポジトリ２２のＡＰＩテーブル２２１に存在するレコードの情報を更新する処理である。

まずステップＳ１１０１では、ＡＰＩ情報更新処理部２１３は、ＡＰＩ参照要求を受信したことを契機としてＡＰＩ情報更新処理を開始する。

次にステップＳ１１０２では、ＡＰＩ情報更新処理部２１３は、ユーザによるユーザ端末５の操作に応じて、ＡＰＩ参照処理部２１１に対してＡＰＩ参照要求を送信してＡＰＩ参照処理（図１６）を呼び出す。そして、ＡＰＩ情報更新処理部２１３は、該当ユーザのＩＤをＡＰＩ関連情報としてＡＰＩ参照処理に入力し、該当ユーザが管理するＡＰＩの一覧情報を取得する。

次にステップＳ１１０３では、ＡＰＩ情報更新処理部２１３は、ユーザ端末５を用いた該当ユーザによる情報更新の対象となるＡＰＩの選択を受け付ける。次にステップＳ１１０４では、ＡＰＩ情報更新処理部２１３は、ステップＳ１１０３の処理により選択されたＡＰＩについて取得されたＡＰＩ情報９を用いて該当ＡＰＩのＡＰＩ詳細情報をＡＰＩ設定変更画面ＧＵＩ９２に表示する。

次にステップＳ１１０５では、ユーザ端末５は、その表示部に表示するＡＰＩ設定変更画面ＧＵＩ９２上でＡＰＩ詳細情報の変更を受け付け、ＡＰＩ詳細情報とＡＰＩ更新情報を用いて、該当ＡＰＩに関する情報更新要求を生成し、ＡＰＩ情報更新処理部２１３に送信する。

次にステップＳ１１０６では、ＡＰＩ情報更新処理部２１３は、情報更新要求を受信し、ＡＰＩ詳細情報とＡＰＩ更新情報を用いてＡＰＩ情報を更新するためのステートメントを作成する。次にステップＳ１１０７では、ＡＰＩ情報更新処理部２１３は、ステップＳ１１０６で作成されたステートメントを用いてＡＰＩリポジトリ２２のＡＰＩテーブル２２１の該当レコード情報を更新する。

次にステップＳ１１０８では、ＡＰＩ情報更新処理部２１３は、ＡＰＩ情報更新処理の要求元に、ＡＰＩ情報更新結果に関する情報を送信する。ステップＳ１１０９では、ＡＰＩ情報更新処理部２１３は、ＡＰＩ情報更新処理を終了する。

（４－２－４）ＡＰＩ削除処理
図１９は、ＡＰＩ管理ノード２のＡＰＩ削除処理の処理手順の一例を示すフローチャートである。以下の処理は、ＡＰＩ管理サーバ２１がＡＰＩ参照要求を受信したことを契機として実行される。ＡＰＩ削除処理は、ＡＰＩ設定変更画面ＧＵＩ９２（図４）を介して入力された情報に基づきＡＰＩリポジトリ２２のＡＰＩテーブル２２１に存在するレコードを削除する処理である。

まずステップＳ１２０１では、ＡＰＩ管理サーバ２１のＡＰＩ削除処理部２１４は、ＡＰＩ参照要求を受信したことを契機としてＡＰＩ削除処理を開始する。

次にステップＳ１２０２では、ＡＰＩ削除処理部２１４は、ユーザによるユーザ端末５の操作に応じて、ＡＰＩ参照処理部２１１に対してＡＰＩ参照要求を送信してＡＰＩ参照処理（図１６）を呼び出す。そして、ＡＰＩ削除処理部２１４は、該当ユーザのＩＤをＡＰＩ関連情報としてＡＰＩ参照処理に入力し、該当ユーザが管理するＡＰＩの一覧情報を取得する。

次にステップＳ１２０３では、ＡＰＩ削除処理部２１４は、ユーザ端末５を用いた該当ユーザによる削除対象のＡＰＩの選択を受け付ける。次にステップＳ１２０４では、ＡＰＩ削除処理部２１４は、ステップＳ１２０３の処理により選択されたＡＰＩについて取得されたＡＰＩ情報９を用いて該当ＡＰＩのＡＰＩ詳細情報をＡＰＩ設定変更画面ＧＵＩ９２に表示する。

次にステップＳ１２０５では、ユーザ端末５は、その表示部に表示するＡＰＩ設定変更画面ＧＵＩ９２上でＡＰＩの削除指示を受け付け、ＡＰＩ削除処理部２１４にＡＰＩの削除要求を送信する。次にステップＳ１２０６では、ＡＰＩ削除処理部２１４は、ＡＰＩの削除要求を受信し、ＡＰＩ詳細情報を用いてＡＰＩ情報を削除するためのステートメントを作成する。

次にステップＳ１２０７では、ＡＰＩ削除処理部２１４は、ステップＳ１２０６で作成されたステートメントを用いてＡＰＩリポジトリ２２のＡＰＩテーブル２２１の該当レコード情報を削除する。次にステップＳ１２０８では、ＡＰＩ削除処理部２１４は、ＡＰＩ削除処理の要求元に、ＡＰＩ削除結果に関する情報を送信する。ステップＳ１２０９では、ＡＰＩ削除処理部２１４は、ＡＰＩ削除処理を終了する。

（４－２－５）ＡＰＩリソースデプロイ処理
図２０は、ＡＰＩ管理ノード２のＡＰＩリソースデプロイ処理の処理手順の一例を示すフローチャートである。ＡＰＩリソースデプロイ処理は、ＡＰＩ管理サーバ２１がＡＰＩリソースデプロイ要求を受信したことを契機として実行する。ＡＰＩリソースデプロイ処理は、入力された情報に基づきＡＰＩリポジトリ２２のＡＰＩテーブル２２１から適切なＡＰＩを参照し、ＡＰＩ仕様定義ファイルなどのデータを含むＡＰＩに関する情報のパッケージを用いてＡＰＩリソースをＡＰＩ実行環境４へデプロイする処理である。

まずステップＳ１３０１では、ＡＰＩ管理サーバ２１のＡＰＩリソースデプロイ処理部２１５は、ＡＰＩリソースデプロイ要求を受信したことを契機としてＡＰＩリソースデプロイ処理を開始する。

次にステップＳ１３０２では、ＡＰＩリソースデプロイ処理部２１５は、ＡＰＩ参照処理部２１１に対してＡＰＩ参照要求を送信してＡＰＩ参照処理（図１６）を呼び出し、ＡＰＩリソースデプロイ要求に含まれる情報を用いてＡＰＩテーブル２２１を探索し、適切なＡＰＩのパッケージを取得する。

次にステップＳ１３０３では、ＡＰＩリソースデプロイ処理部２１５は、ステップＳ１３０２で取得されたパッケージを用いて、ＡＰＩ実行環境４にＡＰＩをデプロイする。次にステップＳ１３０４では、ＡＰＩリソースデプロイ処理部２１５は、ＡＰＩリソースデプロイ処理の要求元に、ＡＰＩリソースデプロイ結果に関する情報を送信する。ステップＳ１３０５では、ＡＰＩリソースデプロイ処理部２１５は、ＡＰＩリソースデプロイ処理を終了する。

（４－２－６）ＡＰＩリソースアンデプロイ処理
図２１は、ＡＰＩ管理ノード２のＡＰＩリソースアンデプロイ処理の処理手順の一例を示すフローチャートである。ＡＰＩリソースアンデプロイ処理は、ＡＰＩ管理サーバ２１のＡＰＩリソースアンデプロイ処理部２１６がＡＰＩリソースアンデプロイ要求を受信したことを契機として実行される。ＡＰＩリソースアンデプロイ処理は、ＡＰＩリソースアンデプロイ処理部２１６へ入力された情報に基づき、ＡＰＩ実行環境４から目的のＡＰＩリソースをアンデプロイする処理である。

まずステップＳ１４０１では、ＡＰＩリソースアンデプロイ処理部２１６は、ＡＰＩリソースアンデプロイ要求を受信したことを契機としてＡＰＩリソースアンデプロイ処理を開始する。

次にステップＳ１４０２では、ＡＰＩリソースアンデプロイ処理部２１６は、ＡＰＩリソースアンデプロイ要求に含まれる情報を用いて、ＡＰＩ実行環境４に存在する目的のＡＰＩリソースのアンデプロイを実行する。次にステップＳ１４０３では、ＡＰＩリソースアンデプロイ処理部２１６は、ＡＰＩリソースアンデプロイ処理の要求元に、ＡＰＩアンリソースデプロイ結果に関する情報を送信する。ステップＳ１４０４では、ＡＰＩリソースアンデプロイ処理部２１６は、ＡＰＩリソースアンデプロイ処理を終了する。

以上の本実施例では、ＡＰＩ連携型アプリケーションの開発において、アプリケーションから他のアプリケーション（ＡＰＩ）を呼び出すに際し、呼び出し元のアプリケーションの開発者の要求に最適なアプリケーションを選定することを支援する。このため、アプリケーション開発者が求めるＡＰＩ性能要件とＡＰＩ開発者が定義したＡＰＩの対応付けを、ＡＰＩ要求テーブル１２２の機能要件とＡＰＩテーブル２２１の記載内容とを対応付ける。

そして本実施例では、様々なＡＰＩに対して仕様確認（例えば候補ＡＰＩ抽出処理）やテスト（アプリケーション動作テストやアプリケーションリリーステスト等）を自動実行しアプリケーション開発者の要求に合致するＡＰＩを選定することで、ＡＰＩ選定を迅速化する動的ＡＰＩ選定システムを実現する。

よって本実施例によれば、ＡＰＩ要求テーブル１２２及びＡＰＩテーブル２２１の追加や更新に応じて、アプリケーションが利用するＡＰＩを動的・継続的に変更できる。これによって、迅速化するＡＰＩの新規提供や、改修、仕様変更等のサイクルに追随しながら、変化の激しい顧客要求に継続的に応えるように、アプリケーション動作テストとアプリケーションリリーステストを同一環境上でシームレスに行って最適なＡＰＩを迅速に選定する。そして、アプリケーションの開発者の負担を軽減し開発効率を向上させることができる。

図２２は、ＡＰＩ選定システムＳを実現するコンピュータのハードウェアの一例を示す図である。コンピュータ５０００では、プロセッサ５１００、メモリ５２００、ストレージ５３００、ネットワークインターフェース５４００、入力装置５５００、及び出力装置５６００が、バス５７００を介して接続されている。プロセッサ５１００は、ＣＰＵ（Central Processing Unit）等である。メモリ５２００は、ＲＡＭ（Random Access Memory）等である。ストレージ５３００は、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、媒体読取装置等である。入力装置５５００は、キーボード、マウス、タッチパネル等である。出力装置５６００は、ディスプレイ等である。

コンピュータ５０００において、ＡＰＩ選定システムＳを実現するためのプログラムがストレージ５３００から読み出されて、プロセッサ５１００及びメモリ５２００の協働により実行されることにより、ＡＰＩ選定システムＳが実現される。あるいは、ＡＰＩ選定システムＳを実現するためのプログラムは、ネットワークインターフェース５４００を介した通信により外部のコンピュータから取得されてもよい。あるいは、アプリケーション管理サーバ１１及びＡＰＩ管理サーバ２１を実現するための各プログラムは、可搬型の記録媒体（光学ディスク、半導体記憶媒体等）に記録され、媒体読取装置により読み出されて、プロセッサ５１００及びメモリ５２００の協働により実行されてもよい。

なおアプリケーション管理サーバ１１、アプリケーションリソースデータベース１２、ＡＰＩ管理サーバ２１、ＡＰＩリポジトリ２２、アプリケーション実行環境３、及びＡＰＩ実行環境４のそれぞれは、１つのコンピュータ５０００上で実現されてもよいし、各機能部が複数のコンピュータ５０００に適宜分散配置されて実現されてもよい。またアプリケーションリソースデータベース１２、ＡＰＩ管理サーバ２１、ＡＰＩリポジトリ２２、アプリケーション実行環境３、及びＡＰＩ実行環境４は、クラウドで構築されてもよいし、オンプレミスで構築されてもよい。

本発明は上述の実施形態に限定されるものではなく、様々な変形例を含む。例えば、上記した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、矛盾しない限りにおいて、ある実施形態の構成の一部を他の実施形態の構成で置き換え、ある実施形態の構成に他の実施形態の構成を加えることも可能である。また、各実施形態の構成の一部について、構成の追加、削除、置換、統合、又は分散をすることが可能である。また実施形態で示した構成及び処理は、処理効率又は実装効率に基づいて適宜分散、統合、又は入れ替えることが可能である。

Ｓ：動的ＡＰＩ選定システム、１：アプリケーション管理ノード、２：ＡＰＩ管理ノード、３：アプリケーション実行環境、４：ＡＰＩ実行環境、５：ユーザ端末、７：アプリケーションリソース構成定義ファイル（マニフェスト）、１１：アプリケーション管理サーバ、１２：アプリケーションリソースデータベース、２１：ＡＰＩ管理サーバ、２２：ＡＰＩリポジトリ、３１：アプリケーションインスタンス、３２：ＡＰＩゲートウェイ、３２：アプリケーションインスタンス、３３：コンテナ管理機能部、３４：コンテナランタイム

Claims (7)

1. ＡＰＩ（Application Programming Interface）を選定するＡＰＩ選定システムであって、
   ＡＰＩを該ＡＰＩが有する機能要件と対応付けて蓄積するＡＰＩリポジトリと、
   アプリケーション開発者が開発するアプリケーションが連携するＡＰＩに求められる機能要件及び非機能要件を定義するＡＰＩ要求定義の入力を前記アプリケーション開発者から受け付けて記憶部に保存する保存処理部と、
   前記保存処理部によって前記記憶部に保存された前記ＡＰＩ要求定義の機能要件と一致又は類似する機能要件を有する複数の候補ＡＰＩを前記ＡＰＩリポジトリから抽出する候補ＡＰＩ抽出処理を実行する候補ＡＰＩ抽出処理部と
   を有することを特徴とするＡＰＩ選定システム。
2. 前記ＡＰＩ要求定義は、
   探索対象のＡＰＩを保存する前記ＡＰＩリポジトリのアドレスと、
   前記機能要件として、ＡＰＩのデータの入出力形式及び該ＡＰＩの探索のためのキーワードと、
   前記非機能要件として、ＡＰＩの性能要件及びリリース方式と
   が記述されており、
   前記候補ＡＰＩ抽出処理部は、前記候補ＡＰＩ抽出処理において、
   前記アドレスの前記ＡＰＩリポジトリに保存されているＡＰＩのなかから、前記ＡＰＩ要求定義に記述されている入出力形式及びキーワードと一致又は類似する入出力形式及び単語が対応付けられているＡＰＩを抽出する
   ことを特徴とする請求項１に記載のＡＰＩ選定システム。
3. 前記アプリケーション、ＡＰＩゲートウェイ、及び前記複数の候補ＡＰＩを実行環境にデプロイするデプロイ処理を実行するアプリケーションデプロイ処理部と、
   前記ＡＰＩゲートウェイを介して前記アプリケーションと前記候補ＡＰＩを連携してアプリケーションの動作テストを行い、ＡＰＩを連携した前記アプリケーションの性能の観測値が前記性能要件を充足するかを判定し、前記性能要件を充足しないと判定されたＡＰＩを前記候補ＡＰＩから除外する動作テスト処理を実行するアプリケーション動作テスト処理部と
   を有することを特徴とする請求項２に記載のＡＰＩ選定システム。
4. 前記アプリケーション動作テスト処理部によって前記性能要件を充足しないと判定されたＡＰＩが除外された前記候補ＡＰＩに含まれる全てのＡＰＩにトラフィックを流してＡＰＩの性能を計測し、最良の計測値である一意のＡＰＩを決定するリリーステスト処理を行うアプリケーションリリーステスト処理部
   を有することを特徴とする請求項３に記載のＡＰＩ選定システム。
5. 前記アプリケーションリリーステスト処理部は、
   前記リリーステスト処理を、前記動作テスト処理に引き続き、前記実行環境にデプロイされた前記アプリケーション及びＡＰＩに対して実行することを特徴とする請求項４に記載のＡＰＩ選定システム。
6. 下記（ａ）、（ｂ）、及び（ｃ）を定期的に監視するアプリケーションリソース監視処理部を有し、
   前記アプリケーションリソース監視処理部によって下記（ａ）、（ｂ）、及び（ｃ）の何れかの条件に該当することが検知されたことを契機として、前記候補ＡＰＩ抽出処理、前記デプロイ処理、前記動作テスト処理、及び、前記リリーステスト処理を再実行することを特徴とする請求項４に記載のＡＰＩ選定システム。
   （ａ）前記実行環境にデプロイ済みの前記アプリケーションの性能の観測値が、前記性能要件を満たさなくなったこと。
   （ｂ）前記ＡＰＩリポジトリにおいて、ＡＰＩが新規登録、情報更新、又は削除されたこと。
   （ｃ）前記記憶部において、前記ＡＰＩ要求定義が新規登録、情報更新、又は削除されたこと。
7. ＡＰＩ（Application Programming Interface）を選定するＡＰＩ選定システムが実行するＡＰＩ選定方法であって、
   前記ＡＰＩ選定システムが、
   アプリケーション開発者が開発するアプリケーションが連携するＡＰＩに求められる機能要件及び非機能要件を定義するＡＰＩ要求定義の入力を前記アプリケーション開発者から受け付けて記憶部に保存する保存処理ステップと、
   前記保存処理ステップによって前記記憶部に保存された前記ＡＰＩ要求定義の機能要件と一致又は類似する機能要件を有する複数の候補ＡＰＩを。ＡＰＩを該ＡＰＩが有する機能要件と対応付けて蓄積するＡＰＩリポジトリから抽出する候補ＡＰＩ抽出処理を実行する候補ＡＰＩ抽出処理ステップと
   を有することを特徴とするＡＰＩ選定方法。
   

Images