一実施形態では、方法は、(a)ローカルサービスレジストリにおいてクライアントから特定のサービスについての検索クエリを受信すること、を含み得る。この実施形態では、上記ローカルサービスレジストリは、上記ローカルサービスレジストリに登録されたサービスを列挙するローカルデータベースを含む。上記ローカルサービスレジストリは、サービスレジストリのネットワーク内にある。上記方法は、(b)上記ローカルデータベースに問い合わせて、上記検索クエリを満たすサービスの第1のリストを決定すること、を含み得る。上記方法は、(c)上記特定のサービスの属性以外の属性に基づいて、サービスレジストリの上記ネットワーク内の近隣サービスレジストリであって、上記ローカルサービスレジストリの近隣にある上記近隣サービスレジストリを判定すること、を含み得る。上記方法は、(d)上記近隣サービスレジストリへ上記検索クエリを送信すること、を含み得る。この実施形態では、上記近隣サービスレジストリは、上記近隣サービスレジストリに登録されたサービスを列挙する近隣データベースを含む。上記方法は、(e)上記近隣サービスレジストリに登録された、上記検索クエリを満たすサービスの第2のリストを、上記近隣サービスレジストリから受信すること、を含み得る。上記方法は、(f)上記検索クエリを満たすサービスの上記第1のリスト及び上記第2のリストを上記クライアントに返すこと、を含み得る。この実施形態の見込まれる利点のいくつかは、次のパラグラフで説明される。
一実施形態では、サービスレジストリは上記ネットワーク内の装置間で分散しており、上記サービスレジストリは同一でなくてもよい。このケースでは、サービスは、ローカルサービスレジストリに登録され得る。そのように、サービスレジストリは、上記ネットワーク内の全てのサービスに気付いていなくてもよいが、ローカルサービスに氣づき得る。上記ローカルサービスレジストリが、上記検索クエリを満たすことができない場合には、上記クエリは、近くのサービスレジストリ(例えば、上記ローカルサービスレジストリの近くの1つ以上の近隣サービスレジストリ)へ転送されることが可能である。見込まれる利点として、この実施形態は、(上記ネットワーク内の装置間で分散されない中央のサービスレジストリとは対照的に)より卓越した耐障害性(fault tolerance)を提供し得る。他の見込まれる利点として、この実施形態は、(上記ネットワーク内の装置において単に複製されたサービスレジストリとは対照的に)同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、(潜在的に)高い耐障害性及び低いネットワークトラフィックを伴う効率的な手法でサービスを検索し、見つけることを可能にし得る。他の見込まれる利点は、特定のサービスを検索する場合に、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。
上述したように、一実施形態では、特定のサービスについての検索要求(クエリ)は、上記ネットワーク内の近隣サービスレジストリへ転送され得る。近隣ノードは、検索される上記特定のサービスの属性以外の属性に基づいて判定される。例えば、データストレージサービスについての要求は、ネットワークレイテンシ(例えば、データストレージ以外の属性)に基づいて近隣サービスレジストリへ転送され得る。見込まれる利点として、この手法で近隣ノードを選択することは、ローカルで提供されないサービスを迅速に見つけることを可能にし得る。
一実施形態では、上記特定のサービスの上記属性は、特定の属性であり、上記検索クエリは、上記特定のサービスと、上記特定のサービスの上記特定の属性とを識別する。この実施形態では、上記方法は、上記特定の属性以外の属性に基づいて上記近隣サービスレジストリを判定することを含む。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。他の見込まれる利点は、特定のサービスを検索する場合に、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。
他の実施形態では、上記方法は、複数の属性に基づいて上記近隣サービスレジストリを判定することを含む。上記複数の属性は、上記特定のサービスの属性ではなく、上記複数の属性の各々は、重み付けされる。この実施形態の利点は、上記特定のサービスの属性ではない1つ以上の属性を検索が考慮することを可能にする。属性を重み付けすることは、異なる重みを与えながら異なる属性を使用するという利点を提供し得る。
他の実施形態では、上記検索クエリは、データストレージとして上記特定のサービスを示す。上記サービスの上記属性以外の上記属性は、帯域幅、地理的な位置、開放チャネル、レイテンシ、マルチキャストキャパシティ、ホップ数、コスト又はネットワークタイプを含む。
一実施形態では、サービスレジストリの上記ネットワークは、サービスレジストリのツリーネットワークである。他の実施形態では、サービスレジストリの上記ネットワークは、サービスレジストリのメッシュネットワークである。ツリーネットワーク及びメッシュネットワークの見込まれる利点は、それぞれサービスを並列で(且つ潜在的には効率的な手法で)検索することを可能にするということである。ツリーネットワークの見込まれる利点は、(メッシュネットワークと比べて)ツリーネットワークはネットワークトラフィックを減らし得るということ(例えば、より少ない検索及びより少ないマッチング結果)である。メッシュネットワークの見込まれる利点は、(ツリーネットワークと比べて)メッシュネットワークはより速くより並列であり得るということである。
一実施形態では、上記方法は、また、(g)上記近隣サービスレジストリにおいて上記検索クエリを受信することと、(h)上記近隣サービスレジストリに問い合わせて、上記検索クエリを満たすサービスの上記第2のリストを決定することと、(i)上記第2のリストを上記ローカルサービスレジストリへ送信することと、を含み得る。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。
一実施形態では、上記近隣サービスレジストリは、要求するサービスレジストリである。この実施形態では、上記方法は、(j)サービスの上記第2のリストが十分であるかを判定することを含む。サービスの上記第2のリストが十分ではない場合に、上記方法は、上記特定のサービスの上記属性以外の上記属性に基づいて、サービスレジストリの上記ネットワーク内の他の近隣サービスレジストリであって、上記要求するサービスレジストリの近隣にある上記他の近隣サービスレジストリを判定すること、を含み得る。サービスの上記第2のリストが十分ではない場合に、上記方法は、上記他の近隣サービスレジストリに登録されたサービスを列挙する他の近隣データベースを含む上記他の近隣サービスレジストリへ、上記検索クエリを送信すること、を含み得る。サービスの上記第2のリストが十分ではない場合に、上記方法は、上記他の近隣サービスレジストリに登録された、上記検索クエリを満たすサービスの他のリストを、上記他の近隣サービスレジストリから受信すること、を含み得る。上記第2のリストは、上記他のリストを含む。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。例えば、結果が十分な場合に、さらなる近隣ノードへ上記クエリを必ずしも送信する必要もなく、検索は停止し得る。
一実施形態では、上記方法は、次に続く(successive)他のノードにおいて要素(j)を繰り返すことを含む。見込まれる利点として、この実施形態は、結果が十分になるまで上記クエリが上記ネットワークを通じて伝わることを可能にする。
本明細書では、システムも説明される。上記システムは、装置を含み得る。当該装置は、ローカルサービスレジストリに登録されたサービスを列挙するローカルデータベースを記憶するメモリを含む。この実施形態では、上記ローカルサービスレジストリは、サービスレジストリのネットワーク内にある。上記装置は、クライアントから特定のサービスについての検索クエリを受信するプロセッサも含み得る。この実施形態では、上記プロセッサは、また、上記ローカルデータベースに問い合わせて、上記検索クエリを満たすサービスの第1のリストを決定し、上記特定のサービスの属性以外の属性に基づいて、サービスレジストリの上記ネットワーク内の近隣サービスレジストリであって、上記ローカルサービスレジストリの近隣にある上記近隣サービスレジストリを判定し得る。この実施形態では、上記装置は、上記近隣サービスレジストリへ上記検索クエリを送信する送信機を含む。このケースでは、上記近隣サービスレジストリは、上記近隣サービスレジストリに登録されたサービスを列挙する近隣データベースを含む。この実施形態における上記装置は、上記近隣サービスレジストリに登録された、上記検索クエリを満たすサービスの第2のリストを、上記近隣サービスレジストリから受信する受信機、も含み得る。上記プロセッサは、上記検索クエリを満たすサービスの上記第1のリスト及び上記第2のリストを、上記クライアントに返す。この実施形態の見込まれる利点のいくつかは、次のパラグラフで説明される。
一実施形態では、サービスレジストリは上記ネットワーク内の装置間で分散しており、上記サービスレジストリは同一でなくてもよい。このケースでは、サービスは、ローカルサービスレジストリに登録され得る。そのように、サービスレジストリは、上記ネットワーク内の全てのサービスに気付いていなくてもよいが、ローカルサービスに氣づき得る。上記ローカルサービスレジストリが、上記検索クエリを満たすことができない場合には、上記クエリは、近くのサービスレジストリ(例えば、上記ローカルサービスレジストリの近くの1つ以上の近隣サービスレジストリ)へ転送されることが可能である。見込まれる利点として、この実施形態は、(上記ネットワーク内の装置間で分散されない中央のサービスレジストリとは対照的に)より卓越した耐障害性(fault tolerance)を提供し得る。他の見込まれる利点として、この実施形態は、(上記ネットワーク内の装置において単に複製されたサービスレジストリとは対照的に)同期のためのネットワークトラフィックを減らし得る。他の見込まれる利点として、この実施形態は、(潜在的に)高い耐障害性及び低いネットワークトラフィックを伴う効率的な手法でサービスを検索し、見つけることを可能にし得る。他の見込まれる利点は、特定のサービスを検索する場合に、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。
上述したように、一実施形態では、特定のサービスについての検索要求(クエリ)は、上記ネットワーク内の近隣サービスレジストリへ転送され得る。近隣ノードは、検索される上記特定のサービスの属性以外の属性に基づいて判定される。例えば、データストレージサービスについての要求は、ネットワークレイテンシ(例えば、データストレージ以外の属性)に基づいて近隣サービスレジストリへ転送され得る。見込まれる利点として、この手法で近隣ノードを選択することは、ローカルで提供されないサービスを迅速に見つけることを可能にし得る。
一実施形態では、上記特定のサービスの上記属性は、特定の属性であり、上記検索クエリは、上記特定のサービスと、上記特定のサービスの上記特定の属性とを識別する。この実施形態では、上記プロセッサは、上記特定の属性以外の属性に基づいて、上記近隣サービスレジストリを判定し得る。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。他の見込まれる利点は、特定のサービスを検索する場合に、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。
一実施形態では、上記プロセッサは、上記プロセッサは、複数の属性に基づいて上記近隣サービスレジストリを判定する。上記複数の属性は、上記特定のサービスの属性ではない。上記プロセッサは、上記複数の属性の各々を重み付けする。この実施形態の利点は、上記特定のサービスの属性ではない1つ以上の属性を検索が考慮することを可能にする。属性を重み付けすることは、異なる重みを与えながら異なる属性を使用するという利点を提供し得る。
一実施形態では、上記検索クエリは、データストレージとして上記特定のサービスを示す。上記サービスの上記属性以外の上記属性は、帯域幅、地理的な位置、開放チャネル、レイテンシ、マルチキャストキャパシティ、ホップ数、コスト又はネットワークタイプを含む。
一実施形態では、サービスレジストリの上記ネットワークは、サービスレジストリのツリーネットワークである。他の実施形態では、サービスレジストリの上記ネットワークは、サービスレジストリのメッシュネットワークである。ツリーネットワーク及びメッシュネットワークの見込まれる利点は、それぞれサービスを並列で(且つ潜在的には効率的な手法で)検索することを可能にするということである。ツリーネットワークの見込まれる利点は、(メッシュネットワークと比べて)ツリーネットワークはネットワークトラフィックを減らし得るということ(例えば、より少ない検索及びより少ないマッチング結果)である。メッシュネットワークの見込まれる利点は、(ツリーネットワークと比べて)メッシュネットワークはより速くより並列であり得るということである。
上記システムは、他の装置をさらに含み得る。上記他の装置は、上記近隣データベースを記憶するメモリを含み得る。上記他の装置は、上記検索クエリを受信する受信機と、上記近隣データベースに問い合わせて、上記検索クエリを満たすサービスの第2のリストを決定するプロセッサと、を含み得る。上記他の装置は、上記ローカルサービスレジストリへ上記第2のリストを送信する送信機を含み得る。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。
一実施形態では、上記近隣サービスレジストリは、要求するサービスレジストリである。この実施形態では、上記他の装置内の上記プロセッサは、サービスの上記第2のリストが十分であるかを判定する。上記プロセッサは、また、サービスの上記第2のリストが十分ではない場合に、上記特定のサービスの上記属性以外の上記属性に基づいて、サービスレジストリの上記ネットワーク内の他の近隣サービスレジストリであって、上記要求するサービスレジストリの近隣にある上記他の近隣サービスレジストリを判定し得る。上記プロセッサは、また、上記他の近隣サービスレジストリに登録されたサービスを列挙する他の近隣データベースを含む上記他の近隣サービスレジストリへ、上記検索クエリを送信し得る。上記受信機は、上記他の近隣サービスレジストリに登録された、上記検索クエリを満たすサービスの他のリストを、上記他の近隣サービスレジストリから受信し得る。上記第2のリストは、上記他のリストを含む。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。例えば、結果が十分な場合に、さらなる近隣ノードへ上記クエリを必ずしも送信する必要もなく、検索は停止し得る。
上記システムは、上記他の装置のように、上記検索クエリを満たすサービスを引き続き検索するように構成されるメモリ、受信機、プロセッサ及び送信機を含む追加の装置も含み得る。見込まれる利点として、この実施形態は、結果が十分になるまで上記クエリが上記ネットワークを通じて伝わることを可能にする。
別の実施形態では、方法は、特定のサービスに対応するサービスレジストリのネットワークのトポロジを決定することを含み得る。この実施形態では、上記サービスレジストリの各々は、対応するサービスレジストリに登録されたサービスのインスタンスを列挙する。上記トポロジを決定することは、サービスレジスタの各々について、上記特定のサービスの属性以外の属性に基づいて1つ以上の近隣サービスレジストリを判定することを含み得る。この実施形態の利点は、より卓越した耐障害性を含み、同期のためのネットワークトラフィックを減らし得る。さらに他の見込まれる利点として、この実施形態は、効率的な手法でサービスを検索し、見つけることを可能にし得る。
サービスレジストリのネットワークトポロジは、複数のノードのネットワーク上のオーバレイネットワークであり得る。そのような実施形態では、上記方法は、上記サービスレジストリについての複数のトポロジであって、異なる特定のサービスに各々対応する当該複数のトポロジを決定することを含み得る。見込まれる利点として、当該トポロジに従って次に続く近隣ノードに問い合わせることは、ローカルで提供されないサービスを迅速に見つけることを可能にし得る。
異なるトポロジは、異なる見込まれる利点を有し得る。例えば、上記ネットワークのツリートポロジ及びメッシュトポロジの両方の1つの見込まれる利点は、それぞれ並列にサービスを検索することを可能にするということである。ツリートポロジの見込まれる利点は、(メッシュネットワークと比べて)ツリートポロジはネットワークトラフィックを減らし得るということである。メッシュトポロジの見込まれる利点は、(ツリーネットワークと比べて)メッシュトポロジはより速くより並列であり得るということである。さらに、1つの見込まれる利点は、検索される上記特定のサービスに基づいて好適な又は最良のトポロジ(ツリー、メッシュ、又はその他)が選択され得るということである。
以下の詳細な説明は、添付の図面を参照する。異なる図面における同一の参照番号は、同一の又は同様の要素を識別する。
以下に説明するように、装置のネットワークは、ネットワークを通じて通信し得るし、一連の様々なサービスを提供するシステムの一部を形成し得る。異なる装置は、異なる時間に異なるサービスを提供し得る。システムは、好ましくは効率的で且つ信頼性の高い手法で、特定のサービスを提供する装置を探し、又は検索する必要があり得る(例えば技術的問題を導入する)。
異なる装置により提示されるサービスを発見する問題を解決するために、装置は、提示されるサービスをサービスレジストリ内に登録し得る。一解決策/一実施形態では、上記サービスレジストリは、ネットワーク内で集中させられ得る。そのような解決策/実施形態では、ネットワーク内の全てのサービスが、中央のサービスレジストリ内に登録される。1つの中央のサービスレジストしかないので、当該1つの中央のサービスレジストリは常に同期し、維持するのが相対的に容易である。しかしながら、中央のサービスレジストは、単一障害点(single point of failure)を作る(即ち、他の技術的問題)。即ち、上記中央のサービスレジストリに障害が起こると、サービスは、見つけるのが不可能でなければ困難であり得る。さらに、中央のサービスレジストリは、良好にスケーリングしない(別の技術的問題)。即ち、ネットワークが急激に成長する場合に、サービスレジストリの処理スピード及び利用可能な帯域幅も急激に成長する。
一解決策/実施形態では、サービスレジストリは、ネットワーク内の装置間で分散され得る(例えば、レジストリの完全なコピーが複製され得る)。この解決策/実施形態は、集中されたサービスレジストリを超えてさらなる耐障害性を可能にする。一方、ネットワークが成長すると、装置間でのレジストリの同期がますます困難になり、ネットワークトラフィックが問題点になり得る(即ち、他の技術的問題)。
さらに別の解決策/実施形態では、サービスレジストリは、ネットワーク内の装置間で分散されるが、サービスレジストリは同一ではないかもしれない。この実施形態では、サービスは、ローカルサービスレジストリに登録され得る。サービスレジストリは、ネットワーク内の全てのサービスに気づかなくてもよいが、ローカルサービスに氣づき得る。よって、ローカルに提供されていないサービスを見つけることは、難題をもたらし得る(即ち、技術的問題)。ネットワーク内のサービスを見つけるために、この解決策/実施形態は、(サービスを探す)クライアントに、ローカルサービスレジストリにサービスを要求すること(例えば、ローカルサービスレジストリにクエリを送信すること)を可能にする。ローカルサービスレジストリが要求を満たせない場合には、当該要求は、近くのサービスレジストリ(例えば、上記ローカルサービスレジストリの近くの1つ以上の近隣サービスレジストリ)へ転送されることが可能である。このソリューション/実施形態は、(中央のサービスレジストリとは対照的に)卓越した耐障害性を可能にし(例えば、見込まれる利点)、(完全に分散されたサービスレジストリとは対照的に)同期のためのネットワークトラフィックを減らす(例えば、他の見込まれる利点)。一解決策/一実施形態では、特定のサービスについての検索要求(クエリ)は、ネットワーク内の近隣サービスレジストリへ転送され得る。当該近隣ネットワークノードは、検索される上記特定のサービスの属性以外の属性に基づいて選択される。例えば、データストレージサービスについての要求が、ネットワーク遅延(例えば、データストレージ以外の属性)に基づいて近隣サービスレジストリへ転送され得る。この解決策/実施形態に従って近隣ノードを選択することは、ローカルで提供されないサービスを迅速に見つけることを可能にし得る(例えば、他の見込まれる利点)。他の見込まれる利点は、特定のサービスを検索するために、検索される当該特定のサービスの属性以外の属性に基づいて上記近隣サービスレジストリを判定できることである。
図1は、説明されたシステム及び/又は方法が実装されることが可能である例示的な環境100のブロック図である。図1の実施形態に示されるように、環境100は、ネットワーク110、サブネットワーク120−A〜120−N(集合で「サブネットワーク120」と呼ばれ、また、個別に「サブネットワーク120」と呼ばれる)、装置130A−A〜130N−K(集合で「装置130」と呼ばれ、個別に「装置130」と呼ばれる)、及び管理装置150を含む。装置130−N−Kは、サブネットワーク120−N内のK番目の装置130に言及する。この実施形態では、環境100内のコンポーネントは、サービス指向アーキテクチャ(SOA)システムサービスバス140を形成する。
ネットワーク110は、サブネットワーク120及び/又は装置130が互いに通信することを可能にする。ネットワーク110は、1つ以上の回線交換ネットワーク及び/又はパケット交換ネットワークを含み得る。例えば、一実施形態では、ネットワーク110は、ローカルエリアネットワーク(LAN)、広域ネットワーク(WAN)、メトロポリタンエリアネットワーク(MAN)、公衆回線電話網(PSTN)、アドホックネットワーク、イントラネット、インターネット、光ファイバネットワーク、無線ネットワーク、及び/又は、これらの若しくは他のタイプのネットワークの組合せを含む。
サブネットワーク120は、LAN(例えば、レイヤ2ネットワーク)及び/又はプライベートネットワーク(例えば、レイヤ3ネットワーク)を含み得る。サブネットワーク120は、1つ以上の装置130を相互接続させ得る。例えば、サブネットワーク120−Aは、装置130−A−A〜130−A−Jを相互接続させ得る。装置130は、例えば、SOAシステムサービスバス140を介して通信するいずれかの装置を含み得る。
装置130は、PHP(Hypertext Preprocessor)サーバ装置、Cプログラムサーバ装置、リナックスサーバ装置、ウィンドウズサーバ装置及び/若しくは他のタイプのサーバ装置などのサーバコンピュータ装置; ウィンドウズ、リナックス、アンドロイド、iOS及び/又は他のオペレーティングシステムを実行するデスクトップ、ラップトップ、タブレット、携帯通信装置及び/若しくは他のタイプのパーソナルコンピュータ装置などのパーソナルコンピュータ装置; 可視光カメラ、赤外線(IR)カメラ及び/若しくは熱紋(heat signature)カメラなどの監視装置(monitoring device); マイクロフォン、モーションセンサ、熱センサ、圧力センサ及び/若しくは他のタイプのアラームセンサなどのアラームセンサ; マイクロコントローラコンピュータ装置; 並びに/又は、他のタイプのコンピュータ装置を含み得る。装置130は、サブネットワーク120に接続されているように示されているが、特定の装置130は、ネットワーク110に直接的に接続されていなくてもよい。
一実施形態では、SOAシステムサービスバス140は、既存のネットワークトポロジの上に装置130間で実装される。SOAシステムサービスバス140は、異なるタイプの装置130、及び/又は異なるプラットフォームを使用して実装された装置130が、サービス指向アーキテクチャを使用して通信することを可能にする。SOAシステムサービスバス140は、第1の装置130がいずれかの装置130(例えば、それ自身又は他の装置130)に特定のサービスを要求することを可能にし得る。よって、第1の装置130により提供されるクライアント(例えば、それ自体「サービス」又は「クライアントサービス」)は、(例えば、サービスが第1の装置130において利用可能でない場合に)第2の装置130により提供されるサービスを求め得る。(例えば、第2の装置130における)他のサービスを要求する(例えば第1の装置130における)第1のサービスは、要求を開始したので、「クライアント」又は「クライアントサービス」と呼ばれる。上記第1のサービスは、例えば、ネットワーク内の他のサービスへサービスを提供してもよい。
一実施形態では、サービスは、標準化されたサービスインタフェースを介してアクセスされる。各タイプのサービスは、特定のサービスインタフェース(例えば、異なるサービスインタフェース)に関連付けられ得る。よって、サービスを要求するクライアントは、サービスインタフェースを用いて通信し得る。また、上記クライアントは、上記サービスの実際の実装について非依存(agnostic)であり得る。換言すると、各実装が他の実装に関係していなくてもよいように、サービスの実装は、サービスインタフェースにより定義されるプロトコルを使用して互いに通信する。特定のサービスインタフェースに関連付けられている、実行しているサービスの実装は、サービスインスタンスと呼ばれ得る。サービスホスト(例えば、サービスを提供する装置)を含む装置130は、サービスレジストリ(例えば、サービスのリスト又はデータベース)を用いて、利用可能なサービスインスタンスを記録し得る。SOAシステムサービスバス140は、装置130内のサービスホストのサービスレジストリを検索することにより、要求されたサービス見つけることを、装置130の通信に可能にし得る。
管理装置150は、管理者がSOAシステムサービスバス140を構成し又は管理することを可能にし得る。例えば、管理装置150は、ポータブル通信装置(例えば、携帯電話、スマートフォン、ファブレット装置、GPS(Global Positioning System)装置、及び/若しくは他のタイプの無線装置); パーソナルコンピュータ若しくはワークステーション; サーバ装置; ラップトップ、タブレット若しくは他のタイプのポータブルコンピュータ; 及び/又は通信ケイパビリティを有するいずれかのタイプの装置を含み得る。
ネットワーク110のように、サブネットワーク120は、1つ以上の回線交換ネットワーク及び/又はパケット交換ネットワークを含み得る。例えば、サブネットワーク120は、LAN、WLAN、MAN、PSTN、アドホックネットワーク、イントラネット、インターネット、光ファイバネットワーク、無線ネットワーク、及び/又は、これらの若しくは他のタイプのネットワークの組合せを含み得る。
図1は、環境100の例示的なコンポーネントを示すが、他の実装では、環境100は、図1に描かれたものと比べて、より少ないコンポーネント、異なるコンポーネント、異なるように配置されたコンポーネント、又は追加のコンポーネントを含んでもよい。さらに、又は、あるいは、環境100内のいずれか1つの装置(又は装置のいずれかのグループ)は、環境100内の1つ以上の他の装置により行うように説明された機能を行ってもよい。
図2は、装置130の例示的なコンポーネントを説明するブロック図である。図2に示されるように、装置130は、バス210、プロセッサ220、メモリ230、入力装置240、出力装置250及び通信インタフェース260を含み得る。
バス210は、装置120のコンポーネント間の通信を可能にするパスを含み得る。プロセッサ220は、命令を解釈し実行するいずれかのタイプのシングルコアプロセッサ、マルチコアプロセッサ、マイクロプロセッサ、ラッチベースのプロセッサ、及び/若しくは処理ロジック(又はプロセッサ、マイクロプロセッサ及び/若しくは処理ロジックのファミリー)を含み得る。他の実施形態では、プロセッサ220は、ASIC(Application-Specific Integrated Circuit)、FPGA(Field Programmable Gate Array)、及び/又は、他のタイプの集積回路若しくは処理ロジックを含んでもよい。
メモリ230は、プロセッサ220による実行のための情報及び/若しくは命令を記憶し得るいずれかのタイプの揮発性及び/若しくは動的ストレージ装置、並びに/又は、プロセッサ220による使用のための情報を記憶し得るいずれかのタイプの不揮発性ストレージ装置を含み得る。例えば、メモリ230は、ランダムアクセスメモリ(RAM)若しくは他のタイプの動的ストレージ装置、リードオンリメモリ(ROM)装置若しくは他のタイプの静的ストレージ装置、連想メモリ(content addressable memory:CAM)、磁気及び/若しくは光学記録メモリ装置及びその対応装置(例えば、ハードディスクドライブ、光学ドライブなど)、並びに/又は、フラッシュメモリなどの取り外し可能な形式のメモリを含み得る。
入力装置240は、オペレータが装置130に情報を入力することを可能にする。例えば、入力装置240は、キーボード、マウス、ペン、マイクロフォン、リモートコントローラ、音声キャプチャ装置、イメージ及び/若しくはビデオキャプチャ装置、タッチスクリーンディスプレイ、並びに/又は他のタイプの入力装置を含み得る。一実施形態では、装置130は、遠隔で管理されてもよく、入力装置240を含まなくてもよい。換言すると、装置130は、「ヘッドレス」であってもよく、例えばキーボードを含まなくてもよい。
出力装置250は、装置130のオペレータへの情報を出力し得る。出力装置250は、ディスプレイ、プリンタ、スピーカ及び/又は他のタイプの出力装置を含み得る。例えば、装置130は、ディスプレイを含んでもよく、当該ディスプレイは、顧客にコンテンツを表示するためのLCD(Liquid Crystal Display)を含んでもよい。一実施形態では、装置130は、遠隔で管理されてもよく、出力装置250を含まなくてもよい。換言すると、装置130は、「ヘッドレス」であってもよく、例えばディスプレイを含まなくてもよい。
通信インタフェース260は、装置130が他の装置及び/又はシステムと通信することを可能にする送受信機(例えば、送信機及び/又は受信機)を含み得る。通信インタフェース260は、無線通信(例えば、高周波(Radio Frequency)、赤外線、及び/又は可視光など)、有線通信(例えば、導線、ツイストペアケーブル、同軸ケーブル、伝送線、光ファイバケーブル、及び/又は導波管など)、又は、有線通信及び無線通信の組合せを介して、通信し得る。通信インタフェース260は、ベースバンド信号を高周波(RF)信号に変換する送信機、及び/又は、RF信号をベースバンド信号に変換する受信機を含み得る。通信インタフェース260は、信号を送受信するためのアンテナに結合され得る。
通信インタフェース260は、入力ポート及び/若しくは出力ポート、入力システム及び/若しくは出力システム、並びに/若しくは、他の装置へのデータの送信を容易にする他の入出力コンポーネントを含む、論理的なコンポーネントを含み得る。例えば、通信インタフェース260は、無線通信のためのネットワークインタフェースカード(例えば、イーサネットカード)、及び/又は、無線通信のための無線ネットワークインタフェース(例えば、Wi−Fi)カードを含み得る。通信インタフェース260は、ケーブルを通じた通信のためのUSB(Universal Serial Bus)ポート、Bluetooth(登録商標)無線インタフェース、RFID(Radio-Frequency Identification)インタフェース、NFC(Near-Field Communication)無線インタフェース、及び/又は、1つの形式から他の形式へデータを変換する他のタイプのインタフェースも含み得る。
以下に説明するように、装置130は、SOAネットワーク内のサービス(例えば、近くのサービス)を見つけることに関するある動作を行い得る。装置130は、メモリ230などのコンピュータに読み取り可能な媒体に含まれるソフトウェア命令をプロセッサ220が実行するのに応じて、これらの動作を行い得る。コンピュータに読み取り可能な媒体は、不揮発性メモリ装置を含む。メモリ装置は、単一の物理的なメモリ装置内に実装されてもよく、又は、複数の物理的なメモリ装置にわたって散在してもよい。ソフトウェア命令は、他のコンピュータに読み取り可能な媒体又は他の装置からメモリ230へ読み込まれてもよい。メモリ230に含まれるソフトウェア命令は、プロセッサ220に、本明細書で説明されるプロセスを行わせ得る。あるいは、ハードワイヤード(例えば、固定の)回路が、ソフトウェア命令の代わりに、又はソフトウェア命令と組み合せて使用されて、本明細書で説明されるプロセスを実装してもよい。よって、本明細書で説明される実装は、ハードウェア回路及びソフトウェアのいずれかの特定の組み合せに限定されない。
図2は、装置130の例示的なコンポーネントを示すが、他の実装では、装置130は、図2に描かれたものと比べて、より少ないコンポーネント、異なるコンポーネント、追加のコンポーネント、又は異なるように配置されたコンポーネントを含んでもよい。さらに、又は、あるいは、装置130の1つ以上のコンポーネントは、装置130の1つ以上の他のコンポーネントにより行われるように説明された1つ以上のタスクを行ってもよい。管理装置150は、装置130と同様に構成されてもよい。
図3は、装置130の例示的な通信レイヤを説明するブロック図である。装置130の機能コンポーネントは、例えば、メモリ230からの命令を実行するプロセッサ220により実装され得る。さらに、又は、あるいは、装置130の機能コンポーネントは、1つ以上のASICのハードワイヤード(例えば固定の)回路を用いて実装されてもよい。図3に示されるように、装置130は、サービスレイヤ130、オーバレイネットワークレイヤ320及び装置レイヤ330を含み得る。
一実施形態では、サービスレイヤ310は、クライアントが特定のサービスタイプのサービスインスタンスを検索することを可能にし、クライアントが特定のサービスインスタンスへ要求を送信することを可能にする。サービスは、一実施形態では、サービスの実際の実装に非依存である標準化されたサービスインタフェースを介してアクセスされ得る。サービスインスタンスは、明示的な境界(boundary)と関連付けられ得る。この実施形態では、装置130上で実行される特定のプロセス、及び/又は、装置130上に記憶される特定のデータは、曖昧さなしに、サービスインスタンス内に、又はサービスインスタンスの外に存在する。サービスインスタンスは、他のサービスインスタンスについて自律的であり得る。例えば、特定のサービスインスタンスは、当該特定のサービスインスタンスと相互作用する他のサービスインスタンスに悪影響を与えることなく修正され得る(例えば、コードが書き換えられ得る)。サービスは、(同一のタイプの又は異なるタイプの)他のサービスインスタンスとスキーマ及び/又はコントラクトを共有し得るが、一実施形態では、サービス実装を共有しない。スキーマは、上記サービスインタフェースにより送信され又は受信されるメッセージのフォーマット及び内容を特定する。コントラクトは、上記サービスインタフェースにより送信され又は受信されるメッセージの許容されるシーケンスを特定する。
一実施形態では、オーバレイネットワークレイヤ320は、既存のネットワークトポロジの上にオーバレイネットワークを実装する。オーバレイネットワークレイヤ320は、ファイアウォールを通じてトラフィックをルーティングすること、及び/又は、下層のネットワークトポロジにおけるネットワークアドレス変換(NAT)を扱うことを、担い得る。一実施形態では、(例えば下層のネットワークトポロジとは異なり得る)オーバレイネットワークトポロジは、ツリー構造で組織化されたノードを含む。オーバレイネットワークトポロジは、論理的にノードを接続する。他の実施形態では、オーバレイネットワークトポロジは、異なるタイプの構造(例えば、メッシュトポロジ)を含んでもよい。装置130内の各サービスホストは、オーバレイネットワーク内のノードに対応し得るし、ノードIDを割り当てられ得る。装置130上のノードは、複数のサービスホスト及び/又は複数のノードを含み得る。装置130は、1つのノードに対応する1つのホストを含むように説明され得る。ノードは、ルーティングツリーのようなネットワークトポロジを介して接続され得る。ノードは、ルーティングツリーを介して他のノードへメッセージを送信し得る。一実施形態では、ノードは、メッセージにオーバレイネットワークトポロジを横断(traverse)させることなく、下層のネットワークトポロジを介して他のノードへ上記メッセージを送信し得る。各ノードは、(下層ネットワークと同様に)オーバレイネットワーク内の近隣に到達するための情報(例えば、ネットワーク110などの下層ネットワークのアドレス)を記憶し得る。オーバレイネットワークレイヤ320は、ノード間の通信レイヤに対応し得るし、複数のネットワークトポロジを使用して特定の機能を実現し得る。例えば、特定のタイプのサービスのためのサービスレジストリを検索する場合に、オーバレイネットワークレイヤ320は、サービスレジストリを検索している間に、ノードのツリーの端を横断し得る。一実施形態では、第1のノードから第2のノードへメッセージを送信する場合に、オーバレイネットワークレイヤ320は、ツリーの端を追うことによってよりも、上記第1のノードから上記第2のノードへ直接的にメッセージを送信し得る。オーバレイネットワークレイヤ320は、サービスレイヤ310にノードIDを提供し得る。サービスレイヤ310は、下層のネットワークトポロジを知る必要もなく、特定のノードIDへメッセージを送信し得る。
一実施形態では、装置レイヤ330は、SOAシステムサービスバス140の初期のインストールの間に装置の発見(device discovery)を行う。装置レイヤ330及び/又はオーバレイネットワークレイヤ320は、初期のインストールの後でノードの発見(node discovery)も行い得るし、及び/又は、オフラインになって後にオーバレイネットワークに再度参加したロスト(lost)ノードを再発見し得る。一実施形態では、オーバレイネットワークレイヤ320は、証明書などの、ノードに各々のIDを検証することを可能にする、オーバレイネットワークについての共有秘密(shared secret)を管理する。オーバレイネットワークレイヤ320は、1つ以上の近さのメトリックに基づいて、オーバレイネットワークのためのトポロジ(例えば、ルーティングツリー又はメッシュ)を形成し得る。しかしながら、第1のノードから第2のノードへのメッセージは、ルーティングツリーを横断する必要はなく、その代わりに、第1のノードから第2のノードへ直接的に送信されてもよい。他の実施形態では、第1のノードから第2のノードへのメッセージは、ルーティングツリーを横断する。さらに、オーバレイネットワークレイヤ320は、マルチキャストグループに基づいてマルチキャストメッセージを送信し得る。さらに、オーバレイネットワークレイヤ320は、サービスレイヤ310にサービス品質(QoS)保証を提供し得る。
ネットワークレイヤ320は、概して「ノード」を扱い、装置レイヤ330は、概して「装置」を扱う。装置レイヤ330は、下層のネットワークトポロジ(例えば、ネットワーク110及び/又はサブネットワーク120)を使用して通信するのに必要な機能性を含む装置130の低レベルの機能性に対応する。例えば、装置レイヤ330は、OSI(Open Systems Interconnection)モデルのレイヤ1〜6(例えば、物理レイヤ、データリングレイヤ、ネットワークレイヤ、トランスポートレイヤ、セッションレイヤ及びプレゼンテーションレイヤ)を実装し得る。これらのレイヤの実装は、イーサネットフレームのルーティング、インターネットプロトコル(IP)パケットのルーティング、セッション管理、パケットの暗号化及び解読、ロストパケットの再送などを含み得る。
図3は、装置130の例示的な機能コンポーネントを示すが、他の実装では、図3に描かれたものと比べて、装置130は、より少ない機能コンポーネント、異なる機能コンポーネント、異なるように配置された機能コンポーネント、又は追加の機能コンポーネントを含んでもよい。さらに、又は、あるいは、装置130内のいずれか1つのコンポーネント(又はコンポーネントのいずれかのグループ)は、装置130内の1つ以上の他の機能コンポーネントにより行われるように説明された機能を行ってもよい。
図4Aは、サービスレイヤ310の例示的な機能コンポーネントを説明するブロック図である。図4Aに示されるように、サービスレイヤ310は、サービスホスト415を含む。サービスホスト415は、1つ以上のサービス410−A〜410−N(集合で「サービス410」と呼ばれ、また、個別に「サービス410」と呼ばれる)、1つ以上のクライアント420−A〜420−K(集合で「クライアント420」と呼ばれ、また、個別に「クライアント420」と呼ばれる)、メッセージディスパッチャ(message dispatcher)430、及びサービスレジストリ440を含み得る。
サービス410は、装置130のサービスレイヤ310のサービスホスト415に関連付けられるサービスインスタンスに対応する。一実施形態では、サービス410は、サービスインタフェース412及びサービス実装414を含む。サービスインタフェース412は、標準化された通信プロトコルなどの通信プロトコルを含み得る。一実施形態では、通信プロトコルは、固有の名称及びバージョンを含む。サービスインタフェース412は、SOAP(Simple Object Access Protocol)インタフェース仕様、JSON(JavaScript Object Notation)インタフェース仕様、及び/又は他のタイプのインタフェース仕様を使用して規定され得る。サービス実装414は、サービス410の実装を含む。サービス実装414は、サービスインタフェース412経由で受信される要求を処理し、及び/又は、サービスインタフェース412を通じてサービス要求に応答する。サービスインタフェース412は、サービス実装414から受信される応答を、適当なプロトコルに準拠した特定のフォーマットに変換する。クライアント420は、当該適当なプロトコルを使用して、サービス410とメッセージを交換する。
一実施形態では、クライアント420は、サービスレジストリ440へ要求を送信することにより、特定のサービスタイプのサービスインスタンスを要求する。サービスインスタンスが識別され、選択されると、クライアント420は、メッセージディスパッチャ430経由で、識別され選択された特定のサービスインスタンスへ要求を送信し得る。上述したように、クライアント420は、サービス410でもあってもよい。「クライアント」又は「クライアントサービス」という用語は、サービスを、別のサービスを要求しているものとみなす。
メッセージディスパッチャ430は、クライアント420からの入力メッセージを受信し、当該入力メッセージの対象とするサービス410に当該入力メッセージを向ける。さらに、メッセージディスパッチャ430は、サービスからメッセージを受信し、特定のクライアント420へ当該メッセージを送信し得る。入力メッセージの宛先が、メッセージディスパッチャ430と同じ装置130上にはない場合には、その後、当該入力メッセージは、正しい装置130への転送のために、オーバレイネットワークレイヤ320へ転送され得る。サービス410及びクライアント420は、オーバレイネットワークレイヤ320により実装されるオーバレイネットワーク内のエンドポイント(endpoint)として機能し得る。よって、一実施形態では、オーバレイネットワークレイヤ320は、オーバレイネットワークのルーティングツリーに基づいてルーティングテーブルを維持し得る。ルーティングテーブルは、特定のノードIDについて次のホップ宛先のリストを含み得る。メッセージディスパッチャ430は、出力IDについて次のホップ宛先を識別し得るし、配信のためにオーバレイネットワークレイヤ320にメッセージを提供し得る。よって、この実施形態では、メッセージディスパッチャ430は、要求−応答メッセージングメカニズムを実装する。
サービスレジストリ440は、配置されたサービス(例えば、サービスのインスタンス)と関連付けられた属性とともに、当該配置されたサービス410のリストを維持する。サービスレジストリ440の例示的なコンポーネントを、図4Cを参照して以下により詳細に説明する。サービス410は、(例えば、サービスの属性を含む)サービスの記述をサービスレジストリ440に提供することにより、サービスレジストリ440に登録し得る。クライアント420は、サービス410でもあってもよいので、クライアント420も、サービスレジストリ440に登録してもよい。
図4Bは、サービスレジストリ440の機能性を説明するブロック図である。図4Bに示されるように、サービスレジストリ440は、クライアント420から検索クエリ(search query)を受信し得る。検索クエリは、特定のサービスタイプ、当該特定のサービスについての1つ以上の要求される属性、要求されるヒット数、及び/又は1つ以上の他のパラメータを特定し得る。サービスレジストリ440は、上記検索クエリを満たすサービス410を識別し得る。要求されるヒット数が、サービスレジストリ440によって満たされない場合には、サービスレジストリ440は、オーバレイネットワーク内の他のサービスレジストリ440(例えば、隣接したサービスレジストリ440)へクエリを転送し得る。一実施形態では、サービスレジストリ440は、検索クエリに基づいて特定のサービスインスタンスを選択しない。それどころか、この実施形態では、サービスレジストリ440は、上記クエリの結果をクライアント420に返し、上記クエリを発信したクライアント420は、上記検索結果から特定のサービスインスタンスを選択し得る。他の実施形態では、サービスレジストリ440は、上記クエリの結果から、上記検索クエリに基づいて、特定のサービスインスタンスを選択する。
図4A及び図4Bは、サービスレイヤ310の例示的な機能コンポーネントを示すが、他の実装形態では、図4A及び図4Bに描かれたものと比べて、サービスレイヤ310は、より少ない機能コンポーネント、異なる機能コンポーネント、異なるように配置された機能コンポーネント、又は追加の機能コンポーネントを含んでもよい。さらに、サービスレイヤ310内のいずれか1つのコンポーネント(又はコンポーネントのいずれかのグループ)は、サービスレイヤ310内の1つ以上の他の機能コンポーネントにより行われるように説明された機能を行ってもよい。
図4Cは、サービスレジストリ440の例示的な機能コンポーネントを説明するブロック図である。図4Cに示されるように、サービスレジストリ440は、ホストサービスレジストリデータベース(DB)442、クエリハンドラ444及びサービスレジストリキャッシュ446を含み得る。
ホストサービスレジストリDB442は、サービスホスト415により提供されるサービス410のリスト及び/又はこれらのサービスの属性を維持する。ホストサービスレジストリDB442において列挙されるサービスと当該サービスの属性との例は、図4Cに関連して以下に提供される。ホストレジストリDB442は、サービスレジストリ440に登録するサービス410により住まれ(populate)得る。
ホストサービスレジストリDB442は、列挙されるサービスを追加し又は削除するための、及び、サービスホスト415により提供されるサービスの属性を読み又は書くためのインタフェースもさらし得る。一実施形態では、例えば、ホストサービスレジストリDB442は、異なる装置130上のサービスホスト415により提供されるサービス410のリストを維持し得る。上記異なる装置上のサービスホスト415は、されされた上記インタフェースを使用して他の装置上のサービスレジストリ内のサービスを列挙し得る。さらに、ホストサービスレジストリDB442は、他のサービスレジストリによりアクセス可能な検索クエリサービスインタフェースをさらし得る。よって、他のサービスレジストリは、上記検索クエリサービスインタフェースを使用して、ホストサービスレジストリDB442が特定のクエリを満たすエントリを含むかを判定し得る。一実施形態では、DB442が無効な(outdated)情報を記憶するのを防ぐのを助けるために、ホストサービスレジストリDB442内に列挙されるサービスは失効し得る(例えば、リフレッシュされていなければしばらくするとDB442から削除される)。
クエリハンドラ444は、クライアント420から受信されるクエリを処理(handle)し得る。一実施形態では、クエリが与えられると、クエリハンドラ444は、まず、ローカルのホストサービスレジストリDB442を検索し、その後にサービスレジストリキャッシュ446が続く。クエリハンドラ444は、例えば上記クエリが満たされない場合に、他のサービスレジストリにコールを出し得る。サービスレジストリキャッシュ446は、遠隔のサービスレジストリ440からのデータを記憶し得る。各サービスホスト415は、ローカルサービスレジストリ440を維持し得る。サービスホスト415に登録するサービス410は、ローカルサービスレジストリ440内に登録される。ローカルサービスレジストリ440により満たされない、クライアント420からのクエリは、1つ以上の近隣のサービスホスト415へ送信されて、上記クエリを満たすサービスを含むサービスレジストリ440を上記近隣のサービスホスト415が有するかが調べられ得る。上記遠隔のサービスレジストリ440は、ローカルサービスレジストリ440に上記クエリの結果を返し得る。当該結果は、サービスレジストリキャッシュ446内に記憶され得る。いくつかの実施形態では、親ノードが、子ノードについてのデータをキャッシュし得る。一方、子ノードは、その親ノードについてのデータをキャッシュしなくてもよい。一実施形態では、キャッシュ446が無効な情報を記憶するのを防ぐのを助けるために、サービスレジストリキャッシュ446に列挙されるサービスは失効し得る(例えば、リフレッシュされていなければしばらくするとキャッシュ446から削除される)。
図4Cは、サービスレジストリ440の例示的な機能コンポーネントを示すが、他の実装では、図4Cに描かれたものと比べて、サービスレジストリ440は、より少ない機能コンポーネント、異なる機能コンポーネント、異なるように配置された機能コンポーネント、又は追加の機能コンポーネントを含んでもよい。さらに、サービスレジストリ440のいずれか1つのコンポーネント(又はコンポーネントのいずれかのグループ)は、サービスレジストリ440内の1つ以上の他の機能コンポーネントにより行われるように説明された機能を行ってもよい。
図4Dは、特定のサービスについての例示的な属性テーブル460のブロック図である。一実施形態では、サービスのインスタンス(例えば、各インスタンス)は、テーブル460のような属性テーブルに関連付けられる。ホストサービスレジストリDB442は、対応するサービスレジストリ440に登録された各サービスについての属性テーブルを記憶し得る。一実施形態では、上述したように、いずれか1つのサービスレジストリDB442内に記憶される情報は、他のサービスレジストリデータベース内に記憶される情報と異なり得る。例示的な属性テーブル460は、IDフィールド462,インタフェースフィールド464、サービスフォーマットフィールド468、トランスポートプロトコルフィールド470、CPUランキングフィールド472、ディスクスペースフィールド474及びRAMフィールド476という8つのフィールドを含む。
インスタンスIDフィールドは、特定のサービスのインスタンスを一意に定義する。(ノードIDとともに)インスタンスIDは、ネットワーク内の(同一のタイプ又は異なるタイプの)他のサービスからサービスインスタンスを一意に識別し得る。一実施形態では、インスタンスIDフィールド462は整数である。テーブル460では、インスタンスIDは、例えば6529である。
インタフェースフィールド464は、サービスのインタフェースの名称である。このケースでは、インタフェースフィールド464は、インタフェースのタイプによりサービスのタイプも識別する。例えば、テーブル460は、インタフェースを「ストレージサービス」として識別する。サービスフォーマットフィールド468は、サービスのインスタンスにより使用されるフォーマットを識別する。例えば、テーブル460は、サービスフォーマットを「JSON」として識別する。トランスポートプロトコルフィールド470は、サービスのインスタンスにより使用されるプロトコルを識別する。例えば、テーブル460は、サービスフォーマットを「ノードプロトコル」として識別する。
CPUランキングフィールド472は、サービスインスタンスに関連付けられるCPUのパフォーマンスを識別する。一実施形態では、スケールが使用される(例えば、1〜100)。テーブル460は、CPUランキングフィールド742において、サービスについてCPUランキングを20/100として識別する。RAMフィールド476は、サービスに利用可能なランダムアクセスメモリの量を識別する。テーブル460は、フィールド476において、利用可能なRAMを2GBとして識別する。
図4Dは、属性テーブル460の例示的なコンポーネントを示すが、他の実施形態では、図4Dに描かれたものと比べて、属性テーブル460は、より少ないコンポーネント、異なるコンポーネント、異なるように配置されたコンポーネント、又は追加のコンポーネントを含んでもよい。
図5Aは、オーバレイネットワークレイヤ320の機能コンポーネントを説明するブロック図である。図5Aに示されるように、オーバレイネットワークレイヤ320は、ノードマネージャ510、通信マネージャ520及びマルチキャストマネージャ530を含み得る。ノードマネージャ510は、ノードIDなどのノード情報を、オーバレイネットワーク内の他のノードに提供し得る。さらに、ノードマネージャ510は、オーバレイネットワーク内のノードのリストを維持し得る。ノードマネージャ510は、ノード発見(discovery)を実行して、オーバレイネットワークに追加される新たなノードを識別し、及び/又は、オーバレイネットワークに再度参加したロストノードを再発見し得る。ノードマネージャ510は、また、以下に説明されるようにネットワークのトポロジ(例えば、どのノードが最も近い他のノードであるか)を判定し得る。
通信マネージャ520は、ノードが互いに通信することを可能にし得る。通信マネージャ520は、オーバレイネットワークのツリーを横断するメカニズムを実装し得る。サービスレジストリの検索クエリに関連して、又は、他のノードへの直接的な通信方法が利用可能ではない場合に、ツリー横断が実行され得る。さらに、通信マネージャ520は、オーバレイネットワークのツリーを横断する必要なくオーバレイネットワークの特定のノードが直接的に通信することを可能にし得る直接的な通信方法を実装し得る。
マルチキャストマネージャ530は、マルチキャストメカニズムを実装し得る。当該マルチキャストメカニズムが使用されて、マルチキャストグループのメンバ(例えば、全てのメンバ)へメッセージが送信され得る。さらに、上記マルチキャストメカニズムが使用されて、加入通知メッセージパターンが実装され得る。よって、特定のサービスインスタンスに関連付けられるイベントが使用されて、上記特定のサービスインスタンスからのメッセージに加入(subscribe)したノードへ送信されるメッセージがトリガされ得る。マルチキャストマネージャ530は、アプリケーションレイヤマルチキャストマネージャ、又は、より低いOSIレイヤからのマルチキャストマネージャを含み得る。
図5Aは、オーバレイネットワークレイヤ320の例示的な機能コンポーネントを示すが、他の実施形態では、オーバレイネットワークレイヤ320は、図5Aに描かれたものと比べて、より少ない機能コンポーネント、異なる機能コンポーネント、異なるように配置された機能コンポーネント、又は追加の機能コンポーネントを含んでもよい。さらに、オーバレイネットワークレイヤ320のいずれか1つのコンポーネント(又はコンポーネントのいずれかのグループ)は、オーバレイネットワークレイヤ320内の1つ以上の他の機能コンポーネントにより行われるように説明された機能を行ってもよい。
図5Bは、オーバレイネットワーク540の例示的なトポロジのブロック図である。図5Bの例に示されるように、オーバレイネットワーク540はノードN1〜N7を組む。ノードN1及びN2は、マルチキャストグループ560−1内にある。ノードN1は、サービスエンドポイントS1及びS3、並びにクライアントエンドポイントC1を含む。ノードN3は、ノードN1及びN2にとっての親ノードである。ノードN3は、サービスエンドポイントS7及びクライアントエンドポイントC3を含む。
ノードN6及びN7は、マルチキャストグループ560−2内にあり、ノードN7は、クライアントエンドポイントC2及びサービスエンドポイントS5及びS6を含む。ノードN5は、ノードN6及びN7にとっての親ノードであり、サービスエンドポイントS9を含む。ノードN3及びN5は、マルチキャストグループ560−3内にある。ノードN4は、ノードN3及びN5にとっての親ノードであり、オーバレイネットワーク540のルートノードである。さらに、ノードN4は、マルチキャストグループ560−4内にあり、サービスエンドポイントS8を含む。ネットワーク540のトポロジ内の親ノードは2つの子ノードを有するが、他の実装では、親ノードは、2つを超える子ノードを有してもよい。
各サービスエンドポイントは、サービスレジストリ440に関連付けられるとすると、検索クエリは、以下のようにオーバレイ機能ネットワーク540を横断し得る。サービスエンドポイントS7は、検索クエリを実行して、サービスエンドポイントS1及びサービスエンドポイントS5に含まれる(即ち、S1及びS5がマッチする)特定のサービスを見つける(例えば識別し又は検索する)。サービスエンドポイントS7は、ローカルサービスレジストリに上記検索クエリを送信し得る。上記検索クエリにおいてマッチなしという結果になり得る。その後、上記ローカルサービスレジストリは、オーバレイネットワーク内の隣接するサービスレジストリを識別し得る。当該隣接するサービスレジストリは、ノードN1内のサービスレジストリ、及びノードN4内のサービスレジストを含み得る(ノード2に関連付けられるサービスエンドポイントがないので、ノードN2はサービスレジストリを含まなくてもよい)。ノードN1内のサービスレジストリは、サービスエンドポイントS1を識別するヒットを返し得る。ノードN4内のサービスレジストリは、いずれのヒットも返さなくてもよく、隣接するサービスレジストリへ上記検索クエリを転送し得る。このケースでは、当該隣接するサービスレジストリは、ノードN3及びN5内のサービスレジストリを含む。しかしながら、ノードN3内のサービスレジストリは、検索を既に処理したので、上記検索クエリは、ノードN5内のサービスレジストリへのみ送信され得る。ノードN5におけるサービスレジストリは、ヒットせず、ノードN7におけるサービスレジストリへ上記検索クエリを転送し得る。ノードN7は、サービスエンドポイントS5をヒットとして識別し得る。そして、ノードN7は、上記検索クエリの結果をノードN4へ返し得る。ノードN4は、ノードN3内のサービスエンドポイントS7へ検索結果を転送し得る。
図6A及び図6Bは、サービスレジスタ440のネットワークを形成する(例えば、サービスホスト415(図4を参照)を各々含む)ノードの他の例示的なネットワーク600のトポロジ(例えば、ツリーネットワーク)のブロック図である。ネットワーク600は、ノードP〜Uという6つのノードを含む。ノードPは、ノードQ及びノードRという2つの子を有する。ノードRは、いずれの子も有しない。ノードQは、ノードS、ノードT及びノードUという3つの子を有する。ネットワーク600の例では、各ノードは、図4Aに示されるコンポーネント(例えば、サービス410、クライアント420、メッセージディスパッチャ430及びサービスレジストリ440)を含み得るサービスホスト415に対応する。
図6Bは、サービスホスト(例えば、サービスホスト415−P〜415−U)とサービスレジストリ(例えば、レジストリ440−P〜440−U)との関係を示す。例えば、ネットワーク600の例について、各サービスホストは、対応するクライアント(クライアント420−P〜420−U、図示せず)及び対応するサービス(サービス410−P〜410−U、図示せず)も含む。さらに、各サービスレジストリ440−P〜440−Uは、ホストサービスレジストリDB(DB442−P〜442−U、図示せず)、クエリハンドラ(クエリハンドラ444−P〜444−U)及びサービスレジストリキャッシュ(例えば、キャッシュ446−P〜446−U)を含む。
述べられたように、クライアントが、特定のサービスを検索する場合に、当該検索は、トポロジに従って1つのノードから他のノードへネットワークを通じて伝わり得る。上記ネットワークトポロジは、検索される上記特定のサービスによって異なり得る。例えば、ストレージキャパシティの検索は、特定のタイプのトランスコーダ(transcoder)の検索とは異なるネットワークトポロジに関連付けられ得る。図7Aは、一実施形態におけるSOAネットワークのトポロジを決定するための例示的なプロセス700Aのフローチャートである。ノードマネージャ510(図5Aを参照)は、プロセス700Aを行い、また、周期的に行い得る。しかしながら、他の実装形態では、環境100内のいずれかの装置が、プロセス700Aの全て又は一部を行ってもよい。
一実施形態では、ノードマネージャ510は、ネットワークトポロジを生成する特定のサービスを選択する(ブロック702)。例えば、ノードマネージャ510は、ネットワークについてのトポロジを構築するサービスとして「ストレージサービス」を選択し得る。他の実施形態では、ノードマネージャ510は、特定のサービスを考慮しないが、ノードの属性(例えば、処理速度)又は1つのノードと他のノードとの関係の属性(例えば、帯域幅)などの1つ以上の属性に基づいて(ブロック702)、トポロジを生成する。
ノードマネージャ510は、1つ以上の属性に基づいてネットワークのトポロジを決定し得る。特定のサービスが選択される場合に(ブロック702)、ノードマネージャ510は、当該特定のサービスの属性以外の属性に基づいてトポロジを決定し得る。特定のサービスが選択されない場合には、ノードマネージャ510は、当該特定のサービスの属性以外の属性に基づいて、(ブロック702で選択された属性のための)トポロジを決定し得る(例えば、当該トポロジは、上記特定のサービスを検索するために使用され得る)。即ち、(例えば、上記トポロジが、上記特定のサービスを考慮せずに生成されたとしても、)上記トポロジは、特定のサービスを検索するために使用され得る。そのトポロジは、上記特定のサービスの属性以外の属性に基づいて生成された。したがって、ノードマネージャ510は、また、上記トポロジを生成するための属性(例えば、上記特定のサービスの属性以外の属性)を判定し得る(ブロック706)。例えば、図7Bは、特定のサービスの属性以外の属性を判定するための例示的なプロセス700Bのフローチャートである。属性を判定すること(ブロック706)は、図7Bに示されるプロセス700Bを含み得る。図7Aのプロセス700Aのように、プロセス700Bは、ノードマネージャ510により行われ得る。
ブロック706(図7を参照)を詳述する図7Bに切り替えると、プロセス700Bは、複数の属性を判定し得る。一実施形態では、判定される属性は、上記特定のサービス(ブロック702で選択されたサービス、又は上記トポロジが検索のために使用される場合に検索されるサービス)の属性ではない。例えば、プロセス700Bは、2つのノードが同一のドメイン内にあるかを判定すること(ブロック722)を含み得る。同一のドメイン内のノードは、異なるドメイン内のノードよりも近くにあり得る。例えば、同一のドメイン内のノードは、同じファイアウォールの後方にあるノードであり得る。プロセス706は、ノードがマルチキャスト経由で互いに到達できるかを判定すること(ブロック724)を含み得る。いくつかの実装では、同一のネットワーク内のノード(ブロック722)は、マルチキャスト経由で到達できる(例えば、マルチキャストケイパビリティ)同一のノードであってもよい(ブロック724)。他の実施形態では、マルチキャスト経由で到達可能なノードは、ノードが同一のマルチキャストグループのメンバであることを判定するなどの異なる技術を使用して、判定されてもよい。マルチキャスト経由で到達可能なノードは、マルチキャスト経由で到達可能ではないノードよりも近いとみなされてもよい。
プロセス700Bは、ノードの地理的な位置を判定すること(ブロック726)も含み得る。このケースでは、互いに地理的に近いノードは、地理的に離れたノードよりもトポロジにおいてより近いとみなされる。プロセス700Bは、ノード間のレイテンシ及び/又はノード間の利用可能な帯域を判定すること(ブロック728)を含み得る。低いレイテンシを伴うノードは、高いレイテンシを伴うノードよりもネットワーク内でより近いとみなされ得る。ノード間の高い帯域幅を伴うノードは、低い帯域幅を伴うノードよりもネットワーク内でより近いとみなされ得る。
プロセス700Bは、ノードのストレージキャパシティを判定すること(ブロック730)を含み得る。プロセス700Bは、ノードのプロセッサスピード又はクラスを判定することも含み得る(ブロック732)。高いストレージキャパシティ及び高いプロセッサスピードを伴うノードは、例えば、トポロジにおいて親ノードとなり得る。(例えば検索される上記特定のサービスの属性以外の)属性であって、図7Bに示される属性以外の当該属性が、判定されてもよい。例えば、(例えば上記特定のサービスの属性以外の)属性は、いずれかの2つのノード間でチャネルが存在し開放されているか(例えばオープンチャネル)、いずれかの2つのノード間の(例えば下層の物理ネットワーク内での)ホップ数、2つのノード間でデータを搬送するための(例えば通貨での)コスト(例えば携帯加入サービス)、地理的な位置(例えば、データが特定の国を通貨するか)、及び/又はネットワークタイプ(例えば、光ファイバ、WiFi、セルラーなど)を含んでもよい。
図7Aに戻ると、ノードマネージャ510は、ネットワークトポロジを決定するために、属性を(例えば当該属性の各々のための重みで)重み付けし得る(ブロック708)。重み付けされた属性に基づいて、ノードマネージャ510は、他のノードとの各ノードの近さを判定できる(ブロック710)。一実施形態では、近さの判定は、一部において、上記特定のサービスの属性以外の属性に基づく(ブロック710)。上記近さに基づいて、ノードマネージャ510は、(ブロックS702で決定された)上記特定のサービス、又は(ブロック702で決定された)選択された属性についてのネットワークのトポロジを決定できる(ブロック712)。例えば、上記トポロジは、とりわけツリーネットワーク又はメッシュネットワークであり得る。
一実施形態では、ノードマネージャ510は、サービスごとに異なるトポロジを決定し得る。例えば、ノードマネージャ510は、「カメラ」についてのトポロジとは異なる、「ストレージサービス」についてのトポロジを決定し得る。一例では、ノードマネージャ510は、レイテンシ又は地理的な位置(又はいずれかの条件の重み付けされた混合)などの異なる条件についてのトポロジを決定し得る。一実施形態では、クライアント420(例えば、検索を要求したクライアント)は、検索を発信する際にトポロジを識別する。異なる条件についてのトポロジをノードマネージャ510が決定するケースでは、トポロジに関連付けられる条件は、例えば、検索条件において検索されているものとして識別される特定のサービスの属性以外の1つ以上の属性を含み得る。この実施形態は、大きな帯域幅を必要とするファイルをストリーミングする場合に、クライアントが「良好は帯域幅でのストレージサービス」を検索することを可能にする。他の例では、この実施形態は、小さいレイテンシを必要とするファイルをストリーミングする場合に、クライアントが「地理的に近い(例えば低いレイテンシの)ストレージサービス」を検索することを可能にする。1つのトポロジが地理的な近さのために使用され、他のトポロジが帯域幅のために使用される。さらに、異なるトポロジが、地理的な近さ及び帯域幅の組合せのために定義され使用されてもよい。上述した例では、帯域幅及び地理的な近さは、検索される特定のサービス(例えば、データストレージ)の属性以外の属性である。
例えば、ネットワーク600は、サービスを検索するために使用される。図8は、SOAネットワークにおいてサービスを検索するための例示的なプロセス800のフローチャートである。例えば、プロセス800は、サービスレイヤ310内のサービスホストにおいて実行し得る。一実施形態では、プロセス800(又はプロセス800の一部)は、繰り返され、及び/又は反復され得る。プロセスの複数のインスタンス(又はプロセスの一部)は、複数のサービスホストにおいて発生し、例えば、上記プロセスは、別のサービスにおいて自身を呼び出す。プロセス800は、図6のネットワーク600に関連して説明される。
プロセス800は、クライアントにおいて検索クエリを形成し、サービスレジストリへ当該クエリが送信されることから始まる。一実施形態では、クライアントは、(例えば、異なるノード内のサービスホスト415と対照的に同一のサービスホスト415内の)ローカルサービスレジストリへ上記クエリを送信する。例えば、ネットワーク600を参照すると、ノードS内のクライアント420−Sは、特定のサービスについてのクエリを形成し、ノードS内のサービスレジストリ440−Sへ上記クエリを送信する(ブロック802)。図8に示されるように、クエリは、(&(インタフェース=ストリーレジサービス)(CPUランキング>10)(ディスクスペース>=500MB)であり得る。上記クエリは、結果の数(例えば、6などのサービス数)を特定し、要求し得る。この例では、上記クエリは、特定のサービス(例えば、「ストレージサービス」)と、当該特定のサービスの特定の属性(例えば、「ディスクスペース>=500MB」)とを特定する。クライアント440−Sにより生成される上記クエリは、クロールする(例えば、横断する、従う、又は移動する)オーバレイネットワークのトポロジを特定し、又は要求し得る。上述したように、上記クエリは、地理的な近さ、レイテンシ、帯域幅、同一の若しくは異なるドメイン、ストレージキャパシティ、プロセッサスピードなど、又は、これらの属性の重み付けされたいずれかの組合せについてのトポロジを特定し得る。
サービスレジストリは、上記クライアントから上記クエリを受信する(ブロック804)。ネットワーク600の例を継続すると、ノードS内のサービスレジストリ440−Sは、クライアント420−S(例えば、ローカルサービスレジストリ)から上記特定のサービスについての上記クエリを受信する。とりわけ、クエリハンドラ444−S(図4Cを参照)が、上記クエリを受信し得る。図8に示され、以下により詳細に示されるように、サービスレジストリは、他のサービスレジストリ(例えば、異なるノード内の異なるサービスホスト415内のサービスレジストリ)からも検索クエリを受信し得る(ブロック804)。
検索クエリを受信すると、上記サービスレジストリは、ホストサービスレジストリDB(例えば、ローカルデータベース)内に登録されているサービスをマッチングするために、当該ホストサービスレジストリDBに問い合わせる(query)(ブロック806)。上述した例を継続すると、クエリハンドラ444−Sは、クライアント420−Kから受信した上記検索クエリを用いて、ホストサービスレジストリDB442−S(図4を参照)に問い合わせる。上記クエリは、上記クエリにマッチする(例えば上記クエリを満たす)登録されたサービスのリスト(例えば、第1のレイスト)をもたらし得る。
上記クエリの結果が十分である場合には(ブロック808:YES)、上記クエリを満たす、上記登録されたサービスの上記リスト(例えば、上記第1のレイスト)は、上記クライアントに返され得る(ブロック810)。十分にマッチする結果は、例えば、上記リスト内のサービスの数と、数(例えば、上記検索クエリ内で上記クライアントにより要求された数、又はデフォルトの数)とを比較することにより、判定され得る。検索結果がクライアントへ返された後に(ブロック810)、プロセス800は、(少なくとも、ブロック803において上記クエリを受信したサービスレジストリ440について)終了し得る。
上述したように、ローカルサービスレジストリ440−Sは、より高速の検索のために遠隔のサービスホストからのサービス情報が記憶されるキャッシュ446−Sを有し得る。よって、クエリハンドラ444−Sは、結果を補うために(又はローカルDB442−Sにおいて不十分な結果がある場合にのみ)サービスレジストリキャッシュ446−Sにも問い合わせる。キャッシュ446−Sからの結果は、上記クライアントに返されるサービスの上記リストの中に含まれ得る。
サービスレジストリ440−Sは、マッチするサービスの検索のために他のサービスレジストリをドラフト(draft)し得る。検索結果が十分ではない場合に(ブロック808)、サービスレジストリ440−S(例えば、クエリハンドラ)は、近隣ノードを判定するためにトポロジを決定し、及び/又は選択し得る(ブロックS811)。一実施形態では、上記トポロジは、クライアントにより発信される上記クエリにおいて識別され得る。他の実施形態では、上記トポロジは、検索される上記特定のサービスに基づいて選択され得る。さらに他の実施形態では、クエリハンドラ444−Sは、他の要素に基づいて上記トポロジを選択する。選択される上記トポロジは、上述したもの、即ち、地理的な近さ、レイテンシ、帯域幅など、又は重み付けされたそれらのいずれかの組合せを含み得る。一実施形態では、例えば、要求されたトポロジが存在しない場合に、トポロジはオンザフライ(on the fly)で生成され得る。
異なるトポロジが、検索される特定のサービスに依存する他のトポロジよりも良くてもよい(最高のトポロジがブロック811において選択されてもよい)。例えば、検索される上記特定のサービスが、高精細ビデオのストリーミングである場合には、帯域幅は、トポロジのための重要な属性(例えば、ブロック706において選択され、ブロック708において重み付けされる属性)であり得る。一方、例えば、検索される上記特定のサービスが、電話である場合には、レイテンシは、トポロジのための最も重要な属性(例えば、ブロック706において選択され、ブロック708において重み付けされる属性)であり得る。したがって、この実施形態は、検索される上記特定のサービスに最も適したトポロジの選択を可能にする。
クエリハンドラ444−Sは、他の近隣ノードのIDを要求し、受信し得る(ブロック812)。近隣ノードは、例えば、(ブロック811から)選択された上記トポロジにおいて1ホップだけ離れた、ネットワーク(例えば、ネットワーク600)内のノードである。上述したように、上記近隣ノード(例えば、サービスレジストリ)は、検索される上記特定のサービスの属性以外の属性に基づく(例えば最も近いネイバとして前に選択された)ネイバである。例えば、特定のサービス「ストレージサービス」についての近隣サービスレジストリにおいて、(上記サービスの属性以外の)上記属性は、ネットワークレイテンシを含み得る。例示的なネットワーク600を継続すると、サービスレジストリ440−S内のクエリハンドラ444−Sは、ホストサービスレジストリDB442−Sに問い合せ(ブロック806)、3つのマッチするサービス、即ち不十分な数の結果を見つける(ブロック808:NO)(例えば、6つの結果が上記クライアントにより要求された)。結果として、クエリハンドラ444−S(図4Cを参照)は、ネットワークレイヤ320内のノードマネージャ510から(例えば1ホップ離れた)上記近隣ノードのIDを要求する。クエリハンドラ444−Sは、ノードマネージャ510、即ち、図6Aに示されるようにたまたまノードSの親であるノードQから、近隣ノードのリストを受信する。
クエリハンドラは、検索を転送するのに近隣ノード(例えば、近隣サービスレジストリ)が利用可能かを判定する。いずれの近隣ノードも、検索を続けるのに利用可能ではない場合には(ブロック814:NO)、これの標識(indication)が、検索結果があれば検索結果とともに(ブロック810)、上記クライアント(又は要求する他のサービスレジストリ)へ送信され得る。この場合に、プロセス800は、(少なくとも上記クエリを受信したサービスレジストリ415について)終了し得る。クエリハンドラは、ノードマネージャ510が近隣ノードのリストを返す場合でも、いずれの他の近隣ノードも検索のために利用可能ではないと判定し得る。例えば、クエリハンドラは、近隣ノードの上記リスト内の各ノードは同一の検索に参加しており、上記検索クエリを転送するのに利用可能なノードが残されていないと判定し得る。
近隣ノードが検索を続けるのに利用可能である場合には(ブロック814:YES)、サービスレジストリ(例えば、クエリハンドラ)は、上記近隣ノード内の上記サービスレジストリ(例えば、近隣サービスレジストリ)へ上記検索クエリを送信し得る(ブロック816)。現在の例では、クエリハンドラ444−Sは、(例えば、サービスレジストリ440−Qは、検索に参加したとは知られていないので)ノードQが検索を続けるのに利用可能であると判定する(ブロック814:YES)。サービスレジストリ440−Sは、ノードQ内のサービスレジストリ440−Qへ上記検索クエリを転送する(ブロック816)。破線で示されるように、上記近隣ノード内の上記サービスレジストリは、(他のサービスレジストリから上記検索クエリを受信することによりブロック804で開始する)プロセス800の他のインスタンスを発生させ得る。一実施形態では、サービスレジストリ440−Sは、既に見つかったマッチする検索結果の数に基づいて、上記クエリ内の要求される検索結果の数を調整する。以下に詳細に説明するように、最終的には、サービスレジストリ440−Sは、近隣サービスレジストリ440−Qから検索結果(例えば、サービスの第2のリスト)を受信し得る(ブロック818)。サービスレジストリ440−Sは、サービスレジストリ440−Qから受信される結果(例えば、サービスの第2のリスト)を自らの結果(例えば、ブロック806からの上記第1のリスト)と結合し、上記クライアントへ両方のリストを返す。
現在の例では、サービスレジストリ440−Qは、サービスレジストリ440−Sから上記検索結果を受信し(ブロック804)、ホストサービスレジストリDB442−Qに問い合わせる(ブロック806)。サービスレジストリ440−Q内のクエリハンドラ444−Qは、ホストサービスレジストリDB442−Qに問い合わせ(ブロック806)、マッチするいずれのサービスも見つけない。即ち、不十分な数の結果である(ブロック808:NO)。例として、クエリハンドラ444−Qにより受信される上記クエリは、要求される結果の数が3(例えば、6という元の要求から3だけ減算されたもの)であることを示し得る。結果として、クエリハンドラ444−Qは、ノードマネージャ510に近隣ノードのIDを要求する。クエリハンドラ444−Qは、ノードマネージャ510から近隣ノードのリストを受信する。当該近隣ノードは、図6A及び図6Bに示されるようにノードS、ノードT、ノードU及びノードPである。一実施形態では、所定の時間が経過すると、結果の数にかかわらず、結果は十分であるとみなされ得る(ブロック808:YES)。
クエリハンドラ444−Qは、近隣ノードが検索を転送するのに利用可能であるかを判定する(ブロック814)。クエリハンドラ444−Qは、ノードT、ノードU及びノードPが検索を続けるのに利用可能であると判定する(ブロック814:YES)。サービスレジストリ440−Sから上記検索クエリが受信され、ノードSは明らかに検索に既に関与しているので、クエリハンドラ444−QはノードSを含めない。よって、クエリハンドラ444−Qは、近隣ノードT、近隣ノードU及び近隣ノードP内のサービスレジストリへ上記検索クエリを送信する(ブロック816)。破線で示されるように、近隣ノードT、U及びP内のサービスレジストリは、(他のサービスレジストリから上記検索クエリを受信することによりブロック804で開始する)プロセス800の他のインスタンスを発生させ得る。
その後、サービスレジストリ440−Qは、サービスレジストリ440−T、サービスレジストリ440−U、及びサービスレジストリ440−Pへ検索要求を送信する(ブロック816)。上述したように、一実施形態では、サービスレジストリ440−Qは、既に見つかったマッチする検索結果の数に基づいて、上記クエリ内の要求される検索結果の数(例えば、3)を調整する。一実施形態では、全ての利用可能な近隣ノードにおける検索が並列で行われるように、上記検索要求はこれらの近隣ノードへ送信される。他の実施形態において、上記検索要求(例えば、検索クエリ)は、(例えば、各結果が受信された後に、又は時間ウィンドウの後に)順に送信されることが可能である。上記検索要求を順に送信することは、(例えば、ブロック814において判定された)全ての利用可能な近隣ノードへ上記検索要求を送信する前に、検索結果が十分であるとサービスレジストリ440−Tが判定すること(ブロック808)を可能にする。サービスレジストリ440Tは、要求を受信し(ブロック804)、ホストサービスレジストリDB442−T内に、クエリにマッチする1つのサービスを見つける。しかしながら、合計4つの検索結果はまだ不十分である(例えば、6よりも少ない)(ブロック808:NO)。サービスレジストリ440−Tは、ネットワークトポロジを決定し、及び/又は選択し(ブロック811)、(例えば1ホップ離れた)近隣ノードのIDのためにオーバレイネットワークレイヤ320のノードマネージャ510へ要求を送信する(ブロック812)。ノードマネージャ510は、サービスレジストリ440−TへノードQのIDを返す(ブロック812)。しかしながら、サービスレジストリ440−Tは、ノードQ内のサービスレジストリ440−Qは既に検索に関与しており、他の利用可能な近隣ノードが残されていない(ブロック814:NO)ということを知っている。サービスレジストリ444−Tは、この結果(及び検索結果)をサービスレジストリ440−Qへ送信し(ブロック810)、サービスレジストリ440−Tにおけるプロセス800は終了する。
サービスレジストリ440−Uも、上記要求を受信するが(ブロック804)、ホストサービスレジストリDB442−Uの検索の間に(ブロック806)、サービスを見つけられず、不十分な数の検索結果が残る(ブロック808:NO)。サービスレジストリ440−Uは、ネットワークトポロジを決定し、及び/又は選択し(ブロック811)、(例えば1ホップ離れた)近隣ノードのIDのためにオーバレイネットワークレイヤ320のノードマネージャ510へ要求を送信する(ブロック812)。ノードマネージャ510は、ノードQのIDをサービスレジストリ440−Uへ返す(ブロック812)。しかしながら、サービスレジストリ440−Uは、ノードQ内のサービスレジストリ440−Qは既に検索に関与しており(サービスレジストリ440−Uはサービスレジストリ440−Qから上記要求を受信しており)、他の利用可能な近隣ノードが残されていない(ブロック814:NO)ということを知っている。そして、サービスレジストリ440−Uは、サービスレジストリ440−Qへこの結果を送信し(ブロック810)、サービスレジストリ440−Tにおけるプロセス800が終了する。
サービスレジストリ440−Pも、上記要求を受信し(ブロック804)、ホストサービスレジストリDB442−P内に、検索クエリにマッチし、又は当該検索クエリを満たす2つのサービスを発見する(ブロック806)。それでもなお、2つの結果は、十分なものよりも少ない(例えば要求される3つよりも少ない)とみなされる(ブロック808:ES)。サービスレジストリ440−Pは、ネットワークトポロジを決定し、及び/又は選択し(ブロック811)、(例えば1ホップ離れた)近隣ノードのIDのためにオーバレイネットワークレイヤ320のノードマネージャ510へ要求を送信する(ブロック812)。ノードマネージャ510は、ノードQ及びRのIDをサービスレジストリ440−Pへ返す(ブロック812)。しかしながら、サービスレジストリ440−Pは、ノードQ内のサービスレジストリ440−Qは既に検索に関与しており(サービスレジストリ440−Pはサービスレジストリ440−Qから上記要求を受信しており)、ただ1つの利用可能な近隣ノードとしてノードRが残されている(ブロック814:YES)ということを知っている。サービスレジストリ444−Pは、サービスレジストリ440−Rへ上記検索結果を送信し(ブロック816)、サービスレジストリ440−Rにおいてプロセス800の他のインスタンスを発生させる。上記検索要求は、要求される結果の数を、(例えば、要求された3と比べて2つの検索結果を反映する)1に調整し得る。
サービスレジストリ440−Rは、上記検索要求を受信し(ブロック804)、ホストサービスレジストリDB442−R内に、検索クエリにマッチし、又は当該検索クエリを満たす1つのサービスを発見する(ブロック806)。1つの結果は十分であるとみなされ(ブロック808:YES)、当該結果はサービスレジストリ440−P(サービスレジストリ440−Rへ検索要求を送信したサービスレジストリ)へ送信される。サービスレジストリ440−Pは、サービスレジストリ440−Rから上記結果(例えば、リスト)を受信し(ブロック818)、受信された当該結果を自らの結果と結合し得る。その後、サービスレジストリ440−Pは、サービスレジストリ440−Q(即ち、サービスレジストリ440−Pが検索に参加することを要求したサービスレジストリ)へ上記結果を送信する。現在の例では、サービスレジストリ440−Pは、3つの結果をサービスレジストリ440−Qへ送信する。サービスレジストリ440−Qは、サービスレジストリ440−Pから上記結果を受信し(ブロック818)、受信された上記結果を自らの結果と結合し、サービスレジストリ440−S(例えば、サービスレジストリ440−Qが検索に参加することを要求したサービスレジストリ)へ上記結果を返す(ブロック818)。現在の例では、サービスレジストリ440−Qは、サービスレジストリ440−Sへ4つの結果を送信する。サービスレジストリ440−Sは、サービスレジストリ440−Qから上記結果(例えば、サービスの第2のリスト)を受信する(ブロック818)。サービスレジストリ440−Sは、サービスレジストリ440−Qから受信された上記結果(例えば、サービスの第2のリスト)を、自らの結果(例えば、ブロック806からの第1のリストからの3つ)と結合し、上記クライアントへ結果を返し得る(ブロック810)。現在の例では、サービスレジストリ440−Sは、7つの結果を上記クライアントへ送信する。
示されるように、クライアントは元のクエリの中で6つの結果を要求したが、7つの結果を受信した。サービスレジストリ440が並列で検索したので、追加の結果が発生し得る。これは、要求されるよりも多くの検索(及びおそらく必要であるよりも多くの計算能力))を示すが、一方で、追加の結果は、完全なデータベースのコピーをノードが必ずしも有しない分散データベースという見込まれる利点のために小さい計算コストである。
一実施形態では、サービスレジストリは、近隣から結果を受信する場合に(ブロック818)、サービスレジストリキャッシュ446内にこれらの結果を記憶し得る。キャッシュ446内に記憶される情報は、TTL(Time-To-Live)を有してもよく、期間の後に削除されてもよい。他の実施形態では、サービスレジストリは、近隣サービスレジストリから結果を受信しない(ブロック818)。代わりに、上記近隣サービスレジストリは、要求する上記クライアントに直接的に上記結果を送信する。この後者の実施形態の利点は、いずれかの進行中の検索の状態、及びサービスレジストリが近隣からの応答を受信したかを、サービスレジストリは必ずしも記憶しなくてもよいということである。一方、この後者の実施形態は、キャッシュ446のサイズを限定し、長期的には検索を遅くし得る。
上記オーバレイネットワークのトポロジの他の例は、メッシュネットワークである。当該メッシュネットワークでは、各ノードは、上記オーバレイネットワーク1つ以上の他のノードに直接的に接続される。上記メッシュネットワーク内の各ノードは、オーバレイネットワークトポロジ内の接続(例えば、予め定義された配信パターン)に従って、自らに接続されるノードへトラフィックを転送し得る。ツリートポロジは、多くのメッシュトポロジのうちの1つとみなされ得る。他の例として、1つのメッシュトポロジは、各ノードを各他のノードに接続し得る。このケースでは、ネットワーク内の各ノードは、検索クエリを受信し得る。クライアント420から当該検索クエリを受信したサービスレジストリ440は、全てのノードから検索結果を受信した後に検索結果をランク付けし得る。
上述したツリートポロジと同様に、(ネットワークトポロジのグループの)異なるメッシュトポロジは、検索される異なる特定のサービス(又は属性の異なるグルーピング)に関連付けられ得る。さらに、メッシュトポロジ内の各接続は、検索される特定のサービスレジストリの属性以外の属性に基づいて確立され得る。例えば、各ノードは、地理的に最も近い4つのノードに接続され得る。他の例として、上記オーバレイネットワークの上記トポロジは、(メッシュかツリーかによらず)手動で構成され得る。一実施形態では、例えば、検索結果は、要求するクライアント420からのサービスのホップ数に基づいてランク付けされ得る。
メッシュネットワークのケースでは、要求される数よりも多くの検索結果が返され得る(したがって、追加の計算リソースが使用される)(即ち、見込まれる技術的問題)。それでもなお、メッシュネットワークは、効率的な手法で分散データベースの並列な検索を可能にし得る(例えば、異なる技術的問題への解決策の候補)。さらに、メッシュトポロジを通じた検索は、ツリートポロジを通じた検索よりも、より速く、より並列的であり得る(例えば、技術的問題への解決策の候補)。しかしながら、メッシュトポロジを通じた検索は、ツリートポロジよりも、より多くのネットワークトラフィック、及びより過剰な検索結果をもたらし得る(例えば、メッシュトポロジの見込まれる技術的問題、及びツリートポロジにより提供される解決策の候補)。
以上の明細書では、添付の図面を参照して様々な好適な実施形態を説明した。しかし、添付の特許請求の範囲に記載される本発明のより広い範囲から逸脱することなく、実施形態に様々な改変及び変更を加えることができ、追加的な実施形態を実現することができることは明らかであろう。本明細書及び図面は、したがって、限定としてではなく例示とみなされるべきである。
例えば、一実施形態では、クライアントは、ローカルサービスホスト又はローカルサービスレジストリ以外のサービスホスト及びサービスレジストリへ検索クエリを送信してもよい(ブロック802)。この実施形態では、上記クライアントは、SOAネットワーク内のいずれかのノードへ、又は、SOAネットワーク内の特定のノード(例えば、近いノード)へ、上記検索クエリを送信してもよい。他の例として、一実施形態では、ノードマネージャ510は、(例えば、特定のサービスの属性以外の属性に加えて)特定のサービスの属性に基づいてネットワークのトポロジを決定してもよい。
例えば、図7A、図7B及び図8に関連して一連のブロックが説明され、信号フローの順序が説明されたが、ブロック及び/又は信号フローの順序は、他の実装では変更されてもよい。さらに、非依存のブロック及び/又は信号フローは並列に実行されてもよい。
上述したシステム及び/又は方法は、各図に示す実装において、多くの異なる形態のソフトウェア、ファームウェア、及びハードウェアで実装され得ることが理解されるであろう。これらのシステム及び方法を実装するのに使用される実際のソフトウェアコード又は専用の制御ハードウェアは、各実施形態を限定するものではない。よって、システム及び方法の動作および挙動は、特定のソフトウェアコードを参照せずに記載された。すなわち、ソフトウェア及び制御ハードウェアは、本明細書の記載に基づくシステム及び方法を実装するように設計され得ることが理解される。
さらに、前述のある特定の部分が、1つ以上の機能を実行する構成要素として実装されてもよい。構成要素とは、本明細書で使用される場合、プロセッサ、ASIC、若しくはFPGAといったハードウェア、又はハードウェアとソフトウェアとの組み合わせ(例えば、ソフトウェアを実行するプロセッサ)を含み得る。本明細書で使用される「例示的な」という用語は、「説明のための例として」を意味する。
「comprises」/「comprising」という用語は、本明細書で使用される場合、記述される特徴、整数、ステップ又は構成要素の存在を特定するようにとられるが、1つ以上の他の特徴、整数、ステップ、構成要素若しくはそのグループの存在又は追加を排除しない、ということが強調されるべきである。
本出願で使用されるいかなる要素、動作、または命令も、特に明示しない限り、実施形態にとって不可欠または本質的であると解釈すべきではない。また、本明細書で使用する場合、冠詞の「a」は1つ以上の項目を含むことが意図されている。さらに、「〜に基づいて(based on)」という句は、特に明示しない限り、「少なくとも一部は〜に基づいて」を意味するものである。