(57)【要約】【課題】  そのそれぞれがそれ自体のレガシー・リソース発見サービスを有する可能性のある、複数の分散および自律コンピューティング・システム内に配置されたリソースを識別し割り振るための方法およびシステムを提供することにある。【解決手段】  分散コンピューティング・システムのそれぞれに配置されたリソース識別サーバは、専用サーバのツリー階層にリソース属性データを伝達する。リソース属性データは、分散コンピューティング・システム内の固有フォーマットで維持され、専用サーバによって提供された共通フォーマットにマッピングされる。リソース属性データは、ツリー階層内の各ノードで集約され、ツリー階層を介して１つまたは複数のルート・ノードに上に伝達され、すべてのノードを介して複製される。定期的なリソース・チェックおよびリソース属性データ更新により、追加のシステム頑強性が提供される。リソース割り振り照会は、階層内の任意のレベル・ノードに提示され、処理のために適切なコンピューティング・システムに転送される。【選択図】  図１
2009541856.tif 000002
【特許請求の範囲】
【請求項１】
分散システム内の連合リソース発見のための方法において、
複数の分散コンピューティング・システム内に配置された複数のリソースに関連するリソース属性データを階層に応じて配置された複数の専用サーバのうちの１つまたは複数に前記分散コンピューティング・システムから伝達するステップであって、前記リソース属性データが前記複数の分散コンピューティング・システム内に配置された前記関連リソースの識別および割り振りを容易にするために十分なものであるステップと、
リソース照会を処理し、前記専用サーバの階層を介して前記照会に適したリソースを含む分散コンピューティング・システムにその照会を経路指定するために、前記専用サーバの階層内の任意の所与の専用サーバで十分な量のリソース属性データを維持するステップと、
を含む、方法。
【請求項２】
前記リソース属性データを複数の固有属性フォーマットで入手するステップであって、各固有属性フォーマットが前記分散コンピューティング・システムのうちの１つによって決定され、それに関連付けられるステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記リソース属性データを伝達する前記ステップが、前記伝達されたリソース属性データを前記複数の固有属性フォーマットから前記複数の専用サーバのうちの少なくとも１つによって提供された共通属性フォーマットにマッピングするステップをさらに含む、請求項２に記載の方法。
【請求項４】
前記リソース属性データを入手する前記ステップが、複数のリソース発見サーバを使用して前記リソース属性データを入手するステップであって、各リソース発見サーバが前記複数の分散コンピューティング・システムのうちの１つに関連付けられるステップを含む、請求項２に記載の方法。
【請求項５】
前記リソース発見サーバのそれぞれに共通属性フォーマットを伝達するステップをさらに含み、
前記リソース属性データを伝達する前記ステップが、
前記専用サーバおよび前記リソース発見サーバのうちの少なくとも１つを使用して、前記伝達されたリソース属性データを前記複数の固有フォーマットから前記複数の専用サーバのうちの少なくとも１つによって提供された共通属性フォーマットにマッピングするステップと、
このマッピングを前記リソース属性データとともに前記専用サーバのうちの１つに伝達するステップと、
をさらに含む、請求項４に記載の方法。
【請求項６】
十分な量のリソース属性データを維持する前記ステップが、前記複数のコンピューティング・システムから前記リソース属性データが伝達される各専用サーバで前記リソース属性データを集約するステップと、前記集約されたリソース・データを、１つまたは複数の中間専用サーバを介して前記階層のルート専用サーバに伝達するステップとをさらに含む、請求項１に記載の方法。
【請求項７】
前記中間専用サーバのそれぞれで前記リソース・データを集約するステップをさらに含む、請求項６に記載の方法。
【請求項８】
十分な量のリソース属性データを維持する前記ステップが、前記階層内の各専用サーバで維持された前記リソース属性データを前記階層内の１つまたは複数の追加専用サーバで複製するステップをさらに含む、請求項１に記載の方法。
【請求項９】
所定の前記階層がツリー階層を含む、請求項１に記載の方法。
【請求項１０】
前記リソース属性データを伝達する前記ステップが、前記複数のコンピューティング・システムのうちの１つから前記ツリー階層内の複数のリーフ・ノード専用サーバのうちの１つに前記リソース属性データを伝達するステップをさらに含む、請求項９に記載の方法。
【請求項１１】
十分な量のリソース属性データを維持する前記ステップが、前記専用サーバに維持された前記リソース属性データを定期的に更新するステップをさらに含む、請求項１に記載の方法。
【請求項１２】
十分な量のリソース属性データを維持する前記ステップが、
前記専用サーバに伝達された各リソース属性データに関する存続時間値を識別するステップと、
前記識別された存続時間値に従って更新が受信されていない前記専用サーバからリソース属性データを削除するステップと、
をさらに含む、請求項１に記載の方法。
【請求項１３】
コンピュータによって読み取られたときに、分散システム内の連合リソース発見のための方法を前記コンピュータに実行させるコンピュータ可読コードを含むコンピュータ可読媒体において、前記方法が、
複数の分散コンピューティング・システム内に配置された複数のリソースに関連するリソース属性データを階層に応じて配置された複数の専用サーバのうちの１つまたは複数に前記分散コンピューティング・システムから伝達するステップであって、前記リソース属性データが前記複数の分散コンピューティング・システム内に配置された前記関連リソースの識別および割り振りを容易にするために十分なものであるステップと、
リソース照会を処理し、前記専用サーバの階層を介して前記照会に適したリソースを含む分散コンピューティング・システムにその照会を経路指定するために、前記専用サーバの階層内の任意の所与の専用サーバで十分な量のリソース属性データを維持するステップと、
を含む、コンピュータ可読媒体。
【請求項１４】
前記方法が、前記リソース属性データを複数の固有属性フォーマットで入手するステップであって、各固有属性フォーマットが前記分散コンピューティング・システムのうちの１つによって決定され、それに関連付けられるステップをさらに含む、請求項１３に記載のコンピュータ可読媒体。
【請求項１５】
前記リソース属性データを伝達する前記ステップが、前記伝達されたリソース属性データを前記複数の固有属性フォーマットから前記複数の専用サーバのうちの少なくとも１つによって提供された共通属性フォーマットにマッピングするステップをさらに含む、請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
前記リソース属性データを入手する前記ステップが、複数のリソース発見サーバを使用して前記リソース属性データを入手するステップであって、各リソース発見サーバが前記複数の分散コンピューティング・システムのうちの１つに関連付けられるステップを含む、請求項１４に記載のコンピュータ可読媒体。
【請求項１７】
前記方法が、前記リソース発見サーバのそれぞれに共通属性フォーマットを伝達するステップをさらに含み、
前記リソース属性データを伝達する前記ステップが、
前記専用サーバおよび前記リソース発見サーバのうちの少なくとも１つを使用して、前記伝達されたリソース属性データを前記複数の固有フォーマットから前記複数の専用サーバのうちの少なくとも１つによって提供された共通属性フォーマットにマッピングするステップと、
このマッピングを前記リソース属性データとともに前記専用サーバのうちの１つに伝達するステップと、
をさらに含む、請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
十分な量のリソース属性データを維持する前記ステップが、前記複数のコンピューティング・システムから前記リソース属性データが伝達される各専用サーバで前記リソース属性データを集約するステップと、前記集約されたリソース・データを、１つまたは複数の中間専用サーバを介して前記階層のルート専用サーバに伝達するステップとをさらに含む、請求項１３に記載のコンピュータ可読媒体。
【請求項１９】
十分な量のリソース属性データを維持する前記ステップが、前記階層内の各専用サーバで維持された前記リソース属性データを前記階層内の１つまたは複数の追加専用サーバで複製するステップをさらに含む、請求項１３に記載のコンピュータ可読媒体。
【請求項２０】
所定の前記階層がツリー階層を含む、請求項１３に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報技術システムの管理および監督の分野に関し、特に、異なる管理権限下にあり、すでにそれ自体の個別レガシー・リソース発見サービス（legacy resource discovery service）を有する可能性のある複数の情報技術システム間のリソース発見および割り振りに関する。
【背景技術】
【０００２】
現代のアプリケーションおよびサービスは、種々の組織に属し、種々の管理権限下にある複数のコンピューティング・システム上で実行される。複数のコンピューティング・システムにまたがるこのようなアプリケーションまたはサービスを実行するためには、このようなアプリケーションのためにすべてのコンピューティング・システム内のリソースを発見し、割り振る必要がある。このようなリソースとしては、たとえば、中央演算処理装置（ＣＰＵ）リソースなどのコンピューティング・ハードウェア・リソース、たとえば、物理マシン内のハード・ディスク・サイズ、メモリ・サイズなどの記憶容量、大気または気象データおよびビデオまたはオーディオ・データなどの様々なタイプのデータを収集するデータ・コレクタまたはデータ・センサを含む。使用可能なリソースは静的リソースおよび動的リソースのいずれにもなり得る。たとえば、所与のマシンのメモリ・サイズまたはネットワーク・アダプタ速度は通常、固定されているが、使用可能なメモリまたは帯域幅は時間の経過につれて頻繁に変化する。
【０００３】
様々な同時発生リソース要求間でリソースを割り振るためには、すべての関連組織に属す様々なコンピューティング・システムから使用可能なリソースのリポジトリを作成し、維持する必要がある。このリポジトリの作成および維持は、割り振りに使用可能なリソースを発見することを含む。リソース発見は、所与のリソース要求の指定の要件に従ってリモート・リソースの場所を突き止めることができ、様々なアプリケーションのために多くの分散コンピューティング・システムで広く使用される。たとえば、グリッド・コンピューティングでは、アプリケーションを実行するために必要なＣＰＵおよびメモリ・リソースを所有するマシンまたはノードが発見または識別され、その後、これらの識別されたマシンにそのアプリケーションが配備される。
【０００４】
様々なリソース発見のための手法が提案されている。これらの提案された手法としては、１９８８年発行のP. MockapetrisおよびK. J. Dunlapによる「Development of the Domain Name System」（Proceedingsof SIGCOMM'88, Stanford, Californiaの１２３〜１３３ページ）に記載されたドメイン・ネーム・システム（ＤＮＳ：domain name system）、１９９７年１２月発行のM. Wahl、T. Howes、およびS. Killeによる「RFC 2251 - Lightweight Directory Access Protocol (v3)」、２００１年１月発行のＩＴＵ-Ｔによる「Recommendation X.500」、および１９９６年発行のD.W. Chadwickによる「Understanding X.500 - TheDirectory」に記載された軽量ディレクトリ・アクセス・プロトコル（ＬＤＡＰ／Ｘ．５００）、ならびにSunMicrosystemsによる「Java Naming and Directory Interface − JNDI Documentation」（http://java.sun.com/products/jndi/docs.html）に記載されたＪａｖａ命名ディレクトリ・インターフェース（ＪＮＤＩ：java naming and directory interface）を含む。これらのシステムはいずれも、リソースを発見するためのディレクトリ・サービスを提供し、通常、各組織内のリソースを発見するための「固有（native）」リソース発見サービスとして使用される。しかし、それぞれがそれ自体のレガシー・リソース発見サービスを有する複数の組織が、共用グローバル・プールからのリソースを使用する必要があるアプリケーションのために、組織境界を越えてそれぞれのリソースを共用したい場合、そのリソースが存在する組織にかかわらず、必要なリソースを見つけることができる連合リソース発見（federated resources discovery）が必要である。上記の手法はいずれも連合サーチを提供できない。第一に、上記のこれまでのリソース発見の試みは、ほとんどの場合、静的リソース、すなわち、たとえばホスト名とインターネット・プロトコル（ＩＰ）のマッピングなど、極めてゆっくり変化するリソースのために手配されていた。これらのシステムを使用して、たとえば、数十分以下の規模で頻繁に変化する動的リソースのサポートは、非常に限られている。より重要なことに、これらのシステムでは、使用可能なリソースの空間（space）または領域（universe）は、委任された方法で管理される定義済みツリー階層にグローバルに編成されるものと想定する。すなわち、各組織は、このような階層について合意し、ツリーの一部分、典型的にはサブブランチまたはノードを「所有」し、各リソースはツリー階層内の特定のノードに属す。
【０００５】
管理上および信頼上の理由により、自律システムは、リソースをどのように編成すべきかについて種々の認識を有する可能性がある。したがって、リソースをどのように編成すべきかについてそれぞれがそれ自体のプリファレンスまたはレガシー定義を有する複数の組織のためのリソースについて一般に受け入れられているグローバル編成および管理は存在する可能性はない。加えて、グローバル編成によって、リソースの割り振りに複雑さと制約がもたらされる。たとえば、新しいタイプのリソースまたは新しい組織を今後追加する予定である場合、リソース階層を事前定義することは難しい可能性がある。基本的に、すでに種々のリソース発見サービスを使用しているシステムは、共通タスクのために共同作業する必要があるが、個々のレガシー・リソース発見サービスを変更することは不可能であり、不都合なことである。
【０００６】
スケーラブル広域リソース発見ツール（ＳＷＯＲＤ：scalable wide-area resource discovery tool）の１つは、２００４年１２月発行のDavid Oppenheimer、Jeannie Albrecht、David Patterson、およびAmin Vahdatによる「Distributed Resource Discovery on PlanetLab with SWORD」（First Workshop on Real, Large Distributed Systems (WORLDS '04)）に記載されている。このリソース発見サービスは、２００２年７月発行のLarry Peterson、Tom Anderson、David Culler、およびTimothy Roscoeによる「A Blueprint for Introducing Disruptive Technology into the Internet」に記載されているようにＰｌａｎｅｔＬａｂのために作成されたものである。ＳＷＯＲＤによって使用されるリソース発見ツールでは、分散ハッシュ・テーブル（ＤＨＴ：distributed hash table）ベースのピアツーピア・ネットワークを使用して、動的リソースに関する多次元範囲照会（multi-dimensional range query）をサポートする。ピアツーピア・ネットワークを使用する場合の不利点の１つは、システムの管理が難しいことである。ピアツーピア・ネットワークは個別ノードの高い自律性を可能にするように配置されており、システム内の特に集中化した制御および管理を容易にすることが極めて難しくなっている。加えて、ＳＷＯＲＤ内のリソース発見ツールでは、それぞれの個別自律システムがその完全なリソース・レコードをピアツーピア・ネットワーク、すなわち、おそらく任意のノードにエクスポートする必要がある。このため、すべての自律システムは相互に高度に信頼していなければならず、これが実際に問題になる可能性がある。個別自律システムは、外界の任意のノードにそのオリジナル・レコードを快く公開しない可能性がある。
【特許文献１】ＩＢＭ整理番号ＹＯＲ９２００６０２８１ＵＳ１によって識別され、「A distributed algorithm for minimum overhead replication in a treehierarchy subject to consistency constraints」という名称の同時係属の米国特許出願
【非特許文献１】１９８８年発行のP. MockapetrisおよびK. J. Dunlapによる「Development of the DomainName System」（Proceedings of SIGCOMM'88, Stanford,Californiaの１２３〜１３３ページ）
【非特許文献２】１９９７年１２月発行のM. Wahl、T. Howes、およびS. Killeによる「RFC 2251 - Lightweight Directory Access Protocol (v3)」
【非特許文献３】２００１年１月発行のＩＴＵ−Ｔによる「RecommendationX.500」
【非特許文献４】１９９６年発行のD.W. Chadwickによる「Understanding X.500 - The Directory」
【非特許文献５】Sun Microsystemsによる「Java Naming and Directory Interface -- JNDI Documentation」
【非特許文献６】２００４年１２月発行のDavidOppenheimer、Jeannie Albrecht、DavidPatterson、およびAmin Vahdatによる「DistributedResource Discovery on PlanetLab with SWORD」（FirstWorkshop on Real, Large Distributed Systems (WORLDS '04)）
【非特許文献７】２００２年７月発行のLarry Peterson、Tom Anderson、David Culler、およびTimothy Roscoeによる「A Blueprint forIntroducing Disruptive Technology into the Internet」
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明によるシステムおよび方法は、広域ネットワーク内の静的リソースと動的リソースの両方を発見するための連合アーキテクチャを使用する。それぞれが専用かつ潜在的に独自所有（proprietary）のリソース発見サービスを有する複数の自律システムが相互接続され結合されてグローバル統一リソース発見システムになる。グローバルに編成され、一般に合意を得た既存のリソース空間は不要であり、各自律システム、たとえば、所与の組織またはドメインはそのリソースを自律的に編成することができる。このフレキシビリティにより、各システムは任意の定義済みグローバル・リソース階層に関する制約または複雑な問題なしに動作することができる。
【課題を解決するための手段】
【０００８】
本発明によるリソース発見に適したアーキテクチャの模範的な一実施形態によれば、Ｄサーバという複数の専用サーバがツリー階層などの階層に配置される。この階層は、リソースに関するユーザ照会に応答するために使用される。たとえば、各サーバは、この階層内のポイントまたはノードであり、階層内でボトムアップ式にその子からデータを集約するために使用される。それぞれの子も階層内のサーバである。発見可能なリソースを含む各ドメインまたは組織内に配置された１つまたは複数のサーバはＤサーバのうちの１つと通信状態にある。それぞれの個別組織サーバはＯサーバという。一実施形態では、各Ｏサーバは、その階層内のリーフ・ノードとして位置決めされたＤサーバのうちの１つをその親（parent）として選択する。Ｏサーバは、そのリソース・レコードを要約（summary）に集約し、要約されたデータをその選択された親Ｄサーバに定期的に転送する。１つまたは複数のＯサーバからこのように要約されたデータを受信すると、各Ｄサーバは、たとえば、より粗い細分性を使用して、要約されたデータをさらに集約し、そのさらに集約されたデータを階層を介してさらに上のその親および祖父母（grandparent）に転送する。階層のルート・サーバがその子孫（descendent）のすべて、すなわち、すべてのＯサーバおよびＤサーバから、要約されたデータを受信し集約するまで、潜在的に細分性を増加して、階層の各レベルで集約および転送が繰り返される。リーフ・ノードからルート・ノードへの集約により階層内の各親ノードに対してその親をルートとするサブツリーの集約ビュー（aggregated view）が提供され、複製オーバレイ（replicationoverlay）により各ノードに対して階層の他の部分のテレスコープ・ビュー（telescopic view）が提供される。階層内の整合性を保証することにより、所与の整合性限界内で最小限のオーバヘッドを使用することができる。
【０００９】
たとえば、階層のルート・ノードで照会を受信すると、集約され要約されたデータを使用して、所望のリソースの位置およびその他の属性に関するデータまたは情報を含む子サーバを階層内のルート・サーバに対して識別する。これらの子サーバは識別され、照会は子に転送される。照会が個別Ｏサーバに到達するまで、それぞれの子は階層を介してさらに下に照会を同様に転送する。Ｏサーバは、それぞれのデータベースをサーチし、照会を提案したユーザにサーチ結果を返すことにより、照会に応答する。ルート・サーバで照会を受け取るには、各照会が階層構造全体を通過する必要があり、時間およびリソースを消費するプロセスになる。階層内の様々なサーバ間で要約を複製することにより、照会応答時間が短縮され、リソースが保存され、ボトルネックが回避される。したがって、照会を階層内のルートＤサーバに必ず据える必要はない。たとえば、各Ｄサーバは、それ自体の要約されたデータと、兄弟（sibling）および祖先（ancestor）の兄弟からの要約されたデータを保管する。照会を受信すると、所与のＤサーバは、複製された要約をサーチし、ルートＤサーバを介して照会を経路指定せずに適切なＤサーバに照会を直接転送する。
【００１０】
本発明の模範的な諸実施形態によるシステムおよび方法は、多くの自律システム内に位置する静的リソースと動的リソースの両方に関する多次元照会に応答することができる。階層の各ノードでは、完全なリソース・レコードではなく、要約されたデータのみが必要であり、システムの管理が非常に容易になり、各自律システムが信頼しなければならないものに関する要件が最小限になる。
【００１１】
本発明による分散システム内の連合リソース発見のための方法の模範的な一実施形態によれば、複数の分散コンピューティング・システム内に配置された複数のリソースに関連するリソース属性データは、階層、たとえば、ツリー階層に応じて配置された複数の専用サーバのうちの１つまたは複数に分散コンピューティング・システムから伝達される。リソース属性データは、複数の分散コンピューティング・システム内に配置された関連リソースの識別および割り振りを容易にするために十分なものである。一実施形態では、リソース属性データは複数の固有属性フォーマットで入手され、各固有属性フォーマットは分散コンピューティング・システムのうちの１つによって決定され、それに関連付けられる。リソース属性データがこの固有フォーマットで伝達されると、伝達されたリソース属性データは複数の固有属性フォーマットから、複数の専用サーバのうちの少なくとも１つによって提供された共通属性フォーマットにマッピングされる。一実施形態では、複数のリソース発見サーバを使用してリソース属性データが入手され、各リソース発見サーバは複数の分散コンピューティング・システムのうちの１つに関連付けられる。階層内でサポートされる共通フォーマットへのデータのフォーマット設定を可能にするために、リソース発見サーバのそれぞれに共通属性フォーマットが伝達され、専用サーバのうちの少なくとも１つまたはリソース発見サーバのうちの１つを使用して、伝達されたリソース属性データを複数の固有フォーマットから専用サーバによって提供された共通属性フォーマットにマッピングする。このマッピングは、リソース属性データとともに専用サーバのうちの１つに伝達される。
【００１２】
専用サーバにリソース属性データを伝達することに加えて、リソース照会を処理し、専用サーバの階層を介してその照会に適したリソースを含む分散コンピューティング・システムにその照会を経路指定するために、専用サーバの階層内の任意の所与の専用サーバで十分な量のリソース属性データが維持される。一実施形態では、複数のコンピューティング・システムからリソース属性データが伝達される各専用サーバでリソース属性データが集約される。これらの集約されたデータは、１つまたは複数の中間専用サーバを介して階層のルート専用サーバに伝達される。最初にリソース属性データを受信する専用サーバでデータを集約することに加えて、中間専用サーバのそれぞれでリソース属性データをさらに集約することができる。
【００１３】
一実施形態では、各専用サーバで十分な量のリソース属性データを維持するために、各専用サーバで維持されたリソース属性データおよび集約されたデータが階層内の１つまたは複数の追加専用サーバで階層内で複製される。専用サーバの階層がツリー階層である場合、リソース属性データの伝達は、複数のコンピューティング・システムのうちの１つからツリー階層内の複数のリーフ・ノード専用サーバのうちの１つにリソース属性データを伝達することを含む。一実施形態では、リソース属性データの維持は、専用サーバに維持されたリソース属性データを定期的に更新することを含む。専用サーバに伝達された各リソース属性データに関する存続時間値（time to live value）を識別し、識別された存続時間値に従って更新が受信されていない専用サーバからリソース属性データを削除することにより、古いデータまたは期限切れデータが階層から除去される。
【発明を実施するための最良の形態】
【００１４】
最初に図１を参照すると、本発明により使用するためのシステム１０の模範的な一実施形態が例示されている。このシステムは、所定の階層に応じて配置された複数の専用サーバ１２（Ｄサーバ）を含む。専用サーバは、この階層により相互に通信状態にあり、ファイルまたはデータを交換することができる。適切なサーバは、当技術分野で既知であって入手可能であり、コマンドを処理し、データを保管し、他のサーバと通信できる任意のタイプのプロセッサまたは処理装置を含む。一実施形態では、各サーバは、任意の適切なマシンまたはプロセッサ上で実行されるソフトウェア・プログラムである。したがって、サーバまたはサーバ機能は、快くホストとしてサーバを処理する任意のマシンまたはドメインによって提供することができる。サーバに適したソースとしては、リソース所有者またはその他の自発的に申し出ているエンティティを含むが、これらに限定されない。これらのエンティティはサーバ・プロバイダと呼ぶことができる。
【００１５】
専用サーバを配置できる適切な階層としては、ツリー階層およびピラミッド階層を含むが、これらに限定されない。好ましくは、サーバは、ツリー階層に配置され、複数のリーフ・ノードＤサーバ２０と、複数の中間ノードＤサーバ１６と、ルート・ノードＤサーバ１４とを含む。すべてのＤサーバは、単一の位置に、たとえば、専用サーバ・ファームの一部として位置することができる。代わって、サーバは、様々な位置に分散され、１つまたは複数のネットワークの全域で通信状態にある。たとえば、各Ｄサーバは、個別ドメインに位置するかまたは異なる組織に属すことができる。階層は、Ｄサーバ間の自発的関連付けにより形成することができる。各Ｄサーバは、それが他のどのＤサーバを最も信頼しているかあるいは通信帯域幅または最小遅延に基づいて、他のどのＤサーバがその親として参加すべきかを決定する。サーバは、厳密にその階層専用になる場合もあれば、階層外で他のサービスまたは機能を提供する多目的サーバになる場合もある。
【００１６】
一実施形態では、所与のＤサーバを提供したエンティティは、たとえば、同じエンティティまたは異なるエンティティのいずれかからもう１つのサーバを親として選択する。各サーバは、通常、少なくとも１つの親を有する。このようにして、複数のサーバを１つの階層に編成することができる。正確にどのサーバを選択するかは、２つのエンティティ間のネゴシエーションを必要とする可能性があり、決定するのは各エンティティの義務である。したがって、階層内のサーバ配置に関する決定は、これらのサーバを自発的に申し出るかまたは提供する様々なドメインまたは組織によって行われ、集中エンティティまたは第三者によって行われることはない。一般に、所与のサーバはそれ自体の子孫間から親を選択せず、その結果、ループを回避する。子孫を親として選択するのを防止するために、各サーバで子孫リストが維持される。一実施形態では、親サーバは、結果的に平衡階層（balanced hierarchy）になるような順序または配置で選択され、効率が改善される。たとえば、各サーバのサブブランチに関する最大深さが維持され、より大きい最大深さを有するサーバのみが親として選択される。
【００１７】
システムは、特定のドメインまたは組織に関連し、Ｏサーバ２２という複数のリソース発見サーバも含む。各Ｏサーバを１つの個別ドメインに関連付けるか、あるいは２つ以上のＯサーバを１つの共通ドメインに関連付けることができる。適切なタイプのＯサーバはＤサーバの場合と同じである。一実施形態では、すべてのＯサーバは、個別のものであり、Ｄサーバとは別個のものである。代わって、少なくとも１つのＯサーバと１つのＤサーバは共通サーバである。一般に、Ｏサーバは、複数サーバが広く分散したシステムとして配置される。各Ｏサーバは１つまたは複数のネットワークの全域でＤサーバのうちの少なくとも１つと通信状態にある。たとえば、分散Ｏサーバは、インターネットなどの広域ネットワーク１８の全域でＤサーバと通信状態にある。加えて、他のグループのＯサーバも、１つまたは複数のローカル・エリア・ネットワーク２４、たとえば、所与のドメインまたはインターネット・サービス・プロバイダに関連するローカル・エリア・ネットワークを介してＤサーバと通信することができる。本明細書で使用する様々なサーバ間の通信は、各サーバが任意の他のサーバとの間でデータを送受信できるという点で双方向通信である。一実施形態では、各Ｏサーバは、それがデータをエクスポートすることになる１つのＤサーバを選択する。各ＯサーバはＤサーバのうちのいずれか１つと通信することができるが、好ましくは、各Ｏサーバは、ツリー階層内のリーフ・ノードを表すＤサーバの１つによって識別され、そのＤサーバにより伝達される。したがって、Ｏサーバはツリー階層内のそのＤサーバの子ノードになる。
【００１８】
各Ｏサーバは、単一サーバになる場合もあれば、所与のドメインまたは組織内の分散サービスである場合もある。各Ｏサーバは、その組織内のリソースを発見し、保管されたリソース・データを更新し、所望のレベルの細分性に応じてリソース・データを要約し、他のサーバにリソース・データを伝達し、他のサーバからリソース・データを受信することができる。リソース・データは、生フォーマットまたは集約要約フォーマットで伝達することができる。所与の組織内に含まれるリソースは、その組織の特定のフォーマットまたは独自所有のフォーマットに応じて編成され、そのフォーマットでこれらのリソースを記述するデータまたは属性はＯサーバ内で入手され維持される。そのリソースを記述するために使用される属性に関する特定のフォーマットまたは固有フォーマットとしては、特定のタイプのリソースを命名するために使用される規則を含む。適切な属性タイプとしては、整数、ダブル（double）、文字列、タイムスタンプ、カテゴリ、ブラブ（blob）、およびこれらの組み合わせを含むが、これらに限定されない。属性フォーマットの変形は、たとえば、メモリ対ＲＡＭのように完全に同じリソースを記述するために異なる名前を使用すること、ならびに同じ基本機能を有する異なるリソースを使用することから発生する。たとえば、ある組織はその１次記憶ソースとしてＲＡＭを使用する可能性があり、他の組織はその１次記憶ソースとしてフラッシュ・メモリを使用する可能性がある。どちらもそれぞれの組織に対して同じ基本機能を提供するが、そのリソースを記述するために異なる属性を有することになる。適切なリソースとしては、様々な組織によって使用できるデータを提供する、アプリケーションならびにセンサまたはその他のデータ・ソース、たとえば、ビデオ・カメラおよびその他の監視装置に割り振ることができる処理および通信リソースを含む。
【００１９】
各Ｏサーバは、階層構造内に含まれる分散専用サーバであるＤサーバのうちの１つまたは複数と通信状態にあって、それとデータを交換することができるので、各ＯサーバはＤサーバのうちの１つに対し、その組織の特定のフォーマットまたはプロトコルに応じてそのＯサーバに保管されたリソース属性データをエクスポートする。このＤサーバはＯサーバにとって親Ｄサーバである。したがって、様々な組織はユニバーサル・フォーマットに応じてフォーマットする必要がない。
【００２０】
任意の所与のリソースの識別、位置、および諸機能を含む、そのリソースの記述は、そのリソースに関連し、リソース属性データで表される複数の属性を使用して提供される。これらの属性は定性または定量記述子の形を取ることができる。一実施形態では、とりわけ、実数または整数、カテゴリ・データ、および数値間隔などの定量数値形式で属性が提供される。所与のリソースに関連する各属性は、それが関連付けられるリソースの次元と見なすことができる。データまたは属性の量が大きいほど、相互に関係する次元数（dimensionality）が大きくなるか高くなる。次元数が大きいほど、関連データを保管するために必要な記憶空間が大きくなる。しかし、リソースが位置する組織に関連するＯサーバを除いて、すべてのリソースに関する次元数全体を階層内のすべてのサーバで維持する必要はない。実際に、任意の所与のＤサーバでは、そのＤサーバからの照会を、そのリソースに関する属性データのすべてを含むＯサーバの方向に経路指定するために十分な量の情報だけが必要である。したがって、任意の所与のＤサーバは、任意の所与のリソースに関する属性の要約または集約表現だけを必要とする。
【００２１】
図２を参照すると、本発明によるリソース発見および割り振りで使用するためのＤサーバ２６のツリー階層の模範的な一実施形態が図２に例示されている。このツリー階層リソース発見システムは、ルートＤサーバ１４と、中間ノードＤサーバ１６と、リーフ・ノードＤサーバ２０とを含む、複数の個別Ｄサーバを含む。各リーフ・ノードＤサーバ２０は、１つまたは複数のＯサーバからそれに伝達されたリソース属性データを含む。これらのリソース属性データとしては、数の範囲などの定量データ２６と、コンポーネントのリストまたは集合などの定性データ２８とを含む。
【００２２】
任意の所与のＤサーバにおけるリソース属性データの保管を改善するために、集約関数（aggregation function）を使用して、そのリソースに関連し、そのＤサーバに伝達されたリソース属性データの要約または集約が作成される。一般に、集約関数は、元のデータより粗い細分性の要約されたデータを生成する。これは、通常、所与の属性に関連するデータまたは情報の量を削減することによって達成される。一実施形態では、集約は、所与の属性に関連するデータの量を減少させることを含む。したがって、所与の属性の場合、集約関数はその属性に関連するデータを有するリソースの集合について適用され、集約は所与の属性に関する集約を伴う。適切な集約関数は、依然としてリソース照会をサポートしながら、データ・ボリュームを削減する任意のタイプの集約を含む。これらの集約関数としては、数値、整数または実数、単一バケットまたはマルチバケット（ヒストグラム）、およびカテゴリ、すなわち、セット和集合（set union）を含むが、これらに限定されない。単一集約関数をすべての属性に適用するか、または個別かつ別個の集約関数を各属性ごとに使用することもできる。たとえば、数値を使用して記述される、ネットワーク・アダプタの使用可能帯域幅などの属性の場合、所与の集合のリソースに関する属性の上限および下限を計算することにより、集約結果が生成される。この集約結果は所与のＤサーバに伝達される。その属性に関する各集約結果は上限および下限を有し、集約結果をさらに集約することができる。所与の集合の集約結果の場合、集約結果のすべてについて受け入れられる範囲の数値のすべては、その集約結果のすべてに関連する最小下限と集約結果のすべてに関連する最大上限によって定義された範囲内に収まることになる。したがって、集約された属性は全体的な最小下限と全体的な最大上限とを含む。各リソースに関する個別の属性はＤサーバで維持されない。集約属性のみが全体的な上限および下限を含む。この集約属性は、Ｄサーバの階層を介して上に、そして最終的にルートＤサーバに伝達される。集約された属性を受信する階層内のＤサーバは、その属性の点でそれより下のリソースについてより粗いかまたは広いビューを入手する。そのＤサーバは任意のリソースの属性に関連する正確な値を把握していない可能性があるが、Ｄサーバは、その子ノードに関連する任意のリソースがその集約された属性の上限と下限の範囲内に収まる値をその属性について有することを把握するであろう。所与のＤサーバ、たとえば、中間Ｄサーバのうちの１つが集約された属性データをその子から受信すると、そのＤサーバは各次元に沿ってそのデータをさらに集約する。この場合も、定量または数値属性について、Ｄサーバは、すべての下限のうちの最小のものと、すべての上限のうちの最大のものとを取り、その結果、新しい下限と上限を入手する。このようにさらに集約された属性はそのＤサーバの親に伝達される。このプロセスは、階層内のルート・サーバに到達するまで、ＤサーバからＤサーバへと繰り返される。
【００２３】
カテゴリ属性２８の場合、その属性に含まれるメンバまたはカテゴリを表すために集合またはリストが使用される。たとえば、その属性は、所与のリソースがサポートできる通信プロトコルのタイプのＩＤにすることができ、その属性は、サポートされる通信プロトコルのＩＤを含む集合によって表される。集約は、リソースに関連し、Ｏサーバまたは子Ｄサーバから受信したすべての属性集合の組み合わせまたは和集合を取ることを含む。すべての集合の和集合を表す属性集合は階層を介して上に伝達され、各レベルでさらに集約または結合される。図２に示されている通り、最下部のリーフ・ノードＤサーバ２０から最上部のルートＤサーバ１４までの各サーバで集約が繰り返される。ルートＤサーバは、すべての使用可能なリソースの属性に関するすべてのカテゴリのＩＤを含む上位集合（superset）を維持する。ルートＤサーバは、所与のコンピューティング・システムで実行されるアプリケーションなど、１つまたは複数のリソース要求への割り振りのために発見され使用可能なすべてのリソースの属性データを受信し集約する。上記の例では下限および上限ならびにセット和集合集約関数が使用されているが、集約関数がデータ・サイズを縮小し、使用可能なリソースにサーチを向けるのを支援する限り、その他の形式の集約関数も使用することができる。
【００２４】
一実施形態では、集約関数は、たとえば、番地、市区町村、郡、州などの位置属性とともに使用するのに適している。たとえば、リーフ・ノード・レベルＤサーバのレベルでは、位置属性は、たとえば、ビデオ・カメラなどの所与のリソースが位置する市区町村ブロック・サイズの長方形を記述するかまたは境界線で囲むために十分な量の情報を含む。図２に例示されている通り、各リーフ・ノードＤサーバにおける位置の集合は位置の集合｛Ｌ｝で示され、これは正確な番地または正確なマップ・グリッドと同じくらいの細部を示すことができるであろう。位置属性は集約され、中間Ｄサーバ１６に伝達されるので、位置情報に提供される細部の量は、たとえば、市区町村名｛Ｃ｝および州名｛Ｓ｝など、減少した特異性によって示される。市区町村名集合は、その子からその中間Ｄサーバに伝達されるすべての位置属性集合に含まれる市区町村のすべてを含む。ルートＤサーバ・レベルでは、位置属性は、すべてのリソースが所与の州内に位置することを指定するだけであろう。
【００２５】
一般に、集約のプロセスは、矢印Ａの方向によって示されるように、階層を介して上に属性データを伝達する際に使用される。複製（replication）は、矢印Ｂによって示されるように、階層を介してリーフ・ノードＤサーバまたは中間Ｄサーバまで集約されたデータを下に伝達するために使用される。また、複製は、階層の構造全体を通してより多くの情報を伝達し、照会に対する応答をより効率的なものにするために使用される。一実施形態では、所与のＤサーバの兄弟、そのＤサーバの祖先の兄弟、ならびにそれ自体がデータを有する場合にＤサーバの祖先の要約されたデータが定期的に階層内の上から下にそのＤサーバから受信側Ｄサーバに送信され、受信側Ｄサーバによってキャッシュされる。たとえば、図２の拡張リスト３０に例示されている通り、所与のリーフ・ノードＤサーバＤ1は、それ自体の集約されたリソース属性データと、その兄弟であるリーフ・ノードＤサーバＤ2、その親である中間ＤサーバＣ1、その親の兄弟である中間ＤサーバＣ2、その祖父母である中間ＤサーバＢ1、その祖父母の兄弟である中間ＤサーバＢ2およびＢ3、ならびにルートＤサーバＡの複製され集約されたリソース・データとを含む。したがって、処理のためにリソース割り振り照会をルートＤサーバに伝達する必要なしに、そのリソース割り振り照会をそのリーフ・ノードで受信し処理できるように、Ｄサーバの階層に提示されたリソース割り振りデータのすべてに関する十分な情報が階層内の単一リーフ・ノードで維持される。すなわち、リーフ・ノードはすべての使用可能なまたは識別されたリソースについて十分に詳細なピクチャを有する。
【００２６】
したがって、各サーバは、その要約され集約されたデータを階層を介して上に転送し、階層内の上流に位置するサーバの集約されたデータを階層を介して下にリーフ・ノードに向かって伝搬する。たとえば、Ｄサーバ・ノードＢ1は、ルートＤサーバＡからＤサーバＢ2およびＢ3の集約された属性データを受信し、この集約された属性データをＤサーバＣ1およびＣ2の両方に転送する。ＤサーバＣ1およびＣ2は、集約された属性データを受信すると、リール・レベル・サーバに向かって階層内の下方伝搬を続行する。
【００２７】
複製を使用して、階層内の様々なＤサーバ間でリソース情報を伝達すると、各Ｄサーバは、少なくとも一部分の要約または集約コピーと、潜在的にグローバル・リソースの集合全体を含み、リソース発見および照会時間を加速する。一般に、所与のＤサーバが任意の特定のリソースについて有する細部の量は、Ｄサーバとリソースとの間の距離、たとえば、中間ノードＤサーバおよびＯサーバの数に比例する。Ｄサーバとリソースとの間の距離がより短い場合、より高度な特異性または細部がそのリソースに関するＤサーバに維持される。この距離が拡大するにつれて、Ｄサーバは依然としてそのリソースに関する情報を維持することになるが、細分性はかなり粗くなる。たとえば、Ｄサーバ・ノードＤ1は市区町村ブロック・レベルの特異性でＤサーバ・ノードＤ2で保管されたカメラ・レコードの位置を把握しているが、Ｄサーバ・ノードＤ1は州レベルの特異性でＤサーバ・ノードＢ2およびＢ3に関するカメラ・レコードの位置だけを把握している。特異性のレベルを低減し、距離につれて細分性を増加すると、全体的な保管およびメッセージ・オーバヘッドが極めて大きいものにならないことが保証される。一実施形態では、ｎ個のサーバを含む階層内のノード度（node degree）がｋである場合、保管の複雑さ（storagecomplexity）は各サーバで約ｋ  ｌｏｇ  ｎである。
【００２８】
また、複製により、ルートＤサーバだけでなく、階層内の任意のＤサーバに照会を送信することができる。図３を参照すると、Ｄサーバの所与の階層を使用してリソース照会の処理を例示する模範的な一実施形態が示されている。クライアント３４は階層内のＤサーバのうちの１つａ１に照会３６を提示する。このＤサーバａ１は、それ自体の要約されたデータと、それに伝達された任意の複製データとを含む、そのＤサーバに保管された要約または集約データをサーチする。このサーチに基づいて、Ｄサーバａ１は、その兄弟Ｄサーバｃ１およびその伯父Ｄサーバｂ２が照会によって要求されたリソースに関する情報を含むと判断する。Ｄサーバａ１はその兄弟および伯父Ｄサーバｃ１およびｂ２に照会３８、４０を転送する。次に、これらのＤサーバｃ１およびｂ２はそのＤサーバの子のデータをサーチし、関連リソース情報を所有するその子Ｄサーバに照会４６、４８を転送する。Ｏサーバのうちの１つまたは複数に照会４２、４４、５０を経路指定するために、その後の子においてリソース属性データをサーチするプロセスが繰り返される。Ｏサーバはツリー階層内のリーフ・ノードＤサーバの子ノードである。各Ｏサーバは、その照会に応答して、詳細なリソース・レコードを求めてそれ自体のデータベースをサーチし、その結果５２、５４、５６をクライアントに返す。例示されている通り、初期照会３４はルートＤサーバ１４に提示または転送されていないが、中間ノードＤサーバに提示されている。そのポイントから照会が処理され、その照会に応答するリソースを含む、ドメインまたはコンピュータ・システムであるＯサーバに転送されている。
【００２９】
応答時間を減少させることに加えて、複製により、たとえば、ルートＤサーバを含むＤサーバのうちの１つまたは複数の障害に直面したときに、階層システムの頑強性または弾力性が改善される。ルートＤサーバ１４が故障またはクラッシュした場合、階層に提示された照会は依然として、残っている使用可能なＤサーバによって処理し応答することができる。一実施形態では、階層内の各Ｄサーバは、その子サーバおよび親サーバとの各通信リンクに沿って周期的な「ハートビート（heart-beat）」メッセージを維持する。これらのハートビート・メッセージは、通信リンクおよびサーバの可用性をテストする。たとえば、親Ｄサーバに関連するサーバまたは通信リンクがアクセス不能であることを所与のハートビート・メッセージが示す場合、Ｄサーバはその新しい親として伯父Ｄサーバを選択する。この選択は、ランダムにまたは１つまたは複数の所定の選択基準に応じて行うことができる。親Ｄサーバが階層システムのルートＤサーバである場合、子のうちの１つが新しいルートとして選ばれる。新しいルートＤサーバの選択に適した方法としては、各子Ｄサーバに対する現行負荷およびその組み合わせを考慮して、最小ＩＰアドレスを有する子Ｄサーバを選択することを含むが、これに限定されない。一般に、すべての照会を単一ルートＤサーバに提示または転送する必要性を除去すると、関連のボトルネックが緩和され、階層全体にわたって計算負荷が分散され、照会応答時間が短縮される。
【００３０】
任意の所与のＤサーバに保管された集約または要約されたデータが可能な限り最新のものであり、現在使用不能なリソースおよび最近追加されたリソースを含む使用可能なリソースの現行状態を正確に表すことを保証することにより、階層システムに追加の頑強性が提供される。一実施形態では、要約されたデータは軟質状態（soft-state）である。たとえば、各Ｄサーバは、要約されたデータの各次元ごとに存続時間（ＴＴＬ：time-to-live）値を維持する。一般に、データは、新しいデータが子または親から受信されると、定期的にリフレッシュされる。リフレッシュ済みデータが規定のＴＴＬ値に従って受信される限り、要約されたデータが現行かつ信頼できるものとして維持される。しかし、リソースが除去されるかまたは子Ｄサーバがオフラインになると、リフレッシュ済みデータはＴＴＬ値によって設定された制約の範囲内で受信されなくなる。したがって、これらに関連する要約データがＴＴＬ値に応じて期限切れになると、このデータは所与のＤサーバから除去される。したがって、期限切れのデータ、階層トポロジに対する変更、および使用可能なリソースの変化は、照会に応じたリソース発見を妨害したり、損なうことはない。
【００３１】
一般に、複製のプロセスは、記憶域、プロセッサ、および通信リソースが消費されるときにオーバヘッドを被る。したがって、複製データにおいて所望の更新レベルを保持しながら、全体的なシステム・パフォーマンスおよびリソース割り振りに対するこのオーバヘッドの影響を最小限にするための方法が使用される。一実施形態では、各リンクについて最適更新期間を設定する分散アルゴリズムが使用される。このアルゴリムの一実施形態の記述は、ＩＢＭ整理番号ＹＯＲ９２００６０２８１ＵＳ１によって識別され、「A distributed algorithm for minimum overhead replication in a treehierarchy subject to consistency constraints」という名称の同時係属の米国特許出願に記載されている。
【００３２】
喪失に加えて、階層トポロジおよび使用可能なリソースの集合に対する追加および訂正も考慮される。たとえば、所与のＤサーバは、前の親Ｄサーバの喪失ならびに新しい親Ｄサーバとのその後の再接続に続いて、再フォーマットされた階層トポロジを再結合することになる。新しい親Ｄサーバと接続すると、子Ｄサーバはその集約または要約されたデータを新しい親に転送する。
【００３３】
一実施形態では、データ複製は最後のリーフＤサーバ・ノードまで貫徹されるが、Ｏサーバはどのデータの複製にも関係していない。Ｏサーバは、Ｄサーバによって理解できる適切な形式、たとえば、要約または集約形式で、そのデータをエクスポートするだけである。Ｏサーバ・データをＤサーバに転送するために、定期的または自動化された方法を含む様々な方法が使用される。データの転送は、ＯサーバによってまたはＤサーバからの照会に応答して開始することができる。一実施形態では、ＤサーバまたはＯサーバに統合されるかまたはいずれかのサーバとは分離して動作し、システム管理者、たとえば、ラッパ・デーモン（wrapper daemon）の直接制御の範囲外のバックグラウンドで自動的に実行されるルーチンを使用して、ＯサーバからＤサーバにデータ更新を転送する。一実施形態では、このルーチンが定期的に所与のＯサーバに照会し、所望の要約されたデータを抽出し、抽出されたデータを親Ｄサーバに転送する。単に検索を行って転送することに加えて、このルーチンは、Ｏサーバのサーチによって返された結果をクライアントによって理解される共通フォーマットに再フォーマットすることもできる。
【００３４】
Ｄサーバの階層は、多種多様な組織またはドメインに含まれるリソースの割り振りをモニターし管理するために任意の特定の属性フォーマットを使用することに限定されない。加えて、分散コンピューティング・システムには、リソース識別のためのユニバーサルまたは標準化された属性フォーマットが課せられていない。各コンピューティング・システムは、それ自体の属性フォーマットを決定し、使用する。したがって、各タイプのリソースに使用されるスキーマ、すなわち、属性のリストは、異なる組織内で完全に同じである必要はない。様々な受信属性が異なる場合でも、リーフ・レベルのＤサーバは、様々なＯサーバから受信した所与のタイプのリソースに関する属性を、階層内の複数のＤサーバ間で使用される１つまたは複数の共通属性にマッピングすることができる。一実施形態では、Ｄサーバのうちの１つまたは複数、たとえば、リーフ・ノードＤサーバは、階層内のリソース属性データに使用する予定の所定の共通属性フォーマットをＯサーバに伝達する。伝達された共通属性は、各Ｏサーバがそのリソースに関するリソース・データ属性を共通属性にマッピングできるようにするために十分な量の情報を含む。このマップは、リソース属性データとともにＤサーバに伝達される。したがって、各自律組織は、その固有リソース発見システムを選択する際の自由度が増しており、連合階層システムは、より多様なレガシー自律システムを組み込むことができる。個別コンピューティング・システムには、いかなる外部属性フォーマットまたは階層も課せられない。
【００３５】
本発明による分散システム内の連合リソース発見のための方法の模範的な一実施形態では、複数の分散コンピューティング・システム内に配置された複数のリソースに関連するリソース属性データがこれらの分散コンピューティング・システムから定義済み階層に応じて配置された複数の専用サーバのうちの１つまたは複数に伝達される。一般に、リソース属性データは、複数の分散コンピューティング・システム内に配置された関連リソースの識別および割り振りを容易にするために、分散コンピューティング・システムに含まれるリソースに関する十分な量のデータを含む。このリソースは、クライアント、たとえば、コンピューティング・システム内または階層内のサーバのうちの１つで実行されるアプリケーションからのリソース要求照会に応じて識別され割り振られる。コンピューティング・リソースの任意の配置またはネットワーク配置を含む適切なコンピューティング・システムとしては、情報技術（ＩＴ：information technology）コンピューティング・システムを含むが、これに限定されない。
【００３６】
一実施形態では、リソース属性データをＤサーバに伝達するために、Ｄサーバを使用する各コンピューティング・システムからリソース・データが積極的に入手される。代わって、複数のコンピューティング・システム内に配置されたＯサーバは、そのＯサーバが位置するコンピューティング・システム内に含まれるリソースに関するリソース属性データを入手する。一実施形態では、各コンピューティング・システムは、リソース属性データを入手するために使用される２つ以上のＯサーバを含む。好ましくは、各コンピューティング・システムは、リソース属性データの取得および伝達のために１つのＯサーバを含む。リソース属性データは、階層内の任意のＤサーバに伝達することができる。好ましくは、リーフ階層の場合、リソース属性データはその階層内に含まれるリーフ・ノードＤサーバのうちの１つに伝達される。一実施形態では、適切なリーフ・ノードＤサーバは各Ｏサーバごとに識別され、Ｏサーバは関連リーフ・ノードＤサーバにリソース属性データを伝達する。
【００３７】
各Ｏサーバまたはリソース発見サーバは、そのコンピューティング・システム内に含まれるリソースに関するリソース属性データを、そのコンピューティング・システム用の固有属性フォーマットで入手する。複数のコンピューティング・システムの場合、複数の固有属性フォーマットが可能であり、各フォーマットが独特のものである可能性がある。これらの固有フォーマットにより、特定のリソースに割り当てられた名前およびコンピューティング・システム内の所与の機能に使用されるリソースのタイプを含むがこれらに限定されない、リソースを説明し記述する方法が様々になる。各コンピューティング・システム用の各固有属性フォーマットは、分散コンピューティング・システムのうちの１つによって決定され、それに関連付けられる。様々なコンピューティング・システムに対して１つの汎用またはユニバーサル属性フォーマットが課せられるわけではない。その代わりに、伝達されたリソース属性データがＤサーバ・レベルで複数の固有属性フォーマットから共通属性フォーマットにマッピングされる。この共通属性フォーマットは、複数の専用サーバのうちの少なくとも１つによって提供される。共通フォーマットと固有フォーマットとのマッピングはＤサーバ・レベルまたはＯサーバ・レベルで実行することができる。一実施形態では、共通属性フォーマットがＯサーバのそれぞれに伝達され、リソース属性データをＤサーバに伝達する際にＯサーバは伝達されたリソース属性データを複数の固有フォーマットからＤサーバによって提供された共通属性フォーマットにマッピングする。したがって、リソース属性データとともに両方のマッピング情報がＤサーバに伝達される。
【００３８】
分散コンピューティング・システム内で現在使用可能なリソースのすべてに関するリソース属性データを階層内のＤサーバに伝達すると、十分な量のリソース属性データが専用サーバの階層内の任意の所与の専用サーバに維持される。したがって、リソース照会は任意のＤサーバに提示し、そのＤサーバによって処理することができ、これらのＤサーバはこれらの照会を専用サーバの階層を介して適切な分散コンピューティング・システムまたはその照会に適したリソースを含むコンピューティング・システム内の適切なＯサーバに経路指定することができる。各Ｄサーバにおける所望の量のリソース属性データの維持は、集約および複製を使用して実施される。一実施形態では、リソース属性データは、複数のコンピューティング・システムからそのリソース属性データが伝達される各Ｄサーバで集約される。これらの集約されたリソース属性データは、１つまたは複数の中間Ｄサーバを介して階層のルートＤサーバに伝達される。リーフ・ノードＤサーバでリソース属性データを集約することに加えて、リソース属性データは、そのデータが階層を介して上に伝達されたときに、中間専用サーバのそれぞれでさらに集約される。
【００３９】
一実施形態では、階層内の各専用サーバに維持されたリソース属性データは、階層内の１つまたは複数の追加専用サーバ、たとえば、階層内の兄弟および祖先で複製される。任意の所与のリソースの状況および可用性、すなわち、そのリソースに関連するリソース属性データは時間の経過につれて変化するので、Ｄサーバに維持されたリソース属性データは定期的に更新される。たとえば、存続時間値は、専用サーバに伝達された各リソース属性データについて識別される。これは、更新を受信しなければならないかまたはそのデータが期限切れになる規定の条件または期間である。識別された存続時間値に従って更新が受信されない場合、リソース属性データは専用サーバから削除される。
【００４０】
一実施形態では、要求、すなわち、リソース要求は、リーフ・ノードＤサーバ、中間Ｄサーバ、およびルート・ノードＤサーバを含む、階層内のＤサーバのうちの１つに送信される。適切な照会としては、構造化照会言語（ＳＱＬ：structured query language）選択照会を含む。各ノードは集約され複製されたデータを含むので、照会は階層内の他のノードＤサーバに転送することができ、隣接Ｄサーバ、すなわち、親子Ｄサーバではなく、サーバ間の比較的長いジャンプを越えて転送することもできる。受信側Ｄサーバは、照会に応答して、照会ソース、すなわち、ユーザに付き合わせレコードを返す場合もあれば、階層内の他のＤサーバに照会を転送する場合もある。最終的に、照会に応答してリソース・レコードを返すことができる１つまたは複数のサーバにその照会が転送される。一実施形態では、１つまたは複数のＤサーバは、その照会の固有フォーマットから階層内で使用される共通照会フォーマットに照会をマッピングする。好ましくは、このマッピングまたは変換はＤサーバ・レベルで処理される。一実施形態では、照会フォーマットは、たとえば、Ｏサーバまたは他の照会ソースから、Ｄサーバに伝達される。固有フォーマットの所与の照会の受信に応答して、Ｄサーバの階層によって処理するために階層によって使用される共通照会フォーマットにその照会をマッピングできるように、Ｄサーバは必要なマッピング関係を作成する。
【００４１】
一実施形態では、クライアントに代わって、リゾルバ・モジュール（resolvermodule）が照会を送信し、結果を受信するように動作することができる。リゾルバは、Ｄサーバ階層およびＯサーバと対話するという負担からクライアントを救済することができる。クライアントは、Ｏサーバから返される結果の固有フォーマットを把握していない外部アプリケーションである可能性があり、そのフォーマットは組織ごとに様々である可能性があるので、リゾルバは適切なフォーマット設定を実行し、ユニバーサル・フォーマットで結果をクライアントに返すことができる。
【００４２】
一実施形態では、クライアント照会は反復プロセスで処理され、すなわち、各サーバは他のサーバに照会するようにクライアントをリダイレクトする。好ましくは、クライアント照会は、サーバが照会を転送し、その結果をリレーしてクライアントに返すという再帰的方法で処理されない。反復プロセスを使用すると、クライアントは必要なときにサーチを停止することができる。たとえば、クライアントは、その照会に応答して全数サーチ（exhaustive search）を行う必要がない可能性があり、第１の限定リソース（qualifyingresource）のレコードを受信したときまたは十分な数のレコードを受信したときに、照会プロセスを停止することができる。再帰的モードでは、クライアントがサーバに通知し、サーチを停止することが難しい。反復モードを使用すると、複雑さと責任がクライアントにシフトされ、クライアントは停止決定を行うためにより適切な位置になる。
【００４３】
本発明によるシステムおよび方法は、分散組織の様々な配置により様々なアプリケーションで使用することができる。適切なアプリケーションとしては、インターネットベースのストリーム処理システムならびにリソース・リッチ・センサおよびアクチュエータ・ネットワークを含むが、これらに限定されない。これらのシステムでは、本発明は、複数のネットワークの全域で実行されるアプリケーションをサポートしながら、前に分離され潜在的にアプリケーション固有のネットワークおよびリソースを統一する。加えて、本発明による模範的な方法およびシステムは、それぞれが潜在的に異なるディレクトリ・サービスを使用する複数のグリッドを統一することにより、別々に開発され配備されたディレクトリ・サービスおよびグリッド・コンピューティング・システムへの統一アクセスを提供するためにエンタープライズ・ディレクトリ・サービスとともに使用することができる。
【００４４】
本発明の模範的な諸実施形態による方法およびシステムは、完全にハードウェアの一実施形態、完全にソフトウェアの一実施形態、またはハードウェアとソフトウェアの両方の要素を含む一実施形態の形を取ることができる。好ましい一実施形態では、本発明は、ファームウェア、常駐ソフトウェア、およびマイクロコードを含むがこれらに限定されないソフトウェアで実装される。加えて、模範的な方法およびシステムは、コンピュータ、論理処理装置、または任意の命令実行システムによりあるいはそれに関連して使用するためのプログラム・コードを提供するコンピュータ使用可能媒体またはコンピュータ可読媒体からアクセス可能なコンピュータ・プログラム（computer program product）の形を取ることができる。この説明のために、コンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、装置、またはデバイスによりあるいはそれに関連して使用するためのプログラムを収容、保管、伝達、伝搬、または伝送可能な任意の装置にすることができる。適切なコンピュータ使用可能媒体またはコンピュータ可読媒体は、電子、磁気、光、電磁、赤外線、または半導体システム（あるいは装置またはデバイス）もしくは伝搬媒体を含むが、これらに限定されない。コンピュータ可読媒体の例としては、半導体またはソリッド・ステート・メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、剛性磁気ディスク、および光ディスクを含む。光ディスクの現在の例としては、コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、書き換え可能コンパクト・ディスク（ＣＤ−Ｒ／Ｗ）、およびＤＶＤを含む。
【００４５】
プログラム・コードの保管または実行あるいはその両方に適したデータ処理システムは、システム・バスを介して記憶素子に直接または間接的に結合された少なくとも１つのプロセッサを含むが、これに限定されない。記憶素子としては、プログラム・コードの実際の実行中に使用されるローカル・メモリと、大容量記憶装置と、実行中に大容量記憶装置からコードを検索しなければならない回数を削減するために少なくとも何らかのプログラム・コードの一時記憶を提供するキャッシュ・メモリとを含む。キーボード、ディスプレイ、およびポインティング・デバイスを含むがこれらに限定されない入出力またはＩ／Ｏ装置は、直接あるいは介在する入出力コントローラを介してシステムに結合することができる。また、本発明による方法およびシステムの模範的な諸実施形態は、データ処理システムが介在する私設網または公衆網を介してその他のデータ処理システムあるいはリモート・プリンタまたは記憶装置に結合された状態になれるようにするためにシステムに結合されたネットワーク・アダプタも含む。現在使用可能な適切なタイプのネットワーク・アダプタは、モデム、ケーブル・モデム、ＤＳＬモデム、イーサネット・カード、およびそれらの組み合わせを含むが、これらに限定されない。
【００４６】
一実施形態では、本発明は、マシンまたはコンピュータによって読み取られたときに、本発明の模範的な諸実施形態による分散情報技術システム内の連合リソース発見のための方法をマシンまたはコンピュータに実行させるマシン実行可能コードまたはコンピュータ実行可能コードを含むマシン可読媒体またはコンピュータ可読媒体、ならびにそのコンピュータ実行可能コードそのものを対象とする。マシン可読コードまたはコンピュータ可読コードは、マシンまたはコンピュータによって読み取り、実行することができる任意のタイプのコードまたは言語にすることができ、機械語、アセンブラ言語、高水準言語、オブジェクト指向言語、およびスクリプト言語を含む、当技術分野で既知であって入手可能な任意の適切な言語または構文で表現することができる。コンピュータ実行可能コードは、本発明によるシステムによって使用されるコンピュータ・ネットワーク内に配置され、それと通信状態にあり、それによってアクセス可能なデータベースを含む、任意の適切な記憶媒体またはデータベースに保管することができ、本発明の提示を制御するために使用される制御システムを含む、当技術分野で既知であって入手可能な任意の適切なハードウェア・プラットフォーム上で実行することができる。
【００４７】
本明細書に開示されている本発明の例示的な諸実施形態が本発明の諸目的を果たすことは明らかであるが、当業者であれば多数の変更例およびその他の実施形態を考案できることは認識されている。さらに、任意の実施形態による特徴（複数も可）または要素（複数も可）あるいはその両方は、単独でまたは他の実施形態（複数も可）と組み合わせて使用することができ、本発明による方法のステップまたは要素は任意の適切な順序で実行または遂行することができる。したがって、特許請求の範囲は本発明の精神および範囲の範囲内になると思われるこのような変更例および実施形態のすべてを包含するためのものであることが理解されるであろう。
【図面の簡単な説明】
【００４８】
【図１】本発明とともに使用するための専用サーバ階層および分散コンピューティング・システムの一実施形態の概略表現である。
【図２】本発明とともに使用するための専用サーバ階層の一実施形態の概略表現である。
【図３】本発明による照会処理の一実施形態を例示する概略表現である。
【図１】
2009541856.tif 000003
【図２】
2009541856.tif 000004
【図３】
2009541856.tif 000005
【手続補正書】
【提出日】平成21年6月16日(2009.6.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
分散システム内の連合リソース発見のための方法において、
複数の分散コンピューティング・システム内に配置された複数のリソースに関連するリソース属性データを階層に応じて配置された複数の専用サーバのうちの１つまたは複数に前記分散コンピューティング・システムから伝達するステップであって、前記リソース属性データが前記複数の分散コンピューティング・システム内に配置された前記関連リソースの識別および割り振りを容易にするために十分なものであるステップと、
リソース照会を処理し、前記専用サーバの階層を介して前記照会に適したリソースを含む分散コンピューティング・システムにその照会を経路指定するために、前記専用サーバの階層内の任意の所与の専用サーバで十分な量のリソース属性データを維持するステップと、
を含む、方法。
【請求項２】
前記リソース属性データを複数の固有属性フォーマットで入手するステップであって、各固有属性フォーマットが前記分散コンピューティング・システムのうちの１つによって決定され、それに関連付けられるステップをさらに含む、請求項１に記載の方法。
【請求項３】
前記リソース属性データを伝達する前記ステップが、前記伝達されたリソース属性データを前記複数の固有属性フォーマットから前記複数の専用サーバのうちの少なくとも１つによって提供された共通属性フォーマットにマッピングするステップをさらに含む、請求項２に記載の方法。
【請求項４】
前記リソース属性データを入手する前記ステップが、複数のリソース発見サーバを使用して前記リソース属性データを入手するステップであって、各リソース発見サーバが前記複数の分散コンピューティング・システムのうちの１つに関連付けられるステップを含む、請求項２に記載の方法。
【請求項５】
前記リソース発見サーバのそれぞれに共通属性フォーマットを伝達するステップをさらに含み、
前記リソース属性データを伝達する前記ステップが、
前記専用サーバおよび前記リソース発見サーバのうちの少なくとも１つを使用して、前記伝達されたリソース属性データを前記複数の固有フォーマットから前記複数の専用サーバのうちの少なくとも１つによって提供された共通属性フォーマットにマッピングするステップと、
このマッピングを前記リソース属性データとともに前記専用サーバのうちの１つに伝達するステップと、
をさらに含む、請求項４に記載の方法。
【請求項６】
十分な量のリソース属性データを維持する前記ステップが、前記複数のコンピューティング・システムから前記リソース属性データが伝達される各専用サーバで前記リソース属性データを集約するステップと、前記集約されたリソース・データを、１つまたは複数の中間専用サーバを介して前記階層のルート専用サーバに伝達するステップとをさらに含む、請求項１に記載の方法。
【請求項７】
前記中間専用サーバのそれぞれで前記リソース・データを集約するステップをさらに含む、請求項６に記載の方法。
【請求項８】
十分な量のリソース属性データを維持する前記ステップが、前記階層内の各専用サーバで維持された前記リソース属性データを前記階層内の１つまたは複数の追加専用サーバで複製するステップをさらに含む、請求項１に記載の方法。
【請求項９】
前記所定の階層がツリー階層を含む、請求項１に記載の方法。
【請求項１０】
前記リソース属性データを伝達する前記ステップが、前記複数のコンピューティング・システムのうちの１つから前記ツリー階層内の複数のリーフ・ノード専用サーバのうちの１つに前記リソース属性データを伝達するステップをさらに含む、請求項９に記載の方法。
【請求項１１】
十分な量のリソース属性データを維持する前記ステップが、前記専用サーバに維持された前記リソース属性データを定期的に更新するステップをさらに含む、請求項１に記載の方法。
【請求項１２】
十分な量のリソース属性データを維持する前記ステップが、
前記専用サーバに伝達された各リソース属性データに関する存続時間値を識別するステップと、
前記識別された存続時間値に従って更新が受信されていない前記専用サーバからリソース属性データを削除するステップと、
をさらに含む、請求項１に記載の方法。
【請求項１３】
コンピュータによって読み取られたときに、分散システム内の連合リソース発見のための方法を前記コンピュータに実行させるコンピュータ可読コードを含むコンピュータ可読媒体において、前記方法が、
複数の分散コンピューティング・システム内に配置された複数のリソースに関連するリソース属性データを階層に応じて配置された複数の専用サーバのうちの１つまたは複数に前記分散コンピューティング・システムから伝達するステップであって、前記リソース属性データが前記複数の分散コンピューティング・システム内に配置された前記関連リソースの識別および割り振りを容易にするために十分なものであるステップと、
リソース照会を処理し、前記専用サーバの階層を介して前記照会に適したリソースを含む分散コンピューティング・システムにその照会を経路指定するために、前記専用サーバの階層内の任意の所与の専用サーバで十分な量のリソース属性データを維持するステップと、
を含む、コンピュータ可読媒体。
【請求項１４】
前記方法が、前記リソース属性データを複数の固有属性フォーマットで入手するステップであって、各固有属性フォーマットが前記分散コンピューティング・システムのうちの１つによって決定され、それに関連付けられるステップをさらに含む、請求項１３に記載のコンピュータ可読媒体。
【請求項１５】
前記リソース属性データを伝達する前記ステップが、前記伝達されたリソース属性データを前記複数の固有属性フォーマットから前記複数の専用サーバのうちの少なくとも１つによって提供された共通属性フォーマットにマッピングするステップをさらに含む、請求項１４に記載のコンピュータ可読媒体。
【請求項１６】
前記リソース属性データを入手する前記ステップが、複数のリソース発見サーバを使用して前記リソース属性データを入手するステップであって、各リソース発見サーバが前記複数の分散コンピューティング・システムのうちの１つに関連付けられるステップを含む、請求項１４に記載のコンピュータ可読媒体。
【請求項１７】
前記方法が、前記リソース発見サーバのそれぞれに共通属性フォーマットを伝達するステップをさらに含み、
前記リソース属性データを伝達する前記ステップが、
前記専用サーバおよび前記リソース発見サーバのうちの少なくとも１つを使用して、前記伝達されたリソース属性データを前記複数の固有フォーマットから前記複数の専用サーバのうちの少なくとも１つによって提供された共通属性フォーマットにマッピングするステップと、
このマッピングを前記リソース属性データとともに前記専用サーバのうちの１つに伝達するステップと、
をさらに含む、請求項１６に記載のコンピュータ可読媒体。
【請求項１８】
十分な量のリソース属性データを維持する前記ステップが、前記複数のコンピューティング・システムから前記リソース属性データが伝達される各専用サーバで前記リソース属性データを集約するステップと、前記集約されたリソース・データを、１つまたは複数の中間専用サーバを介して前記階層のルート専用サーバに伝達するステップとをさらに含む、請求項１３に記載のコンピュータ可読媒体。
【請求項１９】
十分な量のリソース属性データを維持する前記ステップが、前記階層内の各専用サーバで維持された前記リソース属性データを前記階層内の１つまたは複数の追加専用サーバで複製するステップをさらに含む、請求項１３に記載のコンピュータ可読媒体。
【請求項２０】
前記所定の階層がツリー階層を含む、請求項１３に記載のコンピュータ可読媒体。
【国際調査報告】
2009541856.tif 000006