(57)【要約】  Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有するＷｅｂサービスの予約であるＷｅｂサービス予約の要求とＷｅｂサービスを実行することができる少なくとも１つのサーバの状態とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理ステップと、受信したＷｅｂサービスリクエストの時間間隔と受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、受信したＷｅｂサービスリクエストが受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、Ｗｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストをサーバへ転送する転送ステップとをコンピュータに実行させる。
2008126190.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御をコンピュータに実行させるＷｅｂサービス制御プログラムであって、
Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理ステップと、
前記コンシューマからのＷｅｂサービスリクエストを受信した場合、受信したＷｅｂサービスリクエストの時間間隔と前記受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、
前記適合判定ステップにより前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送ステップと
をコンピュータに実行させるＷｅｂサービス制御プログラム。
【請求項２】
請求項１に記載のＷｅｂサービス制御プログラムにおいて、
前記管理ステップは、電子的交渉に基づいて前記Ｗｅｂサービス予約の要求を受信し、前記電子的交渉に基づいて該Ｗｅｂサービス予約の受諾または拒絶を示す応答を送信し、
前記受諾を示す応答は、該Ｗｅｂサービス予約の予約識別子を含むことを特徴とするＷｅｂサービス制御プログラム。
【請求項３】
請求項２に記載のＷｅｂサービス制御プログラムにおいて、
前記適合判定ステップは、前記受信したＷｅｂサービスリクエストに前記予約識別子が付加されており、且つ前記受信したＷｅｂサービスリクエストが該予約識別子に対応した前記Ｗｅｂサービス予約における前記Ｗｅｂサービスリクエストの条件を満たす場合、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合すると判定することを特徴とするＷｅｂサービス制御プログラム。
【請求項４】
請求項１に記載のＷｅｂサービス制御プログラムにおいて、
前記転送ステップは、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約における前記Ｗｅｂサービスリクエストの条件を満たす場合、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合すると判定することを特徴とするＷｅｂサービス制御プログラム。
【請求項５】
請求項１に記載のＷｅｂサービス制御プログラムにおいて、
前記サーバの状態は、該サーバの処理能力を含み、
前記管理ステップは、前記処理能力が前記Ｗｅｂサービス予約を実行可能であると判定した場合、該Ｗｅｂサービス予約を受諾することを特徴とするＷｅｂサービス制御プログラム。
【請求項６】
請求項１に記載のＷｅｂサービス制御プログラムにおいて、
前記Ｗｅｂサービスリクエストの条件は更に、前記コンシューマから前記プロバイダへ送信されるＷｅｂサービスリクエストの期間の条件を含むことを特徴とするＷｅｂサービス制御プログラム。
【請求項７】
請求項６に記載のＷｅｂサービス制御プログラムにおいて、
前記Ｗｅｂサービス予約の要求は、前記コンシューマから前記プロバイダへ送信されるＷｅｂサービスリクエストの期間及び処理量を含み、
前記管理ステップは、前記Ｗｅｂサービス予約の要求に示された期間において予約されていない前記サーバの処理能力が該Ｗｅｂサービス予約の要求に示された処理量以上である場合、該Ｗｅｂサービス予約を受諾すると判定することを特徴とするＷｅｂサービス制御プログラム。
【請求項８】
請求項１に記載のＷｅｂサービス制御プログラムにおいて、
前記転送ステップは、前記適合判定ステップにより受信されたＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合しないと判定された場合、該Ｗｅｂサービスリクエストの拒絶を行うことを特徴とするＷｅｂサービス制御プログラム。
【請求項９】
請求項１に記載のＷｅｂサービス制御プログラムにおいて、
前記Ｗｅｂサービスは、ＳＯＡＰ、ＲＥＳＴ、ＣＯＲＢＡ、ＨＴＴＰの少なくともいずれかを用いることを特徴とするＷｅｂサービス制御プログラム。
【請求項１０】
Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御装置であって、
Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理部と、
前記コンシューマからのＷｅｂサービスリクエストを受信した場合、受信したＷｅｂサービスリクエストの時間間隔と前記受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定部と、
前記適合判定部により前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送部と
を備えるＷｅｂサービス制御装置。
【請求項１１】
請求項１０に記載のＷｅｂサービス制御装置において、
前記管理部は、電子的交渉に基づいて前記Ｗｅｂサービス予約の要求を受信し、前記電子的交渉に基づいて該Ｗｅｂサービス予約の受諾または拒絶を示す応答を送信し、
前記受諾を示す応答は、該Ｗｅｂサービス予約の予約識別子を含むことを特徴とするＷｅｂサービス制御装置。
【請求項１２】
請求項１１に記載のＷｅｂサービス制御装置において、
前記適合判定部は、前記受信したＷｅｂサービスリクエストに前記予約識別子が付加されており、且つ前記受信したＷｅｂサービスリクエストが該予約識別子に対応した前記Ｗｅｂサービス予約における前記Ｗｅｂサービスリクエストの条件を満たす場合、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合すると判定することを特徴とするＷｅｂサービス制御装置。
【請求項１３】
請求項１０に記載のＷｅｂサービス制御装置において、
前記転送部は、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約における前記Ｗｅｂサービスリクエストの条件を満たす場合、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合すると判定することを特徴とするＷｅｂサービス制御装置。
【請求項１４】
請求項１０に記載のＷｅｂサービス制御装置において、
前記サーバの状態は、該サーバの処理能力を含み、
前記管理部は、前記処理能力が前記Ｗｅｂサービス予約を実行可能であると判定した場合、該Ｗｅｂサービス予約を受諾することを特徴とするＷｅｂサービス制御装置。
【請求項１５】
Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御方法であって、
Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理ステップと、
前記コンシューマからのＷｅｂサービスリクエストを受信した場合、受信したＷｅｂサービスリクエストの時間間隔と前記受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、
前記適合判定ステップにより前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送ステップと
を実行するＷｅｂサービス制御方法。
【請求項１６】
Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の中継をコンピュータに実行させる中継プログラムであって、
Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求を送信し、該Ｗｅｂサービス予約が受諾された場合、該受諾を示す応答を受信する予約要求ステップと、
前記コンシューマからＷｅｂサービスリクエストが発行された場合、前記受諾されたＷｅｂサービス予約に設定された前記下限値に基づくタイミングで該Ｗｅｂサービスリクエストを前記プロバイダへ送信する送信ステップと
をコンピュータに実行させる中継プログラム。
【請求項１７】
請求項１６に記載の中継プログラムにおいて、
前記送信ステップは、複数のＷｅｂサービスリクエストが前記コンシューマから発行された場合、前記受諾されたＷｅｂサービス予約に示された前記下限値以上の時間間隔で前記複数のＷｅｂサービスリクエストのそれぞれを前記プロバイダへ送信することを特徴とする中継プログラム。
【請求項１８】
請求項１６に記載の中継プログラムにおいて、
前記送信ステップは、複数のＷｅｂサービスリクエストが前記コンシューマから発行された場合、発行されたＷｅｂサービスリクエストに対応する前記受諾されたＷｅｂサービス予約を識別し、前記発行されたＷｅｂサービスリクエストを前記プロバイダへ送信する時間間隔を前記Ｗｅｂサービス予約毎に管理し、前記Ｗｅｂサービス予約毎の該時間間隔が対応する前記下限値以上になるように制御することを特徴とする中継プログラム。
【請求項１９】
請求項１６に記載の中継プログラムにおいて、
前記Ｗｅｂサービス予約の要求に対する前記受諾を示す応答は、該Ｗｅｂサービス予約の識別子である予約識別子を含み、
前記送信ステップは、前記受諾されたＷｅｂサービス予約の予約識別子を前記発行されたＷｅｂサービスリクエストに付加し、該Ｗｅｂサービスリクエストを前記プロバイダへ送信することを特徴とする中継プログラム。
【請求項２０】
請求項１６に記載の中継プログラムにおいて、
前記管理ステップは、電子的交渉に基づいて前記Ｗｅｂサービス予約の要求を送信し、前記電子的交渉に基づいて該Ｗｅｂサービス予約の受諾または拒絶を示す応答を受信することを特徴とする中継プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御プログラム、Ｗｅｂサービス制御装置、Ｗｅｂサービス制御方法、中継プログラムに関するものである。
【背景技術】
【０００２】
近年、サービスを疎に接続してシステムを作るＳＯＡ（Service Oriented Architecture）の技術潮流が起きている。また、従来のＷｅｂサービスシステムにおいて、プロバイダは、コンシューマが将来送信するＷｅｂサービスリクエスト量を予想し、その最大ピーク量によって用意すべきサーバの設備容量を決定していた。【０００３】
また、ＧＧＦ（Global Grid Forum）において標準化されたＷＳ（Web Service）−Ａｇｒｅｅｍｅｎｔ仕様など、電子的交渉の技術が提案されている。【０００４】
なお、本発明の関連ある従来技術として、相対する当事者間のビジネス相互作用を管理する方法及び装置がある（例えば、特許文献１参照）。また、分散型マルチメディアアプリケーションのためにエンドツーエンドのサービス品質交渉を提供する方法がある（例えば、特許文献２参照）。
【特許文献１】特開２００６−１４６８９２号公報
【特許文献２】特表２００４−５３７１８７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のＷｅｂサービスシステムにおいて、プロバイダ側のオペレータは、コンシューマ側の複数の顧客の明確な利用計画を得ることなくＷｅｂサービスリクエスト量の見積もりを行っていた。また、オペレータは、運用開始後にＷｅｂサービスリクエスト量の予想が外れた場合、設備容量を調整する必要があった。これらの作業は、オペレータが行うため、工数が掛かるとともに、誤りが起こるリスクがあった。また、オペレータは、設備容量の追加のために顧客にヒアリングを行うが、顧客が大量になったり、ヒアリングの頻度が上がったりすると、見積もりが困難になっていた。【０００６】
更に、プロバイダは、設備容量を超えるリクエストを受ける場合があり、これを技術的にも契約的にも防ぐことができないため、サーバが過負荷になり不安定になるリスクがあった。【０００７】
また、科学技術計算のサービスの場合、必要なリソースの見積もりは容易であるが、Ｗｅｂサービスの場合、突発的にリクエストが増加するケースなどが存在するため、必要なリソースの見積もりは困難である。【０００８】
本発明は上述した問題点を解決するためになされたものであり、予約に基づいて受け入れるＷｅｂサービスリクエスト量を制御することができるＷｅｂサービス制御プログラム、Ｗｅｂサービス制御装置、Ｗｅｂサービス制御方法、中継プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決するため、本発明は、Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御をコンピュータに実行させるＷｅｂサービス制御プログラムであって、Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理ステップと、前記コンシューマからのＷｅｂサービスリクエストを受信した場合、受信したＷｅｂサービスリクエストの時間間隔と前記受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、前記適合判定ステップにより前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送ステップとをコンピュータに実行させる。【００１０】
また、本発明は、Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御装置であって、Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理部と、前記コンシューマからのＷｅｂサービスリクエストを受信した場合、受信したＷｅｂサービスリクエストの時間間隔と前記受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定部と、前記適合判定部により前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送部とを備える。【００１１】
また、本発明は、Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御方法であって、Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理ステップと、前記コンシューマからのＷｅｂサービスリクエストを受信した場合、受信したＷｅｂサービスリクエストの時間間隔と前記受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、前記適合判定ステップにより前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送ステップとを実行する。【００１２】
また、本発明は、Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の中継をコンピュータに実行させる中継プログラムであって、Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求を送信し、該Ｗｅｂサービス予約が受諾された場合、該受諾を示す応答を受信する予約要求ステップと、前記コンシューマからＷｅｂサービスリクエストが発行された場合、前記受諾されたＷｅｂサービス予約に設定された前記下限値に基づくタイミングで該Ｗｅｂサービスリクエストを前記プロバイダへ送信する送信ステップとをコンピュータに実行させる。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係るＷｅｂサービスシステムの構成の一例を示すブロック図である。
【図２】実施の形態１に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。
【図３】実施の形態１に係る価格表の内容の一例を示す表である。
【図４】実施の形態１に係る利用計画表の内容の第１の例を示す表である。
【図５】実施の形態１に係る利用計画表の内容の第２の例を示す表である。
【図６】実施の形態１に係る予約リクエストの内容の一例を示す図である。
【図７】実施の形態１に係る予約リプライの内容の一例を示す図である。
【図８】実施の形態１に係るプロバイダ予約情報テーブルの内容の一例を示す表である。
【図９】実施の形態１に係るサーバ情報テーブルの内容の一例を示す表である。
【図１０】実施の形態１に係るコンシューマ予約情報テーブルの内容の一例を示す表である。
【図１１】実施の形態１に係る通過判定情報テーブルの内容の一例を示す表である。
【図１２】実施の形態２に係るＷｅｂサービスシステムの構成の一例を示すブロック図である。
【図１３】実施の形態２に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。
【図１４】実施の形態２に係るサービスプロファイルの一例を示すグラフである。
【図１５】実施の形態３に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。
【図１６】従来の負荷分散装置の動作の一例を示すブロック図である。
【図１７】従来の負荷分散装置により保持されるｃｏｏｋｉｅテーブルの一例を示す表である。
【図１８】実施の形態４に係るＷｅｂサービスリクエストの一例を示す図である。
【図１９】実施の形態４に係るＣＫの動作の一例を示すフローチャートである。
【図２０】実施の形態５に係るＣＣの動作の一例を示すフローチャートである。
【図２１】実施の形態５に係るＣＫの動作の一例を示すフローチャートである。
【図２２】単位時間当たりのＷｅｂサービスリクエスト数を用いる場合にサーバが受信するＷｅｂサービスリクエストの時間分布の一例を示すタイムチャートである。
【図２３】実施の形態５に係るＭＳＩを用いる場合にサーバが受信するＷｅｂサービスリクエストの時間分布の一例を示すタイムチャートである。
【図２４】実施の形態５に係るサービスプロファイルの一例を示すグラフである。
【発明を実施するための最良の形態】
【００１４】
以下、本発明の実施の形態について図面を参照しつつ説明する。【００１５】
実施の形態１．
本実施の形態に係るＷｅｂサービスシステムにおけるＷｅｂサービスは、Ｗｅｂ  Ｓｅｒｖｉｃｅ／ＳＯＡＰ（Simple Object Access Protocol）、ＲＥＳＴ（Representational State Transfer）、ＨＴＴＰ（HyperText Transfer Protocol）等を用いるサービスである。【００１６】
また、本実施の形態においては、収入印紙サービスを提供するＷｅｂサービスシステムについて説明する。収入印紙サービスにおいて、プロバイダは、コンシューマから電子決済で発行された電子領収書を受け取り、その電子領収書に収入印紙（タイムスタンプ）を押す。サービスを受けたコンシューマは、国に支払う額とプロバイダの手数料とを合わせてプロバイダに支払う。以下、このサービスは、サービス種別"ＴＳＳｅｒｖｉｃｅ"で表され、このサービスにより提供される機能（関数）は"ｓｔａｍｐ"、"ｃｈｅｃｋ"で表される。【００１７】
まず、本実施の形態に係るＷｅｂサービスシステムの構成について説明する。【００１８】
図１は、本実施の形態に係るＷｅｂサービスシステムの構成の一例を示すブロック図である。このＷｅｂサービスシステムは、コンシューマ側に、ＣＣ（Contract Client）１１（中継装置）、少なくとも１つのクライアント１２、計画端末１３、各部署端末１４を備え、プロバイダ側に、ＣＭ（Contract Manager）２１、ＣＫ（Contract Keeper）２２、少なくとも１つのサーバ２３、オペレータ端末２４、プロバイダ端末３１を備える。ここで、ＣＭ２１、ＣＫ２２、サーバ２３、オペレータ端末２４は、データセンタ内に設けられる。【００１９】
クライアント１２は、ＣＣ１１に接続される。ＣＣ１１は、ネットワーク１を介してＣＭ２１及びＣＫ２２に接続される。なお、ＣＣ１１とクライアント１２は、一つの装置内にあっても良い。計画端末１３は、ネットワーク１を介してＣＭ２１に接続される。各部署端末１４は、計画端末１３に接続される。ＣＭ２１は、ＣＫ２２及びサーバ２３に接続される。ＣＫ２２は、サーバ２３に接続される。オペレータ端末２４は、ＣＭ２１及びサーバ２３に接続される。【００２０】
各部署端末１４は、コンシューマの各部署におけるサービスの利用計画を決定する。計画端末１３は、コンシューマにおけるサービスの利用計画の取り纏めを行う。クライアント１２は、Ｗｅｂサービスのクライアントプログラムを実行する。オペレータ端末２４は、オペレータが操作する端末であり、サーバ２３の監視や制御を行う。プロバイダ端末３１は、プロバイダの担当者が操作する端末であり、価格表などの入力を行う。【００２１】
次に、本実施の形態に係るＷｅｂサービスシステムの動作について説明する。【００２２】
図２は、本実施の形態に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。このシーケンス図は、コンシューマ側における各部署端末１４、クライアント１２、計画端末１３、ＣＣ１１、プロバイダ側におけるＣＭ２１、ＣＫ２２、ノード、オペレータ端末２４、プロバイダ端末３１の動作を示す。プロバイダ側において、ノードは、サービスに割り当てられる少なくとも１つのサーバ２３である。このＷｅｂサービスシステムは、Ｗｅｂサービス予約処理（Ｓ１１〜Ｓ３１）、Ｗｅｂサービス実行処理（Ｓ３２〜Ｓ４３）を行う。【００２３】
次に、Ｗｅｂサービス予約処理について説明する。【００２４】
プロバイダ端末３１は、プロバイダの営業の担当者等により作成されたサービスの価格表をＣＭ２１へ送信する（Ｓ１１）。次に、ＣＭ２１は、受信した価格表を計画端末１３へ送信する（Ｓ１２）。次に、計画端末１３は、受信した価格表を各部署端末１４へ転送する（Ｓ１３）。【００２５】
ここで、価格表について説明する。図３は、本実施の形態に係る価格表の内容の一例を示す表である。この価格表は、上述したＴＳＳｅｒｖｉｃｅのｓｔａｍｐのサービスに対する価格を示すものである。この価格表は、サービスを利用する期間を分類した期間区分の一覧と共に、期間区分毎のサービスの単価を示す。期間区分には、その期間区分を示す開始日及び終了日の年月日、日数が記入される。また、期間区分は、Ｗｅｂサービスリクエスト量のレベルが異なる期間（繁忙期や閑散期）に分けられている。単価には、電子領収書１枚（１リクエスト）あたりの価格［円／枚］が記入される。更に、予約する枚数の上限である枚数上限が記入されても良い。なお、単価は、予約時に支払う予約時単価、実行時に支払う実行時単価に分けられても良い。【００２６】
次に、各部署の担当者は、受信した価格表及び過去のサービスの利用実績表に基づいて自部署のサービスの利用計画を策定し、各部署端末１４は、その利用計画を計画端末１３へ通知する（Ｓ１４）。【００２７】
次に、計画端末１３は、各部署からの利用計画を取り纏めることにより利用計画表を作成し、ＣＣ１１へ送信する（Ｓ１５）。【００２８】
ここで、利用計画表について説明する。図４は、本実施の形態に係る利用計画表の内容の第１の例を示す表である。この利用計画表は、サービスを利用する期間区分の一覧と共に、期間区分毎の予約量合計、予約量増分、単価、見積もり額を示す。【００２９】
期間区分には、価格表と同じ値が記入される。予約量合計は、予約するＷｅｂサービスリクエスト数の合計を表し、予約量増分は、新たに予約するＷｅｂサービスリクエスト数を表す。予約量合計には、過去の利用計画表における予約量の合計である更新前予約量合計［枚］、今回までの予約量の合計である更新後予約量合計［枚］が記入される。予約量増分には、予約量増分［枚］、１日あたりの予約量増分［枚／日］が記入される。単価には、価格表と同じ値が記入される。見積もり額には、サービスに支払う料金の増分（予約量増分×単価）が記入される。また、この例の利用計画表は、最初に作成された利用計画表である。従って、更新前予約量合計は全て０であり、更新後予約量合計と予約量増分は等しい。【００３０】
また、計画端末１３は、利用計画表をＣＣ１１へ送信した後も、利用計画の更新を行い、更新前の利用計画表との差分を示す利用計画表をＣＣ１１へ送信することができる。図５は、本実施の形態に係る利用計画表の内容の第２の例を示す表である。図５の利用計画表は、図４の利用計画表の次に作成された利用計画表である。従って、図５の更新前予約量合計は図４の更新後予約量合計に等しく、図５の更新後予約量合計は更新前予約量合計に予約量増分を加えた値である。【００３１】
次に、ＣＣ１１は、ＣＭ２１に対してサービスの予約のための電子的交渉を開始する（Ｓ２１）。次に、ＣＭ２１は、電子的交渉の仕様に従って認証などの準備を行う（Ｓ２２）。次に、ＣＣ１１は、予約リクエストをＣＭ２１へ送信する（Ｓ２３，Ｓ２５）。次に、ＣＭ２１は、予約条件及び受信した予約リクエストに基づいて予約リクエストを受諾するか拒絶するかの判定を行う予約判定処理、その判定結果に応じて予約リプライをＣＣ１１へ送信する予約応答処理を行う（Ｓ２４，Ｓ２６）。【００３２】
ここで、予約リクエスト及び予約リプライは、電子的交渉の仕様（例えば、ＧＧＦ  ＷＳ−Ａｇｒｅｅｍｅｎｔ仕様）で定められたＡｇｒｅｅｍｅｎｔ文書の形式に従う機械可読式契約書であり、ＸＭＬ（Extensible Markup Language）等で記述される。受諾を示す予約リプライがＣＭ２１からＣＣ１１へ渡されると、その契約が成立したことになる。また、この契約にあたって、プロバイダは、予約されたリクエスト条件と異なるＷｅｂサービスリクエストを拒絶できることを、コンシューマに示す。【００３３】
ここで、予約リクエストの内容について説明する。図６は、本実施の形態に係る予約リクエストの内容の一例を示す図である。予約リクエストには、対象サービス、予約期間（期間）、要求量が記述される。対象サービスは、サービス種別（ｓｅｒｖｉｃｅ）、機能（ｔｅｒｍ）で表される。この例において、サービス種別はＴＳＳｅｒｖｉｃｅ、機能はｓｔａｍｐである。予約期間は、開始時刻及び終了時刻で表される。要求量は、Ｗｅｂサービスリクエスト量（処理量）であり、単位と数値が記述される。この例において、単位はＲＰＳ（Ｒｅｑｕｅｓｔ／ｓｅｃ）、数値は２０である。【００３４】
次に、予約リプライの内容について説明する。図７は、本実施の形態に係る予約リプライの内容の一例を示す図である。予約リプライには、対象サービス、予約期間、要求量、受け付け状況が記述される。対象サービス、予約期間、要求量は、対応する予約リクエストと同一の値である。受け付け状況は、予約判定処理の結果に応じて、予約リクエストが受諾されたことを示す「受け付け完了」、または予約リクエストが拒絶されたことを示す「拒絶」となる。ここで、予約リクエストが受諾された場合、予約リクエストに記された予約を行うことにより契約が成立し、この契約に対してＣＭ２１により契約ＩＤが与えられ、予約リプライに記載される。この例の予約リプライにおいて、受け付け状況は「受け付け完了」であり、契約ＩＤが記載されている。【００３５】
また、ＣＭ２１は、プロバイダ予約情報テーブルを保持しており、予約が成立した場合、成立した予約の情報をプロバイダ予約情報テーブルに登録する。図８は、本実施の形態に係るプロバイダ予約情報テーブルの内容の一例を示す表である。プロバイダ予約情報テーブルは、成立した予約毎の情報であるプロバイダ予約情報を有する。プロバイダ予約情報は、契約ＩＤ（Agreement ID）、要求元、開始時刻、終了時刻、対象サービス、必要能力の値を有する。契約ＩＤは、予約リプライと同一の値である。要求元は、コンシューマの名称である。予約期間（開始時刻、終了時刻）、対象サービスは、受諾した予約リクエストに記述された値と同一である。必要能力は、受諾した予約リクエストに記述された要求量の値と同一であり、実行に必要なサーバの処理能力を表す。【００３６】
次に、ＣＭ２１は、受信した予約リクエストで要求されている予約期間を対象期間とし、対象期間とプロバイダ予約情報テーブルに基づいてサーバ情報テーブルを作成する。図９は、本実施の形態に係るサーバ情報テーブルの内容の一例を示す表である。サーバ情報テーブルは、サーバ２３毎のサーバ情報を示す。サーバ情報は、対象期間におけるサーバ２３の状態であり、保有能力［ＲＰＳ］、予約済み能力［％］、残存能力［％］の値を有する。保有能力は、そのサーバが持つ処理能力の最大値をサービス毎のＷｅｂサービスリクエスト量で表した値である。この例において、サービスは、ＴＳＳｅｒｖｉｃｅのｓｔａｍｐ、ＴＳＳｅｒｖｉｃｅのｃｈｅｃｋである。予約済み能力は、対象期間において予約済みの処理能力の合計を保有能力に対する割合［％］として表した値である。残存能力は、（１００％−予約済み能力）であり、予約されていない処理能力を保有能力に対する割合［％］として表した値である。【００３７】
次に、ＣＭ２１は、予約リクエストの内容が予約条件を満たすか否かの判断を行う。予約条件を満たす場合、ＣＭ２１は、予約リクエストの内容をプロバイダ予約情報として登録し、受諾を示す予約リプライをクライアント１２に返す。一方、予約条件を満たさない場合、ＣＭ２１は、拒絶を示す予約リプライをクライアント１２に返す。予約条件とは、予約リクエストにおける要求量がサーバ情報テーブルにおける残存能力以下であること、とする。即ち、ＣＭ２１は、受信した予約リクエストの要求量が残存能力を超えている場合、その予約リクエストの拒絶を示す予約リプライを返す。【００３８】
なお、予め予約準備期間を設定し、ＣＭ２１が（予約リクエストにおける予約期間の開始時刻−予約準備期間）をその予約リクエストの予約〆切時刻として設定するとき、予約条件は、現在時刻が予約リクエストの予約〆切時刻以前であること、としても良い。即ち、ＣＭ２１は、予約リクエストを受信した時点の現在時刻がその予約リクエストの予約〆切時刻を過ぎている場合、その予約リクエストの拒絶を示す予約リプライを返す。【００３９】
また、ＣＣ１１は、コンシューマ予約情報テーブルを保持し、受諾を示す予約リプライを受信した場合、その内容をコンシューマ予約情報テーブルに登録する。図１０は、本実施の形態に係るコンシューマ予約情報テーブルの内容の一例を示す表である。コンシューマ予約情報テーブルは、受諾を示す予約リプライ毎の情報であるコンシューマ予約情報を有する。コンシューマ予約情報は、プロバイダ予約情報と同様の契約ＩＤ、予約期間（開始時刻及び終了時刻）、対象サービス、必要能力の値を有する。【００４０】
次に、ＣＭ２１は、プロバイダ予約情報をオペレータ端末２４に送信する（Ｓ３１）。オペレータは、オペレータ端末２４上のプロバイダ予約情報を見ることにより、ノードの割り当てを決定する。【００４１】
次に、Ｗｅｂサービス実行処理について説明する。【００４２】
オペレータ端末２４は、ＣＭ２１から受信した対象のプロバイダ予約情報に従って、対象のプロバイダ予約情報の予約期間の開始時刻までに、対象のプロバイダ予約情報の必要能力を確保するだけのサーバ２３をノードとして割り当てる（Ｓ３２）。また、オペレータ端末２４は、対象のプロバイダ予約情報の予約期間が終了した場合、対象のプロバイダ予約情報の必要能力分のノードを解放する。【００４３】
次に、ＣＭ２１は、対象のプロバイダ予約情報における予約期間の開始時刻になると、対象のプロバイダ予約情報をＣＫ２２へ送信し、ＣＫ２２は、受信したプロバイダ予約情報の内容を通過判定情報テーブルに登録する（Ｓ３３）。また、ＣＭ２１は、現在時刻が通過判定情報の予約期間の終了時刻を過ぎた場合、その通過判定情報を通過判定情報テーブルから削除する。【００４４】
ここで、通過判定情報テーブルについて説明する。図１１は、本実施の形態に係る通過判定情報テーブルの内容の一例を示す表である。通過判定情報テーブルは、受信したプロバイダ予約情報毎の通過判定情報を有する。通過判定情報は、ＣＫ２２がＷｅｂサービスリクエストを判定するための情報であり、プロバイダ予約情報のうち、契約ＩＤ、要求元、対象サービス、必要能力の値を有する。また、通過判定情報テーブルは、予約期間が現在時刻を含む通過判定情報のみを有する。【００４５】
次に、クライアント１２は、Ｗｅｂサービスのクライアントプログラムにより、ＣＣ１１及びＣＫ２２を介してノードへＷｅｂサービスリクエストを送信する。クライアント１２からのＷｅｂサービスリクエストを受信したＣＣ１１は、このＷｅｂサービスリクエストが付加条件を満たす場合、クライアント予約情報テーブルから対応する契約ＩＤを取得し、このＷｅｂサービスリクエストに契約ＩＤを付加する。ここで、付加条件は、対象サービスがＷｅｂサービスリクエストと同一であり、且つ、予約期間が現在時刻を含んでいるクライアント予約情報が、クライアント予約情報テーブルに存在することである。【００４６】
また、ＣＫ２２は、ＣＣ１１からのＷｅｂサービスリクエストを受信し、このＷｅｂサービスリクエストと通過判定情報テーブルを比較し、このＷｅｂサービスリクエストが通過条件を満たす場合、Ｗｅｂサービスリクエストをノードへ転送する（Ｓ４１，Ｓ４２）。また、ＣＫ２２は、受信したＷｅｂサービスリクエストが通過条件を満たさない場合、Ｗｅｂサービスリクエストをノードへ転送せず、拒絶の通知をクライアント１２へ送信する（Ｓ４３）。ここで、通過条件は、受信したＷｅｂサービスリクエストの契約ＩＤと同一の通過判定情報が通過判定情報テーブルに存在し、且つその契約ＩＤを持つＷｅｂサービスリクエスト量が通過判定情報の必要能力以下であること、とする。【００４７】
なお、通過条件は、上述した１つの条件だけではなく、複数の通過条件が設定されても良い。この場合、複数の通過条件に対して異なる単価が設定されても良い。【００４８】
ノードは、ＣＫ２２から受信したＷｅｂサービスリクエストに従ってサービスを実行し、その結果をクライアント１２へ送信する。ＣＫ２２は、通過させたＷｅｂサービスリクエストの情報をＣＭ２１へ渡す。ＣＭ２１は、Ｗｅｂサービスリクエストの情報を要求元毎、対象サービス毎、期間区分毎に集計し、実績情報テーブルとして記録する。この実績情報テーブルは、コンシューマに対する利用料金の請求に用いられる。【００４９】
本実施の形態によれば、ＣＫ２２は、予約された条件を満たさないＷｅｂサービスリクエストを拒絶することができる。更に、好ましくないＷｅｂサービスリクエストの拒絶が可能になったことにより、ノードの過負荷を防ぐことができ、システムの安定性を向上させることができる。また、Ｗｅｂサービスリクエスト量の予約が自動化されることにより、オペレータの工数が大幅に削減でき、大量のコンシューマや頻繁なＷｅｂサービスリクエスト量の予約の頻繁な更新にも対処することができる。また、予約準備期間を設けることにより、予約期間前に設備増強などの対策を打つことができる。【００５０】
また、自律システムを用いたＷｅｂサービスシステムと比較すると、本実施の形態のＷｅｂサービスシステムは、制御が容易であり、設備の準備やコストの算出が容易である。【００５１】
実施の形態２．
本実施の形態においては、サーバ群がグリッドシステムであるＷｅｂサービスシステムについて説明する。【００５２】
まず、本実施の形態に係るＷｅｂサービスシステムの構成について説明する。【００５３】
図１２は、本実施の形態に係るＷｅｂサービスシステムの構成の一例を示すブロック図である。この図において、図１と同一符号は図１に示された対象と同一又は相当物を示しており、ここでの説明を省略する。この図は、図１と比較すると、新たにグリッド運用サーバ２５を備える。また、ＣＭ２１は、ＣＫ２２及びグリッド運用サーバ２５に接続される。オペレータ端末２４は、グリッド運用サーバ２５に接続される。複数のサーバ２３からなるサーバ群は、グリッドシステムを構成し、グリッド運用サーバ２５により制御される。また、このサーバ群は、グリッド運用サーバ２５により本実施の形態のＷｅｂサービス以外のノードとして割り当てられることができる。【００５４】
次に、本実施の形態に係るＷｅｂサービスシステムの動作について説明する。【００５５】
図１３は、本実施の形態に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。この図において、図２と同一符号は図２に示された対象と同一又は相当物を示しており、ここでの説明を省略する。この図は、図２と比較すると、オペレータ端末２４の動作の代わりにグリッド運用サーバ２５の動作を示す。このＷｅｂサービスシステムは、Ｗｅｂサービス予約処理（Ｓ１１〜Ｓ５１）、Ｗｅｂサービス実行処理（Ｓ５２〜Ｓ６４）を行う。【００５６】
次に、Ｗｅｂサービス予約処理について説明する。【００５７】
まず、処理Ｓ１１〜Ｓ２６は、実施の形態１と同様である。次に、ＣＭ２１は、予約リクエストの内容が予約条件を満たす場合、グリッド運用サーバ２５に対して、予約条件を満たすサーバ２３を予約期間直前にノードとして割り当てるための予約であるサーバ予約処理を行う（Ｓ５１）。【００５８】
次に、Ｗｅｂサービス実行処理について説明する。【００５９】
グリッド運用サーバ２５は、サーバ予約処理に従って、対象とする予約期間の開始時刻直前になると、予約されたサーバ２３をグリッドシステムのノードとして設定（デプロイ）する（Ｓ５２，Ｓ６２）。また、グリッド運用サーバ２５は、対象の予約期間が終了した場合、対象のノードを解放する。【００６０】
サーバ予約処理において、ＣＭ２１は、予め設定されたサーバ２３毎の安定運用限界値を用いて、どれだけのサーバ２３を予約するかを決定する。安定運用限界値は、上述した保有能力と等しい。図１４は、本実施の形態に係るサービスプロファイルの一例を示すグラフである。このサービスプロファイルは、横軸をＷｅｂサービスリクエスト量［ＲＰＳ］とし、縦軸を処理遅延（ＲＴＴ：Round Trip Time）［ｓｅｃ］とした座標に、Ｗｅｂサービスリクエスト量と処理遅延との相関を曲線として表したグラフである。また、このサービスプロファイルは、Ｗｅｂサービスシステムの運用開始前の性能試験により計測される。このサービスプロファイルによれば、Ｗｅｂサービスリクエスト量が運用限界値を超えると急激に処理遅延が増加する。更に、性能試験時と実際の運用時の誤差の許容量である誤差許容量が定められ、Ｗｅｂサービスリクエスト量が運用限界値を超えることのないよう、（運用限界値−誤差許容量）である安定運用限界値が定められる。【００６１】
サーバ予約処理において、ＣＭ２１は、サーバ情報テーブルに基づいて、サーバ２３毎のＷｅｂサービスリクエスト量が安定運用限界値以下（安定運用域）になるようにサーバ２３を予約する。例えば、全てのサーバ２３の安定運用限界値が等しいとすると、予約する必要能力の合計を安定運用限界値で除した値以上の最小整数のサーバ２３を予約する。例えば、第１の予約により第１のサーバ２３が予約され、第２の予約の予約期間における必要能力が第１のサーバの安定運用限界値を超える場合、追加の第２のサーバ２３が予約される。その結果、グリッド運用サーバ２５は、第１の予約の開始時刻で第１のサーバ２３を割り当て（Ｓ５２）、第２の予約の開始時刻で第２のサーバ２３を割り当てる（Ｓ６２）。【００６２】
また、処理Ｓ５３，Ｓ６１，Ｓ６３，Ｓ６４は、それぞれ実施の形態１における処理Ｓ３３，Ｓ４１，Ｓ４２，Ｓ４３と同様である。【００６３】
本実施の形態によれば、グリッド運用サーバ２５が予約された必要能力に応じて自動的にノードを割り当てることにより、オペレータの負担を軽減すると共に、設備準備量の誤りをなくし、Ｗｅｂサービスシステムの安定性を向上させることができる。また、グリッド運用サーバ２５が必要なタイミングで必要なノードを割り当てることにより、サーバ２３の利用率を向上させることができる。【００６４】
なお、複数のサーバ２３は、データセンタ以外の場所に配置されても良いし、複数の場所に分散して配置されても良い。【００６５】
実施の形態３．
本実施の形態においては、サーバ群がグリッドシステムであり、サーバ毎の安定運用限界値を調整するＷｅｂサービスシステムについて説明する。【００６６】
本実施の形態に係るＷｅｂサービスシステムの構成は、実施の形態２と同様である。【００６７】
本実施の形態に係るＷｅｂサービスシステムの動作について説明する。【００６８】
図１５は、本実施の形態に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。この図において、図１３と同一符号は図１３に示された対象と同一又は相当物を示しており、ここでの説明を省略する。この図は、図１３と比較すると、新たに、処理Ｓ６５〜Ｓ６７を行う。【００６９】
上述したように安定運用限界値の初期値は、運用前の試験の結果に対して余裕を持って低めに設定されている。処理Ｓ１１〜Ｓ６４は、実施の形態２と同様に行われる。次に、グリッド運用サーバ２５は、稼働中のノードから負荷指標を取得し（Ｓ６５，Ｓ６６）、ＣＭ２１へ渡す（Ｓ６７）。負荷指標（負荷情報）とは、ＣＰＵ使用率、ネットワーク使用量、メモリ使用量などである。次に、ＣＭ２１は、プロバイダ予約情報テーブル、実績情報テーブル、負荷指標等の処理能力の実測値に基づいて誤差許容量及び安定運用限界値を再設定する。ここで、ＣＭ２１は、処理能力の実測値と現在の安定運用限界値を比較し、処理能力の実測値に対して安定運用限界値が高すぎる場合、例えば、実際のＷｅｂサービスリクエスト量に対する実際の処理遅延がサービスプロファイルから得られる処理遅延より小さい場合、安定運用限界値を増加させる。また、ＣＭ２１は、実際の処理能力に対して安定運用限界値が低すぎる場合、例えば、実際のＷｅｂサービスリクエスト量に対する実際の処理遅延がサービスプロファイルから得られる処理遅延より大きい場合、安定運用限界値を増加させる。また、ＣＭ２１は、安定運用限界値の再設定を行った場合、再びサーバ予約処理を行う。【００７０】
従来のＷｅｂサービスシステムにおいて、運用開始前の未定な要因により誤差許容量は余裕を持って大きい値に設定する必要があった。本実施の形態によれば、運用開始前に誤差許容量が大き過ぎる値に設定された場合でも、運用中に誤差許容値を見直し、誤差許容量を適切な値に減少させることができる。従って、安定運用限界値が大きくなり、準備する設備量を少なくし、運用コストを削減することができる。逆に、運用中の負荷指標が悪化した場合、誤差許容量を大きくし、安定運用限界値が小さくすることにより、以後に予約されるＷｅｂサービスリクエスト量を抑え、Ｗｅｂサービスシステムの安定性を優先させることができる。【００７１】
実施の形態４．
本実施の形態においては、コンシューマからプロバイダへのＷｅｂサービスリクエストにおける複数のプロトコルレイヤの情報に契約ＩＤを付加するＷｅｂサービスシステムについて説明する。【００７２】
上述した各実施の形態において、ＷｅｂサービスがＳＯＡＰを用いる場合、ＣＣ１１がＷｅｂサービスリクエストのＳＯＡＰ  ｅｎｖｅｌｏｐｅ内に契約ＩＤを付加し、ＣＫ２２は、ＳＯＡＰ  ｅｎｖｅｌｏｐｅ内の契約ＩＤを検出する必要がある。この場合、ＣＫ２２は、ＳＯＡＰ  ｅｎｖｅｌｏｐｅを記述するＸＭＬの構文解析を行う必要があり、この処理は、ＣＫ２２の負荷を増大させる。【００７３】
本実施の形態に係るＷｅｂサービスシステムの構成は、実施の形態１と同様であるが、ＣＫ２２は、レイヤ７スイッチを用いて実現される。本実施の形態に係るＷｅｂサービスシステムの動作は、実施の形態１と同様であるが、処理Ｓ４１，Ｓ４２，Ｓ４３におけるＣＣ１１及びＣＫ２２の動作が異なる。【００７４】
ここで、レイヤ７スイッチで構成された従来の負荷分散装置の例を用い、レイヤ７スイッチの動作について説明する。【００７５】
図１６は、従来の負荷分散装置の動作の一例を示すブロック図である。負荷分散装置１１１は、クライアント１１２と複数のサーバ１１３ａ，１１３ｂ，１１３ｃとに接続され、クライアント１１２と複数のサーバ１１３ａ，１１３ｂ，１１３ｃとの間の中継を行う。クライアント１１２が、サーバへ最初のリクエストを送信すると、受信したサーバ１１３ａは、ｃｏｏｋｉｅを挿入したリプライをクライアント１１２へ送信する。このときのリプライは、例えば以下のようになる。【００７６】
ＨＴＴＰ／１．１  ２００  ＯＫ
Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃｕｓｔｏｍｅｒ＝“ＷＩＬＥ＿Ｅ＿ＣＯＹＯＴＥ”；【００７７】
ｃｏｏｋｉｅを受信したクライアント１１２は、以後、継続する一連のｈｔｔｐリクエストにｃｏｏｋｉｅを挿入し、サーバへ送信する。このときのリクエストには、例えば以下のヘッダが付加される。【００７８】
ＰＯＳＴ  ／ａｃｍｅ／ｐｉｃｋｉｔｅｍ  ＨＴＴＰ／１．１
Ｃｏｏｋｉｅ：  Ｃｕｓｔｏｍｅｒ＝“ＷＩＬＥ＿Ｅ＿ＣＯＹＯＴＥ”；【００７９】
負荷分散装置１１１は、リクエスト及びリプライからｃｏｏｋｉｅを抽出することにより、ｃｏｏｋｉｅを含むクライアント１１２からのリクエストを、そのｃｏｏｋｉｅを発行したサーバ１１３ａへ振り分ける。図１７は、従来の負荷分散装置により保持されるｃｏｏｋｉｅテーブルの一例を示す表である。負荷分散装置１１１は、このｃｏｏｋｉｅテーブルのように、発行されたｃｏｏｋｉｅ毎に、発行元のノードの識別子を保持する。負荷分散装置１１１は、ｃｏｏｋｉｅヘッダを持つリクエストが通過する度に、ｃｏｏｋｉｅテーブルを参照し、送るべきノードを決定する。【００８０】
本実施の形態におけるＣＫ２２は、上述したｃｏｏｋｉｅテーブルの代わりに通過判定情報テーブルを用い、ｃｏｏｋｉｅの代わりに契約ＩＤを用いることにより、容易にレイヤ７スイッチを流用することができる。【００８１】
処理Ｓ４１，Ｓ４２，Ｓ４３において、クライアント１２は、Ｗｅｂサービスのクライアントプログラムにより、ＣＣ１１及びＣＫ２２を介してノードへＷｅｂサービスリクエストを送信する。クライアント１２からのＷｅｂサービスリクエストを受信したＣＣ１１は、このＷｅｂサービスリクエストが付加条件を満たす場合、クライアント予約情報テーブルから対応する契約ＩＤを取得し、このＷｅｂサービスリクエストのＳＯＡＰ  ｅｎｖｅｌｏｐｅ内に契約ＩＤを付加する。更に、ＣＣ１１は、このＷｅｂサービスリクエストのＳＯＡＰ  ｅｎｖｅｌｏｐｅ外のＨＴＴＰヘッダにも契約ＩＤを付加する。【００８２】
図１８は、本実施の形態に係るＷｅｂサービスリクエストの一例を示す図である。この図において、契約ＩＤは、ＳＯＡＰヘッダにおいて“ＳＯＡＰ−ｗｅｄｇｅ−ｃｏｎｔｒａｃｔ−ｉｄ”として挿入されていると共に、ＨＴＴＰヘッダにおいて“Ｘ−ｗｅｄｇｅ−ｃｏｎｔｒａｃｔ−ｉｄ”として挿入されている。【００８３】
ＣＣ１１からのＷｅｂサービスリクエストを受信したＣＫ２２は、このＷｅｂサービスリクエストと通過判定情報テーブルを比較し、このＷｅｂサービスリクエストが通過条件を満たす場合、Ｗｅｂサービスリクエストをノードへ転送する（Ｓ４１，Ｓ４２）。また、ＣＫ２２は、受信したＷｅｂサービスリクエストが通過条件を満たさない場合、Ｗｅｂサービスリクエストをノードへ転送せず、拒絶の通知をクライアント１２へ送信する（Ｓ４３）。本実施の形態における通過条件は、受信したＷｅｂサービスリクエストのＨＴＴＰヘッダ及びＳＯＡＰ  ｅｎｖｅｌｏｐｅの少なくともいずれかに契約ＩＤが存在し、且つその契約ＩＤを含む通過判定情報が通過判定情報テーブル中に存在し、且つその契約ＩＤを持つＷｅｂサービスリクエスト量が通過判定情報の必要能力以下であること、とする。【００８４】
次に、処理Ｓ４１，Ｓ４２，Ｓ４３におけるＣＫ２２の動作について説明する。図１９は、本実施の形態に係るＣＫの動作の一例を示すフローチャートである。まず、ＣＫ２２は、受信したＷｅｂサービスリクエストのＨＴＴＰヘッダの解析を行い（Ｓ１１１）、そのＨＴＴＰヘッダに通過判定情報テーブル中の契約ＩＤが含まれているか否かの判定を行う（Ｓ１１２）。契約ＩＤが含まれている場合（Ｓ１１２，Ｙ）、処理Ｓ１１５へ移行する。契約ＩＤが含まれていない場合（Ｓ１１２，Ｎ）、ＣＫ２２は、受信したＷｅｂサービスリクエストのＳＯＡＰ  ｅｎｖｅｌｏｐｅの解析を行い（Ｓ１１３）、そのＳＯＡＰ  ｅｎｖｅｌｏｐｅに通過判定情報テーブル中の契約ＩＤが含まれているか否かの判定を行う（Ｓ１１４）。契約ＩＤが含まれている場合（Ｓ１１４，Ｙ）、処理Ｓ１１５へ移行する。【００８５】
契約ＩＤが含まれていない場合（Ｓ１１４，Ｎ）、ＣＫ２２は、通過条件を満たさないと判定し（Ｓ１２１）、このフローは終了する。【００８６】
処理Ｓ１１２またはＳ１１４において契約ＩＤが含まれている場合、ＣＫ２２は、その契約ＩＤを含む通過判定情報が通過判定情報テーブル中に存在するか否かの判断を行う（Ｓ１１５）。通過判定情報テーブル中に存在しない場合（Ｓ１１５，Ｎ）、処理Ｓ１２１へ移行する。通過判定情報テーブル中に存在する場合（Ｓ１１５，Ｙ）、ＣＫ２２は、その契約ＩＤを持つＷｅｂサービスリクエスト量が通過判定情報の必要能力以下であるか否かの判断を行う（Ｓ１１６）。必要能力以下でない場合（Ｓ１１６，Ｎ）、処理Ｓ１２１へ移行する。必要能力以下である場合（Ｓ１１６，Ｙ）、ＣＫ２２は、通過条件を満たすと判定し、このフローは終了する。【００８７】
ここで、ＳＯＡＰ  ｅｎｖｅｌｏｐｅを表すＸＭＬの構文に比べてＨＴＴＰの構文は単純であるため、ＳＯＡＰ  ｅｎｖｅｌｏｐｅ中の契約ＩＤを検出する処理に比べて、ＨＴＴＰヘッダ中の契約ＩＤを検出する処理は負荷が低い。特に、レイヤ７スイッチは、ＨＴＴＰの処理を効率よく行うように設計されているため、ＣＫ２２の処理を高速化することができる。【００８８】
なお、本実施の形態におけるＣＣ１１は、ＷｅｂサービスリクエストのＳＯＡＰ  ｅｎｖｅｌｏｐｅとＨＴＴＰヘッダの両方に契約ＩＤを付加するとしたが、ＨＴＴＰヘッダに契約ＩＤを付加する機能を持たないＣＣが存在する場合でも、上述したＣＫ２２の動作によれば、少なくともＳＯＡＰ  ｅｎｖｅｌｏｐｅに契約ＩＤが付加されているＷｅｂサービスリクエストは、ノードへ転送することができる。【００８９】
また、本実施の形態においては、サービス呼び出しのためのプロトコルとしてＳＯＡＰを用い、ＳＯＡＰより下位の送受信のためのプロトコルとしてＨＴＴＰを用いたが、それぞれ他のプロトコルを用いても良い。ＳＯＡＰの代わりのプロトコルとしては、ＣＯＲＢＡ（Common Object Request Broker Architecture）  ｏｖｅｒ  ｈｔｔｐ、ＲＥＳＴ等がある。更に、上述したそれぞれの実施の形態を組み合わせても良い。【００９０】
本実施の形態によれば、ＣＣ１１がＷｅｂサービスリクエストのＨＴＴＰヘッダにも契約ＩＤを負荷し、ＣＫ２２がＷｅｂサービスリクエストのＨＴＴＰヘッダにおける契約ＩＤを検出することにより、ＣＫ２２の処理を軽減し、高速化することができる。また、既存のレイヤ７スイッチを流用してＣＫ２２を構成することにより、ＣＫ２２のコストを抑えることができる。【００９１】
実施の形態５．
本実施の形態においては、Ｗｅｂサービスリクエスト量の新たな尺度を用いたＷｅｂサービスシステムについて説明する。【００９２】
上述した各実施の形態においては、Ｗｅｂサービスリクエスト量の尺度を単位時間（１秒）当たりのＷｅｂサービスリクエスト数［ＲＰＳ］（Ｒｅｑｕｅｓｔ／ｓｅｃ）としたが、この尺度を用いてもコンシューマとプロバイダの間で確実な同期を取ることは困難な場合がある。また、この尺度を用いてもＷｅｂサービスリクエストのバースト性（短期間に大量の処理が投入されること）により、サーバの安定性を損なう場合がある。例えば、１００［ＲＰＳ］の契約において、コンシューマが契約期間の最初の０．００１秒間に９９リクエストを送信する等、Ｗｅｂサービスリクエストの時間分布が極端に偏る場合が発生し得る。【００９３】
本実施の形態においては、Ｗｅｂサービスリクエスト量の新たな尺度として、ＭＳＩ（Minimum Service Interval）を定義する。ＭＳＩは、連続して送信されるＷｅｂサービスリクエストの時間間隔の下限値［ｍｓｅｃ］を表す。Ｗｅｂサービスリクエスト量ｘ［ｍｓｅｃ］の予約の予約期間において、直前のＷｅｂサービスリクエストの送信からｘ［ｍｓｅｃ］以上経過していない時点での新たなＷｅｂサービスリクエストの送信は拒絶される。【００９４】
本実施の形態に係るＷｅｂサービスシステムの構成及び動作は、実施の形態１と同様であるが、ＣＣ１１及びＣＫ２２の動作が異なる。【００９５】
上述した実施の形態において単位時間当たりのＷｅｂサービスリクエスト数の尺度で表されていたＷｅｂサービスリクエスト量（要求量、保有能力、残存能力、必要能力、運用限界値、誤差許容量、安定運用限界値）は、本実施の形態においてＭＳＩの尺度で表される。【００９６】
ここで、Ｗｅｂサービスリクエスト量（要求量及び必要能力）がＭＳＩでｘ［ｍｓｅｃ］と設定された予約の予約期間におけるＣＣ１１及びＣＫ２２の動作について説明する。【００９７】
まず、処理Ｓ４１，Ｓ４２，Ｓ４３におけるＣＣ１１の動作について説明する。クライアント１２からのＷｅｂサービスリクエストを受信したＣＣ１１は、このＷｅｂサービスリクエストが付加条件を満たす場合、クライアント予約情報テーブルから対応する契約ＩＤを取得し、このＷｅｂサービスリクエストに契約ＩＤを付加する。【００９８】
ＣＣ１１は、契約ＩＤ毎にＷｅｂサービスリクエストをＣＫ２２へ送信する時間間隔を計測するための送信間隔タイマを有し、ＷｅｂサービスリクエストをＣＫ２２へ送信する度にその契約ＩＤの送信間隔タイマをリセットする。図２０は、本実施の形態に係るＣＣの動作の一例を示すフローチャートである。ＣＣ１１がクライアント１２からのＷｅｂサービスリクエストを受信すると、このフローは開始する。まず、ＣＣ１１は、受信したＷｅｂサービスリクエストが対象サービス条件を満たすか否かの判断を行う（Ｓ１３１）。対象サービス条件とは、受信したＷｅｂサービスリクエスト中の対象サービスと一致するクライアント予約情報がクライアント予約情報テーブルに存在することである。【００９９】
対象サービス条件を満たさない場合（Ｓ１３１，Ｎ）、Ｗｅｂサービスリクエストの拒絶の応答をクライアント１２へ送信し（Ｓ１４１）、このフローは終了する。対象サービス条件を満たす場合（Ｓ１３１，Ｙ）、ＣＣ１１は、現在時刻が予約期間条件を満たすか否かの判断を行う（Ｓ１３２）。予約期間条件とは、予約期間が現在時刻を含んでいるクライアント予約情報がクライアント予約情報テーブルに存在することである。【０１００】
予約期間条件を満たさない場合（Ｓ１３２，Ｎ）、処理Ｓ１４１へ移行する。予約期間条件を満たす場合（Ｓ１３２，Ｙ）、ＣＣ１１は、現在時刻が送信間隔条件を満たすか否かの判断を行う（Ｓ１３３）。送信間隔条件とは、当該Ｗｅｂサービスリクエスト中の契約ＩＤに対応する送信間隔タイマの値がｘ［ｍｓｅｃ］以上であることである。送信間隔条件を満たさない場合（Ｓ１３３，Ｎ）、処理Ｓ１３２へ戻り、受信したＷｅｂサービスリクエストを送信せずに保持する。送信間隔条件を満たす場合（Ｓ１３３，Ｙ）、ＣＣ１１は、受信したＷｅｂサービスリクエストをＣＫ２２へ送信し（Ｓ１４２）、その契約ＩＤの送信間隔タイマをリセットし（Ｓ１４３）、このフローは終了する。【０１０１】
上述したＣＣ１１の動作によれば、ＣＣ１１がＷｅｂサービスリクエストをＣＫ２２へ送信する時間間隔は、必ず予約量のｘ［ｍｓｅｃ］以上になる。【０１０２】
次に、処理Ｓ４１，Ｓ４２，Ｓ４３におけるＣＫ２２の動作について説明する。ＣＫ２２は、契約ＩＤ毎にＷｅｂサービスリクエストをＣＣ１１から受信した時間間隔を計測するための受信間隔タイマを有し、ＷｅｂサービスリクエストをＣＣ１１から受信する度にその契約ＩＤの受信間隔タイマをリセットする。図２１は、本実施の形態に係るＣＫの動作の一例を示すフローチャートである。ＣＫ２２がＣＣ１１からのＷｅｂサービスリクエストを受信すると、このフローは開始する。まず、ＣＫ２２は、受信したＷｅｂサービスリクエストが契約ＩＤ条件を満たすか否かの判断を行う（Ｓ１５１）。契約ＩＤ条件とは、受信したＷｅｂサービスリクエスト中の契約ＩＤと一致する通過判定情報が通過判定情報テーブルに存在することである。【０１０３】
契約ＩＤ条件を満たさない場合（Ｓ１５１，Ｎ）、Ｗｅｂサービスリクエストの拒絶の応答をＣＣ１１へ送信し（Ｓ１６１）、このフローは終了する。契約ＩＤ条件を満たす場合（Ｓ１５１，Ｙ）、ＣＫ２２は、当該Ｗｅｂサービスリクエストの受信時刻が受信間隔条件を満たすか否かの判断を行う（Ｓ１５３）。受信間隔条件とは、当該Ｗｅｂサービスリクエスト中の契約ＩＤに対応する受信間隔タイマの値がｘ［ｍｓｅｃ］以上であることである。受信間隔条件を満たさない場合（Ｓ１５３，Ｎ）、処理Ｓ１６１へ移行する。受信間隔条件を満たす場合（Ｓ１５３，Ｙ）、ＣＣ１１は、受信したＷｅｂサービスリクエストを契約ＩＤに割り当てられたノードへ転送し（Ｓ１６２）、その契約ＩＤの受信間隔タイマをリセットし（Ｓ１６３）、このフローは終了する。【０１０４】
上述したＣＫ２２の動作によれば、ＣＫ２２は、予約量のｘ［ｍｓｅｃ］を下回る時間間隔で受信したＷｅｂサービスリクエストを拒絶することができ、ＣＫ２２がＷｅｂサービスリクエストをサーバへ転送する時間間隔は、必ず予約量のｘ［ｍｓｅｃ］以上になる。【０１０５】
次に、Ｗｅｂサービスリクエスト量の尺度に単位時間当たりのＷｅｂサービスリクエスト数［ＲＰＳ］を用いる場合とＭＳＩ［ｍｓｅｃ］を用いる場合について比較して説明する。図２２は、単位時間当たりのＷｅｂサービスリクエスト数を用いる場合にサーバが受信するＷｅｂサービスリクエストの時間分布の一例を示すタイムチャートである。この図において、横軸は時刻、縦軸はＷｅｂサービスリクエスト数を表し、１つの“Ｘ”印が１つのＷｅｂサービスリクエストを表す。また、予約期間を示す。上述したように予約量を単位時間当たりのＷｅｂサービスリクエスト数で表す場合、予約期間開始時にＷｅｂサービスリクエストが殺到する等の偏りが発生する。【０１０６】
図２３は、本実施の形態に係るＭＳＩを用いる場合にサーバが受信するＷｅｂサービスリクエストの時間分布の一例を示すタイムチャートである。表記方法は、尺度ＲＰＳの場合と同様である。予約量をＭＳＩで表す場合、予約期間内で満遍なくＷｅｂサービスリクエストがサーバに到着する。【０１０７】
次に、実施の形態２または実施の形態３のように、サーバ群がグリッドシステムであり、サーバ毎の安定運用限界値を用いる場合について説明する。【０１０８】
サーバ予約処理において、ＣＭ２１は、予め設定されたサーバ２３毎の安定運用限界値を用いて、どれだけのサーバ２３を予約するかを決定する。安定運用限界値は、上述した保有能力と等しい。図２４は、本実施の形態に係るサービスプロファイルの一例を示すグラフである。このサービスプロファイルは、Ｗｅｂサービスリクエスト量をＭＳＩで表す場合に、横軸をＭＳＩ［ｍｓｅｃ］とし、縦軸を処理遅延（ＲＴＴ）［ｓｅｃ］とした座標に、Ｗｅｂサービスリクエスト量と処理遅延との相関を曲線として表したグラフである。また、このサービスプロファイルは、Ｗｅｂサービスシステムの運用開始前の性能試験により計測される。このサービスプロファイルによれば、ＭＳＩが運用限界値を下回ると急激に処理遅延が増加する。更に、性能試験時と実際の運用時の誤差の許容量である誤差許容量が定められ、ＭＳＩが運用限界値を下回ることのないよう、（運用限界値＋誤差許容量）である安定運用限界値が定められる。【０１０９】
本実施の形態においては、実施の形態３に示したサーバ予約処理において、ＣＭ２１は、サーバ情報テーブルに基づいて、サーバ２３毎のＭＳＩが安定運用限界値以上（安定運用域）になるようにサーバ２３を予約する。例えば、全てのサーバ２３の安定運用限界値が等しいとすると、予約する必要能力のＭＳＩの逆数の合計に安定運用限界値を乗じた値以上となる最小の数のサーバ２３を予約する。例えば、第１の予約により第１のサーバ２３が予約され、第２の予約の予約期間において第１の予約及び第２の予約の必要能力のＭＳＩの逆数の合計が第１のサーバの安定運用限界値の逆数を上回る場合、追加の第２のサーバ２３が予約される。【０１１０】
本実施の形態によれば、Ｗｅｂサービスリクエスト量の尺度にＭＳＩを導入することにより、プロバイダが受信するＷｅｂサービスリクエスト量のバースト性を回避することができ、Ｗｅｂサービスシステムの安定性の向上させることができる。また、Ｗｅｂサービスリクエスト量の尺度を単位時間当たりのＷｅｂサービスリクエスト数とする場合と比較して、Ｗｅｂサービスリクエスト量の尺度をＭＳＩにすると、ＣＫ２２がＷｅｂサービスリクエストを通過させるか否かの判定の論理を簡単にし、ＣＫ２２の負荷を低減することができる。従って、ＣＫ２２の安定性を向上させる、あるいはＣＫ２２のコストを低減することができる。また、契約におけるＷｅｂサービスリクエスト量の意味を簡明にすることができる。【０１１１】
なお、上述した実施の形態の組み合わせも、容易に実現することができる。【０１１２】
また、上述した実施の形態に係るＣＣ１１，ＣＭ２１，ＣＫ２２は、情報通信装置に容易に適用することができ、情報通信装置の性能をより高めることができる。ここで、情報通信装置には、例えばサーバ、ルータ、スイッチ等が含まれ得る。【０１１３】
更に、Ｗｅｂサービスシステムを構成するコンピュータにおいて上述した各ステップを実行させるプログラムを、Ｗｅｂサービス制御プログラムとして提供することができる。上述したプログラムは、コンピュータにより読取り可能な記録媒体に記憶させることによって、Ｗｅｂサービスシステムを構成するコンピュータに実行させることが可能となる。更に、ＣＣを構成するコンピュータにおいて上述した各ステップを実行させるプログラムを、中継プログラムとして提供することができる。上述したプログラムは、コンピュータにより読取り可能な記録媒体に記憶させることによって、ＣＣを構成するコンピュータに実行させることが可能となる。【０１１４】
ここで、上記コンピュータにより読取り可能な記録媒体としては、ＲＯＭやＲＡＭ等のコンピュータに内部実装される内部記憶装置、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。【０１１５】
なお、管理ステップは、実施の形態における処理Ｓ２２，Ｓ２４，Ｓ２６に対応する。また、適合判定ステップ及び転送ステップは、実施の形態における処理Ｓ４１〜Ｓ４３のうちＣＫ２２による処理に対応する。【０１１６】
また、予約要求ステップは、実施の形態における処理Ｓ２１，Ｓ２３，Ｓ２５に対応する。また、送信ステップは、実施の形態における処理Ｓ４１〜Ｓ４３のうちＣＣ１１による処理に対応する。【０１１７】
また、管理部は、実施の形態におけるＣＭ２１に対応する。また、適合判定部及び転送部は、実施の形態におけるＣＫ２２に対応する。
【産業上の利用可能性】
【０１１８】
本発明によれば、予約に基づいて受け入れるＷｅｂサービスリクエスト量を制御することができる。
【図１】
2008126190.tif 000003
【図２】
2008126190.tif 000004
【図３】
2008126190.tif 000005
【図４】
2008126190.tif 000006
【図５】
2008126190.tif 000007
【図６】
2008126190.tif 000008
【図７】
2008126190.tif 000009
【図８】
2008126190.tif 000010
【図９】
2008126190.tif 000011
【図１０】
2008126190.tif 000012
【図１１】
2008126190.tif 000013
【図１２】
2008126190.tif 000014
【図１３】
2008126190.tif 000015
【図１４】
2008126190.tif 000016
【図１５】
2008126190.tif 000017
【図１６】
2008126190.tif 000018
【図１７】
2008126190.tif 000019
【図１８】
2008126190.tif 000020
【図１９】
2008126190.tif 000021
【図２０】
2008126190.tif 000022
【図２１】
2008126190.tif 000023
【図２２】
2008126190.tif 000024
【図２３】
2008126190.tif 000025
【図２４】
2008126190.tif 000026
【手続補正書】
【提出日】平成21年4月7日(2009.4.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御をコンピュータに実行させるＷｅｂサービス制御プログラムであって、
Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理ステップと、
前記コンシューマからのＷｅｂサービスリクエストを受信した場合、受信したＷｅｂサービスリクエストの時間間隔と前記受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、
前記適合判定ステップにより前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送ステップと
をコンピュータに実行させるＷｅｂサービス制御プログラム。
【請求項２】
請求項１に記載のＷｅｂサービス制御プログラムにおいて、
前記管理ステップは、電子的交渉に基づいて前記Ｗｅｂサービス予約の要求を受信し、前記電子的交渉に基づいて該Ｗｅｂサービス予約の受諾または拒絶を示す応答を送信し、
前記受諾を示す応答は、該Ｗｅｂサービス予約の予約識別子を含むことを特徴とするＷｅｂサービス制御プログラム。
【請求項３】
請求項２に記載のＷｅｂサービス制御プログラムにおいて、
前記適合判定ステップは、前記受信したＷｅｂサービスリクエストに前記予約識別子が付加されており、且つ前記受信したＷｅｂサービスリクエストが該予約識別子に対応した前記Ｗｅｂサービス予約における前記Ｗｅｂサービスリクエストの条件を満たす場合、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合すると判定することを特徴とするＷｅｂサービス制御プログラム。
【請求項４】
Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御装置であって、
Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理部と、
前記コンシューマからのＷｅｂサービスリクエストを受信した場合、受信したＷｅｂサービスリクエストの時間間隔と前記受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定部と、
前記適合判定部により前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送部と
を備えるＷｅｂサービス制御装置。
【請求項５】
Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御方法であって、
Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行う管理ステップと、
前記コンシューマからのＷｅｂサービスリクエストを受信した場合、受信したＷｅｂサービスリクエストの時間間隔と前記受諾されたＷｅｂサービス予約におけるＷｅｂサービスリクエストの条件とに基づいて、前記受信したＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、
前記適合判定ステップにより前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送ステップと
を実行するＷｅｂサービス制御方法。
【請求項６】
Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の中継をコンピュータに実行させる中継プログラムであって、
Ｗｅｂサービスリクエストの条件として少なくとも時間間隔の下限値を有する前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求を送信し、該Ｗｅｂサービス予約が受諾された場合、該受諾を示す応答を受信する予約要求ステップと、
前記コンシューマからＷｅｂサービスリクエストが発行された場合、前記受諾されたＷｅｂサービス予約に設定された前記下限値に基づくタイミングで該Ｗｅｂサービスリクエストを前記プロバイダへ送信する送信ステップと
をコンピュータに実行させる中継プログラム。
【請求項７】
請求項６に記載の中継プログラムにおいて、
前記送信ステップは、複数のＷｅｂサービスリクエストが前記コンシューマから発行された場合、前記受諾されたＷｅｂサービス予約に示された前記下限値以上の時間間隔で前記複数のＷｅｂサービスリクエストのそれぞれを前記プロバイダへ送信することを特徴とする中継プログラム。
【請求項８】
請求項６に記載の中継プログラムにおいて、
前記送信ステップは、複数のＷｅｂサービスリクエストが前記コンシューマから発行された場合、発行されたＷｅｂサービスリクエストに対応する前記受諾されたＷｅｂサービス予約を識別し、前記発行されたＷｅｂサービスリクエストを前記プロバイダへ送信する時間間隔を前記Ｗｅｂサービス予約毎に管理し、前記Ｗｅｂサービス予約毎の該時間間隔が対応する前記下限値以上になるように制御することを特徴とする中継プログラム。
【国際調査報告】
2008126190.tif 000027
2008126190.tif 000028
2008126190.tif 000029
2008126190.tif 000030