JP2006072785A - サービス利用のためのリクエストメッセージ制御方法、および、サービス提供システム - Google Patents

Abstract

【課題】Ｗｅｂサービスプロバイダを介して、Ｗｅｂサービスを提供するサービス提供システムにおいて、プロバイダの状態変化、構成変化等の発生に起因する呼出し先Ｗｅｂサービスプロバイダのパフォーマンス変化に即応し、システム全体の性能、信頼性を向上させる。
【解決手段】ＷｅｂサービスリクエスタとＷｅｂサービスプロバイダとの間で送受信されるメッセージを中継するＷｅｂサービスブローカと、Ｗｅｂサービスプロバイダが多段に連続してツリー構造を形成して接続している場合において、リクエストメッセージ送信先Ｗｅｂサービスプロバイダを決定する際に利用する情報として、Ｗｅｂサービブローカが直接呼出すＷｅｂサービスプロバイダだけではなく、ツリー構造の子孫方向に存在するＷｅｂサービスプロバイダの性能、状態、構成を利用する。
【選択図】 図１

Description

本発明は、サービス利用のためのリクエストメッセージ制御方法に係り、サービスリクエスタがサービスプロバイダからサービスの提供を受けるために、リクエストメッセージを中継するサービスブローカを介するサービス提供システムにおいて、最適なリクエストメッセージの経路を探索するために用いて好適なリクエストメッセージ制御方法に関する。

近年、インターネットの普及を背景として、ＸＭＬをベースとしたＷｅｂサービスが注目されてきている。

ＸＭＬをベースとしたＷｅｂサービスでは、ＳＯＡＰ(Simple Object Access Protocol)、ＷＳＤＬ（Web Services Description Language）、ＵＤＤＩ(Universal Description、Discovery and Integration)を中心技術とおり、標準的なＷｅｂサービスのモデルでは、Ｗｅｂサービスを提供するＷｅｂサービスプロバイダと、Ｗｅｂサービスを利用するＷｅｂサービスリクエスタとの間の仲立ちとし、Ｗｅｂサービスブローカが、送受信されるメッセージを中継し、様々な機能を提供する。

このＷｅｂサービスブローカは、メッセージの変換、署名・暗号化、認証・アクセス制御、ルーティング等の機能を提供する。

Ｗｅｂサービスブローカのメッセージルーティング機能は、中継するリクエストメッセージの内容、送信先Ｗｅｂサービスのパフォーマンス等の情報を用いてリクエストメッセージ送信先を決定する。

例えば、以下の特許文献１のＷｅｂサービスの動的呼出し方法では、呼出し先Ｗｅｂサービスの可用性、ＱｏＳ（Quality of Service）等の情報に基づいた呼出し先Ｗｅｂサービス選択ルールを用いることが示されている。

米国特許出願公開２００３／０２０４６２２号明細書

従来のＷｅｂサービスにおいては、リクエストメッセージ送信先決定に用いるＱｏＳ情報（パフォーマンス情報）には、一定期間測定した平均レスポンス時間等の統計情報が利用される。

呼出し先Ｗｅｂサービスプロバイダが、さらに別のＷｅｂサービスプロバイダ（サブＷｅｂサービスプロバイダ）を呼出して自身のサービスを提供している場合には、呼出し先Ｗｅｂサービスプロバイダのパフォーマンスは、そのサブＷｅｂサービスプロバイダのパフォーマンス、状態、構成等に依存する。

例えば、呼出し先Ｗｅｂサービスプロバイダが、二つの同程度の性能を発揮するサブＷｅｂサービスプロバイダに対してリクエストメッセージを振分けて呼び出すことにより、自分のサービスを提供するために他のＷｅｂサービスを利用している状況を想定する。

何らかの理由により一方のサブＷｅｂサービスプロバイダが利用不可状態になった場合、呼出し先Ｗｅｂサービスプロバイダのパフォーマンス情報はそれまでのパフォーマンスよりも劣化する可能性が考えられるが、統計的なパフォーマンス情報に基づいた呼出し先Ｗｅｂサービス決定方式では、期待するパフォーマンスが得られない可能性のあるＷｅｂサービスプロバイダにリクエストメッセージを送信する場合が発生する。すなわち、システムの構成や状況が変化した場合には、リクエストメッセージ送信のための最適な経路が選択されないという問題点があった。

本発明は、上記問題点解決するためになされたもので、その目的は、呼出し先ＷｅｂサービスプロバイダのサブＷｅｂサービスプロバイダの状態変化、構成変化等の発生に起因する呼出し先Ｗｅｂサービスプロバイダのパフォーマンス変化に即応し、最適なサービス利用のための経路を選択して、システム全体の性能、信頼性を向上しうるリクエストメッセージ制御方法を提供することにある。

本発明は、リクエストメッセージ送信先Ｗｅｂサービスプロバイダを決定する際に利用する情報として、Ｗｅｂサービスブローカが直接リクエストメッセージを送信するＷｅｂサービスプロバイダのパフォーマンス情報、状態情報、構成情報に加え、サブＷｅｂサービスプロバイダの性能情報、状態情報、構成情報を利用する。言い換えれば、本発明では、Ｗｅｂサービスブローカ、Ｗｅｂサービスプロバイダが多段に連続してツリー構造を形成して接続している場合、Ｗｅｂサービスブローカが直接呼出すＷｅｂサービスプロバイダの情報だけではなく、ツリー構造の子孫方向に存在するＷｅｂサービスプロバイダの情報も利用して、リクエストメッセージ送信先Ｗｅｂサービスプロバイダを決定する。

本発明によれば、呼出し先ＷｅｂサービスプロバイダのサブＷｅｂサービスプロバイダの状態変化、構成変化等の発生に起因する呼出し先Ｗｅｂサービスプロバイダのパフォーマンス変化に即応し、最適なサービス利用のための経路を選択して、システム全体の性能、信頼性を向上しうるリクエストメッセージ制御方法を提供することができる。

以下、本発明に係る一実施形態を、図１ないし図１２を用いて説明する。

〔システム構成例〕
先ず、図１および図２を用いて本発明の一実施形態に係るサービス提供システムの構成を説明する。
図１は、本発明の一実施形態に係るサービス提供システムを示す構成図である。

図１に示されるサービス提供システムでは、サービスを利用するリクエストメッセージを発信するＷｅｂサービスリクエスタをルートとして、サービスを提供するＷｅｂサービスプロバイダ（以下の明細書と図面において、単に、「Ｗｅｂサービス」という）とＷｅｂサービスリクエスタとＷｅｂサービスのリクエストメッセージの仲介をするＷｅｂサービスブローカがツリー上に配され、これらが例えば、ＴＣＰ／ＩＰネットワークにより結合されている。

本実施形態は、Ｗｅｂサービスリクエスタから、サービスを提供するＷｅｂサービスを呼び出す場合において、呼出されるＷｅｂサービスがさらに別のサブＷｅｂサービスを呼出し、しかも、同一の機能を提供する複数のサブＷｅｂサービスが存在する場合を想定する。そして、その間のＷｅｂサービスブローカが、リクエストメッセージ送信先サブＷｅｂサービスを決定する。

図１では、Ｗｅｂサービスリクエスタ１００がリクエストメッセージをＷｅｂサービスブローカ１０１に送信し、Ｗｅｂサービスブローカ１０１は定義された振分けルールに基づきＷｅｂサービス１０２またはＷｅｂサービス１０３を選択し、リクエストメッセージを送信する。さらに、Ｗｅｂサービス１０２は、Ｗｅｂサービスブローカ１０４を新たに呼出し、Ｗｅｂサービスブローカ１０４は、Ｗｅｂサービス１０５またはＷｅｂサービス１０６からリクエストメッセージ送信先を決定する。なお、図１では、Ｗｅｂサービスブローカは、Ｗｅｂサービスを呼出しているが、他のＷｅｂサービスブローカを直接呼出すこともある。

ここで、サービスリクエスタ１００は、エンドユーザが操作するブラウザ、あるいはリクエストメッセージを送信してレスポンスメッセージを受信するクライアントプログラム、あるいは他のＷｅｂサービスリクエスタから呼出されるＷｅｂサービスである場合がある。すなわち、サービスを提供するＷｅｂサービスも、呼び出される下位のＷｅｂサービスから見れば、サービスリクエスタの役割を担うということである。

Ｗｅｂサービス１０２、Ｗｅｂサービス１０３は同一の機能を提供するＷｅｂサービスであり、Ｗｅｂサービスリクエスタ１００は、Ｗｅｂサービスブローカ１０１の公開するエンドポイントに対してリクエストメッセージを送信するのみで、実際にどちらの具体的なＷｅｂサービスを使用するかは意識しない。同様に、Ｗｅｂサービス１０５、Ｗｅｂサービス１０６も同一の機能を提供するＷｅｂサービスであり、Ｗｅｂサービス１０２は、どちらのＷｅｂサービスを利用するかを意識せずサブＷｅｂサービス呼出しのためのリクエストメッセージをＷｅｂサービスブローカ１０４が公開するエンドポイント宛てに送信する。

本実施形態では、例えば、Ｗｅｂサービス１０９が利用不可状態に変化した場合に、Ｗｅｂサービス１０９が利用不可状態に変化したことに起因するＷｅｂサービスブローカ１０７のパフォーマンス変化、サブＷｅｂサービス構成変化等を、Ｗｅｂサービスブローカ１０７がＷｅｂサービスブローカ１０１に通知（１１０）し、Ｗｅｂサービスブローカ１０１における、Ｗｅｂサービス１０２、１０３の間のリクエストメッセージ振分けルールに反映させることにより、サブＷｅｂサービスの変化に対してより即応性のあるリクエストメッセージ送信先決定を可能とする。

次に、図２を用いてＷｅｂサービスとＷｅｂサービスブローカの構成について説明する。
図２は、ＷｅｂサービスとＷｅｂサービスブローカの構成図である。

ここでは、サービス固有の処理を実装したＷｅｂサービス実装プログラムと、Ｗｅｂサービス実装プログラムを実行するためにＳＯＡＰメッセージ送受信機能や、呼出し先サービスの決定機能等を提供するＷｅｂサービス実行エンジンを併せたものをＷｅｂサービスと表している。

一般的に一つのＷｅｂサービス実行エンジン上には複数のＷｅｂサービス実装プログラムが配備（デプロイ）されており、リクエストメッセージの送信先エンドポイントやメッセージの内容等によって呼出し先Ｗｅｂサービス実装プログラムを決定し、サービスに固有の処理が実行される。

Ｗｅｂサービス２００は、図２に示されるように、リクエスト受信サーバ部２０１とリクエストメッセージ処理部２０２と呼出し先サービス決定部２０４とサービス固有処理部２０５とリクエスト送信クライアント部２０６からなり、データとしては、上位ブローカ管理情報２０３を有している。

リクエスト受信サーバ部２０１は、Ｗｅｂサービスリクエスタからリクエストメッセージを受信する部分である。リクエストメッセージ処理部２０２は、受信したリクエストメッセージ中に含まれる上位Ｗｅｂサービスブローカの情報を取得し、上位ブローカ管理情報２０３を更新する部分である。呼出し先サービス決定部２０４は、呼出し先のＷｅｂサービスが複数ある場合に、呼出し先を決定する部分である。サービス固有処理部２０５は、そのＷｅｂサービスに固有な処理をおこないサービスを提供する部分である。リクエスト送信クライアント部２０６は、受信したリクエストメッセージを、下位のＷｅｂサービスブローカに送信する部分である。

また、上位ブローカ管理情報２０３には、図１に示したような、そのＷｅｂサービスの上位にあたるサービスブローカを管理するための情報が格納されている。

Ｗｅｂサービスブローカ２１０は、図２に示されるように、リクエスト受信サーバ部２１１と呼出し先エンドポイント決定部２１２とリクエストメッセージ処理部２１８とリクエスト送信クライアント部２１９と振分けルール決定部２２０とブローカ間通知送信部２２１とブローカ間通知情報処理部２２３とパーフォマンス計算部２２２とブローカ間通知受信部２２４と、データとしては、下位ブローカ情報２１６と呼出し先Ｗｅｂサービスエンドポイント情報２１３と振分けルール２１４と下位ブローカの呼出し先Ｗｅｂサービスパーフォマンス・状態情報２１７と呼出し先Ｗｅｂサービスパーフォマンス・状態情報２１５、上位ブローカ管理情報２２５とを有している。

リクエスト受信サーバ部２１１は、上位のＷｅｂサービスからリクエストメッセージを受信する部分である。呼出し先エンドポイント決定部２１２は、このＷｅｂサービスブローカが、呼出し先のエンドポイントを決定する部分である。リクエストメッセージ処理部２１８は、受信したリクエストメッセージ中にそのＷｅｂサービスブローカ自身のＷｅｂサービスブローカ情報を付与する部分である。リクエスト送信クライアント部２１９は、呼出し先エンドポイントとして決定されたエンドポイントにリクエストメッセージを送信する部分である。振分けルール決定部２２０は、下位Ｗｅｂサービスブローカから受信した情報を基にして、新たな振分けルールを決定し、振り分けルール２１４に設定する部分である。ブローカ間通知送信部２２１は、作成されたブローカ間通知情報を上位Ｗｅｂサービスブローカに送信する。ブローカ間通知情報処理部２２３は、上位Ｗｅｂサービスブローカへ通知するための通知情報を作成する部分である。パフォーマンス計算部２２２は、下位のＷｅｂサービスブローカの情報などを参照して、自身のＷｅｂサービスブローカのパフォーマンス予測値を計算する部分である。ブローカ間通知受信部２２４は、下位のＷｅｂサービスブローカからの通知情報を受信する部分である。

下位ブローカ情報２１６は、このＷｅｂサービスブローカの下位にあたるＷｅｂサービスブローカに関する情報である。呼出し先Ｗｅｂサービスエンドポイント情報２１３は、このＷｅｂサービスブローカから呼び出されるＷｅｂサービスエンドポイントに関する情報である。振分けルール２１４は、このサービスブローカから呼び出されるＷｅｂサービスエンドポイントを決定するためのルールである。呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５は、このＷｅｂサービスブローカから見た呼出し先Ｗｅｂサービスパフォーマンス・状態情報である。下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７は、このＷｅｂサービスブローカの下位ブローカから見た呼出し先Ｗｅｂサービスパフォーマンス・状態情報である。上位ブローカ管理情報２２５は、Ｗｅｂサービスに格納されている上位ブローカ管理情報２０３と同一の情報であり、Ｗｅｂサービス２００からＷｅｂサービスブローカ２１０にファイル転送して渡すことにしてもよいし、ファイルサーバで共有することにより、データ共有により両者から参照するようにしてもよい。また、Ｗｅｂサービス２００が上位ブローカ管理情報を取り出し、リクエスト送信するときのメッセージに上位ブローカ管理情報を含めることにより、Ｗｅｂサービスブローカ２１０に渡してもよい。

〔データ構造〕
次に、図３ないし図９を用いて本発明に係るサービス提供システムのデータ構造の詳細について説明する。
図３は、上位ブローカ管理情報２０３の一例を示す図である。
図４は、リクエストメッセージ中のＷｅｂサービスブローカ情報の一例を示す図である。
図５は、呼出し先Ｗｅｂサービスエンドポイント情報２１３の一例を示す図である。
図６は、呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５の一例を示す図である。
図７は、下位ブローカ情報２１６の一例を示す図である。
図８は、下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７の一例を示す図である。
図９は、ブローカ間通知メッセージの一例を示す図である。

上位ブローカ管理情報２０３は、そのＷｅｂサービスの上位にあたるサービスブローカを管理するための情報であり、図３に示されるように、リクエストメッセージ送信元のＷｅｂサービスブローカ（上位Ｗｅｂサービスブローカ）の識別名、通知用ポートのエンドポイントＵＲＬ、通知用ポートのインタフェース定義ファイルへのリンク情報、上位Ｗｅｂサービスブローカからのリクエストメッセージを受信したエンドポイントＵＲＬ等の情報を保持する。

Ｗｅｂサービスブローカ情報は、図４に示されるように、リクエストメッセージ中に含まれる。図４に示されるリクエストメッセージ７００は、ＳＯＡＰメッセージであり、 Ｗｅｂサービスブローカ情報７０１を含んでいる。

呼出し先Ｗｅｂサービスエンドポイント情報２１３は、Ｗｅｂサービスブローカから呼び出すＷｅｂサービスのエンドポイントに関する情報を保持し、図５に示されるように、受信エンドポイントＵＲＬと送信先エンドポイントＵＲＬからなる。

この呼出し先Ｗｅｂサービスエンドポイント情報２１３は、Ｗｅｂサービスブローカがリクエストメッセージを受信したエンドポイントＵＲＬに対して、送信先ＷｅｂサービスエンドポイントＵＲＬの集合を管理するためにあり、Ｗｅｂサービスブローカが受信したリクエストメッセージの送信先を決定するために利用される。

呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５は、Ｗｅｂサービスブローカから見た呼出し先Ｗｅｂサービスのパフォーマンスと状態情報を表し、図６に示されるように、Ｗｅｂサービスの識別名、Ｗｅｂサービスのパフォーマンス統計情報、Ｗｅｂサービスの状態情報等を保持する。ここで、パフォーマンス統計情報は、例えば、単位時間当たりのリクエスト処理数等で表される情報であり、状態情報は、利用可能状態（正常状態）を表すａｌｉｖｅ、利用不可能状態（異常状態）を表すｄｅａｄ等で表される情報である。

下位ブローカ情報２１６は、Ｗｅｂサービスブローカの下位にあたるＷｅｂサービスブローカに関する情報であり、図７に示されるように、下位Ｗｅｂサービスブローカ識別名、下位Ｗｅｂサービスブローカのパフォーマンス情報等を保持する。下位ブローカ情報は、下位Ｗｅｂサービスブローカからの通知情報により取得できる。

下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７は、下位ブローカから見た呼出し先Ｗｅｂサービスパフォーマンス・状態情報であり、図８に示されるように、Ｗｅｂサービス識別名、Ｗｅｂサービスのパフォーマンス統計情報、状態情報等を保持する。これらの情報は、下位Ｗｅｂサービスブローカからの通知情報により取得できる。

ブローカ間通知メッセージは、Ｗｅｂサービスブローカ間でやり取りされるメッセージであり、図９に示されるような構造を持つ。図９に示されるブローカ間通知メッセージ１２００は、ＳＯＡＰメッセージであり、１２０１の部分で通知情報送信元Ｗｅｂサービスブローカの識別名とパフォーマンス予測値を示し、１２０２、１２０３は、通知情報送信元Ｗｅｂサービスブローカの呼出し先Ｗｅｂサービスの情報を表し、それぞれＷｅｂサービスブローカ識別名、パフォーマンス情報、状態等の情報を保持する。

〔Ｗｅｂサービス提供システムの処理〕
次に、図１０ないし図１２を用いて本発明の一実施形態に係るサービス提供システムの処理手順について説明する。
図１０は、Ｗｅｂサービスの処理手順を示すフローチャートである。
図１１、図１２は、Ｗｅｂサービスブローカの処理手順を示すフローチャートである。

先ず、図３のフローチャートに従って、ＷｅｂサービスがＷｅｂサービスのリクエストメッセージ受信し、レスポンスメッセージを送信する処理までの手順を説明する。

以下では、図１のＷｅｂサービス１０２の動作について説明する。すなわち、図２のＷｅｂサービス２００は、図１のＷｅｂサービス１０２に該当する。

先ず、Ｗｅｂサービス２００のリクエスト受信サーバ部２０１は、Ｗｅｂサービスリクエスタからリクエストメッセージを受信する（ステップ３００）。

図１に従えばＷｅｂサービスリクエスタは、Ｗｅｂサービスブローカ１０１である。

リクエストメッセージ処理部（ブローカ情報抽出部）２０２は、図４に示したリクエストメッセージ中に含まれる上位Ｗｅｂサービスブローカの情報を取得し、上位ブローカ管理情報２０３を更新する（ステップ３０１）。上位ブローカ管理情報２０３の構造は、図３に示したところである。

次に、呼出し先サービス決定部２０４は、呼出し先Ｗｅｂサービスが複数ある場合の呼出し先を決定して、決定したＷｅｂサービスのサービス固有処理部２０５が、そのＷｅｂサービスに固有の処理を開始する（ステップ３０３）。

サービス固有処理の中では、一部の機能を他のＷｅｂサービスを呼び出すことによって実現する場合がある。その場合、サービス固有処理の中で他のＷｅｂサービスを呼び出すために新たにリクエストメッセージ送信処理がおこなわれる。

このときに、リクエスト送信クライアント部２０６は、リクエストメッセージをＷｅｂサービスブローカに送信する（ステップ３０４）。

次に、リクエスト送信クライアント部２０６は、送信したリクエストメッセージに対するレスポンスメッセージをＷｅｂサービスブローカから受信し（ステップ３０５）、サービス固有処理部２０５は、リクエストメッセージ送信元へ応答するためのレスポンスメッセージを作成し、サービス固有処理を終了する（ステップ３０６）。

そして、リクエスト受信サーバ部２０１は、リクエストメッセージ送信元へレスポンスメッセージを送信する（ステップ３０７）。

次に、図４のフローチャートに従ってＷｅｂサービスブローカが、リクエストメッセージを受信し、レスポンスメッセージを送信するまでの処理手順を説明する。

以下では、図１のＷｅｂサービスブローカ１０４の動作について説明する。すなわち、図２のＷｅｂサービスブローカ２１０は、図１のＷｅｂサービス１０４に該当する。

先ず、Ｗｅｂサービスブローカ２１０のリクエスト受信サーバ部２１１は、Ｗｅｂサービス１０２からリクエストメッセージを受信する（ステップ４００）。

呼出し先エンドポイント決定部２１２では、ステップ４０１〜４０７が実行される。

先ず、呼出し先エンドポイント決定部２１２は、呼出し先Ｗｅｂサービスエンドポイント情報２１３から、呼出し先エンドポイントに関する情報を取得する（ステップ４０１）。呼出し先Ｗｅｂサービスエンドポイント情報２１３の構造は、図５に示したところである。

次に、呼出し先エンドポイント決定部２１２は、振分けルール２１４からリクエストメッセージの振分けルールを取得する（ステップ４０２）。

次に、呼出し先エンドポイント決定部２１２は、呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５（４１０）のパフォーマンス情報を取得する（ステップ４０３）。呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５の構造は、図６に示したところである。

次に、呼出し先エンドポイント決定部２１２は、下位ブローカ情報２１６から、下位ブローカに関する情報を取得する（ステップ４０４）。下位ブローカ情報２１６の構造は、図７に示したところである。

次に、呼出し先エンドポイント決定部２１２は、下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７から、下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報を取得する（ステップ４０５）。下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７の構造は、図８に示したところである。

次に、呼出し先エンドポイント決定部２１２は、最初にリクエストメッセージを作成・送信したユーザ（リクエスタ）のポリシ（リクエスタポリシ）を取得し、検証する（ステップ４０６）。

リクエスタポリシは、リクエストメッセージ中にリクエスタを識別する情報が含まれており、外部のポリシ検索サービスを利用して取得するか、または、メッセージ中にポリシ自体が含む等の方法により取得する。リクエスタポリシには、リクエスタがＷｅｂサービスを利用する際の条件に関する様々な情報が含まれる。

次に、呼出し先エンドポイント決定部２１２は、呼出し先Ｗｅｂサービスのパフォーマンス・状態情報２１５、下位ブローカ情報２１６、下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７、リクエスタポリシの検証結果に基づいて、振分けルール２１４に従って、呼出し先Ｗｅｂサービスエンドポイント情報２１３から取得したエンドポイントの集合の中からリクエストメッセージ送信先を決定する（ステップ４０７）。

例えば、振分けルールとして、より良いパフォーマンスのＷｅｂサービスへ優先的にリクエストメッセージを送信する方式が設定されている場合、Ｗｅｂサービスブローカ１０４が測定するＷｅｂサービス１０５、１０６のパフォーマンス統計情報に基づいて、リクエストメッセージを振分ける。

リクエストメッセージ処理部（ブローカ情報付与部）２１８は、リクエストメッセージ中に自身のＷｅｂサービスブローカ情報を付与する（ステップ４１３）。リクエストメッセージ中に、Ｗｅｂサービスブローカ情報が付与されている様子は、図４に示したところである。

リクエスト送信クライアント部２１９は、決定したエンドポイントへリクエストメッセージを送信する（ステップ４１４）。

そして、リクエスト送信クライアント部２１９が、リクエストメッセージ送信先エンドポイントから正常応答を受信（ステップ４１５）した場合は、呼出し先Ｗｅｂサービスの性能（例えば、レスポンスタイム）を測定し（ステップ４１６）、呼出し先Ｗｅｂサービスパフォーマンス状態情報２１５の該当Ｗｅｂサービスに関するパフォーマンス情報を更新する（ステップ４１７）。

最後に、リクエスト受信サーバ部２１１は、リクエストメッセージ送信元へ受信したレスポンスメッセージを送信する（ステップ４１８）。

次に、図５のフローチャートに従って、Ｗｅｂサービスブローカ１０４（２１０）が呼出しているＷｅｂサービス１０５で異常が発生した場合の処理について説明する。

Ｗｅｂサービスブローカ１０４（２１０）のリクエスト送信クライアント部２１９は、呼出し先Ｗｅｂサービスの利用不可能状態を示すエラーレスポンスメッセージの受信やタイムアウト等の応答異常の場合には（ステップ５００）、呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５の該当するＷｅｂサービスの状態を利用不可（ｄｅａｄ）に更新する（ステップ５０１）。

振分けルール決定部２２０は、呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５から呼出し先Ｗｅｂサービスのパフォーマンス・状態情報を取得する（ステップ５０３）。

次に、振分けルール決定部２２０は、下位ブローカ情報２１６から下位ブローカのパフォーマンス情報を取得する（ステップ５０４）。

次に、振分けルール決定部２２０は、下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７から下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報を取得する（ステップ５０６）。

次に、振分けルール決定部２２０は、呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５、下位ブローカ情報２１６、下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７から取得した情報を用いて、新たな振分けルールを決定し、振分けルール２１４に設定する（ステップ５０８）。

ブローカ間情報通知処理部２２３は、上位ブローカ管理情報２２５から通知情報送信先Ｗｅｂサービスブローカに関する情報を取得する（ステップ５１０）。この上位ブローカ管理情報２２５は、Ｗｅｂサービスの上位ブローカ管理情報２０３が反映されたものである。

そして、上位Ｗｅｂサービスブローカが存在するかどうかを検証し（ステップ５１２）、上位Ｗｅｂサービスブローカが存在する場合は、ステップ５１３へ進み、上位Ｗｅｂサービスブローカが存在しなければ終了する。

上位Ｗｅｂサービスブローカが存在する場合、パフォーマンス計算部２２２は、呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５（５０２）、下位ブローカ情報２１６（５０５）、下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７（５０７）から取得した情報と振分けルール２１４（５０９）を用いて、Ｗｅｂサービスブローカのパフォーマンス予測値を計算する（ステップ５１３）。

例えば、Ｗｅｂサービス１０５、１０６が同程度のパフォーマンスを発揮しており、Ｗｅｂサービスブローカ１０４がＷｅｂサービス１０５、１０６に対して同程度にリクエストメッセージを振り分けていた場合、Ｗｅｂサービス１０６が利用不可状態に変化したことによって、Ｗｅｂサービスブローカ１０４がＷｅｂサービス１０２からのリクエストを受信するエンドポイントとしてのパフォーマンスは、それまでのパフォーマンスの１／２と予測する等である。

ブローカ間通知情報処理部２２３は、上位Ｗｅｂサービスブローカへ通知するための通知情報を作成する（ステップ５１４）。

そして、ブローカ間情報通知送信部２２１は、作成された通知情報を上位ＷｅｂサービスブローカであるＷｅｂサービスブローカ１０１へ送信する（ステップ５１５）。

次に、下位にあるＷｅｂサービスブローカ１０４から通知情報を受信したＷｅｂサービスブローカ１０１（２１０）の処理について、図５のフローチャートに従って説明する。

Ｗｅｂサービスブローカ１０１（２１０）のブローカ間通知受信部２２４は、図９に示したブローカ間通知メッセージ１２００により、Ｗｅｂサービスブローカ１０４からの通知情報を受信する（ステップ５１６）。

ブローカ間通知情報処理部２２４は、通知情報から取得した下位ブローカ情報を下位ブローカ情報２１６に登録する（ステップ５１７）。

振分けルール決定部２２０は、下位ブローカ情報２１６から、下位ブローカ情報を取得する（ステップ５１８）。

次に、振分けルール決定部２２０は、下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７から、下位Ｗｅｂサービスの呼出し先Ｗｅｂサービスパフォーマンス・状態情報を取得する（ステップ５１９）。

次に、振分けルール決定部２２０は、呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５から各呼出し先Ｗｅｂサービスのパフォーマンス情報、状態情報を取得する（ステップ５２０）。

次に、振分けルール決定部２２０は、呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５、下位ブローカ情報２１６、下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７から取得した情報を用いて、新たな振分けルールを決定し、振分けルール２１４へ設定する（ステップ５０８）。

例えば、下位Ｗｅｂサービスブローカ１０４からの通知情報受信以前までは、Ｗｅｂサービス１０２のパフォーマンスがＷｅｂサービス１０３より上回っていたため、Ｗｅｂサービス１０２へ優先的にリクエストメッセージを振分けるルールが適用されていた場合を考える。下位Ｗｅｂサービスブローカ１０４から、Ｗｅｂサービス１０５のシステムダウンによりＷｅｂサービスブローカのパフォーマンス予測値がそれまでの１／２に変化することが通知された場合、Ｗｅｂサービス１０３へリクエストを送信した場合のパフォーマンスがＷｅｂサービス１０２へ送信した場合のパフォーマンスより上回ることが期待できると判断でき、新たな振分けルールとしてＷｅｂサービス１０３へ優先的にリクエストメッセージを振分けるルールを設定する。

また、例えば、下位Ｗｅｂサービスブローカ１０４からの通知情報受信以前までは、Ｗｅｂサービス１０５、１０６、Ｗｅｂサービス１０８、１０９のパフォーマンスが同程度であり、Ｗｅｂサービスブローカ１０１のリクエストメッセージ振分け比率として、１：１が設定されていた場合を考える。下位Ｗｅｂサービスブローカ１０４から、Ｗｅｂサービス１０６が利用不可状態になったことが通知された場合、新たな振分けルールとして、１：２の比率でＷｅｂサービス１０２、１０３へリクエストメッセージを振分けるルールを設定する。

下位Ｗｅｂサービスブローカから通知情報を受信したＷｅｂサービスブローカは、通知情報に含まれる情報（Ｗｅｂサービスブローカのエンドポイントのパフォーマンス予測値、下位ブローカの呼出し先Ｗｅｂサービスのパフォーマンス・状態情報等）を自由に組み合わせて新たな振分けルールを決定することができる。

下位Ｗｅｂサービスのパフォーマンス変化、状態変化、構成変化等に起因して下位Ｗｅｂサービスブローカから通知される情報を用いて新たにＷｅｂサービスブローカに設定される振分けルールは暫定的なルールとして利用し、ある一定時間の経過後それまでと同様に呼出し先Ｗｅｂサービスの統計的なパフォーマンス情報に基づいた振分けルールに再度戻す方法をとることもできる。

このようにすれば、状態変化が発生した場合、パフォーマンス統計情報に状態変化発生の影響が反映されるまでにはある一定時間のパフォーマンス測定が必要であり、それまでの間、状態変化発生の影響を考慮して導き出した予測値に従ったルールを適用することにより、より状態変化に対して即応性のあるリクエストメッセージ送信先決定をおこなうことができる。

このとき、図１２に示した振分けルール設定５０８の後の次のステップ５１０以降の処理は前述と同様である。

〔Ｗｅｂサービスにおけるリクエスタポリシの設定について〕
ここで、リクエスタポリシとして、リクエスタが利用したくないＷｅｂサービスとしてＷｅｂサービス１０９が指定されている場合を考える。

今、Ｗｅｂサービス１０８がシステムダウンにより利用不可能状態に変化し、Ｗｅｂサービスブローカ１０７が上位Ｗｅｂサービスブローカ１０１へ通知情報を送信する場合を想定する。

このとき、Ｗｅｂサービスブローカ１０１は、リクエストメッセージの送信先としてＷｅｂサービス１０３を選択した場合、下位Ｗｅｂサービス１０９の利用が避けられないことを、下位Ｗｅｂサービスブローカ１０７からの通知情報を基に把握することができ、リクエスタのポリシを満たすために、リクエストメッセージをＷｅｂサービス１０２へ送信することができる。

従来は、向けＷｅｂサービスブローカ１０７のリクエストメッセージ送信先決定の段階でリクエスタポリシを満たすリクエストメッセージ送信先が存在しないことが判明し、上位の分岐まで遡った処理をするか、または、エラーによるリクエストメッセージの再送信を最初からやり直したりしていたが、本発明では、下位Ｗｅｂサービスの情報を上位の分岐点で把握しているため、そのようなむだな処理の発生を回避することができる。

本発明の一実施形態に係るサービス提供システムを示す構成図である。 ＷｅｂサービスとＷｅｂサービスブローカの構成図である。 上位ブローカ管理情報２０３の一例を示す図である。 リクエストメッセージ中のＷｅｂサービスブローカ情報の一例を示す図である。 呼出し先Ｗｅｂサービスエンドポイント情報２１３の一例を示す図である。 呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１５の一例を示す図である。 下位ブローカ情報２１６の一例を示す図である。 下位ブローカの呼出し先Ｗｅｂサービスパフォーマンス・状態情報２１７の一例を示す図である。 ブローカ間通知メッセージの一例を示す図である。 Ｗｅｂサービスの処理手順を示すフローチャートである。 Ｗｅｂサービスブローカの処理手順を示すフローチャートである（その一）。 Ｗｅｂサービスブローカの処理手順を示すフローチャートである（その二）。

符号の説明

１００…Ｗｅｂサービスリクエスタ
１０１…Ｗｅｂサービスブローカ
１０２…Ｗｅｂサービスブローカ１０１が直接リクエストメッセージを送信するＷｅｂサービス
１０３…Ｗｅｂサービスブローカ１０１が直接リクエストメッセージを送信するＷｅｂサービス
１０４…Ｗｅｂサービスブローカ１０１の下位Ｗｅｂサービスブローカ
１０５ …Ｗｅｂサービスブローカ１０４が直接リクエストメッセージを送信するＷｅｂサービス
１０６ …Ｗｅｂサービスブローカ１０４が直接リクエストメッセージを送信するＷｅｂサービス
１０７ …Ｗｅｂサービスブローカ１０１の下位Ｗｅｂサービスブローカ
１０８ …Ｗｅｂサービスブローカ１０７が直接リクエストメッセージを送信するＷｅｂサービス
１０９ …Ｗｅｂサービスブローカ１０７が直接リクエストメッセージを送信するＷｅｂサービス
１１０ …Ｗｅｂサービスブローカ１０４からＷｅｂサービスブローカ１０１への通知情報

Claims (8)

1. サービスを利用するためのリクエストメッセージを送信するサービスリクエスタと、
   前記リクエストメッセージを受信し、そのメッセージに基づく同一のサービスを提供する複数のサービスプロバイダと、
   前記リクエストメッセージを受信し、そのメッセージを前記サービスプロバイダのいずれかまたは他のサービスブローカに送信するサービスブローカとがネットワークにより結合されたサービス提供システムにおいて、
   前記サービスリクエスタと、前記サービスブローカと、前記サービスプロバイダとは、ツリー構造を持つように結合され、
   前記サービス提供システムは、前記ツリー構造のルートにあたるサービスリクエスタから発信されるリクエストメッセージを、下位にあたるサービスブローカとサービスプロバイダとに順次転送して、サービスを実現するサービス提供システムであって、
   前記サービスブローカは、そのサービスブローカの下位にあたるサービスプロバイダの性能情報と、状態情報と、前記ツリー構造上のサービスブローカの関係情報とを参照して、前記下位にあたるサービスブローカまたはサービスプロバイダを選択して、前記ツリー構造の上位にあたるサービスプロバイダから送信されるリクエストメッセージを、前記選択したサービスブローカまたはサービスプロバイダに送信することを特徴とするリクエストメッセージ制御方法。
2. 前記サービスブローカは、そのサービスブローカの下位にあたるサービスプロバイダの性能情報と、状態情報と、前記ツリー構造上のサービスブローカの関係情報とを、そのサービスブローカの上位にあたるサービスブローカに通知することを特徴とする請求項１記載のリクエストメッセージ制御方法。
3. 前記サービスブローカは、そのサービスブローカの下位にあたるサービスブローカから通知された前記サービスプロバイダの性能情報、状態情報と、前記ツリー構造上のサービスブローカの関係情報とに基づき、そのサービスブローカにリクエストメッセージを送信したときに得られるサービスのパフォーマンス予測値を算出し、そのサービスブローカの上位にあたるサービスブローカに、算出したパフォーマンス予測値を通知し、
   前記パフォーマンス予測値を通知されたサービスブローカは、通知されたパフォーマンス予測値を参照して、前記下位にあたるサービスブローカまたはサービスプロバイダを選択して、前記ツリー構造の上位にあたるサービスプロバイダから送信されるリクエストメッセージを、前記選択したサービスブローカまたはサービスプロバイダに送信することを特徴とする請求項１記載のリクエストメッセージ制御方法。
4. 前記サービスブローカが、前記サービスリクエスタのサービスを提供されるためのポリシ（リクエスタポリシ）を参照し、
   前記サービスブローカは、前記リクエスタポリシに基づいて、同一のサービスを提供する下位にあたるサービスプロバイダが複数ある場合には、前記下位にあたるサービスブローカまたはサービスプロバイダを選択することを特徴とする請求項１記載のリクエストメッセージ制御方法。
5. 特に、前記リクエスタポリシには、前記サービスリクエスタが利用したくないサービスプロバイダの記述が含まれ、前記サービスリクエスタが利用したくないサービスプロバイダが含まれるサブツリーの方向には、前記リクエストメッセージが送信されないように、前記下位にあたるサービスブローカまたはサービスプロバイダを選択することを特徴とする請求項４記載のリクエストメッセージ制御方法。
6. サービスを利用するためのリクエストメッセージを送信するサービスリクエスタと、
   前記リクエストメッセージを受信し、そのメッセージに基づく同一のサービスを提供する複数のサービスプロバイダと、
   前記リクエストメッセージを受信し、そのメッセージを前記サービスプロバイダのいずれかまたは他のサービスブローカに送信するサービスブローカとがネットワークにより、ツリー構造を持つように結合され、
   前記ツリー構造のルートにあたるサービスリクエスタから発信されるリクエストメッセージを、下位にあたるサービスブローカとサービスプロバイダとに順次転送して、サービスを実現するサービス提供システムにおいて、
   前記サービスブローカは、そのサービスブローカの下位にあたるサービスプロバイダの性能情報と、状態情報と、前記ツリー構造上のサービスブローカの関係情報とを参照して、前記下位にあたるサービスブローカまたはサービスプロバイダを選択して、前記ツリー構造の上位にあたるサービスプロバイダから送信されるリクエストメッセージを、前記選択したサービスブローカまたはサービスプロバイダに送信することを特徴とするサービス提供システム。
7. 前記サービスブローカは、そのサービスブローカの下位にあたるサービスプロバイダの性能情報と、状態情報と、前記ツリー構造上のサービスブローカの関係情報とを、そのサービスブローカの上位にあたるサービスブローカに通知することを特徴とする請求項６記載のサービス提供システム。
8. Ｗｅｂサービスリクエスタと、Ｗｅｂサービスプロバイダと、Ｗｅｂサービスブローカとから構成され、Ｗｅｂサービスを提供することを特徴とする請求項６記載のサービス提供システム。
   

Images