JP5984148B2 - 遠隔手続き呼び出しを制御する装置及び方法 - Google Patents

Description

本発明は、遠隔手続き呼び出しを制御する装置及び方法に関する。特に、本発明は、クライアントのサーバに対する遠隔手続き呼び出しを制御する装置及び方法に関する。

クライアントのサーバに対する複数の遠隔手続き呼び出しの実行がほぼ同時に要求されることがある。ところが、遠隔手続き呼び出しの同時に実行できる数や、遠隔手続き呼び出しに基づく処理の同時に実行できる数には上限がある場合があり、そのような場合は、遠隔手続き呼び出しの態様や遠隔手続き呼び出しに基づく処理の態様をどのようなものとするかが問題となる。

ここで、同時セッション数を規定されている最大数以上に増やすための技術は、公報記載の技術として知られている（例えば、特許文献１参照）。

特許文献１は、コンピュータが、機器ごとに、リクエストの受信からリプライの発行までのリプライ発行待ち時間を指定し、リプライの受信から次のリクエストの発行までの次回リクエスト発行待ち時間を指定し、いずれかの機器からリクエストを受信した際に、制御要求がない場合は、その機器のリプライ発行待ち時間の経過後に、次回リクエスト発行待ち時間を通知するリプライを送信し、各機器が、リプライの受信の際に、リプライで通知されている次回リクエスト発行待ち時間の経過後に、次のリクエストを送信することを開示する。

また、遠隔手続き呼び出しの一例であるＡＰＩ（Application Programming Interface）呼び出しに関する技術も、公報記載の技術として知られている（例えば、特許文献２、３参照）。

特許文献２は、アプリケーションソースコード格納部が、アプリケーション群の各ソースコードを格納し、呼出遷移カウント部が、アプリケーションソースコードをアプリケーションごとに読込み、ＡＰＩ関数呼出遷移回数を計数し、呼出遷移カウント格納部が、その計数結果を遷移マトリックスとしてアプリケーションごとに格納し、呼出遷移共通カウント部が、遷移マトリックスに対しアプリケーションごとに読込み比較をしアプリケーション群間で共通するＡＰＩ関数呼出遷移候補回数を計数し、呼出遷移共通カウント格納部が、その計数結果を共通遷移マトリックスとして格納することを開示する。

特許文献３は、情報端末が、外部情報提供部から新しいアプリケーションプログラムやミドルウェアをダウンロードしてインストールする際に、アプリケーションプログラムの起動時において、ミドルウェアがアプリケーションプログラムへ提供する機能群の性能値及びユーザのアプリケーションプログラムの使い方の両者を考慮して、ロード可能なミドルウェア群の中からアプリケーションプログラムの実行性能を高めるミドルウェアを優先的に選択してロードすることを開示する。

特開２００９−２５１６６５号公報 特開平１１−２１２７８０号公報 特開２００８−５９４９４号公報

ところで、上述した、クライアントのサーバに対する複数の遠隔手続き呼び出しの実行がほぼ同時に要求されたような場合には、ユーザの関心を考慮して、遠隔手続き呼び出しの態様や遠隔手続き呼び出しに基づく処理の態様を決定するのが望ましい。

しかしながら、特許文献１〜３の技術は、ユーザの関心を考慮して、遠隔手続き呼び出しの態様や遠隔手続き呼び出しに基づく処理の態様を決定することを開示するものではない。

本発明の目的は、ユーザの関心を考慮して、遠隔手続き呼び出しの態様又は遠隔手続き呼び出しに基づく処理の態様を決定することにある。

かかる目的のもと、本発明は、クライアントのサーバに対する遠隔手続き呼び出しを制御する装置であって、クライアントからサーバに対して実行された遠隔手続き呼び出しから、定期的な遠隔手続き呼び出しと、不定期的な遠隔手続き呼び出しとを抽出する抽出部と、定期的な遠隔手続き呼び出しから得られる第１の情報と、不定期的な遠隔手続き呼び出しから得られる第２の情報とに基づき、クライアントからサーバに対して実行される遠隔手続き呼び出しについて、遠隔手続き呼び出しの態様及び遠隔手続き呼び出しに基づく処理の態様の何れかを決定する決定部とを含む、装置を提供する。

この装置において、決定部は、不定期的な遠隔手続き呼び出しが対象とする特定のデータを示す情報を第２の情報として用いる、ものであってよい。その場合、決定部は、定期的な遠隔手続き呼び出しが対象とするデータを示す情報が設定される項目を示す情報を第１の情報として用い、不定期的な遠隔手続き呼び出しにおいて項目に設定された情報が示すデータを特定のデータに決定する、ものであってよい。また、これらの場合において、決定部は、クライアントからサーバに対して実行される定期的な遠隔手続き呼び出しについて、特定のデータを対象とする特定の定期的な遠隔手続き呼び出しが他の定期的な遠隔手続き呼び出しとは区別されるように、定期的な遠隔手続き呼び出しの態様及び定期的な遠隔手続き呼び出しに基づく処理の態様の何れかを決定する、ものであってよい。

更に、決定部は、クライアントからサーバに対して実行される遠隔手続き呼び出しについて、遠隔手続き呼び出しの態様を決定する場合には、態様として、遠隔手続き呼び出しの優先度を決定し、遠隔手続き呼び出しに基づく処理の態様を決定する場合には、態様として、遠隔手続き呼び出しに基づく処理の優先度を決定する、ものであってよい。

また、本発明は、クライアントのサーバに対する遠隔手続き呼び出しを制御する装置であって、クライアントからサーバに対して実行された遠隔手続き呼び出しから、定期的な遠隔手続き呼び出しと、不定期的な遠隔手続き呼び出しとを抽出する抽出部と、定期的な遠隔手続き呼び出しが対象とするデータを示す値が設定される項目を推定する推定部と、不定期的な遠隔手続き呼び出しにおいて項目に設定された値が示す不定期的な遠隔手続き呼び出しが対象とする特定のデータを認識する認識部と、クライアントからサーバに対して実行される定期的な遠隔手続き呼び出しについて、特定のデータを対象とする特定の定期的な遠隔手続き呼び出しが他の定期的な遠隔手続き呼び出しよりも優先されるように、定期的な遠隔手続き呼び出しの態様及び定期的な遠隔手続き呼び出しに基づく処理の態様の何れかを決定する決定部とを含む、装置も提供する。

更に、本発明は、クライアントのサーバに対する遠隔手続き呼び出しを制御する方法であって、クライアントからサーバに対して実行された遠隔手続き呼び出しから、定期的な遠隔手続き呼び出しを抽出するステップと、クライアントからサーバに対して実行された遠隔手続き呼び出しから、不定期的な遠隔手続き呼び出しを抽出するステップと、定期的な遠隔手続き呼び出しから得られる第１の情報と、不定期的な遠隔手続き呼び出しから得られる第２の情報とに基づき、クライアントからサーバに対して実行される遠隔手続き呼び出しについて、遠隔手続き呼び出しの態様及び遠隔手続き呼び出しに基づく処理の態様の何れかを決定するステップとを含む、方法も提供する。

更にまた、本発明は、クライアントのサーバに対する遠隔手続き呼び出しを制御する装置として、コンピュータを機能させるプログラムであって、コンピュータを、クライアントからサーバに対して実行された遠隔手続き呼び出しから、定期的な遠隔手続き呼び出しと、不定期的な遠隔手続き呼び出しとを抽出する抽出部と、定期的な遠隔手続き呼び出しから得られる第１の情報と、不定期的な遠隔手続き呼び出しから得られる第２の情報とに基づき、クライアントからサーバに対して実行される遠隔手続き呼び出しについて、遠隔手続き呼び出しの態様及び遠隔手続き呼び出しに基づく処理の態様の何れかを決定する決定部として機能させる、プログラムも提供する。

本発明によれば、ユーザの関心を考慮して、遠隔手続き呼び出しの態様又は遠隔手続き呼び出しに基づく処理の態様を決定することができる。

システムの状態を監視するアプリケーションがクライアントに表示するダッシュボードＵＩの例を示した図である。 本発明の実施の形態におけるクライアントサーバシステムの全体構成例を示した図である。 本発明の実施の形態におけるＡＰＩ呼び出し制御部の機能構成例を示したブロック図である。 ＡＰＩ呼び出しを一定期間記録することにより得られたＡＰＩの呼び出しのタイミングを示した図である。 リソースを表すパラメータ項目の推定方法を説明するための図である。 リソースを表すパラメータ項目の推定の一例について示した図である。 定期ＡＰＩの呼び出しの優先度の変更方法を説明するための図である。 本発明の実施の形態におけるＡＰＩ呼び出し制御部の動作例を示したフローチャートである。 本発明の実施の形態におけるクライアントのハードウェア構成例を示した図である。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。

［本実施の形態の背景］
ＲＥＳＴｆｕｌ ＡＰＩ等のステートレスなリモートＡＰＩをウェブブラウザ（以下、単に「ブラウザ」という）から定期的に呼び出すことにより、クライアントがサーバで動作するシステムの状態を監視したいという要求がある。その際、定期的なＡＰＩの呼び出しは同時に行われることが多い。

図１は、このようなシステムの状態を監視するアプリケーションがクライアントに表示するダッシュボードＵＩ６００を示した図である。このダッシュボードＵＩ６００では、システムの状態を監視したり、監視のための操作を行ったりすることが可能になっている。ダッシュボードＵＩ６００は、コンポーネント６０１ａ〜６０１ｆを含む。そして、コンポーネント６０１ａ〜６０１ｆは、それぞれ、対応するリソースの状態を表示する表示部６０２ａ〜６０２ｆと、そのリソースに対してユーザが操作を行うための操作部６０３ａ〜６０３ｆとを提供している。ここで、表示部６０２ａ〜６０２ｆは、定期的なＡＰＩの呼び出しにより、リソースの状態を表示する。また、操作部６０３ａ〜６０３ｆをユーザが操作すると、不定期的なＡＰＩの呼び出しが行われる。このようなアプリケーションにおいて、各コンポーネントはモジュール化されており、同時にタイマがセットされるため、定期的なＡＰＩの呼び出しのタイミングは重なり易い。従って、上述したように、定期的なＡＰＩの呼び出しは同時に行われることが多くなる。

しかしながら、ＡＰＩの呼び出しが同時に行われることにより、同時に多大なＨＴＴＰリクエストが発生すると、ブラウザが同時に処理できるＨＴＴＰリクエストの上限に達することがある。その場合、上限に達した後におけるＨＴＴＰリクエストは長時間待たされ、所謂詰まった状態が生ずる。具体的には、複数の定期的なＡＰＩが同時に実行される際に、ユーザの関心が高いリソースに関するＡＰＩの実行が後回しになることがあり、ユーザの待ち時間がより長くなる。

そこで、本実施の形態では、まず、繰り返し行われるリモートＡＰＩの呼び出しの履歴に基づいて、リモートＡＰＩを、定期的に呼び出されるリモートＡＰＩ（以下、「定期ＡＰＩ」という）と、ユーザの要求に応じて不定期に呼び出されるリモートＡＰＩ（以下、「不定期ＡＰＩ」という）とに分類する。次に、定期ＡＰＩのパラメータを比較することにより、定期ＡＰＩが対象とするリソースを表すパラメータを推定する。そして、直近の不定期ＡＰＩが対象としたリソースはユーザの関心が高いと推定し、このリソースの優先度が高くなるよう、各リソースの優先度を決定する。これにより、複数の定期ＡＰＩの実行が同時に要求された場合に、各定期ＡＰＩが対象とするリソースの優先度に基づいて、これらの定期ＡＰＩの実行順序を決定する。

［本実施の形態のクライアントサーバシステムの構成］
図２は、本実施の形態におけるクライアントサーバシステムの全体構成例を示した図である。図示するように、このクライアントサーバシステムは、サーバ１０と、クライアント２０とを含み、クライアント２０では、アプリケーション３０と、ブラウザ４０とが動作する。また、このクライアントサーバシステムは、情報を表示するためのディスプレイ６０と、情報を入力するための入力デバイス７０とを含む。

サーバ１０は、ＡＰＩを実行するコンピュータである。具体的には、サーバ１０は、ＡＰＩ実行部１１を備え、ＡＰＩ実行部１１が、クライアント２０のブラウザ４０から呼び出されたＡＰＩを実行し、結果をブラウザ４０に返す。

クライアント２０は、ブラウザ４０を介してアプリケーション３０によるサービスを受けるユーザが使用するコンピュータである。具体的には、クライアント２０は、アプリケーション３０の機能として、タイマイベント処理部３１と、入力イベント処理部３２と、イベント制御部３３とを備え、ブラウザ４０の機能として、操作受付部４１と、表示制御部４２と、ＡＰＩ呼び出し部４３と、ＡＰＩ呼び出し制御部５０とを備える。

タイマイベント処理部３１は、予め登録されたタイマがタイムアウトすることによってタイマイベントが発生したことが伝えられると、その旨をイベント制御部３３に通知する。

入力イベント処理部３２は、操作受付部４１から入力イベントが発生したことが伝えられると、その旨をイベント制御部３３に通知する。

イベント制御部３３は、タイマイベントが発生した旨又は入力イベントが発生した旨を受け取り、イベントの内容に応じて、表示制御部４２に対するディスプレイ６０への表示出力の要求や、ＡＰＩ呼び出し部４３に対するＡＰＩ呼び出しの要求を行う。

操作受付部４１は、入力デバイス７０を用いたユーザの入力操作を受け付けることによって入力イベントが発生すると、その旨を入力イベント処理部３２に伝える。

表示制御部４２は、イベント制御部３３の要求に従って、ディスプレイ６０への表示出力を行う。

ＡＰＩ呼び出し部４３は、イベント制御部３３の要求に従って、サーバ１０に対するＡＰＩ呼び出しを行う。

ＡＰＩ呼び出し制御部５０は、複数の呼び出しが同時に要求された場合にＡＰＩ呼び出しの優先度を決定し、その優先度に基づいてＡＰＩ呼び出し部４３によるＡＰＩ呼び出しを制御する。

［本実施の形態のＡＰＩ呼び出し制御部の構成］
図３は、本実施の形態におけるＡＰＩ呼び出し制御部５０の機能構成例を示した図である。図示するように、このＡＰＩ呼び出し制御部５０は、ＡＰＩ呼び出し監視部５１と、定期ＡＰＩ記憶部５２と、パラメータ推定部５３と、不定期ＡＰＩ記憶部５４と、優先度決定部５５と、優先度記憶部５６とを含む。

ＡＰＩ呼び出し監視部５１は、ＡＰＩ呼び出し部４３によるＡＰＩ呼び出しを監視する。ＡＰＩ呼び出しの監視は、最初の定期ＡＰＩ呼び出し監視処理と、続く不定期ＡＰＩ呼び出し監視処理とに分けられる。まず、ＡＰＩ呼び出し監視部５１は、定期ＡＰＩ呼び出し監視処理において、ＡＰＩ呼び出しを一定時間監視し、定期ＡＰＩの呼び出しがあったかどうかを判定する。そして、定期ＡＰＩの呼び出しがあったと判定すれば、定期ＡＰＩの情報を定期ＡＰＩ記憶部５２に記憶する。次に、ＡＰＩ呼び出し監視部５１は、不定期ＡＰＩ呼び出し監視処理において、ＡＰＩ呼び出しを監視し、ＡＰＩ呼び出しを検出すると、それが不定期ＡＰＩの呼び出しであるかどうかを判定する。そして、それが不定期ＡＰＩの呼び出しであると判定すれば、不定期ＡＰＩの情報を不定期ＡＰＩ記憶部５４に記憶する。本実施の形態では、遠隔手続き呼び出しの一例として、ＡＰＩ呼び出しを用いており、定期的な遠隔手続き呼び出しと不定期的な遠隔手続き呼び出しとを抽出する抽出部の一例として、ＡＰＩ呼び出し監視部５１を設けている。

定期ＡＰＩ記憶部５２は、ＡＰＩ呼び出し監視部５１による定期ＡＰＩの呼び出しの監視により得られた定期ＡＰＩの情報を記憶する。

パラメータ推定部５３は、定期ＡＰＩ記憶部５２に記憶された定期ＡＰＩの情報に基づいて、ＡＰＩが対象とするリソースを表すパラメータ項目を推定する。本実施の形態では、データの一例として、リソースを用いており、対象とするデータを示す情報又は値が設定される項目の一例として、パラメータ項目を用いており、項目を推定する推定部の一例として、パラメータ推定部５３を設けている。

不定期ＡＰＩ記憶部５４は、ＡＰＩ呼び出し監視部５１による不定期ＡＰＩの呼び出しの監視により得られた不定期ＡＰＩの情報を記憶する。

優先度決定部５５は、不定期ＡＰＩ記憶部５４に記憶された不定期ＡＰＩの情報において、パラメータ推定部５３により推定されたパラメータ項目に設定されたパラメータ値を調べることにより、不定期ＡＰＩが対象とするリソースを特定する。そして、定期ＡＰＩ記憶部５２に記憶された定期ＡＰＩの情報において、パラメータ推定部５３により推定されたパラメータ項目にそのリソースを表すパラメータ値が設定されているものを検索することにより、そのリソースを対象とする定期ＡＰＩがあるかどうかを判定する。その結果、そのような定期ＡＰＩがあれば、その優先度が高くなるように、定期ＡＰＩの優先度を決定する。本実施の形態では、対象とするデータを示す情報又は値の一例として、パラメータ値を用いており、項目に設定された値が示す特定のデータを認識する認識部の一例として、優先度決定部５５を設けている。

優先度記憶部５６は、優先度決定部５５により決定された各定期ＡＰＩの優先度の情報を記憶する。この優先度の情報は、複数の定期ＡＰＩの呼び出しの実行が同時に要求された場合にＡＰＩ呼び出し部４３により参照され、複数の定期ＡＰＩの呼び出しの実行を優先度の高いものから順に行うことを可能とする。

［ＡＰＩ呼び出し監視部の概略動作］
ＡＰＩ呼び出し監視部５１は、ＡＰＩ呼び出し部４３によるＡＰＩ呼び出しを一定期間記録し、ＡＰＩ呼び出しのパターンから定期ＡＰＩの呼び出しと不定期ＡＰＩの呼び出しとを判別する。ここで、このような判別は、フーリエ変換等の公知の手法を用いて行えばよい。

図４は、ＡＰＩ呼び出しを一定期間記録することにより得られたＡＰＩの呼び出しのタイミングを示した図である。図において、ＡＰＩ２０１，２０２，２０３は、定期的に呼び出されているので、定期ＡＰＩである。一方、ＡＰＩ２０４，２０５，２０６は、不定期に呼び出されているので、不定期ＡＰＩである。

［パラメータ推定部の概略動作］
パラメータ推定部５３は、近い時刻に呼び出される定期ＡＰＩのＵＲＬやリクエストボディを比較する。具体的には、ＵＲＬやリクエストボディに含まれる各パラメータの項目（以下、「パラメータ項目」という）に設定された値（以下、「パラメータ値」という）を比較する。その結果、異なるパラメータ値が設定されたパラメータ項目が１つだけの定期ＡＰＩ呼び出しの回数が閾値以上あれば、そのパラメータ項目がリソースを表すパラメータ項目であると推定する。

図５は、このようなリソースを表すパラメータ項目の推定方法を説明するための図である。具体的には、見出し部にパラメータ項目「パラメータ１」，…，「パラメータ４」を示し、データ部に各パラメータ項目に設定されたパラメータ値を示した表である。この表では、データ部の１行目〜４行目が、「パラメータ２」に設定されたパラメータ値のみが異なる定期ＡＰＩ呼び出しを表している。「パラメータ２」に設定されたパラメータ値が４行目では省略されているが、例えば、データ部の１行目〜４行目が１００回以上の定期ＡＰＩ呼び出しを表し、定期ＡＰＩ呼び出しの回数の閾値が１００であるとすると、「パラメータ２」がリソースを表すと推定する。一方、データ部の５行目及び６行目は、「パラメータ３」に設定されたパラメータ値のみが異なる定期ＡＰＩを表している。しかしながら、これは２回の定期ＡＰＩ呼び出しを表すに過ぎず、定期ＡＰＩ呼び出しの回数の閾値１００に満たないので、「パラメータ３」がリソースを表すとは推定しない。

図６は、リソースを表すパラメータ項目の推定の一例について示した図である。短時間内に呼び出された定期ＡＰＩに、図示するような情報が含まれていたとする。すると、この場合は、異なるパラメータ値が設定されている唯一のパラメータ項目である「collectionId」がリソースを表すパラメータ項目であると推定できる。

［優先度決定部の概略動作］
本実施の形態では、不定期ＡＰＩが呼び出された場合に、その不定期ＡＰＩが対象とするリソースに対するユーザの関心が高いと考える。そこで、同一のリソースを対象とする定期ＡＰＩの呼び出しの優先度を高くする。

図７は、このような定期ＡＰＩの呼び出しの優先度の変更方法を説明するための図である。図示するように、まず、定期ＡＰＩ２１１，２１２が呼び出されたとする。このとき、定期ＡＰＩ２１１，２１２の呼び出しの優先度は何れも「中」であるものとする。次に、不定期ＡＰＩ２１３が呼び出されたとする。すると、リソースを表すと推定されたパラメータ項目「collectionId」に設定されたパラメータ値「col_kurokawa」がユーザの関心が高いリソースを表すことが分かる。これにより、その後、定期ＡＰＩ２１４，２１５が同時に呼び出された場合、「collectionId」に「col_kurokawa」が設定された定期ＡＰＩ２１４の優先度が「高」に変更される。

［本実施の形態のクライアントサーバシステムの動作］
クライアント２０では、イベント制御部３３が、タイマイベント処理部３１からタイマイベントが発生した旨の通知を受け、入力イベント処理部３２から入力イベントが発生した旨の通知を受ける。そして、タイマイベント又は入力イベントの内容に応じて、ＡＰＩ呼び出し部４３に対し、ＡＰＩ呼び出しの実行を要求する。すると、ＡＰＩ呼び出し部４３が、サーバ１０に対して、ＡＰＩ呼び出しを実行する。これにより、サーバ１０では、ＡＰＩ実行部１１が、クライアント２０から呼び出されたＡＰＩを実行する。

クライアントサーバシステムはこのような動作を行うが、本実施の形態では、ＡＰＩ呼び出し部４３がＡＰＩ呼び出しを実行する際に、ＡＰＩ呼び出し制御部５０による制御を受ける。図８は、このＡＰＩ呼び出し制御部５０の動作例を示したフローチャートである。この動作は、例えば、図１に示したような画面に遷移したときに開始するものとする。

図示するように、ＡＰＩ呼び出し制御部５０では、まず、ＡＰＩ呼び出し監視部５１が、定期ＡＰＩ呼び出し監視処理を行う。即ち、ＡＰＩ呼び出し部４３によるＡＰＩ呼び出しを一定時間観測する（ステップ５０１）。そして、一定時間観測したＡＰＩ呼び出しの中に定期ＡＰＩの呼び出しがあるかどうかを判定する（ステップ５０２）。定期ＡＰＩの呼び出しがないと判定すれば、ＡＰＩ呼び出し監視部５１は、ステップ５０１を繰り返すが、定期ＡＰＩの呼び出しがあると判定すれば、ＡＰＩ呼び出し監視部５１は、その定期ＡＰＩの情報を定期ＡＰＩ記憶部５２に記憶する（ステップ５０３）。このとき、ＡＰＩ呼び出し監視部５１は、定期ＡＰＩの呼び出しがあった旨をパラメータ推定部５３に伝え、パラメータ推定部５３が、定期ＡＰＩ記憶部５２に記憶された定期ＡＰＩの情報を参照して、リソースを表すパラメータ項目を推定する（ステップ５０４）。その後、パラメータ推定部５３は、リソースを表すパラメータ項目の推定が完了した旨をＡＰＩ呼び出し監視部５１に伝え、推定したリソースを表すパラメータ項目を優先度決定部５５に通知する。

これにより、ＡＰＩ呼び出し監視部５１は、不定期ＡＰＩ呼び出し監視処理を行う。即ち、ＡＰＩ呼び出し部４３によるＡＰＩ呼び出しを観測する（ステップ５０５）。そして、観測したＡＰＩ呼び出しが不定期ＡＰＩの呼び出しであるかどうかを判定する（ステップ５０６）。観測したＡＰＩ呼び出しが不定期ＡＰＩの呼び出しでないと判定すれば、ＡＰＩ呼び出し監視部５１は、ステップ５０５を繰り返すが、観測したＡＰＩ呼び出しが不定期ＡＰＩの呼び出しであると判定すれば、ＡＰＩ呼び出し監視部５１は、その不定期ＡＰＩの情報を不定期ＡＰＩ記憶部５４に記憶する（ステップ５０７）。その後、優先度決定部５５は、この不定期ＡＰＩが対象とするリソースを対象とする定期ＡＰＩがあるかどうかを判定する（ステップ５０８）。具体的には、不定期ＡＰＩ記憶部５４に記憶された不定期ＡＰＩの情報を参照して、パラメータ推定部５３から通知されたパラメータ項目に設定されたパラメータ値を取得する。そして、定期ＡＰＩ記憶部５２に記憶された定期ＡＰＩの情報を参照して、このパラメータ値がパラメータ項目に設定された定期ＡＰＩがあるかどうかを判定する。その結果、不定期ＡＰＩが対象とするリソースを対象とする定期ＡＰＩがないと判定すれば、優先度決定部５５は、ステップ５０５を繰り返すようＡＰＩ呼び出し監視部５１に指示する。一方、不定期ＡＰＩが対象とするリソースを対象とする定期ＡＰＩがあると判定すれば、優先度決定部５５は、その定期ＡＰＩの優先度を高くする（ステップ５０９）。

以上により、クライアントサーバシステムの動作の説明を終了する。尚、このようにして優先度を付加した後、優先度の調整を行ってもよい。優先度の調整としては、例えば、一定時間経過後に優先度をリセットすることが考えられる。或いは、優先度の偏りの発生を防止するための係数を導入することも考えられる。ここで、優先度の偏りとは、ある時期にある定期ＡＰＩの優先度を高くする処理が集中したことにより、その定期ＡＰＩの優先度が特に高くなっている状態である。そして、これを防止するには、最近の優先度を高くする処理において、以前に優先度を高くした処理よりも、優先度を高める度合いを大きくすることが考えられる。

以上述べたように、本実施の形態では、クライアント２０からサーバ１０に対して実行されたＡＰＩ呼び出しから定期ＡＰＩの呼び出しと不定期ＡＰＩの呼び出しとを抽出し、ＡＰＩが対象とするリソースを示すパラメータ項目を定期ＡＰＩに基づいて推定し、不定期ＡＰＩにおいてそのパラメータ項目に設定されたパラメータ値に基づいて不定期ＡＰＩが対象とするリソースを特定し、そのリソースを対象とする定期ＡＰＩの呼び出しの優先度を高くするようにした。これにより、同時に実行が要求される定期ＡＰＩの呼び出しのうちユーザの関心が高いものを、アプリケーションに関する知識を用いずに特定し、その実行の優先度を上げることが可能となった。

尚、本実施の形態では、定期ＡＰＩの呼び出しから推定されたリソースを表すパラメータ項目と、不定期ＡＰＩにおいてそのパラメータ項目に設定されたパラメータ値とに基づいて、定期ＡＰＩの呼び出しの優先度を決定するようにしたが、この限りではない。定期ＡＰＩの呼び出しから得られる第１の情報と、不定期ＡＰＩの呼び出しから得られる第２の情報とに基づいて、定期ＡＰＩの呼び出しの優先度を決定するようにしてもよい。ここで、第１の情報と第２の情報とは同種の情報であっても異種の情報であってもよい。

また、本実施の形態では、ブラウザ４０が同時に呼び出せるＡＰＩの数に上限があるものとし、定期ＡＰＩの呼び出しの優先度を決定するようにした。しかしながら、ブラウザ４０が同時に呼び出せるＡＰＩの数に上限がないものとし、定期ＡＰＩの呼び出しに基づく処理の優先度を決定するようにしてもよい。即ち、ブラウザ４０は、要求された全ての定期ＡＰＩの呼び出しを実行し、サーバ１０側で優先度に従って定期ＡＰＩに基づく処理を実行できるようにしてもよい。

更に、本実施の形態では、定期ＡＰＩの呼び出し又は定期ＡＰＩの呼び出しに基づく処理の優先度を決定するようにしたが、この限りではない。あるリソースを対象とする定期ＡＰＩが他の定期ＡＰＩとは区別されるように、定期ＡＰＩの呼び出し又は定期ＡＰＩの呼び出しに基づく処理の態様を決定するようにしてもよい。例えば、あるリソースを対象とする定期ＡＰＩの呼び出しに対しては新たに処理を行うが、別のリソースを対象とする定期ＡＰＩの呼び出しに対しては既に行った処理の結果を用いる、といったものが考えられる。また、これは更に一般化して、単に、定期ＡＰＩの呼び出し又は定期ＡＰＩの呼び出しに基づく処理の態様を決定するものと捉えることも可能である。即ち、本実施の形態では、定期的な遠隔手続き呼び出しの態様及び定期的な遠隔手続き呼び出しに基づく処理の態様の何れかを決定する決定部の一例として、優先度決定部５５を設けていると言うことができる。

［本実施の形態のクライアントのハードウェア構成］
図９は、本実施の形態におけるクライアント２０のハードウェア構成例を示した図である。図示するように、クライアント２０は、演算手段であるＣＰＵ（Central Processing Unit）２０ａと、Ｍ／Ｂ（マザーボード）チップセット２０ｂを介してＣＰＵ２０ａに接続されたメインメモリ２０ｃと、同じくＭ／Ｂチップセット２０ｂを介してＣＰＵ２０ａに接続された表示機構２０ｄ（図２のディスプレイ６０に対応）とを備える。また、Ｍ／Ｂチップセット２０ｂには、ブリッジ回路２０ｅを介して、ネットワークインターフェイス２０ｆと、磁気ディスク装置（ＨＤＤ）２０ｇと、音声機構２０ｈと、キーボード／マウス２０ｉ（図２の入力デバイス７０に対応）と、光学ドライブ２０ｊとが接続されている。

尚、図９において、各構成要素は、バスを介して接続される。例えば、ＣＰＵ２０ａとＭ／Ｂチップセット２０ｂの間や、Ｍ／Ｂチップセット２０ｂとメインメモリ２０ｃの間は、ＣＰＵバスを介して接続される。また、Ｍ／Ｂチップセット２０ｂと表示機構２０ｄとの間は、ＡＧＰ（Accelerated Graphics Port）を介して接続されてもよいが、表示機構２０ｄがＰＣＩ Ｅｘｐｒｅｓｓ対応のビデオカードを含む場合、Ｍ／Ｂチップセット２０ｂとこのビデオカードの間は、ＰＣＩ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）バスを介して接続される。また、ブリッジ回路２０ｅと接続する場合、ネットワークインターフェイス２０ｆについては、例えば、ＰＣＩ Ｅｘｐｒｅｓｓを用いることができる。また、磁気ディスク装置２０ｇについては、例えば、シリアルＡＴＡ（AT Attachment）、パラレル転送のＡＴＡ、ＰＣＩ（Peripheral Components Interconnect）を用いることができる。更に、キーボード／マウス２０ｉ、及び、光学ドライブ２０ｊについては、ＵＳＢ（Universal Serial Bus）を用いることができる。

ここで、本発明は、全てハードウェアで実現してもよいし、全てソフトウェアで実現してもよい。また、ハードウェア及びソフトウェアの両方により実現することも可能である。また、本発明は、コンピュータ、データ処理システム、コンピュータプログラムとして実現することができる。このコンピュータプログラムは、コンピュータにより読取り可能な媒体に記憶され、提供され得る。ここで、媒体としては、電子的、磁気的、光学的、電磁的、赤外線又は半導体システム（装置又は機器）、或いは、伝搬媒体が考えられる。また、コンピュータにより読取り可能な媒体としては、半導体、ソリッドステート記憶装置、磁気テープ、取り外し可能なコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、リジッド磁気ディスク、及び光ディスクが例示される。現時点における光ディスクの例には、コンパクトディスク−リードオンリーメモリ（ＣＤ−ＲＯＭ）、コンパクトディスク−リード／ライト（ＣＤ−Ｒ／Ｗ）及びＤＶＤが含まれる。

以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態には限定されない。本発明の精神及び範囲から逸脱することなく様々に変更したり代替態様を採用したりすることが可能なことは、当業者に明らかである。

１０…サーバ、１１…ＡＰＩ実行部、２０…クライアント、３０…アプリケーション、３１…タイマイベント処理部、３２…入力イベント処理部、３３…イベント制御部、４０…ブラウザ、４１…操作受付部、４２…表示制御部、４３…ＡＰＩ呼び出し部、５０…ＡＰＩ呼び出し制御部、５１…ＡＰＩ呼び出し監視部、５２…定期ＡＰＩ記憶部、５３…パラメータ推定部、５４…不定期ＡＰＩ記憶部、５５…優先度決定部、５６…優先度記憶部

Claims (7)

1. クライアントのサーバに対する遠隔手続き呼び出しを制御する装置であって、
   前記クライアントから前記サーバに対して実行された遠隔手続き呼び出しから、定期的な遠隔手続き呼び出しと、不定期的な遠隔手続き呼び出しとを抽出する抽出部と、
   前記クライアントから前記サーバに対して実行される定期的な遠隔手続き呼び出しであって、前記不定期的な遠隔手続き呼び出しが対象とする特定のデータを対象とする定期的な遠隔手続き呼び出しについて、当該定期的な遠隔手続き呼び出しの態様及び当該定期的な遠隔手続き呼び出しに基づく処理の態様の何れかを決定する決定部と
   を含む、装置。
2. 前記定期的な遠隔手続き呼び出しが対象とするデータを示す情報が設定される項目を推定する推定部を更に備え、
   前記決定部は、前記不定期的な遠隔手続き呼び出しにおいて前記項目に設定された情報が示すデータを前記特定のデータに決定する、請求項１の装置。
3. 前記決定部は、前記クライアントから前記サーバに対して実行される前記定期的な遠隔手続き呼び出しについて、前記特定のデータを対象とする特定の定期的な遠隔手続き呼び出しが他の定期的な遠隔手続き呼び出しとは区別されるように、当該定期的な遠隔手続き呼び出しの態様及び当該定期的な遠隔手続き呼び出しに基づく処理の態様の何れかを決定する、請求項１又は請求項２の装置。
4. 前記決定部は、前記クライアントから前記サーバに対して実行される前記定期的な遠隔手続き呼び出しについて、当該定期的な遠隔手続き呼び出しの態様を決定する場合には、当該態様として、当該定期的な遠隔手続き呼び出しの優先度を決定し、当該定期的な遠隔手続き呼び出しに基づく処理の態様を決定する場合には、当該態様として、当該定期的な遠隔手続き呼び出しに基づく処理の優先度を決定する、請求項１乃至請求項３の何れかの装置。
5. クライアントのサーバに対する遠隔手続き呼び出しを制御する装置であって、
   前記クライアントから前記サーバに対して実行された遠隔手続き呼び出しから、定期的な遠隔手続き呼び出しと、不定期的な遠隔手続き呼び出しとを抽出する抽出部と、
   前記定期的な遠隔手続き呼び出しが対象とするデータを示す値が設定される項目を推定する推定部と、
   前記不定期的な遠隔手続き呼び出しにおいて前記項目に設定された値が示す当該不定期的な遠隔手続き呼び出しが対象とする特定のデータを認識する認識部と、
   前記クライアントから前記サーバに対して実行される定期的な遠隔手続き呼び出しについて、前記特定のデータを対象とする特定の定期的な遠隔手続き呼び出しが他の定期的な遠隔手続き呼び出しよりも優先されるように、当該定期的な遠隔手続き呼び出しの態様及び当該定期的な遠隔手続き呼び出しに基づく処理の態様の何れかを決定する決定部と
   を含む、装置。
6. クライアントのサーバに対する遠隔手続き呼び出しをコンピュータが制御する方法であって、
   前記コンピュータが、前記クライアントから前記サーバに対して実行された遠隔手続き呼び出しから、定期的な遠隔手続き呼び出しを抽出するステップと、
   前記コンピュータが、前記クライアントから前記サーバに対して実行された遠隔手続き呼び出しから、不定期的な遠隔手続き呼び出しを抽出するステップと、
   前記コンピュータが、前記クライアントから前記サーバに対して実行される定期的な遠隔手続き呼び出しであって、前記不定期的な遠隔手続き呼び出しが対象とする特定のデータを対象とする定期的な遠隔手続き呼び出しについて、当該定期的な遠隔手続き呼び出しの態様及び当該定期的な遠隔手続き呼び出しに基づく処理の態様の何れかを決定するステップと
   を含む、方法。
7. クライアントのサーバに対する遠隔手続き呼び出しを制御する装置として、コンピュータを機能させるプログラムであって、
   前記コンピュータを、
   前記クライアントから前記サーバに対して実行された遠隔手続き呼び出しから、定期的な遠隔手続き呼び出しと、不定期的な遠隔手続き呼び出しとを抽出する抽出部と、
   前記クライアントから前記サーバに対して実行される定期的な遠隔手続き呼び出しであって、前記不定期的な遠隔手続き呼び出しが対象とする特定のデータを対象とする定期的な遠隔手続き呼び出しについて、当該定期的な遠隔手続き呼び出しの態様及び当該定期的な遠隔手続き呼び出しに基づく処理の態様の何れかを決定する決定部と
   して機能させる、プログラム。

Images