JP5979223B2 - 分散処理におけるサービス検索方法、プログラム、およびサーバ装置 - Google Patents

Description

分散処理システムにおけるサービス検索方法、プログラム、およびサーバ装置に関する。

複数のサーバがネットワークによって接続された分散処理システムにおいて、クライアントからあるサービスの検索依頼が発生した場合に、複数のサーバから一つ以上のサーバを選択して検索を実行する必要がある。

このような検索を実行するための従来技術として、次のようなものがある。クライアントは、特定のサーバに対して検索を要求し、その特定のサーバが他のサーバの状況を検索して要求に合うサーバを選択し、クライアントに回答する。このとき、特定のサーバは要求にあったサーバが受付けが可能か問合せを行い、受付け不可ならば他のサーバを選択し受付け可能となるまで問い合わせを続ける。

しかし、この従来技術では、ネットワーク上のクライアントからの検索要求の数が増加したときに、それらの検索要求を受け付ける特定のサーバの負荷が増大するという問題点を有していた。

また、他の従来技術として確実性高く連携情報を伝達し効率的に連携処理を行うことができるサービス処理装置及び連携処理システムを提供するために、各サービスを連携させるための指示書を各サービスを提供するサービス処理装置間で順次伝達していく。これにより、各サービス処理装置で指示書に基づいたサービスが順次実行されて一連のサービスの連携処理が行われるシステムが知られている（例えば特許文献１）。伝達される指示書には、各サービス毎に、各サービスを行うサービス処理装置を指定するための属性情報が記述される。サービス処理装置は、指示書を次のサービス処理装置に伝達するにあたり、受信した指示書内の次のサービスを行うサービス処理装置を指定するための属性情報に基づいてサービス処理装置を検索し、送信先を決定する。サービス処理装置は、該決定された送信先に指示書を送信する。

しかし、この従来技術は、指示書に基づいて複数のサービス処理装置が連携する技術を開示しているものであって、サービス処理装置はやはり検索サーバという特定のサーバに問合せをしながら連携しなければならない。このため、この従来技術でも、特定のサーバの負荷が増大するという問題点を有していた。

特開２００５−２２８２５２号公報

そこで、本発明は、特定のサーバへの負荷の集中を回避することを目的とする。
態様の一例では、サーバの属性情報を他のサーバとの間で交換することにより経路情報を生成し、サービス検索依頼元からサービス検索依頼を受信したときに、前記サーバの属性情報を参照することにより、前記サーバが前記サービス検索依頼におけるサービス検索条件に適合するか否かを判定し、適合しないと判定した場合に、前記サービス検索依頼に付加されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サーバの情報を前記検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送し、適合すると判定した場合に、前記サービス検索依頼に付加されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サービス検索条件が指定するサーバの数を１減らすとともに前記サーバの情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送することを備える。

サービス検索について、特定ノードに集中して検索する必要がなく負荷分散が可能になる。検索時点で適切なサービス実施ノードを決定することが可能となる。

本発明の実施形態におけるサーバノードの構成図である。 従来技術の動作を説明する図である。 本実施形態における属性情報の交換動作を説明する図である。 Ｈｅｌｌｏメッセージのデータ構成例を示す図である。 属性情報ＤＢのデータ構成例を示す図である。 経路情報ＤＢのデータ構成例を示す図である。 本実施形態におけるサービス検索依頼メッセージの転送動作を説明する図である。 サービス検索依頼メッセージのデータ構成例を示す図である。 検索判定処理の制御動作例を示すフローチャートである。 検索結果通知処理の制御動作例を示すフローチャートである。 検索結果転送処理の制御動作例を示すフローチャートである。 経路情報通知処理の制御動作例を示すフローチャートである。 経路情報生成処理の制御動作例を示すフローチャートである。 Ｈｅｌｌｏメッセージのデータフォーマット例を示す図である。 サービス検索依頼メッセージのデータフォーマット例を示す図である。 検索結果メッセージのデータフォーマット例を示す図である。 本実施形態のシステムを実現可能なハードウェアシステムの構成図である。

以下、本発明を実施するための形態について図面を参照しながら詳細に説明する。
図１は、本発明の実施形態による互いに複数台がネットワークによって接続されるサービスを行なうサーバ装置であるサーバノード１００の構成図である。

属性情報データベース（以下、「属性情報ＤＢ」と呼ぶ）１０１は、自サーバノード１００に関するサービス情報とリソース情報を含む属性情報を蓄積する。
経路情報通知部１０２は、定期的に、属性情報ＤＢ１０１を参照することにより、自サーバノード１００に関するサービス情報とリソース情報を含む例えばＨｅｌｌｏメッセージ１１３を生成する。そして、経路情報通知部１０２は、このＨｅｌｌｏメッセージ１１３を、メッセージ送信部１０３を介して、ネットワークに接続される他のサーバノード１００に例えば定期的に通知する。

メッセージ受信部１０４は、他のサーバノード１００からのメッセージを受信する。メッセージ振分け部１０５は、メッセージ受信部１０４が受信したメッセージのうち、Ｈｅｌｌｏメッセージ１１３を経路情報生成部１０６に、検索依頼メッセージ１１４を検索判定部１０８にそれぞれ振り分ける。

経路情報生成部１０６は、メッセージ受信部１０４およびメッセージ振分け部１０５を介して受信された他サーバノード１００からのＨｅｌｌｏメッセージ１１３に含まれる属性情報に基づいて、経路情報を生成する。このとき例えば、経路情報生成部１０６は、属性情報に基づいて計算したサービス検索の優先度を経路情報に付加する。そして、経路情報生成部１０６は、生成した経路情報を含むように、経路情報データベース（以下、「経路情報ＤＢ」と呼ぶ）１０７を更新する。すなわち、経路情報ＤＢ１０７は、他サーバノード１００との間で交換した属性情報に基づいて経路情報生成部１０６によって生成された経路情報を蓄積するデータベースである。

検索判定部１０８は、メッセージ受信部１０４およびメッセージ振分け部１０５を介してクライアントノードまたは他サーバノード１００からサービス検索依頼メッセージ１１４を受信したときに、以下の動作を実行する。検索判定部１０８は、属性情報ＤＢ１０１に蓄積されている自身の属性情報を参照することにより、自身がサービス検索依頼メッセージ１１４に格納されているサービス検索条件にマッチするか否かを判定する。サービス検索条件としては例えば、
サービスＩＤ＝“分散バッチサービス”
ＣＰＵ使用率＜＝２０％
必要数＝５
のような指定がなされる。

検索転送部１０９は、検索判定部１０８でマッチが成立しないと判定した場合に、サービス検索依頼メッセージ１１４に付加されている検索履歴情報に検索実績がないサーバノード１００を、経路情報ＤＢ１０７に蓄積されている経路情報に基づいて選択する。このとき例えば、検索転送部１０９は、経路情報に含まれる優先度が高いサーバノード１００を選択する。そして、検索転送部１０９は、自身のサーバノード１００の情報を検索履歴情報として付加したサービス検索依頼メッセージ１１４を、メッセージ送信部１０３を介して、選択したサーバノード１００に転送する。

検索結果通知部１１０は、検索判定部１０８でマッチが成立すると判定した場合に、次の処理を実行する。検索結果通知部１１０は、自身のサーバノード１００が生成した経路情報を基に、サービス検索依頼メッセージ１１４に対する応答である検索結果メッセージ１１５を、メッセージ送信部１０３を介して、サービス検索依頼メッセージ１１４の依頼元へ通知する。検索結果メッセージ１１５によって、検索結果、条件を満たすサーバのアドレス(ＵＲＩ等)が返却される。前述のサービス検索依頼メッセージ１１４中のサービス検索条件として、例えば必要数＝５が設定されていれば、検索結果は５回受けとることになる。

サービス登録部１１１は、属性情報ＤＢ１０１が蓄積する自サーバノード１００のサービス情報の登録または削除を行う。ヒューマンインタフェースによって人間が手動でサービス登録を行ったり、マシン起動時のバッチ処理（ＡＰＩやコマンド)等で登録されてよい。

ノード情報監視部１１２は、自身のサーバのリソースを監視し、監視の結果に基づいて属性情報ＤＢ１０１が蓄積する自サーバノード１００のサービス情報及びリソース情報を更新する。

以上の本実施形態の構成により、例えばクライアントノードからのサービス検索依頼メッセージ１１４は、ネットワークによって接続された複数のサーバノード１００のうちの任意のサーバノード１００にて受信される。そして、受信したサービス検索依頼メッセージ１１４が自ノードで処理できない場合には、サービス検索依頼メッセージ１１４を、経路情報ＤＢ１０７から決定される他のサーバノード１００に転送する。いずれかのサーバノード１００にて、サービス検索依頼メッセージ１１４を自ノードで処理できる場合は、検索処理を実行し、その検索結果を、検索結果メッセージ１１５に格納して、サービス検索依頼メッセージ１１４の依頼元の例えばクライアントノードに通知する。このような制御動作により、サービス検索について、特定ノードに集中して検索する必要がなく負荷分散が可能になる。あらかじめ相互に交換している経路情報に基づいて、検索時点で最適なサービス実施ノードを決定することが可能となる。

図１の構成を有する本発明の実施形態の動作について、以下に詳細に説明する。
まず、本実施形態との対比を明確にするために、従来のサービス検索方法の例について、図２を用いて説明する。図２において、Ｃ１はクライアントノード、Ｓｉ（ｉ＝１〜４）はサーバノード、ＳＸはサービス検索サーバノードを示す。図２の構成は、一つのサブネット２０１内で、これらの各ノードが相互に接続された構成を有する。以下の（１）〜（４）の処理は、それぞれ図２中の（１）〜（４）の処理の矢印と対応している。

クライアントノードＣ１から検索依頼を受信したサービス検索サーバノードＳＸが、検索を行い、クライアントノードＣ１に結果を返す仕組みになっている。
（１）サービス検索サーバノードＳＸに各サーバノードの情報（リソース情報、ハードスペック、サービス等）の情報を集め、データベースに登録する。
（２）クライアントノードＣ１からサービス検索依頼を、サービス検索サーバノードＳＸが受ける。
（３）サービス検索サーバノードＳＸは自ノードのデータベースを参照し、クライアントノードＣ１の要求にあったサーバノードＳｉを選び、受付が可能か問い合わせる。問合せで、受付不可なら再度データベースを参照して他のサーバノードＳｉを選び受付可能になるまで問合せを続ける。
（４）サービス検索サーバノードＳＸは、クライアントノードＣ１に検索結果を返信する。

以上の（１）〜（４）の制御処理を実行する従来技術の構成では、検索要求を行うクライアントノードの数がＣ１だけでなく他のにも増加したときに、それらの検索要求を受け付けるサービス検索サーバノードＳＸの負荷が増大してしまう。

そこで、本実施形態では、図１の構成を有するサーバノード１００が以下に説明する分散処理を実行することにより、負荷分散を実現する。

図３は、図１に示される構成を有する本実施形態における属性情報の交換動作を説明する図である。図３において、Ｃｊ（ｊ＝１，２）はクライアントノード、Ｓｉ（ｉ＝１〜５）は図１の構成を有するサーバノード１００を示す。なお、サーバノードは、仮想マシンであってもよい。図３の構成では、Ｈｅｌｌｏメッセージ１１３が到達可能なネットワークである一つのサブネット３０１内で、多数のサーバノードＳｉが相互に接続される。さらに、任意のサーバノードＳｉに、サブネット３０１の内外から、それらを利用するクライアントノードＣｊが接続される。本実施形態では、従来技術と異なり、図２にあったような、特定のサービス検索サーバノードＳＸは不要である。

図３の構成で、各サーバノードＳｉ内の経路情報通知部１０２（図１）は、図３の両矢印付き実線群で示されるＨｅｌｌｏメッセージ１１３を用い、自ノード内の属性情報ＤＢ１０１から読み出した属性情報を、他のサーバノードＳｉに定期的にブロードキャストする。あるいは、Ｈｅｌｌｏメッセージ１１３のブロードキャストのタイミングは、自ノードの起動時、特定のイベントの発生時等であってもよい。

図４は、Ｈｅｌｌｏメッセージ１１３のデータ構成例を示す図である。宛先アドレス４０１としては、サブネット３０１（図３）内のブロードキャストアドレスが格納される。送信元アドレス４０２としては、自ノードのアドレスが格納される。サービス情報４０３としては、検索サービスのサービスＩＤ（識別子）、サービス名、サービススペック等が格納される。リソース情報としての自ノード情報４０４としては、ＣＰＵ（中央演算処理装置）種別、ＣＰＵ使用率、メモリ使用率、ハードディスク使用率等の、サーバノード１００（Ｓｉ）のハードウェアのリソース情報が格納される。

これらのサービス情報およびリソース情報は、図１の属性情報ＤＢ１０１を参照して取得される。図５は、属性情報ＤＢ１０１のデータ構成例を示す図である。

属性情報ＤＢ１０１には、図１のサーバノード１００に関して、サーバノードＩＤ（識別情報）（図中の記載例「サーバノード５」）に対応させて、リソース情報としてＣＰＵ使用率、メモリ使用率などの値が蓄積されている。これらのリソース情報は、図１のノード情報監視部１１２が、自ノードのハードウェアリソースを例えば定期的、起動時、またはイベント発生時に監視し、その監視結果に基づいて更新される。監視は、ＣＰＵ使用率、メモリ使用率などを取得するコマンドを実行することで行われる。

また、属性情報ＤＢ１０１には、検索サービスのサービスＩＤ（図中の記載例「サービス１００１」または「サービス１００２」）に対応させて、次のサービス情報が蓄積される。サービス名、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ：統一資源識別子）、およびサービス固有情報（サービススペック）等である。サービス名は、文字列である。ＵＲＩには、例えば分散ファイルシステムを示す表記、例えば「ｈｄｆｓ＿ｓｙｓｔｅｍ：／／・・・」が設定される。サービス固有情報は、例えばハードディスクの容量である。

図１の経路情報通知部１０２は、図５に例示されるような構成を有する属性情報ＤＢ１０１を参照することにより、図４に例示されるようなデータ構成を有するＨｅｌｌｏメッセージ１１３を生成し、ブロードキャストする。

図３の説明に戻り、各サーバノードＳｉ内の経路情報生成部１０６（図１）は、他のサーバノードＳｉからブロードキャストされるＨｅｌｌｏメッセージ１１３を受信すると、優先順位付きの経路情報を生成し、経路情報ＤＢ１０７（図１）に対して登録または情報の更新を行う。

図６は、経路情報ＤＢ１０７のデータ構成例を示す図である。経路情報として、転送先サーバのサーバ識別情報（図中の記載例「サーバノード２」または「サーバノード４」）と、各サーバ識別情報に対応する優先度の情報（図中の記載例「８０」または「６０」）が登録される。サーバ識別情報は例えば、サーバノード１００のホスト名または宛先アドレスであってよい。図１の経路情報生成部１０６は、例えば所定の評価関数によって、各サーバノードＳｉ（図３）ごとの優先度を決定する。この評価関数は例えば、図４に例示される構成を有するＨｅｌｌｏメッセージ１１３内のリソース情報として自ノード情報に含まれるＣＰＵ種別、ＣＰＵ使用率、メモリ使用率、ハードディスク使用率や、サービス情報に含まれるサービスによる負荷率等をパラメータとして定義される。例えばＣＰＵ使用率の小さいほうが優先度が高い等である。ネットワーク内の各サーバノードＳｉをどう使いたいかによって、優先度の決定の仕方を決めることができる。

図７は、本実施形態における図１のサービス検索依頼メッセージ１１４の転送動作を説明する図である。図７において、サーバノードＳｉ、クライアントノードＣｊ、およびサブネット３０１は、図３に示されるものと同様である。以下の説明では、随時、図１の構成を参照する。また、以下のＩ、II、III （III ―１、III ―２）、およびIV（IV−１、IV−２）の各処理は、図７中の四角で囲まれた同じ番号の部分の処理を示す。また、図８は、サービス検索依頼メッセージのデータ構成例を示す図である。図８中のＩ、III （ａ）、およびIII （ｂ）の各行が、以下のＩおよびIII の各処理で扱われるサービス検索依頼メッセージ１１４のデータ構造を示している。

（Ｉ）クライアントノードＣ１は、任意に指定されるサーバノード例えばＳ５に、図８のＩとして示されるデータ構造を有するサービス検索依頼メッセージ１１４を送信する。図７中のＣ１からＳ５へ向かう「Ｉ」の矢印が該当する。図８に示されるように、このサービス検索依頼メッセージ１１４には、依頼元として、クライアントノードＣ１のアドレス（図中Ｉの記載例「Ｃ１」）が格納される。依頼先として、サーバノードＳ５のアドレス（図中Ｉの記載例「Ｓ５」）が格納される。また、所定のサービス検索条件が格納される。

（II）サーバノードＳ５では、検索判定部１０８が、サービス検索依頼メッセージ１１４を受信すると、自ノードの属性情報ＤＢ１０１を参照することにより、自ノードが受信したサービス検索依頼メッセージ１１４中のサービス検索条件に該当するかを判定する。
（III −１）検索判定部１０８での判定結果がＮＧの（条件にあっていない）場合、サービス検索依頼メッセージ１１４を検索転送部１０９に渡す。
（III −２）検索転送部１０９は、経路情報ＤＢ１０７を参照して転送先のサーバノードを決定し、サービス検索依頼メッセージ１１４の依頼先にそのサーバノードのアドレス（図８中III （ａ）の記載例「Ｓ３」）を格納し、サービス検索依頼メッセージ１１４の検索履歴情報である検索済リストに自ノードＩＤ（図中III （ａ）の記載例「Ｓ５」）を追加して、サーバノード（Ｓ３）に転送する。図７中のＳ５からＳ３へ向かう「III ―２」の矢印が該当する。

以降、転送先でも同様な処理が行われる。
（II）すなわち、サーバノードＳ３では、検索判定部１０８が、サービス検索依頼メッセージ１１４を受信すると、自ノードの属性情報ＤＢ１０１を参照することにより、自ノードが受信したサービス検索依頼メッセージ１１４中のサービス検索条件に該当するかを判定する。

（III −１）検索判定部１０８での判定結果がＮＧの場合、サービス検索依頼メッセージ１１４を検索転送部１０９に渡す。
（III −２）検索転送部１０９は、経路情報ＤＢ１０７を参照して転送先のサーバノードを決定し、サービス検索依頼メッセージ１１４の依頼先にそのサーバノードのアドレス（図８中III （ｂ）の記載例「Ｓ１」）を格納し、サービス検索依頼メッセージ１１４の検索済リスト（検索履歴情報）に自ノードＩＤ（図中III （ｂ）の記載例「Ｓ３」）を追加して、サーバノード（Ｓ１）に転送する。図７中のＳ３からＳ１へ向かう「III ―２」の矢印が該当する。

（II）サーバノードＳ１でも、検索判定部１０８が、サービス検索依頼メッセージ１１４を受信すると、自ノードの属性情報ＤＢ１０１を参照することにより、自ノードが受信したサービス検索依頼メッセージ１１４中のサービス検索条件に該当するかを判定する。

（IV−１）検索判定部１０８での判定結果がＯＫの（条件に合った）場合、サービス検索依頼メッセージ１１４が検索結果通知部１１０に渡される。
（IV−２）検索結果通知部１１０は、サービスの検索結果が格納された検索結果メッセージ１１５を作成し、依頼元のクライアントノードC1に送信する。図７中のＳ１からＳ２を経由してＣ１へ向かう「IV―２」の矢印が該当する。

以上の図７に示される動作例により、例えばクライアントノードＣ１からのサービス検索依頼メッセージ１１４は、任意のサーバノードＳ５にて受信される。そして、受信したサービス検索依頼メッセージ１１４が自ノードで処理できない場合には、サーバノードＳ５→Ｓ３→Ｓ１と転送されて、サーバノードＳ１にて検索処理が実行される。その検索結果は、サーバノードＳ１にて検索結果メッセージ１１５に格納されて、サービス検索依頼メッセージ１１４の送信元の例えばクライアントノードＣ１に通知される。このような制御動作により、クライアントノードＣｊからのサービス検索依頼メッセージ１１４は、任意のサーバノードＳｉにて受信することができ、検索可能なサーバノードＳｉに転送することができる。これにより、特定ノードに集中しない負荷分散が可能になる。あらかじめ相互に交換し経路情報ＤＢ１０７に蓄積している経路情報に基づいて、検索時点で適切なサービス実施ノードを決定することが可能となる。

ここで、サービス検索依頼メッセージ１１４に格納されているサービス検索条件において複数のサーバノードＳｉに対する検索が指定されるように構成することができる。この場合、検索結果通知部１１０は、検索判定部１０８でマッチが成立すると判定した場合に、前述した検索結果メッセージ１１５をサービス検索依頼メッセージ１１４の送信元へ通知するとともに、次の処理を実行する。検索結果通知部１１０は、サービス検索条件が指定するサーバの数が１でなければ、サービス検索依頼メッセージ１１４中のサービス検索条件が指定するサーバノードＳｉの数を１減らした上で、検索転送部１０９に、そのサービス検索依頼メッセージ１１４の転送を指示する。このような構成により、複数のサーバノードＳｉ間で負荷分散を図りながら、かつ複数のサーバノードＳｉを使ってサービス検索依頼メッセージ１１４に対するサービス検索処理を実行することが可能となる。

図９は、図１の検索判定部１０８を実現する検索判定処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。

まず、サービス検索依頼メッセージ１１４からサービス検索条件が取り出される（ステップＳ９０１）。

次に、図１の属性情報ＤＢ１０１が参照され、ステップＳ９０１で取り出されたサービス検索条件を満たしているかが判定される（ステップＳ９０２）。

サービス検索条件を満たしているならば（ステップＳ９０３の判定がＹｅｓ）、サービス検索依頼メッセージ１１４が検索結果通知部１１０に通知される（ステップＳ９０４）。その後、検索判定処理の制御処理を終了する。

サービス検索条件を満たしていないならば（ステップＳ９０３の判定がＮｏ）、サービス検索依頼メッセージ１１４が検索転送部１０９に通知される（ステップＳ９０５）。その後、検索判定処理の制御処理を終了する。

図１０は、図１の検索結果通知部１１０を実現する検索結果通知処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。

まず、サービス検索依頼メッセージ１１４から依頼元が取り出される（図８参照）（ステップＳ１００１）。

次に、検索結果が格納され、ステップＳ１００１で取り出された依頼元が格納された検索結果メッセージ１１５が生成される（ステップＳ１００２）。

次に、ステップＳ１００２で生成された検索結果メッセージ１１５が、依頼元に送信される（ステップＳ１００３）。

ここで、サービス検索依頼メッセージ１１４が複数のサーバノードＳｉに対する検索を指定していなければ、ステップＳ１００３の処理の終了により、そのまま図１０の検索結果通知処理を終了する。

一方、サービス検索依頼メッセージ１１４に格納されているサービス検索条件において複数のサーバノードＳｉに対する検索が指定されていれば、図１０の破線で示されるステップＳ１００４からＳ１００８までの一連の処理が実行される。

まず、サービス検索依頼メッセージ１１４からサービス検索条件が取り出される（ステップＳ１００４）。
次に、サービス検索条件のノード数が１か否かが判定される（ステップＳ１００５）。

ノード数が１であれば（ステップＳ１００６の判定がＹｅｓ）、そのまま図１０の検索結果通知処理を終了する。

ノード数が１でなければ（ステップＳ１００６の判定がＮｏ）、サービス検索依頼メッセージ１１４中のサービス検索条件が指定するサーバノードＳｉの数が１減らされる（ステップＳ１００７）。

その上で、図１１で後述する検索転送処理を起動して、そのサービス検索依頼メッセージ１１４の転送を行わせる（ステップＳ１００８）。その後、検索通知処理の制御処理を終了する。

ステップＳ１００４〜Ｓ１００８の処理により、ステップＳ１００３にて検索結果メッセージ１１５を返信した後、さらにそのサービス検索依頼メッセージ１１４を転送して、他のサーバノードＳｉに検索処理を行わせることが可能となる。

図１１は、図１の検索転送部１０９を実現する検索転送処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。

まず、サービス検索依頼メッセージ１１４の検索済リスト（検索履歴情報）（図８参照）が取り出される（ステップＳ１１０１）。

次に、経路情報ＤＢ１０７から、優先順位の高いサーバノードＳｉから順に、宛先候補が取り出される（ステップＳ１１０２）。

宛先候補があるか否かが判定される（ステップＳ１１０３）。
宛先候補があって、ステップＳ１１０３の判定がＹｅｓならば、宛先候補が、ステップＳ１１０１で取り出された検索済リスト（検索履歴情報）に含まれるか否かが判定される（ステップＳ１１０４）。

宛先候補が検索済リストに含まれてステップＳ１１０６の判定がＹｅｓならば、ステップＳ１１０２に戻って、経路情報ＤＢ１０７から次の宛先候補が取り出される。

ステップＳ１１０２〜Ｓ１１０６のループ処理により、宛先候補が検索済リストに含まれずにステップＳ１１０６の判定がＮｏになると、サービス検索依頼メッセージ１１４の依頼先（図８参照）に、宛先候補のサーバノードＳｉが設定される（ステップＳ１１０７）。

一方、ステップＳ１１０２〜Ｓ１１０６のループ処理により、宛先候補がなくなってステップＳ１１０３の判定がＮｏになると、そのサービス検索依頼メッセージ１１４を転送元のサーバノードに送り返す（バックトラックする）ために、次の処理が実行される。サービス検索依頼メッセージ１１４の依頼先に、転送元のサーバノード（検索済リストからわかる）が設定される（ステップＳ１１０５）。

ステップＳ１１０７またはＳ１１０５の処理の後、サービス検索依頼メッセージの検索済リストに自ノードが追加される（リスト数が＋１される）（ステップＳ１１０８）。

最後に、サービス検索依頼メッセージ１１４が、メッセージ送信部１０３を介して転送される（ステップＳ１１０９）。その後、検索転送処理の制御処理を終了する。

図１２は、図１の経路情報通知部１０２を実現する経路情報通知処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。

まず、Ｈｅｌｌｏメッセージ１１３のバッファが取得される。このとき、宛先アドレス（図４の４０１）にブロードキャストアドレスが設定される。また、送信元アドレス（図４の４０２）に自ノードのアドレスが設定され、メッセージ種別（後述する図１４の「ｔｙｐｅ」フィールド）に「Ｈｅｌｌｏ」が設定される（以上、ステップＳ１２０１）。

次に、自ノードの属性情報ＤＢ１０１に登録されているサービス情報が、Ｈｅｌｌｏメッセージ１１３のサービス情報（図４の４０３）に設定される。また、自ノードの属性情報ＤＢ１０１に登録されているリソース情報がＨｅｌｌｏメッセージ１１３の自ノード情報（図４の４０４）に設定される（以上、ステップＳ１２０２）。

そして、ステップＳ１２０１およびＳ１２０２により生成されたＨｅｌｌｏメッセージ１１３が、メッセージ送信部１０３に通知されて送信される（ステップＳ１２０３）。その後、図１２の経路情報通知処理を終了する。

図１３は、図１の経路情報生成部１０６を実現する経路情報生成処理を示すフローチャートである。このフローチャートは例えば、後述する図１７に示されるＣＰＵ１７０１がメモリ１７０２に記憶された制御プログラムを実行する動作として実現される。

受信されたＨｅｌｌｏメッセージ１１３のサービス情報（図４の４０３）と自ノード情報（図４の４０４）が取得され、サービス情報とリソース情報としての自ノード情報とから優先度が決定される（ステップＳ１３０１）。

次に、受信されたＨｅｌｌｏメッセージ１１３の送信元アドレス（図４の４０２）が取得される（ステップＳ１３０２）。これをＬＳとする。

次に、経路情報ＤＢ１０７が検索され、ステップＳ１３０２で取得されたＬＳに対応するレコードが存在するか否かが判定される（ステップＳ１３０３）。

ステップＳ１３０３の判定がＹｅｓならば、取得した経路情報ＤＢ１０７の優先度を、ステップＳ１３０１で決定された優先度によって更新される（ステップＳ１３０４）。その後、図１３の経路情報生成処理を終了する。

ステップＳ１３０３の判定がＮｏならば、経路情報ＤＢ１０７にステップＳ１３０２で取得されたＬＳのエントリが作成され、作成されたエントリにステップＳ１３０１で決定された優先度が設定される（ステップＳ１３０５）。その後、図１３の経路情報生成処理を終了する。

図１４は、Ｈｅｌｌｏメッセージ１１３のデータフォーマット例を示す図である。
「ｓｙｍｂｏｌ」「ｌｅｎｇｔｈ」「ｒｅｑｕｅｓｔ ｎｕｍｂｅｒ」「ｒｅｑｕｅｓｔ ｔｉｍｅ」「ｃａｔｅｇｏｒｙ」「ｔｙｐｅ」「ｓｔａｔｕｓ」および「ｏｐｔｉｏｎ」の各フィールドは、Ｈｅｌｌｏメッセージ１１３のヘッダ部を構成する。この中で特に、「ｔｙｐｅ」フィールドには、メッセージの種別として、Ｈｅｌｌｏメッセージ１１３であることを示す値が格納される。

「ａｄｄｒｅｓｓ ｌｅｎｇｔｈ」は、要求受付用のＩＰ（インターネットプロトコル）アドレスの長さを示す。「ｒｅｑｕｅｓｔ ｐｏｒｔ」は、要求受付用のポート番号を示す。「ａｄｄｒｅｓｓ」は、要求受付用のＩＰアドレスを示す。「ｏｐｔｉｏｎ」は、オプションフィールドであり、図４のサービス情報４０３、自ノード情報（リソース情報）４０４などが格納される。

図１５は、サービス検索依頼メッセージ１１４のデータフォーマット例を示す図である。
サービス検索依頼メッセージ１１４のヘッダ部は、図１４に示されるＨｅｌｌｏメッセージ１１３のヘッダ部と同じである。その場合、「ｔｙｐｅ」フィールドには、メッセージの種別として、サービス検索依頼メッセージ１１４であることを示す値が格納される。

「ｌｉｍｉｔ」は、検索件数の上限値が設定される。上限なしの場合は０が設定される。「ｒｅｓｅｒｖｅ」は、予約フィールドである。「ｑｕｅｒｙ ｌｅｎｇｔｈ」は、サービス検索条件の条件式の長さが格納される。「ｑｕｅｒｙ」は、４バイト境界でサービス検索条件の条件式が格納される。「ｋｅｙｓ」は、検索成功時に取得する属性キーのリストが格納される。「ｈｉｓｔｏｒｙ」は、転送時の通過ノードの履歴情報すなわち検索済リスト（検索履歴情報）が格納される。

図１６は、検索結果メッセージ１１５のデータフォーマット例を示す図である。
検索結果メッセージ１１５のヘッダ部は、図１４に示されるＨｅｌｌｏメッセージ１１３のヘッダ部と同じである。その場合、「ｔｙｐｅ」フィールドには、メッセージの種別として、検索結果メッセージ１１５であることを示す値が格納される。

「ｒｅｓｕｌｔ」には、検索結果（１：検出、２：検索終了、３：検索タイムアウト）が格納される。「ｈｏｐ ｃｏｕｎｔ」にはホップ数が格納される。「ｕｒｉ ｌｅｎｇｔｈ」には、ＵＲＩの長さが格納される。「ｕｒｉ」には、４バイト境界で検索結果の場所を示すＵＲＩが格納される。「ａｔｔｒ」には、要求された属性キーに対応する属性情報が格納される。

図１７は、本実施形態のシステムを実現可能なハードウェアシステムの構成図である。
図１７は、上記システムをソフトウェア処理として実現できるコンピュータのハードウェア構成の一例を示す図である。

図１７に示されるコンピュータは、ＣＰＵ１７０１、メモリ１７０２、入力装置１７０３、出力装置１７０４、外部記憶装置１７０５、可搬記録媒体１７０９が挿入される可搬記録媒体駆動装置１７０６、及び通信インタフェース１７０７を有し、これらがバス１７０８によって相互に接続された構成を有する。同図に示される構成は上記システムを実現できるコンピュータの一例であり、そのようなコンピュータはこの構成に限定されるものではない。

ＣＰＵ１７０１は、当該コンピュータ全体の制御を行う。メモリ１７０２は、プログラムの実行、データ更新等の際に、外部記憶装置１７０５（或いは可搬記録媒体１７０９）に記憶されているプログラム又はデータを一時的に格納するＲＡＭ等のメモリである。ＣＵＰ１７０１は、プログラムをメモリ１７０２に読み出して実行することにより、全体の制御を行う。

入出力装置１７０３、１７０４は、ユーザによるキーボードやマウス等による入力操作を検出し、その検出結果をＣＰＵ１７０１に通知し、ＣＰＵ１７０１の制御によって送られてくるデータを表示装置や印刷装置に出力する。

外部記憶装置１７０５は、例えばハードディスク記憶装置である。主に各種データやプログラムの保存に用いられる。

可搬記録媒体駆動装置１７０６は、光ディスクやＳＤＲＡＭ、コンパクトフラッシュ（登録商標）等の可搬記録媒体１７０９を収容するもので、外部記憶装置１７０５の補助の役割を有する。

通信インタフェース１７０７は、例えばＬＡＮ（ローカルエリアネットワーク）又はＷＡＮ（ワイドエリアネットワーク）の通信回線を接続するための装置である。

本実施形態によるシステムは、図１に示される各機能または図９〜図１３のフローチャート等で実現される機能を搭載したプログラムをＣＰＵ１７０１が実行することで実現される。そのプログラムは、例えば外部記憶装置１７０５や可搬記録媒体１７０９に記録して配布してもよく、或いはネットワーク接続装置１７０７によりネットワークから取得できるようにしてもよい。

１００、Ｓｉ サーバノード
１０１ 属性情報ＤＢ（データベース）
１０２ 経路情報通知部
１０３ メッセージ送信部
１０４ メッセージ受信部
１０５ メッセージ振分け部
１０６ 経路情報生成部
１０７ 経路情報ＤＢ（データベース）
１０８ 検索判定部
１０９ 検索転送部
１１０ 検索結果通知部
１１１ サービス登録部
１１２ ノード情報監視部
１１３ Ｈｅｌｌｏメッセージ
１１４ サービス検索依頼メッセージ
１１５ 検索結果メッセージ
２０１、３０１ サブネット
４０１ 宛先アドレス
４０２ 送信元アドレス
４０３ サービス情報
４０４ 自ノード情報
Ｃｊ クライアントノード
ＳＸ サービス検索サーバノード
１７０１ ＣＰＵ
１７０２ メモリ
１７０３ 入力装置
１７０４ 出力装置
１７０５ 外部記憶装置
１７０６ 可搬記録媒体駆動装置
１７０７ 通信インタフェース
１７０８ バス
１７０９ 可搬記録媒体

Claims (5)

1. サーバの属性情報を他のサーバとの間で交換することにより経路情報を生成し、サービス検索依頼元からサービス検索依頼を受信したときに、前記サーバの属性情報を参照することにより、前記サーバが前記サービス検索依頼におけるサービス検索条件に適合するか否かを判定し、適合しないと判定した場合に、前記サービス検索依頼に付加されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サーバの情報を前記検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送し、適合すると判定した場合に、前記サービス検索依頼に付加されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サービス検索条件が指定するサーバの数を１減らすとともに前記サーバの情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送する、
   ことを備えることを特徴とする分散処理におけるサービス検索方法。
2. 前記経路情報を生成するときに、前記交換した属性情報に基づいて計算したサービス検索の優先度を前記経路情報に付加し、
   前記サービス検索依頼を転送するときに、前記経路情報に含まれる優先度が高いサーバを選択する、
   ことを備えることを特徴とする請求項１に記載の分散処理におけるサービス検索方法。
3. 前記属性情報はサービス情報とリソース情報を含み、
   前記サービス情報の登録または削除を行い、
   前記サーバのリソースを監視し、前記監視の結果に基づいて前記リソース情報を更新する、
   ことをさらに備えることを特徴とする請求項１または２のいずれかに記載の分散処理におけるサービス検索方法。
4. サーバに、
   サービス情報とリソース情報を含む前記サーバの属性情報を他のサーバとの間で交換することにより経路情報を生成する機能と、
   サービス検索依頼を受信したときに、前記サーバの前記属性情報を参照することにより、前記サーバが前記サービス検索依頼におけるサービス検索条件に適合するか否かを判定する機能と、
   適合しないと判定した場合に、前記サービス検索依頼に格納されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サーバの情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送する機能と、
   適合すると判定した場合に、前記サービス検索依頼に付加されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サービス検索条件が指定するサーバの数を１減らすとともに前記サーバの情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送する機能と、
   を実行させるためのプログラム。
5. サーバ装置であって、
   サービス情報とリソース情報を含む前記サーバ装置の属性情報を他のサーバとの間で交換することにより経路情報を生成する経路情報生成部と、
   サービス検索依頼を受信したときに、前記サーバ装置の前記属性情報を参照することにより、前記サーバ装置が前記サービス検索依頼におけるサービス検索条件に適合するか否かを判定する検索判定部と、
   適合しないと前記検索判定部が判定した場合に、前記サービス検索依頼に付加されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サーバ装置の情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送し、
   適合すると前記検索判定部が判定した場合に、前記サービス検索依頼に付加されている検索履歴情報に検索実績がないサーバを前記経路情報に基づいて選択し、前記サービス検索条件が指定するサーバの数を１減らすとともに前記サーバ装置の情報を検索履歴情報として付加した前記サービス検索依頼を前記選択したサーバに転送する
   転送検索部と、
   を備えることを特徴とするサーバ装置。

Images