JP2018081431A - プログラム部品管理装置および管理方法 - Google Patents

Abstract

【課題】所定の機能を実現するプログラム部品の実行に要する処理時間を実績値として管理し、プログラム部品の処理時間の推定に役立てることができるようにすること。【解決手段】プログラム部品管理装置としてのＡＰＩ管理システム１は、ＡＰＩを使用するために必要な情報を蓄積するデータ蓄積部１４と、クライアント３からの処理要求を受け付け、受け付けた処理要求がＡＰＩについての処理要求である場合は、データ蓄積部に蓄積された情報に基づいてＡＰＩ提供サーバ２へ処理要求を送信し、ＡＰＩの実行結果をサーバから受信すると、実行結果をクライアント３へ送信する要求処理部１３と、処理要求に係るＡＰＩの実行に要した処理時間を実績値として管理する実績値管理部１６を備える。【選択図】図１

Description

本発明は、プログラム部品管理装置および管理方法に関する。

あるソフトウェアの機能やデータを、他のソフトウェアから呼び出して利用するための規約をＡＰＩ（Application Programming Interface）と呼ぶ。コンピュータプログラムの開発者は、ＡＰＩを利用するための簡易なプログラムを記述するだけで、所望の機能およびデータを利用したソフトウェアを開発することができる。

近年では、自社の情報サービスが持つ機能、または管理しているデータを、通信ネットワークを通じて呼び出すことができるＡＰＩ（WebAPIとも呼ばれる）を公開する企業が増えている。自社の持つ機能やデータをＡＰＩを介して他社に提供することで、自社サービスの価値を向上させるビジネスモデルが広まりつつある。

ところで、ＡＰＩを通じて実行するジョブの中には、処理時間が長いものもある。さらに、ＡＰＩ提供サーバの混雑度合いによって、処理時間の変化が大きいものもある。このようにＡＰＩを利用した場合に要する処理時間の長さは様々であり、予測しにくい。そこで、ＡＰＩ利用者には、ＡＰＩを利用した場合の処理時間を正確に見積もりたいという要求がある。ＡＰＩを利用した場合の処理時間を正確に見積もることができれば、例えば、ＡＰＩを利用した大量の処理を含む作業計画を作成したり、同様の機能をもつ複数のＡＰＩのうち処理時間が短いＡＰＩを選択して効率を上げたりすることができる。

ＡＰＩの処理時間を予測する技術ではないが、ジョブの処理時間を推定する技術としては、特許文献１に記載の技術が知られている。特許文献１には、あらかじめ実行速度を測定するための通信を行い、その通信の応答時間と転送対象のデータ容量とを元に、データ転送完了に要する時間を算出する技術が開示されている。

特開２００５−３９４８１号公報

単純なデータ処理の場合は、処理時間とデータ容量とが強い相関を持つ単純なデータ処理であれば、特許文献１の技術も有効である。しかし、複雑なＡＰＩを用いるデータ処理や、複数のＡＰＩを使用する処理等では、処理時間は状況に応じて種々異なる。例えばデータ分析を行うＡＰＩの場合は、データの性質や分析アルゴリズムによって、処理時間は様々である。

また、例えばＶＭ（Virtual Machine）のような仮想環境を構築するＡＰＩの場合は、一般的に処理時間が長いため、ＡＰＩ提供側の混雑の度合いによる影響も受けやすい。つまり、処理時間の長いＡＰＩの場合、そのＡＰＩを提供するサーバの負荷などに起因して処理時間が増減する傾向にある。

このように、ＡＰＩ利用者から見ると、ＡＰＩの内部処理を考慮して処理時間を推定するのは難しい。さらに、ＡＰＩを利用する新しい情報サービスを開発する場合、複数のＡＰＩを組み合わせることで１つのジョブを実現することも多い。この場合、ジョブを構成する全てのＡＰＩの処理時間を推定する必要がある。

一部のＡＰＩは、処理状態を外部から確認する機能を提供している場合がある。しかし、複数の企業が公開するＡＰＩを連携させて利用する場合、それら全てのＡＰＩが処理状態を確認するための機能をそれぞれ提供している可能性は低く、現実的ではない。

本発明は上述の課題に鑑みてなされたもので、その目的は、所定の機能を実現するプログラム部品の実行に要する処理時間を実績値として管理することで、プログラム部品の処理時間の推定に役立てることができるようにしたプログラム部品管理装置および管理方法を提供することにある。本発明の他の目的は、プログラム部品の処理時間の実績値を適宜更新することで、処理時間を比較的正確に推定できるようにしたプログラム部品管理装置および管理方法を提供することにある。

上記課題を解決すべく、本発明の一つの観点に従うプログラム部品管理装置は、所定の機能を実現するプログラム部品を少なくとも一つ管理するプログラム部品管理装置であって、プログラム部品を使用するために必要な情報を蓄積するデータ蓄積部と、クライアントコンピュータからの処理要求を受け付け、受け付けた処理要求がプログラム部品についての処理要求である場合は、データ蓄積部に蓄積された情報に基づいてプログラム部品を提供するサーバコンピュータへ処理要求を送信し、プログラム部品の実行結果をサーバコンピュータから受信すると、実行結果をクライアントコンピュータへ送信する要求処理部と、処理要求に係るプログラム部品の実行に要した処理時間を実績値として管理する実績値管理部と、を備える。

本発明によれば、プログラム部品の実行に要した処理時間を実績値として管理するため、その実績値を利用することで、これから実行させようとするプログラム部品の処理時間の推定に役立てることができる。

ＡＰＩ管理システムを含む情報処理システムの全体構成図。 ＡＰＩ処理実績値の例。 ＡＰＩ定義データの例。 ＡＰＩ処理実績値の更新処理を示すフローチャート。 推定ＡＰＩリクエスト処理を示すフローチャート。 ＡＰＩ処理実績値の初期値登録の例。 ＡＰＩ処理実績値を通常の運用の中で更新する例。 第２実施例に係り、ＡＰＩ管理システムを含むシステム全体の構成図。 第３実施例に係り、ＡＰＩ管理システムを含むシステム全体の構成図。 ＡＰＩ定義データの例。 ＡＰＩリクエスト処理のフローチャート。 第４実施例に係り、複数のサーバがそれぞれ提供するＡＰＩを連携させる場合の模式図。 第５実施例に係るＡＰＩ管理システムで用いるＡＰＩ処理実績値の例。 第６実施例に係るＡＰＩ管理システムで用いるＡＰＩ処理実績値の例。

以下、図面に基づいて本発明の実施の形態を説明する。本実施形態では、所定の機能を実現するプログラム部品としてＡＰＩを用いる場合を説明する。以下、ＨＴＴＰ（Hypertext Transfer Protocol）の規約に従うＷｅｂＡＰＩを、ＡＰＩの例として述べる。

本実施形態では、ＡＰＩの処理時間の実績値を一つまたは複数の方法で管理することで、将来そのＡＰＩを使用する場合の処理時間の推定に役立てる。さらに本実施形態では、内部状態がブラックボックスである複数のサーバコンピュータがそれぞれ提供する複数のＡＰＩを使用する場合でも、処理時間の合計を推定することができる。さらに、本実施例では、ＡＰＩ利用者が使用を希望するＡＰＩの処理時間が、ＡＰＩ利用者の希望する時刻に間に合うか否かを判定し、その判定結果を通知する。さらに、本実施形態では、希望時刻に間に合うか否かの判定結果に応じて、ＡＰＩの実行を制御する。ＡＰＩの実行の制御には、ＡＰＩ実行のキャンセル、ＡＰＩの実行時期の調整などがある。

図１〜図７を用いて、ＡＰＩ管理システム１が、その管理下のＡＰＩ群の処理時間を推定する方式について説明する。

図１に示す情報処理システムは、「プログラム部品管理装置」としてのＡＰＩ管理システム１と、「サーバコンピュータ」としてのＡＰＩ提供サーバ２Ａ，２Ｂと、「クライアントコンピュータ」としてのクライアント３とを含む。

クライアント３は、例えばインターネットなどの適宜な通信網ＣＮ１を通じて、ＡＰＩ管理システム１と接続する。ＡＰＩ提供サーバ２Ａも、インターネット等の通信網ＣＮ２を通じて、ＡＰＩ管理システム１と接続している。同様に、ＡＰＩ提供サーバ２Ｂも、通信網ＣＮ３を通じて、ＡＰＩ管理システム１と接続している。特に区別しない場合、ＡＰＩ提供サーバ２Ａ，２ＢをＡＰＩ提供サーバ２と呼ぶ。さらに、ＡＰＩ提供サーバをサーバと略記する場合もある。クライアント３は複数でも構わないが、簡単のために１つのクライアント３を示す。

先にクライアント３の構成を説明した後、サーバ２の構成を説明する。その後にＡＰＩ管理システム１の構成を説明する。

クライアント３は、コンピュータ装置として構成されている。クライアント３は、例えば、通信部３１と、ＡＰＩリクエスト生成部３２とを含む。通信部３１は、ＡＰＩを利用するためのリクエストを送信し、そのレスポンスを受信する。ＡＰＩリクエスト生成部３２は、ＡＰＩを利用するリクエストを生成する。以下、ＡＰＩを使用するためのリクエストを、ＡＰＩリクエストまたはリクエストと呼ぶ。

クライアント３は、例えばスマートフォン等のような、通信部を備えたデバイスと、そのデバイスにインストールされたネイティブアプリケーション等とを含んで構成することができる。あるいは、インターネットに接続されたパーソナルコンピュータに、Ｗｅｂブラウザで動作するクライアントサイドアプリケーションをインストールすることで、クライアント３を構成してもよい。さらには、インターネットに接続されたサーバに、サーバサイドアプリケーションを実装することでクライアント３を構成してもよい。

ＡＰＩ提供サーバ２の構成を説明する。ＡＰＩ提供サーバ２Ａは、複数のＡＰＩ（ＡＰＩ−Ａ１，ＡＰＩ−Ａ２）を公開する。

ＡＰＩ提供サーバ２Ａは、例えば、通信部２１と、ＡＰＩ処理部２２とを含む。通信部２１は、各ＡＰＩへのリクエストを受信したり、そのリクエストに対するレスポンスをリクエスト送信元へ返信したりする。ＡＰＩ処理部２２は、各ＡＰＩへのリクエストを処理する。

通信部２１は、例えば、受信したリクエストを対応するＡＰＩ処理部２２へ転送するプログラムと、通信モジュールとを含んで構成される。ＡＰＩ処理部２２は、例えば、リクエストに応じた処理を実行し、その処理結果を通信部２１へ送信するコンピュータプログラムから構成することができる。

ＡＰＩ提供サーバ２Ｂは、ＡＰＩ提供サーバ２Ａとは別の独立したサーバとして構成されており、１つのＡＰＩ（ＡＰＩ−Ｂ１）を公開する。ＡＰＩ提供サーバ２Ｂは、ＡＰＩ提供サーバ２Ａと同様に、通信部２１とＡＰＩ処理部２２を備えている。

ＡＰＩ管理システム１の構成を説明する。ＡＰＩ管理システム１は、コンピュータ装置として構成されており、例えば、クライアント通信部１１、サーバ通信部１２、ＡＰＩリクエスト処理部１３、データ蓄積部１４、ＡＰＩ登録部１５、実績値管理部１６および推定ＡＰＩ処理部１７を備える。

クライアント通信部１１は、クライアント３と通信網ＣＮ１を介して双方向通信を行う機能である。クライアント通信部１１は、クライアント３からリクエスト（ＡＰＩリクエスト）を受信したり、リクエストに対するレスポンス（ＡＰＩレスポンス）をクライアント３へ送信したりする。クライアント通信部１１は、クライアント３からＡＰＩリクエストを受信したらＡＰＩリクエスト処理部１３に転送し、ＡＰＩリクエスト処理部１３からＡＰＩレスポンスを受信したらクライアント３に転送する、コンピュータプログラムと、通信モジュール（図示せず）とを備える。

サーバ通信部１２は、ＡＰＩ提供サーバ２Ａ，２Ｂと通信網ＣＮ２，ＣＮ３を介して双方向通信する機能である。サーバ通信部１２は、ＡＰＩ提供サーバ２Ａ，２ＢにＡＰＩリクエストを送信したり、ＡＰＩ提供サーバ２Ａ，２ＢからのＡＰＩレスポンスを受信したりする。サーバ通信部１２は、所定のコンピュータプログラムと、通信モジュール（図示せず）とを含む。所定のコンピュータプログラムは、ＡＰＩリクエスト処理部１３からＡＰＩリクエストを受信した場合はその宛先に応じてＡＰＩ提供サーバ２へ転送し、ＡＰＩ提供サーバ２からＡＰＩレスポンスを受信した場合はＡＰＩリクエスト処理部１３へ転送する。クライアント通信部１１とサーバ通信部１２とを合わせて、クライアント３やサーバ２と通信する通信部と呼ぶこともできる。

ＡＰＩリクエスト処理部は、「要求処理部」の例である。ＡＰＩリクエスト処理部１３は、例えば、受信したＡＰＩリクエストを適切な送信先へ振り分ける機能と、受信したＡＰＩレスポンスをクライアント通信部１１へ転送する機能と、ＡＰＩリクエストの処理に要する時間を実績値管理部１６へ送信する機能とを含む。

ＡＰＩリクエストの振り分け機能は、受信したＡＰＩリクエストの内容を解析し、そのＡＰＩリクエストに適した送信先に振り分ける。ＡＰＩレスポンスをクライアント通信部１１へ転送する機能は、ＡＰＩ管理システム１の内外で発生したＡＰＩレスポンスをクライアント通信部１１へ転送する。ＡＰＩ管理システム１の内部で発生するＡＰＩレスポンスとは、後述する推定ＡＰＩ処理部１７の出力するレスポンスである。ＡＰＩ管理システム１の外部で発生するＡＰＩレスポンスとは、ＡＰＩ提供サーバ２が送信するレスポンスである。

ＡＰＩリクエストの処理に要する時間を実績値管理部１６へ送信する機能は、例えば、ＡＰＩリクエストを送信先に振り分けた時刻（リクエスト送信時刻）と、そのＡＰＩリクエストに対応するＡＰＩレスポンスを受信した時刻（レスポンス受信時刻）とを、実績値管理部１６へ送る。

ＡＰＩリクエスト処理部１３は、上述の機能を実現するためのＡＰＩリクエスト処理用のコンピュータプログラムから構成される。ＡＰＩリクエスト処理用のコンピュータプログラムは、ＡＰＩリクエストを受信したら、その受信時刻を記録すると共に、データ蓄積部１４に蓄積されたＡＰＩ定義データＴ２を参照して、そのリクエストを適切な送信先へ振り分ける。さらに、ＡＰＩリクエスト処理用のコンピュータプログラムは、ＡＰＩレスポンスを受信したら、その受信時刻を記録すると共に、そのレスポンスをクライアント通信部１１に転送する。さらに、ＡＰＩリクエスト処理用のコンピュータプログラムは、ＡＰＩリクエスト受信の時刻とそれに対するレスポンス受信の時刻とを実績値管理部１６に送信する。上述したＡＰＩリクエスト処理用のコンピュータプログラムは、一つのコンピュータプログラムとして構成してもよいし、複数のコンピュータプログラムから構成してもよい。

上述の通り、本実施例におけるＡＰＩリクエストの振り分けには、ＡＰＩ管理システム１の外部への振り分けと、ＡＰＩ管理システム１の内部への振り分けとに分けることができる。ＡＰＩリクエスト処理部１３は、ＡＰＩリクエストが、ＡＰＩ提供サーバ２の提供するＡＰＩ（ＡＰＩ−Ａ１、ＡＰＩ−Ａ２、ＡＰＩ−Ｂ１）に対するものであれば、サーバ通信部１２へ転送する。ＡＰＩリクエスト処理部１３は、ＡＰＩリクエストが、ＡＰＩ管理システム１自身が提供するＡＰＩ（推定ＡＰＩ）に対するものであれば、推定ＡＰＩ処理部１７へ転送する。ＡＰＩリクエスト処理部１３は、ＡＰＩリクエストが、サーバ２の提供するＡＰＩまたはＡＰＩ管理システム１の提供する推定ＡＰＩのいずれでもない場合、クライアント通信部１１へエラーを送信する。

クライアント３からは、一連の処理として複数のＡＰＩを列挙したリクエストが送信される場合がある。その場合、ＡＰＩリクエスト処理部１３は、ＡＰＩ定義データＴ２を参照し、リクエスト内の記載順序に従って、各ＡＰＩリクエストを個別に処理する。

データ蓄積部１４は、例えば、ＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）などの記憶装置として構成することができる。データ蓄積部１４は、例えば、ＡＰＩの実行に要した処理時間であるＡＰＩ処理実績値Ｔ１と、ＡＰＩを使用するために必要な情報であるＡＰＩ定義データＴ２とを蓄積する。ＡＰＩ処理実績値Ｔ１およびＡＰＩ定義データＴ２の詳細は、図２，図３で後述する。ＡＰＩ処理実績値Ｔ１およびＡＰＩ定義データＴ２は、電子ファイルの形態で管理してもよいし、あるいは、データベースシステムで管理してもよい。

ＡＰＩ登録部１５は、ＡＰＩ管理システム１の管理するＡＰＩをＡＰＩ管理システム１へ登録する機能である。ＡＰＩ登録部１５は、ＡＰＩが登録されたことを実績値管理部１６に通知する機能も持つ。

ＡＰＩ登録部１５は、ＡＰＩ登録用のコンピュータプログラムから構成される。ＡＰＩ登録用のコンピュータプログラムは、ＡＰＩ提供者（例えばサーバ２を通じて提供される情報サービスの管理者）またはＡＰＩ管理システム１の管理者による操作を受けて、クライアント３に提供するＡＰＩの仕様などの情報を、データ蓄積部１４にＡＰＩ定義データＴ２として登録する。さらに、所定のコンピュータプログラムは、ＡＰＩが登録されたことを実績値管理部１６に通知する。

なお、ＡＰＩ管理システム１へのＡＰＩの登録は、例えば、ＡＰＩ登録部１５が提供する管理画面を用いてもよいし、設定用のファイルに記述してもよい。

実績値管理部１６は、ＡＰＩ管理システム１に登録された各ＡＰＩについて、それぞれのＡＰＩ処理実績値Ｔ１を生成したり更新したりする機能である。通常、ＡＰＩ管理システム１は、複数のＡＰＩを管理下におくため、以下、ＡＰＩ群と呼ぶことがある。

実績値管理部１６は、ＡＰＩ登録部１５からＡＰＩが登録された旨の通知を受けると、通知されたＡＰＩの仕様をデータ蓄積部１４に蓄積されたＡＰＩ定義データＴ２から取得する。実績値管理部１６は、通知されたＡＰＩのＡＰＩ処理実績値Ｔ１を、ＡＰＩリクエスト処理部１３と連携して生成する。さらに、実績値管理部１６は、各ＡＰＩへのリクエストを定期的に送信し、その応答時間を元にＡＰＩ処理実績値Ｔ１を更新する。さらに、実績値管理部１６は、クライアント３が通常利用において送信するＡＰＩリクエストの応答時間を元に、ＡＰＩ処理実績値Ｔ１を更新する。ＡＰＩ処理実績値Ｔ１の生成と更新の処理フローは後述する。

推定ＡＰＩ処理部１７は、「処理時間推定部」の例である。推定ＡＰＩ処理部１７は、指定されたＡＰＩの処理時間を推定し、その推定結果を出力する機能である。ＡＰＩ管理システム１は、ＡＰＩの処理時間を推定するための機能を推定ＡＰＩとして持つ。ＡＰＩ管理システム１は、その推定ＡＰＩをクライアント３に公開している。クライアント３が処理時間の推定を所望するＡＰＩを指定して、推定ＡＰＩへリクエストを送ると、推定ＡＰＩ処理部１７は推定ＡＰＩを用いて、指定されたＡＰＩの処理時間を推定する。推定ＡＰＩは、指定されたＡＰＩについてＡＰＩ処理実績値Ｔ１を参照することで、指定されたＡＰＩの処理に要する時間を推定する。推定ＡＰＩ処理部１７は、推定結果をレスポンスとして、クライアント通信部１１からクライアント３へ送信する。推定ＡＰＩ処理部１７は、上述した機能を実現するための推定ＡＰＩ処理用のコンピュータプログラムから構成されている。処理時間を推定する処理フローは後述する。

図２は、ＡＰＩ処理実績値Ｔ１のデータ構造例を示す。ＡＰＩ処理実績値Ｔ１は、例えば、ＡＰＩ毎（Ｃ１１）、時間帯毎に（Ｃ１２）、そのＡＰＩの応答時間（Ｃ１３）を対応付けたリストである。図２では、１時間毎に平均応答時間を管理する。これに限らず、１時間未満または１時間を超えた時間単位で平均応答時間を管理することもできる。

ＡＰＩの応答時間とは、ＡＰＩリクエスト処理部１３がリクエストを受信した時刻から、そのリクエストに対するレスポンスを受信した時刻までの時間とする。図２の例では、ＡＰＩ−Ａ１は、１日の中でも昼から夕方にかけて平均応答時間が遅くなっている。これは、ＡＰＩ−Ａ１が企業の業務に関わるものである場合に特徴的な傾向である。

図２中のＡＰＩ−Ａ２の平均応答時間は約３０分である。このように時間のかかるＡＰＩの場合は、通常、非同期処理が行われている。つまり、ＡＰＩ−Ａ２のリクエストをＡＰＩ提供サーバ２Ａが受信すると、そのリクエストに対応する処理が完了する前に、そのリクエストを正常に受け付けたことだけを先にレスポンスとしてリクエスト元へ送信する、という処理が行われる。リクエストの受け付けを示すレスポンスをリクエスト元に送信した後、ＡＰＩが実行されて処理結果がリクエスト元へ送信される。

このような非同期処理を行うＡＰＩの場合、その処理が実際に完了したか否かを確認する必要がある。ＡＰＩ管理システム１は、処理状態（処理中、完了、エラー等）を取得するＡＰＩを適宜実行することで、非同期処理を行うＡＰＩの処理状態を取得することができる。処理状態を取得するＡＰＩは、非同期処理に対応したＡＰＩが同時に提供していることが多い。あるいは、ＡＰＩの処理完了をプッシュ通知または電子メールで通知する機能をＡＰＩ提供サーバ２が備えている場合、ＡＰＩ管理システム１は、サーバ２の持つ通知機能を利用してもよい。本実施例のＡＰＩリクエスト処理部１３は、処理状態を取得するためのＡＰＩ、またはサーバ２の持つ通知機能などを用いることで、ＡＰＩの処理完了に対応する時刻を取得できるものとする。

図３は、ＡＰＩ定義データＴ２の例を示す。ＡＰＩ定義データＴ２は、例えば、ＡＰＩ毎に（Ｃ２１）、ＡＰＩ利用者への公開仕様（Ｃ２２）と、それに対応したＡＰＩ提供者の内部仕様（Ｃ２３）と、ヘッダやペイロードのパラメタ（Ｃ２４）とをまとめたリストである。

本実施例では、ＡＰＩ提供者の提供するＡＰＩとしてＡＰＩ−Ａ１、ＡＰＩ−Ａ２、ＡＰＩ−Ｂ１が、ＡＰＩ管理システム１が提供するＡＰＩとして推定ＡＰＩが、ＡＰＩ定義データＴ２にそれぞれ定義されている。

ＡＰＩ定義データＴ２によれば、ＡＰＩ提供者の提供するＡＰＩに対するＡＰＩリクエストは、ＡＰＩ管理システム１からＡＰＩ提供サーバ２へ転送される。同様にＡＰＩ定義データＴ２によれば、ＡＰＩ管理システム１の提供する推定ＡＰＩに対するＡＰＩリクエストは、ＡＰＩ管理システム１の内部の推定ＡＰＩ処理部１７へ転送される。

上述の通り、一連の処理として、複数のＡＰＩを列挙したリクエストが送信される場合もある。その場合のリクエスト方法や内部での処理方法は、ＡＰＩ定義データＴ２の下側に示すように、「複数ＡＰＩ」の項目として定義されている。ＡＰＩリクエスト処理部１３は、複数ＡＰＩのリクエストを受信すると、まず「複数ＡＰＩ」の定義を参照し、その定義に従って当該リクエストから個別ＡＰＩリクエストをそれぞれ抽出し、それぞれの個別ＡＰＩの定義を参照する。

図４は、実績値管理部１６によるＡＰＩ処理実績値の生成および更新の処理を示すフローチャートである。ここでは、ＡＰＩ提供サーバ２Ａの提供するＡＰＩ−Ａ１，ＡＰＩ−Ａ２がＡＰＩ管理システム１に登録されている状況下で、ＡＰＩ提供サーバ２Ｂの提供するＡＰＩ−Ｂ１を新規ＡＰＩとして登録する際の、ＡＰＩ処理実績値Ｔ１の生成と更新を説明する。

ＡＰＩ−Ｂ１を提供する情報サービス（ＡＰＩ提供サーバ２Ｂ）の管理者、またはＡＰＩ管理システム１の管理者は、ＡＰＩ−Ｂ１の仕様を、ＡＰＩ登録部１５を通じてデータ蓄積部１４へ登録する。ＡＰＩ−Ｂ１の仕様を定義するデータは、ＡＰＩ定義データＴ２に追記される（Ｓ１０）。

ＡＰＩ登録部１５は、新規ＡＰＩであるＡＰＩ−Ｂ１が登録されたことを、実績値管理部１６へ通知する。その通知を受けた実績値管理部１６は、データ蓄積部１４内のＡＰＩ定義データＴ２を参照し、ＡＰＩ−Ｂ１の定義を取得する。

実績値管理部１６は、ＡＰＩ定義データＴ２から取得したＡＰＩ−Ｂ１の定義を元に、ＡＰＩ−Ｂ１に対するＡＰＩリクエストを生成し、ＡＰＩリクエスト処理部１３に送信する（Ｓ１１）。実績値管理部１６がＡＰＩリクエストを生成して、ＡＰＩリクエスト処理部１３から送信させる処理を、ここではテスト実行と呼ぶ。

ＡＰＩリクエスト処理部１３は、実績値管理部１６からＡＰＩリクエストを受け取ると、そのＡＰＩリクエストをＡＰＩ提供サーバ２Ｂへ転送する。ＡＰＩリクエスト処理部１３は、送信したＡＰＩリクエストに対応するＡＰＩレスポンスを受信すると、そのＡＰＩレスポンスをリクエスト送信元である実績値管理部１６へ転送する。

このとき、ＡＰＩリクエスト処理部１３は、実績値管理部１６からＡＰＩリクエストを受信した時刻と、対応するレスポンスをＡＰＩ提供サーバ２Ｂから受信した時刻とを、実績値管理部１６へ送信する。

実績値管理部１６は、ＡＰＩリクエスト処理部１３から受け取った、ＡＰＩリクエスト受信時刻およびＡＰＩレスポンス受信時刻を元に、テスト実行の応答時間を算出し、図６に示すようなＡＰＩ処理実績値Ｔ１（１）を記録する。

実績値管理部１６は、テスト実行を、レスポンス受信後の一定時間経過後（図６の例では１０分経過後）に再実行することを、例えば１日間繰り返す。これにより、実績値管理部１６は、新規登録されたＡＰＩ−Ｂ１の応答時間の、１日間の時間帯毎の変動を記録することができる。

ところで、ＡＰＩ提供サーバ２Ｂでは、実績値管理部１６によるテスト実行以外にも、図外の他の経路から同じＡＰＩ−Ｂ１が利用されていたり、あるいは、ＡＰＩ提供サーバ２Ｂが図外の他のＷｅｂブラウザから利用されていたりする可能性がある。ＡＰＩ提供サーバ２は、ＡＰＩ管理システム１の専用のサーバであるとは限らず、図１に示すクライアント３以外のクライアントからも適宜利用される。このため、ＡＰＩ−Ｂ１の応答時間は、時間毎に変化する可能性が高い（Ｓ１１）。

実績値管理部１６は、指定期間（例えば１日間）のテスト実行後、ＡＰＩ処理実績値Ｔ１（１）について時間帯毎の平均応答時間を算出し、算出した平均応答時間をＡＰＩ−Ｂ１の処理実績値の初期値として、ＡＰＩ処理実績値Ｔ１に登録する（Ｓ１２）。

なお、リクエスト受信時刻とレスポンス受信時刻とが２つ以上の時間帯にまたがっているサンプルについては、リクエスト受信時刻が含まれる時間帯のサンプルとしてもよいし、レスポンス受信時刻が含まれる時間帯のサンプルとしてもよいし、あるいは処理時間が含まれる割合が多い時間帯のサンプルとしてもよい。ただし、扱い方は全体として統一するものとする。

新規ＡＰＩに対するＡＰＩ処理実績値の生成および登録が完了するまでは（Ｓ１０〜Ｓ１２）、新規ＡＰＩの公開準備期間として非公開とする方が運用面で好適である。

ステップＳ１０〜Ｓ１２の新規ＡＰＩについてのＡＰＩ処理実績値の初期値登録の次に、ＡＰＩの通常運用Ｓ１３へ移行する。

ＡＰＩの通常運用では、以下に述べるステップＳ１４〜Ｓ１６を実行する。ステップＳ１４〜Ｓ１６では、ＡＰＩ通常運用時における、ＡＰＩ処理実績値Ｔ１の更新方法について説明する。

実績値管理部１６は、ステップＳ１１と同様に、まずＡＰＩ処理実績値（実測）を記録し、それを用いて定期的に、ＡＰＩ処理実績値Ｔ１を更新する。ＡＰＩの通常運用時とは、ＡＰＩ管理システム１に登録されたＡＰＩ群（ＡＰＩ−Ａ１、ＡＰＩ−Ａ２、ＡＰＩ−Ｂ１）を、クライアント３が任意のタイミングで利用する状態のことを指す。

ＡＰＩ通常運用時には、クライアント３から任意のタイミングでＡＰＩリクエストが発行される（Ｓ１４）。この他に、必須ではないが、実績値管理部１６からも定期的に各ＡＰＩへのリクエストを送信してもよい（Ｓ１５）。通常運用において、実績値管理部１６が各ＡＰＩをテスト実行することを、ここではシステム同定処理と呼ぶ。

ステップＳ１５でのＡＰＩリクエストの送信は、ステップＳ１１のテスト実行と同様であるが、ＡＰＩリクエストを送信する際の時間間隔は、ステップＳ１１での時間間隔よりも長くしてもよい。ステップＳ１５では、例えば、レスポンス受信後から３０分経過後等の周期で、ＡＰＩリクエストを発行することができる。ステップＳ１４およびステップＳ１５は並行して行われるステップである。これにより、例えば図７に示すような、ＡＰＩ処理実績値Ｔ１（２）が記録される。

実績値管理部１６は、各ＡＰＩの処理実績値を更新する（Ｓ１６）。実績値管理部１６は、例えば１日毎に、各ＡＰＩの応答時間がそれぞれ１日分ずつ記録されたＡＰＩ処理実績値Ｔ１（２）に対して、ＡＰＩ毎、時間帯毎の平均値を算出する。そして、実績値管理部１６は、ＡＰＩ処理実績値Ｔ１（２）で求めた各々の値と、ＡＰＩ処理実績値Ｔ１の対応するＡＰＩ、対応する時間帯の値との平均値を算出して、ＡＰＩ処理実績値Ｔ１を新しい平均値で更新する。

実績値管理部１６がステップＳ１４〜Ｓ１６を繰り返すことによって、ＡＰＩ処理実績値Ｔ１の時間帯毎の傾向は、ＡＰＩの利用状況をより反映した形で更新される。しかし、ＡＰＩの種類、すなわち情報サービスの種類によっては、ＡＰＩリクエストの応答時間は、時間帯だけでなく、曜日によっても傾向が異なる可能性が高い。例えば、業務サービスのＡＰＩでは、最初の平日である月曜日は利用者が少ないため、応答時間は短い。これに対し、最後の平日である金曜日は利用者が多いため、応答時間が長くなる。さらに、週末の土曜日と日曜日は利用者が殆どいないため、応答時間が月曜日よりも短い、ということも考えられる。

ＡＰＩの利用状況が曜日によって異なる傾向を示す場合、ＡＰＩ処理実績値Ｔ１を曜日を問わずに更新してしまうと、そのような傾向は表現することができない。従って、曜日の影響を受ける可能性があるＡＰＩの場合には、曜日毎のＡＰＩ処理実績値（すなわち合計７個）を蓄積しておき、次の週には、前の週の同じ曜日のＡＰＩ処理実績値を更新するようにするとよい。つまり、曜日毎にＡＰＩ処理実績値を計算して更新すればよい。

曜日毎の傾向があるかどうかが事前に判別しにくい場合は、毎日更新するＡＰＩ処理実績値Ｔ１とは別に、曜日毎のＡＰＩ処理実績値を作成しておき、１週間後に、７個のＡＰＩ処理実績値の、同じ時間帯の値の曜日毎の変動を確認するとよい。なお、月単位、四半期単位、期単位で傾向が出るＡＰＩもあり得るが、週単位（曜日毎）の場合と考え方は同じである。

図５は、推定ＡＰＩリクエスト処理のフローチャートである。ここでは、一連の処理としてＡＰＩ−Ａ１、ＡＰＩ−Ａ２、ＡＰＩ−Ｂ１を順に実行する場合の、全体の処理時間の推定方法を説明する。

クライアント３は、ＡＰＩ管理システム１が提供する推定ＡＰＩを利用するためのＡＰＩリクエストを生成し、ＡＰＩ管理システム１へ送信する（Ｓ２０）。推定ＡＰＩのリクエストの記述方法は、図３に示すＡＰＩ定義データＴ２の「推定ＡＰＩ」に従う。

ＡＰＩ管理システム１のクライアント通信部１１は、推定ＡＰＩのリクエストを受信すると、ＡＰＩリクエスト処理部１３へ転送する。ＡＰＩリクエスト処理部１３は、クライアント通信部１１からリクエストを受信すると、データ蓄積部１４のＡＰＩ定義データＴ２を参照し、そのリクエストに対応するＡＰＩを特定する。ＡＰＩリクエスト処理部１３は、推定ＡＰＩへのリクエストであることを知ると、そのリクエストを推定ＡＰＩ処理部１７へ転送する（Ｓ２１）。

推定ＡＰＩ処理部１７は、ＡＰＩリクエスト処理部１３からリクエストを受信すると、推定対象のＡＰＩ群とその実行順序（ＡＰＩ−Ａ１→ＡＰＩ−Ａ２→ＡＰＩ−Ｂ１）とを抽出する。

推定ＡＰＩ処理部１７は、データ蓄積部１４のＡＰＩ処理実績値Ｔ１を参照し、１番目のＡＰＩであるＡＰＩ−Ａ１の、推定ＡＰＩリクエスト受信時刻に対応する時間帯での、平均応答時間（時間Ａ１とする）を取得する。推定ＡＰＩ処理部１７は、２番目のＡＰＩであるＡＰＩ−Ａ２に対して、推定ＡＰＩリクエスト受信時刻に、時間Ａ１を足した時刻に対応する時間帯での、平均応答時間（時間Ａ２とする）を取得する。推定ＡＰＩ処理部１７、３番目のＡＰＩであるＡＰＩ−Ｂ１に対して、推定ＡＰＩリクエスト受信時刻に、時間Ａ１と時間Ａ２とを足した時刻に対応する時間帯での、平均応答時間（時間Ｂ１とする）を取得する。推定ＡＰＩ処理部１７は、これら３つの時間の合計（＝時間Ａ１＋時間Ａ２＋時間Ｂ１）を、推定対象ＡＰＩ群の合計処理時間として推定する（Ｓ２２）。

なお、推定ＡＰＩへのリクエストは、ＡＰＩ通常運用時に実行されるため、図７に示すＡＰＩ処理実績値Ｔ１（２）を同時に参照し、その日の傾向を更に反映することも可能である。

例えば、推定対象であるＡＰＩの、推定ＡＰＩリクエスト受信時刻の少し前の時間帯での応答時間をＡＰＩ処理実績値Ｔ１（２）から取得し、ＡＰＩ処理実績値Ｔ１の同時間帯の平均応答時間と比較する。比較の結果、その日は全般的に１．１倍程度遅い傾向が見られるのであれば、推定ＡＰＩ処理部１７は、ＡＰＩ処理実績値Ｔ１の平均応答時間を１．１倍した値を、推定時間として算出する（Ｓ２２）。

推定ＡＰＩ処理部１７は、推定結果をレスポンスに設定してＡＰＩリクエスト処理部１３へ送信する。ＡＰＩリクエスト処理部１３は、推定ＡＰＩ処理部１７から受け取ったレスポンスを、クライアント通信部１１からクライアント３へ送信する（Ｓ２３）。

推定ＡＰＩ処理部１７の出力する推定結果には、ステップＳ２２で算出した処理時間と、その処理時間を推定ＡＰＩリクエスト受信時刻に足した時刻（すなわち処理完了時刻）とが含まれる。

このように構成される本実施例によれば、ＡＰＩの実行に要した処理時間を実績値として管理するため、その実績値を利用することで、これから実行させようとするＡＰＩの処理時間を推定することができる。

本実施例によれば、一つ以上のＡＰＩの処理に要する時間を推定できるため、ＡＰＩ利用者は、ＡＰＩリクエストを発行する前にＡＰＩ処理に要する時間を把握することができ、処理完了時刻などを知ることができ、使い勝手が向上する。

本実施例によれば、ＡＰＩ処理実績値Ｔ１を管理するため、ＡＰＩ提供サーバ２の仕様や性能が不明な場合でも、そのサーバ２で提供されているＡＰＩの処理に要する時間を、容易かつ正確に推定することができる。

本実施例では、ＡＰＩの処理時間を推定するプログラム部品を推定ＡＰＩとしてクライアント３に公開するため、クライアント３は、通常のＡＰＩを利用する場合と同様にして、ＡＰＩの処理に要する時間を知ることができ、使い勝手がよい。

本実施例では、ＡＰＩの通常運用時における処理時間の実績値を用いて、ＡＰＩ処理実績値Ｔ１を更新するため、最新の値をＡＰＩ処理実績値Ｔ１に保持することができ、推定精度を維持することができる。

本実施例では、ＡＰＩの通常運用時において、各ＡＰＩの全部または一部に対してテスト実行を行うことができるため、利用頻度の少ないＡＰＩについてもその処理時間の実測値を得ることができ、推定精度を維持することができる。

図８を用いて第２実施例を説明する。本実施例を含む以下の各実施例は、第１実施例の変形例に相当するため、第１実施例との相違を中心に述べる。本実施例では、ＡＰＩ管理システム１Ａが管理しているＡＰＩ群の利用状況をＡＰＩ管理システム１Ａから発信する方式について説明する。

図８は、ＡＰＩ管理システム１Ａを含む情報処理システムの構成図である。本実施例のＡＰＩ管理システム１Ａは、図１に示すＡＰＩ管理システム１に比べて、利用状況生成部１８を備えている。

利用状況生成部１８は「利用状況出力部」の例である。利用状況生成部１８は、利用状況生成用のコンピュータプログラムから構成される。利用状況生成用のコンピュータプログラムは、ＡＰＩ管理システム１Ａの管理する各ＡＰＩに対する推定ＡＰＩリクエストを生成して、ＡＰＩリクエスト処理部１３へ送信する。そして、利用状況生成用のコンピュータプログラムは、各ＡＰＩに対する推定ＡＰＩ処理部１７からのレスポンスをＡＰＩリクエスト処理部１３を介して受信すると、ＡＰＩ毎に、その時点における推定処理時間および推定完了時刻を列挙したリストデータまたは画面を生成する。

ＡＰＩの利用状況を示す画面の例としては、例えば、ＡＰＩ管理システム１Ａの管理しているＡＰＩ群を一覧で表示するマーケットプレイス、ＡＰＩ管理システム１が管理しているＡＰＩ群の利用者や提供者のためのポータル等を挙げることができる。さらに、その画面では、各ＡＰＩに関する情報の一部として、上記の推定処理時間や推定完了時刻を付記するとよい。

各ＡＰＩに対する推定ＡＰＩリクエストの生成処理と、その結果を受けた画面更新処理とは、ＡＰＩ管理システム１Ａが定期的に行ってもよいし、あるいは、上述した画面の閲覧者による利用状況取得操作に応じて行ってもよい。利用状況取得操作は、画面に対する操作ではなく、推定ＡＰＩと同様に、ＡＰＩ管理システム１Ａが提供する利用状況取得ＡＰＩへのリクエストによって行えるようにしてもよい。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例では、管理対象のＡＰＩ群の利用状況を算出して提示することができるため、より一層ＡＰＩの使い勝手が向上する。

図９〜図１１を用いて第３実施例を説明する。本実施例では、ＡＰＩを使用する際に希望納期を設定できるようにしている。希望納期は「希望時刻」に該当する。

図９は、ＡＰＩ管理システム１Ｂを含む情報処理システムの構成図である。本実施例のＡＰＩ管理システム１Ｂは、図１に示すＡＰＩ管理システム１に比べて、ＡＰＩリクエストキュー１９を追加した点と、ＡＰＩ定義データＴ２Ｂおよび処理フローが一部異なる点で相違する。

図１０は、ＡＰＩ定義データＴ２Ｂの構造を示す。本実施例のＡＰＩ定義データＴ２Ｂは、図３で示したＡＰＩ定義データＴ２と比較して、各ＡＰＩのパラメタＣ２４Ｂに希望納期を追加した点で異なる。このＡＰＩ定義データＴ２Ｂもデータ蓄積部１４に蓄積されている。

希望納期は、一例として「ｔｉｍｅｌｉｍｉｔ＝ｙｙｙｙｍｍｄｄｈｈｍｍ」という形式で、ＵＲＬパラメタに指定している。例えば、希望納期が２０１６年６月２９日の１７時３０分であれば、「ｔｉｍｅｌｉｍｉｔ＝２０１６０６２９１７３０」となる。希望納期を指定する目的はＡＰＩによって異なる。推定ＡＰＩへのリクエストに希望納期を指定する場合は、第１実施例に示した処理時間の推定結果に加えて、希望納期に間に合うか否かの判定結果と、間に合うと判定した場合はいつまでにそのリクエストを送信する必要があるかという情報とが、そのリクエストに対するレスポンスに含まれる。

これに対し、通常ＡＰＩ（ＡＰＩ−Ａ１、ＡＰＩ−Ａ２、ＡＰＩ−Ｂ１、および複数ＡＰＩ）へのリクエストに希望納期を指定する場合は、その通常ＡＰＩに対する処理時間を推定し、推定結果が希望納期に間に合わなければ、その通常ＡＰＩへのリクエストを自動的にキャンセルする。クライアント３からのＡＰＩリクエストには、通常は費用が発生するため、納期に間に合わないＡＰＩリクエストは自動的にキャンセルすることで、ＡＰＩ利用者の費用負担を軽減する。

図１１は、希望納期を指定したＡＰＩリクエスト処理のフローチャートである。本処理は、希望納期を推定ＡＰＩに指定する場合と、通常ＡＰＩに指定する場合の、両方を含んでいる。

ＡＰＩリクエスト処理部１３は、クライアント３からのＡＰＩリクエストをクライアント通信部１１経由で受信する（Ｓ３０）。ＡＰＩリクエスト処理部１３は、受信したＡＰＩリクエストが、推定ＡＰＩに対するリクエストであるか判定する（Ｓ３１）。

ＡＰＩリクエスト処理部１３は、ステップＳ３０で受信したＡＰＩリクエストが推定ＡＰＩに対するリクエストであると判定すると（Ｓ３１：ＹＥＳ）、そのＡＰＩリクエストを推定ＡＰＩ処理部１７へ転送する（Ｓ３２）。

推定ＡＰＩ処理部１７は、ＡＰＩリクエスト処理部１３から受領したＡＰＩリクエストを処理する（Ｓ３３）。詳しくは、推定ＡＰＩ処理部１７は、ＡＰＩリクエストのパラメタに希望納期が指定されているかどうか判別し、指定されていない場合は、第１実施例で述べた処理時間の推定を行う。すなわち、推定ＡＰＩ処理部１７は、ＡＰＩリクエストを受信した時刻を起点として、処理時間を推定する。

ＡＰＩリクエストのパラメタに希望納期が指定されている場合、処理の起点をいつに設定するかによって推定方式が異なる。単純にリクエスト受信時の時刻を処理の起点とする場合は、第１実施例で示した方式で、処理完了時刻を推定し、希望納期との前後関係を判定すればよい。

但し、処理時間推定に用いるＡＰＩ処理実績値Ｔ１は、ＡＰＩによっては、時間帯毎に応答時間が大きく異なる可能性がある。例えば、リクエスト受信時の時刻を処理の起点とすると希望納期に間に合わないが、少し後の時刻を処理の起点とすると希望納期に間に合う可能性がある。

そのように極端な応答時間の変化が発生することは少ないと考えられるが、複数のＡＰＩを一連の処理とする場合など、汎用的な利用を考えるならば、処理の起点を一定間隔で後ろ倒ししながら、処理時間推定を行うとよい。

そのような方式とすることで、希望納期に間に合うためにはどの時刻から処理を開始するか、すなわちＡＰＩリクエストをいつ送信する必要があるか、という「リクエスト推奨時刻」もレスポンスに含むことができる。推定ＡＰＩ処理部１７は、以上のような推定処理を行う。推定ＡＰＩ処理部１７は、希望納期に間に合わない場合、希望納期に間に合わない旨と、現時点を処理の起点とした場合の推定処理時間と、推定完了時刻とをＡＰＩレスポンスに設定して、ＡＰＩリクエスト処理部１３へ送信する。

推定ＡＰＩ処理部１７は、希望納期に間に合うと判定した場合、希望納期に間に合う旨と、現時点を処理の起点とした場合の推定処理時間と、推定完了時刻（現時点を処理の起点とすると間に合わない場合は、そのことも記載）と、リクエスト推奨時刻と、推奨時刻でリクエストを発行した場合の推定処理時間とをＡＰＩレスポンスに設定し、ＡＰＩリクエスト処理部１３へ送信する。

リクエスト推奨時刻が複数ある場合は、例えば推定処理時間が短い順に上位３件を設定するなど、限定してもよい（Ｓ３３）。

ＡＰＩリクエスト処理部１３は、ステップＳ３１において、受信したＡＰＩリクエストが推定ＡＰＩへのものではない、すなわち通常ＡＰＩに対するリクエストであると判定すると（Ｓ３１：ＮＯ）、そのＡＰＩリクエストに希望納期が指定されているかどうか判定する（Ｓ３４）。

ＡＰＩリクエスト処理部１３は、通常ＡＰＩに対するリクエストに希望納期が指定されていないと判定すると（Ｓ３４：ＮＯ）、通常ＡＰＩの通常利用であるため、そのリクエストをサーバ通信部１２へ転送する（Ｓ３５）。サーバ通信部１２は、受領したＡＰＩリクエストを、対応するＡＰＩを有するサーバ２へ送信する。

これに対し、ＡＰＩリクエスト処理部１３は、通常ＡＰＩに対するリクエストに希望納期が指定されている場合（Ｓ３４：ＹＥＳ）、そのＡＰＩリクエストの処理時間を推定させるべく、推定ＡＰＩに対するリクエストを生成して、推定ＡＰＩ処理部１７へ転送する（Ｓ３６）。推定ＡＰＩに対するリクエストは、指定された希望納期を含む。

推定ＡＰＩ処理部１７は、ステップＳ３３と同様の推定処理を行う（Ｓ３７）。ＡＰＩリクエスト処理部１３は、推定ＡＰＩ処理部１７から受信したレスポンスを元に、通常ＡＰＩへのリクエストが希望納期に間に合うかどうかを確認する（Ｓ３８）。

ＡＰＩリクエスト処理部１３は、通常ＡＰＩへのリクエストが希望納期に間に合うと判定すると（Ｓ３８：ＹＥＳ）、そのＡＰＩリクエストをサーバ通信部１２へ転送する。但し、現時点を処理の起点とすると間に合わない場合には、ＡＰＩリクエスト処理部１３は、リクエスト推奨時刻になるまでＡＰＩリクエストキュー１９に蓄積し、リクエスト推奨時刻になってからサーバ通信部１２へ転送する（Ｓ３９）。ステップＳ３９では、リクエスト推奨時刻になるのを待ってＡＰＩリクエストをサーバ通信部１２へ転送することを、適切なタイミングでリクエストをサーバ通信部へ転送する、と表現している。

ＡＰＩリクエスト処理部１３は、通常ＡＰＩへのリクエストが希望納期に間に合わないと判定すると（Ｓ３８：ＮＯ）、通常ＡＰＩへのリクエストをキャンセルし、所定の情報をクライアント３へ通知させる（Ｓ４０）。すなわち、ＡＰＩリクエスト処理部１３は、キャンセルした旨と、推定ＡＰＩからのレスポンス内容（希望納期に間に合わない旨、推定処理時間、推定完了時刻）とを、通常ＡＰＩへのリクエストに対するレスポンスに設定し、クライアント通信部１１へ転送する（Ｓ４０）。

このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例では、ＡＰＩリクエストのパラメタに希望納期を設定することができるため、より一層ＡＰＩの使い勝手を向上することができる。

本実施例では、推定ＡＰＩに対するリクエストに希望納期が含まれている場合、リクエスト推奨時刻と、リクエスト推奨時刻にＡＰＩリクエストを発行した場合の推定処理時間などをレスポンスに含めることができる。これにより、ＡＰＩ利用者は、いつまでにリクエストを発行すればよいか等を事前に知ることができ、使い勝手がよい。

本実施例では、通常ＡＰＩに対するリクエストに希望納期が含まれている場合、推定処理時間が希望納期に間に合わないときは、リクエストを自動的にキャンセルする。このため、本実施例によれば、ＡＰＩ利用者が無駄なリクエストを発行するのを抑制でき、ＡＰＩ利用時のコストを低減できる。

図１２を用いて第４実施例を説明する。本実施例では、複数のＡＰＩ提供サーバ２がそれぞれ提供するＡＰＩを連携させて、一つのまとまった処理を行う様子を説明する。

図１２では、ＡＰＩ管理システム１の持つ各機能１１〜１７のうちいくつかの機能１３，１６，１７を示している。なお、図１２では、ＡＰＩ提供サーバをＡＰＩサーバと略記している。

図１２に示す例では、クライアント３は、サーバ２Ａの提供するデータ取得用ＡＰＩと、サーバ２Ｂの提供する前処理用ＡＰＩと、サーバ２Ｃの提供する分析用ＡＰＩと、サーバ２Ｄの提供するデータ保存用ＡＰＩとを順番に使用する。これにより、クライアント３は、所望のデータを取得し、取得したデータを前処理し、前処理の完了したデータを分析し、その分析結果を保存することができる。

図１３を用いて第５実施例を説明する。本実施例では、ＡＰＩリクエストに設定するパラメタとして、分析手法を指定できるようにした。

ＡＰＩ処理実績値Ｔ１Ｃに示すように、例えばＡＰＩ−Ｂ１が分析用のＡＰＩである場合、分析処理に使用する手法（アルゴリズム）をパラメタとして指定できる。分析手法は、ＡＰＩ登録時などで手動で指定してもよいし、自動的に判定してもよい。

図１４を用いて第６実施例を説明する。図１４のＡＰＩ処理実績値Ｔ１Ｄに示すように、本実施例では、ＡＰＩに処理させるデータの単位サイズごとに、平均応答時間の実績値を管理する。データの単位サイズはＡＰＩ登録時などで手動で指定してもよいし、自動的に判定してもよい。

なお、本発明は上述の実施形態に限定されず、様々な変形例が含まれる。上記実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることもできる。また、ある実施形態の構成に他の実施形態の構成を加えることもできる。また、各実施形態の構成の一部について、他の構成を追加・削除・置換することもできる。

上記各構成、機能、処理部、処理手段等は、それらの一部や全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

また、上述した実施形態に含まれる技術的特徴は、特許請求の範囲に明示された組み合わせに限らず、適宜組み合わせることができる。

１，１Ａ，１Ｂ：ＡＰＩ管理システム、２Ａ，２Ｂ，２Ｃ，２Ｄ：ＡＰＩ提供サーバ、３：クライアント、１１：クライアント通信部、１２：サーバ通信部、１３：ＡＰＩリクエスト処理部、１４：データ蓄積部、１５：ＡＰＩ登録部、１６：実績値管理部、１７：推定ＡＰＩ処理部、１８：利用状況生成部、１９：ＡＰＩリクエストキュー

Claims (14)

1. 所定の機能を実現するプログラム部品を少なくとも一つ管理するプログラム部品管理装置であって、
   プログラム部品を使用するために必要な情報を蓄積するデータ蓄積部と、
   クライアントコンピュータからの処理要求を受け付け、前記受け付けた処理要求が前記プログラム部品についての処理要求である場合は、前記データ蓄積部に蓄積された情報に基づいて、前記プログラム部品を提供するサーバコンピュータへ前記処理要求を送信し、前記プログラム部品の実行結果を前記サーバコンピュータから受信すると、前記実行結果を前記クライアントコンピュータへ送信する要求処理部と、
   前記処理要求に係るプログラム部品の実行に要した処理時間を実績値として管理する実績値管理部と、
   を備えるプログラム部品管理装置。
2. さらに、前記実績値管理部により管理される前記実績値に基づいて、前記クライアントコンピュータが前記プログラム部品を使用する場合の処理時間を推定し、その推定結果を前記クライアントコンピュータへ送信する処理時間推定部を備える、
   請求項１に記載のプログラム部品管理装置。
3. 前記処理時間推定部は、前記クライアントコンピュータからの推定要求に応じて、前記クライアントコンピュータから指定されたプログラム部品の実行に要する処理時間を推定し、推定結果を前記クライアントコンピュータへ送信する、
   請求項２に記載のプログラム部品管理装置。
4. 前記推定要求は、複数のプログラム部品を指定することができる、
   請求項３に記載のプログラム部品管理装置。
5. 前記推定要求は、複数のプログラム部品と実行順序とを指定することができる、
   請求項４に記載のプログラム部品管理装置。
6. 前記実績値管理部は、プログラム部品を使用するために必要な情報が前記データ蓄積部に登録された場合に、前記登録されたプログラム部品を提供するサーバコンピュータに対して、前記登録されたプログラム部品のテスト実行を前記要求処理部を介して要求し、前記登録されたプログラム部品のテスト実行に要した処理時間を実績値の初期値として保存する、
   請求項１に記載のプログラム部品管理装置。
7. 前記実績値管理部は、前記クライアントコンピュータが前記サーバコンピュータの提供するプログラム部品を使用した場合の処理時間に基づいて前記実績値を更新する、
   請求項６に記載のプログラム部品管理装置。
8. 前記実績値管理部は、前記サーバコンピュータに対し、前記プログラム部品のテスト実行を所定の契機で前記要求処理部を介して要求し、前記テスト実行に要した処理時間に基づいて前記実績値を更新する、
   請求項７に記載のプログラム部品管理装置。
9. さらに、前記処理時間推定部による前記プログラム部品の処理時間の推定結果を前記プログラム部品の利用状況として出力する利用状況出力部を備える、
   請求項２に記載のプログラム部品管理装置。
10. 前記要求には、前記プログラム部品の処理が完了する時刻の希望時刻が設定されており、
    前記要求処理部は、前記希望時刻の設定されたプログラム部品の処理時間を前記処理時間推定部に推定させ、前記処理時間推定部の推定結果に基づいて、前記希望時刻の設定されたプログラム部品の実行完了予定時刻が前記希望時刻に間に合うか否かを判断し、間に合わないと判断した場合は、前記希望時刻の設定されたプログラム部品について前記クライアントコンピュータから発行された処理要求をキャンセルする、
    請求項２に記載のプログラム部品管理装置。
11. 前記要求には、推定対象であるプログラム部品の処理が完了する時刻の希望時刻が設定されており、
    前記処理時間推定部は、前記クライアントコンピュータから指定されたプログラム部品の実行に要する処理時間の推定結果と、前記処理時間の推定結果が前記希望時刻に間に合うか否かを示す判定結果と、前記処理時間の推定結果が前記希望時刻に間に合うために前記プログラム部品についての処理要求を発行すべき推奨時刻とを、前記クライアントコンピュータへ送信する、
    請求項２に記載のプログラム部品管理装置。
12. 前記要求には、推定対象であるプログラム部品の処理が完了する時刻の希望時刻が設定されており、
    前記処理時間推定部は、前記プログラムの実行に要する処理時間の推定結果が前記希望時刻に間に合うように、前記プログラム部品を実行する時間帯を変更し、前記要求処理部へ指示する、
    請求項２に記載のプログラム部品管理装置。
13. 前記データ蓄積部は、前記プログラム部品を使用するために必要な情報のみを記憶しており、それ以外の前記サーバコンピュータに関する情報は記憶していない、
    請求項１に記載のプログラム部品管理装置。
14. 所定の機能を実現する少なくとも一つのプログラム部品を計算機を用いて管理する方法であって、
    サーバコンピュータの提供するプログラム部品を使用するために必要な情報をデータ蓄積部に蓄積するステップと、
    クライアントコンピュータからの処理要求を受け付け、前記受け付けた処理要求が前記プログラム部品についての処理要求である場合は、前記データ蓄積部に蓄積された情報に基づいて前記サーバコンピュータへ前記処理要求を送信し、前記プログラム部品の実行結果を前記サーバコンピュータから受信すると、前記実行結果を前記クライアントコンピュータへ送信するステップと、
    前記処理要求に係るプログラム部品の実行に要した処理時間を実績値として管理するステップと、
    前記実績値に基づいて、前記クライアントコンピュータが前記プログラム部品を使用する場合の処理時間を推定し、その推定結果を前記クライアントコンピュータへ送信するステップと、
    を実行するプログラム部品の管理方法。

Images