JP7201087B2 - Ａｐｉ変換装置、ａｐｉ変換方法、およびプログラム - Google Patents
Ａｐｉ変換装置、ａｐｉ変換方法、およびプログラム Download PDFInfo
- Publication number
- JP7201087B2 JP7201087B2 JP2021528608A JP2021528608A JP7201087B2 JP 7201087 B2 JP7201087 B2 JP 7201087B2 JP 2021528608 A JP2021528608 A JP 2021528608A JP 2021528608 A JP2021528608 A JP 2021528608A JP 7201087 B2 JP7201087 B2 JP 7201087B2
- Authority
- JP
- Japan
- Prior art keywords
- api
- conversion
- version number
- definition
- api conversion
- Prior art date
- Legal status (The legal status 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 status listed.)
- Active
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/547—Remote procedure calls [RPC]; Web services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Description
本発明は、ＡＰＩ変換装置、ＡＰＩ変換方法、およびプログラムに関する。
各事業者がサービスを管理するためのＡＰＩ（Application Program Interface）をウェブ上にて提供しており、ＡＰＩを利用するサーバはＡＰＩを呼び出すソフトウェアを通じてサービスを構築・運用している。ＡＰＩの仕様（ＡＰＩの名称、ＵＲＬ（Uniform Resource Locator）、パラメータ等）は、各事業者が規定しており、サーバは当該規定に従ってＡＰＩを使用する。
プライベートクラウドや実験環境では、OpenStack（登録商標）のように半年毎に新版がリリースされる。このようなサーバ基盤ソフトウェアを施策毎に構築する場合、複数の版数が混在しやすく、版数毎にＡＰＩのバージョンが異なる可能性がある。
図１２は、同種ＡＰＩに複数の版数が混在するネットワークシステムの概略図である。図１２は、アクセストークン取得ＡＰＩの場合を例に採る。
図１２に示すように、ネットワークシステムは、ＶＮＦＭ（VNF Manager）やＯＳＳ（Operation Support System）を用いて、ＡＰＩサービスを提供するサービス提供システム１０サービス提供システム１０と、サービス提供システム１０により提供されたＡＰＩサービスを利用するサーバ３１～３３と、が含まれる。サーバ３１～３３は、OpenStack APIと、その認証手段（OpenStack Identity）であるkeystoneを用いて、認証、ポリシー管理、およびカタログ・サービス関連の機能を実行する。サーバ３１～３３は、同種ＡＰＩの複数の版数を持ち、順に、OpenStack Liberty版、OpenStack Newton版、OpenStack Rocky版であるとする。
図１２に示すように、ネットワークシステムは、ＶＮＦＭ（VNF Manager）やＯＳＳ（Operation Support System）を用いて、ＡＰＩサービスを提供するサービス提供システム１０サービス提供システム１０と、サービス提供システム１０により提供されたＡＰＩサービスを利用するサーバ３１～３３と、が含まれる。サーバ３１～３３は、OpenStack APIと、その認証手段（OpenStack Identity）であるkeystoneを用いて、認証、ポリシー管理、およびカタログ・サービス関連の機能を実行する。サーバ３１～３３は、同種ＡＰＩの複数の版数を持ち、順に、OpenStack Liberty版、OpenStack Newton版、OpenStack Rocky版であるとする。
サービス提供システム１０は、ＶＮＦＭ（VNF Manager）やＯＳＳ（Operation Support System）を用いて、プライベートクラウドや実験環境を管理する。保守運用者１０ａは、ＡＰＩバージョンの違いを管理するためクライアントライブラリ（ここでは、ＡＰＩｖ２ライブラリ１１、ＡＰＩｖ３ライブラリ１２、ＡＰＩｖ４ライブラリ１３）を有する。
図１２に示すように、サービス提供システム１０は、ＡＰＩｖ２ライブラリ１１を用いて、OpenStack Liberty版を有するサーバ３１に対しIdentity ＡＰＩ ｖ２ アクセストークン取得を発行し（Ｓ１ａ参照）、サーバ３１はそのアクセストークンを送信する（Ｓ２ａ参照）。同様に、サービス提供システム１０は、ＡＰＩｖ３ライブラリ１２を用いて、OpenStack Newton版を有するサーバ３２に対しIdentity ＡＰＩ ｖ３ アクセストークン取得を発行し（Ｓ１ｂ参照）、サーバ３２はそのアクセストークンを送信する（Ｓ２ｂ参照）。また、サービス提供システム１０は、ＡＰＩｖ４ライブラリ１３を用いて、OpenStack Rocky版を有するサーバ３３に対しIdentity ＡＰＩ ｖ４ アクセストークン取得を発行し（Ｓ１ｃ参照）、サーバ３３はそのアクセストークンを送信する（Ｓ２ｃ参照）。
「クロスクラウドＡＰＩ管理プラットフォーム」，2018 Gartner Magic Quadrant，コネクテッドエクスペリエンス,［online］,［令和１年６月１日検索］,インターネット 〈URL: https://cloud.google.com/apigee/〉
「CA API Gatewayバックエンド・アプリケーション、ネットワーク・システム、インフラストラクチャのＡＰＩを介した公開、保護、管理」，［online］,［令和１年６月１日検索］,インターネット 〈URL: https://www.ca.com/jp/products/ca-api-gateway.html〉
上述したように、プライベートクラウドや実験環境では、OpenStackのように約半年毎に新版がリリースされる。サーバ基盤ソフトウェアを施策毎に構築する場合、複数の版数が混在しやすく、版数毎にＡＰＩのバージョンが異なる可能性がある。
上記環境をＶＮＦＭやＯＳＳを用いて統合的に管理する場合、ＡＰＩバージョンの違いをクライアントライブラリ（図１２のＡＰＩｖ２ライブラリ１１、ＡＰＩｖ３ライブラリ１２、ＡＰＩｖ４ライブラリ１３参照）等を用いて吸収しなければならず、管理コストの増大につながる。
上記環境をＶＮＦＭやＯＳＳを用いて統合的に管理する場合、ＡＰＩバージョンの違いをクライアントライブラリ（図１２のＡＰＩｖ２ライブラリ１１、ＡＰＩｖ３ライブラリ１２、ＡＰＩｖ４ライブラリ１３参照）等を用いて吸収しなければならず、管理コストの増大につながる。
また、ＡＰＩ-ＧＷ（API Gateway）には、ＡＰＩ変換機能を備えるものがある（非特許文献１，非特許文献２参照）。このＡＰＩ-ＧＷは、ＡＰＩ変換機能として、ＡＰＩ変換プログラムを実装することで、上記クライアントライブラリによる対応は不要となる。しかしながら、ＡＰＩ変換プログラムの開発が必要であり、管理コストは低減されない。
このような背景に鑑みて本発明がなされたのであり、本発明は、管理対象システムのＡＰＩの版数の違いを低コストに隠蔽し、サービス提供システムの管理コストを低減することができるＡＰＩ変換装置、ＡＰＩ変換方法、およびプログラムを提供することを課題とする。
前記した課題を解決するため、本発明は、サービス提供システムが提供するＡＰＩを記述する定義書であるＡＰＩ定義、およびＡＰＩ変換機能のためのＡＰＩ変換プログラムを格納する記憶部にアクセスするアクセス部と、ＡＰＩを用いて制御可能な複数の制御対象サーバからなる管理対象システムのＡＰＩの版数保持していない場合、前記管理対象システムからＡＰＩの版数を取得するとともに、前記サービス提供システムのＡＰＩの版数と前記管理対象システムのＡＰＩの版数とが異なる場合、ＡＰＩ変換を指示するＡＰＩ版数管理部と、前記ＡＰＩ版数管理部からのＡＰＩ変換指示を受けて、前記アクセス部により前記ＡＰＩ定義、および前記ＡＰＩ変換プログラムを取得して、受信したＡＰＩを新版数に変換し、前記ＡＰＩ変換プログラムが取得できなかった場合、取得した新旧の版数の前記ＡＰＩ定義の差分を抽出し、新版数の前記ＡＰＩ定義に新規パラメータが存在する場合、前記サービス提供システムに不足情報を要求するとともに、前記サービス提供システムから取得した前記不足情報と、前記記憶部から取得した新旧の版数の前記ＡＰＩ定義とに基づいて、新版数の前記ＡＰＩ変換プログラムを生成し、前記ＡＰＩ定義、および前記ＡＰＩ変換プログラムに基づいて、受信したＡＰＩを新版数に変換するＡＰＩ変換部と、を備えることを特徴とするＡＰＩ変換装置とした。
本発明によれば、管理対象システムのＡＰＩの版数の違いを低コストに隠蔽し、サービス提供システムの管理コストを低減することができるＡＰＩ変換装置、ＡＰＩ変換方法、およびプログラムを提供することができる。
以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）におけるＡＰＩ変換装置およびＡＰＩ変換方法について説明する。
（実施形態）
図１は、本発明の実施形態に係るＡＰＩ変換装置１００が適用されるネットワークシステムの全体構成図である。
図１に示すように、ネットワークシステムは、ＶＮＦＭやＯＳＳを用いて、ＡＰＩサービスを提供するサービス提供システム１０と、ＡＰＩを用いて制御可能な複数のサーバ３１～３３（制御対象サーバ）と、が含まれる。サービス提供システム１０は、ＡＰＩの管理主体であり、保守運用者１０ａによって運用される。
（実施形態）
図１は、本発明の実施形態に係るＡＰＩ変換装置１００が適用されるネットワークシステムの全体構成図である。
図１に示すように、ネットワークシステムは、ＶＮＦＭやＯＳＳを用いて、ＡＰＩサービスを提供するサービス提供システム１０と、ＡＰＩを用いて制御可能な複数のサーバ３１～３３（制御対象サーバ）と、が含まれる。サービス提供システム１０は、ＡＰＩの管理主体であり、保守運用者１０ａによって運用される。
サーバ３１～３３は、OpenStack APIと、その認証手段（OpenStack Identity）であるkeystoneを用いて、認証、ポリシー管理、およびカタログ・サービス関連の機能を実行する。サーバ３１～３３は、同種ＡＰＩの複数の版数を有し、ここでは、サーバ３１～３３は、OpenStack Liberty版サーバ、OpenStack Newton版サーバ、OpenStack Rocky版サーバであるとする。
ＡＰＩ変換装置１００は、上記サービス提供システム１０と、管理対象システム３０と、の間に設けられる。一例として、ＡＰＩ変換装置１００は、サーバ３１～３３のＡＰＩ-ＧＷに設置される。この場合、ＡＰＩ変換装置１００は、このＡＰＩ-ＧＷのＡＰＩ変換機能部として導入されるものであってもよい。
ＡＰＩ変換装置１００は、ＡＰＩ変換ＤＢ（database）２０（記憶部）を参照して管理対象システム３０のＡＰＩの版数に応じたＡＰＩ変換を行う（後記）。ＡＰＩ変換ＤＢ２０は、ＡＰＩを記述する定義書であるＡＰＩ定義２１～２３、およびＡＰＩ変換機能のためのＡＰＩ変換プログラム２４を保持する（後記）。
［ＡＰＩ変換装置１００］
図１に示すように、ＡＰＩ変換装置１００は、外部システムＩＦ（interface）部１１０、ＡＰＩ版数管理部１２０、管理対象システムＩＦ部１３０、ＡＰＩ変換部１４０、ＡＰＩ変換ＤＢアクセス部１５０（アクセス部）を備えて構成される。
図１に示すように、ＡＰＩ変換装置１００は、外部システムＩＦ（interface）部１１０、ＡＰＩ版数管理部１２０、管理対象システムＩＦ部１３０、ＡＰＩ変換部１４０、ＡＰＩ変換ＤＢアクセス部１５０（アクセス部）を備えて構成される。
<外部システムＩＦ部１１０>
外部システムＩＦ部１１０は、ＡＰＩを受信するとＡＰＩ版数管理部１２０に通知する。また、外部システムＩＦ部１１０は、取得した不足情報（該当パラメータの値）をＡＰＩ変換部１４０に通知する。
外部システムＩＦ部１１０は、ＡＰＩを受信するとＡＰＩ版数管理部１２０に通知する。また、外部システムＩＦ部１１０は、取得した不足情報（該当パラメータの値）をＡＰＩ変換部１４０に通知する。
<ＡＰＩ版数管理部１２０>
ＡＰＩ版数管理部１２０は、同種ＡＰＩの複数の版数を管理する。ＡＰＩ版数管理部１２０は、管理対象システム３０のＡＰＩの版数を保持しているか確認し、保持していない場合、管理対象システム３０からＡＰＩの版数を取得するとともに、サービス提供システム１０から受信したＡＰＩの版数（ｖ２）と管理対象システム３０のＡＰＩの版数（ｖ３）とを比較し、ＡＰＩの版数が異なる場合、ＡＰＩ変換部１４０にＡＰＩ変換を指示する。
具体的には、ＡＰＩ版数管理部１２０は、下記（１）～（３）のＡＰＩ版数管理を行う。
ＡＰＩ版数管理部１２０は、同種ＡＰＩの複数の版数を管理する。ＡＰＩ版数管理部１２０は、管理対象システム３０のＡＰＩの版数を保持しているか確認し、保持していない場合、管理対象システム３０からＡＰＩの版数を取得するとともに、サービス提供システム１０から受信したＡＰＩの版数（ｖ２）と管理対象システム３０のＡＰＩの版数（ｖ３）とを比較し、ＡＰＩの版数が異なる場合、ＡＰＩ変換部１４０にＡＰＩ変換を指示する。
具体的には、ＡＰＩ版数管理部１２０は、下記（１）～（３）のＡＰＩ版数管理を行う。
（１） ＡＰＩ版数管理部１２０は、ＡＰＩの管理対象システム３０のＡＰＩの版数を保持しているか確認する。ＡＰＩの版数を保持していない場合、管理対象システムＩＦ部１３０にＡＰＩの版数の取得を指示する。ここでは、ＡＰＩ版数管理部１２０は、管理対象システムＩＦ部１３０にアクセストークン取得ＡＰＩ（ｖ３）送信を指示する。
（２） ＡＰＩ版数管理部１２０は、受信したＡＰＩ版数（ｖ２）と対象システムのＡＰＩの版数（ｖ３）を比較し、ＡＰＩの版数が異なる場合、ＡＰＩ変換部１４０にＡＰＩ変換を指示する。
また、ＡＰＩ版数管理部１２０は、ＡＰＩの管理対象システム３０のＡＰＩの版数を保持しているか確認する。ＡＰＩの版数を保持している場合、受信したＡＰＩの版数（ｖ２）と管理対象システム３０のＡＰＩの版数（ｖ３）とを比較し、両者のＡＰＩの版数が異なる場合、ＡＰＩ変換部１４０にＡＰＩ変換を指示する。
また、ＡＰＩ版数管理部１２０は、ＡＰＩの管理対象システム３０のＡＰＩの版数を保持しているか確認する。ＡＰＩの版数を保持している場合、受信したＡＰＩの版数（ｖ２）と管理対象システム３０のＡＰＩの版数（ｖ３）とを比較し、両者のＡＰＩの版数が異なる場合、ＡＰＩ変換部１４０にＡＰＩ変換を指示する。
（３） ＡＰＩ版数管理部１２０は、外部システムＩＦ部１１０を介して、サービス提供システム１０からのアクセストークン取得に対するアクセストークンの返送を指示する。
<管理対象システムＩＦ部１３０>
管理対象システムＩＦ部１３０は、ＡＰＩの版数（ｖ３）をＡＰＩ版数管理部１２０に回答する。また、管理対象システムＩＦ部１３０は、取得したアクセストークンをＡＰＩ版数管理部１２０に通知する。
管理対象システムＩＦ部１３０は、ＡＰＩの版数（ｖ３）をＡＰＩ版数管理部１２０に回答する。また、管理対象システムＩＦ部１３０は、取得したアクセストークンをＡＰＩ版数管理部１２０に通知する。
<ＡＰＩ変換部１４０>
ＡＰＩ変換部１４０は、各部への指示動作を実行した上で、所定のＡＰＩ変換プログラムを用いてＡＰＩ変換を行うとともに、所定のＡＰＩ変換プログラムがない場合は、該当ＡＰＩ変換プログラムを生成する。以下、（４）～（６）の項目に分けて述べる。
（４）各部への指示動作
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０にＡＰＩ変換プログラム（ｖ２→ｖ３）取得を指示する。
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０へＡＰＩ定義（Identity ＡＰＩ ｖ２とｖ３）取得を指示する。
ＡＰＩ変換部１４０は、ＡＰＩ定義（ｖ２）とＡＰＩ定義（ｖ３）の差分（diff）を抽出する。
ＡＰＩ変換部１４０は、新版数（ｖ３）に新規パラメータが存在する場合、外部システムＩＦ部１１０に不足情報要求を指示する。
ＡＰＩ変換部１４０は、各部への指示動作を実行した上で、所定のＡＰＩ変換プログラムを用いてＡＰＩ変換を行うとともに、所定のＡＰＩ変換プログラムがない場合は、該当ＡＰＩ変換プログラムを生成する。以下、（４）～（６）の項目に分けて述べる。
（４）各部への指示動作
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０にＡＰＩ変換プログラム（ｖ２→ｖ３）取得を指示する。
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０へＡＰＩ定義（Identity ＡＰＩ ｖ２とｖ３）取得を指示する。
ＡＰＩ変換部１４０は、ＡＰＩ定義（ｖ２）とＡＰＩ定義（ｖ３）の差分（diff）を抽出する。
ＡＰＩ変換部１４０は、新版数（ｖ３）に新規パラメータが存在する場合、外部システムＩＦ部１１０に不足情報要求を指示する。
ＡＰＩ変換部１４０は、ＡＰＩ定義（ｖ２）、ＡＰＩ定義（ｖ３）、不足情報を用いてＡＰＩ変換プログラム（ｖ２→ｖ３）を生成する。
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０へＡＰＩ変換プログラム（ｖ２→ｖ３）のＡＰＩ変換ＤＢ２０への登録を指示する。
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０にＡＰＩ変換プログラム（ｖ２→ｖ３）取得を指示する。
ＡＰＩ変換部１４０は、ＡＰＩ変換プログラム（ｖ２→ｖ３）２５を用いて、受信したアクセストークン取得ＡＰＩをｖ２からｖ３へ変換する。
ＡＰＩ変換部１４０は、ＡＰＩ版数管理部１２０にＡＰＩ変換結果を通知する。
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０へＡＰＩ変換プログラム（ｖ２→ｖ３）のＡＰＩ変換ＤＢ２０への登録を指示する。
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０にＡＰＩ変換プログラム（ｖ２→ｖ３）取得を指示する。
ＡＰＩ変換部１４０は、ＡＰＩ変換プログラム（ｖ２→ｖ３）２５を用いて、受信したアクセストークン取得ＡＰＩをｖ２からｖ３へ変換する。
ＡＰＩ変換部１４０は、ＡＰＩ版数管理部１２０にＡＰＩ変換結果を通知する。
（５）所定のＡＰＩ変換プログラムが取得できる場合
ＡＰＩ変換部１４０は、ＡＰＩ変換指示を受けて、ＡＰＩ変換ＤＢ２０からＡＰＩ定義（IdentityＡＰＩ ｖ２とｖ３）、およびＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）を取得するとともに、取得したＡＰＩ定義（Identity ＡＰＩ ｖ２とｖ３）、およびＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５に基づいて、受信したＡＰＩをｖ２からｖ３へ変換する。
ＡＰＩ変換部１４０は、ＡＰＩ変換指示を受けて、ＡＰＩ変換ＤＢ２０からＡＰＩ定義（IdentityＡＰＩ ｖ２とｖ３）、およびＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）を取得するとともに、取得したＡＰＩ定義（Identity ＡＰＩ ｖ２とｖ３）、およびＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５に基づいて、受信したＡＰＩをｖ２からｖ３へ変換する。
（６）所定のＡＰＩ変換プログラムがなく、当該ＡＰＩ変換プログラムを生成する場合
ＡＰＩ変換部１４０は、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を取得できなかった場合、ＡＰＩ定義（IdentityＡＰＩ ｖ２）とＡＰＩ定義（IdentityＡＰＩ ｖ３）の差分（diff）を抽出し、新版数（ｖ３）に新規パラメータが存在する場合、サービス提供システム１０に不足情報を要求し、サービス提供システム１０から取得した不足情報と、ＡＰＩ変換ＤＢ２０から取得したＡＰＩ定義（IdentityＡＰＩｖ２）２２およびＡＰＩ定義（IdentityＡＰＩｖ３）２３とに基づいて、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を生成する。
ＡＰＩ変換部１４０は、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を取得できなかった場合、ＡＰＩ定義（IdentityＡＰＩ ｖ２）とＡＰＩ定義（IdentityＡＰＩ ｖ３）の差分（diff）を抽出し、新版数（ｖ３）に新規パラメータが存在する場合、サービス提供システム１０に不足情報を要求し、サービス提供システム１０から取得した不足情報と、ＡＰＩ変換ＤＢ２０から取得したＡＰＩ定義（IdentityＡＰＩｖ２）２２およびＡＰＩ定義（IdentityＡＰＩｖ３）２３とに基づいて、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を生成する。
<ＡＰＩ変換ＤＢアクセス部１５０>
ＡＰＩ変換ＤＢアクセス部１５０は、ＡＰＩ定義（IdentityＡＰＩ ｖ１）２１～２４、およびＡＰＩ変換プログラム（IdentityＡＰＩ）２４を格納するＡＰＩ変換ＤＢ２０にアクセスする。
ＡＰＩ変換ＤＢアクセス部１５０は、ＡＰＩ定義（IdentityＡＰＩ ｖ１）２１～２４、およびＡＰＩ変換プログラム（IdentityＡＰＩ）２４を格納するＡＰＩ変換ＤＢ２０にアクセスする。
ＡＰＩ変換ＤＢアクセス部１５０は、ＡＰＩ変換部１４０に該当のＡＰＩ定義、および所定のＡＰＩ変換プログラムの取得結果をＡＰＩ変換部１４０へ通知する。ＡＰＩ変換プログラムが取得できなかった場合、「なし」を通知する。
［ＡＰＩ変換ＤＢ２０］
図１に示すように、ＡＰＩ変換ＤＢ２０は、ＡＰＩを記述する定義書であるＡＰＩ定義（IdentityＡＰＩ ｖ１）２１、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３と、ＡＰＩ変換機能のためのＡＰＩ変換プログラム（Identity ＡＰＩ）２４と、を格納する。
図１に示すように、ＡＰＩ変換ＤＢ２０は、ＡＰＩを記述する定義書であるＡＰＩ定義（IdentityＡＰＩ ｖ１）２１、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３と、ＡＰＩ変換機能のためのＡＰＩ変換プログラム（Identity ＡＰＩ）２４と、を格納する。
以下、上述のように構成されたＡＰＩ変換装置１００の動作について説明する。
［動作概要］
まず、図２～図３を参照してＡＰＩ変換装置１００の動作概要を述べる。
<事前準備>
図２は、ＡＰＩ変換装置１００の事前準備の動作例を示す図である。図２は、後記図３の本番に先立って行われるＡＰＩ実行テストを示している。 “アクセストークン取得ＡＰＩ”を動作例に採る。
図２に示すように、管理対象システム３０は、アクセストークン取得ＡＰＩの版数の異なるサーバ３１～３３である。例えば、OpenStack Liberty版サーバ３１は、アクセストークン取得ＡＰＩがIdentityＡＰＩ ｖ２のサーバ、OpenStack Newton版サーバ３２は、アクセストークン取得ＡＰＩがIdentityＡＰＩ ｖ３のサーバ、OpenStack Rocky版サーバ３３は、アクセストークン取得ＡＰＩがIdentityＡＰＩ ｖ４のサーバである。
［動作概要］
まず、図２～図３を参照してＡＰＩ変換装置１００の動作概要を述べる。
<事前準備>
図２は、ＡＰＩ変換装置１００の事前準備の動作例を示す図である。図２は、後記図３の本番に先立って行われるＡＰＩ実行テストを示している。 “アクセストークン取得ＡＰＩ”を動作例に採る。
図２に示すように、管理対象システム３０は、アクセストークン取得ＡＰＩの版数の異なるサーバ３１～３３である。例えば、OpenStack Liberty版サーバ３１は、アクセストークン取得ＡＰＩがIdentityＡＰＩ ｖ２のサーバ、OpenStack Newton版サーバ３２は、アクセストークン取得ＡＰＩがIdentityＡＰＩ ｖ３のサーバ、OpenStack Rocky版サーバ３３は、アクセストークン取得ＡＰＩがIdentityＡＰＩ ｖ４のサーバである。
サービス提供システム１０の保守運用者１０ａが、管理対象システム３０に対してIdentityＡＰＩ ｖ２のアクセストークン取得を発行する（ステップＳ１１）。ＡＰＩ変換装置１００は、このIdentityＡＰＩ ｖ２のアクセストークン取得を受けて、アクセストークン取得ＡＰＩ（ｖ２）からＡＰＩ版数取得ＡＰＩに変換し（ＡＰＩ変換（Identity ＡＰＩ ｖ２→ＡＰＩ版数変換ＡＰＩ））、管理対象システム３０（ここではOpenStack Newton版サーバ３２）にＡＰＩの版数取得を送信する（ステップＳ１２）。なお、まだOpenStack Newton版サーバ３２のＡＰＩ版数が分かっていないので、後記ＡＰＩ変換（同種ＡＰＩの異なる版数間の変換）ではなく、アクセストークン取得ＡＰＩ（ｖ２）からＡＰＩ版数取得ＡＰＩへの変換である。
OpenStack Newton版サーバ３２は、ＡＰＩ変換装置１００にＡＰＩ版数（ｖ３）を送信する（ステップＳ１３）。
ＡＰＩ変換装置１００は、ＡＰＩ変換ＤＢ２０に対してＡＰＩ変換ＤＢ２０からＡＰＩ変換プログラム（ｖ２→ｖ３）２５（後記図６および図７参照。以下同様。）取得しようとする（ステップＳ１４）。図２の例では、図１に示すＡＰＩ変換ＤＢ２０は、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ１→ｖ２）２４を有するものの、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５を有しない。このため、ＡＰＩ変換ＤＢ２０は、ＡＰＩ変換装置１００にＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５「なし」を返す（ステップＳ１５）。
ＡＰＩ変換装置１００は、ＡＰＩ変換ＤＢ２０に対してＡＰＩ変換ＤＢ２０からＡＰＩ変換プログラム（ｖ２→ｖ３）２５（後記図６および図７参照。以下同様。）取得しようとする（ステップＳ１４）。図２の例では、図１に示すＡＰＩ変換ＤＢ２０は、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ１→ｖ２）２４を有するものの、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５を有しない。このため、ＡＰＩ変換ＤＢ２０は、ＡＰＩ変換装置１００にＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５「なし」を返す（ステップＳ１５）。
ＡＰＩ変換装置１００は、ＡＰＩ変換ＤＢ２０からＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５「なし」を受けて、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５を生成するために下記の動作を行う。
ＡＰＩ変換装置１００は、ＡＰＩ変換ＤＢ２０からＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３（図１参照）を取得するための要求を出す（ステップＳ１６）。ＡＰＩ変換ＤＢ２０は、ＡＰＩ変換装置１００にＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３を返す（ステップＳ１７）。
ＡＰＩ変換装置１００は、このＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３をもとに、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２とＡＰＩ定義（IdentityＡＰＩ ｖ３）２３との差分（diff ｖ２⇔ｖ３）を抽出する（ステップＳ１８）。
ＡＰＩ変換装置１００は、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）を生成の際に不足する不足情報を、保守運用者１０ａに要求する（ステップＳ１９）。この場合、保守運用者１０ａに対して、不足するパラメータについて必須か任意かの属性を通知することで、保守運用者１０ａが不足情報を検討する際の稼動削減を図ることができる。保守運用者１０ａは、ＡＰＩ変換装置１００に不足情報を回答する（ステップＳ２０）。ここで、保守運用者１０ａにＧＵＩ（Graphical User Interface）画面を表示して、保守運用者１０ａがＧＵＩ画面入力する態様でもよい。
ＡＰＩ変換装置１００は、取得したＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５を生成の際に不足する不足情報と、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３と、に基づいてＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を生成する（ステップＳ２１）。
ＡＰＩ変換装置１００は、生成したＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５をＡＰＩ変換ＤＢ２０に登録する（ステップＳ２２）。なお、後記図６および図７に示すように、ＡＰＩ変換装置１００によって生成されたＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５がＡＰＩ変換ＤＢ２０に登録されている。このように、一旦、ＡＰＩ変換ＤＢ２０に登録されたＡＰＩ変換プログラムは、他の利用者がＡＰＩ変換プログラムを参照することで再利用することが可能である。
ＡＰＩ変換装置１００は、生成したＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５をＡＰＩ変換ＤＢ２０に登録する（ステップＳ２２）。なお、後記図６および図７に示すように、ＡＰＩ変換装置１００によって生成されたＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５がＡＰＩ変換ＤＢ２０に登録されている。このように、一旦、ＡＰＩ変換ＤＢ２０に登録されたＡＰＩ変換プログラムは、他の利用者がＡＰＩ変換プログラムを参照することで再利用することが可能である。
<本番動作例>
図３は、ＡＰＩ変換装置１００の本番の動作例を示す図である。前記図２に示すＡＰＩ変換装置１００の事前準備の実行により、ＡＰＩ変換ＤＢ２０には、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５が登録されている。
図３に示すように、サービス提供システム１０の保守運用者１０ａが、管理対象システム３０に対してIdentityＡＰＩ ｖ２のアクセストークン取得を発行する（ステップＳ３１）。ＡＰＩ変換装置１００は、このIdentityＡＰＩ ｖ２のアクセストークン取得発行を受けて、ＡＰＩ変換ＤＢ２０に対しＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）の取得を要求する（ステップＳ３２）。ＡＰＩ変換ＤＢ２０は、ＡＰＩ変換装置１００にＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）を送信する（ステップＳ３３）。
図３は、ＡＰＩ変換装置１００の本番の動作例を示す図である。前記図２に示すＡＰＩ変換装置１００の事前準備の実行により、ＡＰＩ変換ＤＢ２０には、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５が登録されている。
図３に示すように、サービス提供システム１０の保守運用者１０ａが、管理対象システム３０に対してIdentityＡＰＩ ｖ２のアクセストークン取得を発行する（ステップＳ３１）。ＡＰＩ変換装置１００は、このIdentityＡＰＩ ｖ２のアクセストークン取得発行を受けて、ＡＰＩ変換ＤＢ２０に対しＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）の取得を要求する（ステップＳ３２）。ＡＰＩ変換ＤＢ２０は、ＡＰＩ変換装置１００にＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）を送信する（ステップＳ３３）。
ＡＰＩ変換装置１００は、ＡＰＩ変換ＤＢ２０からＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５を取得して、Identity ＡＰＩの版数をｖ２→ｖ３に変換するＡＰＩ変換（Identity ＡＰＩ ｖ２→ｖ３）を行う（ステップＳ３４）。
ＡＰＩ変換装置１００は、上記ＡＰＩ変換によりIdentityＡＰＩ ｖ２をIdentityＡＰＩ ｖ３に変換したIdentityＡＰＩ ｖ３をもとに、管理対象システム３０（ここではOpenStack Newton版サーバ３２）に対してIdentityＡＰＩ ｖ３のアクセストークン取得を行う（ステップＳ３５）。OpenStack Newton版サーバ３２は、ＡＰＩ変換装置１００にIdentityＡＰＩ ｖ３のアクセストークンを送信する（ステップＳ３６）。
ＡＰＩ変換装置１００は、保守運用者１０ａにOpenStack Newton版サーバ３２からの、IdentityＡＰＩ ｖ３のアクセストークンを送信する（ステップＳ３７）。
<ＡＰＩ変換ルール生成手順>
図４は、ＡＰＩ変換装置１００のＡＰＩ変換ルール生成手順を示す図である。
ＡＰＩのバージョンアップによりパラメータの追加や削除が発生する。しかし、パラメータの追加や削除は、リアルタイムで実行されるとは限らない。このため、完全自動化は困難である。本実施形態では、必要最低限の手動処理（図４のＳｔｅｐ２参照）と自動処理（図４のＳｔｅｐ１，Ｓｔｅｐ３参照）を組合せることで処理稼動を最適化する。
図４は、ＡＰＩ変換装置１００のＡＰＩ変換ルール生成手順を示す図である。
ＡＰＩのバージョンアップによりパラメータの追加や削除が発生する。しかし、パラメータの追加や削除は、リアルタイムで実行されるとは限らない。このため、完全自動化は困難である。本実施形態では、必要最低限の手動処理（図４のＳｔｅｐ２参照）と自動処理（図４のＳｔｅｐ１，Ｓｔｅｐ３参照）を組合せることで処理稼動を最適化する。
Ｓｔｅｐ１の自動処理は、新旧ＡＰＩ定義の差分抽出（diff）を行う。具体的には、図２のＳ１８のＡＰＩ定義（IdentityＡＰＩ ｖ２）２２とＡＰＩ定義（IdentityＡＰＩ ｖ３）２３との差分（diff ｖ２⇔ｖ３）を抽出処理である。
Ｓｔｅｐ２の手動処理は、一方にのみ存在するパラメータを入力する。具体的には、図２のＳ１９のＡＰＩ変換プログラムを生成の際に不足する不足情報の要求と、図２のＳ２０のその不足情報の回答である。
Ｓｔｅｐ３の自動処理は、ＡＰＩ変換プログラムの生成および登録である。具体的には、図２のＳ２１のＡＰＩ変換プログラムの生成と、図２のＳ２２の生成されたＡＰＩ変換プログラムのＡＰＩ変換ＤＢ２０への登録である。
［動作詳細］
次に、図５～図８を参照してＡＰＩ変換装置１００の動作詳細を述べる。
<事前準備>
図５および図６は、ＡＰＩ変換装置１００の事前準備の詳細な動作例を示す図であり、図２のＡＰＩ変換装置１００の事前準備の動作の詳細を示している。図５は、図２と同様に“アクセストークン取得ＡＰＩ”を動作例に採る。図２と同一処理を実行するステップには同一符号を付している。
図５に示すように、サービス提供システム１０の保守運用者１０ａが、管理対象システム３０に対してIdentityＡＰＩ ｖ２のアクセストークン取得を発行する（ステップＳ１１）。ＡＰＩ変換装置１００は、このIdentityＡＰＩ ｖ２のアクセストークン取得を受けて、アクセストークン取得ＡＰＩ（ｖ２）からＡＰＩ版数取得ＡＰＩに変換し（ＡＰＩ変換（Identity ＡＰＩ ｖ２→ＡＰＩ版数変換ＡＰＩ））、管理対象システム３０（ここではOpenStack Newton版サーバ３２）にＡＰＩの版数取得を送信する（ステップＳ１２）。
次に、図５～図８を参照してＡＰＩ変換装置１００の動作詳細を述べる。
<事前準備>
図５および図６は、ＡＰＩ変換装置１００の事前準備の詳細な動作例を示す図であり、図２のＡＰＩ変換装置１００の事前準備の動作の詳細を示している。図５は、図２と同様に“アクセストークン取得ＡＰＩ”を動作例に採る。図２と同一処理を実行するステップには同一符号を付している。
図５に示すように、サービス提供システム１０の保守運用者１０ａが、管理対象システム３０に対してIdentityＡＰＩ ｖ２のアクセストークン取得を発行する（ステップＳ１１）。ＡＰＩ変換装置１００は、このIdentityＡＰＩ ｖ２のアクセストークン取得を受けて、アクセストークン取得ＡＰＩ（ｖ２）からＡＰＩ版数取得ＡＰＩに変換し（ＡＰＩ変換（Identity ＡＰＩ ｖ２→ＡＰＩ版数変換ＡＰＩ））、管理対象システム３０（ここではOpenStack Newton版サーバ３２）にＡＰＩの版数取得を送信する（ステップＳ１２）。
ＡＰＩ変換装置１００のＡＰＩ変換機能は、下記の通りである。
外部システムＩＦ部１１０は、サービス提供システム１０の保守運用者１０ａからＡＰＩ（ここではIdentityＡＰＩ ｖ２のアクセストークン取得）を受信すると（ステップＳ１１）、ＡＰＩ版数管理部１２０に通知する。
外部システムＩＦ部１１０は、サービス提供システム１０の保守運用者１０ａからＡＰＩ（ここではIdentityＡＰＩ ｖ２のアクセストークン取得）を受信すると（ステップＳ１１）、ＡＰＩ版数管理部１２０に通知する。
ＡＰＩ版数管理部１２０は、ＡＰＩ（IdentityＡＰＩ ｖ２のアクセストークン取得）の宛先システムのＡＰＩの版数を保持しているか確認する（ステップＳ１１１）。ＡＰＩ（IdentityＡＰＩ ｖ２のアクセストークン取得）の宛先システムのＡＰＩの版数を保持していない場合、管理対象システムＩＦ部１３０にＡＰＩの版数の取得を指示する（ステップＳ１１２）。いま、ＡＰＩ版数管理部１２０は、ＡＰＩ（IdentityＡＰＩ ｖ２のアクセストークン取得）の宛先システムのＡＰＩの版数を保持していないので、管理対象システムＩＦ部１３０にＡＰＩの版数の取得を指示する。
管理対象システムＩＦ部１３０は、ＡＰＩ版数管理部１２０にＡＰＩ版数（Identity ＡＰＩ ｖ３）を回答する（ステップＳ１１３）。
ＡＰＩ版数管理部１２０は、外部システムＩＦ部１１０が受信したＡＰＩ版数（IdentityＡＰＩ ｖ２）と管理対象システム３０（ここではOpenStack Newton版サーバ３２）のＡＰＩ版数（IdentityＡＰＩ ｖ３）を比較する。そして、ＡＰＩ版数管理部１２０は、ＡＰＩ版数が異なる場合、ＡＰＩ変換部１４０にＡＰＩ変換を指示する（ステップＳ１１４）。
ＡＰＩ版数管理部１２０は、外部システムＩＦ部１１０が受信したＡＰＩ版数（IdentityＡＰＩ ｖ２）と管理対象システム３０（ここではOpenStack Newton版サーバ３２）のＡＰＩ版数（IdentityＡＰＩ ｖ３）を比較する。そして、ＡＰＩ版数管理部１２０は、ＡＰＩ版数が異なる場合、ＡＰＩ変換部１４０にＡＰＩ変換を指示する（ステップＳ１１４）。
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０にＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）取得を指示する（ステップＳ１１５）。ＡＰＩ変換ＤＢアクセス部１５０は、ＡＰＩ変換ＤＢ２０に対してＡＰＩ変換ＤＢ２０からＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）取得しようとする（ステップＳ１４）。図５の例では、ＡＰＩ変換ＤＢ２０は、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）を有しない。このため、ＡＰＩ変換ＤＢ２０は、ＡＰＩ変換装置１００にＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５「なし」を返す（ステップＳ１５）。
ＡＰＩ変換ＤＢアクセス部１５０は、ＡＰＩ変換ＤＢ２０からの結果（この場合、取得できなかったため「なし」）をＡＰＩ変換部１４０に通知する（ステップＳ１１６）。
ここまでの動作で、ＡＰＩ変換装置１００は、ＡＰＩ変換ＤＢ２０にＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５がないことを確認したので、下記のＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５の生成を行う。
図６に示すように、ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０にＡＰＩ定義（Identity ＡＰＩ ｖ２とｖ３）取得を指示する（ステップＳ１１７）。ＡＰＩ変換ＤＢアクセス部１５０は、ＡＰＩ変換部１４０に該当のＡＰＩ定義を通知する（ステップＳ１１８）。
ＡＰＩ変換部１４０は、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２とＡＰＩ定義（IdentityＡＰＩ ｖ３）２３との差分（diffｖ２⇔ｖ３）を抽出する（ステップＳ１１９）。
ＡＰＩ変換部１４０は、新バージョン（ｖ３）に新規パラメータが存在するか否か判断し（ステップＳ１２０）、新バージョン（ｖ３）に新規パラメータが存在する場合、外部システムＩＦ部１１０に不足情報要求を指示する（ステップＳ１２０）。
ＡＰＩ変換部１４０は、新バージョン（ｖ３）に新規パラメータが存在するか否か判断し（ステップＳ１２０）、新バージョン（ｖ３）に新規パラメータが存在する場合、外部システムＩＦ部１１０に不足情報要求を指示する（ステップＳ１２０）。
外部システムＩＦ部１１０は、保守運用者１０ａから取得（ステップＳ１９，Ｓ２０）した不足情報（該当パラメータの値）をＡＰＩ変換部１４０に通知する（ステップＳ１２１）。
ＡＰＩ変換部１４０は、取得したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）を生成の際に不足する不足情報と、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３と、に基づいてＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）を生成する（ステップＳ１２２）。
ＡＰＩ変換部１４０は、取得したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）を生成の際に不足する不足情報と、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３と、に基づいてＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）を生成する（ステップＳ１２２）。
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０にＡＰＩ変換プログラム（Identityｖ２→ｖ３）のＡＰＩ変換ＤＢ２０への登録を指示する（ステップＳ１２３）。
ＡＰＩ変換ＤＢアクセス部１５０は、生成したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）をＡＰＩ変換ＤＢ２０に登録する（ステップＳ２２）。これにより、ＡＰＩ変換装置１００によって生成されたＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５がＡＰＩ変換ＤＢ２０に登録される。
ＡＰＩ変換ＤＢアクセス部１５０は、生成したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）をＡＰＩ変換ＤＢ２０に登録する（ステップＳ２２）。これにより、ＡＰＩ変換装置１００によって生成されたＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５がＡＰＩ変換ＤＢ２０に登録される。
<本番動作例>
図７は、ＡＰＩ変換装置１００の本番の詳細な動作例を示す図であり、図３のＡＰＩ変換装置１００の本番の動作の詳細を示している。図３と同一処理を実行するステップには同一符号を付している。
前記図５および図６に示すＡＰＩ変換装置１００の事前準備の実行により、ＡＰＩ変換ＤＢ２０には、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５が登録されている。
図７に示すように、サービス提供システム１０の保守運用者１０ａが、管理対象システム３０に対してIdentityＡＰＩ ｖ２のアクセストークン取得を発行する（ステップＳ３１）。
外部システムＩＦ部１１０は、ＡＰＩを受信するとＡＰＩ版数管理部１２０に通知する（ステップＳ３１１）。
図７は、ＡＰＩ変換装置１００の本番の詳細な動作例を示す図であり、図３のＡＰＩ変換装置１００の本番の動作の詳細を示している。図３と同一処理を実行するステップには同一符号を付している。
前記図５および図６に示すＡＰＩ変換装置１００の事前準備の実行により、ＡＰＩ変換ＤＢ２０には、ＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）２５が登録されている。
図７に示すように、サービス提供システム１０の保守運用者１０ａが、管理対象システム３０に対してIdentityＡＰＩ ｖ２のアクセストークン取得を発行する（ステップＳ３１）。
外部システムＩＦ部１１０は、ＡＰＩを受信するとＡＰＩ版数管理部１２０に通知する（ステップＳ３１１）。
ＡＰＩ版数管理部１２０は、ＡＰＩの宛先システムである管理対象システム３０（ここではOpenStack Newton版サーバ３２）のＡＰＩの版数を保持しているか確認する。ＡＰＩの版数を保持している場合、保守運用者１０ａから受信したＡＰＩの版数（ｖ２）と管理対象システム３０（OpenStack Newton版サーバ３２）のＡＰＩの版数（ｖ３）を比較し、ＡＰＩの版数が異なる場合、ＡＰＩ変換部１４０にＡＰＩ変換を指示する（ステップＳ３１２）。
ＡＰＩ変換部１４０は、ＡＰＩ変換ＤＢアクセス部１５０にＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）取得を指示する（ステップＳ３１３）。
ＡＰＩ変換ＤＢアクセス部１５０は、結果をＡＰＩ変換部１４０に通知する（ステップＳ３１４）。この場合、取得できたため、ＡＰＩ変換ＤＢアクセス部１５０は、「ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）」をＡＰＩ変換部１４０に送信する。
ＡＰＩ変換ＤＢアクセス部１５０は、結果をＡＰＩ変換部１４０に通知する（ステップＳ３１４）。この場合、取得できたため、ＡＰＩ変換ＤＢアクセス部１５０は、「ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）」をＡＰＩ変換部１４０に送信する。
ＡＰＩ変換部１４０は、取得したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）を用いて、外部システムＩＦ部１１０が受信したアクセストークン取得ＡＰＩをｖ２からｖ３へ変換する。
ＡＰＩ変換部１４０は、ＡＰＩ版数管理部１２０にＡＰＩ変換結果を通知する（ステップＳ３１５）。
ＡＰＩ変換部１４０は、ＡＰＩ版数管理部１２０にＡＰＩ変換結果を通知する（ステップＳ３１５）。
ＡＰＩ版数管理部１２０は、管理対象システムＩＦ部１３０にアクセストークン取得ＡＰＩ（ｖ３）送信を指示する（ステップＳ３１６）。管理対象システムＩＦ部１３０は、取得したアクセストークンをＡＰＩ版数管理部１２０に通知する（ステップＳ３１７）。
ＡＰＩ版数管理部１２０は、外部システムＩＦ部１１０へアクセストークンの返送を指示する（ステップＳ３１８）。外部システムＩＦ部１１０は、保守運用者１０ａにOpenStack Newton版サーバ３２からの、IdentityＡＰＩ ｖ３のアクセストークンを送信する（ステップＳ３７）。
ＡＰＩ版数管理部１２０は、外部システムＩＦ部１１０へアクセストークンの返送を指示する（ステップＳ３１８）。外部システムＩＦ部１１０は、保守運用者１０ａにOpenStack Newton版サーバ３２からの、IdentityＡＰＩ ｖ３のアクセストークンを送信する（ステップＳ３７）。
<動作フロー>
図８Ａおよび図８Ｂは、ＡＰＩ変換装置１００のＡＰＩ変換方法の主要動作を示すフローチャートである。
ステップＳ５０１でＡＰＩ版数管理部１２０（図１参照）は、管理対象システム３０（図１参照）のＡＰＩの版数を保持しているか否かを確認する。
管理対象システム３０のＡＰＩの版数を保持していない場合（ステップＳ５０１：Ｎｏ）、ステップＳ５０２でＡＰＩ版数管理部１２０は、管理対象システム３０からＡＰＩの版数を取得する。管理対象システム３０のＡＰＩの版数を保持している場合（ステップＳ５０１：Ｙｅｓ）、ステップＳ５０３に進む。
図８Ａおよび図８Ｂは、ＡＰＩ変換装置１００のＡＰＩ変換方法の主要動作を示すフローチャートである。
ステップＳ５０１でＡＰＩ版数管理部１２０（図１参照）は、管理対象システム３０（図１参照）のＡＰＩの版数を保持しているか否かを確認する。
管理対象システム３０のＡＰＩの版数を保持していない場合（ステップＳ５０１：Ｎｏ）、ステップＳ５０２でＡＰＩ版数管理部１２０は、管理対象システム３０からＡＰＩの版数を取得する。管理対象システム３０のＡＰＩの版数を保持している場合（ステップＳ５０１：Ｙｅｓ）、ステップＳ５０３に進む。
ステップＳ５０３でＡＰＩ版数管理部１２０は、サービス提供システム１０から受信したＡＰＩの版数（ｖ２）と管理対象システム３０のＡＰＩの版数（ｖ３）が異なるか否かを判別する。
ＡＰＩの版数が異なる場合（ステップＳ５０３：Ｙｅｓ）、ステップＳ５０４に進み、ＡＰＩの版数が異ならない場合（版数が同一の場合）（ステップＳ５０３：Ｎｏ）、本フローの処理を終了する。
ＡＰＩの版数が異なる場合（ステップＳ５０３：Ｙｅｓ）、ステップＳ５０４に進み、ＡＰＩの版数が異ならない場合（版数が同一の場合）（ステップＳ５０３：Ｎｏ）、本フローの処理を終了する。
ステップＳ５０４でＡＰＩ変換ＤＢアクセス部１５０は、ＡＰＩ定義（IdentityＡＰＩ ｖ１）２１～２３、およびＡＰＩ変換プログラム（Identity ＡＰＩ）２４を格納するＡＰＩ変換ＤＢ２０にアクセスする。
ステップＳ５０５でＡＰＩ変換ＤＢアクセス部１５０は、ＡＰＩ変換部１４０にＡＰＩ変換を指示する。
ステップＳ５０５でＡＰＩ変換ＤＢアクセス部１５０は、ＡＰＩ変換部１４０にＡＰＩ変換を指示する。
ステップＳ５０６でＡＰＩ変換部１４０は、前記ＡＰＩ変換指示を受けて、ＡＰＩ変換ＤＢ２０からＡＰＩ定義（Identity ＡＰＩ ｖ２とｖ３）２２，２３、およびＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を取得する。
ステップＳ５０７でＡＰＩ変換部１４０は、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を取得できたか否かを判別する。
ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を取得できた場合（ステップＳ５０７：Ｙｅｓ）、ステップＳ５０８でＡＰＩ変換部１４０は、取得したＡＰＩ定義（IdentityＡＰＩ ｖ２とｖ３）、およびＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５に基づいて、受信したＡＰＩをｖ２からｖ３へ変換して本フローを終了する。
ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を取得できた場合（ステップＳ５０７：Ｙｅｓ）、ステップＳ５０８でＡＰＩ変換部１４０は、取得したＡＰＩ定義（IdentityＡＰＩ ｖ２とｖ３）、およびＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５に基づいて、受信したＡＰＩをｖ２からｖ３へ変換して本フローを終了する。
一方、ステップＳ５０７でＡＰＩ変換部１４０は、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を取得できなかった場合（ステップＳ５０７：Ｎｏ）、下記のステップＳ５０９以下の処理を実行する。この場合、ＡＰＩ変換ＤＢ２０は、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を保持しておらず、ＡＰＩ変換部１４０は、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を取得できないとする。
ステップＳ５０９でＡＰＩ変換部１４０は、ＡＰＩ定義（Identity ＡＰＩｖ２）２２とＡＰＩ定義（Identity ＡＰＩｖ３）２３の差分（diff）を抽出し、新版数（ｖ３）に新規パラメータが存在する場合、サービス提供システム１０に不足情報を要求する。
ステップＳ５１０でＡＰＩ変換部１４０は、サービス提供システム１０から取得した不足情報と、ＡＰＩ変換ＤＢ２０から取得したＡＰＩ定義（Identity ＡＰＩｖ２）２２およびＡＰＩ定義（Identity ＡＰＩｖ３）２３とに基づいて、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を生成する。
ステップＳ５１１でＡＰＩ変換部１４０は、生成したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５に基づいて、受信したＡＰＩをｖ２からｖ３へ変換する。
ステップＳ５１２でＡＰＩ変換ＤＢアクセス部１５０は、生成したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５をＡＰＩ変換ＤＢ２０に登録して本フローの処理を終える。
ステップＳ５１２でＡＰＩ変換ＤＢアクセス部１５０は、生成したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５をＡＰＩ変換ＤＢ２０に登録して本フローの処理を終える。
［ＡＰＩ変換ルール生成手順］
ＡＰＩ変換ルール生成の具体例について説明する。
<新旧ＡＰＩ定義の差分抽出>
まず、ＡＰＩ変換装置１００（図１参照）は、新旧ＡＰＩ定義の差分抽出（diff）を行う。この新旧ＡＰＩ定義の差分抽出（diff）は、前記図４のＡＰＩ変換ルール生成手順のＳｔｅｐ１の自動処理に対応する。より詳細には、図６のＡＰＩ変換部１４０の差分抽出（diff）（ステップＳ１１９）である。
ＡＰＩ変換ルール生成の具体例について説明する。
<新旧ＡＰＩ定義の差分抽出>
まず、ＡＰＩ変換装置１００（図１参照）は、新旧ＡＰＩ定義の差分抽出（diff）を行う。この新旧ＡＰＩ定義の差分抽出（diff）は、前記図４のＡＰＩ変換ルール生成手順のＳｔｅｐ１の自動処理に対応する。より詳細には、図６のＡＰＩ変換部１４０の差分抽出（diff）（ステップＳ１１９）である。
図９は、ＡＰＩ変換装置１００の新旧ＡＰＩ定義の差分抽出の一例を示す図である。図９は、前記図４のＳｔｅｐ１の自動処理新旧ＡＰＩ定義の差分抽出（diff）の具体例である。
前記図１に示すように、ＡＰＩ変換ＤＢ２０には、ＡＰＩ定義（IdentityＡＰＩ ｖ１）２１、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２、ＡＰＩ定義（IdentityＡＰＩ ｖ３）２３、ＡＰＩ変換プログラム（Identity ＡＰＩ）２４が格納されている。
ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２とＡＰＩ定義（IdentityＡＰＩ ｖ３）２３との差分（diff ｖ２⇔ｖ３）抽出を例に採る。
前記図１に示すように、ＡＰＩ変換ＤＢ２０には、ＡＰＩ定義（IdentityＡＰＩ ｖ１）２１、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２、ＡＰＩ定義（IdentityＡＰＩ ｖ３）２３、ＡＰＩ変換プログラム（Identity ＡＰＩ）２４が格納されている。
ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２とＡＰＩ定義（IdentityＡＰＩ ｖ３）２３との差分（diff ｖ２⇔ｖ３）抽出を例に採る。
図９に示すように、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２は、
API版数 version: “2.0”
API名 title: “Identity API ”
URL /v2.0/tokens:
HTTPメソッド post:
以下パラメータ定義 parameters:
を記述し、
以下パラメータ定義 parameters:は、さらに、
パラメータ名 - name: “methods”
パラメータの場所 in: “body”
必須パラメータか否か required: true
パラメータの型 type: array
を記述し、
以下レスポンス定義 responses:
を記述する。
API版数 version: “2.0”
API名 title: “Identity API ”
URL /v2.0/tokens:
HTTPメソッド post:
以下パラメータ定義 parameters:
を記述し、
以下パラメータ定義 parameters:は、さらに、
パラメータ名 - name: “methods”
パラメータの場所 in: “body”
必須パラメータか否か required: true
パラメータの型 type: array
を記述し、
以下レスポンス定義 responses:
を記述する。
一方、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２３は、ＡＰＩ定義（IdentityＡＰＩ ｖ３）２２と比較して、図９の符号ａの[差分１]に示すように、
URL /v3.0/tokens:
というURL変更がある。
また、図９の符号ｂの[差分２]に示すように、
“domain”パラメータが追加されており、差分となる。
URL /v3.0/tokens:
というURL変更がある。
また、図９の符号ｂの[差分２]に示すように、
“domain”パラメータが追加されており、差分となる。
<パラメータ追加>
次に、ＡＰＩ変換装置１００は、一方にのみ存在するパラメータを入力する。具体的には、ＡＰＩ定義（IdentityＡＰＩ ｖ３）では“domain”というパラメータが追加されているため、その値を保守運用者１０ａに入力してもらう。
このパラメータ追加は、前記図４のＡＰＩ変換ルール生成手順のＳｔｅｐ２の手動処理に対応する。より詳細には、図６のＡＰＩ変換部１４０が、外部システムＩＦ部１１０を介して行う不足情報要求（ステップＳ１９）と不足情報回答（ステップＳ２０）である。
次に、ＡＰＩ変換装置１００は、一方にのみ存在するパラメータを入力する。具体的には、ＡＰＩ定義（IdentityＡＰＩ ｖ３）では“domain”というパラメータが追加されているため、その値を保守運用者１０ａに入力してもらう。
このパラメータ追加は、前記図４のＡＰＩ変換ルール生成手順のＳｔｅｐ２の手動処理に対応する。より詳細には、図６のＡＰＩ変換部１４０が、外部システムＩＦ部１１０を介して行う不足情報要求（ステップＳ１９）と不足情報回答（ステップＳ２０）である。
<ＡＰＩ変換プログラム生成・登録>
次に、ＡＰＩ変換装置１００は、ＡＰＩ変換プログラム生成・登録する。具体的には、[差分１]（URL変更：”/ｖ２.0/tokens”→”/ｖ３.0/tokens”）、および、[差分２]（”domain”パラメータ追加）に対して文字列変換プログラムを生成し、ＡＰＩ変換ＤＢ２０に登録する。このＡＰＩ変換プログラム生成・登録は、前記図４のＡＰＩ変換ルール生成手順のＳｔｅｐ３の自動処理に対応する。より詳細には、図６のＡＰＩ変換部１４０が、取得したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）を生成の際に不足する不足情報と、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３と、に基づいてＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）を生成する処理（ステップＳ１２２）と、ＡＰＩ変換ＤＢアクセス部１５０が、生成したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）をＡＰＩ変換ＤＢ２０に登録する処理（ステップＳ２２）である。
次に、ＡＰＩ変換装置１００は、ＡＰＩ変換プログラム生成・登録する。具体的には、[差分１]（URL変更：”/ｖ２.0/tokens”→”/ｖ３.0/tokens”）、および、[差分２]（”domain”パラメータ追加）に対して文字列変換プログラムを生成し、ＡＰＩ変換ＤＢ２０に登録する。このＡＰＩ変換プログラム生成・登録は、前記図４のＡＰＩ変換ルール生成手順のＳｔｅｐ３の自動処理に対応する。より詳細には、図６のＡＰＩ変換部１４０が、取得したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）を生成の際に不足する不足情報と、ＡＰＩ定義（IdentityＡＰＩ ｖ２）２２およびＡＰＩ定義（IdentityＡＰＩ ｖ３）２３と、に基づいてＡＰＩ変換プログラム（Identity ＡＰＩ ｖ２→ｖ３）を生成する処理（ステップＳ１２２）と、ＡＰＩ変換ＤＢアクセス部１５０が、生成したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）をＡＰＩ変換ＤＢ２０に登録する処理（ステップＳ２２）である。
［ＡＰＩ変換例］
ＡＰＩ変換例についてさらに詳細に説明する。
図１０は、ＡＰＩ変換装置１００のＡＰＩ変換例を示す図である。図１０左は、前記図７の外部システムＩＦ部１１０が、受信したIdentityＡＰＩ ｖ２のアクセストークンである（ステップＳ３１）。また、図１０右は、前記図７の管理対象システムＩＦ部１３０が管理対象システム３０（OpenStack Newton版サーバ３２）に送信するIdentityＡＰＩ ｖ３のアクセストークンである（ステップＳ３５）。
ＡＰＩ変換例についてさらに詳細に説明する。
図１０は、ＡＰＩ変換装置１００のＡＰＩ変換例を示す図である。図１０左は、前記図７の外部システムＩＦ部１１０が、受信したIdentityＡＰＩ ｖ２のアクセストークンである（ステップＳ３１）。また、図１０右は、前記図７の管理対象システムＩＦ部１３０が管理対象システム３０（OpenStack Newton版サーバ３２）に送信するIdentityＡＰＩ ｖ３のアクセストークンである（ステップＳ３５）。
図１０の符号ｃの[変換１]に示すように、IdentityＡＰＩ ｖ２のアクセストークンの「GET /v2.0/tokens HTTP/1.1」が、IdentityＡＰＩ ｖ３のアクセストークンの「GET /v3.0/tokens HTTP/1.1」に変換されている。
また、図１０の符号ｄの[変換２]に示すように、IdentityＡＰＩ ｖ３のアクセストークンには、新規パラメータ
"domain": {
"name": "Default"
},
が追加されている。
また、図１０の符号ｄの[変換２]に示すように、IdentityＡＰＩ ｖ３のアクセストークンには、新規パラメータ
"domain": {
"name": "Default"
},
が追加されている。
［ハードウェア構成］
本実施形態に係るＡＰＩ変換装置１００は、例えば図１１に示すような構成のコンピュータ１０００によって実現される。以下、ＡＰＩ変換装置１００を例に挙げて説明する。図１１は、ＡＰＩ変換装置１００の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
コンピュータ９００は、ＣＰＵ９１０、ＲＡＭ９２０、ＲＯＭ９３０、ＨＤＤ９４０、通信インターフェイス（Ｉ／Ｆ：Interface）９５０、入出力インターフェイス（Ｉ／Ｆ）９６０、およびメディアインターフェイス（Ｉ／Ｆ）９７０を有する。
本実施形態に係るＡＰＩ変換装置１００は、例えば図１１に示すような構成のコンピュータ１０００によって実現される。以下、ＡＰＩ変換装置１００を例に挙げて説明する。図１１は、ＡＰＩ変換装置１００の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。
コンピュータ９００は、ＣＰＵ９１０、ＲＡＭ９２０、ＲＯＭ９３０、ＨＤＤ９４０、通信インターフェイス（Ｉ／Ｆ：Interface）９５０、入出力インターフェイス（Ｉ／Ｆ）９６０、およびメディアインターフェイス（Ｉ／Ｆ）９７０を有する。
ＣＰＵ９００は、ＲＯＭ９３０またはＨＤＤ９４０に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ９３０は、コンピュータ９００の起動時にＣＰＵ９１０によって実行されるブートプログラムや、コンピュータ９００のハードウェアに依存するプログラム等を格納する。
ＨＤＤ９４０は、ＣＰＵ９１０によって実行されるプログラム、および、かかるプログラムによって使用されるデータ等を格納する。ＨＤＤ９４０は、例えばＡＰＩ変換ＤＢ２０（図１参照）であってもよい。通信インターフェイス９５０は、通信網５０を介して他の機器からデータを受信してＣＰＵ９１０へ送り、ＣＰＵ９１０が生成したデータを通信網５０を介して他の機器へ送信する。
ＣＰＵ９１０は、入出力インターフェイス９６０を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ９１０は、入出力インターフェイス９６０を介して、入力装置からデータを取得する。また、ＣＰＵ９１０は、生成したデータを入出力インターフェイス９６０を介して出力装置へ出力する。
メディアインターフェイス９７０は、記録媒体９８０に格納されたプログラムまたはデータを読み取り、ＲＡＭ９２０を介してＣＰＵ９１０に提供する。ＣＰＵ９１０は、かかるプログラムを、メディアインターフェイス９７０を介して記録媒体９８０からＲＡＭ９２０上にロードし、ロードしたプログラムを実行する。記録媒体９８０は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phasechangerewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
例えば、コンピュータ９００が本実施形態に係るＡＰＩ変換装置１００として機能する場合、コンピュータ９００のＣＰＵ９１０は、ＲＡＭ９２０上にロードされたプログラムを実行することにより、ＡＰＩ変換装置１００の各部の機能を実現する。また、ＨＤＤ９４０には、ＡＰＩ変換装置１００の各部内のデータが格納される。コンピュータ９００のＣＰＵ９１０は、これらのプログラムを記録媒体９８０から読み取って実行するが、他の例として、他の装置から通信網５０を介してこれらのプログラムを取得してもよい。
［効果］
以上説明したように、ＡＰＩ変換装置１００は、サービス提供システム１０が提供するＡＰＩを記述する定義書であるＡＰＩ定義２１～２３、およびＡＰＩ変換機能のためのＡＰＩ変換プログラム２４を格納するＡＰＩ変換ＤＢ２０にアクセスするＡＰＩ変換ＤＢアクセス部１５０と、ＡＰＩを用いて制御可能な複数の制御対象サーバ３１～３３からなる管理対象システム３０のＡＰＩの版数保持していない場合、管理対象システム３０からＡＰＩの版数を取得するとともに、サービス提供システム１０のＡＰＩの版数と管理対象システム３０のＡＰＩの版数とが異なる場合、ＡＰＩ変換を指示するＡＰＩ版数管理部１２０と、ＡＰＩ版数管理部１２０からのＡＰＩ変換指示を受けて、ＡＰＩ変換ＤＢアクセス部１５０によりＡＰＩ定義２１～２３、およびＡＰＩ変換プログラム２４を取得して、受信したＡＰＩを新版数に変換し、ＡＰＩ変換プログラムが取得できなかった場合、取得した新旧の版数のＡＰＩ定義の差分を抽出し、新版数のＡＰＩ定義に新規パラメータが存在する場合、サービス提供システム１０に不足情報を要求するとともに、サービス提供システム１０から取得した不足情報と、ＡＰＩ変換ＤＢ２０から取得した新旧の版数のＡＰＩ定義２１～２３とに基づいて、新版数のＡＰＩ変換プログラム２５を生成し、ＡＰＩ定義２１～２３、およびＡＰＩ変換プログラム２５に基づいて、受信したＡＰＩを新版数に変換するＡＰＩ変換部１４０と、を備える。
以上説明したように、ＡＰＩ変換装置１００は、サービス提供システム１０が提供するＡＰＩを記述する定義書であるＡＰＩ定義２１～２３、およびＡＰＩ変換機能のためのＡＰＩ変換プログラム２４を格納するＡＰＩ変換ＤＢ２０にアクセスするＡＰＩ変換ＤＢアクセス部１５０と、ＡＰＩを用いて制御可能な複数の制御対象サーバ３１～３３からなる管理対象システム３０のＡＰＩの版数保持していない場合、管理対象システム３０からＡＰＩの版数を取得するとともに、サービス提供システム１０のＡＰＩの版数と管理対象システム３０のＡＰＩの版数とが異なる場合、ＡＰＩ変換を指示するＡＰＩ版数管理部１２０と、ＡＰＩ版数管理部１２０からのＡＰＩ変換指示を受けて、ＡＰＩ変換ＤＢアクセス部１５０によりＡＰＩ定義２１～２３、およびＡＰＩ変換プログラム２４を取得して、受信したＡＰＩを新版数に変換し、ＡＰＩ変換プログラムが取得できなかった場合、取得した新旧の版数のＡＰＩ定義の差分を抽出し、新版数のＡＰＩ定義に新規パラメータが存在する場合、サービス提供システム１０に不足情報を要求するとともに、サービス提供システム１０から取得した不足情報と、ＡＰＩ変換ＤＢ２０から取得した新旧の版数のＡＰＩ定義２１～２３とに基づいて、新版数のＡＰＩ変換プログラム２５を生成し、ＡＰＩ定義２１～２３、およびＡＰＩ変換プログラム２５に基づいて、受信したＡＰＩを新版数に変換するＡＰＩ変換部１４０と、を備える。
このようにすることにより、ＡＰＩ変換装置１００は、管理対象システムのＡＰＩの版数の違いを低コストに隠蔽し、サービス提供システムの管理コストを低減することができる。
より詳細には、ＡＰＩ変換装置１００は、ＡＰＩ定義（IdentityＡＰＩ ｖ１）２１～２３、およびＡＰＩ変換プログラム（IdentityＡＰＩ）２４を格納するＡＰＩ変換ＤＢ２０にアクセスするＡＰＩ変換ＤＢアクセス部１５０と、管理対象システムのＡＰＩの版数を保持しているか確認し、保持していない場合、管理対象システムからＡＰＩの版数を取得するとともに、サービス提供システムから受信したＡＰＩの版数（ｖ２）と管理対象システムのＡＰＩの版数（ｖ３）とを比較し、両者のＡＰＩの版数が異なる場合、ＡＰＩ変換部１４０にＡＰＩ変換を指示するＡＰＩ版数管理部１２０と、ＡＰＩ変換指示を受けて、ＡＰＩ変換ＤＢ２０からＡＰＩ定義（IdentityＡＰＩ ｖ２とｖ３）、およびＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）を取得するとともに、取得したＡＰＩ定義（Identity ＡＰＩ ｖ２とｖ３）、およびＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）に基づいて、受信したＡＰＩをｖ２からｖ３へ新版数に変換するＡＰＩ変換部１４０と、を備える。ＡＰＩ変換部１４０は、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を取得できなかった場合、ＡＰＩ定義（IdentityＡＰＩ ｖ２）とＡＰＩ定義（IdentityＡＰＩ ｖ３）の差分（diff）を抽出し、新版数（ｖ３）に新規パラメータが存在する場合、サービス提供システムに不足情報を要求し、サービス提供システム１０から取得した不足情報と、ＡＰＩ変換ＤＢ２０から取得したＡＰＩ定義（IdentityＡＰＩｖ２）２２およびＡＰＩ定義（IdentityＡＰＩｖ３）２３とに基づいて、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を生成する。
このように、ＡＰＩ変換装置１００は、ＡＰＩ変換プロセスを自動化可能な処理と人手を介在させるべき処理とに分類している。すなわち、ＡＰＩ変換部１４０において、ＡＰＩ変換のプロセスが、変換ルール生成・登録手順と、ＡＰＩ実行手順とに分けられている（図４参照）。このため、新版数（ｖ３）に新規パラメータが存在する場合、サービス提供システム１０から取得した不足情報を用いて、ＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５を生成することができる。これにより、効率的かつ柔軟なＡＰＩ変換が可能になる効果がある。例えば、複数の版数が混在し、版数毎にＡＰＩのバージョンが異なる場合であっても、ＡＰＩのバージョン違いを隠蔽することができ、ＶＮＮＦ、ＯＳＳ等を用いるサービス提供システム１０の管理コストを低減することができる。
また、ＡＰＩ変換装置１００において、ＡＰＩ変換ＤＢアクセス部１５０が、生成したＡＰＩ変換プログラム（IdentityＡＰＩ ｖ２→ｖ３）２５（新版数のＡＰＩ変換プログラム）をＡＰＩ変換ＤＢ２０に登録する。
これにより、他者が生成・登録したＡＰＩ変換プログラムを再利用可能になり、サービス提供システム１０の管理コストをより一層低減することができる。
［その他］
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。
１０ サービス提供システム
１０ａ 保守運用者
２０ ＡＰＩ変換ＤＢ（記憶部，記憶手段）
２１～２３ ＡＰＩ定義
２４，２５ ＡＰＩ変換プログラム
３０ 管理対象システム
３１～３３ サーバ（制御対象サーバ）
１１０ 外部システムＩＦ部
１２０ ＡＰＩ版数管理部
１３０ 管理対象システムＩＦ部
１４０ ＡＰＩ変換部
１５０ ＡＰＩ変換ＤＢアクセス部（アクセス部）
１０ａ 保守運用者
２０ ＡＰＩ変換ＤＢ（記憶部，記憶手段）
２１～２３ ＡＰＩ定義
２４，２５ ＡＰＩ変換プログラム
３０ 管理対象システム
３１～３３ サーバ（制御対象サーバ）
１１０ 外部システムＩＦ部
１２０ ＡＰＩ版数管理部
１３０ 管理対象システムＩＦ部
１４０ ＡＰＩ変換部
１５０ ＡＰＩ変換ＤＢアクセス部（アクセス部）
Claims (4)
- サービス提供システムが提供するＡＰＩ（Application Program Interface）を記述する定義書であるＡＰＩ定義、およびＡＰＩ変換機能のためのＡＰＩ変換プログラムを格納する記憶部にアクセスするアクセス部と、
ＡＰＩを用いて制御可能な複数の制御対象サーバからなる管理対象システムのＡＰＩの版数保持していない場合、前記管理対象システムからＡＰＩの版数を取得するとともに、前記サービス提供システムのＡＰＩの版数と前記管理対象システムのＡＰＩの版数とが異なる場合、ＡＰＩ変換を指示するＡＰＩ版数管理部と、
前記ＡＰＩ版数管理部からのＡＰＩ変換指示を受けて、前記アクセス部により前記ＡＰＩ定義、および前記ＡＰＩ変換プログラムを取得して、受信したＡＰＩを新版数に変換し、前記ＡＰＩ変換プログラムが取得できなかった場合、取得した新旧の版数の前記ＡＰＩ定義の差分を抽出し、新版数の前記ＡＰＩ定義に新規パラメータが存在する場合、前記サービス提供システムに不足情報を要求するとともに、前記サービス提供システムから取得した前記不足情報と、前記記憶部から取得した新旧の版数の前記ＡＰＩ定義とに基づいて、新版数の前記ＡＰＩ変換プログラムを生成し、前記ＡＰＩ定義、および前記ＡＰＩ変換プログラムに基づいて、受信したＡＰＩを新版数に変換するＡＰＩ変換部と、を備える
ことを特徴とするＡＰＩ変換装置。 - 前記アクセス部は、
生成した新版数の前記ＡＰＩ変換プログラムを前記記憶部に登録する
ことを特徴とする請求項１に記載のＡＰＩ変換装置。 - ＡＰＩ変換装置が実行するＡＰＩ変換方法であって、
アクセス部が、サービス提供システムが提供するＡＰＩ（Application Program Interface）を記述する定義書であるＡＰＩ定義、およびＡＰＩ変換機能のためのＡＰＩ変換プログラムを格納する記憶部にアクセスする工程と、
ＡＰＩ版数管理部が、ＡＰＩを用いて制御可能な複数の制御対象サーバからなる管理対象システムのＡＰＩの版数保持していない場合、前記管理対象システムからＡＰＩの版数を取得するとともに、前記サービス提供システムのＡＰＩの版数と前記管理対象システムのＡＰＩの版数とが異なる場合、ＡＰＩ変換を指示する工程と、
ＡＰＩ変換部が、前記ＡＰＩ版数管理部からのＡＰＩ変換指示を受けて、前記アクセス部により前記ＡＰＩ定義、および前記ＡＰＩ変換プログラムを取得して、受信したＡＰＩを新版数に変換し、前記ＡＰＩ変換プログラムが取得できなかった場合、取得した新旧の版数の前記ＡＰＩ定義の差分を抽出し、新版数の前記ＡＰＩ定義に新規パラメータが存在する場合、前記サービス提供システムに不足情報を要求するとともに、前記サービス提供システムから取得した前記不足情報と、前記記憶部から取得した新旧の版数の前記ＡＰＩ定義とに基づいて、新版数の前記ＡＰＩ変換プログラムを生成し、前記ＡＰＩ定義、および前記ＡＰＩ変換プログラムに基づいて、受信したＡＰＩを新版数に変換する工程と、有する
ことを特徴とするＡＰＩ変換方法。 - ＡＰＩ（Application Program Interface）サービスを提供するサービス提供システムと、ＡＰＩを用いて制御可能な複数の制御対象サーバからなる管理対象システムと、の間に設けられるＡＰＩ変換装置としてのコンピュータを、
サービス提供システムが提供するＡＰＩを記述する定義書であるＡＰＩ定義、およびＡＰＩ変換機能のためのＡＰＩ変換プログラムを格納する記憶手段にアクセスするアクセス手順、
ＡＰＩを用いて制御可能な複数の制御対象サーバからなる管理対象システムのＡＰＩの版数保持していない場合、前記管理対象システムからＡＰＩの版数を取得するとともに、前記サービス提供システムのＡＰＩの版数と前記管理対象システムのＡＰＩの版数とが異なる場合、ＡＰＩ変換を指示するＡＰＩ版数管理手順、
前記ＡＰＩ版数管理手順によるＡＰＩ変換指示を受けて、前記アクセス手順により前記ＡＰＩ定義、および前記ＡＰＩ変換プログラムを取得して、受信したＡＰＩを新版数に変換し、前記ＡＰＩ変換プログラムが取得できなかった場合、取得した新旧の版数の前記ＡＰＩ定義の差分を抽出し、新版数の前記ＡＰＩ定義に新規パラメータが存在する場合、前記サービス提供システムに不足情報を要求するとともに、前記サービス提供システムから取得した前記不足情報と、前記記憶手段から取得した新旧の版数の前記ＡＰＩ定義とに基づいて、新版数の前記ＡＰＩ変換プログラムを生成し、前記ＡＰＩ定義、および前記ＡＰＩ変換プログラムに基づいて、受信したＡＰＩを新版数に変換するＡＰＩ変換手順、
を実行させるためのプログラム。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP2019/024771 WO2020255389A1 (ja) | 2019-06-21 | 2019-06-21 | Ａｐｉ変換装置、ａｐｉ変換方法、およびプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2020255389A1 JPWO2020255389A1 (ja) | 2020-12-24 |
| JP7201087B2 true JP7201087B2 (ja) | 2023-01-10 |
Family
ID=74040408
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2021528608A Active JP7201087B2 (ja) | 2019-06-21 | 2019-06-21 | Ａｐｉ変換装置、ａｐｉ変換方法、およびプログラム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US11822982B2 (ja) |
| JP (1) | JP7201087B2 (ja) |
| WO (1) | WO2020255389A1 (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10761908B2 (en) * | 2018-10-30 | 2020-09-01 | Stoplight, Inc. | Distillation of various application interface data structures distributed over distinctive repositories to form a data source of consolidated application interface data components |
| US10970136B1 (en) * | 2019-10-03 | 2021-04-06 | Caret Holdings, Inc. | Adaptive application version integration support |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008293152A (ja) | 2007-05-23 | 2008-12-04 | Hitachi Ltd | Ｗｅｂシステムの連携方法および装置 |
| JP2015228086A (ja) | 2014-05-30 | 2015-12-17 | 株式会社リコー | 情報処理システム、情報処理装置、情報処理方法およびプログラム |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006164191A (ja) * | 2004-12-10 | 2006-06-22 | Matsushita Electric Ind Co Ltd | プログラム取得実行装置、プログラム取得実行方法、プログラム取得実行プログラム記録媒体、およびプログラム取得実行プログラム |
| GB0619147D0 (en) * | 2006-09-28 | 2006-11-08 | Ibm | A method, apparatus or software for managing software component version identifications in a componentised software system |
| US9910881B1 (en) * | 2013-12-12 | 2018-03-06 | Amazon Technologies, Inc. | Maintaining versions of control plane data for a network-based service control plane |
-
2019
- 2019-06-21 US US17/619,113 patent/US11822982B2/en active Active
- 2019-06-21 WO PCT/JP2019/024771 patent/WO2020255389A1/ja active Application Filing
- 2019-06-21 JP JP2021528608A patent/JP7201087B2/ja active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2008293152A (ja) | 2007-05-23 | 2008-12-04 | Hitachi Ltd | Ｗｅｂシステムの連携方法および装置 |
| JP2015228086A (ja) | 2014-05-30 | 2015-12-17 | 株式会社リコー | 情報処理システム、情報処理装置、情報処理方法およびプログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| US11822982B2 (en) | 2023-11-21 |
| WO2020255389A1 (ja) | 2020-12-24 |
| US20220276916A1 (en) | 2022-09-01 |
| JPWO2020255389A1 (ja) | 2020-12-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3531306B1 (en) | System for building and modeling web pages | |
| US8943496B2 (en) | Providing a hosted appliance and migrating the appliance to an on-premise environment | |
| US10158701B2 (en) | Method and system for providing a state model of an application program | |
| US9146755B2 (en) | System and method for transporting platform independent power configuration parameters | |
| US9851986B2 (en) | Application configuration in a virtual environment | |
| US10417027B1 (en) | Virtual machine proxy server for hyper-V image backup and recovery | |
| WO2022015855A1 (en) | Cloud data fake platform and saas orchestration | |
| US9032367B2 (en) | Providing a demo appliance and migrating the demo appliance to a production appliance | |
| US20130198637A1 (en) | Cloud service dashboard | |
| JP7097958B2 (ja) | 自動ユニバーサルコネクタパッケージを使用してクラウドアプリケーションをクラウドサービスブローカプラットフォームに統合するためのシステムおよび方法 | |
| JP7201087B2 (ja) | Ａｐｉ変換装置、ａｐｉ変換方法、およびプログラム | |
| Von Suchodoletz et al. | Towards emulation-as-a-service: cloud services for versatile digital object access | |
| US10834201B2 (en) | Device identification and reconfiguration in a network | |
| Hashizume et al. | Cloud service model patterns | |
| CN114416169A (zh) | 基于微前端的数据处理方法、介质、装置和计算设备 | |
| KR100693346B1 (ko) | 사용자별 맞춤형 가상 컴퓨팅 환경 제공 시스템 및 그 방법 | |
| Liebetraut et al. | Emulation-as-a-service-the past in the cloud | |
| US20200099749A1 (en) | Providing device specific security measures in the internet of things | |
| US20140189643A1 (en) | Methods for creating and providing a virtual environment and devices thereof | |
| JP5951702B2 (ja) | ファイルシステム、秘密分散サーバ、ファイル管理方法及びプログラム | |
| JP7332950B2 (ja) | サービス連携支援装置、サービス連携支援方法、および、サービス連携支援プログラム | |
| JP6852424B2 (ja) | アプリケーションサーバ、その方法及びプログラム | |
| Ludwig et al. | Implications of security mechanisms and Service Level Agreements (SLAs) of Platform as a Service (PaaS) clouds for geoprocessing services | |
| JP7284696B2 (ja) | 仮想デスクトップ提供システム | |
| KR100988111B1 (ko) | 터미널 환경의 서버 기반 컴퓨팅 시스템에서 많은 사용자가하나의 리소스 공유로 어플리케이션 실행이 불가능한 경우리소스 가상화를 통해 이를 실행하는 장치 및 그 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20211109 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20221122 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20221205 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 7201087 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |