(57)【特許請求の範囲】
【請求項１】
資源要求の操作をするクライアントと、該クライアントから要求応答型プロトコルのポーリングを受け付ける資源ブローカサーバと、該資源ブローカサーバから要求応答型プロトコルのポーリングを受け付ける資源マネージャサーバとが階層型に構成された資源管理システムにおけるポーリング制御方法であって、
前記資源ブローカサーバは、前記クライアントから受信した資源要求メッセージの操作内容毎に、１つ以上の前記資源マネージャサーバへ資源要求メッセージを送信してから完了するまでの過去の処理時間を蓄積する第１の履歴情報データベースを有し、
前記クライアントが、前記資源要求メッセージを前記資源ブローカサーバへ送信するステップと、
前記資源ブローカサーバが、第１の履歴情報データベースを用いて前記資源要求メッセージの操作内容に応じた第１の所要時間ΔＳ１を含む資源受付メッセージを、前記クライアントへ返信するステップと、
前記クライアントが、前記資源受付メッセージを受信してから第１の所要時間ΔＳ１の経過後に、状態問合せメッセージを前記資源ブローカサーバへ送信するステップと
を有すると共に、
前記資源マネージャサーバは、前記資源ブローカサーバから受信した資源要求メッセージの対象設備装置毎に、１つ以上の対象設備装置へ資源要求メッセージを送信してから完了するまでの過去の処理時間を蓄積する第２の履歴情報データベースを有し、
前記資源ブローカサーバが、前記資源要求メッセージを前記資源マネージャサーバへ送信するステップと、
前記資源マネージャサーバが、第２の履歴情報データベースを用いて前記資源要求メッセージの対象設備装置に応じた第２の所要時間ΔＳ２を含む資源受付メッセージを、前記資源ブローカサーバへ返信するステップと、
前記資源ブローカサーバが、前記資源受付メッセージを受信してから第２の所要時間ΔＳ２の経過後に、状態問合せメッセージを前記資源マネージャサーバへ送信するステップと
を有することを特徴とするポーリング制御方法。
【請求項２】
前記システムは、ネットワーク資源管理システム又は計算資源管理システムであり、
前記資源は、ネットワーク資源、又は、計算機／ストレージ資源である
ことを特徴とする請求項１に記載のポーリング制御方法。
【請求項３】
資源要求の操作をするクライアントと、該クライアントから要求応答型プロトコルのポーリングを受け付ける資源ブローカサーバと、該資源ブローカサーバから要求応答型プロトコルのポーリングを受け付ける資源マネージャサーバとが階層型に構成された資源管理システムであって、
前記クライアントは、
前記資源要求メッセージを前記資源ブローカサーバへ送信する要求送信手段と、
前記資源ブローカサーバから、資源受付メッセージを受信する受付受信手段と、
前記資源受付メッセージを受信してから第１の所要時間ΔＳ１の経過を計測するタイマ手段と、
第１の所要時間ΔＳ１の経過後に、状態問合せメッセージを前記資源ブローカサーバへ送信する問合せ送信手段とを有し、
前記資源ブローカサーバは、
前記操作内容毎に、前記クライアントから受信した資源要求メッセージを１つ以上の前記資源マネージャサーバへ資源要求メッセージを送信してから完了するまでの過去の処理時間を蓄積する第１の履歴情報データベースと、
前記クライアントから前記資源要求メッセージを受信する要求受信手段と、
第１の履歴情報データベースを用いて前記資源要求メッセージの操作内容に応じた第１の所要時間ΔＳ１を取得する所要時間取得手段と、
第１の所要時間ΔＳ１を含む資源受付メッセージを、前記クライアントへ返信する受付送信手段と、
前記資源要求メッセージを前記資源マネージャサーバへ送信する要求送信手段と、
前記資源マネージャサーバから、資源受付メッセージを受信する受付受信手段と、
前記資源受付メッセージを受信してから第２の所要時間ΔＳ２の経過を計測するタイマ手段と、
第２の所要時間ΔＳ２の経過後に、状態問合せメッセージを前記資源マネージャサーバへ送信する問合せ送信手段とを有し、
前記資源マネージャサーバは、
前記対象設備装置毎に、前記資源ブローカサーバから受信した資源要求メッセージを該対象設備装置へ送信してから完了するまでの過去の処理時間を蓄積する第２の履歴情報データベースと、
前記資源ブローカサーバから、前記資源要求メッセージを受信する要求受信手段と、
第２の履歴情報データベースを用いて前記資源要求メッセージの対象設備装置に応じた第２の所要時間ΔＳ２を取得する所要時間取得手段と、
第２の所要時間ΔＳ２を含む資源受付メッセージを、前記資源ブローカサーバへ返信する受付送信手段と
を有することを特徴とする資源管理システム。
【請求項４】
前記システムは、ネットワーク資源管理システム又は計算資源管理システムであり、
前記資源は、ネットワーク資源、又は、計算機／ストレージ資源である
ことを特徴とする請求項３に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、資源管理システムにおけるポーリング制御方法及びシステムに関する。
【背景技術】
【０００２】
近年、地理的に分散した計算資源を、高速なネットワーク資源で相互に結ぶことによって、大規模高性能計算システムを構築することが可能となってきた。これを実現するためには、通信における遅延・帯域の不安定、及び／又は、計算機における過負荷等を引き起こさないように、必要なネットワーク資源及び／又は計算資源（及びストレージ資源）を予め確保しておかなければならない。即ち、これら資源を、エンドツーエンドのサービスレベルの通信品質に応じて、管理する必要がある。
【０００３】
図１は、対象設備システムに資源管理システムを備えたシステム構成図である。
【０００４】
図１によれば、「グリッド」が表されている。グリッドとは、利用者の要求に応じて、地理的に分散した計算資源を、ネットワーク資源の操作によって柔軟に利用するシステムをいう。図１によれば、資源管理システム１として、ネットワーク資源管理システムと計算資源管理システムとが表されている。ネットワーク資源管理システムは、対象設備システムにおけるネットワーク資源を管理し、計算資源管理システムは、対象設備システムにおける計算資源を管理する。
【０００５】
資源管理システム１は、ユーザによって操作されるオペレーションクライアント３からの要求に応じて、対象設備システム２における資源の確保／開放／変更等の管理をする。対象設備システム２のネットワーク資源は、例えばＧＭＰＬＳ(Generalized Multi-Protocol Label Switching)のようなＭＰＬＳプロトコルをベースに、光クロスコネクト等によって構築された光ネットワークであってもよい。そのようなネットワーク資源を介して、地理的に分散した計算資源が相互に通信する。
【０００６】
図２は、資源管理システムのシステム構成図である。
【０００７】
資源管理システム１は、階層型分散システムとして構成される。このシステムは、オペレーションクライアント３からの要求に応じて資源全体の調停を実行する資源ブローカサーバ１１と、実際に対象設備システム２に対して資源の確保を実行する複数の資源マネージャサーバ１２とを有する。資源マネージャサーバ１２は、ドメイン毎に実資源管理を実行し、資源ブローカサーバ１１は、それらドメイン間に渡って全体の調停を実行する。尚、ネットワーク資源管理システム又は計算資源管理システムのいずれも同様である。
【０００８】
資源管理システム１における通信は、要求応答型プロトコルによって構成されたクライアント−サーバ関係に基づく。資源管理システム１は、拡張性及び可用性のために、例えばＳＯＡＰ（非特許文献１参照）に基づくＷｅｂサービスによって連携する。ＳＯＡＰは、下位プロトコルにＨＴＴＰ(HyperText Tranfer Protocol)等を使用し、簡単なＸＭＬ(eXtended Markup Language、拡張マークアップ言語)ベースのメッセージをやりとりする通信プロトコルである。ＳＯＡＰは、ＸＭＬ文書にエンベロープ（封筒）と称される付帯情報が付いたメッセージを、ＨＴＴＰ等のプロトコルで交換する。サービスを利用するクライアントと、サービスを提供するサーバとの双方が、ＳＯＡＰエンジンを備えることによって、異なる環境間でのオブジェクト呼び出しを可能にしている。
【０００９】
従って、図２によれば、オペレーションクライアント３から見て、資源ブローカサーバ１１は「サーバ」として機能する。また、「クライアント」としての資源ブローカサーバ１１から見て、資源マネージャサーバ１２は「サーバ」として機能する。
【００１０】
このように、オペレーションクライアント３から送信される要求メッセージによって、２相コミットのシーケンスを実行する。そのために、各相における処理の完了を、資源ブローカサーバによって検出する必要がある。
【００１１】
ここで、資源管理システム１が、要求応答型プロトコル（ＳＯＡＰ）によって設計されているために、「サーバ」としての資源マネージャサーバ１２が、「クライアント」としての資源ブローカサーバ１１に対して、新規セッションを張って完了通知を実行できるとは限らない。例えばＮＡＴやファイアウォールによりサーバ側からの接続が制限されていることがあり得る。従って、「クライアント」としての資源ブローカサーバ１１は、ポーリング（問合せメッセージ）を用いて、「サーバ」としての資源マネージャサーバにおける資源状態を確認しなければならない。
【００１２】
図３は、従来技術の２相コミットのシーケンス図である。
【００１３】
最初に、予約処理のシーケンスを説明する。
（Ｓ３０１）オペレーションクライアント３は、予約要求（確保／開放／変更）メッセージを、資源ブローカサーバ１１へ送信する。
（Ｓ３０２）資源ブローカサーバ１１は、予約要求メッセージを、資源マネージャサーバ１２へ送信すると共に、受付メッセージをオペレーションクライアント３へ返信する。
（Ｓ３０３）受付メッセージを受信したオペレーションクライアント３は、タイマによって一定時間を計測する。
（Ｓ３０４）資源マネージャサーバ１２は、対象設備システム２へ、資源の確保／開放／変更の予約をすると共に、受付メッセージを資源ブローカサーバ１１へ返信する。
（Ｓ３０５）受付メッセージを受信した資源ブローカサーバ１１は、タイマによって一定時間を計測する。
（Ｓ３０６）資源ブローカサーバ１１は、タイマがタイムアウトすると、状態問合せメッセージを、資源マネージャサーバ１２へ送信する。
（Ｓ３０７）このとき、資源マネージャサーバ１２は、対象設備システム２から未だ受付メッセージを受信していないので、資源ブローカサーバ１１へ未完了メッセージを返信する。
（Ｓ３０８）未完了メッセージを受信した資源ブローカサーバ１１は、タイマによって一定時間を再び計測する。
（Ｓ３０９）オペレーションクライアント３は、タイマがタイムアウトすると、状態問合せメッセージを、資源ブローカサーバ１１へ送信する。
（Ｓ３１０）このとき、資源ブローカサーバ１１は、資源マネージャサーバ１２から未だ完了メッセージを受信していないので、オペレーションクライアント３へ未完了メッセージを返信する。
（Ｓ３１１）対象設備システム２は、対象装置に対する資源の確保／開放／変更の予約が完了した後、受付メッセージを資源マネージャサーバ１２へ送信する。
（Ｓ３１２）未完了メッセージを受信したオペレーションクライアント３は、タイマによって一定時間を再び計測する。
（Ｓ３１３）資源ブローカサーバ１１は、タイマがタイムアウトすると、状態問合せメッセージを、資源マネージャサーバ１２へ送信する。
（Ｓ３１４）このとき、資源マネージャサーバ１２は、対象設備システム２から既に受付メッセージを受信しているので、資源ブローカサーバ１１へ完了メッセージを返信する。
（Ｓ３１５）オペレーションクライアント３は、タイマがタイムアウトすると、状態問合せメッセージを、資源ブローカサーバ１１へ再び送信する。
（Ｓ３１６）このとき、資源ブローカサーバ１１は、資源マネージャサーバ１２から既に完了メッセージを受信しているので、オペレーションクライアント３へ完了メッセージを返信する。
このように、対象設備システム２としては、Ｓ３１１で予約受付を完了しているにも拘わらず、オペレーションクライアント３がその旨を知る（同期を取る）ことができるのはＳ３１６の時である。
【００１４】
次に、確定処理のシーケンスを説明する。
（Ｓ３２１）オペレーションクライアント３は、確定要求（確保／開放／変更）メッセージを、資源ブローカサーバ１１へ送信する。
（Ｓ３２２）資源ブローカサーバ１１は、確定要求メッセージを、資源マネージャサーバ１２へ送信すると共に、受付メッセージをオペレーションクライアント３へ返信する。
（Ｓ３２３）受付メッセージを受信したオペレーションクライアント３は、タイマによって一定時間を計測する。
（Ｓ３２４）資源マネージャサーバ１２は、対象設備システム２へ、資源の確保／開放／変更をすると共に、受付メッセージを資源ブローカサーバ１１へ返信する。
（Ｓ３２５）受付メッセージを受信した資源ブローカサーバ１１は、タイマによって一定時間を計測する。
（Ｓ３２６）対象設備システム２は、資源の確保／開放／変更が完了した後、完了メッセージを資源マネージャサーバ１２へ送信する。
（Ｓ３２７）資源ブローカサーバ１１は、タイマがタイムアウトすると、状態問合せメッセージを、資源マネージャサーバ１２へ送信する。
（Ｓ３２８）このとき、資源ブローカサーバ１１は、資源マネージャサーバ１２から未だ完了メッセージを受信していないので、オペレーションクライアント３へ未完了メッセージを返信する。
（Ｓ３２９）未完了メッセージを受信したオペレーションクライアント３は、タイマによって一定時間を再び計測する。
（Ｓ３３０）資源ブローカサーバ１１は、タイマがタイムアウトすると、状態問合せメッセージを、資源マネージャサーバ１２へ送信する。
（Ｓ３３１）このとき、資源マネージャサーバ１２は、対象設備システム２から既に完了メッセージを受信しているので、資源ブローカサーバ１１へ完了メッセージを返信する。
（Ｓ３３２）オペレーションクライアント３は、タイマがタイムアウトすると、状態問合せメッセージを、資源ブローカサーバ１１へ再び送信する。
（Ｓ３３３）このとき、資源ブローカサーバ１１は、資源マネージャサーバ１２から既に完了メッセージを受信しているので、オペレーションクライアント３へ完了メッセージを返信する。
このように、対象設備システム２としては、Ｓ３２６で資源の確保／開放／変更を完了しているにも拘わらず、オペレーションクライアント３がその旨を知る（同期を取る）ことができるのはＳ３３２の時である。
【００１５】
図３からも明らかなとおり、ポーリングの送信間隔を一定時間とすると、無駄にポーリングを送信することとなり、ネットワークに負荷をかけると共に、タイミングによっては資源状態の確認の遅れにつながる。従来技術によれば、クライアントは、一定時間間隔毎にポーリングを送信しているが、資源制御に要する処理時間は様々に変動する。この変動は、資源マネージャサーバ１２におけるその時点での負荷状態などの様々要因が関係している。従って、ポーリング間隔を、固定的に定めることは困難である。
【００１６】
このような問題に対して、ポーリング間隔を動的に制御する方法として、「クライアント側の監視情報に基づく制御」と、「サーバ側の監視情報に基づく制御」とがある。
【００１７】
「クライアント側の監視情報に基づく制御」によれば、第１に、ポーリングによってクライアントで得られた監視情報の履歴から、ポーリング送信間隔を変更する技術がある（例えば特許文献１参照）。この技術によれば、ネットワーク性能情報管理装置に適用され、ポーリングによってクライアントで得られた監視情報の履歴から性能値の時間変動率を計算する。その変動が大きい場合にはポーリング間隔を短く、変動が小さい場合にはポーリング間隔を長く変更する。
【００１８】
また、「クライアント側の監視情報に基づく制御」によれば、第２に、クライアントで得られたポーリング応答の成否から、ポーリング送信間隔を変更する技術がある（例えば特許文献２参照）。この技術によれば、ポーリング制御装置であって、クライアントにおいて観測されたポーリング応答の成否から通信品質を判断し、ポーリング成功が連続する間はポーリング間隔を伸長させ、ポーリング応答の不達やＮＡＣ応答があった場合にはポーリング間隔を短縮させる。
【００１９】
更に、「サーバ側の監視情報に基づく制御」によれば、サーバとクライアントの間でトランザクションの処理時間に関する情報を交換する技術もある（例えば特許文献３参照）。この技術によれば、サーバ側が、各トランザクションに対する計算資源（又はストレージ資源）の過去の利用時間の平均値からトランザクションの予測所要時間を計算する。サーバ側は、その予測所要時間をクライアントへ通知する。クライアントは、その予測所要遅延時間に従って、トランザクション要求を制御する。これにより、サーバの負荷低減と、クライアント側の不要な待ち時間の削減と、トランザクション要求の消失防止とを実現することができる。
【００２０】
【特許文献１】特開平１１−１５４９５５号公報
【特許文献２】特開２００４−３３６１１３号公報
【特許文献３】特開平７−１２９５１０号公報
【非特許文献１】ＳＯＡＰ  Version 1.2 （Ｗ３Ｃ勧告）
【発明の開示】
【発明が解決しようとする課題】
【００２１】
特許文献１又は２に記載された技術によれば、クライアント側の監視情報のみによって制御するために、定常的にポーリングを送信し、送信間隔調整に必要な情報を監視している必要がある。しかしながら、資源管理システムは、資源ブローカサーバが「クライアント」として機能し、資源マネージャサーバが「サーバ」として機能する。各資源の状態を管理しているのは、「サーバ」側となる。そのために、資源に対するアクセス頻度が少ないクライアント側の監視情報から、適切なポーリングタイミングを予測し且つ制御することは難しい。
【００２２】
また、特許文献３に記載された技術によれば、トランザクション単位で、ＣＰＵ又は補助記憶装置の使用時間履歴を記憶し、平均値からトランザクション所要時間を予測する。この技術を、資源管理システムにおけるトランザクションの分散化にそのまま適用した場合、性能及び精度の点で非効率である場合がある。具体的には、トランザクションがいくつかの子トランザクションの組み合わせで構成される場合、子トランザクションのパターンに対して、親トランザクションのパターンは、一般にＯ（Ｎ２）となる。そのために、トランザクション単位での管理は、データベース規模や消費メモリ量を大きくする。
【００２３】
従って、本発明は、２相コミットのシーケンスを実行する資源管理システムについて、無駄なポーリングが送信されることなく、資源状態を迅速に同期させることができるポーリング制御方法及びシステムを提供することを目的とする。
【課題を解決するための手段】
【００２４】
本発明によれば、資源要求の操作をするクライアントと、該クライアントから要求応答型プロトコルのポーリングを受け付ける資源ブローカサーバと、該資源ブローカサーバから要求応答型プロトコルのポーリングを受け付ける資源マネージャサーバとが階層型に構成された資源管理システムにおけるポーリング制御方法であって、
資源ブローカサーバは、クライアントから受信した資源要求メッセージの操作内容毎に、１つ以上の資源マネージャサーバへ資源要求メッセージを送信してから完了するまでの過去の処理時間を蓄積する第１の履歴情報データベースを有し、
クライアントが、資源要求メッセージを資源ブローカサーバへ送信するステップと、
資源ブローカサーバが、第１の履歴情報データベースを用いて資源要求メッセージの操作内容に応じた第１の所要時間ΔＳ１を含む資源受付メッセージを、クライアントへ返信するステップと、
クライアントが、資源受付メッセージを受信してから第１の所要時間ΔＳ１の経過後に、状態問合せメッセージを資源ブローカサーバへ送信するステップと
を有すると共に、
資源マネージャサーバは、資源ブローカサーバから受信した資源要求メッセージの対象設備装置毎に、１つ以上の対象設備装置へ資源要求メッセージを送信してから完了するまでの過去の処理時間を蓄積する第２の履歴情報データベースを有し、
資源ブローカサーバが、資源要求メッセージを資源マネージャサーバへ送信するステップと、
資源マネージャサーバが、第２の履歴情報データベースを用いて資源要求メッセージの対象設備装置に応じた第２の所要時間ΔＳ２を含む資源受付メッセージを、資源ブローカサーバへ返信するステップと、
資源ブローカサーバが、資源受付メッセージを受信してから第２の所要時間ΔＳ２の経過後に、状態問合せメッセージを資源マネージャサーバへ送信するステップと
を有することを特徴とする。
【００３０】
本発明のポーリング制御方法における他の実施形態によれば、
システムは、ネットワーク資源管理システム又は計算資源管理システムであり、
資源は、ネットワーク資源、又は、計算機／ストレージ資源である
ことも好ましい。
【００３１】
本発明によれば、資源要求の操作をするクライアントと、該クライアントから要求応答型プロトコルのポーリングを受け付ける資源ブローカサーバと、該資源ブローカサーバから要求応答型プロトコルのポーリングを受け付ける資源マネージャサーバとが階層型に構成された資源管理システムであって、
クライアントは、
資源要求メッセージを資源ブローカサーバへ送信する要求送信手段と、
資源ブローカサーバから、資源受付メッセージを受信する受付受信手段と、
資源受付メッセージを受信してから第１の所要時間ΔＳ１の経過を計測するタイマ手段と、
第１の所要時間ΔＳ１の経過後に、状態問合せメッセージを資源ブローカサーバへ送信する問合せ送信手段とを有し、
資源ブローカサーバは、
操作内容毎に、クライアントから受信した資源要求メッセージを１つ以上の資源マネージャサーバへ資源要求メッセージを送信してから完了するまでの過去の処理時間を蓄積する第１の履歴情報データベースと、
クライアントから資源要求メッセージを受信する要求受信手段と、
第１の履歴情報データベースを用いて資源要求メッセージの操作内容に応じた第１の所要時間ΔＳ１を取得する所要時間取得手段と、
第１の所要時間ΔＳ１を含む資源受付メッセージを、クライアントへ返信する受付送信手段と、
資源要求メッセージを資源マネージャサーバへ送信する要求送信手段と、
資源マネージャサーバから、資源受付メッセージを受信する受付受信手段と、
資源受付メッセージを受信してから第２の所要時間ΔＳ２の経過を計測するタイマ手段と、
第２の所要時間ΔＳ２の経過後に、状態問合せメッセージを資源マネージャサーバへ送信する問合せ送信手段とを有し、
資源マネージャサーバは、
対象設備装置毎に、資源ブローカサーバから受信した資源要求メッセージを該対象設備装置へ送信してから完了するまでの過去の処理時間を蓄積する第２の履歴情報データベースと、
資源ブローカサーバから、資源要求メッセージを受信する要求受信手段と、
第２の履歴情報データベースを用いて資源要求メッセージの対象設備装置に応じた第２の所要時間ΔＳ２を取得する所要時間取得手段と、
第２の所要時間ΔＳ２を含む資源受付メッセージを、資源ブローカサーバへ返信する受付送信手段と
を有することを特徴とする。
【００３７】
本発明のシステムにおける他の実施形態によれば、
システムは、ネットワーク資源管理システム又は計算資源管理システムであり、
資源は、ネットワーク資源、又は、計算機／ストレージ資源であることも好ましい。
【発明の効果】
【００３８】
本発明の資源管理システムにおけるポーリング制御方法及びシステムによれば、２相コミットのシーケンスを実行する資源管理システムについて、無駄なポーリングが送信されることなく、資源状態を迅速に同期させることができる。
【発明を実施するための最良の形態】
【００３９】
以下では、図面を用いて、本発明を実施するための最良の形態について詳細に説明する。
【００４０】
図４は、本発明における資源管理システム内のシーケンス図である。
【００４１】
図４によれば、「クライアント」−「サーバ」−「対象装置」のシーケンスが表されている。ここで、オペレーションクライアント３が「クライアント」となる場合、「サーバ」は資源ブローカサーバ１１であり、「対象装置」は資源マネージャサーバ１２となる。また、資源ブローカサーバ１１が「クライアント」となる場合、「サーバ」は資源マネージャサーバ１２であり、「対象装置」は対象設備システム２となる。
【００４２】
また、本発明における「サーバ」は、要求メッセージにおける過去の処理時間を蓄積する履歴情報データベースを備えている。例えば、要求メッセージの操作毎に及び／又は対象装置毎に、これら過去の処理時間の平均値を、所要時間ΔＳとして蓄積している。
【００４３】
１回のポーリングで成功する例を説明する。
（Ｓ４０１）クライアントが、サーバへ、要求メッセージを送信する。
（Ｓ４０２）サーバは、対象装置へ要求メッセージを更に送信すると共に、クライアントに対して受付メッセージを返信する。本発明の受付メッセージは、所要時間ΔＳを含む。
（Ｓ４０３）クライアントは、タイマによって所要時間ΔＳを計測する。
（Ｓ４０４）その後、対象装置は、処理の完了を、サーバへ通知する。ここで、サーバは、処理の完了をクライアントへ直ぐに通知することはできない。
（Ｓ４０５）その後、クライアントについて、所要時間ΔＳがタイムアウトする。このとき、クライアントは、サーバへ、問合せメッセージを送信する。
（Ｓ４０６）サーバは、対象装置の処理が既に完了しているので、完了メッセージを、クライアントへ返信する。
【００４４】
次に、２回のポーリングで成功する例を説明する。
（Ｓ４１１）クライアントが、サーバへ、要求メッセージを送信する。
（Ｓ４１２）サーバは、対象装置へ要求メッセージを更に送信すると共に、クライアントに対して受付メッセージを返信する。本発明の受付メッセージは、所要時間ΔＳを含む。
（Ｓ４１３）クライアントは、タイマによって所要時間ΔＳを計測する。
（Ｓ４１４）その後、クライアントについて、所要時間ΔＳがタイムアウトする。このとき、クライアントは、サーバへ、問合せメッセージを送信する。
（Ｓ４１５）サーバは、対象装置の処理がまだ完了していないので、未完了メッセージを、クライアントへ返信する。本発明の未完了メッセージは、修正所要時間ΔＳ''を含む。（Ｓ４１６）クライアントは、タイマによって、先の所要時間ΔＳよりも十分に短い所要時間ΔＳ'を計測する。ΔＳ'は、ΔＳ''と受付メッセージの受信時刻と未完了メッセージの受信時刻とに基づいて、クライアントが計算する。ΔＳ'には下限値Ｓｔを設け、その計算結果が、下限値を下回る場合にはＳｔをΔＳ'とする。
（Ｓ４１７）その後、対象装置は、処理の完了を、サーバへ通知する。ここで、サーバは、処理の完了をクライアントへ直ぐに通知することはできない。
（Ｓ４１８）その後、クライアントについて、所要時間ΔＳ'がタイムアウトする。このとき、クライアントは、サーバへ、問合せメッセージを再び送信する。
（Ｓ４１９）サーバは、対象装置の処理が既に完了しているので、完了メッセージを、クライアントへ返信する。
【００４５】
図５は、図３に対する本発明の２相コミットのシーケンス図である。
【００４６】
最初に、予約処理のシーケンスを説明する。
（Ｓ５０１）オペレーションクライアント３は、予約要求メッセージを、資源ブローカサーバ１１へ送信する。
（Ｓ５０２）資源ブローカサーバ１１は、予約要求メッセージを、資源マネージャサーバ１２へ送信すると共に、受付メッセージをオペレーションクライアント３へ返信する。このとき、受付メッセージは、所要時間ΔＳ１を含む。
（Ｓ５０３）受付メッセージを受信したオペレーションクライアント３は、タイマによって所要時間ΔＳ１を計測する。
（Ｓ５０４）資源マネージャサーバ１２は、対象設備システム２へ、資源を予約すると共に、受付メッセージを資源ブローカサーバ１１へ返信する。このとき、受付メッセージは、所要時間ΔＳ２を含む。
（Ｓ５０５）受付メッセージを受信した資源ブローカサーバ１１は、タイマによって所要時間ΔＳ２を計測する。
（Ｓ５０６）対象設備システム２は、資源の予約が完了すると、受付メッセージを資源マネージャサーバ１２へ送信する。
（Ｓ５０７）資源ブローカサーバ１１は、タイマがタイムアウトすると、状態問合せメッセージを、資源マネージャサーバ１２へ送信する。
（Ｓ５０８）このとき、資源マネージャサーバ１２は、対象設備システム２から既に受付メッセージを受信しているので、資源ブローカサーバ１１へ完了メッセージを返信する。
（Ｓ５０９）オペレーションクライアント３は、タイマがタイムアウトすると、状態問合せメッセージを、資源ブローカサーバ１１へ送信する。
（Ｓ５１０）このとき、資源ブローカサーバ１１は、資源マネージャサーバ１２から既に完了メッセージを受信しているので、オペレーションクライアント３へ完了メッセージを返信する。
【００４７】
次に、確定処理のシーケンスを説明する。
（Ｓ５２１）オペレーションクライアント３は、確定要求メッセージを、資源ブローカサーバ１１へ送信する。
（Ｓ５２２）資源ブローカサーバ１１は、確定要求メッセージを、資源マネージャサーバ１２へ送信すると共に、受付メッセージをオペレーションクライアント３へ返信する。このとき、受付メッセージは、所要時間ΔＳ３を含む。
（Ｓ５２３）受付メッセージを受信したオペレーションクライアント３は、タイマによって所要時間ΔＳ３を計測する。
（Ｓ５２４）資源マネージャサーバ１２は、対象設備システム２へ、資源の確保／開放／変更を要求すると共に、受付メッセージを資源ブローカサーバ１１へ返信する。このとき、受付メッセージは、所要時間ΔＳ４を含む。
（Ｓ５２５）受付メッセージを受信した資源ブローカサーバ１１は、タイマによって所要時間ΔＳ４を計測する。
（Ｓ５２６）対象設備システム２は、資源の確保／開放／変更が完了すると、完了メッセージを資源マネージャサーバ１２へ送信する。
（Ｓ５２７）資源ブローカサーバ１１は、タイマがタイムアウトすると、状態問合せメッセージを、資源マネージャサーバ１２へ送信する。
（Ｓ５２８）このとき、資源マネージャサーバ１２は、対象設備システム２から既に完了メッセージを受信しているので、資源ブローカサーバ１１へ完了メッセージを返信する。
（Ｓ５２９）オペレーションクライアント３は、タイマがタイムアウトすると、状態問合せメッセージを、資源ブローカサーバ１１へ送信する。
（Ｓ５３０）このとき、資源ブローカサーバ１１は、資源マネージャサーバ１２から既に完了メッセージを受信しているので、オペレーションクライアント３へ完了メッセージを返信する。
【００４８】
図６は、本発明におけるクライアント及びサーバの機能構成図である。
【００４９】
図６によれば、クライアント１３は、通信インタフェース部１３０と、資源要求部１３１と、要求送信部１３２と、受付受信部１３３と、タイマ部１３４と、問合せ送信部１３５と、状態受信部１３６とを有する。これら機能構成部は、装置に搭載されたコンピュータを機能させるクライアントプログラムを実行することによって実現される。
【００５０】
要求送信部１３２は、資源要求部１３１からの要求に応じて、要求メッセージをサーバへ送信する。要求メッセージは、例えば予約要求メッセージ又は確定要求メッセージである。
【００５１】
受付受信部１３３は、サーバから受付メッセージを受信する。受付受信部１３３は、受信した受付メッセージを資源要求部１３１へ通知すると共に、その受付メッセージに含まれる所要時間ΔＳをタイマ部へ通知する。
【００５２】
タイマ部１３４は、受付受信部１３３からの通知によって所要時間ΔＳの計測を開始する。タイムアウトした際に、タイマ部１３４は、問合せ送信部１３５へその旨を通知する。
【００５３】
問合せ送信部１３５は、タイマ部１３４からタイムアウトの通知を受けた際に、状態問合せメッセージをサーバへ送信する。
【００５４】
状態受信部１３６は、サーバから完了／未完了メッセージを受信する。完了／未完了メッセージは、例えば資源状態の完了／未完了を表す。受信した完了／未完了メッセージは、資源要求部１３１へ通知される。
【００５５】
図６によれば、サーバは、通信インタフェース部１４０と、資源要求実行部１４１と、要求受信部１４２と、受付送信部１４３と、所要時間取得部１４４と、問合せ受信部１４５と、状態送信部１４６と、履歴情報データベース１４７と、資源情報データベース１４８とを有する。これら機能構成部は、装置に搭載されたコンピュータを機能させるサーバプログラムを実行することによって実現される。
【００５６】
履歴情報データベース１４７は、要求メッセージにおける過去の処理時間を蓄積している。例えば、過去の処理時間の平均値を、所要時間ΔＳとしている。
【００５７】
要求受信部１４２は、クライアントから要求メッセージを受信する。要求メッセージは、例えば予約要求メッセージ又は確定要求メッセージである。要求メッセージは、資源要求実行部１４１へ通知されると共に、その旨が所要時間取得部１４４へ通知される。
【００５８】
所要時間取得部１４４は、受信した要求メッセージに応じて、履歴情報データベース１４７から所要時間ΔＳを取得する。その所要時間ΔＳは、受付送信部１４３へ通知される。
【００５９】
受付送信部１４３は、所要時間ΔＳを含む受付メッセージをクライアントへ返信する。
【００６０】
問合せ受信部１４５は、クライアントから問合せメッセージを受信する。問合せ内容を資源状態データベース１４８へ通知する。
【００６１】
資源状態データベースは、要求処理の進捗に従って、資源要求実行部１４１によって処理された最新の資源状態を蓄積している。問合せ受信部１４５から問合せ内容が通知されると、状態送信部１４６へその状態情報を通知する。
【００６２】
状態送信部１４６は、資源の予約／確定の完了／未完了メッセージを、クライアントへ送信する。
【００６３】
資源要求実行部１４１は、クライアントからの要求に応じて、処理を実行する。ここで、サーバの資源要求実行部１４１がクライアントの機能をそのまま備え、更なるサーバへ予約要求及び確定要求をやりとりすることもできる。資源要求実行部１４１は、処理した要求内容に応じて、その処理に要した時間を履歴情報データベース１４７へ通知する。例えば、サーバが資源ブローカサーバである場合、資源ブローカサーバの資源要求実行部１４１は、資源マネージャサーバに対するクライアント機能を有する。
【００６４】
図７は、履歴情報データベースに蓄積されるテーブル情報の説明図である。以下では、２つのパターンについて説明する。
【００６５】
［パターンＡ］
親トランザクションと子トランザクションとのシーケンスを構成する場合である。オペレーションクライアント３に対して、資源ブローカサーバ１１が「サーバ」として機能し、複数の資源マネージャサーバ１２が「対象装置」として機能する場合、資源ブローカサーバ１１がオペレーションクライアント３へ返信する１つの受付メッセージに含まれる所要時間ΔＳは、対象となる資源マネージャサーバ１２と、各資源マネージャサーバの所要時間とに依存する。また、資源マネージャサーバ１２が「サーバ」として機能し、複数の対象装置が「対象装置」となる場合、資源マネージャサーバ１２が資源ブローカサーバ１１へ返信する１つの受付メッセージに含まれる所要時間ΔＳは、対象装置と、各対象装置の所要時間とに依存する。親トランザクションの所要時間は、その下位層に位置する１つ以上の子トランザクションの所要時間の組み合わせである。そのために、データベースのレコードを、資源マネージャサーバ及び対象装置毎に構築することによって、そのレコード数をＯ（ｌｏｇＮ）に抑えることができる。
【００６６】
資源ブローカサーバ１１の履歴情報データベース１４７のテーブルは、資源ブローカサーバ１１が、オペレーションクライアント３に対する「サーバ」として機能する場合の例である。処理対象となる資源マネージャサーバ毎に、「確保」「開放」「変更」それぞれについて、所要時間履歴が蓄積されている。例えば、資源マネージャサーバ＃１に対する予約確保の場合、その所要時間履歴の全ての時間の平均値を、その所要時間ΔＳとすることができる。
【００６７】
資源マネージャサーバ１２の履歴情報データベース１４７のテーブルは、資源マネージャサーバ１２が、資源ブローカサーバ１１に対する「サーバ」として機能する場合の例である。処理対象となる対象設備システムの機器毎に、所要時間履歴が蓄積されている。対象装置に対する操作はいずれのオペレーションの場合も機器設定の変更であり、所要時間に大きな差は生じない。例えば、装置♯１に対する資源の「確保」「開放」「変更」は、その装置の所要時間履歴の全ての時間の平均値を、その所要時間ΔＳとすることができる。
【００６８】
［パターンＢ］
１つのトランザクションだけで構成する場合である。即ち、実行対象が、そのサーバ自身の保持する履歴状態データベースのみである。具体的には、端点又は要求ＩＤ（識別子）をキーとした検索である。但し、「確保」「開放」「変更」と操作が異なる場合、データベースに対する処理も異なる。「確保」「変更」操作の場合には、全経路から条件に合う経路を探し出すか、又は、「変更」要求と競合する経路がないか探し出す、という検索処理を実行するために、ほぼ同等のデータベース処理となる。一方、「開放」操作は、要求ＩＤを探すのみであり、「確保」「変更」の操作に対して、所要処理時間は異なることが想定される。
【００６９】
以上、詳細に説明したように、本発明の資源管理システムにおけるポーリング制御方法及びシステムによれば、２相コミットのシーケンスを実行する資源管理システムについて、無駄なポーリングが送信されることなく、資源状態を迅速に同期させることができる。特に、サーバ側が、過去の所要時間履歴から適切なポーリングのタイミングを算出し、クライアントのポーリングのタイミングを動的に変更することができるので、より適切なタイミングでポーリングを実行することができる。これは、過剰なポーリングによる通信資源・計算資源の浪費の抑止につながる。また、２相コミットのシーケンスを実行する場合、特に、ポーリング間隔が粗であることによる処理結果の同期遅延が無い。資源管理システムに適用することにより、オペレーションクライアント及び対象設備システムに不要な負荷をかけることなく、資源ブローカサーバの保持する資源状態を、資源マネージャサーバの保持する資源状態に迅速に同期させることができる。
【００７０】
前述した本発明の種々の実施形態において、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。
【図面の簡単な説明】
【００７１】
【図１】対象設備システムに資源管理システムを備えたシステム構成図である。
【図２】資源管理システムのシステム構成図である。
【図３】従来技術の２相コミットのシーケンス図である。
【図４】本発明における資源管理システム内のシーケンス図である。
【図５】図３に対する本発明の２相コミットのシーケンス図である。
【図６】本発明におけるクライアント及びサーバの機能構成図である。
【図７】履歴情報データベースに蓄積されるテーブル情報の説明図である。
【符号の説明】
【００７２】
１  資源管理システム
１１  資源ブローカサーバ
１２  資源マネージャサーバ
１３  クライアント
１３０  通信インタフェース部
１３１  資源要求部
１３２  要求送信部
１３３  受付受信部
１３４  タイマ部
１３５  問合せ送信部
１３６  状態受信部
１４  サーバ
１４０  通信インタフェース部
１４１  資源要求実行部
１４２  要求受信部
１４３  受付送信部
１４４  所要時間取得部
１４５  問合せ受信部
１４６  状態送信部
１４７  履歴情報データベース
１４８  資源情報データベース
２  対象設備システム
３  オペレーションクライアント
【図１】
0004911532.tif 000002
【図２】
0004911532.tif 000003
【図３】
0004911532.tif 000004
【図４】
0004911532.tif 000005
【図５】
0004911532.tif 000006
【図６】
0004911532.tif 000007
【図７】
0004911532.tif 000008