スループット管理方法およびスループット管理サーバ
【課題】ビジネスプロセスを実行する上で必要なＷｅｂサービスのスループットを確保することができるスループット管理方法を提供する。
【解決手段】クライアント３００とサーバ２００に各々にスループット制御部３０８、２０５を設ける。クライアント３００のスループット制御部３０８は、サーバ２００に対してスループットの新規確保リクエストなどのスループットに関するリクエストを送信することによってビジネスプロセスを実行するうえで必要なスループットを確保する。サーバ２００のスループット制御部２０５は、スループットの新規確保リクエストなどを受付けてクライアントに割り当てるスループットを管理する。これにより、サーバ２００は過剰なリクエスト処理を抑制でき、サービス不能状態を回避することができる。
【解決手段】クライアント３００とサーバ２００に各々にスループット制御部３０８、２０５を設ける。クライアント３００のスループット制御部３０８は、サーバ２００に対してスループットの新規確保リクエストなどのスループットに関するリクエストを送信することによってビジネスプロセスを実行するうえで必要なスループットを確保する。サーバ２００のスループット制御部２０５は、スループットの新規確保リクエストなどを受付けてクライアントに割り当てるスループットを管理する。これにより、サーバ２００は過剰なリクエスト処理を抑制でき、サービス不能状態を回避することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビジネスプロセスを実行する上で必要なＷｅｂサービスのスループットを確保することができるスループット管理方法およびスループット管理システムに関する。
【背景技術】
【０００２】
従来の分散処理技術といえば、ＣＯＲＢＡ（Common Object Request Broker Architecture）（登録商標）やＪａｖａ（登録商標）−ＲＭＩといった比較的閉じたネットワークで行われるものが多かった。しかし、近年、インターネットの普及によりインターネットを介しての分散処理が行われるようになった。その代表的な例が、Ｗｅｂサービス（以下、ＷＳという。）である。ＷＳは、ＨＴＴＰ（HyperText Transfer Protocol）を利用してサービスを提供する。サービスを提供する側（サーバ側）は、ＷＳＤＬ（Web Services Description Language）を用いて、提供するサービスの内容および仕様を記述する。サービスを利用する側（クライアント側）は、サーバから提供されたＷＳＤＬを読み込み、記述された仕様にそってサービスを利用する。この際、クライアントからサーバにサービスを要求することを、「リクエストを送信する」という。
【０００３】
また、ＷＳの普及により、複数のＷＳを結合して実行する場合のプロセスを記述するプロセス記述言語の開発が進められている。プロセス記述言語の主な仕様に、Ｍｉｃｒｏｓｏｆｔ（登録商標）、ＩＢＭ（登録商標）、ＢＥＡ（登録商標）が提唱するＢＰＥＬ４ＷＳ（Business Process Execution Language for Web Services）と呼ばれる仕様が知られている（例えば、非特許文献１参照）。
【０００４】
ＷＳを利用したプロセスの処理が普及すると様々なサービスが相互に呼ばれることなり、各ＷＳの負荷分散（スループット管理）が必要となることが予想される。ＨＴＴＰの場合、従来技術の負荷分散処理は、サーバ側による負荷分散が一般的であった。サーバ側による負荷分散処理は、基本的にある一定量までのリクエストを適切にサーバに振り分け、それ以上のリクエストが到達すると、そのリクエストを無視するようになっている。この方式では、クライアントはリクエストが無視されたと判断すると、リクエストを再送、もしくはリクエストをキャンセルする。
【非特許文献１】IBM、“Business Process Execution Language for Web Services version 1.1“、[online]、[平成１８年９月１１日]、インターネット<URL:http://www-106.ibm.com/developerworks/library/ws-bpel>
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来のサーバ側での負荷分散処理を行うと、プロセスを実行中に呼出されたＷＳが、既に一定量以上のリクエストを受付けていた場合、そのリクエストは無視される。プロセスは複数のＷＳへのリクエストを集めたものであるため、１つでもＷＳの呼出に失敗すると、それがプロセス全体の処理に影響し、そのプロセスは再送処理などにより中断されてしまう、又は、異常終了となってしまい、安定的なプロセスの実行が困難となる。プロセスは複数のＷＳにリクエストを送信するため、もし複数のＷＳへのリクエストが安定的に処理されなければ、安定的なプロセスの実行は困難になる。
【０００６】
そのため、できる限りリクエストが無視されるケースを取り除く必要がある。この場合考えられるのが、サーバで受付けるリクエスト件数のピーク時（スループット要求の高いとき）に合わせてサーバマシンを調達することである。しかし、この考え方が有効なのは、ピーク時（スループット要求の高いとき）とオフピーク時（スループット要求の低いとき）の差があまり無いケースである。一般的に、ＨＴＴＰのリクエストは応答時間が短く、オフピーク時は負荷が小さく、ピーク時は極端に負荷が大きくなる傾向がある。そのため、ピーク時に合わせたサーバマシンを調達することは過剰なコストをかけることになる。このことを考えると、ピーク時に合わせたサーバマシンの調達というのは最適な構成法とはいえない。一方、リクエスト元によってリクエストの受付を判断するアクセス制御を用いることも考えられる。しかし、特定のリクエスト元のみにアクセスを許可する方法は、不公平であり、また、その特定のリクエスト元のリクエスト送出量が少なければ、サーバの処理能力を十分に活用することがないので、あまり有効な構成法とはいえない。
【０００７】
本発明は、前記の課題を解決するための発明であって、ビジネスプロセスを実行する上で必要なＷｅｂサービスのスループットを確保することができるスループット管理方法およびスループット管理サーバを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、サーバとクライアントのそれぞれにリクエストの受付に関する制御処理部（例えば、スループット制御部２０５，３０８）を有し、その制御処理部を用いてサーバとクライアント間でリクエストの制御情報を交換することで、サーバとプロセスを実行するクライアントのそれぞれの処理時間、すなわち品質を保証するスループットを確保する。このような方法によれば、サーバがリクエストの過剰受付によるサービス不能状態に陥ることなく、かつ、クライアントで実行しているプロセスがＷｅｂサービス（ＷＳ）の呼出で遅延することなく正常に実行でき、そしてサーバの処理能力を有効に使用することができる。
【発明の効果】
【０００９】
本発明によれば、ビジネスプロセスを実行する上で必要なＷｅｂサービスのスループットを確保することができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施形態について図面を参照して説明する。
図１は、本発明の実施形態のスループット管理システムのハードウェア構成を示すブロック図である。スループット管理システムは、１台または複数のクライアント３００、１台または複数のサーバ２００より構成される。クライアント３００は、ハードディスク（ＨＤＤ）３２１、中央演算装置（ＣＰＵ）３２２、メモリ３２３、ネットワークカード（ＮＩＣ）３２４などから構成される。ＨＤＤ３２１は、クライアント３００が処理を実行するための各種データを保存する。ＣＰＵ３２２は、メモリ３２３に格納される各種プログラムを実行する。メモリ３２３は、クライアント３００が処理を実行する各種プログラムおよび一時的なデータを保存する。ＮＩＣ３２４は、ネットワーク１００を介して、他のクライアントまたはサーバ２００と各種データやコマンドを交換する。具体的には、ＮＩＣ３２４は、リクエスト送出部３０６からの要求に応じて、ネットワーク１００を介してサーバ２００に、リクエストを送信する。クライアント３００とサーバ２００は、ある通信路、例えばＥｔｈｅｒｎｅｔ（登録商標）などの汎用的なネットワーク１００を介して接続されている。なお、ＣＰＵはCentral Processing Unitの略、ＨＤＤはHard Disk Driveの略、ＮＩＣはNetwork Interface Cardの略である。
【００１１】
クライアント３００のＨＤＤ３２１には、ビジネスプロセス（以下、ＢＰという。）を定義したＢＰＥＬファイル３０１、確保したスループットの情報を格納するスループット情報格納ＤＢ３０５、ＢＰのインターフェースを定義したＷＳＤＬファイル３１２が格納される。なお、ＢＰＥＬはBusiness Process Execution Languageの略、ＷＳＤＬはWeb Services Description Languageの略である。
【００１２】
メモリ３２３には、クライアント３００が処理を実行する各種プログラムおよび一時的なデータが保存され、具体的には、ＢＰＥＬファイル３０１からスループットの確保が必要なＷｅｂサービスを抽出するＷＳ抽出部３０３、ＢＰＥＬファイル３０１を読み込み、ＢＰを実行するＢＰ処理部３０４、Ｗｅｂサービスへのリクエストを送信するリクエスト送出部３０６、Ｗｅｂサービスへのリクエストの送信回数を測定するスループット測定部３０７、スループット情報の制御を行うスループット制御部３０８のプログラム、およびスループットの管理に使用する閾値用定数３１１が格納される。
【００１３】
また、サーバ２００は、ハードディスク（ＨＤＤ）２２１、中央演算装置（ＣＰＵ）２２２、メモリ２２３、ネットワークカード（ＮＩＣ）２２４などから構成される。ＨＤＤ２２１は、サーバ２００が処理を実行するための各種データを保存する。ＣＰＵ２２２は、メモリ２２３に格納される各種プログラムを実行する。メモリ２２３は、サーバ２００が処理を実行する各種プログラムおよび一時的なデータを保存する。ＮＩＣ２２４は、ネットワーク１００を介して、クライアント３００と各種データやコマンドを交換する。具体的には、ネットワーク１００を介して送られてくるクライアント３００のデータを受信する。
【００１４】
サーバ２００のＨＤＤ２２１には、Ｗｅｂサービスを定義したＷＳ定義ファイル２１０、スループット情報を格納するスループット情報格納ＤＢ２０６が格納される。
【００１５】
メモリ２２３には、サーバ２００が処理を実行する各種プログラムおよび一時的なデータが保存され、具体的には、クライアント３００からのリクエストを受付けるリクエスト受付部２０３、クライアント３００からのリクエストを受信した回数を測定するスループット測定部２０４、スループット情報を制御するスループット制御部２０５のプログラム、およびサーバ管理者が管理するスループット判定のために用いる閾値用定数２０９が格納される。
【００１６】
クライアント３００側のスループット制御部３０８とサーバ２００側のスループット制御部２０５が、それぞれスループットに関する情報を交換することでスループットの管理を行う。その情報の交換には、ＳＯＡＰ（Simple Object Access Protocol）が使用される。
【００１７】
図２は、サーバのソフトウェアの構成例を示す説明図である。サーバ２００は、クライアント３００（３００Ａ，３００Ｂ）からのリクエストを受信し、リクエスト受付部２０３で受付ける。クライアント３００Ａ，３００Ｂは、複数のクライアント３００の例として示している。クライアント３００は、クライアント端末利用者の入力を受付けて、ＢＰを実行する。ＢＰ実行中にＷｅｂサービスを呼び出す必要がある場合は、リクエストを生成し、リクエスト受付部２０３に送付する。
【００１８】
リクエスト受付部２０３は、スループット測定部２０４を用いて、リクエスト毎のスループットの測定を行う。スループット測定部２０４で得られたリクエスト毎のスループットは、スループット情報格納ＤＢ２０６に格納される。
【００１９】
クライアント３００から送付されるリクエストには、スループット制御用のリクエストと、各Ｗｅｂサービス用のリクエストとがある。リクエスト受付部２０３は、スループット制御用のリクエストの場合には、そのリクエストをスループット制御部２０５に送信し、それ以外のリクエストの場合には、キュー２０７にリクエストを格納する。スループット制御用のリクエストは、スループットの新規確保リクエスト、スループット情報の更新リクエスト、スループット情報削除リクエストがある。
【００２０】
スループット制御部２０５は、リクエスト受付部２０３から転送されたスループット制御用のリクエストの処理を行う。リクエスト実行スレッド２０８は、キュー２０７からリクエストを取り出しリクエストを実行する。なお、閾値用定数２０９は、サーバ管理者が管理するスループット判定のために用いる。
【００２１】
図３は、クライアントのソフトウェアの構成例を示す説明図である。ＢＰＥＬファイル３０１，３０２は、ユーザによって定義されたＢＰが記述されているファイルである。ＢＰ処理部３０４は、ＢＰＥＬファイル３０１，３０２を読み込み、ＢＰを実行し、他のサービスを呼び出す必要があれば、そのリクエストをリクエスト送出部３０６に送信する。リクエスト送出部３０６は、呼び出す必要のあるサービス３０９，３１０へリクエストを送信する。また、リクエスト送出部３０６には、Ｗｅｂサービスへのリクエストの送信回数を測定するスループット測定部３０７を有している。
【００２２】
ＷＳ抽出部３０３は、新しいＢＰＥＬファイル３０１，３０２と、そのインターフェースを記述したＷＳＤＬファイル３１２が配置される毎に実行される。ＷＳ抽出部３０３は、ＢＰＥＬファイル３０１，３０２に定義された呼び出されるＷｅｂサービスを抽出し、そのサービス名をスループット制御部３０８に送信する。スループット制御部３０８は、受理したそのサービス名に応じて、スループットの新規確保、スループット情報の更新、スループット情報の削除を行う。確保したスループット情報（例えば、ＢＰ、サービス、確保スループット）は、スループット情報格納ＤＢ３０５に格納される。なお、閾値用定数３１１は、スループットの管理に使用される。
【００２３】
＜サーバおよびクライアントのスループット情報格納ＤＢ＞
図４は、サーバのスループット情報格納ＤＢに格納されているスループット情報テーブルの構成例を示す説明図である。サーバ２００のスループット情報格納ＤＢ２０６には、スループット情報テーブル４０１を格納する。スループット情報テーブル４０１には、各クライアントが各Ｗｅｂサービスに対して確保したスループット情報を格納しており、クライアント、ＢＰ名、サービス、更新日、確保スループット、更新日からのリクエスト数を保持する。クライアント、ＢＰ名、サービスのカラムは、クライアント３００からスループットの新規確保リクエストが送信され、そのリクエストが受理されたときに入力される。更新日は、スループット制御部２０５が、図１６で示すように、一定時間毎に、確保スループットと実測スループット（更新日からのリクエスト数÷更新日からの経過時間から計算）の比較を行うたびに更新される。確保スループットは、毎秒あたりのリクエスト数を表し、スループットの新規確保リクエスト受理、スループット情報の更新リクエスト受理、およびサーバ２００による確保スループット値の更新処理によって更新される。更新日からのリクエスト数は、スループット測定部２０４（図２参照）によって管理され更新日から受付けたリクエスト数を確保している。図４に示すように、例えば、クライアント３００Ａは、ＢＰ１のビジネスプロセスを実行する場合に、Ｓｅｒｖｉｃｅ１のサービスをリクエストし、そのリクエストに対して確保されたリクエストは、毎秒１００リクエストである。また、更新日２００６年１月１１日からのリクエスト数は、３０３２９０であることが示されている。同様に、クライアント３００Ｂは、ＢＰ２のビジネスプロセスを実行する場合に、Ｓｅｒｖｉｃｅ２のサービスをリクエストし、そのリクエストに対して確保されたリクエストは、毎秒５０リクエストである。また、更新日２００６年１月７日からのリクエスト数は、８２４９であることが示されている。
【００２４】
図５は、サーバのスループット情報格納ＤＢに格納されるクライアント情報テーブルおよびドメイン振り分けテーブルの構成例を示す説明図である。サーバ２００のスループット情報格納ＤＢ２０６（図２参照）には、クライアント情報テーブル５０１およびドメイン振り分けテーブル５０２を格納する。クライアント情報テーブル５０１は、クライアント３００がどのドメインに属しているかを保存している。このクライアント情報テーブル５０１は、スループットの新規確保リクエストが受理されたときに、そのクライアント名とクライアントのドメインが入力される。ドメイン振り分けテーブル５０２は、サーバ管理者が設定し、クライアント３００のＵＲＬ（Uniform Resource Locator）がどのドメインに属するかを保存している。
【００２５】
図６は、サーバのスループット情報格納ＤＢに格納されるドメイン情報テーブルの構成例を示す説明図である。サーバ２００のスループット情報格納ＤＢ２０６（図２参照）には、ドメイン情報テーブル６０１を格納する。ドメイン情報テーブル６０１は、ドメイン毎に更新期間、許容スループット、および総確保スループットの情報を持つ。更新期間は、サーバ管理者が設定する。許容スループットは、サーバ管理者が設定し、そのドメインに属するクライアントで確保できるスループットの合計値を示す。総確保スループットは、現在そのドメインに属しているクライアントで確保されているスループットの合計値を示す。この総確保スループットのカラムは、スループット情報テーブル４０１の確保スループットのカラムに変更があるたびに更新される。
【００２６】
図７は、クライアントのスループット情報格納ＤＢに格納されるスループット情報テーブルの構成例を示す説明図である。クライアント３００のスループット情報格納ＤＢ３０５には、スループット情報テーブル７０１を格納する。スループット情報テーブル７０１は、ＢＰ、サービス、確保スループット、更新日からの送信リクエスト数を保持する。ＢＰのカラムは、スループットを確保したＢＰ名が入力される。サービスのカラムは、スループットを確保したサービス名が入力される。ＢＰおよびサービスのカラムは、スループットの新規確保時に入力される。確保スループットのカラムは、毎秒あたりの確保しているリクエスト数を表し、対象のサービスに対して、現在の確保しているスループットが入力される。確保スループットのカラムは、スループットの新規確保およびスループット値の更新時に入力される。
【００２７】
＜サーバのスループット測定部＞
スループット測定部２０４の動作を、図２を参照して説明する。
スループット測定部２０４は、クライアント３００（クライアント３００Ａ，３００Ｂ）からのリクエストを受ける毎に、リクエストのクライアント名、ＢＰ名、サービス名（呼び出しサービス名）を抽出する。その抽出したクライアント名およびサービス名をキーに、スループット情報格納ＤＢ２０６内のスループット情報テーブル４０１（図４参照）から該当レコードを取り出し、その更新日からのリクエスト数の値を更新する。該当レコードがない場合はエラーをクライアント３００に送信する。
【００２８】
＜クライアントとサーバ間のメッセージの流れ＞
図８は、クライアントとサーバ間のメッセージの流れを示す説明図である。まずクライアント３００は、新しいＢＰが配備されると、サーバ２００に対して新規確保リクエストを送信する（ステップＳ８０１）。サーバ２００は、その新規確保リクエストに対して応答する（ステップＳ８０２）。クライアント３００は、その新規確保リクエストに対して応答を受理すると、サーバ２００で動作しているサービスへリクエストを送信する（ステップＳ８０３）。サーバ２００は、そのリクエストに対して応答する（ステップＳ８０４）。クライアント３００は、より大きなスループットが必要と判断した場合、サーバ２００に対してスループットの更新リクエストを送信する（ステップＳ８０５）。サーバ２００は、その更新リクエストに対して応答する（ステップＳ８０６）。サーバ２００は、クライアント３００に対し不要なスループットが確保されていると判断した場合、スループットの更新リクエストを送信する（ステップＳ８０７）。クライアント３００は、ＢＰが配備されなくなったらサーバ２００に対しスループットの削除リクエストを送信する（ステップＳ８０８）。または、サーバ２００は、一定時間リクエストを送信しなかったクライアント３００に対し、スループットの削除リクエストを送信する（ステップＳ８０９）。
【００２９】
図９、図１０は、図８で示したリクエストおよび応答のメッセージを示す構成例である。クライアント３００とサーバ２００との情報の交換には、ＳＯＡＰ（Simple Object Access Protocol）が使用される。ステップＳ８０１からステップＳ８０８に対応するメッセージは、各々、新規確保リクエストメッセージ８０１ｍ、新規確保リクエストの応答メッセージ８０２ｍ、サービスへのリクエストのメッセージ８０３ｍ、サービスからの応答メッセージ８０４ｍ、クライアントからのスループット更新リクエストメッセージ８０５ｍ、更新リクエストの応答メッセージ８０６ｍ、サーバからのスループット更新リクエストメッセージ８０７ｍ、クライアントからのスループット削除リクエストメッセージ８０８ｍ、サーバからのスループット削除リクエストメッセージ８０９ｍに示す。
【００３０】
サーバ２００では、受信したリクエストについてクライアントとプロセスを判別する識別子として、ＨＴＴＰヘッダとＷＳリクエストの標準であるＳＯＡＰ（Simple Object Access Protocol）ヘッダを用いることができる。また、ＨＴＴＰヘッダやＳＯＡＰヘッダは、任意の情報を付加できるため、クライアント３００でサーバ２００にリクエストを送信する際に、ＨＴＴＰヘッダやＳＯＡＰヘッダに、クライアントの識別子とプロセスの識別子とを付加することで、サーバでクライアントとプロセスを識別することができる。
【００３１】
＜サーバのスループット制御部＞
スループット制御部２０５（図２参照）の動作を説明する。スループット制御部２０５は、スループットの新規確保、スループット情報の更新、スループット情報の削除の動作を行う。
【００３２】
＜スループットの新規確保＞
図１１は、スループット新規確保リクエスト受信時のサーバ側の処理を示すフローチャートである。スループットの新規確保は、クライアント３００がスループットの確保リクエストをリクエスト受付部２０３に送信することから開始される。リクエスト受付部２０３は、受信したリクエストがスループット確保リクエストか否かを判定する（ステップＳ１１０１）。スループットの確保リクエストには、クライアント３００のＵＲＬ、クライアント名、およびクライアント３００が実行するＢＰ名、サービス名、要求スループット値が含まれている。受信したリクエストがスループット確保リクエストである場合（ステップＳ１１０１，Ｙｅｓ）、リクエスト受付部２０３は、そのリクエストをスループット制御部２０５に送信する。
【００３３】
スループット制御部２０５は、受信したスループット確保リクエストの中から、クライアント３００のＵＲＬ・クライアント名・ＢＰ名・サービス名・要求スループット値を取り出す（ステップＳ１１０２）。スループット制御部２０５は、取り出した情報をもとにリクエストを受理するか否かを判定する（ステップＳ１１０３）。受理するか否かの判定は、図１２を参照して説明する。
【００３４】
図１２は、サーバ側のスループット割当可否の処理を示すフローチャートである。スループット制御部２０５（図２参照）は、取り出したクライアント名、ＢＰ名、サービス名を用いて、スループット情報テーブル４０１から該当レコードを抽出する（ステップＳ１２０１）。そして、該当レコードが有るか否かを判定する（ステップＳ１２０２）。
【００３５】
該当するレコードがある場合（ステップＳ１２０２，Ｙｅｓ）、スループット制御部２０５は、既にスループットは確保されているので不受理と判断する（ステップＳ１２０７）。該当レコードが無い場合（ステップＳ１２０２，Ｎｏ）、スループット制御部２０５は、要求されたスループットが確保できるか否かの判定を行う。この判定は、まずクライアント３００のＵＲＬからドメイン振り分けテーブル５０２（図５参照）を参照し該当ドメインを決定する（ステップＳ１２０３）。ドメイン情報テーブル６０１（図６参照）を参照し、該当ドメインのレコードを抽出する（ステップＳ１２０４）。スループット制御部２０５は、要求されたスループットが確保できるか否かを判定する（ステップＳ１２０５）。判定方法としては、該当レコードの「（許容スループット−総確保スループット）＞（要求スループット）」の真偽を計算する。真の場合（ステップＳ１２０５，Ｙｅｓ）は、受理と判断する（ステップＳ１２０６）。偽の場合（ステップＳ１２０５，Ｎｏ）は、要求されたスループットが確保できないため不受理と判断する（ステップＳ１２０７）。
【００３６】
図１１に戻り、不受理の場合（ステップＳ１１０３，Ｎｏ）は、クライアント３００に不受理を返答して終了する（ステップＳ１１０６）。受理の場合（ステップＳ１１０３，Ｙｅｓ）、スループット情報格納ＤＢ２０６の更新を行う（ステップＳ１１０４）。ＤＢの更新について図１３を参照して説明する。
【００３７】
図１３は、サーバ側のスループット割当時の処理を示すフローチャートである。スループット制御部２０５は、ドメイン情報テーブル６０１の該当レコードの総確保スループットカラムに（総確保スループット＋要求スループット）を新しい総確保スループット値として更新する（ステップＳ１３０１）。次に、スループット情報テーブル４０１を参照し、新規レコードを追加し、各項目についてクライアント、ＢＰ名、対象サービス、確保スループットを格納する（ステップＳ１３０２）。そして、スループット制御部２０５は、クライアント情報テーブル５０１を参照し、クライアント名をキーに該当レコードが有るか否かを判定する（ステップＳ１３０３）。該当レコードが有る場合（ステップＳ１３０３，Ｙｅｓ）、処理を終了する。該当レコードがない場合（ステップＳ１３０３，Ｎｏ）、新規レコードを追加しクライアントとドメイン振り分けテーブル５０２を参照して取得した該当ドメインを格納する（ステップＳ１３０４）。スループット情報格納ＤＢ２０６の更新が終了する。その後、図１１に戻り、クライアント３００に受理の応答を返し（ステップＳ１１０５）、一連の処理を終了する。
【００３８】
＜スループット情報の更新＞
スループット情報の更新について、適宜図２、図４、図６を参照して説明する。
スループット情報の更新は、クライアント３００側およびサーバ２００側の双方で行う。クライアント３００側は、クライアント３００が、スループット情報の更新リクエストをリクエスト受付部２０３に送信する。スループット情報の更新リクエストには、クライアント、ＢＰ名、対象サービス、新しい要求スループットの値が格納されている。リクエスト受付部２０３は、スループット情報の更新リクエストが送られてきたことを検知してそのスループット情報の更新リクエストをスループット制御部２０５に転送する。スループット制御部２０５は、スループット情報の更新リクエストの中から、クライアント名・ＢＰ名・対象サービス名・新しい要求スループットを取り出す。スループット制御部２０５は、スループット情報テーブル４０１からクライアント・ＢＰ名・サービスをキーにして該当レコードを抽出する。該当レコードの確保スループットと新しい要求スループットを比較して、新しい要求スループットのほうが小さければ、該当レコードの値を一時的に保存して、ドメイン情報テーブル６０１の総確保スループットの更新および該当レコードの更新を行う。ドメイン情報テーブル６０１の更新の詳細について、図１４を参照して説明する。
【００３９】
図１４は、サーバ側で割り当てたスループット値を更新する場合のＤＢの処理を示すフローチャートである。スループット制御部２０５（図２参照）は、リクエストに含まれているクライアント名から、クライアント情報テーブル５０１（図５参照）からクライアントのドメインを抽出し、スループット情報テーブル４０１（図４参照）から得られた確保スループット（Ａ）を抽出し、リクエストに含まれている要求スループット（Ｂ）を抽出する（ステップＳ１４０１）。クライアント３００のドメインをキーにして、ドメイン情報テーブル６０１の該当レコードを抽出する（ステップＳ１４０２）。該当レコードの総確保スループットのカラムを（現在の総確保スループットの値−Ａ＋Ｂ）に更新する（ステップＳ１４０３）。
【００４０】
具体的には、ステップＳ１４０１において、クライアント３００Ａの場合、図４を参照して、確保スループットから、確保スループット（Ａ）は毎秒１００リクエストとなる。また、要求スループット（Ｂ）を、例えば、毎秒２００リクエストとする。ステップＳ１４０２において、図５を参照してクライアント３００Ａの名のドメイン名は、同一ドメインとなり、そのドメインの総確保スループットは、図６を参照して、毎秒１００リクエストを得る。よって、ステップＳ１４０３において、（現在の総確保スループットの値−Ａ＋Ｂ）は、１００−１００＋２００と計算でき、毎秒２００リクエスト（２００／ｓｅｃ）となる。
【００４１】
新しい要求スループット値のほうが大きければ、ドメイン情報テーブル６０１の総確保スループットのカラムを参照し、クライアント３００のドメインに対して、新しい要求スループットについて割当可能か否かを判定する。割当可能か否かの判定の詳細は、図１５を参照して説明する。
【００４２】
図１５は、サーバ側で、クライアントから要求されたスループットについて割当可否の判定処理を示すフローチャートである。スループット制御部２０５（図２参照）は、リクエストに含まれているクライアント名からクライアント情報テーブル５０１（図５参照）を参照してクライアント３００のドメインを抽出し、スループット情報テーブル４０１（図４参照）から得られた確保スループット（Ａ）を抽出し、リクエストに含まれている要求スループット（Ｂ）を抽出する（ステップＳ１５０１）。次に、クライアント３００のドメインをキーにして、ドメイン情報テーブル６０１（図６参照）の該当レコード（総確保スループット）を抽出する（ステップＳ１５０２）。そして、スループット制御部２０５は、「（６０１の総確保スループット−Ａ＋Ｂ）＞該当レコードの許容スループット」で有るか否かを判定する（ステップＳ１５０３）。判定結果が偽の場合（ステップＳ１５０３，Ｎｏ）は、割当可能と判断する（ステップＳ１５０４）。判定結果が真の場合（ステップＳ１５０３，Ｙｅｓ）は、割当不可能と判断する（ステップＳ１５０５）。
【００４３】
スループット制御部２０５は、割当可能と判断すれば、現在の確保スループット値（Ｃ）を一時的に保存し、スループット情報テーブル４０１の該当レコードの確保スループットを更新する。また、クライアントをキーにクライアント情報テーブル５０１を参照し該当レコードを抽出する。そのクライアント情報テーブル５０１の該当レコードのドメインカラムの値をキーにドメイン情報テーブル６０１の該当レコードを抽出する。ドメイン情報テーブル６０１の総確保スループットを新しい総確保スループット（現在の総確保スループット―Ｃ＋要求されたスループット）に更新する。次に、サーバ２００側で定期的に行うスループット情報の更新を、図１６を参照して説明する。
【００４４】
図１６は、サーバ側スループット制御部によるスループット情報の更新処理を示すフローチャートである。サーバ２００側のスループット制御部２０５（図２参照）は、スループット情報の更新の動作を行う。一定間隔ごとに、スループット情報テーブル４０１（図４参照）のレコードの全てを参照する（ステップＳ１６０１）。各レコードについて更新対象レコードか否かを判定する（ステップＳ１６０２）。この判定の詳細について、図１７を参照して説明する。
【００４５】
図１７は、サーバ側のスループット情報更新時にスループット情報テーブルのレコードのうち対象となるレコードの判定処理を示すフローチャートである。スループット制御部２０５は、まず、クライアント情報テーブル５０１を参照しクライアント名からドメインを抽出し（ステップＳ１７０１）、そのドメインのカラム値をキーに、ドメイン情報テーブル６０１から該当レコードを抽出し（ステップＳ１７０２）、該当レコードの更新期間を抽出する（ステップＳ１７０３）。そして、スループット制御部２０５は、更新期間が無期限か否かを判定する（ステップＳ１７０４）。更新期間が無期限の場合（ステップＳ１７０４，Ｙｅｓ）、非対象レコードとなる（ステップＳ１７０８）。更新期間が無期限でない場合（ステップＳ１７０４，Ｎｏ）、すなわち、更新期間が設定されている場合、スループット制御部２０５は、スループット情報テーブル４０１の該当レコードから更新日カラムを取得する（ステップＳ１７０５）。そして、（（現在日時−更新日カラムの値）＜更新間隔）で有るか否かを判定する（ステップＳ１７０６）。判定結果が真の場合（ステップＳ１７０６，Ｙｅｓ）は、非対象レコードとなる（ステップＳ１７０８）。判定結果が偽の場合（ステップＳ１７０６，Ｎｏ）は、対象レコードとなる（ステップＳ１７０７）。
【００４６】
図１６に戻り、対象レコードである場合（ステップＳ１６０２，Ｙｅｓ）、ステップＳ１６０３の処理に移る。対象レコードでない場合（ステップＳ１６０２，Ｎｏ）、次のレコードに移る（ステップＳ１６０１）。ステップＳ１６０３において、スループット制御部２０５は、「確保スループット値×サーバ管理者が管理する閾値用定数２０９」を閾値とし、測定スループットが閾値未満であるか否かを判定する。測定スループットが閾値未満でない場合（ステップＳ１６０３，Ｎｏ）、スループット制御部２０５は、該当レコードの更新日の更新とリクエスト数のクリアを行い（ステップＳ１６０６）、次のレコードへ移る。測定スループットが閾値未満である場合（ステップＳ１６０３，Ｙｅｓ）、スループット制御部２０５は、閾値を新たな確保スループット（確保値）として採用し、スループット情報テーブル４０１およびドメイン情報テーブル６０１を更新する（ステップＳ１６０４）。そして、スループット制御部２０５は、その新たな確保スループットをクライアント３００側に伝達する（ステップＳ１６０５）。クライアント側に伝達した後、該当レコードの更新日の更新とリクエスト数のクリアを行い（ステップＳ１６０６）、次のレコードに移る。
【００４７】
＜スループット情報の削除＞
スループット情報の削除について説明する。
スループット情報の削除は、クライアント３００からスループット情報の削除リクエストを送信、または、サーバ２００側で一定間隔以上アクセスがない場合に行われる。サーバ２００側で一定間隔以上アクセスがない場合に行われるサーバ２００側でのスループット情報の削除について、図１８を参照して説明する。
【００４８】
図１８は、サーバ側でクライアントからのアクセス有無の判定処理を示すフローチャートである。図１８の処理は、スループット制御部２０５（図２参照）による処理である。スループット制御部２０５は、スループット情報テーブル４０１を参照し一定間隔ごとに各テーブルについて繰り返す（ステップＳ１８０１）。まず、クライアントのカラムからクライアント名を抽出し、クライアント情報テーブル５０１を参照してクライアント名からドメインを抽出する（ステップＳ１８０２）。次に、そのドメインをキーにドメイン情報テーブル６０１から該当レコードを抽出する（ステップＳ１８０３）。そして、該当レコードの更新期間を抽出する（ステップＳ１８０４）。その後、更新期間が無期限か否かを判定する（ステップＳ１８０５）。
【００４９】
更新期間が無期限の場合（ステップＳ１８０５，Ｙｅｓ）、アクセス有りとする（ステップＳ１８０９）。更新期間が無期限でない場合（ステップＳ１８０５，Ｎｏ）、すなわち、更新期間が設定されている場合、スループット情報テーブル４０１のレコードから更新日を取得する（ステップＳ１８０６）。そして、（（現在日時−更新日）＜更新間隔）か否かを判定する（ステップＳ１８０７）。判定結果が真の場合（ステップＳ１８０７，Ｙｅｓ）、まだ更新間隔内であるのでアクセス有りとする（ステップＳ１８０９）。判定結果が偽の場合（ステップＳ１８０７，Ｎｏ）、スループット情報テーブル４０１の更新日からのリクエスト数のカラム値を参照し、０より大であるか否かを判定する（ステップＳ１８０８）。０より大であれば（ステップＳ１８０８，Ｙｅｓ）、アクセス有りとする（ステップＳ１８０９）。０であれば（ステップＳ１８０８，Ｎｏ）、アクセス無しとする（ステップＳ１８１０）。アクセス無しの場合、該当レコードを削除する（ステップＳ１８１１）。
【００５０】
スループット情報の削除リクエストには、クライアント名・ＢＰ名・削除対象サービス名が格納されている。スループット情報の削除リクエストを受け取ったリクエスト受付部２０３は、スループット情報の削除リクエストが送られてきたことを検知して、そのリクエストをスループット制御部２０５に転送する。スループット制御部２０５は転送されたスループット情報の削除リクエストの中から、クライアント名・クライアントのドメイン・削除対象サービス名を取り出す。
【００５１】
スループット制御部２０５は、スループット情報テーブル４０１を参照し、クライアント・ＢＰ名・サービスをキーにして該当レコードを抽出する。該当レコード・クライアント情報テーブル５０１を参照し、ドメイン情報テーブル６０１の総確保スループットカラムの値を更新する。次に、スループット情報テーブル４０１の該当レコードを参照し、クライアント３００のみをキーにして該当レコードを参照する。該当レコードが無ければ、クライアント情報テーブル５０１を参照し、クライアント３００をキーにして該当レコードを抽出し、その該当レコードを削除する。最後に、スループット情報テーブル４０１の該当レコードを削除する。
【００５２】
＜クライアントのリクエスト送信時の処理＞
クライアント３００のリクエスト送信時の動作を説明する。
図３に示したように、ＢＰＥＬファイル３０１、３０２は、ユーザによって定義されたＢＰが記述されている。ＢＰ処理部３０４は、ＢＰＥＬファイル３０１，３０２を読み込みＢＰを実行し、他のサービスを呼び出す必要があればそのリクエストをリクエスト送出部３０６に送信する。リクエストの送信処理について、図１９を参照して説明する。
【００５３】
図１９は、クライアント側でリクエスト送信時の処理を示すフローチャートである。まず、ＢＰ処理部３０４（図３参照）の実行スレッド内でＷＳの呼出が発生し、リクエストが生成される（リクエスト発生）（ステップＳ１９０１）。ＢＰ処理部３０４は、生成されたリクエストをリクエスト送出部３０６に転送する（ステップＳ１９０２）。スループット測定部３０７は、リクエストの呼び出し元ＢＰと呼び出し先サービス（即ちＷＳ）を抽出する（ステップＳ１９０３）。スループット測定部３０７は、抽出したＢＰとサービスをキーにスループット情報テーブル７０１から該当レコードを抽出し（ステップＳ１９０４）、該当レコードの更新日からの送信リクエスト数のカラムに１を追加する（ステップＳ１９０５）。最後に、リクエスト送出部３０６は、リクエストをＷＳに向けて送信する（ステップＳ１９０６）。
【００５４】
＜クライアントのＷＳ抽出処理＞
クライアント３００のＷＳ抽出部３０３は、新しいＢＰＥＬファイル３０１，３０２とそのインターフェースを記述したＷＳＤＬファイル３１２が配置されるごとに実行される。ＷＳ抽出部３０３は、ＢＰＥＬファイル３０１，３０２に定義された呼び出されるＷｅｂサービスを抽出し、そのサービス名をスループット制御部３０８に送信する。抽出の実施例をＢＰＥＬ４ＷＳの仕様を用いて図２０を参照して説明する。
【００５５】
図２０は、ビジネスプロセス（ＢＰ）が呼出すＷｅｂサービス（ＷＳ）の抽出方法の一実施例を示す説明図である。図２０の処理は、ＷＳ抽出部３０３（図３参照）による処理である。ＢＰＥＬ４ＷＳでＷＳを呼出す場合は＜ｉｎｖｏｋｅ＞要素で示されているため、その＜ｉｎｖｏｋｅ＞要素をＢＰＥＬファイル３０１，３０２から抽出する（ステップＳ２００１）。＜ｉｎｖｏｋｅ＞要素には呼び出し先の情報がｐａｒｔｎｅｒＬｉｎｋ属性として設定されているため、そのｐａｒｔｎｅｒＬｉｎｋ名（Ａ）を抽出し、ｐａｒｔｎｅｒＬｉｎｋの情報は、＜ｐａｒｔｎｅｒＬｉｎｋ＞要素に記述されているため、（Ａ）の情報を元に、＜ｐａｒｔｎｅｒＬｉｎｋｓ＞要素から該当する＜ｐａｒｔｎｅｒＬｉｎｋ＞要素を抽出する（ステップＳ２００２）。その要素に記述されているｐａｒｔｎｅｒＬｉｎｋＴｙｐｅ名（Ｂ）、ｐａｒｔｎｅｒＲｏｌｅ名（Ｃ）を抽出し、ｐａｒｔｎｅｒＬｉｎｋＴｙｐｅ、ｐａｒｔｎｅｒＲｏｌｅについてはＢＰのインターフェースを定義したＷＳＤＬに記述されているため、ＷＳＤＬファイル３１２から（Ｂ）、（Ｃ）の情報を元に＜ｐａｒｔｎｅｒＬｉｎｋＴｙｐｅ＞要素を抽出する（ステップＳ２００３）。そして、その要素に記述されているｐｏｒｔＴｙｐｅ名（Ｄ）を抽出し、（Ｄ）の情報を元に、＜ｂｉｎｄｉｎｇ＞要素を抽出する（ステップＳ２００４）。そのｎａｍｅ名（Ｅ）を抽出し、（Ｅ）を元に、＜ｐｏｒｔ＞要素を抽出する（ステップＳ２００５）。そして、その＜ｐｏｒｔ＞要素に含まれているｎａｍｅ属性からサービス名を取得する（ステップＳ２００６）。
【００５６】
＜クライアントのスループットの新規確保＞
スループットの新規確保を、図２１を参照して説明する（適宜図３、図７参照）。
図２１は、ビジネスプロセス（ＢＰ）新規配備時のクライアントの処理を示すフローチャートである。スループットの新規確保は、新しいＢＰＥＬファイル３０１，３０２とそのインターフェースを記述したＷＳＤＬファイル３１２が配置された場合に開始される。新しいＢＰＥＬファイル３０１，３０２が定義されると、ＷＳ抽出部３０３が解析し、Ｗｅｂサービスの呼び出しが有りか無しかを判定する（ステップＳ２１０１）。Ｗｅｂサービスの呼び出しが無い場合（ステップＳ２１０１，Ｎｏ）は、処理を終了する。Ｗｅｂサービスの呼び出しがある場合（ステップＳ２１０１，Ｙｅｓ）は、呼び出すＷｅｂサービスの情報をスループット制御部３０８に送信する。
【００５７】
スループット制御部３０８（図３参照）は、呼び出すＷｅｂサービス分を繰り返す（ステップＳ２１０２）。具体的には、それぞれのＷｅｂサービスに対してクライアント３００のＵＲＬ・クライアント名・ＢＰ名・対象サービス名・クライアント毎に決定した確保スループットを含めたスループットの新規確保リクエストを生成し、リクエスト送出部３０６経由で送信する（ステップＳ２１０３）。送信したスループットの新規確保リクエストに対してＷｅｂサービスからスループット制御部３０８に応答があり、その応答にはリクエストの受理・不受理が格納されているので、その応答内容を判定する（ステップＳ２１０４）。不受理の応答である場合（ステップＳ２１０４，Ｎｏ）、不受理の理由がスループット不足場合か否かを判定する（ステップＳ２１０７）。不受理の理由がスループット不足である場合（ステップＳ２１０７，Ｙｅｓ）は、一定時間待ち（ステップＳ２１０５）、再度そのＷｅｂサービスに対してスループットの新規確保リクエストを送信する（ステップＳ２１０３）。不受理の理由がスループット不足でない場合（ステップＳ２１０７，Ｎｏ）、すなわち、既に割当済みの場合は、次のＷｅｂサービスのスループット確保処理に移る。サーバからの応答が受理の場合（ステップＳ２１０４，Ｙｅｓ）は、ＢＰ、サービス、確保スループットをスループット情報格納ＤＢ３０５のスループット情報テーブル７０１（図７参照）に登録する（ステップＳ２１０６）。
【００５８】
＜サーバからクライアントへのスループット情報の更新＞
スループット情報の更新について説明する。
スループット情報の更新は、クライアント３００側・サーバ２００側の双方で行う。サーバ２００からの更新について、図２２を参照して説明する。
【００５９】
図２２は、サーバ側からクライアントへのスループット値の更新処理を示す説明図である。サーバ２００側は、図１６で説明したように、所定の条件を満たすと、スループット変更リクエストを生成する（ステップＳ２２０１）。そして、そのリクエストをクライアント３００に送信する（ステップＳ２２０２）。このリクエストのメッセージ（電文）には、スループットが変更になったＷｅｂサービス名・対象ＢＰ名・新しく設定されたスループットの値が含まれている。クライアント３００は、このリクエストを受信する（ステップＳ２２０３）と、スループット情報格納ＤＢ３０５のスループット情報テーブル７０１（図７参照）を参照し、ＢＰ名・Ｗｅｂサービス名をキーに該当レコードを抽出する（ステップＳ２２０４）。そして、そのレコードの確保スループット値を更新する（ステップＳ２２０５）。
【００６０】
＜クライアントのスループット情報の更新＞
クライアント側のスループット情報の更新について、図２３を参照して説明する。
図２３は、クライアント側スループット制御部によるスループット情報の更新処理を示すフローチャートである。図２３に示す処理は、スループット制御部３０８（図３参照）による処理である。スループット制御部３０８は、一定間隔毎にスループット情報テーブル７０１（図７参照）の全てのレコードを参照（ステップＳ２３０１）し、更新日からの送信リクエスト数から（更新日からの送信リクエスト数÷一定間隔の秒数）を計算し実測スループット値を求める。次に、「確保スループット値×クライアント管理者が管理する閾値用定数３１１」を閾値とし、その実測スループット値が閾値以上か否かを判定する（ステップＳ２３０２）。閾値以上の場合（ステップＳ２３０２，Ｙｅｓ）は、サーバ２００に対して、現在のスループットで確保可能か否かについて更新リクエストを送信し問い合わせる（ステップＳ２３０３）。サービスからの問合せ応答があれば、サーバ２００からの応答がスループット割当て可能か否かを判定する（ステップＳ２３０４）。スループット割当て可能の場合（ステップＳ２３０４，Ｙｅｓ）、現在のスループット値を新しい確保スループットとして採用し該当レコードを更新し（ステップＳ２３０５）、ステップＳ２３０８へ進む。ステップＳ２３０４において、スループット割当て不可の場合（ステップＳ２３０４，Ｎｏ）、ステップＳ２３０８へ進む。
【００６１】
ステップＳ２３０２において、閾値未満の場合（ステップＳ２３０２，Ｎｏ）は、余分なスループットを確保していると判断し閾値を新しい確保スループットとして採用し該当レコードを更新する（ステップＳ２３０６）。そして、その確保スループットを確保済みのスループット値更新リクエスト内に格納して、リクエスト送出部経由でサーバ２００に送信する（ステップＳ２３０７）。最後にリクエスト数の更新として、更新日からのリクエスト数を０にする（ステップＳ２３０８）。
【００６２】
＜クライアントのスループット情報の削除＞
スループット情報の削除について、図２４を参照して説明する。
図２４は、ビジネスプロセス（ＢＰ）削除時におけるクライアント側での処理を示すフローチャートである。図２４に示す処理は、スループット制御部３０８（図３参照）による処理である。スループット情報の削除は、配置されていたＢＰが削除する場合に行われる（ステップＳ２４０１）。ＢＰが削除されようとすると、スループット制御部３０８は、スループット情報テーブル７０１（図７参照）を参照し、削除対象のＢＰのレコードを抽出する（ステップＳ２４０２）。そして、以下の処理は、その各該当レコードに対して繰り返される（ステップＳ２４０３）。まず、サービスのカラムを参照し、ＷＳを抽出する（ステップＳ２４０４）。抽出したＷＳに対してスループット情報の削除リクエストを送信する（ステップＳ２４０５）。その後、該当レコードを削除する（ステップＳ２４０６）。
【００６３】
本実施形態では、クライアント３００は、Ｗｅｂサービス（ＷＳ）を実行するのに必要なスループット要求として単位時間あたりのリクエスト数を、Ｗｅｂサービスを実行する前に予め前記サーバにスループット要求を送信し、サーバ２００は、前記スループット要求の単位時間あたりのリクエスト数を確保している。
【００６４】
本発明によるサーバ２００は、クライアント３００によるプロセスの処理中に呼び出されたＷＳのリクエストについて、そのプロセスに対して該当サーバが処理できる総スループットのうちその一部分を割り当てる手段と、そのリクエストがそのプロセスに割り当てられたスループットの範囲内であるか否かを判定する手段と、プロセスからのリクエスト受信状況を監視し不要なスループットを削除する手段と、プロセスに割り当てたスループットを変更するとその変更についてクライアントに通知する手段を備えることを特徴とする。
【００６５】
本発明によるプロセスを実行するクライアント３００は、プロセスを新規に配備するときに一定量のスループットの確保をサーバ側に通知する手段と、プロセスの実行状況を監視しプロセスで呼び出す各サーバについて確保しているスループットの変更が必要なときにその変更をサーバに通知する手段と、プロセスを削除するときに確保していたスループットをサーバ側に削除するように通知する手段を備えることを特徴とする。
【００６６】
本発明によれば、サーバ２００がリクエストメッセージからクライアントとその実行中のプロセスを識別する手段と、識別したクライアントとプロセスからそれに割り当てたスループットを識別する手段と、識別したクライアントとプロセスからのリクエストがそれに割り当てられたスループット内であればリクエストを処理することを特徴とする。これにより、クライアントからのリクエストの集中によるサーバのサービス不能状態に陥ることはなく、クライアント３００が、ビジネスプロセスを実行する上で必要なＷｅｂサービス（ＷＳ）のスループットを確保することができる。
【００６７】
本発明によるサーバ２００では、受信したリクエストについてクライアントとプロセスを判別する識別子として、ＨＴＴＰヘッダとＷＳリクエストの標準であるＳＯＡＰ（Simple Object Access Protocol）ヘッダを用いることができる。
【図面の簡単な説明】
【００６８】
【図１】本発明の実施形態のスループット管理システムのハードウェア構成を示すブロック図である。
【図２】サーバのソフトウェアの構成例を示す説明図である。
【図３】クライアントのソフトウェアの構成例を示す説明図である。
【図４】サーバのスループット情報格納ＤＢに格納されているスループット情報テーブルの構成例を示す説明図である。
【図５】サーバのスループット情報格納ＤＢに格納されるクライアント情報テーブルおよびドメイン振り分けテーブルの構成例を示す説明図である。
【図６】サーバのスループット情報格納ＤＢに格納されるドメイン情報テーブルの構成例を示す説明図である。
【図７】クライアントのスループット情報格納ＤＢに格納されるスループット情報テーブルの構成例を示す説明図である。
【図８】クライアントとサーバ間のメッセージの流れを示す説明図である。
【図９】図８で示したリクエストおよび応答のメッセージを示す構成例である。
【図１０】図８で示したリクエストおよび応答のメッセージを示す構成例である。
【図１１】スループット新規確保リクエスト受信時のサーバ側の処理を示すフローチャートである。
【図１２】サーバ側のスループット割当可否の処理を示すフローチャートである。
【図１３】サーバ側のスループット割当時の処理を示すフローチャートである。
【図１４】サーバ側で割り当てたスループット値を更新する場合のＤＢの処理を示すフローチャートである。
【図１５】サーバ側で、クライアントから要求されたスループットについて割当可否の判定処理を示すフローチャートである。
【図１６】サーバ側スループット制御部によるスループット情報の更新処理を示すフローチャートである。
【図１７】サーバ側のスループット情報更新時にスループット情報テーブルのレコードのうち対象となるレコードの判定処理を示すフローチャートである。
【図１８】サーバ側でクライアントからのアクセス有無の判定処理を示すフローチャートである。
【図１９】クライアント側でリクエスト送信時の処理を示すフローチャートである。
【図２０】ビジネスプロセス（ＢＰ）が呼出すＷｅｂサービス（ＷＳ）の抽出方法の一実施例を示す説明図である。
【図２１】ビジネスプロセス（ＢＰ）新規配備時のクライアントの処理を示すフローチャートである。
【図２２】サーバ側からクライアントへのスループット値の更新処理を示す説明図である。
【図２３】クライアント側スループット制御部によるスループット情報の更新処理を示すフローチャートである。
【図２４】ビジネスプロセス（ＢＰ）削除時におけるクライアント側での処理を示すフローチャートである。
【符号の説明】
【００６９】
１００ ネットワーク
２００ サーバ
２０３ リクエスト受付部
２０４ スループット測定部
２０５ スループット制御部
２０６ スループット情報格納ＤＢ
２１０ Ｗｅｂサービス（ＷＳ）の定義ファイル
２２１ ＨＤＤ
２２２ ＣＰＵ
２２３ メモリ
２２４ ＮＩＣ
３００，３００Ａ，３００Ｂ クライアント
３０１，３０２ ＢＰＥＬファイル
３０３ Ｗｅｂサービス（ＷＳ）抽出部
３０５ スループット情報格納ＤＢ
３０６ リクエスト送出部
３０７ スループット測定部
３０８ スループット制御部
３２１ ＨＤＤ
３２２ ＣＰＵ
３２３ メモリ
３２４ ＮＩＣ
４０１ スループット情報テーブル
５０１ クライアント情報テーブル
６０１ ドメイン情報テーブル
７０１ スループット情報テーブル
【技術分野】
【０００１】
本発明は、ビジネスプロセスを実行する上で必要なＷｅｂサービスのスループットを確保することができるスループット管理方法およびスループット管理システムに関する。
【背景技術】
【０００２】
従来の分散処理技術といえば、ＣＯＲＢＡ（Common Object Request Broker Architecture）（登録商標）やＪａｖａ（登録商標）−ＲＭＩといった比較的閉じたネットワークで行われるものが多かった。しかし、近年、インターネットの普及によりインターネットを介しての分散処理が行われるようになった。その代表的な例が、Ｗｅｂサービス（以下、ＷＳという。）である。ＷＳは、ＨＴＴＰ（HyperText Transfer Protocol）を利用してサービスを提供する。サービスを提供する側（サーバ側）は、ＷＳＤＬ（Web Services Description Language）を用いて、提供するサービスの内容および仕様を記述する。サービスを利用する側（クライアント側）は、サーバから提供されたＷＳＤＬを読み込み、記述された仕様にそってサービスを利用する。この際、クライアントからサーバにサービスを要求することを、「リクエストを送信する」という。
【０００３】
また、ＷＳの普及により、複数のＷＳを結合して実行する場合のプロセスを記述するプロセス記述言語の開発が進められている。プロセス記述言語の主な仕様に、Ｍｉｃｒｏｓｏｆｔ（登録商標）、ＩＢＭ（登録商標）、ＢＥＡ（登録商標）が提唱するＢＰＥＬ４ＷＳ（Business Process Execution Language for Web Services）と呼ばれる仕様が知られている（例えば、非特許文献１参照）。
【０００４】
ＷＳを利用したプロセスの処理が普及すると様々なサービスが相互に呼ばれることなり、各ＷＳの負荷分散（スループット管理）が必要となることが予想される。ＨＴＴＰの場合、従来技術の負荷分散処理は、サーバ側による負荷分散が一般的であった。サーバ側による負荷分散処理は、基本的にある一定量までのリクエストを適切にサーバに振り分け、それ以上のリクエストが到達すると、そのリクエストを無視するようになっている。この方式では、クライアントはリクエストが無視されたと判断すると、リクエストを再送、もしくはリクエストをキャンセルする。
【非特許文献１】IBM、“Business Process Execution Language for Web Services version 1.1“、[online]、[平成１８年９月１１日]、インターネット<URL:http://www-106.ibm.com/developerworks/library/ws-bpel>
【発明の開示】
【発明が解決しようとする課題】
【０００５】
従来のサーバ側での負荷分散処理を行うと、プロセスを実行中に呼出されたＷＳが、既に一定量以上のリクエストを受付けていた場合、そのリクエストは無視される。プロセスは複数のＷＳへのリクエストを集めたものであるため、１つでもＷＳの呼出に失敗すると、それがプロセス全体の処理に影響し、そのプロセスは再送処理などにより中断されてしまう、又は、異常終了となってしまい、安定的なプロセスの実行が困難となる。プロセスは複数のＷＳにリクエストを送信するため、もし複数のＷＳへのリクエストが安定的に処理されなければ、安定的なプロセスの実行は困難になる。
【０００６】
そのため、できる限りリクエストが無視されるケースを取り除く必要がある。この場合考えられるのが、サーバで受付けるリクエスト件数のピーク時（スループット要求の高いとき）に合わせてサーバマシンを調達することである。しかし、この考え方が有効なのは、ピーク時（スループット要求の高いとき）とオフピーク時（スループット要求の低いとき）の差があまり無いケースである。一般的に、ＨＴＴＰのリクエストは応答時間が短く、オフピーク時は負荷が小さく、ピーク時は極端に負荷が大きくなる傾向がある。そのため、ピーク時に合わせたサーバマシンを調達することは過剰なコストをかけることになる。このことを考えると、ピーク時に合わせたサーバマシンの調達というのは最適な構成法とはいえない。一方、リクエスト元によってリクエストの受付を判断するアクセス制御を用いることも考えられる。しかし、特定のリクエスト元のみにアクセスを許可する方法は、不公平であり、また、その特定のリクエスト元のリクエスト送出量が少なければ、サーバの処理能力を十分に活用することがないので、あまり有効な構成法とはいえない。
【０００７】
本発明は、前記の課題を解決するための発明であって、ビジネスプロセスを実行する上で必要なＷｅｂサービスのスループットを確保することができるスループット管理方法およびスループット管理サーバを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、サーバとクライアントのそれぞれにリクエストの受付に関する制御処理部（例えば、スループット制御部２０５，３０８）を有し、その制御処理部を用いてサーバとクライアント間でリクエストの制御情報を交換することで、サーバとプロセスを実行するクライアントのそれぞれの処理時間、すなわち品質を保証するスループットを確保する。このような方法によれば、サーバがリクエストの過剰受付によるサービス不能状態に陥ることなく、かつ、クライアントで実行しているプロセスがＷｅｂサービス（ＷＳ）の呼出で遅延することなく正常に実行でき、そしてサーバの処理能力を有効に使用することができる。
【発明の効果】
【０００９】
本発明によれば、ビジネスプロセスを実行する上で必要なＷｅｂサービスのスループットを確保することができる。
【発明を実施するための最良の形態】
【００１０】
以下、本発明の実施形態について図面を参照して説明する。
図１は、本発明の実施形態のスループット管理システムのハードウェア構成を示すブロック図である。スループット管理システムは、１台または複数のクライアント３００、１台または複数のサーバ２００より構成される。クライアント３００は、ハードディスク（ＨＤＤ）３２１、中央演算装置（ＣＰＵ）３２２、メモリ３２３、ネットワークカード（ＮＩＣ）３２４などから構成される。ＨＤＤ３２１は、クライアント３００が処理を実行するための各種データを保存する。ＣＰＵ３２２は、メモリ３２３に格納される各種プログラムを実行する。メモリ３２３は、クライアント３００が処理を実行する各種プログラムおよび一時的なデータを保存する。ＮＩＣ３２４は、ネットワーク１００を介して、他のクライアントまたはサーバ２００と各種データやコマンドを交換する。具体的には、ＮＩＣ３２４は、リクエスト送出部３０６からの要求に応じて、ネットワーク１００を介してサーバ２００に、リクエストを送信する。クライアント３００とサーバ２００は、ある通信路、例えばＥｔｈｅｒｎｅｔ（登録商標）などの汎用的なネットワーク１００を介して接続されている。なお、ＣＰＵはCentral Processing Unitの略、ＨＤＤはHard Disk Driveの略、ＮＩＣはNetwork Interface Cardの略である。
【００１１】
クライアント３００のＨＤＤ３２１には、ビジネスプロセス（以下、ＢＰという。）を定義したＢＰＥＬファイル３０１、確保したスループットの情報を格納するスループット情報格納ＤＢ３０５、ＢＰのインターフェースを定義したＷＳＤＬファイル３１２が格納される。なお、ＢＰＥＬはBusiness Process Execution Languageの略、ＷＳＤＬはWeb Services Description Languageの略である。
【００１２】
メモリ３２３には、クライアント３００が処理を実行する各種プログラムおよび一時的なデータが保存され、具体的には、ＢＰＥＬファイル３０１からスループットの確保が必要なＷｅｂサービスを抽出するＷＳ抽出部３０３、ＢＰＥＬファイル３０１を読み込み、ＢＰを実行するＢＰ処理部３０４、Ｗｅｂサービスへのリクエストを送信するリクエスト送出部３０６、Ｗｅｂサービスへのリクエストの送信回数を測定するスループット測定部３０７、スループット情報の制御を行うスループット制御部３０８のプログラム、およびスループットの管理に使用する閾値用定数３１１が格納される。
【００１３】
また、サーバ２００は、ハードディスク（ＨＤＤ）２２１、中央演算装置（ＣＰＵ）２２２、メモリ２２３、ネットワークカード（ＮＩＣ）２２４などから構成される。ＨＤＤ２２１は、サーバ２００が処理を実行するための各種データを保存する。ＣＰＵ２２２は、メモリ２２３に格納される各種プログラムを実行する。メモリ２２３は、サーバ２００が処理を実行する各種プログラムおよび一時的なデータを保存する。ＮＩＣ２２４は、ネットワーク１００を介して、クライアント３００と各種データやコマンドを交換する。具体的には、ネットワーク１００を介して送られてくるクライアント３００のデータを受信する。
【００１４】
サーバ２００のＨＤＤ２２１には、Ｗｅｂサービスを定義したＷＳ定義ファイル２１０、スループット情報を格納するスループット情報格納ＤＢ２０６が格納される。
【００１５】
メモリ２２３には、サーバ２００が処理を実行する各種プログラムおよび一時的なデータが保存され、具体的には、クライアント３００からのリクエストを受付けるリクエスト受付部２０３、クライアント３００からのリクエストを受信した回数を測定するスループット測定部２０４、スループット情報を制御するスループット制御部２０５のプログラム、およびサーバ管理者が管理するスループット判定のために用いる閾値用定数２０９が格納される。
【００１６】
クライアント３００側のスループット制御部３０８とサーバ２００側のスループット制御部２０５が、それぞれスループットに関する情報を交換することでスループットの管理を行う。その情報の交換には、ＳＯＡＰ（Simple Object Access Protocol）が使用される。
【００１７】
図２は、サーバのソフトウェアの構成例を示す説明図である。サーバ２００は、クライアント３００（３００Ａ，３００Ｂ）からのリクエストを受信し、リクエスト受付部２０３で受付ける。クライアント３００Ａ，３００Ｂは、複数のクライアント３００の例として示している。クライアント３００は、クライアント端末利用者の入力を受付けて、ＢＰを実行する。ＢＰ実行中にＷｅｂサービスを呼び出す必要がある場合は、リクエストを生成し、リクエスト受付部２０３に送付する。
【００１８】
リクエスト受付部２０３は、スループット測定部２０４を用いて、リクエスト毎のスループットの測定を行う。スループット測定部２０４で得られたリクエスト毎のスループットは、スループット情報格納ＤＢ２０６に格納される。
【００１９】
クライアント３００から送付されるリクエストには、スループット制御用のリクエストと、各Ｗｅｂサービス用のリクエストとがある。リクエスト受付部２０３は、スループット制御用のリクエストの場合には、そのリクエストをスループット制御部２０５に送信し、それ以外のリクエストの場合には、キュー２０７にリクエストを格納する。スループット制御用のリクエストは、スループットの新規確保リクエスト、スループット情報の更新リクエスト、スループット情報削除リクエストがある。
【００２０】
スループット制御部２０５は、リクエスト受付部２０３から転送されたスループット制御用のリクエストの処理を行う。リクエスト実行スレッド２０８は、キュー２０７からリクエストを取り出しリクエストを実行する。なお、閾値用定数２０９は、サーバ管理者が管理するスループット判定のために用いる。
【００２１】
図３は、クライアントのソフトウェアの構成例を示す説明図である。ＢＰＥＬファイル３０１，３０２は、ユーザによって定義されたＢＰが記述されているファイルである。ＢＰ処理部３０４は、ＢＰＥＬファイル３０１，３０２を読み込み、ＢＰを実行し、他のサービスを呼び出す必要があれば、そのリクエストをリクエスト送出部３０６に送信する。リクエスト送出部３０６は、呼び出す必要のあるサービス３０９，３１０へリクエストを送信する。また、リクエスト送出部３０６には、Ｗｅｂサービスへのリクエストの送信回数を測定するスループット測定部３０７を有している。
【００２２】
ＷＳ抽出部３０３は、新しいＢＰＥＬファイル３０１，３０２と、そのインターフェースを記述したＷＳＤＬファイル３１２が配置される毎に実行される。ＷＳ抽出部３０３は、ＢＰＥＬファイル３０１，３０２に定義された呼び出されるＷｅｂサービスを抽出し、そのサービス名をスループット制御部３０８に送信する。スループット制御部３０８は、受理したそのサービス名に応じて、スループットの新規確保、スループット情報の更新、スループット情報の削除を行う。確保したスループット情報（例えば、ＢＰ、サービス、確保スループット）は、スループット情報格納ＤＢ３０５に格納される。なお、閾値用定数３１１は、スループットの管理に使用される。
【００２３】
＜サーバおよびクライアントのスループット情報格納ＤＢ＞
図４は、サーバのスループット情報格納ＤＢに格納されているスループット情報テーブルの構成例を示す説明図である。サーバ２００のスループット情報格納ＤＢ２０６には、スループット情報テーブル４０１を格納する。スループット情報テーブル４０１には、各クライアントが各Ｗｅｂサービスに対して確保したスループット情報を格納しており、クライアント、ＢＰ名、サービス、更新日、確保スループット、更新日からのリクエスト数を保持する。クライアント、ＢＰ名、サービスのカラムは、クライアント３００からスループットの新規確保リクエストが送信され、そのリクエストが受理されたときに入力される。更新日は、スループット制御部２０５が、図１６で示すように、一定時間毎に、確保スループットと実測スループット（更新日からのリクエスト数÷更新日からの経過時間から計算）の比較を行うたびに更新される。確保スループットは、毎秒あたりのリクエスト数を表し、スループットの新規確保リクエスト受理、スループット情報の更新リクエスト受理、およびサーバ２００による確保スループット値の更新処理によって更新される。更新日からのリクエスト数は、スループット測定部２０４（図２参照）によって管理され更新日から受付けたリクエスト数を確保している。図４に示すように、例えば、クライアント３００Ａは、ＢＰ１のビジネスプロセスを実行する場合に、Ｓｅｒｖｉｃｅ１のサービスをリクエストし、そのリクエストに対して確保されたリクエストは、毎秒１００リクエストである。また、更新日２００６年１月１１日からのリクエスト数は、３０３２９０であることが示されている。同様に、クライアント３００Ｂは、ＢＰ２のビジネスプロセスを実行する場合に、Ｓｅｒｖｉｃｅ２のサービスをリクエストし、そのリクエストに対して確保されたリクエストは、毎秒５０リクエストである。また、更新日２００６年１月７日からのリクエスト数は、８２４９であることが示されている。
【００２４】
図５は、サーバのスループット情報格納ＤＢに格納されるクライアント情報テーブルおよびドメイン振り分けテーブルの構成例を示す説明図である。サーバ２００のスループット情報格納ＤＢ２０６（図２参照）には、クライアント情報テーブル５０１およびドメイン振り分けテーブル５０２を格納する。クライアント情報テーブル５０１は、クライアント３００がどのドメインに属しているかを保存している。このクライアント情報テーブル５０１は、スループットの新規確保リクエストが受理されたときに、そのクライアント名とクライアントのドメインが入力される。ドメイン振り分けテーブル５０２は、サーバ管理者が設定し、クライアント３００のＵＲＬ（Uniform Resource Locator）がどのドメインに属するかを保存している。
【００２５】
図６は、サーバのスループット情報格納ＤＢに格納されるドメイン情報テーブルの構成例を示す説明図である。サーバ２００のスループット情報格納ＤＢ２０６（図２参照）には、ドメイン情報テーブル６０１を格納する。ドメイン情報テーブル６０１は、ドメイン毎に更新期間、許容スループット、および総確保スループットの情報を持つ。更新期間は、サーバ管理者が設定する。許容スループットは、サーバ管理者が設定し、そのドメインに属するクライアントで確保できるスループットの合計値を示す。総確保スループットは、現在そのドメインに属しているクライアントで確保されているスループットの合計値を示す。この総確保スループットのカラムは、スループット情報テーブル４０１の確保スループットのカラムに変更があるたびに更新される。
【００２６】
図７は、クライアントのスループット情報格納ＤＢに格納されるスループット情報テーブルの構成例を示す説明図である。クライアント３００のスループット情報格納ＤＢ３０５には、スループット情報テーブル７０１を格納する。スループット情報テーブル７０１は、ＢＰ、サービス、確保スループット、更新日からの送信リクエスト数を保持する。ＢＰのカラムは、スループットを確保したＢＰ名が入力される。サービスのカラムは、スループットを確保したサービス名が入力される。ＢＰおよびサービスのカラムは、スループットの新規確保時に入力される。確保スループットのカラムは、毎秒あたりの確保しているリクエスト数を表し、対象のサービスに対して、現在の確保しているスループットが入力される。確保スループットのカラムは、スループットの新規確保およびスループット値の更新時に入力される。
【００２７】
＜サーバのスループット測定部＞
スループット測定部２０４の動作を、図２を参照して説明する。
スループット測定部２０４は、クライアント３００（クライアント３００Ａ，３００Ｂ）からのリクエストを受ける毎に、リクエストのクライアント名、ＢＰ名、サービス名（呼び出しサービス名）を抽出する。その抽出したクライアント名およびサービス名をキーに、スループット情報格納ＤＢ２０６内のスループット情報テーブル４０１（図４参照）から該当レコードを取り出し、その更新日からのリクエスト数の値を更新する。該当レコードがない場合はエラーをクライアント３００に送信する。
【００２８】
＜クライアントとサーバ間のメッセージの流れ＞
図８は、クライアントとサーバ間のメッセージの流れを示す説明図である。まずクライアント３００は、新しいＢＰが配備されると、サーバ２００に対して新規確保リクエストを送信する（ステップＳ８０１）。サーバ２００は、その新規確保リクエストに対して応答する（ステップＳ８０２）。クライアント３００は、その新規確保リクエストに対して応答を受理すると、サーバ２００で動作しているサービスへリクエストを送信する（ステップＳ８０３）。サーバ２００は、そのリクエストに対して応答する（ステップＳ８０４）。クライアント３００は、より大きなスループットが必要と判断した場合、サーバ２００に対してスループットの更新リクエストを送信する（ステップＳ８０５）。サーバ２００は、その更新リクエストに対して応答する（ステップＳ８０６）。サーバ２００は、クライアント３００に対し不要なスループットが確保されていると判断した場合、スループットの更新リクエストを送信する（ステップＳ８０７）。クライアント３００は、ＢＰが配備されなくなったらサーバ２００に対しスループットの削除リクエストを送信する（ステップＳ８０８）。または、サーバ２００は、一定時間リクエストを送信しなかったクライアント３００に対し、スループットの削除リクエストを送信する（ステップＳ８０９）。
【００２９】
図９、図１０は、図８で示したリクエストおよび応答のメッセージを示す構成例である。クライアント３００とサーバ２００との情報の交換には、ＳＯＡＰ（Simple Object Access Protocol）が使用される。ステップＳ８０１からステップＳ８０８に対応するメッセージは、各々、新規確保リクエストメッセージ８０１ｍ、新規確保リクエストの応答メッセージ８０２ｍ、サービスへのリクエストのメッセージ８０３ｍ、サービスからの応答メッセージ８０４ｍ、クライアントからのスループット更新リクエストメッセージ８０５ｍ、更新リクエストの応答メッセージ８０６ｍ、サーバからのスループット更新リクエストメッセージ８０７ｍ、クライアントからのスループット削除リクエストメッセージ８０８ｍ、サーバからのスループット削除リクエストメッセージ８０９ｍに示す。
【００３０】
サーバ２００では、受信したリクエストについてクライアントとプロセスを判別する識別子として、ＨＴＴＰヘッダとＷＳリクエストの標準であるＳＯＡＰ（Simple Object Access Protocol）ヘッダを用いることができる。また、ＨＴＴＰヘッダやＳＯＡＰヘッダは、任意の情報を付加できるため、クライアント３００でサーバ２００にリクエストを送信する際に、ＨＴＴＰヘッダやＳＯＡＰヘッダに、クライアントの識別子とプロセスの識別子とを付加することで、サーバでクライアントとプロセスを識別することができる。
【００３１】
＜サーバのスループット制御部＞
スループット制御部２０５（図２参照）の動作を説明する。スループット制御部２０５は、スループットの新規確保、スループット情報の更新、スループット情報の削除の動作を行う。
【００３２】
＜スループットの新規確保＞
図１１は、スループット新規確保リクエスト受信時のサーバ側の処理を示すフローチャートである。スループットの新規確保は、クライアント３００がスループットの確保リクエストをリクエスト受付部２０３に送信することから開始される。リクエスト受付部２０３は、受信したリクエストがスループット確保リクエストか否かを判定する（ステップＳ１１０１）。スループットの確保リクエストには、クライアント３００のＵＲＬ、クライアント名、およびクライアント３００が実行するＢＰ名、サービス名、要求スループット値が含まれている。受信したリクエストがスループット確保リクエストである場合（ステップＳ１１０１，Ｙｅｓ）、リクエスト受付部２０３は、そのリクエストをスループット制御部２０５に送信する。
【００３３】
スループット制御部２０５は、受信したスループット確保リクエストの中から、クライアント３００のＵＲＬ・クライアント名・ＢＰ名・サービス名・要求スループット値を取り出す（ステップＳ１１０２）。スループット制御部２０５は、取り出した情報をもとにリクエストを受理するか否かを判定する（ステップＳ１１０３）。受理するか否かの判定は、図１２を参照して説明する。
【００３４】
図１２は、サーバ側のスループット割当可否の処理を示すフローチャートである。スループット制御部２０５（図２参照）は、取り出したクライアント名、ＢＰ名、サービス名を用いて、スループット情報テーブル４０１から該当レコードを抽出する（ステップＳ１２０１）。そして、該当レコードが有るか否かを判定する（ステップＳ１２０２）。
【００３５】
該当するレコードがある場合（ステップＳ１２０２，Ｙｅｓ）、スループット制御部２０５は、既にスループットは確保されているので不受理と判断する（ステップＳ１２０７）。該当レコードが無い場合（ステップＳ１２０２，Ｎｏ）、スループット制御部２０５は、要求されたスループットが確保できるか否かの判定を行う。この判定は、まずクライアント３００のＵＲＬからドメイン振り分けテーブル５０２（図５参照）を参照し該当ドメインを決定する（ステップＳ１２０３）。ドメイン情報テーブル６０１（図６参照）を参照し、該当ドメインのレコードを抽出する（ステップＳ１２０４）。スループット制御部２０５は、要求されたスループットが確保できるか否かを判定する（ステップＳ１２０５）。判定方法としては、該当レコードの「（許容スループット−総確保スループット）＞（要求スループット）」の真偽を計算する。真の場合（ステップＳ１２０５，Ｙｅｓ）は、受理と判断する（ステップＳ１２０６）。偽の場合（ステップＳ１２０５，Ｎｏ）は、要求されたスループットが確保できないため不受理と判断する（ステップＳ１２０７）。
【００３６】
図１１に戻り、不受理の場合（ステップＳ１１０３，Ｎｏ）は、クライアント３００に不受理を返答して終了する（ステップＳ１１０６）。受理の場合（ステップＳ１１０３，Ｙｅｓ）、スループット情報格納ＤＢ２０６の更新を行う（ステップＳ１１０４）。ＤＢの更新について図１３を参照して説明する。
【００３７】
図１３は、サーバ側のスループット割当時の処理を示すフローチャートである。スループット制御部２０５は、ドメイン情報テーブル６０１の該当レコードの総確保スループットカラムに（総確保スループット＋要求スループット）を新しい総確保スループット値として更新する（ステップＳ１３０１）。次に、スループット情報テーブル４０１を参照し、新規レコードを追加し、各項目についてクライアント、ＢＰ名、対象サービス、確保スループットを格納する（ステップＳ１３０２）。そして、スループット制御部２０５は、クライアント情報テーブル５０１を参照し、クライアント名をキーに該当レコードが有るか否かを判定する（ステップＳ１３０３）。該当レコードが有る場合（ステップＳ１３０３，Ｙｅｓ）、処理を終了する。該当レコードがない場合（ステップＳ１３０３，Ｎｏ）、新規レコードを追加しクライアントとドメイン振り分けテーブル５０２を参照して取得した該当ドメインを格納する（ステップＳ１３０４）。スループット情報格納ＤＢ２０６の更新が終了する。その後、図１１に戻り、クライアント３００に受理の応答を返し（ステップＳ１１０５）、一連の処理を終了する。
【００３８】
＜スループット情報の更新＞
スループット情報の更新について、適宜図２、図４、図６を参照して説明する。
スループット情報の更新は、クライアント３００側およびサーバ２００側の双方で行う。クライアント３００側は、クライアント３００が、スループット情報の更新リクエストをリクエスト受付部２０３に送信する。スループット情報の更新リクエストには、クライアント、ＢＰ名、対象サービス、新しい要求スループットの値が格納されている。リクエスト受付部２０３は、スループット情報の更新リクエストが送られてきたことを検知してそのスループット情報の更新リクエストをスループット制御部２０５に転送する。スループット制御部２０５は、スループット情報の更新リクエストの中から、クライアント名・ＢＰ名・対象サービス名・新しい要求スループットを取り出す。スループット制御部２０５は、スループット情報テーブル４０１からクライアント・ＢＰ名・サービスをキーにして該当レコードを抽出する。該当レコードの確保スループットと新しい要求スループットを比較して、新しい要求スループットのほうが小さければ、該当レコードの値を一時的に保存して、ドメイン情報テーブル６０１の総確保スループットの更新および該当レコードの更新を行う。ドメイン情報テーブル６０１の更新の詳細について、図１４を参照して説明する。
【００３９】
図１４は、サーバ側で割り当てたスループット値を更新する場合のＤＢの処理を示すフローチャートである。スループット制御部２０５（図２参照）は、リクエストに含まれているクライアント名から、クライアント情報テーブル５０１（図５参照）からクライアントのドメインを抽出し、スループット情報テーブル４０１（図４参照）から得られた確保スループット（Ａ）を抽出し、リクエストに含まれている要求スループット（Ｂ）を抽出する（ステップＳ１４０１）。クライアント３００のドメインをキーにして、ドメイン情報テーブル６０１の該当レコードを抽出する（ステップＳ１４０２）。該当レコードの総確保スループットのカラムを（現在の総確保スループットの値−Ａ＋Ｂ）に更新する（ステップＳ１４０３）。
【００４０】
具体的には、ステップＳ１４０１において、クライアント３００Ａの場合、図４を参照して、確保スループットから、確保スループット（Ａ）は毎秒１００リクエストとなる。また、要求スループット（Ｂ）を、例えば、毎秒２００リクエストとする。ステップＳ１４０２において、図５を参照してクライアント３００Ａの名のドメイン名は、同一ドメインとなり、そのドメインの総確保スループットは、図６を参照して、毎秒１００リクエストを得る。よって、ステップＳ１４０３において、（現在の総確保スループットの値−Ａ＋Ｂ）は、１００−１００＋２００と計算でき、毎秒２００リクエスト（２００／ｓｅｃ）となる。
【００４１】
新しい要求スループット値のほうが大きければ、ドメイン情報テーブル６０１の総確保スループットのカラムを参照し、クライアント３００のドメインに対して、新しい要求スループットについて割当可能か否かを判定する。割当可能か否かの判定の詳細は、図１５を参照して説明する。
【００４２】
図１５は、サーバ側で、クライアントから要求されたスループットについて割当可否の判定処理を示すフローチャートである。スループット制御部２０５（図２参照）は、リクエストに含まれているクライアント名からクライアント情報テーブル５０１（図５参照）を参照してクライアント３００のドメインを抽出し、スループット情報テーブル４０１（図４参照）から得られた確保スループット（Ａ）を抽出し、リクエストに含まれている要求スループット（Ｂ）を抽出する（ステップＳ１５０１）。次に、クライアント３００のドメインをキーにして、ドメイン情報テーブル６０１（図６参照）の該当レコード（総確保スループット）を抽出する（ステップＳ１５０２）。そして、スループット制御部２０５は、「（６０１の総確保スループット−Ａ＋Ｂ）＞該当レコードの許容スループット」で有るか否かを判定する（ステップＳ１５０３）。判定結果が偽の場合（ステップＳ１５０３，Ｎｏ）は、割当可能と判断する（ステップＳ１５０４）。判定結果が真の場合（ステップＳ１５０３，Ｙｅｓ）は、割当不可能と判断する（ステップＳ１５０５）。
【００４３】
スループット制御部２０５は、割当可能と判断すれば、現在の確保スループット値（Ｃ）を一時的に保存し、スループット情報テーブル４０１の該当レコードの確保スループットを更新する。また、クライアントをキーにクライアント情報テーブル５０１を参照し該当レコードを抽出する。そのクライアント情報テーブル５０１の該当レコードのドメインカラムの値をキーにドメイン情報テーブル６０１の該当レコードを抽出する。ドメイン情報テーブル６０１の総確保スループットを新しい総確保スループット（現在の総確保スループット―Ｃ＋要求されたスループット）に更新する。次に、サーバ２００側で定期的に行うスループット情報の更新を、図１６を参照して説明する。
【００４４】
図１６は、サーバ側スループット制御部によるスループット情報の更新処理を示すフローチャートである。サーバ２００側のスループット制御部２０５（図２参照）は、スループット情報の更新の動作を行う。一定間隔ごとに、スループット情報テーブル４０１（図４参照）のレコードの全てを参照する（ステップＳ１６０１）。各レコードについて更新対象レコードか否かを判定する（ステップＳ１６０２）。この判定の詳細について、図１７を参照して説明する。
【００４５】
図１７は、サーバ側のスループット情報更新時にスループット情報テーブルのレコードのうち対象となるレコードの判定処理を示すフローチャートである。スループット制御部２０５は、まず、クライアント情報テーブル５０１を参照しクライアント名からドメインを抽出し（ステップＳ１７０１）、そのドメインのカラム値をキーに、ドメイン情報テーブル６０１から該当レコードを抽出し（ステップＳ１７０２）、該当レコードの更新期間を抽出する（ステップＳ１７０３）。そして、スループット制御部２０５は、更新期間が無期限か否かを判定する（ステップＳ１７０４）。更新期間が無期限の場合（ステップＳ１７０４，Ｙｅｓ）、非対象レコードとなる（ステップＳ１７０８）。更新期間が無期限でない場合（ステップＳ１７０４，Ｎｏ）、すなわち、更新期間が設定されている場合、スループット制御部２０５は、スループット情報テーブル４０１の該当レコードから更新日カラムを取得する（ステップＳ１７０５）。そして、（（現在日時−更新日カラムの値）＜更新間隔）で有るか否かを判定する（ステップＳ１７０６）。判定結果が真の場合（ステップＳ１７０６，Ｙｅｓ）は、非対象レコードとなる（ステップＳ１７０８）。判定結果が偽の場合（ステップＳ１７０６，Ｎｏ）は、対象レコードとなる（ステップＳ１７０７）。
【００４６】
図１６に戻り、対象レコードである場合（ステップＳ１６０２，Ｙｅｓ）、ステップＳ１６０３の処理に移る。対象レコードでない場合（ステップＳ１６０２，Ｎｏ）、次のレコードに移る（ステップＳ１６０１）。ステップＳ１６０３において、スループット制御部２０５は、「確保スループット値×サーバ管理者が管理する閾値用定数２０９」を閾値とし、測定スループットが閾値未満であるか否かを判定する。測定スループットが閾値未満でない場合（ステップＳ１６０３，Ｎｏ）、スループット制御部２０５は、該当レコードの更新日の更新とリクエスト数のクリアを行い（ステップＳ１６０６）、次のレコードへ移る。測定スループットが閾値未満である場合（ステップＳ１６０３，Ｙｅｓ）、スループット制御部２０５は、閾値を新たな確保スループット（確保値）として採用し、スループット情報テーブル４０１およびドメイン情報テーブル６０１を更新する（ステップＳ１６０４）。そして、スループット制御部２０５は、その新たな確保スループットをクライアント３００側に伝達する（ステップＳ１６０５）。クライアント側に伝達した後、該当レコードの更新日の更新とリクエスト数のクリアを行い（ステップＳ１６０６）、次のレコードに移る。
【００４７】
＜スループット情報の削除＞
スループット情報の削除について説明する。
スループット情報の削除は、クライアント３００からスループット情報の削除リクエストを送信、または、サーバ２００側で一定間隔以上アクセスがない場合に行われる。サーバ２００側で一定間隔以上アクセスがない場合に行われるサーバ２００側でのスループット情報の削除について、図１８を参照して説明する。
【００４８】
図１８は、サーバ側でクライアントからのアクセス有無の判定処理を示すフローチャートである。図１８の処理は、スループット制御部２０５（図２参照）による処理である。スループット制御部２０５は、スループット情報テーブル４０１を参照し一定間隔ごとに各テーブルについて繰り返す（ステップＳ１８０１）。まず、クライアントのカラムからクライアント名を抽出し、クライアント情報テーブル５０１を参照してクライアント名からドメインを抽出する（ステップＳ１８０２）。次に、そのドメインをキーにドメイン情報テーブル６０１から該当レコードを抽出する（ステップＳ１８０３）。そして、該当レコードの更新期間を抽出する（ステップＳ１８０４）。その後、更新期間が無期限か否かを判定する（ステップＳ１８０５）。
【００４９】
更新期間が無期限の場合（ステップＳ１８０５，Ｙｅｓ）、アクセス有りとする（ステップＳ１８０９）。更新期間が無期限でない場合（ステップＳ１８０５，Ｎｏ）、すなわち、更新期間が設定されている場合、スループット情報テーブル４０１のレコードから更新日を取得する（ステップＳ１８０６）。そして、（（現在日時−更新日）＜更新間隔）か否かを判定する（ステップＳ１８０７）。判定結果が真の場合（ステップＳ１８０７，Ｙｅｓ）、まだ更新間隔内であるのでアクセス有りとする（ステップＳ１８０９）。判定結果が偽の場合（ステップＳ１８０７，Ｎｏ）、スループット情報テーブル４０１の更新日からのリクエスト数のカラム値を参照し、０より大であるか否かを判定する（ステップＳ１８０８）。０より大であれば（ステップＳ１８０８，Ｙｅｓ）、アクセス有りとする（ステップＳ１８０９）。０であれば（ステップＳ１８０８，Ｎｏ）、アクセス無しとする（ステップＳ１８１０）。アクセス無しの場合、該当レコードを削除する（ステップＳ１８１１）。
【００５０】
スループット情報の削除リクエストには、クライアント名・ＢＰ名・削除対象サービス名が格納されている。スループット情報の削除リクエストを受け取ったリクエスト受付部２０３は、スループット情報の削除リクエストが送られてきたことを検知して、そのリクエストをスループット制御部２０５に転送する。スループット制御部２０５は転送されたスループット情報の削除リクエストの中から、クライアント名・クライアントのドメイン・削除対象サービス名を取り出す。
【００５１】
スループット制御部２０５は、スループット情報テーブル４０１を参照し、クライアント・ＢＰ名・サービスをキーにして該当レコードを抽出する。該当レコード・クライアント情報テーブル５０１を参照し、ドメイン情報テーブル６０１の総確保スループットカラムの値を更新する。次に、スループット情報テーブル４０１の該当レコードを参照し、クライアント３００のみをキーにして該当レコードを参照する。該当レコードが無ければ、クライアント情報テーブル５０１を参照し、クライアント３００をキーにして該当レコードを抽出し、その該当レコードを削除する。最後に、スループット情報テーブル４０１の該当レコードを削除する。
【００５２】
＜クライアントのリクエスト送信時の処理＞
クライアント３００のリクエスト送信時の動作を説明する。
図３に示したように、ＢＰＥＬファイル３０１、３０２は、ユーザによって定義されたＢＰが記述されている。ＢＰ処理部３０４は、ＢＰＥＬファイル３０１，３０２を読み込みＢＰを実行し、他のサービスを呼び出す必要があればそのリクエストをリクエスト送出部３０６に送信する。リクエストの送信処理について、図１９を参照して説明する。
【００５３】
図１９は、クライアント側でリクエスト送信時の処理を示すフローチャートである。まず、ＢＰ処理部３０４（図３参照）の実行スレッド内でＷＳの呼出が発生し、リクエストが生成される（リクエスト発生）（ステップＳ１９０１）。ＢＰ処理部３０４は、生成されたリクエストをリクエスト送出部３０６に転送する（ステップＳ１９０２）。スループット測定部３０７は、リクエストの呼び出し元ＢＰと呼び出し先サービス（即ちＷＳ）を抽出する（ステップＳ１９０３）。スループット測定部３０７は、抽出したＢＰとサービスをキーにスループット情報テーブル７０１から該当レコードを抽出し（ステップＳ１９０４）、該当レコードの更新日からの送信リクエスト数のカラムに１を追加する（ステップＳ１９０５）。最後に、リクエスト送出部３０６は、リクエストをＷＳに向けて送信する（ステップＳ１９０６）。
【００５４】
＜クライアントのＷＳ抽出処理＞
クライアント３００のＷＳ抽出部３０３は、新しいＢＰＥＬファイル３０１，３０２とそのインターフェースを記述したＷＳＤＬファイル３１２が配置されるごとに実行される。ＷＳ抽出部３０３は、ＢＰＥＬファイル３０１，３０２に定義された呼び出されるＷｅｂサービスを抽出し、そのサービス名をスループット制御部３０８に送信する。抽出の実施例をＢＰＥＬ４ＷＳの仕様を用いて図２０を参照して説明する。
【００５５】
図２０は、ビジネスプロセス（ＢＰ）が呼出すＷｅｂサービス（ＷＳ）の抽出方法の一実施例を示す説明図である。図２０の処理は、ＷＳ抽出部３０３（図３参照）による処理である。ＢＰＥＬ４ＷＳでＷＳを呼出す場合は＜ｉｎｖｏｋｅ＞要素で示されているため、その＜ｉｎｖｏｋｅ＞要素をＢＰＥＬファイル３０１，３０２から抽出する（ステップＳ２００１）。＜ｉｎｖｏｋｅ＞要素には呼び出し先の情報がｐａｒｔｎｅｒＬｉｎｋ属性として設定されているため、そのｐａｒｔｎｅｒＬｉｎｋ名（Ａ）を抽出し、ｐａｒｔｎｅｒＬｉｎｋの情報は、＜ｐａｒｔｎｅｒＬｉｎｋ＞要素に記述されているため、（Ａ）の情報を元に、＜ｐａｒｔｎｅｒＬｉｎｋｓ＞要素から該当する＜ｐａｒｔｎｅｒＬｉｎｋ＞要素を抽出する（ステップＳ２００２）。その要素に記述されているｐａｒｔｎｅｒＬｉｎｋＴｙｐｅ名（Ｂ）、ｐａｒｔｎｅｒＲｏｌｅ名（Ｃ）を抽出し、ｐａｒｔｎｅｒＬｉｎｋＴｙｐｅ、ｐａｒｔｎｅｒＲｏｌｅについてはＢＰのインターフェースを定義したＷＳＤＬに記述されているため、ＷＳＤＬファイル３１２から（Ｂ）、（Ｃ）の情報を元に＜ｐａｒｔｎｅｒＬｉｎｋＴｙｐｅ＞要素を抽出する（ステップＳ２００３）。そして、その要素に記述されているｐｏｒｔＴｙｐｅ名（Ｄ）を抽出し、（Ｄ）の情報を元に、＜ｂｉｎｄｉｎｇ＞要素を抽出する（ステップＳ２００４）。そのｎａｍｅ名（Ｅ）を抽出し、（Ｅ）を元に、＜ｐｏｒｔ＞要素を抽出する（ステップＳ２００５）。そして、その＜ｐｏｒｔ＞要素に含まれているｎａｍｅ属性からサービス名を取得する（ステップＳ２００６）。
【００５６】
＜クライアントのスループットの新規確保＞
スループットの新規確保を、図２１を参照して説明する（適宜図３、図７参照）。
図２１は、ビジネスプロセス（ＢＰ）新規配備時のクライアントの処理を示すフローチャートである。スループットの新規確保は、新しいＢＰＥＬファイル３０１，３０２とそのインターフェースを記述したＷＳＤＬファイル３１２が配置された場合に開始される。新しいＢＰＥＬファイル３０１，３０２が定義されると、ＷＳ抽出部３０３が解析し、Ｗｅｂサービスの呼び出しが有りか無しかを判定する（ステップＳ２１０１）。Ｗｅｂサービスの呼び出しが無い場合（ステップＳ２１０１，Ｎｏ）は、処理を終了する。Ｗｅｂサービスの呼び出しがある場合（ステップＳ２１０１，Ｙｅｓ）は、呼び出すＷｅｂサービスの情報をスループット制御部３０８に送信する。
【００５７】
スループット制御部３０８（図３参照）は、呼び出すＷｅｂサービス分を繰り返す（ステップＳ２１０２）。具体的には、それぞれのＷｅｂサービスに対してクライアント３００のＵＲＬ・クライアント名・ＢＰ名・対象サービス名・クライアント毎に決定した確保スループットを含めたスループットの新規確保リクエストを生成し、リクエスト送出部３０６経由で送信する（ステップＳ２１０３）。送信したスループットの新規確保リクエストに対してＷｅｂサービスからスループット制御部３０８に応答があり、その応答にはリクエストの受理・不受理が格納されているので、その応答内容を判定する（ステップＳ２１０４）。不受理の応答である場合（ステップＳ２１０４，Ｎｏ）、不受理の理由がスループット不足場合か否かを判定する（ステップＳ２１０７）。不受理の理由がスループット不足である場合（ステップＳ２１０７，Ｙｅｓ）は、一定時間待ち（ステップＳ２１０５）、再度そのＷｅｂサービスに対してスループットの新規確保リクエストを送信する（ステップＳ２１０３）。不受理の理由がスループット不足でない場合（ステップＳ２１０７，Ｎｏ）、すなわち、既に割当済みの場合は、次のＷｅｂサービスのスループット確保処理に移る。サーバからの応答が受理の場合（ステップＳ２１０４，Ｙｅｓ）は、ＢＰ、サービス、確保スループットをスループット情報格納ＤＢ３０５のスループット情報テーブル７０１（図７参照）に登録する（ステップＳ２１０６）。
【００５８】
＜サーバからクライアントへのスループット情報の更新＞
スループット情報の更新について説明する。
スループット情報の更新は、クライアント３００側・サーバ２００側の双方で行う。サーバ２００からの更新について、図２２を参照して説明する。
【００５９】
図２２は、サーバ側からクライアントへのスループット値の更新処理を示す説明図である。サーバ２００側は、図１６で説明したように、所定の条件を満たすと、スループット変更リクエストを生成する（ステップＳ２２０１）。そして、そのリクエストをクライアント３００に送信する（ステップＳ２２０２）。このリクエストのメッセージ（電文）には、スループットが変更になったＷｅｂサービス名・対象ＢＰ名・新しく設定されたスループットの値が含まれている。クライアント３００は、このリクエストを受信する（ステップＳ２２０３）と、スループット情報格納ＤＢ３０５のスループット情報テーブル７０１（図７参照）を参照し、ＢＰ名・Ｗｅｂサービス名をキーに該当レコードを抽出する（ステップＳ２２０４）。そして、そのレコードの確保スループット値を更新する（ステップＳ２２０５）。
【００６０】
＜クライアントのスループット情報の更新＞
クライアント側のスループット情報の更新について、図２３を参照して説明する。
図２３は、クライアント側スループット制御部によるスループット情報の更新処理を示すフローチャートである。図２３に示す処理は、スループット制御部３０８（図３参照）による処理である。スループット制御部３０８は、一定間隔毎にスループット情報テーブル７０１（図７参照）の全てのレコードを参照（ステップＳ２３０１）し、更新日からの送信リクエスト数から（更新日からの送信リクエスト数÷一定間隔の秒数）を計算し実測スループット値を求める。次に、「確保スループット値×クライアント管理者が管理する閾値用定数３１１」を閾値とし、その実測スループット値が閾値以上か否かを判定する（ステップＳ２３０２）。閾値以上の場合（ステップＳ２３０２，Ｙｅｓ）は、サーバ２００に対して、現在のスループットで確保可能か否かについて更新リクエストを送信し問い合わせる（ステップＳ２３０３）。サービスからの問合せ応答があれば、サーバ２００からの応答がスループット割当て可能か否かを判定する（ステップＳ２３０４）。スループット割当て可能の場合（ステップＳ２３０４，Ｙｅｓ）、現在のスループット値を新しい確保スループットとして採用し該当レコードを更新し（ステップＳ２３０５）、ステップＳ２３０８へ進む。ステップＳ２３０４において、スループット割当て不可の場合（ステップＳ２３０４，Ｎｏ）、ステップＳ２３０８へ進む。
【００６１】
ステップＳ２３０２において、閾値未満の場合（ステップＳ２３０２，Ｎｏ）は、余分なスループットを確保していると判断し閾値を新しい確保スループットとして採用し該当レコードを更新する（ステップＳ２３０６）。そして、その確保スループットを確保済みのスループット値更新リクエスト内に格納して、リクエスト送出部経由でサーバ２００に送信する（ステップＳ２３０７）。最後にリクエスト数の更新として、更新日からのリクエスト数を０にする（ステップＳ２３０８）。
【００６２】
＜クライアントのスループット情報の削除＞
スループット情報の削除について、図２４を参照して説明する。
図２４は、ビジネスプロセス（ＢＰ）削除時におけるクライアント側での処理を示すフローチャートである。図２４に示す処理は、スループット制御部３０８（図３参照）による処理である。スループット情報の削除は、配置されていたＢＰが削除する場合に行われる（ステップＳ２４０１）。ＢＰが削除されようとすると、スループット制御部３０８は、スループット情報テーブル７０１（図７参照）を参照し、削除対象のＢＰのレコードを抽出する（ステップＳ２４０２）。そして、以下の処理は、その各該当レコードに対して繰り返される（ステップＳ２４０３）。まず、サービスのカラムを参照し、ＷＳを抽出する（ステップＳ２４０４）。抽出したＷＳに対してスループット情報の削除リクエストを送信する（ステップＳ２４０５）。その後、該当レコードを削除する（ステップＳ２４０６）。
【００６３】
本実施形態では、クライアント３００は、Ｗｅｂサービス（ＷＳ）を実行するのに必要なスループット要求として単位時間あたりのリクエスト数を、Ｗｅｂサービスを実行する前に予め前記サーバにスループット要求を送信し、サーバ２００は、前記スループット要求の単位時間あたりのリクエスト数を確保している。
【００６４】
本発明によるサーバ２００は、クライアント３００によるプロセスの処理中に呼び出されたＷＳのリクエストについて、そのプロセスに対して該当サーバが処理できる総スループットのうちその一部分を割り当てる手段と、そのリクエストがそのプロセスに割り当てられたスループットの範囲内であるか否かを判定する手段と、プロセスからのリクエスト受信状況を監視し不要なスループットを削除する手段と、プロセスに割り当てたスループットを変更するとその変更についてクライアントに通知する手段を備えることを特徴とする。
【００６５】
本発明によるプロセスを実行するクライアント３００は、プロセスを新規に配備するときに一定量のスループットの確保をサーバ側に通知する手段と、プロセスの実行状況を監視しプロセスで呼び出す各サーバについて確保しているスループットの変更が必要なときにその変更をサーバに通知する手段と、プロセスを削除するときに確保していたスループットをサーバ側に削除するように通知する手段を備えることを特徴とする。
【００６６】
本発明によれば、サーバ２００がリクエストメッセージからクライアントとその実行中のプロセスを識別する手段と、識別したクライアントとプロセスからそれに割り当てたスループットを識別する手段と、識別したクライアントとプロセスからのリクエストがそれに割り当てられたスループット内であればリクエストを処理することを特徴とする。これにより、クライアントからのリクエストの集中によるサーバのサービス不能状態に陥ることはなく、クライアント３００が、ビジネスプロセスを実行する上で必要なＷｅｂサービス（ＷＳ）のスループットを確保することができる。
【００６７】
本発明によるサーバ２００では、受信したリクエストについてクライアントとプロセスを判別する識別子として、ＨＴＴＰヘッダとＷＳリクエストの標準であるＳＯＡＰ（Simple Object Access Protocol）ヘッダを用いることができる。
【図面の簡単な説明】
【００６８】
【図１】本発明の実施形態のスループット管理システムのハードウェア構成を示すブロック図である。
【図２】サーバのソフトウェアの構成例を示す説明図である。
【図３】クライアントのソフトウェアの構成例を示す説明図である。
【図４】サーバのスループット情報格納ＤＢに格納されているスループット情報テーブルの構成例を示す説明図である。
【図５】サーバのスループット情報格納ＤＢに格納されるクライアント情報テーブルおよびドメイン振り分けテーブルの構成例を示す説明図である。
【図６】サーバのスループット情報格納ＤＢに格納されるドメイン情報テーブルの構成例を示す説明図である。
【図７】クライアントのスループット情報格納ＤＢに格納されるスループット情報テーブルの構成例を示す説明図である。
【図８】クライアントとサーバ間のメッセージの流れを示す説明図である。
【図９】図８で示したリクエストおよび応答のメッセージを示す構成例である。
【図１０】図８で示したリクエストおよび応答のメッセージを示す構成例である。
【図１１】スループット新規確保リクエスト受信時のサーバ側の処理を示すフローチャートである。
【図１２】サーバ側のスループット割当可否の処理を示すフローチャートである。
【図１３】サーバ側のスループット割当時の処理を示すフローチャートである。
【図１４】サーバ側で割り当てたスループット値を更新する場合のＤＢの処理を示すフローチャートである。
【図１５】サーバ側で、クライアントから要求されたスループットについて割当可否の判定処理を示すフローチャートである。
【図１６】サーバ側スループット制御部によるスループット情報の更新処理を示すフローチャートである。
【図１７】サーバ側のスループット情報更新時にスループット情報テーブルのレコードのうち対象となるレコードの判定処理を示すフローチャートである。
【図１８】サーバ側でクライアントからのアクセス有無の判定処理を示すフローチャートである。
【図１９】クライアント側でリクエスト送信時の処理を示すフローチャートである。
【図２０】ビジネスプロセス（ＢＰ）が呼出すＷｅｂサービス（ＷＳ）の抽出方法の一実施例を示す説明図である。
【図２１】ビジネスプロセス（ＢＰ）新規配備時のクライアントの処理を示すフローチャートである。
【図２２】サーバ側からクライアントへのスループット値の更新処理を示す説明図である。
【図２３】クライアント側スループット制御部によるスループット情報の更新処理を示すフローチャートである。
【図２４】ビジネスプロセス（ＢＰ）削除時におけるクライアント側での処理を示すフローチャートである。
【符号の説明】
【００６９】
１００ ネットワーク
２００ サーバ
２０３ リクエスト受付部
２０４ スループット測定部
２０５ スループット制御部
２０６ スループット情報格納ＤＢ
２１０ Ｗｅｂサービス（ＷＳ）の定義ファイル
２２１ ＨＤＤ
２２２ ＣＰＵ
２２３ メモリ
２２４ ＮＩＣ
３００，３００Ａ，３００Ｂ クライアント
３０１，３０２ ＢＰＥＬファイル
３０３ Ｗｅｂサービス（ＷＳ）抽出部
３０５ スループット情報格納ＤＢ
３０６ リクエスト送出部
３０７ スループット測定部
３０８ スループット制御部
３２１ ＨＤＤ
３２２ ＣＰＵ
３２３ メモリ
３２４ ＮＩＣ
４０１ スループット情報テーブル
５０１ クライアント情報テーブル
６０１ ドメイン情報テーブル
７０１ スループット情報テーブル
【特許請求の範囲】
【請求項１】
ビジネスプロセスを実行するクライアントと、前記クライアントがビジネスプロセスを実行中に呼び出すＷｅｂサービスを実行するサーバとがネットワークを介して接続されるシステムにおける前記Ｗｅｂサービスを実行するスループットを管理するスループット管理方法であって、
前記クライアントは、前記サーバがＷｅｂサービスを実行するのに必要なスループット要求として単位時間あたりのリクエスト数を前記サーバに送信し、
前記サーバは、前記スループット要求の単位時間あたりのリクエスト数を確保する
ことを特徴とするスループット管理方法。
【請求項２】
前記クライアントは、前記サーバにおいて確保しているスループットについて前記スループット要求の更新が必要なとき、スループット更新要求を前記サーバに送信する
ことを特徴とする請求項１に記載のスループット管理方法。
【請求項３】
前記クライアントは、前記サーバにおいて確保しているスループットについて前記スループット要求の削除が必要なとき、スループット削除要求を前記サーバに送信する
ことを特徴とする請求項１に記載のスループット管理方法。
【請求項４】
前記サーバは、前記クライアントから前記スループット更新要求を受信した場合、前記スループット更新要求で要求された前記リクエスト数を所定の許容されるリクエスト数以内で割当て可能か否かを判定し、割当て可能なときは、前記スループット変更要求の受理通知を前記クライアントに送信する
ことを特徴とする請求項２に記載のスループット管理方法。
【請求項５】
ビジネスプロセスを実行するクライアントとネットワークを介して接続され、前記クライアントがビジネスプロセスを実行中に呼び出すＷｅｂサービスを、スループットを管理しつつ実行するスループット管理サーバであって、
前記クライアントが前記ネットワークを介して送信するＷｅｂサービスを実行するのに必要な単位時間あたりのリクエスト数を含むスループット要求を受信すると、
前記リクエスト数を所定の許容されるリクエスト数以内で割当て可能か否かを判定し、
前記リクエスト数を割当て可能なときは、前記リクエスト数を記憶部に格納し、
前記スループット要求の受理通知を前記クライアントに送信する
ことを特徴とするスループット管理サーバ。
【請求項１】
ビジネスプロセスを実行するクライアントと、前記クライアントがビジネスプロセスを実行中に呼び出すＷｅｂサービスを実行するサーバとがネットワークを介して接続されるシステムにおける前記Ｗｅｂサービスを実行するスループットを管理するスループット管理方法であって、
前記クライアントは、前記サーバがＷｅｂサービスを実行するのに必要なスループット要求として単位時間あたりのリクエスト数を前記サーバに送信し、
前記サーバは、前記スループット要求の単位時間あたりのリクエスト数を確保する
ことを特徴とするスループット管理方法。
【請求項２】
前記クライアントは、前記サーバにおいて確保しているスループットについて前記スループット要求の更新が必要なとき、スループット更新要求を前記サーバに送信する
ことを特徴とする請求項１に記載のスループット管理方法。
【請求項３】
前記クライアントは、前記サーバにおいて確保しているスループットについて前記スループット要求の削除が必要なとき、スループット削除要求を前記サーバに送信する
ことを特徴とする請求項１に記載のスループット管理方法。
【請求項４】
前記サーバは、前記クライアントから前記スループット更新要求を受信した場合、前記スループット更新要求で要求された前記リクエスト数を所定の許容されるリクエスト数以内で割当て可能か否かを判定し、割当て可能なときは、前記スループット変更要求の受理通知を前記クライアントに送信する
ことを特徴とする請求項２に記載のスループット管理方法。
【請求項５】
ビジネスプロセスを実行するクライアントとネットワークを介して接続され、前記クライアントがビジネスプロセスを実行中に呼び出すＷｅｂサービスを、スループットを管理しつつ実行するスループット管理サーバであって、
前記クライアントが前記ネットワークを介して送信するＷｅｂサービスを実行するのに必要な単位時間あたりのリクエスト数を含むスループット要求を受信すると、
前記リクエスト数を所定の許容されるリクエスト数以内で割当て可能か否かを判定し、
前記リクエスト数を割当て可能なときは、前記リクエスト数を記憶部に格納し、
前記スループット要求の受理通知を前記クライアントに送信する
ことを特徴とするスループット管理サーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【公開番号】特開２００８−９０３４４（Ｐ２００８−９０３４４Ａ）
【公開日】平成２０年４月１７日（２００８．４．１７）
【国際特許分類】
【出願番号】特願２００６−２６６９５１（Ｐ２００６−２６６９５１）
【出願日】平成１８年９月２９日（２００６．９．２９）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
【公開日】平成２０年４月１７日（２００８．４．１７）
【国際特許分類】
【出願日】平成１８年９月２９日（２００６．９．２９）
【出願人】（０００００５１０８）株式会社日立製作所 (27,607)
【Ｆターム（参考）】
[ Back to top ]