JP4396948B2 - Ｗｅｂサービス制御プログラム、Ｗｅｂサービス制御装置、Ｗｅｂサービス制御方法 - Google Patents

Description

本発明は、Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御プログラム、Ｗｅｂサービス制御装置、Ｗｅｂサービス制御方法に関するものである。

近年、サービスを疎に接続してシステムを作るＳＯＡ（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）［ｓｅｃ］とした座標に、Ｗｅｂサービスリクエスト量と処理遅延との相関を曲線として表したグラフである。また、このサービスプロファイルは、Ｗｅｂサービスシステムの運用開始前の性能試験により計測される。このサービスプロファイルによれば、Ｗｅｂサービスリクエスト量が運用限界値を超えると急激に処理遅延が増加する。更に、性能試験時と実際の運用時の誤差の許容量である誤差許容量が定められ、Ｗｅｂサービスリクエスト量が運用限界値を超えることのないよう、（運用限界値−誤差許容量）である安定運用限界値が定められる。

サーバ予約処理において、ＣＭ２１は、サーバ情報テーブルに基づいて、サーバ２３毎のＷｅｂサービスリクエスト量が安定運用限界値以下（安定運用域）になるようにサーバ２３を予約する。例えば、全てのサーバ２３の安定運用限界値が等しいとすると、予約する必要能力の合計を安定運用限界値で除した値以上の最小整数のサーバ２３を予約する。例えば、第１の予約により第１のサーバ２３が予約され、第２の予約の予約期間における必要能力が第１のサーバの安定運用限界値を超える場合、追加の第２のサーバ２３が予約される。その結果、グリッド運用サーバ２５は、第１の予約の開始時刻で第１のサーバ２３を割り当て（Ｓ５２）、第２の予約の開始時刻で第２のサーバ２３を割り当てる（Ｓ６２）。

また、処理Ｓ５３，Ｓ６１，Ｓ６３，Ｓ６４は、それぞれ実施の形態１における処理Ｓ３３，Ｓ４１，Ｓ４２，Ｓ４３と同様である。

本実施の形態によれば、グリッド運用サーバ２５が予約された必要能力に応じて自動的にノードを割り当てることにより、オペレータの負担を軽減すると共に、設備準備量の誤りをなくし、Ｗｅｂサービスシステムの安定性を向上させることができる。また、グリッド運用サーバ２５が必要なタイミングで必要なノードを割り当てることにより、サーバ２３の利用率を向上させることができる。

なお、複数のサーバ２３は、データセンタ以外の場所に配置されても良いし、複数の場所に分散して配置されても良い。

実施の形態３．
本実施の形態においては、サーバ群がグリッドシステムであり、サーバ毎の安定運用限界値を調整するＷｅｂサービスシステムについて説明する。

本実施の形態に係るＷｅｂサービスシステムの構成は、実施の形態２と同様である。

本実施の形態に係るＷｅｂサービスシステムの動作について説明する。

図１５は、本実施の形態に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。この図において、図１３と同一符号は図１３に示された対象と同一又は相当物を示しており、ここでの説明を省略する。この図は、図１３と比較すると、新たに、処理Ｓ６５〜Ｓ６７を行う。

上述したように安定運用限界値の初期値は、運用前の試験の結果に対して余裕を持って低めに設定されている。処理Ｓ１１〜Ｓ６４は、実施の形態２と同様に行われる。次に、グリッド運用サーバ２５は、稼働中のノードから負荷指標を取得し（Ｓ６５，Ｓ６６）、ＣＭ２１へ渡す（Ｓ６７）。負荷指標（負荷情報）とは、ＣＰＵ使用率、ネットワーク使用量、メモリ使用量などである。次に、ＣＭ２１は、プロバイダ予約情報テーブル、実績情報テーブル、負荷指標等の処理能力の実測値に基づいて誤差許容量及び安定運用限界値を再設定する。ここで、ＣＭ２１は、処理能力の実測値と現在の安定運用限界値を比較し、処理能力の実測値に対して安定運用限界値が高すぎる場合、例えば、実際のＷｅｂサービスリクエスト量に対する実際の処理遅延がサービスプロファイルから得られる処理遅延より小さい場合、安定運用限界値を増加させる。また、ＣＭ２１は、実際の処理能力に対して安定運用限界値が低すぎる場合、例えば、実際のＷｅｂサービスリクエスト量に対する実際の処理遅延がサービスプロファイルから得られる処理遅延より大きい場合、安定運用限界値を増加させる。また、ＣＭ２１は、安定運用限界値の再設定を行った場合、再びサーバ予約処理を行う。

従来のＷｅｂサービスシステムにおいて、運用開始前の未定な要因により誤差許容量は余裕を持って大きい値に設定する必要があった。本実施の形態によれば、運用開始前に誤差許容量が大き過ぎる値に設定された場合でも、運用中に誤差許容値を見直し、誤差許容量を適切な値に減少させることができる。従って、安定運用限界値が大きくなり、準備する設備量を少なくし、運用コストを削減することができる。逆に、運用中の負荷指標が悪化した場合、誤差許容量を大きくし、安定運用限界値が小さくすることにより、以後に予約されるＷｅｂサービスリクエスト量を抑え、Ｗｅｂサービスシステムの安定性を優先させることができる。

また、上述した実施の形態に係るＣＣ１１，ＣＭ２１，ＣＫ２２は、情報通信装置に容易に適用することができ、情報通信装置の性能をより高めることができる。ここで、情報通信装置には、例えばサーバ、ルータ、スイッチ等が含まれ得る。

更に、Ｗｅｂサービスシステムを構成するコンピュータにおいて上述した各ステップを実行させるプログラムを、Ｗｅｂサービス制御プログラムとして提供することができる。上述したプログラムは、コンピュータにより読取り可能な記録媒体に記憶させることによって、Ｗｅｂサービスシステムを構成するコンピュータに実行させることが可能となる。ここで、上記コンピュータにより読取り可能な記録媒体としては、ＲＯＭやＲＡＭ等のコンピュータに内部実装される内部記憶装置、ＣＤ−ＲＯＭやフレキシブルディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカード等の可搬型記憶媒体や、コンピュータプログラムを保持するデータベース、或いは、他のコンピュータ並びにそのデータベースや、更に回線上の伝送媒体をも含むものである。

なお、管理部は、実施の形態におけるＣＭ２１に対応する。また、転送部は、実施の形態におけるＣＫ２２に対応する。また、要求部及び加工部は、実施の形態におけるＣＣ１１に対応する。また、管理ステップは、実施の形態における処理Ｓ２１〜Ｓ２６に対応する。また、転送ステップは、実施の形態における処理Ｓ４１〜Ｓ４３のうちＣＫ２２による処理に対応する。また、加工ステップは、実施の形態における処理Ｓ４１〜Ｓ４３のうちＣＣ１１による処理に対応する。

また、サーバ制御部は、実施の形態におけるグリッド運用サーバ２５に対応する。また、サーバ制御ステップは、実施の形態における処理Ｓ５２，Ｓ６２に対応する。

（付記１） Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御をコンピュータに実行させるＷｅｂサービス制御プログラムであって、
前記Ｗｅｂサービスを実行することができる複数のサーバについてＷｅｂサービスの処理量の上限を設定し、前記サーバの状態と前記Ｗｅｂサービスの予約の要求とを取得し、前記サーバのＷｅｂサービスリクエスト処理量の上限と前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約の受諾または拒絶を行う管理ステップと、
前記管理ステップにより受諾されたＷｅｂサービス予約に基づいて、前記複数のサーバの中の幾つかを前記Ｗｅｂサービスを実行するノードとして設定するサーバ制御ステップと、
Ｗｅｂサービスリクエストを受信し、前記管理ステップにより受諾された予約に適合するＷｅｂサービスリクエストを前記サーバ制御ステップにより設定されたノードへ転送する転送ステップと、
をコンピュータに実行させるＷｅｂサービス制御プログラム。
（付記２） 付記１に記載のＷｅｂサービス制御プログラムにおいて、
前記管理ステップは、電子的交渉に基づいて前記Ｗｅｂサービス予約の要求を受信すると共に、電子的交渉に基づいて該Ｗｅｂサービス予約の受諾または拒絶を示す応答を送信することを特徴とするＷｅｂサービス制御プログラム。
（付記３） 付記２に記載のＷｅｂサービス制御プログラムにおいて、
前記管理ステップは、受諾した前記Ｗｅｂサービス予約に対して予約識別子を設定し、該Ｗｅｂサービス予約の受諾を示す応答に該予約識別子を含めることを特徴とするＷｅｂサービス制御プログラム。
（付記４） 付記３に記載のＷｅｂサービス制御プログラムにおいて、
前記転送ステップは、受信したＷｅｂサービスリクエストが前記予約識別子を有する場合、該予約識別子に対応するＷｅｂサービス予約に適合すると判断することを特徴とするＷｅｂサービス制御プログラム。
（付記５） 付記１乃至付記４のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
前記Ｗｅｂサービス予約は、前記コンシューマから前記プロバイダへ送信される予定のＷｅｂサービスリクエストの期間の条件及びＷｅｂサービスの処理量の条件を含むことを特徴とするＷｅｂサービス制御プログラム。
（付記６） 付記５に記載のＷｅｂサービス制御プログラムにおいて、
前記転送ステップは、受信したＷｅｂサービスリクエストが前記予約識別子を有し、且つ、受信したＷｅｂサービスリクエストがＷｅｂサービス予約における期間の条件及び処理量の条件を満たす場合、該Ｗｅｂサービス予約に適合すると判断することを特徴とするＷｅｂサービス制御プログラム。
（付記７） 付記１乃至付記６のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
更に、前記コンシューマにおける端末により発行されたＷｅｂサービスリクエストを受信し、前記管理ステップにより受諾されたＷｅｂサービス予約に基づいて該Ｗｅｂサービスリクエストの加工を行い、該加工されたＷｅｂサービスリクエストを前記転送ステップへ送信する加工ステップを備えることを特徴とするＷｅｂサービス制御プログラム。
（付記８） 付記７に記載のＷｅｂサービス制御プログラムにおいて、
前記加工ステップは、受信したＷｅｂサービスリクエストが前記管理ステップにより受諾されたＷｅｂサービス予約の内容に適合する場合、該Ｗｅｂサービス予約の予約識別子を前記受信したＷｅｂサービスリクエストに付加することを特徴とするＷｅｂサービス制御プログラム。
（付記９） 付記１乃至付記８のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
前記サーバの状態は、該サーバの処理能力を含み、
前記管理ステップは、前記処理能力が前記Ｗｅｂサービス予約を実行可能であると判断した場合、該Ｗｅｂサービス予約を受諾することを特徴とするＷｅｂサービス制御プログラム。
（付記１０） 付記１乃至付記９のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
前記管理ステップは、前記Ｗｅｂサービスを実行したサーバの負荷情報を取得し、該負荷情報に基づいて前記サーバの処理量の上限を決定することを特徴とするＷｅｂサービス制御プログラム。
（付記１１） 付記１乃至付記９のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
前記管理ステップは、前記Ｗｅｂサービスを実行したサーバの処理量と処理遅延の関係を負荷情報として取得することを特徴とするＷｅｂサービス制御プログラム。
（付記１２） 付記５乃至付記９のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
前記管理ステップは、前記Ｗｅｂサービス予約を受諾する場合、前記ノードとなるサーバの予約を行い、
前記サーバ制御ステップは、前記Ｗｅｂサービス予約における期間までに、前記管理ステップにより予約されたサーバを前記ノードとして設定することを特徴とするＷｅｂサービス制御プログラム。
（付記１３） 付記５乃至付記１０のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
前記管理ステップは、前記サーバの予約を行う際、前記Ｗｅｂサービス予約における処理量の上限が該サーバの処理量の上限を超える場合、更に該サーバと異なるサーバの予約を行うことを特徴とするＷｅｂサービス制御プログラム。
（付記１４） 付記５乃至付記１０のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
前記管理ステップは、前記サーバの予約を行う際、前記Ｗｅｂサービス予約における処理量の上限を該サーバの処理量の上限で除した値以上の最小整数のサーバの予約を行うことを特徴とするＷｅｂサービス制御プログラム。
（付記１５） 付記５に記載のＷｅｂサービス制御プログラムにおいて、
前記処理量は、単位時間当たりのＷｅｂサービスリクエスト数であることを特徴とするＷｅｂサービス制御プログラム。
（付記１６） 付記１乃至付記１４のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
前記Ｗｅｂサービスは、ＳＯＡＰ、ＲＥＳＴ、ＨＴＴＰの少なくともいずれかを用いるサービスであることを特徴とするＷｅｂサービス制御プログラム。
（付記１７） Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御装置であって、
前記Ｗｅｂサービスを実行することができる複数のサーバについてＷｅｂサービスの処理量の上限を設定し、前記サーバの状態と前記Ｗｅｂサービスの予約の要求とを取得し、前記サーバのＷｅｂサービスリクエスト処理量の上限と前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約の受諾または拒絶を行う管理部と、
前記管理部により受諾されたＷｅｂサービス予約に基づいて、前記複数のサーバの中の幾つかを前記Ｗｅｂサービスを実行するノードとして設定するサーバ制御部と、
Ｗｅｂサービスリクエストを受信し、前記管理部により受諾された予約に適合するＷｅｂサービスリクエストを前記サーバ制御部により設定されたノードへ転送する転送部と、
を備えるＷｅｂサービス制御装置。
（付記１８） 付記１６に記載のＷｅｂサービス制御装置において、
前記管理部は、電子的交渉に基づいて前記Ｗｅｂサービス予約の要求を受信すると共に、電子的交渉に基づいて該Ｗｅｂサービス予約の受諾または拒絶を示す応答を送信することを特徴とするＷｅｂサービス制御装置。
（付記１９） Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御方法であって、
前記Ｗｅｂサービスを実行することができる複数のサーバについてＷｅｂサービスの処理量の上限を設定し、前記サーバの状態と前記Ｗｅｂサービスの予約の要求とを取得し、前記サーバのＷｅｂサービスリクエスト処理量の上限と前記サーバの状態と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約の受諾または拒絶を行う管理ステップと、
前記管理ステップにより受諾されたＷｅｂサービス予約に基づいて、前記複数のサーバの中の幾つかを前記Ｗｅｂサービスを実行するノードとして設定するサーバ制御ステップと、
Ｗｅｂサービスリクエストを受信し、前記管理ステップにより受諾された予約に適合するＷｅｂサービスリクエストを前記サーバ制御ステップにより設定されたノードへ転送する転送ステップと、
を実行するＷｅｂサービス制御方法。
（付記２０） 付記１９に記載のＷｅｂサービス制御方法において、
更に、管理ステップの後、前記コンシューマにおける端末により発行されたＷｅｂサービスリクエストを受信し、前記管理ステップにより受諾されたＷｅｂサービス予約に基づいて該Ｗｅｂサービスリクエストの加工を行い、該加工されたＷｅｂサービスリクエストを前記転送ステップへ送信する加工ステップを実行することを特徴とするＷｅｂサービス制御方法。

実施の形態１に係るＷｅｂサービスシステムの構成の一例を示すブロック図である。 実施の形態１に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。 実施の形態１に係る価格表の内容の一例を示す表である。 実施の形態１に係る利用計画表の内容の第１の例を示す表である。 実施の形態１に係る利用計画表の内容の第２の例を示す表である。 実施の形態１に係る予約リクエストの内容の一例を示す図である。 実施の形態１に係る予約リプライの内容の一例を示す図である。 実施の形態１に係るプロバイダ予約情報テーブルの内容の一例を示す表である。 実施の形態１に係るサーバ情報テーブルの内容の一例を示す表である。 実施の形態１に係るコンシューマ予約情報テーブルの内容の一例を示す表である。 実施の形態１に係る通過判定情報テーブルの内容の一例を示す表である。 実施の形態２に係るＷｅｂサービスシステムの構成の一例を示すブロック図である。 実施の形態２に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。 実施の形態２に係るサービスプロファイルの一例を示すグラフである。 実施の形態３に係るＷｅｂサービスシステムの動作の一例を示すシーケンス図である。

符号の説明

１ ネットワーク、１１ ＣＣ、１２ クライアント、１３ 計画端末、１４ 各部署端末、２１ ＣＭ、２２ ＣＫ、２３ サーバ、２４ オペレータ端末、２５ グリッド運用サーバ、３１ プロバイダ端末。

Claims (8)

1. Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御をコンピュータに実行させるＷｅｂサービス制御プログラムであって、
   前記Ｗｅｂサービスの期間前に、前記Ｗｅｂサービスを実行することができる複数のサーバについてＷｅｂサービスの処理量の上限を設定すると共に、前記Ｗｅｂサービス期間中の前記複数のサーバの処理能力と前記Ｗｅｂサービスの予約の要求とを取得し、前記複数のサーバのＷｅｂサービスの処理量の上限と前記複数のサーバの処理能力と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約の受諾または拒絶を行う管理ステップと、
   前記管理ステップにより受諾されたＷｅｂサービス予約と、前記複数のサーバの処理能力とに基づいて、前記複数のサーバの中の少なくとも１つを、前記Ｗｅｂサービスを実行するノードとして設定するサーバ制御ステップと、
   Ｗｅｂサービスリクエストを受信し、前記管理ステップにより受諾された予約に適合するＷｅｂサービスリクエストを前記サーバ制御ステップにより設定されたノードへ転送する転送ステップと、
   をコンピュータに実行させるＷｅｂサービス制御プログラム。
2. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
   前記管理ステップは、電子的交渉に基づいて前記Ｗｅｂサービス予約の要求を受信すると共に、電子的交渉に基づいて該Ｗｅｂサービス予約の受諾または拒絶を示す応答を送信することを特徴とするＷｅｂサービス制御プログラム。
3. 請求項２に記載のＷｅｂサービス制御プログラムにおいて、
   前記管理ステップは、受諾した前記Ｗｅｂサービス予約に対して予約識別子を設定し、該Ｗｅｂサービス予約の受諾を示す応答に該予約識別子を含めることを特徴とするＷｅｂサービス制御プログラム。
4. 請求項３に記載のＷｅｂサービス制御プログラムにおいて、
   前記転送ステップは、受信したＷｅｂサービスリクエストが前記予約識別子を有する場合、該予約識別子に対応するＷｅｂサービス予約に適合すると判断することを特徴とするＷｅｂサービス制御プログラム。
5. 請求項１乃至請求項４のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
   前記Ｗｅｂサービス予約は、前記コンシューマから前記プロバイダへ送信される予定のＷｅｂサービスリクエストの期間の条件及びＷｅｂサービスの処理量の条件を含むことを特徴とするＷｅｂサービス制御プログラム。
6. 請求項１乃至請求項５のいずれかに記載のＷｅｂサービス制御プログラムにおいて、
   前記管理ステップは、前記Ｗｅｂサービスを実行したサーバの負荷情報を取得し、該負荷情報に基づいて前記サーバの処理量の上限を決定することを特徴とするＷｅｂサービス制御プログラム。
7. Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御装置であって、
   前記Ｗｅｂサービスの期間前に、前記Ｗｅｂサービスを実行することができる複数のサーバについてＷｅｂサービスの処理量の上限を設定すると共に、前記Ｗｅｂサービス期間中の前記複数のサーバの処理能力と前記Ｗｅｂサービスの予約の要求とを取得し、前記複数のサーバのＷｅｂサービスの処理量の上限と前記複数のサーバの処理能力と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約の受諾または拒絶を行う管理部と、
   前記管理部により受諾されたＷｅｂサービス予約と、前記複数のサーバの処理能力とに基づいて、前記複数のサーバの中の少なくとも１つを、前記Ｗｅｂサービスを実行するノードとして設定するサーバ制御部と、
   Ｗｅｂサービスリクエストを受信し、前記管理部により受諾された予約に適合するＷｅｂサービスリクエストを前記サーバ制御部により設定されたノードへ転送する転送部と、
   を備えるＷｅｂサービス制御装置。
8. Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御方法であって、
   前記Ｗｅｂサービスの期間前に、前記Ｗｅｂサービスを実行することができる複数のサーバについてＷｅｂサービスの処理量の上限を設定すると共に、前記Ｗｅｂサービス期間中の前記複数のサーバの処理能力と前記Ｗｅｂサービスの予約の要求とを取得し、前記複数のサーバのＷｅｂサービスの処理量の上限と前記複数のサーバの処理能力と前記Ｗｅｂサービス予約の要求とに基づいて該Ｗｅｂサービス予約の受諾または拒絶を行う管理ステップと、
   前記管理ステップにより受諾されたＷｅｂサービス予約と、前記複数のサーバの処理能力とに基づいて、前記複数のサーバの中の少なくとも１つを、前記Ｗｅｂサービスを実行するノードとして設定するサーバ制御ステップと、
   Ｗｅｂサービスリクエストを受信し、前記管理ステップにより受諾された予約に適合するＷｅｂサービスリクエストを前記サーバ制御ステップにより設定されたノードへ転送する転送ステップと、
   を実行するＷｅｂサービス制御方法。

Images