JP2015179510A - サービス指向アーキテクチャ（ｓｏａ）ネットワークにおけるサービスの発見 - Google Patents

Abstract

【課題】ＳＯＡ（サービス指向アーキテクチャ）ネットワーク内のサービスを見つけるための方法を提供する。【解決手段】、ローカルサービスレジストリ（ＳＲ）においてクライアントから特定のサービスについての検索クエリを受信する。ローカルＳＲは、ローカルＳＲに登録されたサービスを列挙するローカルＤＢを含む。ローカルＳＲは、ＳＲのネットワーク内にある。サービスを見つける方法は、ローカルＤＢに問い合わせて、検索クエリを満たすサービスの第１のリストを決定することと、検索される特定のサービスの属性以外の属性に基づいて、ＳＲのネットワーク内の近隣ＳＲを判定することと、を含む。方法は、近隣ＳＲへ検索クエリを送信することと、近隣ＳＲに登録された、検索クエリを満たすサービスの第２のリストを、近隣ＳＲから受信することと、第１のリスト及び第２のリストをクライアントに返すことを含む。【選択図】図８

Description

この開示は、概して、サービス指向アーキテクチャ（service oriented architecture：ＳＯＡ）ネットワークにおけるサービスの発見に関する。

サービス指向アーキテクチャ（ＳＯＡ）は、サービスとして他のアプリケーションにアプリケーションの機能性を提供するソフトウェアのユニットに基づくソフトウェアデザイン及びソフトウェアアーキテクチャデザインの方法論である。サービスは、機能性のユニットである。サービスは、他のソフトウェアアプリケーションにより結合され、より大きなソフトウェアアプリケーションの完全な機能性を提供することができる。ＳＯＡは、ネットワークを通じて接続されるコンピュータが協力することをより容易にする。

一実施形態では、方法は、（ａ）ローカルサービスレジストリにおいてクライアントから特定のサービスについての検索クエリを受信すること、を含み得る。この実施形態では、上記ローカルサービスレジストリは、上記ローカルサービスレジストリに登録されたサービスを列挙するローカルデータベースを含む。上記ローカルサービスレジストリは、サービスレジストリのネットワーク内にある。上記方法は、（ｂ）上記ローカルデータベースに問い合わせて、上記検索クエリを満たすサービスの第１のリストを決定すること、を含み得る。上記方法は、（ｃ）上記特定のサービスの属性以外の属性に基づいて、サービスレジストリの上記ネットワーク内の近隣サービスレジストリであって、上記ローカルサービスレジストリの近隣にある上記近隣サービスレジストリを判定すること、を含み得る。上記方法は、（ｄ）上記近隣サービスレジストリへ上記検索クエリを送信すること、を含み得る。この実施形態では、上記近隣サービスレジストリは、上記近隣サービスレジストリに登録されたサービスを列挙する近隣データベースを含む。上記方法は、（ｅ）上記近隣サービスレジストリに登録された、上記検索クエリを満たすサービスの第２のリストを、上記近隣サービスレジストリから受信すること、を含み得る。上記方法は、（ｆ）上記検索クエリを満たすサービスの上記第１のリスト及び上記第２のリストを上記クライアントに返すこと、を含み得る。この実施形態の見込まれる利点のいくつかは、次のパラグラフで説明される。

一実施形態では、サービスレジストリは上記ネットワーク内の装置間で分散しており、上記サービスレジストリは同一でなくてもよい。このケースでは、サービスは、ローカルサービスレジストリに登録され得る。そのように、サービスレジストリは、上記ネットワーク内の全てのサービスに気付いていなくてもよいが、ローカルサービスに氣づき得る。上記ローカルサービスレジストリが、上記検索クエリを満たすことができない場合には、上記クエリは、近くのサービスレジストリ（例えば、上記ローカルサービスレジストリの近くの１つ以上の近隣サービスレジストリ）へ転送されることが可能である。見込まれる利点として、この実施形態は、（上記ネットワーク内の装置間で分散されない中央のサービスレジストリとは対照的に）より卓越した耐障害性（fault tolerance）を提供し得る。他の見込まれる利点として、この実施形態は、（上記ネットワーク内の装置において単に複製されたサービスレジストリとは対照的に）同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、（潜在的に）高い耐障害性及び低いネットワークトラフィックを伴う効率的な手法でサービスを検索し、見つけることを可能にし得る。他の見込まれる利点は、特定のサービスを検索する場合に、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。

上述したように、一実施形態では、特定のサービスについての検索要求（クエリ）は、上記ネットワーク内の近隣サービスレジストリへ転送され得る。近隣ノードは、検索される上記特定のサービスの属性以外の属性に基づいて判定される。例えば、データストレージサービスについての要求は、ネットワークレイテンシ（例えば、データストレージ以外の属性）に基づいて近隣サービスレジストリへ転送され得る。見込まれる利点として、この手法で近隣ノードを選択することは、ローカルで提供されないサービスを迅速に見つけることを可能にし得る。

一実施形態では、上記特定のサービスの上記属性は、特定の属性であり、上記検索クエリは、上記特定のサービスと、上記特定のサービスの上記特定の属性とを識別する。この実施形態では、上記方法は、上記特定の属性以外の属性に基づいて上記近隣サービスレジストリを判定することを含む。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。他の見込まれる利点は、特定のサービスを検索する場合に、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。

他の実施形態では、上記方法は、複数の属性に基づいて上記近隣サービスレジストリを判定することを含む。上記複数の属性は、上記特定のサービスの属性ではなく、上記複数の属性の各々は、重み付けされる。この実施形態の利点は、上記特定のサービスの属性ではない１つ以上の属性を検索が考慮することを可能にする。属性を重み付けすることは、異なる重みを与えながら異なる属性を使用するという利点を提供し得る。

他の実施形態では、上記検索クエリは、データストレージとして上記特定のサービスを示す。上記サービスの上記属性以外の上記属性は、帯域幅、地理的な位置、開放チャネル、レイテンシ、マルチキャストキャパシティ、ホップ数、コスト又はネットワークタイプを含む。

一実施形態では、サービスレジストリの上記ネットワークは、サービスレジストリのツリーネットワークである。他の実施形態では、サービスレジストリの上記ネットワークは、サービスレジストリのメッシュネットワークである。ツリーネットワーク及びメッシュネットワークの見込まれる利点は、それぞれサービスを並列で（且つ潜在的には効率的な手法で）検索することを可能にするということである。ツリーネットワークの見込まれる利点は、（メッシュネットワークと比べて）ツリーネットワークはネットワークトラフィックを減らし得るということ（例えば、より少ない検索及びより少ないマッチング結果）である。メッシュネットワークの見込まれる利点は、（ツリーネットワークと比べて）メッシュネットワークはより速くより並列であり得るということである。

一実施形態では、上記方法は、また、（ｇ）上記近隣サービスレジストリにおいて上記検索クエリを受信することと、（ｈ）上記近隣サービスレジストリに問い合わせて、上記検索クエリを満たすサービスの上記第２のリストを決定することと、（ｉ）上記第２のリストを上記ローカルサービスレジストリへ送信することと、を含み得る。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。

一実施形態では、上記近隣サービスレジストリは、要求するサービスレジストリである。この実施形態では、上記方法は、（ｊ）サービスの上記第２のリストが十分であるかを判定することを含む。サービスの上記第２のリストが十分ではない場合に、上記方法は、上記特定のサービスの上記属性以外の上記属性に基づいて、サービスレジストリの上記ネットワーク内の他の近隣サービスレジストリであって、上記要求するサービスレジストリの近隣にある上記他の近隣サービスレジストリを判定すること、を含み得る。サービスの上記第２のリストが十分ではない場合に、上記方法は、上記他の近隣サービスレジストリに登録されたサービスを列挙する他の近隣データベースを含む上記他の近隣サービスレジストリへ、上記検索クエリを送信すること、を含み得る。サービスの上記第２のリストが十分ではない場合に、上記方法は、上記他の近隣サービスレジストリに登録された、上記検索クエリを満たすサービスの他のリストを、上記他の近隣サービスレジストリから受信すること、を含み得る。上記第２のリストは、上記他のリストを含む。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。例えば、結果が十分な場合に、さらなる近隣ノードへ上記クエリを必ずしも送信する必要もなく、検索は停止し得る。

一実施形態では、上記方法は、次に続く（successive）他のノードにおいて要素（ｊ）を繰り返すことを含む。見込まれる利点として、この実施形態は、結果が十分になるまで上記クエリが上記ネットワークを通じて伝わることを可能にする。

本明細書では、システムも説明される。上記システムは、装置を含み得る。当該装置は、ローカルサービスレジストリに登録されたサービスを列挙するローカルデータベースを記憶するメモリを含む。この実施形態では、上記ローカルサービスレジストリは、サービスレジストリのネットワーク内にある。上記装置は、クライアントから特定のサービスについての検索クエリを受信するプロセッサも含み得る。この実施形態では、上記プロセッサは、また、上記ローカルデータベースに問い合わせて、上記検索クエリを満たすサービスの第１のリストを決定し、上記特定のサービスの属性以外の属性に基づいて、サービスレジストリの上記ネットワーク内の近隣サービスレジストリであって、上記ローカルサービスレジストリの近隣にある上記近隣サービスレジストリを判定し得る。この実施形態では、上記装置は、上記近隣サービスレジストリへ上記検索クエリを送信する送信機を含む。このケースでは、上記近隣サービスレジストリは、上記近隣サービスレジストリに登録されたサービスを列挙する近隣データベースを含む。この実施形態における上記装置は、上記近隣サービスレジストリに登録された、上記検索クエリを満たすサービスの第２のリストを、上記近隣サービスレジストリから受信する受信機、も含み得る。上記プロセッサは、上記検索クエリを満たすサービスの上記第１のリスト及び上記第２のリストを、上記クライアントに返す。この実施形態の見込まれる利点のいくつかは、次のパラグラフで説明される。

一実施形態では、サービスレジストリは上記ネットワーク内の装置間で分散しており、上記サービスレジストリは同一でなくてもよい。このケースでは、サービスは、ローカルサービスレジストリに登録され得る。そのように、サービスレジストリは、上記ネットワーク内の全てのサービスに気付いていなくてもよいが、ローカルサービスに氣づき得る。上記ローカルサービスレジストリが、上記検索クエリを満たすことができない場合には、上記クエリは、近くのサービスレジストリ（例えば、上記ローカルサービスレジストリの近くの１つ以上の近隣サービスレジストリ）へ転送されることが可能である。見込まれる利点として、この実施形態は、（上記ネットワーク内の装置間で分散されない中央のサービスレジストリとは対照的に）より卓越した耐障害性（fault tolerance）を提供し得る。他の見込まれる利点として、この実施形態は、（上記ネットワーク内の装置において単に複製されたサービスレジストリとは対照的に）同期のためのネットワークトラフィックを減らし得る。他の見込まれる利点として、この実施形態は、（潜在的に）高い耐障害性及び低いネットワークトラフィックを伴う効率的な手法でサービスを検索し、見つけることを可能にし得る。他の見込まれる利点は、特定のサービスを検索する場合に、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。

上述したように、一実施形態では、特定のサービスについての検索要求（クエリ）は、上記ネットワーク内の近隣サービスレジストリへ転送され得る。近隣ノードは、検索される上記特定のサービスの属性以外の属性に基づいて判定される。例えば、データストレージサービスについての要求は、ネットワークレイテンシ（例えば、データストレージ以外の属性）に基づいて近隣サービスレジストリへ転送され得る。見込まれる利点として、この手法で近隣ノードを選択することは、ローカルで提供されないサービスを迅速に見つけることを可能にし得る。

一実施形態では、上記特定のサービスの上記属性は、特定の属性であり、上記検索クエリは、上記特定のサービスと、上記特定のサービスの上記特定の属性とを識別する。この実施形態では、上記プロセッサは、上記特定の属性以外の属性に基づいて、上記近隣サービスレジストリを判定し得る。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。他の見込まれる利点は、特定のサービスを検索する場合に、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。

一実施形態では、上記プロセッサは、上記プロセッサは、複数の属性に基づいて上記近隣サービスレジストリを判定する。上記複数の属性は、上記特定のサービスの属性ではない。上記プロセッサは、上記複数の属性の各々を重み付けする。この実施形態の利点は、上記特定のサービスの属性ではない１つ以上の属性を検索が考慮することを可能にする。属性を重み付けすることは、異なる重みを与えながら異なる属性を使用するという利点を提供し得る。

一実施形態では、上記検索クエリは、データストレージとして上記特定のサービスを示す。上記サービスの上記属性以外の上記属性は、帯域幅、地理的な位置、開放チャネル、レイテンシ、マルチキャストキャパシティ、ホップ数、コスト又はネットワークタイプを含む。

一実施形態では、サービスレジストリの上記ネットワークは、サービスレジストリのツリーネットワークである。他の実施形態では、サービスレジストリの上記ネットワークは、サービスレジストリのメッシュネットワークである。ツリーネットワーク及びメッシュネットワークの見込まれる利点は、それぞれサービスを並列で（且つ潜在的には効率的な手法で）検索することを可能にするということである。ツリーネットワークの見込まれる利点は、（メッシュネットワークと比べて）ツリーネットワークはネットワークトラフィックを減らし得るということ（例えば、より少ない検索及びより少ないマッチング結果）である。メッシュネットワークの見込まれる利点は、（ツリーネットワークと比べて）メッシュネットワークはより速くより並列であり得るということである。

上記システムは、他の装置をさらに含み得る。上記他の装置は、上記近隣データベースを記憶するメモリを含み得る。上記他の装置は、上記検索クエリを受信する受信機と、上記近隣データベースに問い合わせて、上記検索クエリを満たすサービスの第２のリストを決定するプロセッサと、を含み得る。上記他の装置は、上記ローカルサービスレジストリへ上記第２のリストを送信する送信機を含み得る。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。

一実施形態では、上記近隣サービスレジストリは、要求するサービスレジストリである。この実施形態では、上記他の装置内の上記プロセッサは、サービスの上記第２のリストが十分であるかを判定する。上記プロセッサは、また、サービスの上記第２のリストが十分ではない場合に、上記特定のサービスの上記属性以外の上記属性に基づいて、サービスレジストリの上記ネットワーク内の他の近隣サービスレジストリであって、上記要求するサービスレジストリの近隣にある上記他の近隣サービスレジストリを判定し得る。上記プロセッサは、また、上記他の近隣サービスレジストリに登録されたサービスを列挙する他の近隣データベースを含む上記他の近隣サービスレジストリへ、上記検索クエリを送信し得る。上記受信機は、上記他の近隣サービスレジストリに登録された、上記検索クエリを満たすサービスの他のリストを、上記他の近隣サービスレジストリから受信し得る。上記第２のリストは、上記他のリストを含む。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。例えば、結果が十分な場合に、さらなる近隣ノードへ上記クエリを必ずしも送信する必要もなく、検索は停止し得る。

上記システムは、上記他の装置のように、上記検索クエリを満たすサービスを引き続き検索するように構成されるメモリ、受信機、プロセッサ及び送信機を含む追加の装置も含み得る。見込まれる利点として、この実施形態は、結果が十分になるまで上記クエリが上記ネットワークを通じて伝わることを可能にする。

別の実施形態では、方法は、特定のサービスに対応するサービスレジストリのネットワークのトポロジを決定することを含み得る。この実施形態では、上記サービスレジストリの各々は、対応するサービスレジストリに登録されたサービスのインスタンスを列挙する。上記トポロジを決定することは、サービスレジスタの各々について、上記特定のサービスの属性以外の属性に基づいて１つ以上の近隣サービスレジストリを判定することを含み得る。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。

サービスレジストリのネットワークトポロジは、複数のノードのネットワーク上のオーバレイネットワークであり得る。そのような実施形態では、上記方法は、上記サービスレジストリについての複数のトポロジであって、異なる特定のサービスに各々対応する当該複数のトポロジを決定することを含み得る。見込まれる利点として、当該トポロジに従って次に続く近隣ノードに問い合わせることは、ローカルで提供されないサービスを迅速に見つけることを可能にし得る。

異なるトポロジは、異なる見込まれる利点を有し得る。例えば、上記ネットワークのツリートポロジ及びメッシュトポロジの両方の１つの見込まれる利点は、それぞれ並列にサービスを検索することを可能にするということである。ツリートポロジの見込まれる利点は、（メッシュネットワークと比べて）ツリートポロジはネットワークトラフィックを減らし得るということである。メッシュトポロジの見込まれる利点は、（ツリーネットワークと比べて）メッシュトポロジはより速くより並列であり得るということである。さらに、１つの見込まれる利点は、検索される上記特定のサービスに基づいて好適な又は最良のトポロジ（ツリー、メッシュ、又はその他）が選択され得るということである。

後述される１つ以上の実施形態に従った例示的な環境を説明するブロック図である。 図１の装置の例示的なコンポーネントを説明するブロック図である。 図１の装置の例示的な機能レイヤを説明するブロック図である。 図３のサービスレイヤの例示的な機能コンポーネントを説明するブロック図である。 図４Ａのサービスレジストリの機能性を説明するためのブロック図である。 図４Ａのサービスレジストリの例示的な機能コンポーネントを説明するブロック図である。 特定のサービスについての例示的な属性テーブルのブロック図である。 図３のオーバレイネットワークレイヤの機能コンポーネントを説明するブロック図である。 例示的な機能オーバレイネットワークのツリーのブロック図である。 ネットワークの例示的なトポロジのブロック図である。 ネットワークの例示的なトポロジのブロック図である。 一実施形態におけるネットワークのトポロジを決定するための例示的なプロセスのフローチャートである。 特定のサービスの属性以外の属性を決定するためのプロセスのフローチャートである。 サービスを検索するための例示的なプロセスのフローチャートである。

以下の詳細な説明は、添付の図面を参照する。異なる図面における同一の参照番号は、同一の又は同様の要素を識別する。

以下に説明するように、装置のネットワークは、ネットワークを通じて通信し得るし、一連の様々なサービスを提供するシステムの一部を形成し得る。異なる装置は、異なる時間に異なるサービスを提供し得る。システムは、好ましくは効率的で且つ信頼性の高い手法で、特定のサービスを提供する装置を探し、又は検索する必要があり得る（例えば技術的問題を導入する）。

異なる装置により提示されるサービスを発見する問題を解決するために、装置は、提示されるサービスをサービスレジストリ内に登録し得る。一解決策／一実施形態では、上記サービスレジストリは、ネットワーク内で集中させられ得る。そのような解決策／実施形態では、ネットワーク内の全てのサービスが、中央のサービスレジストリ内に登録される。１つの中央のサービスレジストしかないので、当該１つの中央のサービスレジストリは常に同期し、維持するのが相対的に容易である。しかしながら、中央のサービスレジストは、単一障害点（single point of failure）を作る（即ち、他の技術的問題）。即ち、上記中央のサービスレジストリに障害が起こると、サービスは、見つけるのが不可能でなければ困難であり得る。さらに、中央のサービスレジストリは、良好にスケーリングしない（別の技術的問題）。即ち、ネットワークが急激に成長する場合に、サービスレジストリの処理スピード及び利用可能な帯域幅も急激に成長する。

一解決策／実施形態では、サービスレジストリは、ネットワーク内の装置間で分散され得る（例えば、レジストリの完全なコピーが複製され得る）。この解決策／実施形態は、集中されたサービスレジストリを超えてさらなる耐障害性を可能にする。一方、ネットワークが成長すると、装置間でのレジストリの同期がますます困難になり、ネットワークトラフィックが問題点になり得る（即ち、他の技術的問題）。

さらに別の解決策／実施形態では、サービスレジストリは、ネットワーク内の装置間で分散されるが、サービスレジストリは同一ではないかもしれない。この実施形態では、サービスは、ローカルサービスレジストリに登録され得る。サービスレジストリは、ネットワーク内の全てのサービスに気づかなくてもよいが、ローカルサービスに氣づき得る。よって、ローカルに提供されていないサービスを見つけることは、難題をもたらし得る（即ち、技術的問題）。ネットワーク内のサービスを見つけるために、この解決策／実施形態は、（サービスを探す）クライアントに、ローカルサービスレジストリにサービスを要求すること（例えば、ローカルサービスレジストリにクエリを送信すること）を可能にする。ローカルサービスレジストリが要求を満たせない場合には、当該要求は、近くのサービスレジストリ（例えば、上記ローカルサービスレジストリの近くの１つ以上の近隣サービスレジストリ）へ転送されることが可能である。このソリューション／実施形態は、（中央のサービスレジストリとは対照的に）卓越した耐障害性を可能にし（例えば、見込まれる利点）、（完全に分散されたサービスレジストリとは対照的に）同期のためのネットワークトラフィックを減らす（例えば、他の見込まれる利点）。一解決策／一実施形態では、特定のサービスについての検索要求（クエリ）は、ネットワーク内の近隣サービスレジストリへ転送され得る。当該近隣ネットワークノードは、検索される上記特定のサービスの属性以外の属性に基づいて選択される。例えば、データストレージサービスについての要求が、ネットワーク遅延（例えば、データストレージ以外の属性）に基づいて近隣サービスレジストリへ転送され得る。この解決策／実施形態に従って近隣ノードを選択することは、ローカルで提供されないサービスを迅速に見つけることを可能にし得る（例えば、他の見込まれる利点）。他の見込まれる利点は、特定のサービスを検索するために、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。

図１は、説明されたシステム及び／又は方法が実装されることが可能である例示的な環境１００のブロック図である。図１の実施形態に示されるように、環境１００は、ネットワーク１１０、サブネットワーク１２０−Ａ〜１２０−Ｎ（集合で「サブネットワーク１２０」と呼ばれ、また、個別に「サブネットワーク１２０」と呼ばれる）、装置１３０Ａ−Ａ〜１３０Ｎ−Ｋ（集合で「装置１３０」と呼ばれ、個別に「装置１３０」と呼ばれる）、及び管理装置１５０を含む。装置１３０−Ｎ−Ｋは、サブネットワーク１２０−Ｎ内のＫ番目の装置１３０に言及する。この実施形態では、環境１００内のコンポーネントは、サービス指向アーキテクチャ（ＳＯＡ）システムサービスバス１４０を形成する。

ネットワーク１１０は、サブネットワーク１２０及び／又は装置１３０が互いに通信することを可能にする。ネットワーク１１０は、１つ以上の回線交換ネットワーク及び／又はパケット交換ネットワークを含み得る。例えば、一実施形態では、ネットワーク１１０は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、メトロポリタンエリアネットワーク（ＭＡＮ）、公衆回線電話網（ＰＳＴＮ）、アドホックネットワーク、イントラネット、インターネット、光ファイバネットワーク、無線ネットワーク、及び／又は、これらの若しくは他のタイプのネットワークの組合せを含む。

サブネットワーク１２０は、ＬＡＮ（例えば、レイヤ２ネットワーク）及び／又はプライベートネットワーク（例えば、レイヤ３ネットワーク）を含み得る。サブネットワーク１２０は、１つ以上の装置１３０を相互接続させ得る。例えば、サブネットワーク１２０−Ａは、装置１３０−Ａ−Ａ〜１３０−Ａ−Ｊを相互接続させ得る。装置１３０は、例えば、ＳＯＡシステムサービスバス１４０を介して通信するいずれかの装置を含み得る。

装置１３０は、ＰＨＰ（Hypertext Preprocessor）サーバ装置、Ｃプログラムサーバ装置、リナックスサーバ装置、ウィンドウズサーバ装置及び／若しくは他のタイプのサーバ装置などのサーバコンピュータ装置； ウィンドウズ、リナックス、アンドロイド、ｉＯＳ及び／又は他のオペレーティングシステムを実行するデスクトップ、ラップトップ、タブレット、携帯通信装置及び／若しくは他のタイプのパーソナルコンピュータ装置などのパーソナルコンピュータ装置； 可視光カメラ、赤外線（ＩＲ）カメラ及び／若しくは熱紋（heat signature）カメラなどの監視装置（monitoring device）； マイクロフォン、モーションセンサ、熱センサ、圧力センサ及び／若しくは他のタイプのアラームセンサなどのアラームセンサ； マイクロコントローラコンピュータ装置； 並びに／又は、他のタイプのコンピュータ装置を含み得る。装置１３０は、サブネットワーク１２０に接続されているように示されているが、特定の装置１３０は、ネットワーク１１０に直接的に接続されていなくてもよい。

一実施形態では、ＳＯＡシステムサービスバス１４０は、既存のネットワークトポロジの上に装置１３０間で実装される。ＳＯＡシステムサービスバス１４０は、異なるタイプの装置１３０、及び／又は異なるプラットフォームを使用して実装された装置１３０が、サービス指向アーキテクチャを使用して通信することを可能にする。ＳＯＡシステムサービスバス１４０は、第１の装置１３０がいずれかの装置１３０（例えば、それ自身又は他の装置１３０）に特定のサービスを要求することを可能にし得る。よって、第１の装置１３０により提供されるクライアント（例えば、それ自体「サービス」又は「クライアントサービス」）は、（例えば、サービスが第１の装置１３０において利用可能でない場合に）第２の装置１３０により提供されるサービスを求め得る。（例えば、第２の装置１３０における）他のサービスを要求する（例えば第１の装置１３０における）第１のサービスは、要求を開始したので、「クライアント」又は「クライアントサービス」と呼ばれる。上記第１のサービスは、例えば、ネットワーク内の他のサービスへサービスを提供してもよい。

一実施形態では、サービスは、標準化されたサービスインタフェースを介してアクセスされる。各タイプのサービスは、特定のサービスインタフェース（例えば、異なるサービスインタフェース）に関連付けられ得る。よって、サービスを要求するクライアントは、サービスインタフェースを用いて通信し得る。また、上記クライアントは、上記サービスの実際の実装について非依存（agnostic）であり得る。換言すると、各実装が他の実装に関係していなくてもよいように、サービスの実装は、サービスインタフェースにより定義されるプロトコルを使用して互いに通信する。特定のサービスインタフェースに関連付けられている、実行しているサービスの実装は、サービスインスタンスと呼ばれ得る。サービスホスト（例えば、サービスを提供する装置）を含む装置１３０は、サービスレジストリ（例えば、サービスのリスト又はデータベース）を用いて、利用可能なサービスインスタンスを記録し得る。ＳＯＡシステムサービスバス１４０は、装置１３０内のサービスホストのサービスレジストリを検索することにより、要求されたサービス見つけることを、装置１３０の通信に可能にし得る。

管理装置１５０は、管理者がＳＯＡシステムサービスバス１４０を構成し又は管理することを可能にし得る。例えば、管理装置１５０は、ポータブル通信装置（例えば、携帯電話、スマートフォン、ファブレット装置、ＧＰＳ（Global Positioning System）装置、及び／若しくは他のタイプの無線装置）； パーソナルコンピュータ若しくはワークステーション； サーバ装置； ラップトップ、タブレット若しくは他のタイプのポータブルコンピュータ； 及び／又は通信ケイパビリティを有するいずれかのタイプの装置を含み得る。

ネットワーク１１０のように、サブネットワーク１２０は、１つ以上の回線交換ネットワーク及び／又はパケット交換ネットワークを含み得る。例えば、サブネットワーク１２０は、ＬＡＮ、ＷＬＡＮ、ＭＡＮ、ＰＳＴＮ、アドホックネットワーク、イントラネット、インターネット、光ファイバネットワーク、無線ネットワーク、及び／又は、これらの若しくは他のタイプのネットワークの組合せを含み得る。

図１は、環境１００の例示的なコンポーネントを示すが、他の実装では、環境１００は、図１に描かれたものと比べて、より少ないコンポーネント、異なるコンポーネント、異なるように配置されたコンポーネント、又は追加のコンポーネントを含んでもよい。さらに、又は、あるいは、環境１００内のいずれか１つの装置（又は装置のいずれかのグループ）は、環境１００内の１つ以上の他の装置により行うように説明された機能を行ってもよい。

図２は、装置１３０の例示的なコンポーネントを説明するブロック図である。図２に示されるように、装置１３０は、バス２１０、プロセッサ２２０、メモリ２３０、入力装置２４０、出力装置２５０及び通信インタフェース２６０を含み得る。

バス２１０は、装置１２０のコンポーネント間の通信を可能にするパスを含み得る。プロセッサ２２０は、命令を解釈し実行するいずれかのタイプのシングルコアプロセッサ、マルチコアプロセッサ、マイクロプロセッサ、ラッチベースのプロセッサ、及び／若しくは処理ロジック（又はプロセッサ、マイクロプロセッサ及び／若しくは処理ロジックのファミリー）を含み得る。他の実施形態では、プロセッサ２２０は、ＡＳＩＣ（Application-Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）、及び／又は、他のタイプの集積回路若しくは処理ロジックを含んでもよい。

メモリ２３０は、プロセッサ２２０による実行のための情報及び／若しくは命令を記憶し得るいずれかのタイプの揮発性及び／若しくは動的ストレージ装置、並びに／又は、プロセッサ２２０による使用のための情報を記憶し得るいずれかのタイプの不揮発性ストレージ装置を含み得る。例えば、メモリ２３０は、ランダムアクセスメモリ（ＲＡＭ）若しくは他のタイプの動的ストレージ装置、リードオンリメモリ（ＲＯＭ）装置若しくは他のタイプの静的ストレージ装置、連想メモリ（content addressable memory：ＣＡＭ）、磁気及び／若しくは光学記録メモリ装置及びその対応装置（例えば、ハードディスクドライブ、光学ドライブなど）、並びに／又は、フラッシュメモリなどの取り外し可能な形式のメモリを含み得る。

入力装置２４０は、オペレータが装置１３０に情報を入力することを可能にする。例えば、入力装置２４０は、キーボード、マウス、ペン、マイクロフォン、リモートコントローラ、音声キャプチャ装置、イメージ及び／若しくはビデオキャプチャ装置、タッチスクリーンディスプレイ、並びに／又は他のタイプの入力装置を含み得る。一実施形態では、装置１３０は、遠隔で管理されてもよく、入力装置２４０を含まなくてもよい。換言すると、装置１３０は、「ヘッドレス」であってもよく、例えばキーボードを含まなくてもよい。

出力装置２５０は、装置１３０のオペレータへの情報を出力し得る。出力装置２５０は、ディスプレイ、プリンタ、スピーカ及び／又は他のタイプの出力装置を含み得る。例えば、装置１３０は、ディスプレイを含んでもよく、当該ディスプレイは、顧客にコンテンツを表示するためのＬＣＤ（Liquid Crystal Display）を含んでもよい。一実施形態では、装置１３０は、遠隔で管理されてもよく、出力装置２５０を含まなくてもよい。換言すると、装置１３０は、「ヘッドレス」であってもよく、例えばディスプレイを含まなくてもよい。

通信インタフェース２６０は、装置１３０が他の装置及び／又はシステムと通信することを可能にする送受信機（例えば、送信機及び／又は受信機）を含み得る。通信インタフェース２６０は、無線通信（例えば、高周波（Radio Frequency）、赤外線、及び／又は可視光など）、有線通信（例えば、導線、ツイストペアケーブル、同軸ケーブル、伝送線、光ファイバケーブル、及び／又は導波管など）、又は、有線通信及び無線通信の組合せを介して、通信し得る。通信インタフェース２６０は、ベースバンド信号を高周波（ＲＦ）信号に変換する送信機、及び／又は、ＲＦ信号をベースバンド信号に変換する受信機を含み得る。通信インタフェース２６０は、信号を送受信するためのアンテナに結合され得る。

通信インタフェース２６０は、入力ポート及び／若しくは出力ポート、入力システム及び／若しくは出力システム、並びに／若しくは、他の装置へのデータの送信を容易にする他の入出力コンポーネントを含む、論理的なコンポーネントを含み得る。例えば、通信インタフェース２６０は、無線通信のためのネットワークインタフェースカード（例えば、イーサネットカード）、及び／又は、無線通信のための無線ネットワークインタフェース（例えば、Ｗｉ−Ｆｉ）カードを含み得る。通信インタフェース２６０は、ケーブルを通じた通信のためのＵＳＢ（Universal Serial Bus）ポート、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線インタフェース、ＲＦＩＤ（Radio-Frequency Identification）インタフェース、ＮＦＣ（Near-Field Communication）無線インタフェース、及び／又は、１つの形式から他の形式へデータを変換する他のタイプのインタフェースも含み得る。

以下に説明するように、装置１３０は、ＳＯＡネットワーク内のサービス（例えば、近くのサービス）を見つけることに関するある動作を行い得る。装置１３０は、メモリ２３０などのコンピュータに読み取り可能な媒体に含まれるソフトウェア命令をプロセッサ２２０が実行するのに応じて、これらの動作を行い得る。コンピュータに読み取り可能な媒体は、不揮発性メモリ装置を含む。メモリ装置は、単一の物理的なメモリ装置内に実装されてもよく、又は、複数の物理的なメモリ装置にわたって散在してもよい。ソフトウェア命令は、他のコンピュータに読み取り可能な媒体又は他の装置からメモリ２３０へ読み込まれてもよい。メモリ２３０に含まれるソフトウェア命令は、プロセッサ２２０に、本明細書で説明されるプロセスを行わせ得る。あるいは、ハードワイヤード（例えば、固定の）回路が、ソフトウェア命令の代わりに、又はソフトウェア命令と組み合せて使用されて、本明細書で説明されるプロセスを実装してもよい。よって、本明細書で説明される実装は、ハードウェア回路及びソフトウェアのいずれかの特定の組み合せに限定されない。

図２は、装置１３０の例示的なコンポーネントを示すが、他の実装では、装置１３０は、図２に描かれたものと比べて、より少ないコンポーネント、異なるコンポーネント、追加のコンポーネント、又は異なるように配置されたコンポーネントを含んでもよい。さらに、又は、あるいは、装置１３０の１つ以上のコンポーネントは、装置１３０の１つ以上の他のコンポーネントにより行われるように説明された１つ以上のタスクを行ってもよい。管理装置１５０は、装置１３０と同様に構成されてもよい。

図３は、装置１３０の例示的な通信レイヤを説明するブロック図である。装置１３０の機能コンポーネントは、例えば、メモリ２３０からの命令を実行するプロセッサ２２０により実装され得る。さらに、又は、あるいは、装置１３０の機能コンポーネントは、１つ以上のＡＳＩＣのハードワイヤード（例えば固定の）回路を用いて実装されてもよい。図３に示されるように、装置１３０は、サービスレイヤ１３０、オーバレイネットワークレイヤ３２０及び装置レイヤ３３０を含み得る。

一実施形態では、サービスレイヤ３１０は、クライアントが特定のサービスタイプのサービスインスタンスを検索することを可能にし、クライアントが特定のサービスインスタンスへ要求を送信することを可能にする。サービスは、一実施形態では、サービスの実際の実装に非依存である標準化されたサービスインタフェースを介してアクセスされ得る。サービスインスタンスは、明示的な境界（boundary）と関連付けられ得る。この実施形態では、装置１３０上で実行される特定のプロセス、及び／又は、装置１３０上に記憶される特定のデータは、曖昧さなしに、サービスインスタンス内に、又はサービスインスタンスの外に存在する。サービスインスタンスは、他のサービスインスタンスについて自律的であり得る。例えば、特定のサービスインスタンスは、当該特定のサービスインスタンスと相互作用する他のサービスインスタンスに悪影響を与えることなく修正され得る（例えば、コードが書き換えられ得る）。サービスは、（同一のタイプの又は異なるタイプの）他のサービスインスタンスとスキーマ及び／又はコントラクトを共有し得るが、一実施形態では、サービス実装を共有しない。スキーマは、上記サービスインタフェースにより送信され又は受信されるメッセージのフォーマット及び内容を特定する。コントラクトは、上記サービスインタフェースにより送信され又は受信されるメッセージの許容されるシーケンスを特定する。

一実施形態では、オーバレイネットワークレイヤ３２０は、既存のネットワークトポロジの上にオーバレイネットワークを実装する。オーバレイネットワークレイヤ３２０は、ファイアウォールを通じてトラフィックをルーティングすること、及び／又は、下層のネットワークトポロジにおけるネットワークアドレス変換（ＮＡＴ）を扱うことを、担い得る。一実施形態では、（例えば下層のネットワークトポロジとは異なり得る）オーバレイネットワークトポロジは、ツリー構造で組織化されたノードを含む。オーバレイネットワークトポロジは、論理的にノードを接続する。他の実施形態では、オーバレイネットワークトポロジは、異なるタイプの構造（例えば、メッシュトポロジ）を含んでもよい。装置１３０内の各サービスホストは、オーバレイネットワーク内のノードに対応し得るし、ノードＩＤを割り当てられ得る。装置１３０上のノードは、複数のサービスホスト及び／又は複数のノードを含み得る。装置１３０は、１つのノードに対応する１つのホストを含むように説明され得る。ノードは、ルーティングツリーのようなネットワークトポロジを介して接続され得る。ノードは、ルーティングツリーを介して他のノードへメッセージを送信し得る。一実施形態では、ノードは、メッセージにオーバレイネットワークトポロジを横断（traverse）させることなく、下層のネットワークトポロジを介して他のノードへ上記メッセージを送信し得る。各ノードは、（下層ネットワークと同様に）オーバレイネットワーク内の近隣に到達するための情報（例えば、ネットワーク１１０などの下層ネットワークのアドレス）を記憶し得る。オーバレイネットワークレイヤ３２０は、ノード間の通信レイヤに対応し得るし、複数のネットワークトポロジを使用して特定の機能を実現し得る。例えば、特定のタイプのサービスのためのサービスレジストリを検索する場合に、オーバレイネットワークレイヤ３２０は、サービスレジストリを検索している間に、ノードのツリーの端を横断し得る。一実施形態では、第１のノードから第２のノードへメッセージを送信する場合に、オーバレイネットワークレイヤ３２０は、ツリーの端を追うことによってよりも、上記第１のノードから上記第２のノードへ直接的にメッセージを送信し得る。オーバレイネットワークレイヤ３２０は、サービスレイヤ３１０にノードＩＤを提供し得る。サービスレイヤ３１０は、下層のネットワークトポロジを知る必要もなく、特定のノードＩＤへメッセージを送信し得る。

一実施形態では、装置レイヤ３３０は、ＳＯＡシステムサービスバス１４０の初期のインストールの間に装置の発見（device discovery）を行う。装置レイヤ３３０及び／又はオーバレイネットワークレイヤ３２０は、初期のインストールの後でノードの発見（node discovery）も行い得るし、及び／又は、オフラインになって後にオーバレイネットワークに再度参加したロスト（lost）ノードを再発見し得る。一実施形態では、オーバレイネットワークレイヤ３２０は、証明書などの、ノードに各々のＩＤを検証することを可能にする、オーバレイネットワークについての共有秘密（shared secret）を管理する。オーバレイネットワークレイヤ３２０は、１つ以上の近さのメトリックに基づいて、オーバレイネットワークのためのトポロジ（例えば、ルーティングツリー又はメッシュ）を形成し得る。しかしながら、第１のノードから第２のノードへのメッセージは、ルーティングツリーを横断する必要はなく、その代わりに、第１のノードから第２のノードへ直接的に送信されてもよい。他の実施形態では、第１のノードから第２のノードへのメッセージは、ルーティングツリーを横断する。さらに、オーバレイネットワークレイヤ３２０は、マルチキャストグループに基づいてマルチキャストメッセージを送信し得る。さらに、オーバレイネットワークレイヤ３２０は、サービスレイヤ３１０にサービス品質（ＱｏＳ）保証を提供し得る。

ネットワークレイヤ３２０は、概して「ノード」を扱い、装置レイヤ３３０は、概して「装置」を扱う。装置レイヤ３３０は、下層のネットワークトポロジ（例えば、ネットワーク１１０及び／又はサブネットワーク１２０）を使用して通信するのに必要な機能性を含む装置１３０の低レベルの機能性に対応する。例えば、装置レイヤ３３０は、ＯＳＩ（Open Systems Interconnection）モデルのレイヤ１〜６（例えば、物理レイヤ、データリングレイヤ、ネットワークレイヤ、トランスポートレイヤ、セッションレイヤ及びプレゼンテーションレイヤ）を実装し得る。これらのレイヤの実装は、イーサネットフレームのルーティング、インターネットプロトコル（ＩＰ）パケットのルーティング、セッション管理、パケットの暗号化及び解読、ロストパケットの再送などを含み得る。

図３は、装置１３０の例示的な機能コンポーネントを示すが、他の実装では、図３に描かれたものと比べて、装置１３０は、より少ない機能コンポーネント、異なる機能コンポーネント、異なるように配置された機能コンポーネント、又は追加の機能コンポーネントを含んでもよい。さらに、又は、あるいは、装置１３０内のいずれか１つのコンポーネント（又はコンポーネントのいずれかのグループ）は、装置１３０内の１つ以上の他の機能コンポーネントにより行われるように説明された機能を行ってもよい。

図４Ａは、サービスレイヤ３１０の例示的な機能コンポーネントを説明するブロック図である。図４Ａに示されるように、サービスレイヤ３１０は、サービスホスト４１５を含む。サービスホスト４１５は、１つ以上のサービス４１０−Ａ〜４１０−Ｎ（集合で「サービス４１０」と呼ばれ、また、個別に「サービス４１０」と呼ばれる）、１つ以上のクライアント４２０−Ａ〜４２０−Ｋ（集合で「クライアント４２０」と呼ばれ、また、個別に「クライアント４２０」と呼ばれる）、メッセージディスパッチャ（message dispatcher）４３０、及びサービスレジストリ４４０を含み得る。

サービス４１０は、装置１３０のサービスレイヤ３１０のサービスホスト４１５に関連付けられるサービスインスタンスに対応する。一実施形態では、サービス４１０は、サービスインタフェース４１２及びサービス実装４１４を含む。サービスインタフェース４１２は、標準化された通信プロトコルなどの通信プロトコルを含み得る。一実施形態では、通信プロトコルは、固有の名称及びバージョンを含む。サービスインタフェース４１２は、ＳＯＡＰ（Simple Object Access Protocol）インタフェース仕様、ＪＳＯＮ（JavaScript Object Notation）インタフェース仕様、及び／又は他のタイプのインタフェース仕様を使用して規定され得る。サービス実装４１４は、サービス４１０の実装を含む。サービス実装４１４は、サービスインタフェース４１２経由で受信される要求を処理し、及び／又は、サービスインタフェース４１２を通じてサービス要求に応答する。サービスインタフェース４１２は、サービス実装４１４から受信される応答を、適当なプロトコルに準拠した特定のフォーマットに変換する。クライアント４２０は、当該適当なプロトコルを使用して、サービス４１０とメッセージを交換する。

一実施形態では、クライアント４２０は、サービスレジストリ４４０へ要求を送信することにより、特定のサービスタイプのサービスインスタンスを要求する。サービスインスタンスが識別され、選択されると、クライアント４２０は、メッセージディスパッチャ４３０経由で、識別され選択された特定のサービスインスタンスへ要求を送信し得る。上述したように、クライアント４２０は、サービス４１０でもあってもよい。「クライアント」又は「クライアントサービス」という用語は、サービスを、別のサービスを要求しているものとみなす。

メッセージディスパッチャ４３０は、クライアント４２０からの入力メッセージを受信し、当該入力メッセージの対象とするサービス４１０に当該入力メッセージを向ける。さらに、メッセージディスパッチャ４３０は、サービスからメッセージを受信し、特定のクライアント４２０へ当該メッセージを送信し得る。入力メッセージの宛先が、メッセージディスパッチャ４３０と同じ装置１３０上にはない場合には、その後、当該入力メッセージは、正しい装置１３０への転送のために、オーバレイネットワークレイヤ３２０へ転送され得る。サービス４１０及びクライアント４２０は、オーバレイネットワークレイヤ３２０により実装されるオーバレイネットワーク内のエンドポイント（endpoint）として機能し得る。よって、一実施形態では、オーバレイネットワークレイヤ３２０は、オーバレイネットワークのルーティングツリーに基づいてルーティングテーブルを維持し得る。ルーティングテーブルは、特定のノードＩＤについて次のホップ宛先のリストを含み得る。メッセージディスパッチャ４３０は、出力ＩＤについて次のホップ宛先を識別し得るし、配信のためにオーバレイネットワークレイヤ３２０にメッセージを提供し得る。よって、この実施形態では、メッセージディスパッチャ４３０は、要求−応答メッセージングメカニズムを実装する。

サービスレジストリ４４０は、配置されたサービス（例えば、サービスのインスタンス）と関連付けられた属性とともに、当該配置されたサービス４１０のリストを維持する。サービスレジストリ４４０の例示的なコンポーネントを、図４Ｃを参照して以下により詳細に説明する。サービス４１０は、（例えば、サービスの属性を含む）サービスの記述をサービスレジストリ４４０に提供することにより、サービスレジストリ４４０に登録し得る。クライアント４２０は、サービス４１０でもあってもよいので、クライアント４２０も、サービスレジストリ４４０に登録してもよい。

図４Ｂは、サービスレジストリ４４０の機能性を説明するブロック図である。図４Ｂに示されるように、サービスレジストリ４４０は、クライアント４２０から検索クエリ（search query）を受信し得る。検索クエリは、特定のサービスタイプ、当該特定のサービスについての１つ以上の要求される属性、要求されるヒット数、及び／又は１つ以上の他のパラメータを特定し得る。サービスレジストリ４４０は、上記検索クエリを満たすサービス４１０を識別し得る。要求されるヒット数が、サービスレジストリ４４０によって満たされない場合には、サービスレジストリ４４０は、オーバレイネットワーク内の他のサービスレジストリ４４０（例えば、隣接したサービスレジストリ４４０）へクエリを転送し得る。一実施形態では、サービスレジストリ４４０は、検索クエリに基づいて特定のサービスインスタンスを選択しない。それどころか、この実施形態では、サービスレジストリ４４０は、上記クエリの結果をクライアント４２０に返し、上記クエリを発信したクライアント４２０は、上記検索結果から特定のサービスインスタンスを選択し得る。他の実施形態では、サービスレジストリ４４０は、上記クエリの結果から、上記検索クエリに基づいて、特定のサービスインスタンスを選択する。

図４Ａ及び図４Ｂは、サービスレイヤ３１０の例示的な機能コンポーネントを示すが、他の実装形態では、図４Ａ及び図４Ｂに描かれたものと比べて、サービスレイヤ３１０は、より少ない機能コンポーネント、異なる機能コンポーネント、異なるように配置された機能コンポーネント、又は追加の機能コンポーネントを含んでもよい。さらに、サービスレイヤ３１０内のいずれか１つのコンポーネント（又はコンポーネントのいずれかのグループ）は、サービスレイヤ３１０内の１つ以上の他の機能コンポーネントにより行われるように説明された機能を行ってもよい。

図４Ｃは、サービスレジストリ４４０の例示的な機能コンポーネントを説明するブロック図である。図４Ｃに示されるように、サービスレジストリ４４０は、ホストサービスレジストリデータベース（ＤＢ）４４２、クエリハンドラ４４４及びサービスレジストリキャッシュ４４６を含み得る。

ホストサービスレジストリＤＢ４４２は、サービスホスト４１５により提供されるサービス４１０のリスト及び／又はこれらのサービスの属性を維持する。ホストサービスレジストリＤＢ４４２において列挙されるサービスと当該サービスの属性との例は、図４Ｃに関連して以下に提供される。ホストレジストリＤＢ４４２は、サービスレジストリ４４０に登録するサービス４１０により住まれ（populate）得る。

ホストサービスレジストリＤＢ４４２は、列挙されるサービスを追加し又は削除するための、及び、サービスホスト４１５により提供されるサービスの属性を読み又は書くためのインタフェースもさらし得る。一実施形態では、例えば、ホストサービスレジストリＤＢ４４２は、異なる装置１３０上のサービスホスト４１５により提供されるサービス４１０のリストを維持し得る。上記異なる装置上のサービスホスト４１５は、されされた上記インタフェースを使用して他の装置上のサービスレジストリ内のサービスを列挙し得る。さらに、ホストサービスレジストリＤＢ４４２は、他のサービスレジストリによりアクセス可能な検索クエリサービスインタフェースをさらし得る。よって、他のサービスレジストリは、上記検索クエリサービスインタフェースを使用して、ホストサービスレジストリＤＢ４４２が特定のクエリを満たすエントリを含むかを判定し得る。一実施形態では、ＤＢ４４２が無効な（outdated）情報を記憶するのを防ぐのを助けるために、ホストサービスレジストリＤＢ４４２内に列挙されるサービスは失効し得る（例えば、リフレッシュされていなければしばらくするとＤＢ４４２から削除される）。

クエリハンドラ４４４は、クライアント４２０から受信されるクエリを処理（handle）し得る。一実施形態では、クエリが与えられると、クエリハンドラ４４４は、まず、ローカルのホストサービスレジストリＤＢ４４２を検索し、その後にサービスレジストリキャッシュ４４６が続く。クエリハンドラ４４４は、例えば上記クエリが満たされない場合に、他のサービスレジストリにコールを出し得る。サービスレジストリキャッシュ４４６は、遠隔のサービスレジストリ４４０からのデータを記憶し得る。各サービスホスト４１５は、ローカルサービスレジストリ４４０を維持し得る。サービスホスト４１５に登録するサービス４１０は、ローカルサービスレジストリ４４０内に登録される。ローカルサービスレジストリ４４０により満たされない、クライアント４２０からのクエリは、１つ以上の近隣のサービスホスト４１５へ送信されて、上記クエリを満たすサービスを含むサービスレジストリ４４０を上記近隣のサービスホスト４１５が有するかが調べられ得る。上記遠隔のサービスレジストリ４４０は、ローカルサービスレジストリ４４０に上記クエリの結果を返し得る。当該結果は、サービスレジストリキャッシュ４４６内に記憶され得る。いくつかの実施形態では、親ノードが、子ノードについてのデータをキャッシュし得る。一方、子ノードは、その親ノードについてのデータをキャッシュしなくてもよい。一実施形態では、キャッシュ４４６が無効な情報を記憶するのを防ぐのを助けるために、サービスレジストリキャッシュ４４６に列挙されるサービスは失効し得る（例えば、リフレッシュされていなければしばらくするとキャッシュ４４６から削除される）。

図４Ｃは、サービスレジストリ４４０の例示的な機能コンポーネントを示すが、他の実装では、図４Ｃに描かれたものと比べて、サービスレジストリ４４０は、より少ない機能コンポーネント、異なる機能コンポーネント、異なるように配置された機能コンポーネント、又は追加の機能コンポーネントを含んでもよい。さらに、サービスレジストリ４４０のいずれか１つのコンポーネント（又はコンポーネントのいずれかのグループ）は、サービスレジストリ４４０内の１つ以上の他の機能コンポーネントにより行われるように説明された機能を行ってもよい。

図４Ｄは、特定のサービスについての例示的な属性テーブル４６０のブロック図である。一実施形態では、サービスのインスタンス（例えば、各インスタンス）は、テーブル４６０のような属性テーブルに関連付けられる。ホストサービスレジストリＤＢ４４２は、対応するサービスレジストリ４４０に登録された各サービスについての属性テーブルを記憶し得る。一実施形態では、上述したように、いずれか１つのサービスレジストリＤＢ４４２内に記憶される情報は、他のサービスレジストリデータベース内に記憶される情報と異なり得る。例示的な属性テーブル４６０は、ＩＤフィールド４６２，インタフェースフィールド４６４、サービスフォーマットフィールド４６８、トランスポートプロトコルフィールド４７０、ＣＰＵランキングフィールド４７２、ディスクスペースフィールド４７４及びＲＡＭフィールド４７６という８つのフィールドを含む。

インスタンスＩＤフィールドは、特定のサービスのインスタンスを一意に定義する。（ノードＩＤとともに）インスタンスＩＤは、ネットワーク内の（同一のタイプ又は異なるタイプの）他のサービスからサービスインスタンスを一意に識別し得る。一実施形態では、インスタンスＩＤフィールド４６２は整数である。テーブル４６０では、インスタンスＩＤは、例えば６５２９である。

インタフェースフィールド４６４は、サービスのインタフェースの名称である。このケースでは、インタフェースフィールド４６４は、インタフェースのタイプによりサービスのタイプも識別する。例えば、テーブル４６０は、インタフェースを「ストレージサービス」として識別する。サービスフォーマットフィールド４６８は、サービスのインスタンスにより使用されるフォーマットを識別する。例えば、テーブル４６０は、サービスフォーマットを「ＪＳＯＮ」として識別する。トランスポートプロトコルフィールド４７０は、サービスのインスタンスにより使用されるプロトコルを識別する。例えば、テーブル４６０は、サービスフォーマットを「ノードプロトコル」として識別する。

ＣＰＵランキングフィールド４７２は、サービスインスタンスに関連付けられるＣＰＵのパフォーマンスを識別する。一実施形態では、スケールが使用される（例えば、１〜１００）。テーブル４６０は、ＣＰＵランキングフィールド７４２において、サービスについてＣＰＵランキングを２０／１００として識別する。ＲＡＭフィールド４７６は、サービスに利用可能なランダムアクセスメモリの量を識別する。テーブル４６０は、フィールド４７６において、利用可能なＲＡＭを２ＧＢとして識別する。

図４Ｄは、属性テーブル４６０の例示的なコンポーネントを示すが、他の実施形態では、図４Ｄに描かれたものと比べて、属性テーブル４６０は、より少ないコンポーネント、異なるコンポーネント、異なるように配置されたコンポーネント、又は追加のコンポーネントを含んでもよい。

図５Ａは、オーバレイネットワークレイヤ３２０の機能コンポーネントを説明するブロック図である。図５Ａに示されるように、オーバレイネットワークレイヤ３２０は、ノードマネージャ５１０、通信マネージャ５２０及びマルチキャストマネージャ５３０を含み得る。ノードマネージャ５１０は、ノードＩＤなどのノード情報を、オーバレイネットワーク内の他のノードに提供し得る。さらに、ノードマネージャ５１０は、オーバレイネットワーク内のノードのリストを維持し得る。ノードマネージャ５１０は、ノード発見（discovery）を実行して、オーバレイネットワークに追加される新たなノードを識別し、及び／又は、オーバレイネットワークに再度参加したロストノードを再発見し得る。ノードマネージャ５１０は、また、以下に説明されるようにネットワークのトポロジ（例えば、どのノードが最も近い他のノードであるか）を判定し得る。

通信マネージャ５２０は、ノードが互いに通信することを可能にし得る。通信マネージャ５２０は、オーバレイネットワークのツリーを横断するメカニズムを実装し得る。サービスレジストリの検索クエリに関連して、又は、他のノードへの直接的な通信方法が利用可能ではない場合に、ツリー横断が実行され得る。さらに、通信マネージャ５２０は、オーバレイネットワークのツリーを横断する必要なくオーバレイネットワークの特定のノードが直接的に通信することを可能にし得る直接的な通信方法を実装し得る。

マルチキャストマネージャ５３０は、マルチキャストメカニズムを実装し得る。当該マルチキャストメカニズムが使用されて、マルチキャストグループのメンバ（例えば、全てのメンバ）へメッセージが送信され得る。さらに、上記マルチキャストメカニズムが使用されて、加入通知メッセージパターンが実装され得る。よって、特定のサービスインスタンスに関連付けられるイベントが使用されて、上記特定のサービスインスタンスからのメッセージに加入（subscribe）したノードへ送信されるメッセージがトリガされ得る。マルチキャストマネージャ５３０は、アプリケーションレイヤマルチキャストマネージャ、又は、より低いＯＳＩレイヤからのマルチキャストマネージャを含み得る。

図５Ａは、オーバレイネットワークレイヤ３２０の例示的な機能コンポーネントを示すが、他の実施形態では、オーバレイネットワークレイヤ３２０は、図５Ａに描かれたものと比べて、より少ない機能コンポーネント、異なる機能コンポーネント、異なるように配置された機能コンポーネント、又は追加の機能コンポーネントを含んでもよい。さらに、オーバレイネットワークレイヤ３２０のいずれか１つのコンポーネント（又はコンポーネントのいずれかのグループ）は、オーバレイネットワークレイヤ３２０内の１つ以上の他の機能コンポーネントにより行われるように説明された機能を行ってもよい。

図５Ｂは、オーバレイネットワーク５４０の例示的なトポロジのブロック図である。図５Ｂの例に示されるように、オーバレイネットワーク５４０はノードＮ１〜Ｎ７を組む。ノードＮ１及びＮ２は、マルチキャストグループ５６０−１内にある。ノードＮ１は、サービスエンドポイントＳ１及びＳ３、並びにクライアントエンドポイントＣ１を含む。ノードＮ３は、ノードＮ１及びＮ２にとっての親ノードである。ノードＮ３は、サービスエンドポイントＳ７及びクライアントエンドポイントＣ３を含む。

ノードＮ６及びＮ７は、マルチキャストグループ５６０−２内にあり、ノードＮ７は、クライアントエンドポイントＣ２及びサービスエンドポイントＳ５及びＳ６を含む。ノードＮ５は、ノードＮ６及びＮ７にとっての親ノードであり、サービスエンドポイントＳ９を含む。ノードＮ３及びＮ５は、マルチキャストグループ５６０−３内にある。ノードＮ４は、ノードＮ３及びＮ５にとっての親ノードであり、オーバレイネットワーク５４０のルートノードである。さらに、ノードＮ４は、マルチキャストグループ５６０−４内にあり、サービスエンドポイントＳ８を含む。ネットワーク５４０のトポロジ内の親ノードは２つの子ノードを有するが、他の実装では、親ノードは、２つを超える子ノードを有してもよい。

各サービスエンドポイントは、サービスレジストリ４４０に関連付けられるとすると、検索クエリは、以下のようにオーバレイ機能ネットワーク５４０を横断し得る。サービスエンドポイントＳ７は、検索クエリを実行して、サービスエンドポイントＳ１及びサービスエンドポイントＳ５に含まれる（即ち、Ｓ１及びＳ５がマッチする）特定のサービスを見つける（例えば識別し又は検索する）。サービスエンドポイントＳ７は、ローカルサービスレジストリに上記検索クエリを送信し得る。上記検索クエリにおいてマッチなしという結果になり得る。その後、上記ローカルサービスレジストリは、オーバレイネットワーク内の隣接するサービスレジストリを識別し得る。当該隣接するサービスレジストリは、ノードＮ１内のサービスレジストリ、及びノードＮ４内のサービスレジストを含み得る（ノード２に関連付けられるサービスエンドポイントがないので、ノードＮ２はサービスレジストリを含まなくてもよい）。ノードＮ１内のサービスレジストリは、サービスエンドポイントＳ１を識別するヒットを返し得る。ノードＮ４内のサービスレジストリは、いずれのヒットも返さなくてもよく、隣接するサービスレジストリへ上記検索クエリを転送し得る。このケースでは、当該隣接するサービスレジストリは、ノードＮ３及びＮ５内のサービスレジストリを含む。しかしながら、ノードＮ３内のサービスレジストリは、検索を既に処理したので、上記検索クエリは、ノードＮ５内のサービスレジストリへのみ送信され得る。ノードＮ５におけるサービスレジストリは、ヒットせず、ノードＮ７におけるサービスレジストリへ上記検索クエリを転送し得る。ノードＮ７は、サービスエンドポイントＳ５をヒットとして識別し得る。そして、ノードＮ７は、上記検索クエリの結果をノードＮ４へ返し得る。ノードＮ４は、ノードＮ３内のサービスエンドポイントＳ７へ検索結果を転送し得る。

図６Ａ及び図６Ｂは、サービスレジスタ４４０のネットワークを形成する（例えば、サービスホスト４１５（図４を参照）を各々含む）ノードの他の例示的なネットワーク６００のトポロジ（例えば、ツリーネットワーク）のブロック図である。ネットワーク６００は、ノードＰ〜Ｕという６つのノードを含む。ノードＰは、ノードＱ及びノードＲという２つの子を有する。ノードＲは、いずれの子も有しない。ノードＱは、ノードＳ、ノードＴ及びノードＵという３つの子を有する。ネットワーク６００の例では、各ノードは、図４Ａに示されるコンポーネント（例えば、サービス４１０、クライアント４２０、メッセージディスパッチャ４３０及びサービスレジストリ４４０）を含み得るサービスホスト４１５に対応する。

図６Ｂは、サービスホスト（例えば、サービスホスト４１５−Ｐ〜４１５−Ｕ）とサービスレジストリ（例えば、レジストリ４４０−Ｐ〜４４０−Ｕ）との関係を示す。例えば、ネットワーク６００の例について、各サービスホストは、対応するクライアント（クライアント４２０−Ｐ〜４２０−Ｕ、図示せず）及び対応するサービス（サービス４１０−Ｐ〜４１０−Ｕ、図示せず）も含む。さらに、各サービスレジストリ４４０−Ｐ〜４４０−Ｕは、ホストサービスレジストリＤＢ（ＤＢ４４２−Ｐ〜４４２−Ｕ、図示せず）、クエリハンドラ（クエリハンドラ４４４−Ｐ〜４４４−Ｕ）及びサービスレジストリキャッシュ（例えば、キャッシュ４４６−Ｐ〜４４６−Ｕ）を含む。

述べられたように、クライアントが、特定のサービスを検索する場合に、当該検索は、トポロジに従って１つのノードから他のノードへネットワークを通じて伝わり得る。上記ネットワークトポロジは、検索される上記特定のサービスによって異なり得る。例えば、ストレージキャパシティの検索は、特定のタイプのトランスコーダ（transcoder）の検索とは異なるネットワークトポロジに関連付けられ得る。図７Ａは、一実施形態におけるＳＯＡネットワークのトポロジを決定するための例示的なプロセス７００Ａのフローチャートである。ノードマネージャ５１０（図５Ａを参照）は、プロセス７００Ａを行い、また、周期的に行い得る。しかしながら、他の実装形態では、環境１００内のいずれかの装置が、プロセス７００Ａの全て又は一部を行ってもよい。

一実施形態では、ノードマネージャ５１０は、ネットワークトポロジを生成する特定のサービスを選択する（ブロック７０２）。例えば、ノードマネージャ５１０は、ネットワークについてのトポロジを構築するサービスとして「ストレージサービス」を選択し得る。他の実施形態では、ノードマネージャ５１０は、特定のサービスを考慮しないが、ノードの属性（例えば、処理速度）又は１つのノードと他のノードとの関係の属性（例えば、帯域幅）などの１つ以上の属性に基づいて（ブロック７０２）、トポロジを生成する。

ノードマネージャ５１０は、１つ以上の属性に基づいてネットワークのトポロジを決定し得る。特定のサービスが選択される場合に（ブロック７０２）、ノードマネージャ５１０は、当該特定のサービスの属性以外の属性に基づいてトポロジを決定し得る。特定のサービスが選択されない場合には、ノードマネージャ５１０は、当該特定のサービスの属性以外の属性に基づいて、（ブロック７０２で選択された属性のための）トポロジを決定し得る（例えば、当該トポロジは、上記特定のサービスを検索するために使用され得る）。即ち、（例えば、上記トポロジが、上記特定のサービスを考慮せずに生成されたとしても、）上記トポロジは、特定のサービスを検索するために使用され得る。そのトポロジは、上記特定のサービスの属性以外の属性に基づいて生成された。したがって、ノードマネージャ５１０は、また、上記トポロジを生成するための属性（例えば、上記特定のサービスの属性以外の属性）を判定し得る（ブロック７０６）。例えば、図７Ｂは、特定のサービスの属性以外の属性を判定するための例示的なプロセス７００Ｂのフローチャートである。属性を判定すること（ブロック７０６）は、図７Ｂに示されるプロセス７００Ｂを含み得る。図７Ａのプロセス７００Ａのように、プロセス７００Ｂは、ノードマネージャ５１０により行われ得る。

ブロック７０６（図７を参照）を詳述する図７Ｂに切り替えると、プロセス７００Ｂは、複数の属性を判定し得る。一実施形態では、判定される属性は、上記特定のサービス（ブロック７０２で選択されたサービス、又は上記トポロジが検索のために使用される場合に検索されるサービス）の属性ではない。例えば、プロセス７００Ｂは、２つのノードが同一のドメイン内にあるかを判定すること（ブロック７２２）を含み得る。同一のドメイン内のノードは、異なるドメイン内のノードよりも近くにあり得る。例えば、同一のドメイン内のノードは、同じファイアウォールの後方にあるノードであり得る。プロセス７０６は、ノードがマルチキャスト経由で互いに到達できるかを判定すること（ブロック７２４）を含み得る。いくつかの実装では、同一のネットワーク内のノード（ブロック７２２）は、マルチキャスト経由で到達できる（例えば、マルチキャストケイパビリティ）同一のノードであってもよい（ブロック７２４）。他の実施形態では、マルチキャスト経由で到達可能なノードは、ノードが同一のマルチキャストグループのメンバであることを判定するなどの異なる技術を使用して、判定されてもよい。マルチキャスト経由で到達可能なノードは、マルチキャスト経由で到達可能ではないノードよりも近いとみなされてもよい。

プロセス７００Ｂは、ノードの地理的な位置を判定すること（ブロック７２６）も含み得る。このケースでは、互いに地理的に近いノードは、地理的に離れたノードよりもトポロジにおいてより近いとみなされる。プロセス７００Ｂは、ノード間のレイテンシ及び／又はノード間の利用可能な帯域を判定すること（ブロック７２８）を含み得る。低いレイテンシを伴うノードは、高いレイテンシを伴うノードよりもネットワーク内でより近いとみなされ得る。ノード間の高い帯域幅を伴うノードは、低い帯域幅を伴うノードよりもネットワーク内でより近いとみなされ得る。

プロセス７００Ｂは、ノードのストレージキャパシティを判定すること（ブロック７３０）を含み得る。プロセス７００Ｂは、ノードのプロセッサスピード又はクラスを判定することも含み得る（ブロック７３２）。高いストレージキャパシティ及び高いプロセッサスピードを伴うノードは、例えば、トポロジにおいて親ノードとなり得る。（例えば検索される上記特定のサービスの属性以外の）属性であって、図７Ｂに示される属性以外の当該属性が、判定されてもよい。例えば、（例えば上記特定のサービスの属性以外の）属性は、いずれかの２つのノード間でチャネルが存在し開放されているか（例えばオープンチャネル）、いずれかの２つのノード間の（例えば下層の物理ネットワーク内での）ホップ数、２つのノード間でデータを搬送するための（例えば通貨での）コスト（例えば携帯加入サービス）、地理的な位置（例えば、データが特定の国を通貨するか）、及び／又はネットワークタイプ（例えば、光ファイバ、ＷｉＦｉ、セルラーなど）を含んでもよい。

図７Ａに戻ると、ノードマネージャ５１０は、ネットワークトポロジを決定するために、属性を（例えば当該属性の各々のための重みで）重み付けし得る（ブロック７０８）。重み付けされた属性に基づいて、ノードマネージャ５１０は、他のノードとの各ノードの近さを判定できる（ブロック７１０）。一実施形態では、近さの判定は、一部において、上記特定のサービスの属性以外の属性に基づく（ブロック７１０）。上記近さに基づいて、ノードマネージャ５１０は、（ブロックＳ７０２で決定された）上記特定のサービス、又は（ブロック７０２で決定された）選択された属性についてのネットワークのトポロジを決定できる（ブロック７１２）。例えば、上記トポロジは、とりわけツリーネットワーク又はメッシュネットワークであり得る。

一実施形態では、ノードマネージャ５１０は、サービスごとに異なるトポロジを決定し得る。例えば、ノードマネージャ５１０は、「カメラ」についてのトポロジとは異なる、「ストレージサービス」についてのトポロジを決定し得る。一例では、ノードマネージャ５１０は、レイテンシ又は地理的な位置（又はいずれかの条件の重み付けされた混合）などの異なる条件についてのトポロジを決定し得る。一実施形態では、クライアント４２０（例えば、検索を要求したクライアント）は、検索を発信する際にトポロジを識別する。異なる条件についてのトポロジをノードマネージャ５１０が決定するケースでは、トポロジに関連付けられる条件は、例えば、検索条件において検索されているものとして識別される特定のサービスの属性以外の１つ以上の属性を含み得る。この実施形態は、大きな帯域幅を必要とするファイルをストリーミングする場合に、クライアントが「良好は帯域幅でのストレージサービス」を検索することを可能にする。他の例では、この実施形態は、小さいレイテンシを必要とするファイルをストリーミングする場合に、クライアントが「地理的に近い（例えば低いレイテンシの）ストレージサービス」を検索することを可能にする。１つのトポロジが地理的な近さのために使用され、他のトポロジが帯域幅のために使用される。さらに、異なるトポロジが、地理的な近さ及び帯域幅の組合せのために定義され使用されてもよい。上述した例では、帯域幅及び地理的な近さは、検索される特定のサービス（例えば、データストレージ）の属性以外の属性である。

例えば、ネットワーク６００は、サービスを検索するために使用される。図８は、ＳＯＡネットワークにおいてサービスを検索するための例示的なプロセス８００のフローチャートである。例えば、プロセス８００は、サービスレイヤ３１０内のサービスホストにおいて実行し得る。一実施形態では、プロセス８００（又はプロセス８００の一部）は、繰り返され、及び／又は反復され得る。プロセスの複数のインスタンス（又はプロセスの一部）は、複数のサービスホストにおいて発生し、例えば、上記プロセスは、別のサービスにおいて自身を呼び出す。プロセス８００は、図６のネットワーク６００に関連して説明される。

プロセス８００は、クライアントにおいて検索クエリを形成し、サービスレジストリへ当該クエリが送信されることから始まる。一実施形態では、クライアントは、（例えば、異なるノード内のサービスホスト４１５と対照的に同一のサービスホスト４１５内の）ローカルサービスレジストリへ上記クエリを送信する。例えば、ネットワーク６００を参照すると、ノードＳ内のクライアント４２０−Ｓは、特定のサービスについてのクエリを形成し、ノードＳ内のサービスレジストリ４４０−Ｓへ上記クエリを送信する（ブロック８０２）。図８に示されるように、クエリは、（＆（インタフェース＝ストリーレジサービス）（ＣＰＵランキング＞１０）（ディスクスペース＞＝５００ＭＢ）であり得る。上記クエリは、結果の数（例えば、６などのサービス数）を特定し、要求し得る。この例では、上記クエリは、特定のサービス（例えば、「ストレージサービス」）と、当該特定のサービスの特定の属性（例えば、「ディスクスペース＞＝５００ＭＢ」）とを特定する。クライアント４４０−Ｓにより生成される上記クエリは、クロールする（例えば、横断する、従う、又は移動する）オーバレイネットワークのトポロジを特定し、又は要求し得る。上述したように、上記クエリは、地理的な近さ、レイテンシ、帯域幅、同一の若しくは異なるドメイン、ストレージキャパシティ、プロセッサスピードなど、又は、これらの属性の重み付けされたいずれかの組合せについてのトポロジを特定し得る。

サービスレジストリは、上記クライアントから上記クエリを受信する（ブロック８０４）。ネットワーク６００の例を継続すると、ノードＳ内のサービスレジストリ４４０−Ｓは、クライアント４２０−Ｓ（例えば、ローカルサービスレジストリ）から上記特定のサービスについての上記クエリを受信する。とりわけ、クエリハンドラ４４４−Ｓ（図４Ｃを参照）が、上記クエリを受信し得る。図８に示され、以下により詳細に示されるように、サービスレジストリは、他のサービスレジストリ（例えば、異なるノード内の異なるサービスホスト４１５内のサービスレジストリ）からも検索クエリを受信し得る（ブロック８０４）。

検索クエリを受信すると、上記サービスレジストリは、ホストサービスレジストリＤＢ（例えば、ローカルデータベース）内に登録されているサービスをマッチングするために、当該ホストサービスレジストリＤＢに問い合わせる（query）（ブロック８０６）。上述した例を継続すると、クエリハンドラ４４４−Ｓは、クライアント４２０−Ｋから受信した上記検索クエリを用いて、ホストサービスレジストリＤＢ４４２−Ｓ（図４を参照）に問い合わせる。上記クエリは、上記クエリにマッチする（例えば上記クエリを満たす）登録されたサービスのリスト（例えば、第１のレイスト）をもたらし得る。

上記クエリの結果が十分である場合には（ブロック８０８：ＹＥＳ）、上記クエリを満たす、上記登録されたサービスの上記リスト（例えば、上記第１のレイスト）は、上記クライアントに返され得る（ブロック８１０）。十分にマッチする結果は、例えば、上記リスト内のサービスの数と、数（例えば、上記検索クエリ内で上記クライアントにより要求された数、又はデフォルトの数）とを比較することにより、判定され得る。検索結果がクライアントへ返された後に（ブロック８１０）、プロセス８００は、（少なくとも、ブロック８０３において上記クエリを受信したサービスレジストリ４４０について）終了し得る。

上述したように、ローカルサービスレジストリ４４０−Ｓは、より高速の検索のために遠隔のサービスホストからのサービス情報が記憶されるキャッシュ４４６−Ｓを有し得る。よって、クエリハンドラ４４４−Ｓは、結果を補うために（又はローカルＤＢ４４２−Ｓにおいて不十分な結果がある場合にのみ）サービスレジストリキャッシュ４４６−Ｓにも問い合わせる。キャッシュ４４６−Ｓからの結果は、上記クライアントに返されるサービスの上記リストの中に含まれ得る。

サービスレジストリ４４０−Ｓは、マッチするサービスの検索のために他のサービスレジストリをドラフト（draft）し得る。検索結果が十分ではない場合に（ブロック８０８）、サービスレジストリ４４０−Ｓ（例えば、クエリハンドラ）は、近隣ノードを判定するためにトポロジを決定し、及び／又は選択し得る（ブロックＳ８１１）。一実施形態では、上記トポロジは、クライアントにより発信される上記クエリにおいて識別され得る。他の実施形態では、上記トポロジは、検索される上記特定のサービスに基づいて選択され得る。さらに他の実施形態では、クエリハンドラ４４４−Ｓは、他の要素に基づいて上記トポロジを選択する。選択される上記トポロジは、上述したもの、即ち、地理的な近さ、レイテンシ、帯域幅など、又は重み付けされたそれらのいずれかの組合せを含み得る。一実施形態では、例えば、要求されたトポロジが存在しない場合に、トポロジはオンザフライ（on the fly）で生成され得る。

異なるトポロジが、検索される特定のサービスに依存する他のトポロジよりも良くてもよい（最高のトポロジがブロック８１１において選択されてもよい）。例えば、検索される上記特定のサービスが、高精細ビデオのストリーミングである場合には、帯域幅は、トポロジのための重要な属性（例えば、ブロック７０６において選択され、ブロック７０８において重み付けされる属性）であり得る。一方、例えば、検索される上記特定のサービスが、電話である場合には、レイテンシは、トポロジのための最も重要な属性（例えば、ブロック７０６において選択され、ブロック７０８において重み付けされる属性）であり得る。したがって、この実施形態は、検索される上記特定のサービスに最も適したトポロジの選択を可能にする。

クエリハンドラ４４４−Ｓは、他の近隣ノードのＩＤを要求し、受信し得る（ブロック８１２）。近隣ノードは、例えば、（ブロック８１１から）選択された上記トポロジにおいて１ホップだけ離れた、ネットワーク（例えば、ネットワーク６００）内のノードである。上述したように、上記近隣ノード（例えば、サービスレジストリ）は、検索される上記特定のサービスの属性以外の属性に基づく（例えば最も近いネイバとして前に選択された）ネイバである。例えば、特定のサービス「ストレージサービス」についての近隣サービスレジストリにおいて、（上記サービスの属性以外の）上記属性は、ネットワークレイテンシを含み得る。例示的なネットワーク６００を継続すると、サービスレジストリ４４０−Ｓ内のクエリハンドラ４４４−Ｓは、ホストサービスレジストリＤＢ４４２−Ｓに問い合せ（ブロック８０６）、３つのマッチするサービス、即ち不十分な数の結果を見つける（ブロック８０８：ＮＯ）（例えば、６つの結果が上記クライアントにより要求された）。結果として、クエリハンドラ４４４−Ｓ（図４Ｃを参照）は、ネットワークレイヤ３２０内のノードマネージャ５１０から（例えば１ホップ離れた）上記近隣ノードのＩＤを要求する。クエリハンドラ４４４−Ｓは、ノードマネージャ５１０、即ち、図６Ａに示されるようにたまたまノードＳの親であるノードＱから、近隣ノードのリストを受信する。

クエリハンドラは、検索を転送するのに近隣ノード（例えば、近隣サービスレジストリ）が利用可能かを判定する。いずれの近隣ノードも、検索を続けるのに利用可能ではない場合には（ブロック８１４：ＮＯ）、これの標識（indication）が、検索結果があれば検索結果とともに（ブロック８１０）、上記クライアント（又は要求する他のサービスレジストリ）へ送信され得る。この場合に、プロセス８００は、（少なくとも上記クエリを受信したサービスレジストリ４１５について）終了し得る。クエリハンドラは、ノードマネージャ５１０が近隣ノードのリストを返す場合でも、いずれの他の近隣ノードも検索のために利用可能ではないと判定し得る。例えば、クエリハンドラは、近隣ノードの上記リスト内の各ノードは同一の検索に参加しており、上記検索クエリを転送するのに利用可能なノードが残されていないと判定し得る。

近隣ノードが検索を続けるのに利用可能である場合には（ブロック８１４：ＹＥＳ）、サービスレジストリ（例えば、クエリハンドラ）は、上記近隣ノード内の上記サービスレジストリ（例えば、近隣サービスレジストリ）へ上記検索クエリを送信し得る（ブロック８１６）。現在の例では、クエリハンドラ４４４−Ｓは、（例えば、サービスレジストリ４４０−Ｑは、検索に参加したとは知られていないので）ノードＱが検索を続けるのに利用可能であると判定する（ブロック８１４：ＹＥＳ）。サービスレジストリ４４０−Ｓは、ノードＱ内のサービスレジストリ４４０−Ｑへ上記検索クエリを転送する（ブロック８１６）。破線で示されるように、上記近隣ノード内の上記サービスレジストリは、（他のサービスレジストリから上記検索クエリを受信することによりブロック８０４で開始する）プロセス８００の他のインスタンスを発生させ得る。一実施形態では、サービスレジストリ４４０−Ｓは、既に見つかったマッチする検索結果の数に基づいて、上記クエリ内の要求される検索結果の数を調整する。以下に詳細に説明するように、最終的には、サービスレジストリ４４０−Ｓは、近隣サービスレジストリ４４０−Ｑから検索結果（例えば、サービスの第２のリスト）を受信し得る（ブロック８１８）。サービスレジストリ４４０−Ｓは、サービスレジストリ４４０−Ｑから受信される結果（例えば、サービスの第２のリスト）を自らの結果（例えば、ブロック８０６からの上記第１のリスト）と結合し、上記クライアントへ両方のリストを返す。

現在の例では、サービスレジストリ４４０−Ｑは、サービスレジストリ４４０−Ｓから上記検索結果を受信し（ブロック８０４）、ホストサービスレジストリＤＢ４４２−Ｑに問い合わせる（ブロック８０６）。サービスレジストリ４４０−Ｑ内のクエリハンドラ４４４−Ｑは、ホストサービスレジストリＤＢ４４２−Ｑに問い合わせ（ブロック８０６）、マッチするいずれのサービスも見つけない。即ち、不十分な数の結果である（ブロック８０８：ＮＯ）。例として、クエリハンドラ４４４−Ｑにより受信される上記クエリは、要求される結果の数が３（例えば、６という元の要求から３だけ減算されたもの）であることを示し得る。結果として、クエリハンドラ４４４−Ｑは、ノードマネージャ５１０に近隣ノードのＩＤを要求する。クエリハンドラ４４４−Ｑは、ノードマネージャ５１０から近隣ノードのリストを受信する。当該近隣ノードは、図６Ａ及び図６Ｂに示されるようにノードＳ、ノードＴ、ノードＵ及びノードＰである。一実施形態では、所定の時間が経過すると、結果の数にかかわらず、結果は十分であるとみなされ得る（ブロック８０８：ＹＥＳ）。

クエリハンドラ４４４−Ｑは、近隣ノードが検索を転送するのに利用可能であるかを判定する（ブロック８１４）。クエリハンドラ４４４−Ｑは、ノードＴ、ノードＵ及びノードＰが検索を続けるのに利用可能であると判定する（ブロック８１４：ＹＥＳ）。サービスレジストリ４４０−Ｓから上記検索クエリが受信され、ノードＳは明らかに検索に既に関与しているので、クエリハンドラ４４４−ＱはノードＳを含めない。よって、クエリハンドラ４４４−Ｑは、近隣ノードＴ、近隣ノードＵ及び近隣ノードＰ内のサービスレジストリへ上記検索クエリを送信する（ブロック８１６）。破線で示されるように、近隣ノードＴ、Ｕ及びＰ内のサービスレジストリは、（他のサービスレジストリから上記検索クエリを受信することによりブロック８０４で開始する）プロセス８００の他のインスタンスを発生させ得る。

その後、サービスレジストリ４４０−Ｑは、サービスレジストリ４４０−Ｔ、サービスレジストリ４４０−Ｕ、及びサービスレジストリ４４０−Ｐへ検索要求を送信する（ブロック８１６）。上述したように、一実施形態では、サービスレジストリ４４０−Ｑは、既に見つかったマッチする検索結果の数に基づいて、上記クエリ内の要求される検索結果の数（例えば、３）を調整する。一実施形態では、全ての利用可能な近隣ノードにおける検索が並列で行われるように、上記検索要求はこれらの近隣ノードへ送信される。他の実施形態において、上記検索要求（例えば、検索クエリ）は、（例えば、各結果が受信された後に、又は時間ウィンドウの後に）順に送信されることが可能である。上記検索要求を順に送信することは、（例えば、ブロック８１４において判定された）全ての利用可能な近隣ノードへ上記検索要求を送信する前に、検索結果が十分であるとサービスレジストリ４４０−Ｔが判定すること（ブロック８０８）を可能にする。サービスレジストリ４４０Ｔは、要求を受信し（ブロック８０４）、ホストサービスレジストリＤＢ４４２−Ｔ内に、クエリにマッチする１つのサービスを見つける。しかしながら、合計４つの検索結果はまだ不十分である（例えば、６よりも少ない）（ブロック８０８：ＮＯ）。サービスレジストリ４４０−Ｔは、ネットワークトポロジを決定し、及び／又は選択し（ブロック８１１）、（例えば１ホップ離れた）近隣ノードのＩＤのためにオーバレイネットワークレイヤ３２０のノードマネージャ５１０へ要求を送信する（ブロック８１２）。ノードマネージャ５１０は、サービスレジストリ４４０−ＴへノードＱのＩＤを返す（ブロック８１２）。しかしながら、サービスレジストリ４４０−Ｔは、ノードＱ内のサービスレジストリ４４０−Ｑは既に検索に関与しており、他の利用可能な近隣ノードが残されていない（ブロック８１４：ＮＯ）ということを知っている。サービスレジストリ４４４−Ｔは、この結果（及び検索結果）をサービスレジストリ４４０−Ｑへ送信し（ブロック８１０）、サービスレジストリ４４０−Ｔにおけるプロセス８００は終了する。

サービスレジストリ４４０−Ｕも、上記要求を受信するが（ブロック８０４）、ホストサービスレジストリＤＢ４４２−Ｕの検索の間に（ブロック８０６）、サービスを見つけられず、不十分な数の検索結果が残る（ブロック８０８：ＮＯ）。サービスレジストリ４４０−Ｕは、ネットワークトポロジを決定し、及び／又は選択し（ブロック８１１）、（例えば１ホップ離れた）近隣ノードのＩＤのためにオーバレイネットワークレイヤ３２０のノードマネージャ５１０へ要求を送信する（ブロック８１２）。ノードマネージャ５１０は、ノードＱのＩＤをサービスレジストリ４４０−Ｕへ返す（ブロック８１２）。しかしながら、サービスレジストリ４４０−Ｕは、ノードＱ内のサービスレジストリ４４０−Ｑは既に検索に関与しており（サービスレジストリ４４０−Ｕはサービスレジストリ４４０−Ｑから上記要求を受信しており）、他の利用可能な近隣ノードが残されていない（ブロック８１４：ＮＯ）ということを知っている。そして、サービスレジストリ４４０−Ｕは、サービスレジストリ４４０−Ｑへこの結果を送信し（ブロック８１０）、サービスレジストリ４４０−Ｔにおけるプロセス８００が終了する。

サービスレジストリ４４０−Ｐも、上記要求を受信し（ブロック８０４）、ホストサービスレジストリＤＢ４４２−Ｐ内に、検索クエリにマッチし、又は当該検索クエリを満たす２つのサービスを発見する（ブロック８０６）。それでもなお、２つの結果は、十分なものよりも少ない（例えば要求される３つよりも少ない）とみなされる（ブロック８０８：ＥＳ）。サービスレジストリ４４０−Ｐは、ネットワークトポロジを決定し、及び／又は選択し（ブロック８１１）、（例えば１ホップ離れた）近隣ノードのＩＤのためにオーバレイネットワークレイヤ３２０のノードマネージャ５１０へ要求を送信する（ブロック８１２）。ノードマネージャ５１０は、ノードＱ及びＲのＩＤをサービスレジストリ４４０−Ｐへ返す（ブロック８１２）。しかしながら、サービスレジストリ４４０−Ｐは、ノードＱ内のサービスレジストリ４４０−Ｑは既に検索に関与しており（サービスレジストリ４４０−Ｐはサービスレジストリ４４０−Ｑから上記要求を受信しており）、ただ１つの利用可能な近隣ノードとしてノードＲが残されている（ブロック８１４：ＹＥＳ）ということを知っている。サービスレジストリ４４４−Ｐは、サービスレジストリ４４０−Ｒへ上記検索結果を送信し（ブロック８１６）、サービスレジストリ４４０−Ｒにおいてプロセス８００の他のインスタンスを発生させる。上記検索要求は、要求される結果の数を、（例えば、要求された３と比べて２つの検索結果を反映する）１に調整し得る。

サービスレジストリ４４０−Ｒは、上記検索要求を受信し（ブロック８０４）、ホストサービスレジストリＤＢ４４２−Ｒ内に、検索クエリにマッチし、又は当該検索クエリを満たす１つのサービスを発見する（ブロック８０６）。１つの結果は十分であるとみなされ（ブロック８０８：ＹＥＳ）、当該結果はサービスレジストリ４４０−Ｐ（サービスレジストリ４４０−Ｒへ検索要求を送信したサービスレジストリ）へ送信される。サービスレジストリ４４０−Ｐは、サービスレジストリ４４０−Ｒから上記結果（例えば、リスト）を受信し（ブロック８１８）、受信された当該結果を自らの結果と結合し得る。その後、サービスレジストリ４４０−Ｐは、サービスレジストリ４４０−Ｑ（即ち、サービスレジストリ４４０−Ｐが検索に参加することを要求したサービスレジストリ）へ上記結果を送信する。現在の例では、サービスレジストリ４４０−Ｐは、３つの結果をサービスレジストリ４４０−Ｑへ送信する。サービスレジストリ４４０−Ｑは、サービスレジストリ４４０−Ｐから上記結果を受信し（ブロック８１８）、受信された上記結果を自らの結果と結合し、サービスレジストリ４４０−Ｓ（例えば、サービスレジストリ４４０−Ｑが検索に参加することを要求したサービスレジストリ）へ上記結果を返す（ブロック８１８）。現在の例では、サービスレジストリ４４０−Ｑは、サービスレジストリ４４０−Ｓへ４つの結果を送信する。サービスレジストリ４４０−Ｓは、サービスレジストリ４４０−Ｑから上記結果（例えば、サービスの第２のリスト）を受信する（ブロック８１８）。サービスレジストリ４４０−Ｓは、サービスレジストリ４４０−Ｑから受信された上記結果（例えば、サービスの第２のリスト）を、自らの結果（例えば、ブロック８０６からの第１のリストからの３つ）と結合し、上記クライアントへ結果を返し得る（ブロック８１０）。現在の例では、サービスレジストリ４４０−Ｓは、７つの結果を上記クライアントへ送信する。

示されるように、クライアントは元のクエリの中で６つの結果を要求したが、７つの結果を受信した。サービスレジストリ４４０が並列で検索したので、追加の結果が発生し得る。これは、要求されるよりも多くの検索（及びおそらく必要であるよりも多くの計算能力））を示すが、一方で、追加の結果は、完全なデータベースのコピーをノードが必ずしも有しない分散データベースという見込まれる利点のために小さい計算コストである。

一実施形態では、サービスレジストリは、近隣から結果を受信する場合に（ブロック８１８）、サービスレジストリキャッシュ４４６内にこれらの結果を記憶し得る。キャッシュ４４６内に記憶される情報は、ＴＴＬ（Time-To-Live）を有してもよく、期間の後に削除されてもよい。他の実施形態では、サービスレジストリは、近隣サービスレジストリから結果を受信しない（ブロック８１８）。代わりに、上記近隣サービスレジストリは、要求する上記クライアントに直接的に上記結果を送信する。この後者の実施形態の利点は、いずれかの進行中の検索の状態、及びサービスレジストリが近隣からの応答を受信したかを、サービスレジストリは必ずしも記憶しなくてもよいということである。一方、この後者の実施形態は、キャッシュ４４６のサイズを限定し、長期的には検索を遅くし得る。

上記オーバレイネットワークのトポロジの他の例は、メッシュネットワークである。当該メッシュネットワークでは、各ノードは、上記オーバレイネットワーク１つ以上の他のノードに直接的に接続される。上記メッシュネットワーク内の各ノードは、オーバレイネットワークトポロジ内の接続（例えば、予め定義された配信パターン）に従って、自らに接続されるノードへトラフィックを転送し得る。ツリートポロジは、多くのメッシュトポロジのうちの１つとみなされ得る。他の例として、１つのメッシュトポロジは、各ノードを各他のノードに接続し得る。このケースでは、ネットワーク内の各ノードは、検索クエリを受信し得る。クライアント４２０から当該検索クエリを受信したサービスレジストリ４４０は、全てのノードから検索結果を受信した後に検索結果をランク付けし得る。

上述したツリートポロジと同様に、（ネットワークトポロジのグループの）異なるメッシュトポロジは、検索される異なる特定のサービス（又は属性の異なるグルーピング）に関連付けられ得る。さらに、メッシュトポロジ内の各接続は、検索される特定のサービスレジストリの属性以外の属性に基づいて確立され得る。例えば、各ノードは、地理的に最も近い４つのノードに接続され得る。他の例として、上記オーバレイネットワークの上記トポロジは、（メッシュかツリーかによらず）手動で構成され得る。一実施形態では、例えば、検索結果は、要求するクライアント４２０からのサービスのホップ数に基づいてランク付けされ得る。

メッシュネットワークのケースでは、要求される数よりも多くの検索結果が返され得る（したがって、追加の計算リソースが使用される）（即ち、見込まれる技術的問題）。それでもなお、メッシュネットワークは、効率的な手法で分散データベースの並列な検索を可能にし得る（例えば、異なる技術的問題への解決策の候補）。さらに、メッシュトポロジを通じた検索は、ツリートポロジを通じた検索よりも、より速く、より並列的であり得る（例えば、技術的問題への解決策の候補）。しかしながら、メッシュトポロジを通じた検索は、ツリートポロジよりも、より多くのネットワークトラフィック、及びより過剰な検索結果をもたらし得る（例えば、メッシュトポロジの見込まれる技術的問題、及びツリートポロジにより提供される解決策の候補）。

以上の明細書では、添付の図面を参照して様々な好適な実施形態を説明した。しかし、添付の特許請求の範囲に記載される本発明のより広い範囲から逸脱することなく、実施形態に様々な改変及び変更を加えることができ、追加的な実施形態を実現することができることは明らかであろう。本明細書及び図面は、したがって、限定としてではなく例示とみなされるべきである。

例えば、一実施形態では、クライアントは、ローカルサービスホスト又はローカルサービスレジストリ以外のサービスホスト及びサービスレジストリへ検索クエリを送信してもよい（ブロック８０２）。この実施形態では、上記クライアントは、ＳＯＡネットワーク内のいずれかのノードへ、又は、ＳＯＡネットワーク内の特定のノード（例えば、近いノード）へ、上記検索クエリを送信してもよい。他の例として、一実施形態では、ノードマネージャ５１０は、（例えば、特定のサービスの属性以外の属性に加えて）特定のサービスの属性に基づいてネットワークのトポロジを決定してもよい。

例えば、図７Ａ、図７Ｂ及び図８に関連して一連のブロックが説明され、信号フローの順序が説明されたが、ブロック及び／又は信号フローの順序は、他の実装では変更されてもよい。さらに、非依存のブロック及び／又は信号フローは並列に実行されてもよい。

上述したシステム及び／又は方法は、各図に示す実装において、多くの異なる形態のソフトウェア、ファームウェア、及びハードウェアで実装され得ることが理解されるであろう。これらのシステム及び方法を実装するのに使用される実際のソフトウェアコード又は専用の制御ハードウェアは、各実施形態を限定するものではない。よって、システム及び方法の動作および挙動は、特定のソフトウェアコードを参照せずに記載された。すなわち、ソフトウェア及び制御ハードウェアは、本明細書の記載に基づくシステム及び方法を実装するように設計され得ることが理解される。

さらに、前述のある特定の部分が、１つ以上の機能を実行する構成要素として実装されてもよい。構成要素とは、本明細書で使用される場合、プロセッサ、ＡＳＩＣ、若しくはＦＰＧＡといったハードウェア、又はハードウェアとソフトウェアとの組み合わせ（例えば、ソフトウェアを実行するプロセッサ）を含み得る。本明細書で使用される「例示的な」という用語は、「説明のための例として」を意味する。

「ｃｏｍｐｒｉｓｅｓ」／「ｃｏｍｐｒｉｓｉｎｇ」という用語は、本明細書で使用される場合、記述される特徴、整数、ステップ又は構成要素の存在を特定するようにとられるが、１つ以上の他の特徴、整数、ステップ、構成要素若しくはそのグループの存在又は追加を排除しない、ということが強調されるべきである。

本出願で使用されるいかなる要素、動作、または命令も、特に明示しない限り、実施形態にとって不可欠または本質的であると解釈すべきではない。また、本明細書で使用する場合、冠詞の「ａ」は１つ以上の項目を含むことが意図されている。さらに、「〜に基づいて（ｂａｓｅｄ ｏｎ）」という句は、特に明示しない限り、「少なくとも一部は〜に基づいて」を意味するものである。

Claims (15)

1. 方法であって、
   （ａ）ローカルサービスレジストリにおいてクライアントから特定のサービスについての検索クエリを受信すること
   を含み、
   前記ローカルサービスレジストリは、前記ローカルサービスレジストリに登録されたサービスを列挙するローカルデータベースを含み、
   前記ローカルサービスレジストリは、サービスレジストリのネットワーク内にあり、
   前記方法は、
   （ｂ）前記ローカルデータベースに問い合わせて、前記検索クエリを満たすサービスの第１のリストを決定することと、
   （ｃ）前記特定のサービスの属性以外の属性に基づいて、サービスレジストリの前記ネットワーク内の近隣サービスレジストリであって、前記ローカルサービスレジストリの近隣にある前記近隣サービスレジストリを判定することと、
   （ｄ）前記近隣サービスレジストリに登録されたサービスを列挙する近隣データベースを含む前記近隣サービスレジストリへ、前記検索クエリを送信することと、
   （ｅ）前記近隣サービスレジストリに登録された、前記検索クエリを満たすサービスの第２のリストを、前記近隣サービスレジストリから受信することと、
   （ｆ）前記検索クエリを満たすサービスの前記第１のリスト及び前記第２のリストを前記クライアントに返すことと、
   を含む、方法。
2. 前記特定のサービスの前記属性は、特定の属性であり、
   前記検索クエリは、前記特定のサービスと、前記特定のサービスの前記特定の属性とを識別し、
   前記近隣サービスレジストリを判定することは、前記特定の属性以外の属性に基づいて前記近隣サービスレジストリを判定することを含み、
   前記近隣サービスレジストリを判定することは、複数の近隣サービスレジストリから前記近隣サービスレジストリを判定することを含み、
   サービスレジストリの前記ネットワーク内のサービスレジストリのいくつかは、近隣サービスレジストリではない、
   請求項１に記載の方法。
3. 前記近隣サービスレジストリを判定することは、複数の属性に基づいて前記近隣サービスレジストリを判定することを含み、
   前記複数の属性は、前記特定のサービスの属性ではなく、
   前記複数の属性の各々は、重み付けされる、
   請求項２に記載の方法。
4. 前記検索クエリは、前記特定のサービスをデータストレージとして示し、
   前記サービスの前記属性以外の前記属性は、帯域幅、地理的な位置、開放チャネル、レイテンシ、マルチキャストキャパシティ、ホップ数、コスト又はネットワークタイプを含む、
   請求項１に記載の方法。
5. サービスレジストリの前記ネットワークは、サービスレジストリのツリーネットワークである、請求項２に記載の方法。
6. （ｇ）前記近隣サービスレジストリにおいて前記検索クエリを受信することと、
   （ｈ）前記近隣サービスレジストリに問い合わせて、前記検索クエリを満たすサービスの前記第２のリストを決定することと、
   （ｉ）前記第２のリストを前記ローカルサービスレジストリへ送信することと、
   をさらに含む、請求項１に記載の方法。
7. 前記近隣サービスレジストリは、要求するサービスレジストリであり、
   前記方法は、
   （ｊ）サービスの前記第２のリストが十分であるかを判定し、サービスの前記第２のリストが十分ではない場合に、
   前記特定のサービスの前記属性以外の前記属性に基づいて、サービスレジストリの前記ネットワーク内の他の近隣サービスレジストリであって、前記要求するサービスレジストリの近隣にある前記他の近隣サービスレジストリを判定し、
   前記他の近隣サービスレジストリに登録されたサービスを列挙する他の近隣データベースを含む前記他の近隣サービスレジストリへ、前記検索クエリを送信し、
   前記他の近隣サービスレジストリに登録された、前記検索クエリを満たすサービスの他のリストを、前記他の近隣サービスレジストリから受信すること、
   をさらに含み、
   前記第２のリストは、前記他のリストを含み、
   前記方法は、
   （ｋ）次に続く他のノードにおいて要素（ｊ）を繰り返すこと
   をさらに含む、請求項６に記載の方法。
8. 装置を含むシステムであって、
   前記装置は、
   サービスレジストリのネットワーク内にあるローカルサービスレジストリに登録されたサービスを列挙するローカルデータベースを記憶するメモリと、
   プロセッサであって、
   クライアントから特定のサービスについての検索クエリを受信し、
   前記ローカルデータベースに問い合わせて、前記検索クエリを満たすサービスの第１のリストを決定し、
   前記特定のサービスの属性以外の属性に基づいて、サービスレジストリの前記ネットワーク内の近隣サービスレジストリであって、前記ローカルサービスレジストリの近隣にある前記近隣サービスレジストリを判定する
   前記プロセッサと、
   前記近隣サービスレジストリに登録されたサービスを列挙する近隣データベースを含む前記近隣サービスレジストリへ前記検索クエリを送信する送信機と、
   前記近隣サービスレジストリに登録された、前記検索クエリを満たすサービスの第２のリストを、前記近隣サービスレジストリから受信する受信機と、
   を含み、
   前記プロセッサは、前記検索クエリを満たすサービスの前記第１のリスト及び前記第２のリストを、前記クライアントに返す、
   システム。
9. 前記特定のサービスの前記属性は、特定の属性であり、
   前記検索クエリは、前記特定のサービスと、前記特定のサービスの前記特定の属性とを識別し、
   前記プロセッサは、前記特定の属性以外の属性に基づいて、前記近隣サービスレジストリを判定する、
   請求項８に記載のシステム。
10. 前記プロセッサは、複数の属性に基づいて前記近隣サービスレジストリを判定し、
    前記複数の属性は、前記特定のサービスの属性ではなく、
    前記プロセッサは、前記複数の属性の各々を重み付けする、
    請求項９に記載のシステム。
11. 前記検索クエリは、前記特定のサービスをデータストレージとして示し、
    前記サービスの前記属性以外の前記属性は、帯域幅、地理的な位置、開放チャネル、レイテンシ、マルチキャストキャパシティ、ホップ数、コスト又はネットワークタイプを含む、
    請求項８に記載のシステム。
12. サービスレジストリの前記ネットワークは、サービスレジストリのツリーネットワークであり、又は、サービスレジストリの前記ネットワークは、サービスレジストリのメッシュネットワークである、請求項９に記載のシステム。
13. 前記システムは、他の装置をさらに含み、
    前記他の装置は、
    前記近隣データベースを記憶するメモリと、
    前記検索クエリを受信する受信機と、
    前記近隣データベースに問い合わせて、前記検索クエリを満たすサービスの第２のリストを決定するプロセッサと、
    前記ローカルサービスレジストリへ前記第２のリストを送信する送信機と、
    を含む、
    請求項８に記載のシステム。
14. 前記近隣サービスレジストリは、要求するサービスレジストリであり、
    前記他の装置内の前記プロセッサは、サービスの前記第２のリストが十分であるかを判定し、サービスの前記第２のリストが十分ではない場合に、前記特定のサービスの前記属性以外の前記属性に基づいて、サービスレジストリの前記ネットワーク内の他の近隣サービスレジストリであって、前記要求するサービスレジストリの近隣にある前記他の近隣サービスレジストリを判定し、
    前記プロセッサは、前記他の近隣サービスレジストリに登録されたサービスを列挙する他の近隣データベースを含む前記他の近隣サービスレジストリへ、前記検索クエリを送信し、
    前記受信機は、前記他の近隣サービスレジストリに登録された、前記検索クエリを満たすサービスの他のリストを、前記他の近隣サービスレジストリから受信し、
    前記第２のリストは、前記他のリストを含む、
    請求項１３のシステム。
15. 前記システムは、前記他の装置のように、前記検索クエリを満たすサービスを引き続き検索するように構成されるメモリ、受信機、プロセッサ及び送信機を含む追加の装置をさらに含む、請求項１４に記載のシステム。
    

Images