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

Abstract

コンシューマからのＷｅｂサービスの予約であるＷｅｂサービス予約の要求とＷｅｂサービスを実行することができる少なくとも１つのサーバの状態とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行い、予約識別子をコンシューマへ送信する管理ステップと、第１通信プロトコルの情報と第２通信プロトコルの情報とを有するＷｅｂサービスリクエストを受信した場合、第２通信プロトコルの情報において予約識別子の検出を行い、該Ｗｅｂサービスリクエストが受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、Ｗｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストをサーバへ転送する転送ステップとをコンピュータに実行させる。

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

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

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

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

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

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

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

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

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

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

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

実施の形態４．
本実施の形態においては、コンシューマからプロバイダへのＷｅｂサービスリクエストにおける複数のプロトコルレイヤの情報に契約ＩＤを付加するＷｅｂサービスシステムについて説明する。

上述した各実施の形態において、ＷｅｂサービスがＳＯＡＰを用いる場合、ＣＣ１１がＷｅｂサービスリクエストのＳＯＡＰ ｅｎｖｅｌｏｐｅ内に契約ＩＤを付加し、ＣＫ２２は、ＳＯＡＰ ｅｎｖｅｌｏｐｅ内の契約ＩＤを検出する必要がある。この場合、ＣＫ２２は、ＳＯＡＰ ｅｎｖｅｌｏｐｅを記述するＸＭＬの構文解析を行う必要があり、この処理は、ＣＫ２２の負荷を増大させる。

本実施の形態に係るＷｅｂサービスシステムの構成は、実施の形態１と同様であるが、ＣＫ２２は、レイヤ７スイッチを用いて実現される。本実施の形態に係るＷｅｂサービスシステムの動作は、実施の形態１と同様であるが、処理Ｓ４１，Ｓ４２，Ｓ４３におけるＣＣ１１及びＣＫ２２の動作が異なる。

ここで、レイヤ７スイッチで構成された従来の負荷分散装置の例を用い、レイヤ７スイッチの動作について説明する。

図１６は、従来の負荷分散装置の動作の一例を示すブロック図である。負荷分散装置１１１は、クライアント１１２と複数のサーバ１１３ａ，１１３ｂ，１１３ｃとに接続され、クライアント１１２と複数のサーバ１１３ａ，１１３ｂ，１１３ｃとの間の中継を行う。クライアント１１２が、サーバへ最初のリクエストを送信すると、受信したサーバ１１３ａは、ｃｏｏｋｉｅを挿入したリプライをクライアント１１２へ送信する。このときのリプライは、例えば以下のようになる。

ＨＴＴＰ／１．１ ２００ ＯＫ
Ｓｅｔ−Ｃｏｏｋｉｅ：Ｃｕｓｔｏｍｅｒ＝“ＷＩＬＥ＿Ｅ＿ＣＯＹＯＴＥ”；

ｃｏｏｋｉｅを受信したクライアント１１２は、以後、継続する一連のｈｔｔｐリクエストにｃｏｏｋｉｅを挿入し、サーバへ送信する。このときのリクエストには、例えば以下のヘッダが付加される。

ＰＯＳＴ ／ａｃｍｅ／ｐｉｃｋｉｔｅｍ ＨＴＴＰ／１．１
Ｃｏｏｋｉｅ： Ｃｕｓｔｏｍｅｒ＝“ＷＩＬＥ＿Ｅ＿ＣＯＹＯＴＥ”；

負荷分散装置１１１は、リクエスト及びリプライからｃｏｏｋｉｅを抽出することにより、ｃｏｏｋｉｅを含むクライアント１１２からのリクエストを、そのｃｏｏｋｉｅを発行したサーバ１１３ａへ振り分ける。図１７は、従来の負荷分散装置により保持されるｃｏｏｋｉｅテーブルの一例を示す表である。負荷分散装置１１１は、このｃｏｏｋｉｅテーブルのように、発行されたｃｏｏｋｉｅ毎に、発行元のノードの識別子を保持する。負荷分散装置１１１は、ｃｏｏｋｉｅヘッダを持つリクエストが通過する度に、ｃｏｏｋｉｅテーブルを参照し、送るべきノードを決定する。

本実施の形態におけるＣＫ２２は、上述したｃｏｏｋｉｅテーブルの代わりに通過判定情報テーブルを用い、ｃｏｏｋｉｅの代わりに契約ＩＤを用いることにより、容易にレイヤ７スイッチを流用することができる。

処理Ｓ４１，Ｓ４２，Ｓ４３において、クライアント１２は、Ｗｅｂサービスのクライアントプログラムにより、ＣＣ１１及びＣＫ２２を介してノードへＷｅｂサービスリクエストを送信する。クライアント１２からのＷｅｂサービスリクエストを受信したＣＣ１１は、このＷｅｂサービスリクエストが付加条件を満たす場合、クライアント予約情報テーブルから対応する契約ＩＤを取得し、このＷｅｂサービスリクエストのＳＯＡＰ ｅｎｖｅｌｏｐｅ内に契約ＩＤを付加する。更に、ＣＣ１１は、このＷｅｂサービスリクエストのＳＯＡＰ ｅｎｖｅｌｏｐｅ外のＨＴＴＰヘッダにも契約ＩＤを付加する。

図１８は、本実施の形態に係るＷｅｂサービスリクエストの一例を示す図である。この図において、契約ＩＤは、ＳＯＡＰヘッダにおいて“ＳＯＡＰ−ｗｅｄｇｅ−ｃｏｎｔｒａｃｔ−ｉｄ”として挿入されていると共に、ＨＴＴＰヘッダにおいて“Ｘ−ｗｅｄｇｅ−ｃｏｎｔｒａｃｔ−ｉｄ”として挿入されている。

ＣＣ１１からのＷｅｂサービスリクエストを受信したＣＫ２２は、このＷｅｂサービスリクエストと通過判定情報テーブルを比較し、このＷｅｂサービスリクエストが通過条件を満たす場合、Ｗｅｂサービスリクエストをノードへ転送する（Ｓ４１，Ｓ４２）。また、ＣＫ２２は、受信したＷｅｂサービスリクエストが通過条件を満たさない場合、Ｗｅｂサービスリクエストをノードへ転送せず、拒絶の通知をクライアント１２へ送信する（Ｓ４３）。本実施の形態における通過条件は、受信したＷｅｂサービスリクエストのＨＴＴＰヘッダ及びＳＯＡＰ ｅｎｖｅｌｏｐｅの少なくともいずれかに契約ＩＤが存在し、且つその契約ＩＤを含む通過判定情報が通過判定情報テーブル中に存在し、且つその契約ＩＤを持つＷｅｂサービスリクエスト量が通過判定情報の必要能力以下であること、とする。

次に、処理Ｓ４１，Ｓ４２，Ｓ４３におけるＣＫ２２の動作について説明する。図１９は、本実施の形態に係るＣＫの動作の一例を示すフローチャートである。まず、ＣＫ２２は、受信したＷｅｂサービスリクエストのＨＴＴＰヘッダの解析を行い（Ｓ１１１）、そのＨＴＴＰヘッダに通過判定情報テーブル中の契約ＩＤが含まれているか否かの判定を行う（Ｓ１１２）。契約ＩＤが含まれている場合（Ｓ１１２，Ｙ）、処理Ｓ１１５へ移行する。契約ＩＤが含まれていない場合（Ｓ１１２，Ｎ）、ＣＫ２２は、受信したＷｅｂサービスリクエストのＳＯＡＰ ｅｎｖｅｌｏｐｅの解析を行い（Ｓ１１３）、そのＳＯＡＰ ｅｎｖｅｌｏｐｅに通過判定情報テーブル中の契約ＩＤが含まれているか否かの判定を行う（Ｓ１１４）。契約ＩＤが含まれている場合（Ｓ１１４，Ｙ）、処理Ｓ１１５へ移行する。

契約ＩＤが含まれていない場合（Ｓ１１４，Ｎ）、ＣＫ２２は、通過条件を満たさないと判定し（Ｓ１２１）、このフローは終了する。

処理Ｓ１１２またはＳ１１４において契約ＩＤが含まれている場合、ＣＫ２２は、その契約ＩＤを含む通過判定情報が通過判定情報テーブル中に存在するか否かの判断を行う（Ｓ１１５）。通過判定情報テーブル中に存在しない場合（Ｓ１１５，Ｎ）、処理Ｓ１２１へ移行する。通過判定情報テーブル中に存在する場合（Ｓ１１５，Ｙ）、ＣＫ２２は、その契約ＩＤを持つＷｅｂサービスリクエスト量が通過判定情報の必要能力以下であるか否かの判断を行う（Ｓ１１６）。必要能力以下でない場合（Ｓ１１６，Ｎ）、処理Ｓ１２１へ移行する。必要能力以下である場合（Ｓ１１６，Ｙ）、ＣＫ２２は、通過条件を満たすと判定し、このフローは終了する。

ここで、ＳＯＡＰ ｅｎｖｅｌｏｐｅを表すＸＭＬの構文に比べてＨＴＴＰの構文は単純であるため、ＳＯＡＰ ｅｎｖｅｌｏｐｅ中の契約ＩＤを検出する処理に比べて、ＨＴＴＰヘッダ中の契約ＩＤを検出する処理は負荷が低い。特に、レイヤ７スイッチは、ＨＴＴＰの処理を効率よく行うように設計されているため、ＣＫ２２の処理を高速化することができる。

なお、本実施の形態におけるＣＣ１１は、ＷｅｂサービスリクエストのＳＯＡＰ ｅｎｖｅｌｏｐｅとＨＴＴＰヘッダの両方に契約ＩＤを付加するとしたが、ＨＴＴＰヘッダに契約ＩＤを付加する機能を持たないＣＣが存在する場合でも、上述したＣＫ２２の動作によれば、少なくともＳＯＡＰ ｅｎｖｅｌｏｐｅに契約ＩＤが付加されているＷｅｂサービスリクエストは、ノードへ転送することができる。

また、本実施の形態においては、サービス呼び出しのためのプロトコルとしてＳＯＡＰを用い、ＳＯＡＰより下位の送受信のためのプロトコルとしてＨＴＴＰを用いたが、それぞれ他のプロトコルを用いても良い。ＳＯＡＰの代わりのプロトコルとしては、ＣＯＲＢＡ（Common Object Request Broker Architecture） ｏｖｅｒ ｈｔｔｐ、ＲＥＳＴ等がある。更に、上述したそれぞれの実施の形態を組み合わせても良い。

本実施の形態によれば、ＣＣ１１がＷｅｂサービスリクエストのＨＴＴＰヘッダにも契約ＩＤを負荷し、ＣＫ２２がＷｅｂサービスリクエストのＨＴＴＰヘッダにおける契約ＩＤを検出することにより、ＣＫ２２の処理を軽減し、高速化することができる。また、既存のレイヤ７スイッチを流用してＣＫ２２を構成することにより、ＣＫ２２のコストを抑えることができる。

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

更に、Ｗｅｂサービスシステムを構成するコンピュータにおいて上述した各ステップを実行させるプログラムを、Ｗｅｂサービス制御プログラムとして提供することができる。上述したプログラムは、コンピュータにより読取り可能な記録媒体に記憶させることによって、Ｗｅｂサービスシステムを構成するコンピュータに実行させることが可能となる。更に、ＣＣを構成するコンピュータにおいて上述した各ステップを実行させるプログラムを、中継プログラムとして提供することができる。上述したプログラムは、コンピュータにより読取り可能な記録媒体に記憶させることによって、ＣＣを構成するコンピュータに実行させることが可能となる。

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

なお、管理ステップは、実施の形態における処理Ｓ２２，Ｓ２４，Ｓ２６に対応する。また、適合判定ステップ及び転送ステップは、実施の形態における処理Ｓ４１〜Ｓ４３のうちＣＫ２２による処理に対応する。

また、予約要求ステップは、実施の形態における処理Ｓ２１，Ｓ２３，Ｓ２５に対応する。また、送信ステップは、実施の形態における処理Ｓ４１〜Ｓ４３のうちＣＣ１１による処理に対応する。

また、管理部は、実施の形態におけるＣＭ２１に対応する。また、適合判定部及び転送部は、実施の形態におけるＣＫ２２に対応する。

本発明によれば、予約に基づいて受け入れるＷｅｂサービスリクエスト量を制御することができる。

Claims (20)

1. Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御をコンピュータに実行させるＷｅｂサービス制御プログラムであって、
   前記コンシューマからの前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記Ｗｅｂサービス予約の要求と前記サーバの状態とに基づいて該Ｗｅｂサービス予約を受諾するか否かの判定を行い、該Ｗｅｂサービス予約を受諾した場合、該Ｗｅｂサービス予約の識別子である予約識別子を前記コンシューマへ送信する管理ステップと、
   第１通信プロトコルの情報と該第１通信プロトコルより下位レイヤのプロトコルである第２通信プロトコルの情報とを有するＷｅｂサービスリクエストを前記コンシューマから受信した場合、受信したＷｅｂサービスリクエスト中の前記第２通信プロトコルの情報において前記予約識別子の検出を行い、少なくとも該検出の結果に基づいて該Ｗｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、
   前記適合判定ステップにより前記受諾されたＷｅｂサービス予約に適合すると判定されたＷｅｂサービスリクエストを前記サーバへ転送する転送ステップと
   をコンピュータに実行させるＷｅｂサービス制御プログラム。
2. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
   前記適合判定ステップは、前記受信したＷｅｂサービスリクエスト中の前記第２通信プロトコルの情報に前記予約識別子が存在しない場合、該Ｗｅｂサービスリクエスト中の前記第１通信プロトコルの情報において前記予約識別子の検出を行い、該検出の結果に基づいて該Ｗｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行うＷｅｂサービス制御プログラム。
3. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
   前記管理ステップは、電子的交渉に基づいて前記Ｗｅｂサービス予約の要求を受信し、該Ｗｅｂサービス予約の受諾または拒絶を示す応答を送信し、
   前記受諾を示す応答は、該Ｗｅｂサービス予約の予約識別子を含むことを特徴とするＷｅｂサービス制御プログラム。
4. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
   前記サーバの状態は、該サーバの処理能力を含み、
   前記管理ステップは、前記処理能力が前記Ｗｅｂサービス予約を実行可能であると判定した場合、該Ｗｅｂサービス予約を受諾することを特徴とするＷｅｂサービス制御プログラム。
5. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
   前記Ｗｅｂサービス予約は、前記コンシューマから前記プロバイダへ送信されるＷｅｂサービスリクエストの期間及び処理量の少なくともいずれかの条件であるＷｅｂサービスリクエスト条件を有することを特徴とするＷｅｂサービス制御プログラム。
6. 請求項５に記載のＷｅｂサービス制御プログラムにおいて、
   前記適合判定ステップは、前記受信したＷｅｂサービスリクエスト中の前記第１通信プロトコルの情報及び該Ｗｅｂサービスリクエスト中の前記第２通信プロトコルの情報の少なくともいずれかに前記予約識別子が存在し、且つ前記受信したＷｅｂサービスリクエストが該予約識別子に対応した前記Ｗｅｂサービス予約における前記Ｗｅｂサービスリクエスト条件を満たす場合、該Ｗｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合すると判定することを特徴とするＷｅｂサービス制御プログラム。
7. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
   前記第２通信プロトコルは、ＨＴＴＰであり、
   前記第２通信プロトコルの情報は、ＨＴＴＰヘッダであることを特徴とするＷｅｂサービス制御プログラム。
8. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
   前記サーバの状態は、該サーバの処理能力を含み、
   前記Ｗｅｂサービス予約の要求は、前記コンシューマから前記プロバイダへ送信されるＷｅｂサービスリクエストの期間及び処理量の条件を含み、
   前記管理ステップは、前記Ｗｅｂサービス予約の要求に示された期間において予約されていない前記サーバの処理能力が該Ｗｅｂサービス予約の要求に示された処理量以上である場合、該Ｗｅｂサービス予約を受諾すると判定することを特徴とするＷｅｂサービス制御プログラム。
9. 請求項５に記載のＷｅｂサービス制御プログラムにおいて、
   前記処理量は、単位時間当たりのＷｅｂサービスリクエスト数であることを特徴とするＷｅｂサービス制御プログラム。
10. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
    前記適合判定ステップは、前記受信したＷｅｂサービスリクエスト中の前記第１通信プロトコルの情報及び該Ｗｅｂサービスリクエスト中の前記第２通信プロトコルの情報の少なくともいずれかに前記予約識別子が存在する場合、該Ｗｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合すると判定することを特徴とするＷｅｂサービス制御プログラム。
11. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
    前記転送ステップは、前記適合判定ステップにより受信されたＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合しないと判定された場合、該Ｗｅｂサービスリクエストの拒絶を行うことを特徴とするＷｅｂサービス制御プログラム。
12. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
    前記適合判定ステップ及び前記転送ステップは、レイヤ７スイッチにより実現されることを特徴とするＷｅｂサービス制御プログラム。
13. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
    前記第１通信プロトコルは、ＳＯＡＰ、ＲＥＳＴ、ＣＯＲＢＡのいずれかであることを特徴とするＷｅｂサービス制御プログラム。
14. 請求項１に記載のＷｅｂサービス制御プログラムにおいて、
    前記第１通信プロトコルの情報は、Ｗｅｂサービスの呼び出しのメッセージであることを特徴とするＷｅｂサービス制御プログラム。
15. Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御装置であって、
    前記コンシューマからの前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記Ｗｅｂサービス予約の要求と前記サーバの状態とに基づいて該Ｗｅｂサービス予約の受諾の判定を行う管理部と、
    前記管理部により前記Ｗｅｂサービス予約が受諾された場合、該Ｗｅｂサービス予約の識別子である予約識別子を含む通知を前記コンシューマへ送信する予約通知部と、
    第１通信プロトコルの情報と該第１通信プロトコルより下位レイヤのプロトコルである第２通信プロトコルの情報とを有するＷｅｂサービスリクエストを前記コンシューマから受信した場合、該Ｗｅｂサービスリクエスト中の前記第２通信プロトコルの情報において前記予約識別子の検出を行い、少なくとも該検出の結果に基づいて該Ｗｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定部と、
    前記適合判定部により受信されたＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合すると判定された場合、該Ｗｅｂサービスリクエストを前記サーバへ転送する転送部と
    を備えるＷｅｂサービス制御装置。
16. Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の制御を行うＷｅｂサービス制御方法であって、
    前記コンシューマからの前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求と前記Ｗｅｂサービスを実行することができる少なくとも１つのサーバの状態とを取得し、前記Ｗｅｂサービス予約の要求と前記サーバの状態とに基づいて該Ｗｅｂサービス予約の受諾の判定を行う管理ステップと、
    前記管理ステップにより前記Ｗｅｂサービス予約が受諾された場合、該Ｗｅｂサービス予約の識別子である予約識別子を含む通知を前記コンシューマへ送信する通知ステップと、
    第１通信プロトコルの情報と該第１通信プロトコルより下位レイヤのプロトコルである第２通信プロトコルの情報とを有するＷｅｂサービスリクエストを前記コンシューマから受信した場合、該Ｗｅｂサービスリクエスト中の前記第２通信プロトコルの情報において前記予約識別子の検出を行い、少なくとも該検出の結果に基づいて該Ｗｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合するか否かの判定を行う適合判定ステップと、
    前記適合判定ステップにより受信されたＷｅｂサービスリクエストが前記受諾されたＷｅｂサービス予約に適合すると判定された場合、該Ｗｅｂサービスリクエストを前記サーバへ転送する転送ステップと
    を実行するＷｅｂサービス制御方法。
17. Ｗｅｂサービスにおけるコンシューマとプロバイダの間の通信の中継を行う中継プログラムであって、
    前記Ｗｅｂサービスの予約であるＷｅｂサービス予約の要求を送信し、該Ｗｅｂサービス予約が受諾された場合、該Ｗｅｂサービス予約の識別子である予約識別子を取得する予約要求ステップと、
    前記コンシューマから複数レイヤのプロトコルの情報を有するＷｅｂサービスリクエストが発行された場合、前記受諾されたＷｅｂサービス予約に対応する予約識別子を該Ｗｅｂサービスリクエストにおける前記複数レイヤのプロトコルの情報それぞれに付加し、該Ｗｅｂサービスリクエストを前記プロバイダへ送信する送信ステップと
    をコンピュータに実行させる中継プログラム。
18. 請求項１７に記載の中継プログラムにおいて、
    前記複数レイヤのプロトコルの情報は、第１通信プロトコルの情報と該第１通信プロトコルより下位のプロトコルである第２通信プロトコルの情報とであることを特徴とする中継プログラム。
19. 請求項１７に記載の中継プログラムにおいて、
    前記予約要求ステップは、電子的交渉に基づいて前記Ｗｅｂサービス予約の要求を送信し、該Ｗｅｂサービス予約の受諾または拒絶を示す応答を受信し、
    前記受諾を示す応答は、該Ｗｅｂサービス予約の予約識別子を含むことを特徴とする中継プログラム。
20. 請求項１７に記載の中継プログラムにおいて、
    前記第２通信プロトコルは、ＨＴＴＰであり、
    前記第２通信プロトコルの情報は、ＨＴＴＰヘッダであり、
    前記第１通信プロトコルは、ＳＯＡＰ、ＲＥＳＴ、ＣＯＲＢＡのいずれかであることを特徴とする中継プログラム。

Images