(57)【特許請求の範囲】
【請求項１】
リソース名前空間間の競合を解決するためのコンピュータ実行可能方法であって、
異なる名前空間が適用可能である条件を記述するコンテキスト情報をコンピュータにより記憶するステップであって、各リソース名前空間は複数のリソースおよびその対応する名前を含み、リソース名前空間は少なくとも部分的に重複し、それにより２つ以上のリソース名前空間中の同じ名前は前記それぞれのリソース名前空間中のリソースの異なるインスタンスを参照し、前記異なるインスタンスは異なるコンテンツを有する、ステップと、
リソースの名前の要求をコンピュータにより受信し、前記名前を前記コンテキスト情報と比較することによって前記リソース名前空間を互いに優先順位付けするステップであって、
前記コンテキスト情報に基づいて、前記対応する名前に前記条件が提要可能であるか否かを判定することと、
前記条件が適用可能であると判定された前記対応する名前に対して、前記対応する名前が前記要求された前記リソースの前記名前に合致する度合いに基づいて重み付けすることと
を含む、ステップと、
前記優先順位付けされた名前空間から前記名前のリソースをコンピュータにより取得するステップと
を含むことを特徴とする方法。
【請求項２】
リソース名前空間が、名前空間が適用可能である前記条件のうちの１つに関連しない場合、前記リソース名前空間は優先順位付けされないことを特徴とする請求項１に記載の方法。
【請求項３】
前記リソース名前空間は、デフォルトの相対的な優先順位を有し、前記名前が両方の前記リソース名前空間のコンテキスト情報に合致する場合、前記名前のリソースが前記デフォルトの相対的な優先順位に従って取得されることを特徴とする請求項１に記載の方法。
【請求項４】
コンテキストの条件は、任意のリソース名が前記コンテキストに該当するかどうかを判断するために、そのような任意のリソース名と比較できるリソース名のオープンエンドセットを記述する情報を含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記条件はファイルディレクトリまたはレジストリ位置を含むことを特徴とする請求項４に記載の方法。
【請求項６】
リソース名前空間間の競合を解決するためのコンピュータデバイスであって、
前記コンピュータデバイスは、少なくとも１つのプロセッサと、
前記プロセッサと通信可能に接続されるメモリとを備え、
前記メモリは、前記少なくとも１つのプロセッサに、請求項１乃至５のいずれか１項に記載の方法を実行させるコンピュータ実行可能命令を記録することを特徴とするシステム。
【請求項７】
リソース名前空間間の競合を解決するためのコンピュータ実行可能命令を記録するコンピュータ可読記録媒体であって、
前記コンピュータ実行可能命令は、少なくとも１つのプロセッサに、請求項１乃至５のいずれか１項に記載の方法を実行させることを特徴とするコンピュータ可読記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、フレキシブルな名前空間優先順位付けに関する。
【背景技術】
【０００２】
コンピュータアプリケーションは、一般に、オペレーティングシステムを介してコンピュータまたはシステムリソースにアクセスする。リソースは、ファイル、ライブラリ、システムサービス（たとえば、カットアンドペースト、プリンタ）、レジストリまたは構成情報などとすることができる。仮想化環境または構成要素は、システムリソースへのアプリケーションのアクセスを仮想化して、あたかもアプリケーションがオペレーティングシステムを直接扱っているかのようにシステムリソースへのアプリケーションのアクセスを透過的に処理する。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
仮想化環境は、そのうちのいくつかが重複または競合することがあるシステムリソースの複数セットへのアクセスを管理することができる。ネイティブのオペレーティングシステムは、「／ｓｏｍｅｐａｔｈ／ｓｏｍｅＦｉｌｅＮａｍｅ」などのファイル名をもつファイルを含むファイルリソースのセットを有する可能性がある。アプリケーション仮想化パッケージ（またはシャドウリソースのセット）は、同じファイル名、たとえば「／ｐａｔｈ／ｓｏｍｅＦｉｌｅＮａｍｅ」を使用する異なるファイルインスタンスを有する可能性がある。仮想化環境は、「／ｐａｔｈ／ｓｏｍｅＦｉｌｅＮａｍｅ」へのアプリケーションのアクセスを、アプリケーションに対して透過的な様式で管理する。アプリケーションは「／ｐａｔｈ／ｓｏｍｅＦｉｌｅＮａｍｅ」に書き込む可能性があり、仮想化環境は、ファイル「／ｐａｔｈ／ｓｏｍｅＦｉｌｅＮａｍｅ」のどちらのインスタンスに書き込むか、すなわち、ネイティブのオペレーティングシステムファイルか仮想化パッケージファイルかを判断する。
【０００４】
以下で、リソースへのアクセスの管理に関連する技法について説明する。
【課題を解決するための手段】
【０００５】
以下の概要は、以下の詳細な説明で説明するいくつかの概念を紹介するためにのみ含める。本概要は、包括的ではなく、最後に提示する特許請求の範囲によって規定される、請求する主題の範囲を定めるものではない。
【０００６】
コンピュータ上のリソースへのアクセスは、リソースの第１の名前空間とリソースの第２の名前空間とを使用することによって提供され、１つまたは複数の名前は両方の名前空間に共通であり、それらの名前は、リソースの異なるそれぞれのインスタンスを参照する。第１のリソース名の要求がアプリケーションから受信され、第１のリソース名は、第１のリソース名前空間中および第２のリソース名前空間中に存在する。要求に応答して、１つまたは複数のリソースポリシーを第１のリソース名前空間と第２のリソース名前空間とに適用することによって、第１の名前空間からリソースを取得すべきか、第２の名前空間からリソースを取得すべきかを判断する。
【０００７】
以下で、添付の図面に関連して考察する以下の詳細な説明を参照しながら、付随する特徴の多くについて説明する。
【０００８】
本明細書は、添付の図面に照らして以下の詳細な説明を読めば、よりよく理解され、図面中では、付随する説明において同じ部分を示すために同じ参照番号を使用する。
【図面の簡単な説明】
【０００９】
【図１】コンピュータ上の仮想化環境を示す図である。
【図２】重複するリソースの複数セットへのアクセスを管理する仮想化レイヤを示す図である。
【図３】リソース名前空間をフレキシブルに優先順位付けするための構成を示す図である。
【図４】リソース名前空間を優先順位付けするための概略的プロセスを示す図である。
【図５】リソース名前空間を優先順位付けするためのポリシーを使用するためのプロセスを示す図である。
【図６】様々なリソース名前空間に様々なポリシーを適用するためのプロセスを示す図である。
【図７】リソース名前空間に関連する例示的なポリシーを示す図である。
【図８】様々なシーケンスで適用された図７のポリシーを示す図である。
【発明を実施するための形態】
【００１０】
（概観）
以下で説明する実施形態は、コンピューティングシステム上のリソースへの仮想アクセスを管理することに関連する。最初に、仮想環境について説明する。次いで、仮想環境で使用される名前空間をフレキシブルに優先順位付けするための概略的技法について説明する。さらに、名前空間を優先順位付けするための詳細な特徴および実施形態について説明する。
【００１１】
（仮想環境）
図１に、コンピュータ１０２上の仮想化環境１００を示す。コンピュータ１０２上で実行中のアプリケーション１０４は、仮想化環境１００を介して様々なシステムリソース１０６、１０８、および１１０にアクセスする。仮想化環境１００は、システムリソース１０６、１０８、１１０へのアプリケーション１０４のアクセスを管理する。システムリソース１０６、１０８、および１１０は、コンピュータ上で利用可能などんなタイプのリソースでもよい。たとえば、システムリソース１０６は、システムファイル、レジストリまたはデータベースエントリ、初期化または構成ファイル、動的ロードライブラリなどとすることができる。システムリソース１０８は、オブジェクト通信サービス、印刷サービス、カットアンドペーストサービスなどのシステムサービスとすることができる。システムリソース１１０は、プロファイルデータ、ＴＣＰ／ＩＰアドレスおよび／またはポート、ミューテックス、セマフォ、名前付きパイプ、ＣＯＭオブジェクト、オブジェクトブローカー、フォントなどとすることができる。
【００１２】
システムリソース１０６、１０８、および１１０は、コンピュータ１０２上の可視性の異なるスコープを有することがある。一部のリソース１０６、１０８、１１０は、コンピュータ１０２上のすべてのアプリケーションに対して可視であるグローバルネイティブリソースとすることができる。一部のシステムリソース１０６、１０８、および１１０は、アプリケーション１０４のみに対して可視またはアクセス可能であるローカルリソースである可能性がある。たとえば、アプリケーション仮想化パッケージは、アプリケーション１０４のみが使用するファイル、レジストリエントリ、構成設定、または他のリソースのインスタンスを含むことができる。また、あるユーザのみに対して、または仮想化環境１００を使用しているアプリケーションのみに対して利用可能である他の半ローカルな（ｓｅｍｉ−ｌｏｃａｌ）リソースが存在する可能性もある。とりわけ、これらのローカルまたは半ローカルなリソースのいずれかが、同じ名前を有する対応するネイティブのリソースインスタンス（すなわち、コンピュータ１０２上のグローバルリソース）を有する可能性がある。すなわち、背景技術で言及したように、リソース名が与えられれば、その名前をもつグローバルリソースのインスタンス、その名前をもつローカルリソースのインスタンス、および／またはその同じ名前をもつ半ローカルリソースのインスタンスが存在する可能性がある。そのような名前空間の競合を処理する方法をフレキシブルに制御するための技法について、後で詳細に説明する。
【００１３】
仮想化環境１００は、リソース１０６、１０８、および１１０を仮想リソース１１２の１つのセットのように見せることができる。アプリケーション１０４は、あたかもシステムリソース１０６、１０８、および１１０に直接アクセスするかのように読取りおよび／または書込み操作を実行することができるが、仮想化環境１００はそれらの操作を仲介する。概して、アプリケーション１０４は、仮想化環境１００がコンピュータ１０２上に存在しない場合と少しも変わらない動作をする。ただし、（システムリソース１０６、１０８、および１１０など）リソースの名前空間を管理することについて以下で説明する実施形態は、仮想化環境が存在する場合にアプリケーションがその挙動を変えるかどうかにかかわらず適用可能である。
【００１４】
図２に、リソース１５２、１５４、および１５６の複数の重複するセットへのアクセスを管理する仮想化レイヤ１５０を示す。アプリケーション１５８は、仮想化レイヤ１５０を介してリソース１５２、１５４、および１５６に透過的にアクセスする。異なる状況下で、リソース１５２、１５４、および１５６のセットは、異なる順位および目的を有することができる。ユーザセット１５２はアプリケーション１５８のみにスコープされ、パッケージセット１５４は、仮想化レイヤ１５０下で同じユーザによって実行されているアプリケーションにスコープされ、グローバルセット１５６はグローバルスコープを有する。ホストコンピュータ上のどんなアプリケーションまたはユーザ識別子もリソースセット１５６に潜在的にアクセスすることができる。他のタイプのリソースを使用することもできる。別の実施形態では、セット１５２は、仮想環境で実行中のすべてのアプリケーション用とすることができ、セット１５４は、アプリケーションを実行しているすべてのユーザにわたるすべての仮想環境用とすることができる。リソース１５２、１５４、および１５６のセットはタイプによってカテゴリ１６０、１６２、および１６４に分割された状態が示されているが、特定のコンピューティングプラットホーム上でリソースがアクセスされる方法によっては、これは不要になることがある。一実施形態では、リソース１５２、１５４、または１５６のセットは、同じスコープをもつすべてのタイプのリソース、たとえば、グローバルファイル、レジストリエントリ、ネットワーク接続、またはローカルファイルおよびシステムサービスなどを含むコンテナである。
【００１５】
上述のように、リソースの１つのセットは、別のセット中の別のリソースインスタンスと同じ名前をもつリソースインスタンスを有することがあるので、リソース１５２、１５４、および１５６のセットは重複する可能性がある。図２の例では、リソース「ｃ：＼ｄｉｒ＼ｆｉｌｅ１」のインスタンスがリソースのセットの各々の中にある。インスタンスは、異なるコンテンツ、異なるサイズなどを有する。「ｃ：＼ｄｉｒ１＼ｆｉｌｅ４」など、別のリソースは、グローバルリソースセット１５６の中のみにある。仮想化レイヤ１５０は、「ｃ：＼ｄｉｒ１＼ｆｉｌｅ２」という名前のファイルを開けというアプリケーション１５８の要求を処理する。
【００１６】
仮想化レイヤ１５０は、ユーザリソース１５２、１５４、および１５６のセットの優先順位を固定することが可能である。たとえば、仮想化レイヤ１５０は、おそらくユーザリソース１５２のセットに優先権を与え、リソース１５２のセット中の「ｃ：＼ｄｉｒ１＼ｆｉｌｅ２」のインスタンスを開き、対応するファイルハンドルまたはファイルオブジェクトをアプリケーション１５８に返し、このようにしてアプリケーション１５８にリソース１５２のユーザセット中のインスタンスを使用させることができる。アプリケーションが「ｃ：＼ｄｉｒ１＼ｆｉｌｅ４」という名前のファイルにアクセスする場合、リソースは、そのリソースを有する唯一のセットであるリソースセット１５４から取得される。静的な優先順位付けのこの手法は、有用なことがあるが、限界を有する。次に説明するように、仮想化環境１５０は、リソース名前空間が、様々な条件またはコンテキストの下で変化する優先順位をとることができるように拡張できる。
【００１７】
フレキシブルな名前空間優先順位付け
図３に、リソース名前空間をフレキシブルに優先順位付けするための構成を示す。この構成では、仮想化レイヤ１５０はポリシーエンジン１９２を備える。ポリシーエンジン１９２は、リソース名前空間１９０をフレキシブルに優先順位付けするソフトウェア構成要素とすることができる。ポリシーエンジン１９２および仮想化レイヤ１５０は別々の構成要素として示されているが、機能のこの分割は便宜のためであり、他の構造上の構成が可能である。とはいえ、たいていの場合、ポリシーエンジン１９２は、仮想化レイヤ１５０の存在を顧慮せずに動作するアプリケーション１９４に対して可視ではない。
【００１８】
図３には、異なる仮想環境１９６、１９８も示されている。仮想化レイヤ１５０は、分離された状態で動作する異なる仮想環境でアプリケーションを実行して、リソース競合を回避または最小化し、アプリケーション間の干渉を防ぎ、同じアプリケーションの異なるインスタンスを実行できるようにすることなどが可能である。たとえば、仮想環境１９６はＡｄｏｂｅソフトウェア用とすることができ、仮想環境１９８はＭｉｃｒｏｓｏｆｔ  Ｏｆｆｉｃｅアプリケーション用とすることができる。したがって、仮想環境１９６、１９８は、それら自体のリソース名前空間２００、２０２と、それぞれリソース名前空間２００、２０２を優先順位付けするためのポリシー２０４、２０６とを有することができる。
【００１９】
後で説明するように、ポリシー２０４、２０６は、アプリケーション１９４によって必要とされる異なるリソースに対して異なる順序でリソース名前空間の任意のセット（たとえば、リソース名前空間２００、２０２）を優先順位付けするためにポリシーエンジン１９２が使用することができる情報を含む。名前空間２００、２０２からの矢印で示されるように、リソース名前空間２００、２０２は、仮想化レイヤ１５０によって管理されるリソース名前空間のプールまたはキャッシュ２０８に記憶された実際のリソース名前空間への参照とすることができ、したがって、いくつかのリソース名前空間（たとえば、リソース名前空間２００、２０２）を、ポリシーエンジン１９２に都合よく渡し、また、必要なときに、仮想環境（たとえば、仮想環境１９６、１９８）間で共有することなどが可能になる。本明細書全体にわたって、実際のリソースのインスタンスを含むコンテナ、ならびに名前空間にアクセスし、構成要素間で渡し、共有するためなどの、そのような名前空間への参照（たとえば、ポインタ、グローバル一意識別子、オブジェクト参照など）の両方を指すために、「名前空間」を使用する。
【００２０】
図４に、リソース名前空間を優先順位付けするための概略的プロセスを示す。名前空間を動的およびフレキシブルに優先順位付けする（たとえば、アプリケーションによって必要とされる様々なリソースの名前空間を再優先順位付けする）という一般的な発想は、多数の方法で実現でき、本明細書で説明する実施形態は、それらの方法のほんのいくつかにすぎないことを理解されたい。最初に、上述のように、アプリケーションは、それがアクセスする必要があるリソースの名前を有する。したがって、その名前を仮想化レイヤ１５０に提供する（または仮想化レイヤ１５０がインターセプトする）（２２０）（これはアプリケーションに対して透過的である）。次に、仮想化レイヤ１５０および／またはポリシーエンジン１９０は、どのポリシー（たとえば、ポリシー２０４）および名前空間が、要求されたリソースに潜在的に関連しているかを判断する（２２２）。名前空間のいずれも、必要とされるリソースを潜在的に供給することができるので、そのような名前空間は、仮想環境に知られているポリシーと名前空間のすべてとなる可能性がある。所与のポリシーがどの（１つまたは複数の）名前空間に関連しているかが知られるように、名前空間およびポリシーを予め関連付けることもできる。たとえば、仮想化レイヤまたは環境に対するユーザ構成設定は、どの名前空間を使用すべきか、およびそのデフォルトの優先順位を指定することができる。最後に、判断された（２２２）名前空間にポリシーを適用して（２２４）、名前空間を優先順位付けする。後で明らかとなるように、第１のリソースがアプリケーションによって必要とされ、図４のプロセスを使用して取得され、次いで第２のリソースが必要とされ、図４のプロセスを使用して取得された場合、同じ判断された（２２２）ポリシーと名前空間を使用して名前空間を優先順位付けしたとしても、それらの名前空間は、必要とされるリソースごとに異なる優先順位を有する。さらに、どの名前空間からリソースを取得するかは、関連しているポリシーを変更すること、新規のポリシーを追加すること、またはポリシーを削除することなどによって（アプリケーションまたは仮想化レイヤを変更する必要なしに）フレキシブルに変更できる。
【００２１】
図５に、リソース名前空間を優先順位付けするためのポリシーを使用するためのプロセスを示す。ポリシーを異なる方法で実施することが可能であり、図５のプロセスは、それらの方法のうちの１つにすぎないことを理解されたい。最初に、アプリケーションは、リソースの名前（たとえば、ファイルの名前）を有し、対応するリソース（たとえば、ファイル）へのアクセスを必要とする（２５０）。おそらくシステムコール（たとえば、その名前によってファイルを開く要求、またはシステムリソースを要求する何らかの他の手段）に応答して、仮想環境は、必要とされるリソースの完全修飾名と、アプリケーションの仮想環境がアクセスすることができるリソース名前空間のリストと、仮想環境用に定義されたポリシーのリストとをポリシーエンジンに通信する（２５２）。この場合も、他の技法を使用することができる。たとえば、要求されたリソースごとにポリシーと名前空間の静的な予め定義されたセットを使用すること、リソースの要求の前に優先順位付けすべき名前空間のリストを判断することなどが可能である。
【００２２】
ポリシーエンジンは、ポリシーエンジンに通信された（２５２）それぞれの名前空間に対して候補の名前空間構造（名前空間を表す構造）のリストを作成する（２５４）。各構造は、その構造が表す名前空間を特定する一意の識別子（ＩＤ）を有する。この構造は、最初は０に設定される優先順位スコアをも有する。図７に例を示すが、これについては後で説明する。ポリシーエンジンは、通信された（２５２）名前空間に通信された（２５２）ポリシーを適用し、得られた優先順位スコアを構造中に格納することによって、それぞれ構造のリストを使用して名前空間のスコアを決定する（２５６）。構造中の優先順位スコアごとに、必要とされる（２５０）リソースを提供するための候補でないことが判明した候補の名前空間（たとえば、第１のポリシーには関連するが、別のポリシーには関連しないので、ポリシーエンジンに渡された名前空間）を構造のリストから削除する（２５８）。残りの名前空間を、それらの優先順位スコアによって順序付けし（２６０）、仮想化レイヤに返し（２６２）、次いで仮想化レイヤは、残りの名前空間から必要とされる（２５０）リソースを取得することができ、今度はこのリソースをアプリケーションに、その最初の要求に応答して供給することができる。
【００２３】
図６に、様々なリソース名前空間に様々なポリシーを適用するためのプロセスを示す。概して、ポリシーエンジンに通信される（２５２）各ポリシーは、ポリシーエンジンに通信される（２５２）各名前空間の優先順位に潜在的に影響を与えることができる。したがって、名前空間にポリシーを適用することを開始する（２８０）ために、まだ適用されていないポリシーを選択する（２８２）。理解されるように、ポリシーを適用する順序は、名前空間について計算される優先順位に影響を及ぼしてはならない。ポリシーが、要求されたリソースに適用可能である（２８４）場合、候補の名前空間リスト（名前空間構造のリスト）中の（２８６）名前空間ごとに、以下のステップを実施する（ポリシーが適用可能ではなく、適用されていないポリシーがある（２９２）場合、そのポリシーを選択し（２８２）、処理する）。最初に、別のより特定的なポリシーがすでに名前空間に適用されている（２８８）場合（たとえば、名前空間の現在のスコアの絶対値が現在のポリシーの所望のスコアよりも大きい場合）は、別の名前空間を選択する（２８６）。そうでない場合は、たとえば、名前空間にポリシーのスコアを割り当てることによって、現在のポリシーを現在の名前空間に適用する（２９０）。適用されていないポリシーがある（２９２）場合、別のポリシーを選択し（２８２）、それに応じて適用する。適用されていないポリシーがない（２９２）場合、ランク付け／優先順位付けされた名前空間を返す。
【００２４】
要求された名前空間にポリシーが適用可能であるかどうか（２８４）は、多数の方法で判断できることに留意されたい。たとえば、ポリシーは、「ｄｏｃ」で終わるすべてのファイル名に適用される、ディレクトリ「＼ｄｉｒｅｃｔｏｒｙ１＼ｄｉｒｅｃｔｏｒｙ２」中のファイルに適用される、レジストリ位置中のエントリに適用されるなど、いくつかのコンテキスト基準またはセット定義を有することができる。また、図６では、外側ループでポリシーを繰り返し、ポリシーごとに名前空間を繰り返すが、結果は、ポリシーを適用する順序に影響されないので、逆の順序を使用してもよいことに留意されたい。すなわち、外側ループで名前空間を繰り返し、内側のループでポリシーを現在の名前空間上で繰り返してもよい。
【００２５】
一実施形態では、アプリケーション１９４が（たとえば、「ｏｐｅｎ（ファイル名）」などのシステムコールを発行することによって）リソース名のリソースを要求する場合、リソース名、ポリシーのセット、および名前空間のセット（実際には、名前空間への参照、または名前空間のグローバル一意識別子）を、仮想化レイヤ１５０を介してポリシーエンジン１９２に渡すことができる。ポリシーエンジン１９２は、この情報を使用して名前空間を優先順位付けし、リソースは、リソース名のリソースを含む最高優先順位の名前空間から取得される。
【００２６】
図７に、リソース名前空間に関連する例示的なポリシー３２０、３２２、３２４を示す。Ｕ、Ｐ、およびＮと呼ぶ３つの仮定のリソース名前空間が、利用可能なリソース源である。ポリシー３２０および３２４はそれぞれ、名前空間Ｕ、Ｐ、およびＮに関連する。関連の順序（Ｕ、次いでＰ、次いでＮ）は、これらの名前空間のデフォルトの優先順位を反映し、Ｕは最高優先順位を有するということに留意されたい。ポリシー３２２は、名前空間Ｎには関連するが、ＰおよびＵには関連しない。例示的なポリシー３２０、３２２、３２４は、レジストリ位置であるが、ファイルディレクトリまたはリソースのセットの他の定義であってもよい。たとえば、ポリシーは、ローカルレジストリの変更がユーザの個人設定レジストリ名前空間に及ばなければならないことを指定することができる。別のポリシーは、ユーザのプロファイルへの変更がローカルファイルシステム名前空間中で行われなければならないこととすることができる。さらに別の例では、「＊．ｄｏｃ」に合致する名前をもつファイルには、常にローカルファイルシステム名前空間からアクセスしなければならない。あるいは、ネットワーク共有への変更を、所与のリソース名前空間を使用して実施すべきである。いくつかの他の例を検討されたい。
【００２７】
ポリシー３２０、３２２、および３２４などのポリシーは、（前節での例のいくつかと同様に）どの名前空間に適用されるか、または名前空間はどんなポリシーにも自由に関連できるのいずれか一方を本質的に指定することができる。ポリシーが名前空間に関連しない場合（少なくとも特定の名前空間を優先順位付けするために使用されている場合）、そのポリシーは、その特定の名前空間を直接優先順位付けすること可能性があると仮定できる。ポリシーは複数の名前空間に関連でき、その場合、それらの名前空間は、それら自体の間でのデフォルトの優先順位を有しなければならない。ポリシーはまた、そのポリシーが適用される名前空間を優先順位付けするために使用できる何らかの情報を有することができる。たとえば、何らかの重み付け定数が使用できる。優先順位はまた、要求された名前にポリシーを適用可能である度合いであって、２つのポリシーがリソース名に合致する場合、より特定的なコンテキストを有するポリシー（たとえば、より特定的なファイルシステムディレクトリ、ワイルドカード指定のファイル名ではなく明示的なファイル名、より長いレジストリパス、特定の部分文字列を含むパス名など）の方法でポリシーを適用することを可能にする度合いに基づいて、割り当てることができる。
【００２８】
図８は、図５および図６の実施形態による、異なるシーケンスで適用された図７のポリシー３２０、３２２、３２４を示す。次に、データ構造３４０のリストについて詳細に説明し、後で類似のリスト３４２および３４４について簡潔に説明する。この例では、各ポリシーの重みまたは優先順位スコアは、各ポリシーが指定するパスの長さによって決定され、それぞれＵ、Ｐ、およびＮに対して１６、２５、および３１である。他の重みを使用することもでき、パス長は、特定性の好都合な尺度となることがある。重みは、ワイルドカードの存在、いくつかの予め定義された基準などのファクタによって加えることもできる。
【００２９】
アプリケーションが、完全修飾リソース名「ＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ａｄｏｂｅ＼ＪｏｂＱｕｅｕｅ＼Ｃｏｎｆｉｇ」（簡潔に、「ＨＫＬＭ．．．Ｃｏｎｆｉｇ」と称する）に対応するリソースを必要とする（２５０）と仮定する。ポリシー３２０、３２２、および３２４は、要求が行われた仮想環境に対応し、したがって、それらのポリシーならびにそれらに関連する名前空間をポリシーエンジン（または同様の機能の何らかの仮想化構成要素）に通信する（２５２）。ポリシーエンジンは、リスト３４０中の「名前空間」および「初期」の列のように、名前空間ごとに候補の名前空間構造を作成し（２５４）、優先順位を０に設定する。ポリシー３２０、３２２、３２４を次のように適用する（２８０）。
【００３０】
最初にポリシー３２０を選択する（２８２）。要求された名前「ＨＫＬＭ．．．Ｃｏｎｆｉｇ」が、ポリシー３２０によって指定されたパス（コンテキスト）に該当するので、ポリシー３２０は適用可能である（２８４）。言い換えれば、要求されたリソース名「ＨＫＬＭ．．．Ｃｏｎｆｉｇ」は、ポリシー３２０のコンテキストに合致する。したがって、候補リスト３４０中の各名前空間Ｕ、Ｐ、およびＮに対して、以下のことが行われる。Ｕの現在のスコアの絶対値（０）はポリシー３２０の企図されたスコア（１６．３）よりも小さいので、名前空間Ｕを適用する（２９０）。「．３」は、ポリシー３２０に対して、名前空間Ｕ、Ｐ、およびＮの中でＵがデフォルトの最高優先順位を有することを表すために追加されていることに留意されたい。同様に、「．２」および「．１」がそれぞれＰおよびＮの重みに追加されている。次いでＰおよびＮにポリシー３２０を適用し、ＰおよびＮはそれぞれ、１６．２および１６．１のスコアを与えられる。適用されていないポリシー３２２、３２４が存在する（２９２）。ポリシー３２２を選択する（２８２）。ポリシー３２２は、リスト３４０中のスコアよりも大きい優先順位重みを有するので、名前空間に−２５、−２５および２５のスコアを付ける。ポリシー３２２は名前空間ＵおよびＰに関連しないので、それらの名前空間に対して負のスコアが与えられる。最後に、最後のポリシー３２４の重みまたはスコア３１は先行するスコアの絶対値よりも大きいので、各名前空間に最後のポリシー３２４を適用する（２９０）。名前空間の最終スコアは、３１．３、３１．２および３１．１であり、これは、「ＨＫＬＭ．．．Ｃｏｎｆｉｇ」のリソースが名前空間から取得される場合、「ＨＫＬＭ．．．Ｃｏｎｆｉｇ」に対応するリソースが名前空間のうちの１つで見つかるまで、名前空間Ｕ、Ｐ、およびＮがその順序で使用されることを示す。
【００３１】
名前空間リスト３４２および３４４は、ポリシー３２０、３２２、３２４を異なる順序で適用する場合、スコアがどのように割り当てられるかを示す。順序がポリシー３２２、３２０、次いで３２４である場合は、リスト３４２が得られる。順序がポリシー３２４、３２２、次いで３２０である場合、リスト３４４が得られる。各場合における名前空間の最終スコアは同じである。
【００３２】
上述した実施形態のうちのいくつかによれば、複数の重複する名前空間からリソースを取得することができ、（たとえば、ポリシーを使用することによって）異なる名前空間が優先される一般的な（またはより特定的な）状況を指定することによってフレキシブルで予測可能な様式で競合を解決することができる。同じポリシーエンジンは、同じ仮想化レイヤと協働して、その仮想化レイヤによって処理される異なる仮想環境用の異なるポリシーを用いて異なる名前空間を優先順位付けすることができる。さらに、いくつかの実施形態では、名前空間にポリシーをいかなる順序で適用しても決定論的結果を得ることができる。
【００３３】
（結論）
上述した実施形態および特徴は、揮発性または不揮発性コンピュータまたは装置可読媒体に記憶された情報の形態で実現できる。これは、少なくとも、光記憶装置（たとえば、ＣＤ−ＲＯＭ）、磁気媒体、フラッシュＲＯＭ、またはデジタル情報を記憶する任意の現在もしくは将来の手段などの媒体を含むとみなされる。記憶される情報は、機械実行可能命令（たとえば、コンパイルされた実行可能なバイナリコード）、ソースコード、バイトコード、または上述した様々な実施形態を実施するようにコンピューティングデバイスを使用可能にするもしくは構成するために使用できる任意の他の情報の形態とすることができる。これはまた、少なくとも、一実施形態を実施するプログラムの実行中にＣＰＵ命令などの情報を記憶するＲＡＭおよび／または仮想メモリなどの揮発性メモリ、ならびにプログラムまたは実行可能ファイルがロードされ、実行されることを可能にする情報を記憶する不揮発性媒体を含むとみなされる。実施形態および特徴は、ポータブルデバイス、ワークステーション、サーバ、移動無線装置などを含む、どんなタイプのコンピューティングデバイス上ででも実施できる。
【図１】
0005460588.tif 000002
【図２】
0005460588.tif 000003
【図３】
0005460588.tif 000004
【図４】
0005460588.tif 000005
【図５】
0005460588.tif 000006
【図６】
0005460588.tif 000007
【図７】
0005460588.tif 000008
【図８】
0005460588.tif 000009