JP2008509475A - コンテキストポリシー制御によるアプリケーション間の関連付けの制御のためのシステムおよび方法 - Google Patents

Abstract

複数のソフトウェアアプリケーションおよびリソースの相互運用性を制御する方法は、第１のアプリケーションから第２のアプリケーションまたはリソースへの通信をインターセプトするステップと、通信をコンテキスト管理システムに向けるステップと、通信用のコンテキスト候補リストを生成するステップと、これらのコンテキストのために定義された少なくとも１つのポリシーに従って候補リストを評価して、通信のために結果として生じたアクションおよび名前空間を識別するステップと、識別された名前空間内のポリシーによって定義された通りにアクションを実行するステップとを含む。この方法は、第２のアプリケーションの、１つまたは複数のバージョンを追跡するとともに、アプリケーションおよび／またはリソース名の進化を追跡するステップをさらに含む。この方法は、候補リスト上のコンテキストに関連付けられている１つまたは複数の操作を識別するステップと、その後の通信の前に識別された操作を実行するステップとをさらに含む。

Description

本発明は、コンピュータソフトウェアに関し、より詳細には、オペレーティングシステムソフトウェアに関する。

本出願は、参照により全内容が本明細書に組み込まれる、２００４年８月３日出願の米国特許仮出願第６０／５９８，２３４号明細書の利益を主張する。

多くの環境において、しかし特に、アプリケーションがネットワークを介して配信される環境において最も重要な機能は、複雑なインストールなしに、実行中にアプリケーションを稼働させることができる能力である。通常、いくつかの従来技術のシステムでは、プログラムがインストールされているかのように見せるためにクライアントシステムを変更したり、実際にソフトウェア自体をインストールし、次いでこれらの変更を取り消して、元の構成を復元したりするのが非常に面倒であった。これを行う際、次のような複数の問題が生じる。アプリケーションとコンピュータの現在の構成との間に競合があったり、同じまたは異なるアプリケーションのインスタンスがあったり、取り消しのプロセスが複雑であるため、アプリケーションを厳密なプロセスにかけて、その変更のすべてを確実に考慮できるようにする必要があったり、複数のアプリケーションによる共有ファイルやシステム構成要素の使用によって、取り消しやインストールのプロセスが複雑になっていたりする。

米国特許第０９／８５９，２０９号明細書

多くのアプリケーション実行環境内では、社会性（ｓｏｃｉａｂｉｌｉｔｙ）およびバージョン管理の問題によるシステムの障害を防ぐために、アプリケーションを分離することが望ましい。しかし、そうするように構成されていない限り、分離は、これらのプログラムの相互運用を妨げる可能性がある。この問題は、ソフトウェアアプリケーションがオペレーティングシステム内で実行されるが、しかし実際にはそのオペレーティングシステム（ＯＳ）にインストールされない、あるいはいくつかのケースでは、実行中にインストールされ削除される「仮想インストール」環境において特に深刻である。

本発明による実施形態は、そうするように設計されていない環境、またはデフォルトの挙動を介して追加のシステム構成を必要とする環境の存在下で、アプリケーション間の通信および関連付けを容易にすることを対象とする。実施形態は、システムの元の前提を保持し、アプリケーションのランタイム分離を提供し、しかし厳しい管理ポリシーおよび操作ポリシー下での相互運用性を可能にする。

本発明の一態様によれば、複数のソフトウェアアプリケーションおよびリソースの相互運用性を制御する方法は、第１のアプリケーションから第２のアプリケーションまたはリソースへの通信をインターセプトするステップと、通信をコンテキスト管理システムに向けるステップと、通信用のコンテキスト候補リストを生成するステップと、これらのコンテキストのために定義された少なくとも１つのポリシーに従って候補リストを評価して、通信のために結果として生じたアクションおよび名前空間を識別するステップと、識別された名前空間内のポリシーによって定義された通りにアクションを実行するステップとを含む。この方法は、第２のアプリケーションの、１つまたは複数のバージョンを追跡するとともに、アプリケーションおよび／またはリソース名の進化を追跡するステップをさらに含む。この方法は、候補リスト上のコンテキストに関連付けられている１つまたは複数の操作を識別するステップと、その後の通信の前に識別された操作を実行するステップとをさらに含む。候補リストは、１つまたは複数の分散されたコンテキストから生成される。これらの通信は、プロセス間通信、オペレーティングシステム呼び出し、ＡＰＩ呼び出し、またはライブラリ呼び出しのうちの少なくとも１つを含む。コンテキストは、グローバルコンテキスト、管理コンテキスト、ローカルシステムコンテキスト、システム仮想コンテキスト、ベンダーコンテキスト、ユーザコンテキスト、セッションコンテキスト、共有コンテキスト、または隔離コンテキスト（ｉｓｏｌａｔｅｄ ｃｏｎｔｅｘｔ）のうちの少なくとも１つを含む。ポリシーは、ポリシーをいつ適用するかを識別するマッチニーモニック（ｍａｔｃｈ ｍｎｅｍｏｎｉｃ）、複数の要求相関パラメータ（ｒｅｑｕｅｓｔ ｃｏｒｒｅｌａｔｉｏｎ ｐａｒａｍｅｔｅｒ）、およびポリシーを適用するルールのうちの少なくとも１つを含む。

本発明の別の態様によれば、他のアプリケーションまたはリソース内で実行されるアプリケーションのための代替名前空間を定義する方法は、一般名のリソースの呼び出しをインターセプトするステップと、その呼び出しの対象の名前空間を識別するステップと、その一般名を、その名前空間内のアプリケーションによって使用可能なローカル名に変換するステップと、そのローカル名によって識別されるリソースへのアクセスを提供するステップとを含む。この方法は、アプリケーションの、１つまたは複数のバージョンを追跡するとともに、アプリケーションまたはリソース名の進化を追跡するステップをさらに含む。ローカル名によって識別されたリソースへのアクセスが、代替名前空間における異なるローカル名によって識別されるリソースに対して容易になりうるように、ローカル名を絶対名に変換することもできる。対象の名前空間を識別するステップは、１つまたは複数の分散されたクエリを含み、対象の名前空間についての少なくとも１つのクエリは、１つまたは複数のシステムに共通する名前空間を追跡する管理システムに対して行われ得る。

本発明の別の態様によれば、複数のソフトウェアアプリケーションおよびリソースの相互運用性を制御するシステムは、通信用のコンテキスト候補リストを生成するコンテキスト管理システムと、コンテキストのために定義された少なくとも１つのポリシーに従って候補リストを評価するポリシーエンジンであって、さらに通信のために結果として生じたアクションおよび名前空間を識別するポリシーエンジンと、第１のアプリケーションから第２のアプリケーションまたはリソースへの通信をコンテキスト管理システムに向ける仮想関係マネージャであって、識別された名前空間内の少なくとも１つのポリシーによって定義されたように結果として生じたアクションを示す指示を受信する仮想環境マネージャとを含む。

本発明は、クライアントコンピュータのオペレーティングシステムの変更なしにアプリケーションソフトウェア環境を作成するシステムを提供し、このシステムは、オペレーティングシステム抽象化／保護レイヤ（ａｂｓｔｒａｃｔｉｏｎ ａｎｄ ｐｒｏｔｅｃｔｉｏｎ ｌａｙｅｒ）を含み、前記抽象化／保護レイヤは、稼働中のソフトウェアアプリケーションと前記オペレーティングシステムとの間に挿入され、それによってアプリケーションが稼働することができる仮想環境が提供され、実質上アプリケーションレベルの対話が取り除かれる。好ましくは、オペレーティングシステムへの直接の任意の変更は、稼働中のアプリケーションのコンテキスト内で選択的に行われ、抽象化／保護レイヤは、管理設定に従って仮想環境を動的に変更する。さらに、いくつかの実施形態において、システムは、共有システムリソースの使用を絶えず監視し、システム構成要素への変更を適用したり削除したりするサービスとして働く。

したがって、例えば、Ｗｉｎｄｏｗｓ（登録商標）レジストリへのすべての操作がＷｉｎ３２ ＡＰＩを介して行われる、Ｗｉｎｄｏｗｓ（登録商標）ベースのオペレーティングシステム内の実施形態では、システムは、好ましくは、機能をフックする手段を提供し、それによって前記機能が呼び出されるたびに、別の機能またはアプリケーションが呼び出しをインターセプトし、システムは、最も好ましくは、サーバから稼働されるアプリケーションによる要求かどうかに関係なく、またはアクティブに管理される構成キーに対するアプリケーションによる要求である場合、適切な各ＡＰＩ関数をフックして要求に応じる。

本発明の上記および他の特徴および利点は、様々な図面を通じて類似の参照番号が同じ部品を参照する添付の図面に示されているように、本発明の実施形態の以下のより特定の説明から明らかになる。

次に、図１を参照すると、オペレーティングシステムとソフトウェアアプリケーションとの本発明の相対的な関係を図示するブロック図が示されている。本発明の好ましい実施形態は、「オペレーティングシステムガード」と呼ばれるオペレーティングシステム抽象化／保護レイヤ１００を提供する。内部で、多くのオペレーティングシステム１０は、アプリケーション５０が稼働時に互いに影響を与えることを防ぐために、障害ドメインを提供する。しかし、共有システムリソース、および他の多くのオペレーティングシステムの機能によって、この保護ドメインへの障害が可能になってしまう。オペレーティングシステム抽象化／保護レイヤ１００は、ほとんどのアプリケーションレベルの対話を取り除くために、アプリケーション５０間に、追加の、プログラム制御されるバリアを提供する。オペレーティングシステム抽象化／保護レイヤ１００は、アプリケーション５０とオペレーティングシステム１０との間に配置されており、変更を稼働中のアプリケーションのコンテキスト内に封じ込めることに対して、オペレーティングシステム１０への直接の変更を選択的に可能にする。一例として、Ｗｉｎｄｏｗｓ（登録商標）ベースのシステムでは、Ｗｉｎｄｏｗｓ（登録商標）レジストリへのすべての操作は、通常、Ｗｉｎ３２ ＡＰＬを介して行われる。以下で説明するように、ＱｕｅｒｙＲｅｇＥｘやＧｅｔＰｒｏｆｉｌｅＳｔｒｉｎｇのようなシステム関数は、呼び出されるたびに、別の関数またはアプリケーションが呼び出しをインターセプトするように、フックすることができる。本発明のオペレーティングシステムガード１００は、アクティブに管理されているアプリケーションによる要求である場合、またはアクティブに管理されている構成項目に対するアプリケーションによる要求である場合、適切な各ＡＰＩ機能をフックして要求に応じる。このように、そうするように明確に構成されていない限り、本発明の実施形態は、エンドユーザのシステムに対してどんな実際の変更をも加えることなく、アプリケーション環境を作成することができる。また、実行時にアプリケーションによって加えられる任意の変更は、容易に持続されたり、削除されたりすることができる。

本明細書で使用される場合、「オペレーティングシステムガード」という用語は、稼働中のアプリケーションと、アプリケーションが稼働し得る仮想環境を提供する対象のコンピュータまたはクライアントコンピュータのオペレーティングシステムとの間のレイヤを定義する。この仮想環境は、いくつかの目的を有する。まず、仮想環境は、稼働中のアプリケーションがクライアントコンピュータに変更を加えることを防ぐ。アプリケーションがクライアントコンピュータの基礎を成すオペレーティングシステムの設定を変更しようと試みる場合、こうした設定は、保護され、仮想環境においてのみ「行われる」。例えば、アプリケーションがＭＳＶＣＲＴ．ＤＬＬのような共有オブジェクトのバージョンを変更しようと試みる場合、この変更は、そのアプリケーションに局限され、クライアントコンピュータにあるコードはもとのままである。

第２に、本発明の一実施形態は、インストールを実行することなくインストール環境であるように見え、したがって「疑似インストール」または「インストールのよう」な環境を稼働中のアプリケーションに提供する。すべての設定は、提供されているアプリケーションが稼働するとき、またはアプリケーションが特定の設定を必要とするちょうどよいときに仮想環境に導入される。例えば、Ａｄｏｂｅ Ｐｈｏｔｏｓｈｏｐ（登録商標）などのコンピュータプログラムがＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ＼Ｓｏｆｔｗａｒｅ＼Ａｄｏｂｅ下の１組のＷｉｎｄｏｗｓ（登録商標）レジストリエントリを認識すると予想し、Ｐｈｏｔｏｓｈｏｐがインストールされていないために、レジストリエントリがクライアントコンピュータ上のそこにない場合、本発明のこの態様に従って作成されたシステムは、まさにレジストリエントリがクライアントコンピュータ上にあるかのように、Ｐｈｏｔｏｓｈｏｐプログラミングコードにこうしたレジストリエントリを「示す」。

次に、本発明の一実施形態は、クライアント／ユーザのマシンに存在し得る情報がアプリケーションの挙動を干渉したり変更したりするのを防ぐ。例えば、ユーザがすでに、Ｐｈｏｔｏｓｈｏｐの古いバージョンについて、
ＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ＼Ｓｏｆｔｗａｒｅ＼Ａｄｏｂｅ
下に既存のレジストリエントリを有しており、今は新しいバージョンを操作することを望んでいる場合、競合を防ぐために、こうしたエントリを新しいアプリケーションから隠すことができる。

最後に、本発明の一実施形態は、アプリケーションの現在の書き方では存在し得ないアプリケーションの挙動をロック解除する。本発明の一実施形態は、管理設定に従って仮想環境を動的に変更する機能を介してこれを行う。例えば、企業ソフトウェアアプリケーションの典型的な例では、クライアントアプリケーションは、ユーザがレジストリのある設定から接続すべきデータベースのアドレスの設定を読み取ると予想し得る。このレジストリキーは、ＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥに格納されることが多いため、設定は、クライアントコンピュータ全体にグローバルである。ユーザは、クライアントを再インストールするか、このレジストリキーをどのように変更するかがわからなければ、１つのデータベースにしか接続できず、アプリケーションを実行することを望むたびにそのようなことを行うことになる。しかし、本発明を実装することによって、異なるデータベースにそれぞれ接続するアプリケーションの２つのインスタンスは、同じクライアントコンピュータ上で稼働することができるようになる。

コンテキスト
この機能を提供することによって、各アプリケーションは、システム内のプライベートコンテキストで稼働することができる。アプリケーションにとって、システムがどのように見えるか、およびその挙動のそれ自体の私見を有する。本発明の実施形態は、その固有の性質によってこれを提供する。図２を参照すると、２つの別々のアプリケーション５２、５４、または同じアプリケーション（図１で５０と示されている）の２つのインスタンスに、別々のまたは異なるコピーのシステムサービス、構成、およびデータを有するように見えるプライベートコンテキストを提供することができる。好ましい実施形態では、これは、システムのデフォルトの挙動である。

この概念を拡張することによって、本発明の一実施形態のオペレーティングシステムガード１００は、２つ以上のアプリケーション５２、５４がその仮想設定の一部またはすべてを共有することができる、共有され、制御されたコンテキストを提供することもできる。これは、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅなどのアプリケーションスイート、または他のアプリケーションの存在下で異なるように働くアプリケーションには重要である。例えば、多くのアプリケーションは、メールマージまたは文書作成機能を行うエンジンとしてＭｉｃｒｏｓｏｆｔ Ｗｏｒｄを使用する。アプリケーションは、Ｗｏｒｄのインストールまたは存在について知っており、その機能を活用することができなければならない。好ましい実施形態において、同じアプリケーションの２つのインスタンスは、デフォルトでは単一のコンテキストを共有し、２つの別々のアプリケーションは、プライベートコンテキストを維持する。図３を参照すると、２つのアプリケーション５２、５４は、オペレーティングシステムガード１００が使用可能なシステムリソースの共有ビューを提供する間、稼働することができる。

設計
図４に示すように、オペレーティングシステムガードは、以下のサブシステム、コア１０２、構成マネージャ１０４、ファイルマネージャ１０６、共有オブジェクトマネージャ１０８、デバイスマネージャ１１０、フォントマネージャ１１２、プロセスマネージャ１２０、プロセス環境マネージャ１１４、ローダ１１６、およびリカバリマネージャ１１８から成る。コア１０２を除いて、プロセスマネージャ１２０およびローダ１１６、他のすべてのサブシステムは、以下でさらに詳しく説明される仮想化システムの要素である。コア１０２は、主に、構成ファイルによって定義された通りにアプリケーションおよびそのコンテキストを管理する役割を果たす。

オペレーティングシステムガードによって提供されるプロセスマネージャ１２０によって、コア１０２に、対象であり得る任意のプロセスまたは対象のスレッドイベントを知らせることができる。また、これは、プロセス空間を管理し、スレッド処理を扱うために、オペレーティングシステム依存型の実装に抽象化レイヤを提供する。プロセスを、いくつかのアプリケーションバンドルにまとめることができる。アプリケーションバンドルとは、その仮想リソースを互いにすべて共有する１群のプロセスである。例えば、Ｍｉｃｒｏｓｏｆｔ ＷｏｒｄおよびＭｉｃｒｏｓｏｆｔ Ｅｘｃｅｌは、アプリケーションスイートとして一緒に働くことができるように、仮想レジストリおよび仮想ファイルシステムを共有したい場合がある。プロセスマネージャ１２０は、これらのアプリケーションバンドルを「アプリケーション」と呼ぶ。プロセスマネージャ１２０がアプリケーションを解放するように指示されるまで、アプリケーションについての情報は存在する。別のプロセスは、アプリケーションバンドルにロードする必要がある場合、アプリケーションが解放されない限り、そうすることができる。

本発明の一実施形態のローダサブシステム１１６を使用して、仮想環境を稼働中のシステムに転送したり、そこから転送したりすることができる。各仮想化サブシステムは、その構成をローダ１１６用に直列化し、逆のプロセスを介してそれを復元することができる。さらに、ローダ１１６は、段階的にロード／アンロードし、個々の段階の結果を単一の環境記述にまとめることができる。

レジストリおよび構成
アプリケーションは、適切に動作するように、様々な量の構成情報を必要とする。アプリケーションがその構成を読み取ることができる、ゼロから数千の構成レコードが存在する。Ｗｉｎｄｏｗｓ（登録商標）では、構成情報、Ｗｉｎｄｏｗｓ（登録商標）レジストリおよびシステムレベル初期化ファイル、ｗｉｎ．ｉｎｉおよびｓｙｓｔｅｍ．ｉｎｉの共有の場所が２つある。さらに、＼ＷＩＮＤＯＷＳ（登録商標）＼ＳＹＳＴＥＭディレクトリは、アプリケーションがアプリケーション固有の構成または初期化ファイルを書き込む共通の場所である。また、アプリケーションは、追加の構成情報を格納するために、ローカルアプリケーションディレクトリ内の構成またはデータファイルを使用する。この情報は、メーカー独自のフォーマットであるため、扱いにくいことが多い。Ｗｉｎｄｏｗｓ（登録商標）以外のプラットフォームには、レジストリに相当するものはないが、構成情報のための共通ディレクトリが存在する。Ｘ Ｗｉｎｄｏｗｓ（登録商標）には、ａｐｐ−ｄｅｆａｕｌｔｓディレクトリがある。Ｍａｃｉｎｔｏｓｈには、Ｓｙｓｔｅｍ Ｆｏｌｄｅｒがあり、他のオペレーティングシステムには、対応する要素がある。ほとんどのＵＮＩＸ（登録商標）システム上で、図２に示されているように、各個々のアプリケーション５２、５４は、ほとんどの場合、それ自体の構成６２、６４をローカルに格納する。

本発明の一実施形態は、完全な機能レジストリをアプリケーションに提供し、しかし基礎を成すシステムレジストリへの変更を防ぐ仮想Ｗｉｎｄｏｗｓ（登録商標）レジストリ構成要素を含む。アプリケーションがアクセスすると予想するキーはすべて存在するが、仮想レジストリに存在するだけであり得る。このようにして、本発明のオペレーティングシステムガード１００およびＷｉｎｄｏｗｓ（登録商標）レジストリは、レジストリにアクセスするための２段階プロセスを形成する。アプリケーションは、キーへのアクセスを必要とする場合、レジストリに対するクエリを行う。オペレーティングシステムガードは、キー、およびキーの値を知っている場合はその値で応答する。そうでない場合、オペレーティングシステムガードは、要求がＷｉｎｄｏｗｓ（登録商標）レジストリに渡ることを許可する。その値を変更する試行が行われる場合、オペレーティングシステムガードによって、それ自体のみに変更を行うことができる。次回、アプリケーションがキーにアクセスするとき、それはオペレーティングシステムガードに存在し、要求は、本当のレジストリには流れず、それをもとのままにしておく。

オペレーティングシステムガードが使用するキーは、３つの別々のセクションにおいて指定される。これらのオペレーティングシステムガードキーは、既存のキーを変更したり、キーの存在を削除したり、レジストリに新しいキーを追加したりするために、これらのセクションにおいてコマンドとして指定される。このように、仮想レジストリは、システムが意図する通り正確に生じ得る。キーの有無は、キーの実際の値と同じぐらい重要であるため、これは重要である。

一実施形態において、オペレーティングシステムガードは、まず、アプリケーションの基本的なレジストリエントリを含むデータファイルをロードする。次いで、ユーザの選好を含む第２のデータファイルがロードされる。最後に、オペレーティングシステムガードは、任意選択で、ユーザがオーバーライドすることができないポリシー項目を含む１組のキーをロードすることができる。３つのファイルは、互いの上にロードされ、各ファイル内の複製項目がその前のファイル内の項目をオーバーライドする。ユーザ固有の情報は存在せず、アプリケーションがデフォルトのみ存在するため、ユーザが最初にアプリケーションを実行するとき、第２のデータファイルは存在しない。だが、各セッションの後、オペレーティングシステムガードは、将来のセッションで使用するためにその第２のデータファイルを生成して、ユーザの変更を保存する。

構成ファイルは、２つの方法で変更することができる。まず、ファイルは、アプリケーションによって直接編集することができる。このシナリオでは、以下で説明されるオペレーティングシステムガードファイルサブシステムは、ファイルに加えられる変更を扱う。第２に、好ましい実施形態では、アプリケーションは、これらのファイルを変更するために、ＧｅｔＰｒｏｆｉｌｅＳｔｒｉｎｇ、ＷｒｉｔｅＰｒｏｆｉｌｅＳｔｒｉｎｇなど、Ｗｉｎｄｏｗｓ（登録商標） ＡＰＩファミリの呼び出しを呼び出すことができる。この場合、本発明の一実施形態のオペレーティングシステムガードは、まさに上述したように、これらの呼び出しをインターセプトし、内部からそれらの要求に応える。

共有オブジェクト
オペレーティングシステムおよび稼働中のアプリケーションによって使用される多くの構成要素は、いくつかのアプリケーションまたはインスタンスにわたって共有される。一般に、これは、非常に良い考えである。これは、同じファイルの多くのコピーを必要とせず、ディスクスペースを節約する。また、オペレーティングシステムおよびサードパーティが一般的に使用されるコードのライブラリを作成し、分配する機能も提供する。Ｗｉｎｄｏｗｓ（登録商標）プラットフォームでは、ダイナミックリンクライブラリ、すなわちＤＬＬは、アプリケーション内およびアプリケーションにわたって共有されることが多い。他のプラットフォーム上でも、問題は同じである。Ｍａｃｉｎｔｏｓｈでは、ＩＮＩＴおよび他のシステム構成要素は、アプリケーション用にロードされる。これらの構成要素は、多くのバージョンを有する可能性があり、一度にそのうちの１つのみが使用される。ＵＮＩＸ（登録商標）システムでは、動的共有オブジェクト、例えば、「．ｓｏ」ライブラリファイルは、ロード時間を速めたり、ディスクスペースを節約したりするために、また他の理由のためにアプリケーションによって使用される。多くのプログラムは、デフォルトの「ｌｉｂｃ．ｓｏ」を使用する。しかし、このライブラリファイルは、通常、ｌｉｂｃ．ｓｏ．３など、それ自体の何らかのバージョンへのシンボリックリンクである。実際には、この機能は、大きな被害をもたらした。これらの共有構成要素は、頻繁に改正を受けており、同じ構成要素の多くのバージョンがインストールできるようになっている。アプリケーションの作成者は、そのソフトウェアが、潜在的に共有構成要素の１つまたはいくつかのバージョンのみとしか協働しないことを知っている。したがって、実際には、アプリケーションは、通常、他の現在のバージョンを上書きして、作成者が望むバージョンをインストールする。これは、潜在的に、システム上で稼働する他のアプリケーションにおける障害を引き起こす。

Ｗｉｎｄｏｗｓ（登録商標）９８、Ｗｉｎｄｏｗｓ（登録商標）２０００では、Ｍｉｃｒｏｓｏｆｔは、システム管理者がアプリケーションのベースディレクトリにＸＸＸＸ．ＬＯＣＡＬと呼ばれるファイルを作成できるように、Ｗｉｎｄｏｗｓ（登録商標） Ｐｒｏｔｅｃｔｅｄ Ｆｉｌｅ Ｓｙｓｔｅｍ（ＷＰＦＳ）を作成した。この場合、ＸＸＸＸは、拡張子なしの実行ファイル名である。これによって、Ｗｉｎｄｏｗｓ（登録商標）ローダは、ＬｏａｄＬｉｂｒａｒｙ実行中にパス参照を解決するその方法を変更する。しかし、これは、問題を完全に解決するには十分ではない。まず、ＸＸＸＸファイルの設定は、システム管理者の知識に任せられるが、これはばらつきが大きい。第２に、ある構成要素バージョンは、元に戻され、次いで、この構成要素をローカルディレクトリにインストールし、「．ＬＯＣＡＬ」ファイルを作成する必要がある。これは、ＷＩＮＤＯＷＳ（登録商標）＼ＳＹＳＴＥＭにある最も基本的な構成要素でもなければ、どの構成要素にとっても簡単なプロセスではない。また、この解決策は、必要な機能のすべてをカバーするわけではない。ＬｏａｄＬｉｂｒａｒｙ中、Ｗｉｎｄｏｗｓ（登録商標）は、明示的または暗黙的なＬｏａｄＬｉｂｒａｒｙの結果、構成要素が解決されたかどうかに応じて、またそれが名前付きの、またはよく知られているＤＬＬであることを示すレジストリキーが存在するかどうかに応じて、異なるパス解決セマンティクス（ｐａｔｈ ｒｅｓｏｌｕｔｉｏｎ ｓｅｍａｎｔｉｃｓ）を使用する。この場合、ＬｏａｄＬｉｂｒａｒｙの呼び出しは、常にＷＩＮＤＯＷＳ（登録商標）＼ＳＹＳＴＥＭディレクトリに解決する。

また、ＤＬＬおよび他の共有構成要素も、参照カウントセマンティクス（ｒｅｆｅｒｅｎｃｅ ｃｏｕｎｔ ｓｅｍａｎｔｉｃｓ）を保持して、稼働中のアプリケーションが構成要素を参照していない場合を除いて、構成要素が確実にもとのままであるようにする。実際には、オペレーティングシステムベンダーのアプリケーションおよびオペレーティングシステム自体のみが、このプロトコルに適切に従っている。

原則として、共有オブジェクトが常に正しい構成要素に解決することが望ましい。この機能を提供するために、アプリケーションが機能することができる構成要素のバージョンまたはバージョンの範囲を理解することが必要である。次いで、アプリケーションが稼働されるとき、本発明は、構成要素が正しく解決されることを確実にするはずである。本発明において、必要な場合、ＷＰＦＳまたは他のオペレーティングシステム提供機能の使用を自動化することが許容できる。この場合、必要な構成要素を検出し、それらをローカルファイルシステムに入れることが必要である。必要なものがすでにある場合、インストールプログラムが構成要素をインストールしないことが多いので、これは、インストールを監視しているだけより複雑である。

また、名前付きのオブジェクトが正しくロードされることを確実にするための方法を識別することが望ましい。Ｗｉｎｄｏｗｓ（登録商標）プラットフォーム上では、ＭＳＶＣＲＴ．ＤＬＬは、この問題領域内でかなり問題の種である。このオブジェクトの複数のバージョンが維持される場合、上記のレジストリキーは、動的に変更することができ、それによって、ＬｏａｄＬｉｂｒａｒｙ機能が正しい構成要素バージョンを解決できるようになる。正しい構成要素のロードを確実にする別の妥当な方法は、有効な検索パスを使用するためにプロセス環境を動的に編集することである。この検索パスは、システム全体の構成要素前にローカル構成要素が解決されることを確実にする。正しい共有オブジェクトの解決の別の考え得る方法は、シンボリックリンクの使用によるものである。シンボリックリンクは、共有構成要素のために作成することができ、これは、実行時にコンピュータのファイルシステムによって必要な構成要素に解決される。最後に、共有オブジェクトのファイルからの情報についての実際の開く／読み取る／閉じる要求は、本発明によってインターセプトすることができ、ローカルシステム上または本発明のサブシステム内に存在し得るファイルの正しいバージョンについて、動的に応答することができる。

特別な形がいくつか存在する。Ｗｉｎｄｏｗｓ（登録商標）プラットフォーム上で、ＯＬＥ、ＯＤＢＣ、ＭＤＡＣ、および他のベンダー固有の構成要素のいくつかは、いくつかのまたはすべての稼働中のプロセス間にグローバルに共有されるように書き込まれる。ＯＬＥの場合、個別のプロセス間でのデータおよびメモリスペースの共有さえ行う。これらの構成要素の多くのように、ＯＬＥは、それ自体の複数のコピーが一度に稼働するのを防ぐ。ＯＬＥは、特定のバージョンが特定のアプリケーションのためにロードされることを必要とする多くのバグおよび機能も有する。本発明では、アプリケーションは、どのバージョンでも必要とされるＯＬＥをロードすることができ、さらに同じバージョンのＯＬＥを使用する他の構成要素との共有セマンティクスは依然として可能である。

一般に、明確にそういうものとして構成されていない限り、共有オブジェクトは、競合の防止を確実にするために、プライベートにロードされるべきである。構成要素をプライベートにロードできるようにするために使用される方法については何も、オペレーティングシステムガードによってアクティブに管理されているかどうかに関わらず、それをきちんとアンロードしたり、別のソフトウェアアプリケーションのために正しくロードしたりすることを妨げるべきではない。さらに、システムがクラッシュした場合、このクラッシュから、基礎を成すオペレーティングシステムを上書きしたり変更したりしていないクリーンな状態に回復することが必要である。

ファイル
多くのアプリケーションは、アプリケーション内のデータファイルを使用して、構成エントリまたは他のアプリケーションデータを格納する。本発明の実施形態は、本明細書で上述した仮想レジストリに酷似した仮想ファイルシステムを提供する。アプリケーションが開始する前に、本発明の一実施形態は、仮想環境から隠すべきファイルやそこに追加すべきファイル、または仮想環境内の別のものに転送すべきファイルを含めて、ファイルシステムの変更のリストをロードすることができる。アプリケーションが任意のファイルにアクセスしたり、それらを変更したりするときはいつでも、オペレーティングシステムガードは、ファイルを転送すべきであるかどうかをチェックし、そうである場合、好ましい実施形態において、オペレーティングシステムガード構成で指定された場所に要求を転送する。

ユーザのローカルドライブ上に書き込むために、アプリケーションが新しいファイルを作成しようとしたり、既存のファイルを開こうとしたりする場合、オペレーティングシステムガードは、実際にファイルが転送された場所において作成されたり、変更されたりすることを確実にする必要がある。アプリケーションが後で再ロードされる場合、このファイルマッピングは、オペレーティングシステムガード仮想環境に再ロードされなければならない。要求が、ユーザのローカルドライブにある既存のファイルを変更することであるとき、オペレーティングシステムガードは、要求を続ける前に当該のファイルを転送ポイントにコピーする必要がある。転送されるファイルは、ファイルパスの安全なマッピングを確実にするために、元のファイルと同じ名前のものでない場合がある。一実施形態において、ＩＮＩファイルは、このように処理されて、最大のアプリケーション互換性を可能にしながら、最大のシステムセキュリティを提供する。

本発明の一実施形態は、ネットワークを介して配信されるアプリケーションに特に有用である。こうした実装形態では、ソフトウェアアプリケーションがいくつかの種類のデータから成ることを理解することが重要であり、この場合、ソフトウェアアプリケーションが使用する大量のファイルは、最も好ましくは、別々の論理ドライブ上にマウントされる。ファイルベースおよびレジストリベースを含む構成は、ユーザ固有のものおよびシステム全体のものとすることができる。使用されるアプリケーション配信システムは、任意のファイルがこれらのタイプのどれであるかについて各ファイルをマークする必要がある。この情報は、オペレーティングシステムガードシステムに適切に処理させるためのヒントを提供する。

デバイスドライバ
多くのアプリケーションは、デバイスドライバまたは他のオペレーティングシステムレベルのソフトウェアを使用して、ハードウェアサポートやオペレーティングシステムとの低レベルの直接の対話など、その機能の一部を実施する。本発明の一実施形態では、オペレーティングシステムガードは、これらの構成要素を動的に、かつできる限りプライベートにアプリケーションの仮想環境に追加したり、そこから削除したりする機能を提供する。

多くのデバイスドライバは、動的にロード可能になるように構築される。可能な場合、すべてのデバイスドライバを動的にロードするのが好ましい実施形態である。デバイスドライバがブート時に静的ロードを必要とする場合、アプリケーションの実行前に、ユーザにこの知識が提供されなければならない。システムがリブートされると、アプリケーションは、それが中止されたところから続行するはずである。しかし、かなりの割合のデバイスドライバは、動的にアンロード可能ではない。ドライバを動的にアンロードすることが好ましいが、これが達成できない場合、ドライバは、次のリブート時に削除するようにマークされ、ユーザにこれを気付かせる必要がある。アプリケーションが次のリブート前に２回目に実行される場合、システムは、ドライバの存在に引き続き気付いて、第２のインストールを試行せず、次のリブートで削除可能な構成要素を再マークするために、終了を待つ必要がある。

本発明の実施形態が適切に機能できることを確実にするために、基本の類似性および違いは、デバイスドライバクラスごとに存在するため、それらを特徴付けることが重要である。常に存在しているシステムハードウェアのデバイスドライバをロードしたり、アンロードしたりすることは望ましくない。これは、プログラミングの容易さに関して、好ましい実施形態ではないが、本発明の範囲内に含まれており、本発明の実施形態を使用して配信され、稼働されるアプリケーションのライセンス契約での制限など、特定の理由のために必要とされ得ることを理解されたい。

Ｍｉｃｒｏｓｏｆｔプラットフォーム以外では、デバイスドライバは、通常、極めて異なるように扱われる。Ｍａｃｉｎｔｏｓｈシステムは、静的および動的ドライバをサポートするが、すべて同じ方法を介してインストールされ、削除される。Ｍａｃｉｎｔｏｓｈシステムフォルダとリンクすることによって、必要なサポートが提供される。ＵＮＩＸ（登録商標）システムでは、デバイスドライバは、たいていの場合、稼働中のＵＮＩＸ（登録商標）カーネルが変更され、続いてリブートが行われることを必要とする。このプロセスは、非常に複雑である可能性がある。一実施形態において、アプリケーションが完了した後、カーネルを再設定することを含めて、このプロセスは、自動化される。プロセスの一般のパラメータは、Ｗｉｎｄｏｗｓ（登録商標）アプリケーションについて上述したものと同じであり、コンパイルの実際のプロセスステップ、およびこうしたオペレーティングシステムに精通している人は、リブートを行うことができる。

最終的に、システムの障害にわたってドライブを回復し、削除することができることが望ましいことを当業者は理解されよう。したがって、システムの保全性を保持するのに必要などんなデータやプロセスも、本発明の一実施形態に含まれる。当業者は、とりわけ、永続ハードウェア付属装置に関連付けられているものなど、すべてのタイプのデバイスドライバが本発明の実施形態を介して便利にまたは効率的に提供されない可能性があることも理解されよう。

他の項目
本発明の実施形態では、その挙動または存在が代替のオペレーティングシステム上で異なる、いくつかの構成要素があると理解される。これらの構成要素は、フォント、プロセス、環境変数他を含む。

一部のアプリケーションは、正しく実行するために、フォントがインストールされる必要がある。必要な任意のフォントは、オペレーティングシステムガードの構成ファイルで指定される。オペレーティングシステムガードは、アプリケーションを実行する前にこれらのフォントを有効にし、必要な場合、それらをその後削除する。ほとんどのシステムは、それらを登録したり、システムにその存在を気付かせるためのプロセスに加えて、フォントを格納するための共通領域を有しており、オペレーティングシステムガードは、これらの使用可能な方法を使用する。

Ｗｉｎｄｏｗｓ（登録商標）では、フォントは、＼ＷＩＮＤＯＷＳ（登録商標）＼ＦＯＮＴＳディレクトリにコピーされる。しかし、これは、フォントが稼働中のプログラムから使用可能であることを保証しない。好ましい実施形態では、プログラムがＷｉｎｄｏｗｓ（登録商標） ＡＰＩを使用してフォントにアクセスする場合、フォントは、ＣｒｅａｔｅＳｃａｌａｂｌｅＦｏｎｔＲｅｓｏｕｒｃｅ／ＡｄｄＦｏｎｔＲｅｓｏｕｒｃｅなど、Ｗｉｎ３２ ＡＰＩ呼び出しに登録される必要がある。これは、フォントをシステムフォントテーブルに挿入する。いったん完了すると、オペレーティングシステムガードは、ＲｅｍｏｖｅＦｏｎｔＲｅｓｏｕｒｃｅなど、別の適切なＡＰＩ呼び出しによってフォントを削除し、次いでシステムからファイルを削除することができる。代替実施形態として、オペレーティングシステムガードは、仮想レジストリ方法で記述したようにＡＰＩ関数をフックすることができる。さらに、オペレーティングシステムガードは、そのファイルサブシステムを使用して、実際のフォントファイルを稼働中のシステムに入れるのを避けることができる。

Ｍａｃｉｎｔｏｓｈでは、プロセスは、極めて似ており、Ｍａｃｉｎｔｏｓｈシステムフォルダ内のファイルおよび登録起動に基づく。しかし、ＵＮＩＸ（登録商標）では、プロセスは、アプリケーションに依存する。たいていの場合、フォントリソースは、適切な場所に解決された正規のファイルとしてシステムに追加されるので、名前によってアクセスすることができる。多くのＭｏｔｉｆシステムでは、フォント記述は、フォントリソースファイルに入れる必要があり、これによって、フォントを解決することができる。ＭｏｔｉｆまたはＸアプリケーションは、解決サブシステムを介して、または直接呼び出しによってフォントを呼び出すことができる。最近、多くのＭｏｔｉｆおよびＣＤＥベースのシステムは、Ａｄｏｂｅ拡張可能ポストスクリプトフォントを使用する。これらのフォントは、Ａｄｏｂｅタイプの管理システムを介して管理する必要がある。しかし、例外があり、上述したように、Ｗｉｎｄｏｗｓ（登録商標）や他のオペレーティングシステムのデフォルトフォント管理システムの代替がある。Ａｄｏｂｅ Ｔｙｐｅ Ｍａｎａｇｅｒは、他のサードパーティタイプの管理システムのように、このプロセスの何らかの代替インターフェイスを提供する。ほとんどの場合、インターフェイスをサポートするかそれを無視するかを決定する必要がある。オペレーティングシステムガードの目的は、これらのすべてのシステムに普遍的なレイヤを提供することではなく、単に、オペレーティングシステム自体のサブシステムのためにそのようなことを行うことである。

多くのアプリケーションは、環境変数が設定されることを必要とする。これは、ＵＮＩＸ（登録商標）システムで最も一般的であるが、もともとＵＮＩＸ（登録商標）において書かれ、Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステムに移植されたソフトウェアによってもかなり使用される。Ｗｉｎｄｏｗｓ（登録商標）オペレーティングシステム上のアプリケーションは、ＤＯＳ ＰＡＴＨ環境変数にかなり依存しており、それ自体のアプリケーション固有のエントリを設定することが多い。Ｗｉｎｄｏｗｓ（登録商標） ９ｘ／Ｍｅ環境では、そのコアがＤＯＳサブシステムであるため、適用可能である多くの環境設定がある。アプリケーションが特定の変数または既存の環境変数において設定されるべき値の存在を必要とする場合、必要な環境変数は、オペレーティングシステムガードの構成ファイルにおいて指定される。オペレーティングシステムガードは、起動されると、アプリケーションの主なプロセスにこれらの変数を設定する。アプリケーションは、通常、動作しているとき、環境設定を変更しないため、仮想環境は、これらの呼び出しをトラップせず、レジストリおよび構成サブシステムが行う機能の全装備も提供しない。

回復
前のセクションに示した一部の場合、実際の変更をオペレーティングシステムに加える必要がある。これは、デバイスドライバおよびフォントではよくある。さらに、持続され、アプリケーションが次に実行されるときに使用できる必要がある変更を仮想環境に加えることができる。できるだけ早い機会に、システムから変更を削除して、オペレーティングシステムガードシステムがシステムへの変更から回復することができることを必要とする。あるいは、アプリケーションの実行中にシステムがクラッシュした場合、オペレーティングシステムガードは、システムがリブートされる、またはその他の場合、システムへのすべての変更を削除するのに十分な情報を追跡し、仮想環境に加えられた変更を追跡する必要がある。好ましい実施形態では、これは、トランザクションログとして実装されるが、他の実施形態では、他の何らかの類似の構成要素として実装することができ、これは、変更を取り消すことができるように、システム機能時に読み取ることができる。

仮想化の制御
本発明の重要な態様は、オペレーティングシステムガードが可能な仮想化の、多くの面の制御に関する。好ましい実施形態では、制御すべきソフトウェアシステムの正しい側面を確認することができる計装プログラム（ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ ｐｒｏｇｒａｍ）が存在する。また、管理者およびエンドユーザが、こうした項目を表示し、システムによって仮想化されるように変更できるようにする方法も含まれる。

自動化プログラムでは、制御の側面をきちんと読み取るために、制御すべきアプリケーションが観察される。自動化プログラムは、アプリケーションのインストールプロセス中、アプリケーションの実行中、またはそれらの組み合わせ中にこのタスクを実行することができる。好ましい実施形態では、オペレーティングシステムガードは、ラッパアプリケーション（ｗｒａｐｐｅｒ ａｐｐｌｉｃａｔｉｏｎ）に組み込まれている。インストール後、１つまたは多くのソフトウェアの使用後、ラッパアプリケーションは、その全アクションの詳細なリストについて、オペレーティングシステムガードに対してクエリを行う。アクションのこのリストから、ラッパアプリケーションは、その後の使用時に、オペレーティングシステムガードをロードし、動作させるために必要な構成ファイルを作成する。

インストールプロセスの一部として使用される場合、オペレーティングシステムガードは、一実施形態では、インストールをその環境のみに入れることができる仮想レイヤとして働く。インストール後、ファイル、設定などのすべては、後でリロードするためにダンプすることができる。このように、インストールは、元のシステムをそのままにしておき、必要な構成ファイルを自動的に作成してしまう。アプリケーションの使用中に使用されるとき、オペレーティングシステムガードは、他と異なる環境への変更を記録したり、構成ファイルを分類し直したりすることができる。

オペレーティングシステムガードは、後処理のために、その情報をラッパアプリケーションに渡す。好ましい実施形態では、システムが作成できる自動エントリに加えて、ラッパアプリケーションは、オペレーティングシステム固有の、およびアプリケーションまたはドメイン固有の知識によりプログラミングされる。この知識は、構成項目または他のエントリの既知の使用を反映するようにプロセスの出力を変更するために使用される。好ましい実施形態では、コード化への変更をもたらすために、ルールベースのシステムを使用して、観察された挙動を既知のシナリオと比較する。

また、ラッパアプリケーションは、プロセスの構成出力のためのビューワおよび／またはエディタとして使用される。このエディタは、好ましい実施形態では、システム管理者が、項目または項目群を構成に追加したり、編集したり、構成から削除したりできるようにする。エディタを介して構成を観察する際、管理者は、構成の複製を作成して、必要に応じて特定の項目を変更して、アプリケーションレベルの、またはユーザカスタムの変更をもたらすようにすることもできる。

次に図１を参照すると、本発明の一実施形態が機能的に示されている。この実施形態では、２組のアプリケーション／ユーザデータ６０が示されている。オペレーティングシステムガード１００は、アプリケーション５０の２つのインスタンスが互いに干渉しないようにする。さらに、上述したように、オペレーティングシステムガード１００は、抽象化レイヤとして働き、したがって、アプリケーションソフトウェア５０と、クライアントコンピュータの実際のオペレーティングシステム１０との間でコマンドおよび通信を収集する。矢印によって図示されているように、オペレーティングシステムガードとソフトウェアアプリケーションとの間にいくつかのコマンドがあり、これは、これらのコマンドが代わりにオペレーティングシステム自体によって作用される通常のインストールとは異なり、結果的に、必ずしもオペレータが意図したものではない可能性があるクライアントコンピュータへの変更がもたらされる。一方、他のコマンドは、オペレーティングシステムガードを通過し、次いで、オペレーティングシステム自体に転送される。

多くのソフトウェアアプリケーションは、１つまたは複数の追加アプリケーションとともに動作するように設計されている。これは、１組のアプリケーションは、パッケージ化され、単一のユニットとして販売され、しばしば一緒に働くように作成されている、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅなどのソフトウェアの場合がそうである。これは、別のアプリケーションに「プラグイン」するように設計されている、または何らかの方法で通信するように設計されている、多くのソフトウェアアプリケーションによっても証明される。

これは一般的な機能であるが、多くのソフトウェア配布システムは、これらの相互関係が適切に機能できるようにするのが難しい。これは、アプリケーションのパッケージ化中、アプリケーションのエンドユーザ環境への統合中、または実行時の、相互依存の不適切な解決による可能性がある。

現在、Ｐａｃｋａｇｅｄ Ｓｏｆｔｗａｒｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ、Ｅｌｅｃｔｒｏｎｉｃ Ｓｏｆｔｗａｒｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＥＳＤ）、Ｏｎ−Ｄｅｍａｎｄ Ｓｏｆｔｗａｒｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ、およびＭｉｃｒｏｓｏｆｔからのＣｌｉｃｋＯｎｃｅシステムなどいくつかの次世代配布システムを含めて、多くの形のソフトウェア配布が存在する。これらの配布システムのそれぞれは、ソフトウェアがどのように配布されるか、どのようにインストールされ、削除されるか、ソフトウェアがどのようにホストオペレーティング環境および他のアプリケーションと対話するかに関して、いくつかの基本的なパターンを示す。

ソフトウェアの配布
ソフトウェアは、依然としてＣＤ−ＲＯＭやフロッピー（登録商標）ディスクなどの物理媒体で入手可能であるが、電子手段の配布は、ほとんどの形のソフトウェアに普及している。企業用に設計された、Ｍｉｃｒｏｓｏｆｔ、Ｍａｒｉｍｂａ、Ａｌｔｉｒｉｓなど、ベンダーによって提供されるものや、インターネットまたはパブリックアクセスネットワークのために設計されたＤｉｇｉｔａｌ Ｒｉｖｅｒなどからのものなど、多くの形のＥＳＤシステムがある。ＥＳＤシステムは、完全にまたは比較的自動化された何らかのやり方でダウンロードし、インストールすることができるインストールパケットの形でエンドユーザおよび企業にアプリケーションソフトウェアを提供する。このソフトウェアの使用では、競合する従属関係や他の誤構成など、インストール問題をしばしば引き起こしていた。

他のソフトウェアベンダーは、それが使用されるとき、または「要求に応じて」、ソフトウェアの配布のためのシステムを開発してきた。これらのシステムで、アプリケーションパッケージは、必要に応じて、ソフトウェアの使用を必要とするエンドユーザシステムに配布される。次いで、ソフトウェアを、実行中に対象のシステムにインストールしたり、そこから削除したりすることができ、または一部の場合、「仮想でインストールされ」、それによってソフトウェアは、事実上インストールされていないとき、まるでインストールされているかのように、エンドユーザのシステム上で実行される。仮想インストール技術は、まるでインストールされているかのようにアプリケーションが稼働することを確実にするが、アプリケーションをオペレーティング環境および他のアプリケーションから隔離している。

Ｍｉｃｒｏｓｏｆｔ ＣｌｉｃｋＯｎｃｅやＳｕｎのＪａｖａ（登録商標） Ｍａｎａｇｅｍｅｎｔ Ｆｒａｍｅｗｏｒｋなど、いくつかの他の技術が市場に提供されている。これらのシステムの多くでは、ソフトウェアのインストールの問題は、概念上、ソフトウェアのインストールがそのホスト環境を変更することを防ぐことによって、未然に防止される。これは、任意の準拠するソフトウェアに、構成ファイルなど、無害な内部ソースからその構成のすべてを集めることを要求することによって、また任意のシステム全体のレジストリや他のアプリケーション構成エンティティを使用することになく、行われる。また、ソフトウェアは、ホストオペレーティングシステム内の設定を要求したり、そのホストを任意の方法で変更したりすることから制限される。

一般に、変更をまねるが、実際にはそれを行わない仮想インストールを介して、または自己完結型ソフトウェアの作成による環境の変更の制限を介して、ソフトウェアは、そのホスト構成の変更によって対象のオペレーティング環境にインストールされることがわかる。これらのシステムにおいて、ソフトウェアの削除は、それがどのようにインストールされたかに関連する。普通にインストールされた場合、ソフトウェアは、逆の手順またはアンインストールプログラムによって取り消されなければならない。これらのプログラムは、故障し、ホスト環境に損害をもたらすことが多い。仮想インストールシステムでは、ソフトウェアは、決してインストールされず、したがって、削除の必要がない。自己完結型環境の場合、削除は、非侵入にすることもできる簡単なアンインストール手順を確実にすることによって、簡略化される。

統合問題
記述したすべてのシステムおよびソフトウェアの実行のための任意のシステムにおいて、そのホスト環境および／または同じ環境においてインストールされるまたは実行される１つまたは複数の追加のアプリケーションとの１つまたは複数のソフトウェアアプリケーションの可能な対話を特徴付け、容易にする方法に関する問題が存在する。多くのアプリケーションは、一緒に働き、相互通信するように設計されているか、そのホスト環境を変更することによって動作するように設計されている。アプリケーション間の関連付けの他のモードは多数あり、問題はすべてまたはほとんどの既知のモードに広がっているが、本明細書に記載されたものは、単に、対処すべき問題の事例として使用されているだけである。

互いに協働するように設計されているアプリケーションは、通常、いくつかのパターンのうちの１つに従う。まず、多くのアプリケーションは、他のアプリケーションが「プラグイン」するホストである。この例には、サードパーティソフトウェアベンダーが主なアプリケーションへの拡張を作成する機能を提供するＡｄｏｂｅ ＰｈｏｔｏｓｈｏｐやＡｕｔｏｄｅｓｋ ＡｕｔｏＣＡＤがある。このプラグインの存在下で、Ｐｈｏｔｏｓｈｏｐユーザインターフェイスは、プラグインによって提供された新しい機能を含んでおり、エンドユーザにとっては異なるように見える。エンドユーザの目に見える変更に対する要求はない。これは単に、一般的なプラグインの１つの動作モードである。

あるいは、一部のプログラムは、公式に登録されていないプログラムのインターフェイスを活用することによって、またはそうでない場合、元のベンダーはそれを意図していないが、その実行時の挙動を変更することによって、「プラグイン」の見かけをまねることができる。プログラムおよびそのユーザインターフェイスを別のものに組み込むなど、他のソフトウェアプログラムの周りにラッパを提供するプログラムがいくつか存在する。ラッパ内でいくつかの機能が選択されると、ホストは、何らかの仕事を行うように、もう一方のアプリケーションを駆動させることができる。これは、もう一方のソフトウェアアプリケーションをホストするのではなく、単にユーザの要求によってそれを開始させる「ランチャ」プログラムの作成によるなど、疎統合とすることもできる。

いくつかのアプリケーションは、他のアプリケーションを使用して、その仕事の一部を実行する。ＰＤＡアプリケーションなどのソフトウェアは、連絡情報を同期するデータリポジトリとしてＭｉｃｒｏｓｏｆｔ Ｏｕｔｌｏｏｋなどの連絡先マネージャ（ｃｏｎｔａｃｔ ｍａｎａｇｅｒ）を使用する。Ｏｕｔｌｏｏｋは、ＰＤＡアプリケーションの一部として出荷されるのではなく、ソフトウェアは、それと通信して、その同期タスクを行うことができる。多くのプログラムは、Ｍｉｃｒｏｓｏｆｔ Ｗｏｒｄを使用して、メールマージ機能を行う。

また、プログラムは、仕事を行うために、標準の手段、またはメーカー独自の手段を介して互いに通信することもできる。これは、ＣＯＭ／ＤＣＯＭ、ＭＴＳ、ＣＯＲＢＡ、ＳＯＡＰ、または他の手段を介した遠隔手続き呼び出し（ＲＰＣ）などの何かとすることができる。これは、生のＴＣＰ／ＩＰ通信セッション、さらにはＨＴＴＰ要求などの何かとすることができる。ここで当面の主な問題は、相互通信の可用性が、主なアプリケーションが挙動する方法を変更することができることである。一例として、パケットダンパまたは通信トラブルシューティングプログラムは、多くの異なる通信プロトコルを見て、フォーマットすることができることが多い。しかし、ＣＯＲＢＡを使用する環境にない場合、そのプロトコルを構成する必要はない。この構成は、そのホストまたは近くのホストがこのプロトコルを使用するように構成されているかどうかを検出することによって、行うことができる。

プログラムは、データファイルまたは共通データベースの共有を介して緩やかに相互運用することもできる。これは、簡単なファイル共有またはＯＬＥやＯｐｅｎＤｏｃなどの複合文書インターフェイスを介し得る。複合文書の場合、特定の複合文書は、その内部文書構造の様々な部分をホストすることができるソフトウェアアプリケーションの存在および統合に依存する。データベースシステムの場合、結合は、非常に疎であることが多いが、依然として、統合をもたらすために何らかの構成が存在する必要がある。

最後に、多くのプログラムは、異なるように構成された類似のオペレーティングシステムの存在下で異なるように動作したり、特定のホストオペレーティング環境または他のソフトウェアアプリケーションを構成する目的を有したりすることができる。簡単なプログラム例は、ＴｗｅａｋＵＩであり、これは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）デスクトップ環境の構成およびオペレーティングシステムの他の多くの側面を変更するために使用されるプログラムである。

上述した場合のすべてにおいて、ソフトウェアアプリケーションは、それらの世界観が単独であると推定しているか、他のアプリケーションまたはホスト環境の存在下で意図的に異なるように機能する。これは、説明したソフトウェア配布システムの問題を提供し得る。ほとんどの場合、考え得る関連付けのすべてが、配布時またはインストール時に知られているわけではない。したがって、配布システムは、変更に適合する手段を提供する必要がある。

いったんアプリケーションが配布用に構成されると、環境が変わった場合、アプリケーションをしばしば再構成しなければならない。さらに、構成中、そのすべての関連付けを知っておかなければならず、そうでなければ、適切に構成されないかもしれない。仮想インストール環境の場合、デフォルトの挙動は、意図的に任意のプログラム接続を分離することである。したがって、この制限を克服する手段が提供されなければならない。または、自己完結型環境の場合、コンテナパラダイムを侵害しない、関連付けの妥当な手段を見つける必要がある。

可視性／発見可能性（ＤＩＳＣＯＶＥＲＡＢＩＬＩＴＹ）
２つのアプリケーションが相互運用するには、ある時点で互いに可視でなければならない。これは、インストール時または実行時の発見の手段を介するもの、またはこうした時にもう一方から見える一方のプログラムの何らかの明示またはインターフェイスによるものとすることができる。

プログラムは、互いを見つけるために非決定的手段や公式に登録されていない手段を使用することが多いため、可視性の問題は、かなり複雑であり得る。例えば、統合すべきアプリケーションの存在を探すことによって、存在を決定することができる。これは、その実行可能な構成要素のうちの１つまたは複数を検索する、Ｗｉｎｄｏｗｓ（登録商標）レジストリなどの共通レジストリ内でその構成を検索する、ＵＮＩＸ（登録商標）の／ｖａｒ／ｏｐｔや／ｅｔｃのファイルシステムの場所における実行ショートカットやその構成など何らかの共通場所内でアプリケーションの形跡を検索する、共通場所にあるそのインターフェイスのうちの１つまたは複数を検索する、その存在についてそのホストオペレーティング環境に対してクエリを行う、または多くの代替の手法のうちの１つによって行うことができる。

仮想インストール技術などのシステムでは、検索のこれらの手段を介した発見は、プログラムが当該のホスト上で実行されるように構成されている場合でも、機能しない可能性がある。仮想インストール技術では、ホスト環境上にプログラムの形跡がない。アプリケーションをホストに配信するように構成されているサーバに、その可用性の知識のみが存在する。また、一部の仮想インストールシステムは、デスクトップシステムのようなものにホスト統合を提供し、したがって、アプリケーションがこのようにその発見を行うように構成されていない場合でも、この１つの形の発見のみを実行可能にする。仮想でインストールされたソフトウェア構成要素は、デフォルトでは、実際のソフトウェア自体以外のものからは決して見えない。したがって、発見が行われるには、容易にするために代替手段を提供する必要がある。

自己完結型環境の場合、ホスト環境内のソフトウェア構成要素の実際の明示は、かなり変わり得る。Ｍｉｃｒｏｓｏｆｔ ＣｌｉｃｋＯｎｃｅ技術は、例えば、システムの残りから隠されている、またはその存在の過程にわたって変わり得るホスト環境内のある場所に、ソフトウェアアプリケーションの実行可能な構成要素を配置することができる。

発見は、ソフトウェアの中央または分散レジストリを介して行うこともできる。ＵＤＤＩまたはＪＮＤＩなどのシステムは、インターフェイスレイヤでのソフトウェアアプリケーションの発見の手段を提供する。ＵＤＤＩ内のレコードの存在は、予め定義されたまたは動的なエンドポイントでのソフトウェアの可用性を含意する。仮想インストール技術では、このエンドポイントが仮想インストール環境内のみに存在することが多いので、環境内のＵＤＤＩクエリはアプリケーションの存在を解決するが、環境外では解決しない。あるいは、ＵＤＤＩやＪＮＤＩクエリは、単に仮想アプリケーションのプロキシである動的なエンドポイントに解決する。

発見の問題は、インストール時およびインストール後に変更によってさらに複雑になる。あるアプリケーションは別のものと統合できるマシンにインストールされているが、第２のアプリケーションがインストールされていない場合、それ自体を相互運用するように構成できない場合がある。第２のアプリケーションが引き続いてインストールされる場合、相互運用を構成する論理は、第１のソフトウェアアプリケーションのインストール時に行われるだけであることがしばしばである。したがって、統合を提供するために、第１のアプリケーションを再インストールする必要がある。

さらに、アプリケーションが第２のアプリケーションと統合するように構成されており、その第２のアプリケーションが削除される場合、第１のアプリケーションは、削除プロセスの再構成または処理を行うことができなければならない。実際にみると、そうでないことが多い。第２のアプリケーションの削除によって、第１のプログラムが故障するか、そうでない場合、不完全にふるまう可能性がある。

また、アプリケーションの存在は、実行時に決定され、アプリケーションへの挙動の変更をもたらすこともあり得る。ソフトウェアアプリケーションは、別のプログラムを、既知のインターフェイスでそれに話しかけようとすることによって、ホスト上で稼働しているそのプロセスを探すことによって、そのアプリケーションウィンドウの１つまたは複数を見つけることによって、またはＭＴＳ、ＣＯＲＢＡ、ＤＣＯＭなど、ブローカサービスを使用することによって検出することができる。

相互通信
アプリケーションは、いったん相互運用するように構成されても、相互接続する手段を依然として有していなければならない。通常の単一ユーザ実行環境では、実行を失敗させるホスト構成において何かが変わっていない限り、これは、ほとんど問題ではない。しかし、仮想インストール環境、マルチシステム環境、またはマルチユーザシステムにおいて、相互接続は、追加の構成なしに適切に動くことができない。

オペレーティングシステムガードの通常の動作モードでは、既存の何らかのエンドポイントとの競合の可能性を取り除くために、デフォルトの通信エンドポイントが再対象化される。したがって、１つのアプリケーションが別のものと通信しようと試行するとき、両方のアプリケーションが存在し、互いについて知っているように構成されている場合でさえ、通信が失敗する。これは、各通信エンドポイントが異なるように再対象化されることのシステムによる保証の結果である。したがって、オペレーティングシステムガードは、通信セッションが適切に接続し、動作することを確実にするために、再対象化するプロセスを調整するために、システムを提供しなければならない。

マルチユーザ環境でも、問題は同様である。プログラムが同じホスト上の複数のユーザによって使用される予定である場合、通信エンドポイントは、ユーザごとに可変であり、ユーザごとに同じように再対象化されなければならない。Ｍｉｃｒｏｓｏｆｔ Ｔｅｒｍｉｎａｌ ＳｅｒｖｉｃｅｓまたはＣｉｔｒｉｘ ＭｅｔａＦｒａｍｅでは、セマフォおよび相互排除などの通信エンドポイントは、端末セッション内で一意であるようにすでに書き換えられるが、単一のセッションでの同じプログラムの複数のインスタンスは、依然としてこの問題を顕著に示す可能性がある。さらに、ソケット、ＣＯＭ、名前付きパイプなどの標準通信は、一貫してマシンにグローバルであり、どんな方法でも変わらず、したがって、問題がもたらされる。

オペレーティングシステムの統合
現代のソフトウェアのほとんどは、何らかの方法でそのホストオペレーティング環境と統合するように設計されている。デスクトップクラスソフトウェアは、一般に、プログラムショートカットまたはソフトウェア製品にアクセスするための他の簡単な手段を提供する。これらのショートカットによって、オペレーティングシステムは、製品を稼働させるためのユーザインターフェイスを表示することができる。ほとんどの場合、サーバクラスソフトウェアは、管理および簡単な起動／停止構成のインターフェイスを提供する。

すべての場合、ホストオペレーティングシステムは、インストールされたソフトウェアにアクセスするための何らかの手段を提供する。ほとんどの場合、Ｗｉｎｄｏｗｓ（登録商標） Ｓｈｅｌｌや、ＵＮＩＸ（登録商標） ＣＤＥ、ＫＤＥなどのデスクトップシェルは、ソフトウェアの共通のルックアンドフィールおよび統合ポイントを提供するために使用される。これらのタッチポイントと統合するために、正しい手段でそのソフトウェアをインストールすることは、ソフトウェアベンダーの責任である。これらのインターフェイスの中には、ショートカットのようなものの場合、簡単なものもあり、ユーザによるマウスの右クリックのときに使用されるコンテキストメニューなど、より複雑なものもある。

また、共通のコマンドまたはユーザインターフェイスをソフトウェアおよびハードウェアを管理するために使用できるようにする管理インターフェイスもある。Ｍｉｃｒｏｓｏｆｔ Ｍａｎａｇｅｍｅｎｔ Ｃｏｎｓｏｌｅ、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｉｎｓｔａｌｌｅｒ、Ｌｉｎｕｘ ｒｐｍデータベースなどの物は、オペレーティングシステム内の管理情報を見つけるための共通の場所を提供する。

また、追加したり削除したり、仮想的にインストールしたり、そうでなければ要求に応じて提供されたりすることができるソフトウェアがある状態で、これらのインターフェイスは、動的であるか、動的に管理できなければならない。オペレーティングシステムの操作挙動は、そのアクティブなアプリケーションの性質を反映するようにされる。

バージョン管理
統合および相互運用の問題は、ソフトウェアプログラムまたはそのインターフェイスの複数のバージョンの存在によってさらに悪化する。２つのプログラムが通信でき、プログラムのうちの１つが複数のバージョンを有している場合、プログラムのどのバージョンを使用すべきであるかを知るための手段がなければならない。一般に、プログラムの１つのバージョンのみが、呼び出しプログラムと共に正しく動作する。このようなやり方で、２つのプログラム間に従属関係が存在することが知られている。しかし、両方のバージョンのプログラムが正しく動作する場合、従属関係は、バージョンの独立性を示すような方法で、明確に表現されなければならない。

Ｍｉｃｒｏｓｏｆｔ ＣＯＭアーキテクチャなど多くのシステムは、プログラムが相互通信するためのバージョン管理されたインターフェイスを提供する。このシステムで、プログラムインターフェイスに、グローバル一意識別子、すなわちＧＵＩＤ、およびそれ自体を識別するために使用する１つまたは複数の名前が与えられる。さらに、プログラムに、バージョンに依存しない識別子を与えることができる。この識別子は、プログラムが、プログラムのバージョンに関わらず、それと通信することができることを含意する。

実際に、これらのタイプの識別子は、実際にバージョンの従属関係が存在するとき、誤って使用されることが多い。初心者のプログラマのほとんどは、バージョンに依存しない識別子を使用すれば、常に識別子は探しているものに解決すると考えている。このことから、従属ソフトウェアの最新バージョンと常に正しく機能する必要性は、構築されたプログラムにある。従属ソフトウェアが変更され、バージョンに依存しないインターフェイスが存在するにも関わらず、もはや互換性がない場合、問題が起こる。これらの誤りを解決することは、ソフトウェア配布システムに任されるが、解決できないことが多い。

あるいは、多くのプログラムは、バージョンに依存するまたは依存しないインターフェイスを有していないが、それにも関わらず、テストまたは一般的な方法を介してのみ理解されるバージョンの従属関係を有する。別のユーザインターフェイスを駆動させるプログラムは、そのＷｉｎｄｏｗ制御は固有の物理位置にあるか、特定のクラス名を有すると予想することが多い。同じプログラムの別のバージョンは、これらの予想に従わないかもしれない。この場合、駆動中のプログラムは、第１のバージョンのソフトウェアを正しく使用することができるだけである。

この問題の逆も存在する。別のプログラムを駆動させる、またはそれと通信する必要があり、Ｗｉｎｄｏｗクラス名など、特定のエンドポイントを使用することによってのみそうするようにできるプログラムがある場合、駆動されるソフトウェアの別々の２つのバージョンが、実際に同じエンドポイントを使用する可能性がある。この場合、駆動中のプログラムが、所望のエンドポイントで、ソフトウェアの正しいバージョンと通信することができ、しかし依然として、同じエンドポイントを使用してソフトウェアのもう一方のバージョンの操作を容易にすることができる必要がある。

命名
上述したような問題の重要な部分は、名前を理解するという基本的な問題である。名前は、多くの形があり、様々な状況または「コンテキスト」で非常に異なる多くの物であり得る。

コンピュータシステムでは、ほとんど何でも名前付きのオブジェクトとすることができる。ファイルは、「Ｃ：＼Ｗｉｎｄｏｗｓ（登録商標）＼ｎｏｔｅｐａｄ．ｅｘｅ」という名前を有する。レジストリキーは、
「ＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ｍｉｃｒｏｓｏｆｔ＼Ｗｉｎｄｏｗｓ（登録商標）＼ＣｕｒｒｅｎｔＶｅｒｓｉｏｎ＼Ｒｕｎ」である。名前付きパイプは、＼＼ＰＩＰＥ＼ＥｘａｍｐｌｅＰｉｐｅである。フォントは、「Ｔａｈｏｍａ Ｂｏｌｄ」である。ＨＴＴＰ通信のＴＣＰポートは、８０である。データベース内のテーブルの名前は、ＵＳＥＲＳである。グローバル一意識別子、すなわちＧＵＩＤでさえ、基本的に、何らかのオブジェクトの名前である。実用上、他の多くのオブジェクトは、それらの名前を有意にするような方法で命名される。ニュース記事のタイトル、ニュース記事の筆者、またはその出版社である。

オブジェクトに名前が付けられると、そのオブジェクトを見つけるために、提供された名前を使用するという暗黙の了解がある。２つのオブジェクトが同じ名前を有する場合、当該の適切なオブジェクトを解決する何らかのプロセスが提供されなければならない。別々のアプリケーションが共通のオブジェクトの使用を試行する場合、通常、アプリケーションは、その単一のオブジェクトを解決する。しかし、１つのアプリケーションがそのオブジェクトを変更する場合、その変更されたオブジェクトをもはや第２のアプリケーションに使用させないようにすることが望ましいことが多い。したがって、各アプリケーションは、同じ名前を使用する異なるオブジェクトを解決するための方法、および変化するオブジェクトを追跡する方法を有する必要がある。

さらに、名前付きのオブジェクトが存在し、その同じオブジェクトが仮想的にインストールされたアプリケーション内に存在する場合、仮想アプリケーションは、その内部オブジェクトを解決することによって動作するが、仮想環境外のプログラムでは、仮想オブジェクトを見つける必要が依然として残る。

したがって、アプリケーションおよびオブジェクトが可変の寿命、それらの寿命にわたる異なる意味、および潜在的な衝突を有する可能性があるネットワークでは、これらのオブジェクトの対話を管理するために、統一ソリューションが必要である。ＪＮＤＩまたはＵＤＤＩなどの現在の技術分野のシステムは、これらの特徴を反映しない絶対情報を提供するために、情報のシステム全体のレジストリに依存する。ＪＮＤＩクエリは、接合点を作成することによって異なる名前空間を一体化することができる。しかし、システムのユーザは、単にそうしないことによって命名の衝突を処理することが要求される。実際には、これは、その仕事を行うために、多くのシステムがオブジェクトの共通の、しかし異なる定義を有していなければならないため、非常に難しい。ＪＮＤＩシステムは、名前空間を折りたたんだり、マージしたりする手段や、バージョン管理または競合管理の制御の手段を提供しない。

コンテキスト
上記で提供された問題は、当面のシナリオの文脈で、適切な構成、名前付きオブジェクト、またはインターフェイスを提供する機能の存在下で解決される。本明細書に記載した実施形態は、ａ）ソフトウェアプログラムの相互依存性を自動的に理解し、ｂ）プログラムがそのホストオペレーティング環境の類似のビューを共有し、かつ／または変更することができる操作コンテキストを作成し、ｃ）これらのコンテキストの使用可能化またはプロパティを制御し、ｄ）そうでなければ故障するこれらのプログラムの相互接続および相互運用性を容易にするシステムを示す。

実施形態は、ホストオペレーティング環境において１つまたは複数のプログラムを作動させ、制御されたやり方で複数のシステムの挙動を連結する方法を提供する。図５に示したシステム例１５０において、１つまたは複数のコンピューティング装置が存在し得る。これらの装置は、オペレーティングシステムおよび１つまたは複数のアプリケーションが実行される、単一のユーザ１５５またはマルチユーザ１５６装置とすることができる。また、サーバシステム状のデータベースサーバ、ファイルサーバ、または他の事業区分別アプリケーションサーバなどのインフラストラクチャサービス１５８、またネットワークおよびシステムを管理する一部のインフラストラクチャ１５７も存在し得る。

ソフトウェアアプリケーションは、装置のネットワーク内で実行されるとき、したがって、いくつかのレベルの他のソフトウェアと対話できる機能を有する。好ましい実施形態において、基本レベルは、グローバル、管理、ローカルシステム、システム仮想、ベンダー、ユーザ、セッション、共有、および隔離を含む。これらのレベルは、図６および図７に示されている。これらの分類は、コンテキストと呼ばれ、環境間対話のポリシーベースの制御を可能にするためにその中で拡大された、アプリケーションが実行するランタイム環境に対応する。当業者であれば、他のコンテキストを簡単に作成することができ、本明細書で定義されたものは、本発明の用途の例であるものとすることを理解されよう。

Ｇｌｏｂａｌコンテキスト２０１は、図５に示されている一実施形態におけるシステム全体のビューである。グローバルコンテキスト内に存在するオブジェクトまたは名前は、セキュリティポリシーによって許可されるように、すべてのユーザおよびすべてのソフトウェアプログラムによって閲覧し、共有することができる。代替実施形態において、グローバルコンテキストは、会社のすべてのマシンをカバーする企業コンテキスト２０４、会社間の共有の計算のための連合コンテキスト（Ｆｅｄｅｒａｔｅｄ ｃｏｎｔｅｘｔ）２０６、および参加しているすべてのエンティティをカバーするグローバル２０１または分散コンテキストをカバーするように変更することができる。

管理コンテキスト２０７は、管理のある範囲内の１組のマシン、ユーザ、リソース、および／またはアプリケーションの広範なビューである。この範囲は、ＥＳＤソリューションまたは仮想インストールシステム２１４のうちの一方など、配布システムによって管理される１組のシステムとすることができる。これは、企業範囲にわたって部門内に拡張することができ、または管理システムがＡＳＰなどのサービスプロバイダ２０２によってホストされる予定である場合、このコンテキストを、プロバイダのカスタマシステム２０４、２０５にわたって広げることができる。このコンテキストは、本発明の方法を実施する任意のシステムが他の管理システムおよびそれ自体の他のインスタンスと相互運用することができるように存在する。

ローカルシステムコンテキスト３０２は、特定のマシン３０１または仮想マシン（ＶＭＷａｒｅパーティションなど）内のすべての操作のビューを提供する。これは、Ｍｉｃｒｏｓｏｆｔ Ｔｅｒｍｉｎａｌ Ｓｅｒｖｉｃｅｓの「グローバル」コンテキストに等しい。ＣｉｔｒｉｘおよびＭｉｃｒｏｓｏｆｔの従来技術のシステムは、マシンをグローバルおよびセッション固有の名前空間に再分割することによって、これらのコンテキスト問題の一部を解決しようと試みていた。

システム仮想コンテキスト３１０によって、仮想インストール技術によって配信されるものなどのプログラム、またはオペレーティングシステムガードは、操作およびオブジェクトをローカルオペレーティングシステムと共有して、両方が同じ名前空間内で動作するようにすることができる。特定のシステム仮想コンテキストは、１つまたは複数のアプリケーションをオペレーティングシステムとカプセル化する。すべてのアプリケーションがＯＳと同じように共有する必要はない。

ベンダーコンテキストによって、マシン内に存在するが、そのソフトウェアまたはハードウェアを使用するシステムに関連するすべての操作を含む範囲を、ソフトウェアベンダーは作成することができる。一実施形態における一例は、同じマシン上の他のソフトウェアと共存するシステムによって管理されるソフトウェアである。ベンダーコンテキスト内で、ソフトウェアは、管理されているもの、および管理されていないものに基づいてグループ化される。

ユーザコンテキスト２１１は、操作をユーザによって行われる操作にグループ化する機能を提供する。このコンテキストは、単一のマシン上に存在するように制限されないことに留意されたい。このコンテキストを、このユーザの代わりに操作を実行している複数のマシンまたはセッションにわたって広げることができる。この挙動によって、ネットワークで複数のセッションを稼働させているユーザは、実行しているアプリケーション間の協調を図ることができる。

セッションコンテキスト２１２は、操作を、１つのマシン上での１人のユーザの操作に制限する。これは、Ｔｅｒｍｉｎａｌ Ｓｅｒｖｉｃｅｓのローカルユーザの名前空間、またはＵＮＩＸ（登録商標） ｔｅｌｎｅｔ／ｔｔｙセッションに相関し、マシンにログインされたユーザは、識別可能な範囲を有することになる。

図７に示されている共有コンテキスト３１２は、管理上定義された一意の共有構成依存範囲を提供する。この範囲によって、２つ以上のプログラムは、構成およびオブジェクトを共有したり、互いに見たりすることができる。このシステムの好ましい実装形態内に、複数の共有コンテキストがある。各コンテキストは、名前、および共有の挙動を定義する１組のポリシーを含む。このように、アプリケーションの複数の異なるセグメントは、重複する挙動を共有することができる。

図７に示されている隔離コンテキスト３１１は、仮想的にインストールされたアプリケーションのデフォルトの挙動である。この範囲内で、アプリケーションは、すべての他のプログラムから完全に隔離され、ある意味で不可視であり、すべての通常のインターフェイスおよび名前付きオブジェクトは、コンテキスト外に存在しない。

これらのコンテキスト例は、本発明の実施形態が設計上明示的に階層的であることがどれほど必要ないかを示している。オペレーティングシステムガードは、オペレーティングシステムと個々のアプリケーションとの間、およびアプリケーション間のレイヤとして動作するが、アプリケーションまたはコンテキストが階層的に層状にされるという制限はない。この効果は、容易に達成することができるが、本発明のシステムは、ネットワークまたはシステムアーキテクチャによって制限されない１からｎ個の環境を連結することができる。これによって、示したように複数のマシンにまたがることができるＵｓｅｒコンテキストなどのコンテキストを検討することができる。

操作上の特徴
一実施形態におけるシステムは、ホストオペレーティングシステムとの、相互の、およびオペレーティングシステム内のプログラムの通常の通信をインターセプトするソフトウェアレイヤとして設計される。代替実施形態において、システムは、このシステムの機能を利用するのを特に可能にされるプログラムへのコンパイルのためのコードライブラリとして実施される。次いで、個々の各アプリケーション要求は、その特定の操作コンテキスト内で評価され得る。システムは、ファイルシステム要求、レジストリ要求、共有オブジェクト、フォント、コードライブラリなど、すべてのタイプの要求を見る。これらの要求は、通常、一律にリソースと呼ばれる構成項目、名前付きオブジェクト、または通信インターフェイスのためのものであるが、これらに限定されない。リソースは、可変の寿命を有しており、その使用の期間を超えて持続される場合も、されない場合もある。

図８に示されているシステムでは、互いのリソースおよびオペレーティングシステムを使用する２つのアプリケーションが示されている。異なる３つのシナリオが示されている。１つのシナリオでは、プログラム、Ａｐｐｌｉｃａｔｉｏｎ Ａ ４０２が、単独でのみ使用するために構成されたリソース、Ｒｅｓｏｕｒｃｅ Ｓｅｔ １ ４０４を使用しようと試みる。別のシナリオでは、Ａｐｐｌｉｃａｔｉｏｎ Ａ ４０２が、別のプログラム用に構成されたリソース、すなわちＡｐｐｌｉｃａｔｉｏｎ Ｂ ４０３用に構成されたＲｅｓｏｕｒｃｅ Ｓｅｔ ３ ４０６を使用しようと試行する。また、最後のシナリオでは、両方のプログラムが、各プログラムによってアクセスされるように構成され得る共有リソース、Ｒｅｓｏｕｒｃｅ Ｓｅｔ ２ ４０５にアクセスしようと試行する。この図は、米国特許第０９／８５９，２０９号明細書「Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｐｒｏｔｅｃｔｉｏｎ ａｎｄ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ」の図に機能的に等しいが、プロセスを明確にするように示されている。

この図は、システムの基本的な前提を示し、それによって、１つまたは複数のリソースは、１つのアプリケーションに専用であるように構成することができ、またはそれらのリソースを共有することができる。共有は、１組の共有ライブラリなど、１つまたは複数のプログラムから使用可能な一塊のリソースとして行うことができる。また、一方のプログラムがそのリソースを別のプログラムと共有できるようにするために実行することもできる。逆に、プライバシは、あるプログラムのリソースが別のプログラムから使用可能ではないことを確実にする。いかなる場合でも、中間レイヤは、共有操作を許可する、または不許可にする、そうでない場合は、操作を代替コンテキストに転送する役割を果たす。

本発明の一実施形態では、各組４０４、４０５、４０６でのリソースは、別々の名前空間コンテナオブジェクトに格納される。これらのオブジェクトは、名前空間タイプとコンテキストとの組み合わせのための分離可能なストレージを可能にする。名前空間コンテナの一例は、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅのユーザの個人設定（ユーザコンテキスト）のファイルシステムコンテナである。これらのコンテナによって、各組み合わせに適した、局限され、独立したやり方でリソースを格納するが、次いで現在のシステムの機能によって動的に正しい名前空間に入れることができる。リソースは、名前空間コンテナ、または単に適切なリソースまたは名前付きオブジェクトを再作成するのに必要なメタデータで維持することができる。

多くの形のストレージ、データ構造などを使用して、この機能または均等物を達成することができることを理解できる。例えば、名前空間コンテナは、ローカルまたはネットワークファイルシステムに格納されているリソースセットに関連付けられているすべてのデータおよびメタデータを含む単一のファイルとすることができる。別の実施形態例では、名前空間コンテナは、基礎を成すまたはリモートのシステムに要求を転送するプロキシオブジェクトとすることができる。

本発明のシステムでは、相互運用の３つの基本的なモデルがある。１つのアプリケーションがリソースサービスを別のアプリケーションに提供することができるＰｒｏｄｕｃｅｒ／Ｃｏｎｓｕｍｅｒモデルである。このモデルの特徴は、１つまたは複数のプログラムが、相互交換の必要なしにリソースまたはサービスを提供するために、別のプログラムに依存し得る一方向の関連付けである。このモデルで、消費者は、アクセスを制作者の必要な統合ポイントに制限される。したがって、制作者の環境および名前空間コンテナは、一般に、消費者からアクセスできないが、代わりに、構成されたリソースまたはプログラムに基づくインターフェイスのみが許可される。このモデルの一例として、Ｇｒｅａｔ ＰｌａｉｎｓがＭｉｃｒｏｓｏｆｔ Ｅｘｃｅｌを使用して、それが保持する会計データからスプレッドシートを生成するなどの機能のためにＭｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅなどのプログラムを一般的に使用することが挙げられる。ＥｘｃｅｌおよびＧｒｅａｔ Ｐｌａｉｎｓは、独立したプログラムとして有用であり、機能的であるが、共にこの機能を追加することができる。Ｇｒｅａｔ Ｐｌａｉｎｓは、単に、プログラマティックにＥｘｃｅｌを駆動する必要があるだけであり、Ｅｘｃｅｌ自体の内部構成または状態にアクセスする必要はない。

第２のモデルは、Ｐｅｅｒモデルであり、１つまたは複数のプログラムが協調的にリソースを共有することができる。このモデルでは、共有は許可されるが、変更は、ポリシーによって定義された通りに厳重かつ明確に制御される。ピアの環境およびリソースは、単一の名前空間において１組として共存するように見えるが、本明細書に定義されたポリシーに従って、別々に処理される。このモデルの一例は、共有データベースドライバやＭｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅプラグインである。一般に、データベースドライバは、マシン上の多くのプログラムによって使用される。適切に機能するために、これらの他のプログラムは、ドライバの構成に関する情報にアクセスできなければならない。

最後に、システムは、従属関係またはコンテキストが定義されていない場合のデフォルトである、共有がない非相互運用モードをサポートする。あるいは、上述したように、このモードに相関する隔離コンテキストを作成することができる。

図８の主なプログラム、Ａｐｐｌｉｃａｔｉｏｎ Ａ ４０２は、動作しているとき、リソースを要求する。アプリケーション要求のそれぞれは、その関連のコンテキストおよび使用可能な範囲を決定するために、ソフトウェアコアによって評価される。このコアは、詳しくは図９に示されている。要求５１０が受信されると、コンテキストマネージャ５０３は、そのソースがプロセスマネージャ５０４によって識別されることを要求する。

プロセスマネージャ５０４は、そのホスト上で稼働するプロセス、およびこれらのプロセス５０５によってとられる操作のビューを保持する役割を果たす。このビューは、親および子のプロセスおよびスレッドのプロセスツリーに相関する。これによって、システムは、どのリソースプールがある特定の作動中のプロセスまたはスレッドのデフォルトであるかの基本的な理解を確立することができる。

現実にはあるアプリケーションから提供されたとき、多くの要求がオペレーティングシステムから来るように見えるため、ソース解決段階は、重要なステップである。この一例は、ファイルシステム呼び出しである。ファイルへの書き込み要求は、オペレーティングシステムによって遅延され、しかしアプリケーションプログラムにとって満たされる場合もある。後で、オペレーティングシステムがディスクへの書き込みをフラッシュするとき、要求は、オペレーティングシステム自体から来る。コンテキスト管理が適切に働くには、この要求を、その発信側プログラムに結合し直す必要がある。あるプログラムがＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔサービスなどの別のプログラムの代わりに物事を行うもう１つのケース例が示される。この場合、プログラムは、Ｗｉｎｄｏｗｓ（登録商標） Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔサービスが、その構成要素をホストシステムに登録するなど、何らかのインストールタスクを行うことを要求する。特定の要求のプロセス所有者のみを見るシステムは、このアクティビティがオペレーティングシステム自体の一部であることを決定するか、要求をＡｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｓｅｒｖｉｃｅに結合することになる。しかし、所望の結果としては、サービスが実行されることを要求したプログラムにアクションを結合することである。

本発明の一実施形態の実装形態例で、オペレーティング環境の共通のインターフェイスおよび通信経路が計装される。これらの計装インターフェイスは、ソースコンテキストを識別するのに有用である情報を捕捉するために使用される。上述したように、Ｗｉｎｄｏｗｓ（登録商標） Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｉｃｅの要求インターフェイスは、インストール要求の呼び出し側プログラムを識別するために計装される。このＡＰＩ呼び出しの内容は、プロセスマネージャ５０４に送信されて、将来使用するために格納する。このＡＰＩ呼び出しの有効な寿命中、プロセスマネージャ５０４は、この情報を、テーブル内に保持し、要求の所有者をルックアップする手段として使用する。

要求は、要求オブジェクト５１０としてシステムを介して送信される。上述したように、このオブジェクトは、それを発信したＡＰＩ呼び出しに関連付けられている属性を含む。さらに、要求は、例えば、そのサブシステム、要求タイプ（作成、クエリ、削除など）、対象、および親要求についてのデータを含む。一実施形態では、要求オブジェクトは、要求の各カテゴリ／サブシステムに相関するオブジェクト指向クラスとして実装される。これによって、各サブシステム５１１は、本発明の他の部分のインターフェイスに影響を与えることなく、要求固有の情報を格納することができる。

解決の探求が受信されると、プロセスマネージャ５０４は、ソース候補を見つけるために、プロセス、スレッド、およびアクションのそのツリーを検索する。図１０に、プロセス識別子（ＰＩＤ）、スレッド識別子（ＴＩＤ）、および状態またはアクションオブジェクトポインタ（ＳＰｔｒ）のリストを含むこのプロセステーブル５０５が示されている。各エントリは、１つまたは複数のプロセスオブジェクトの親とすることができるプロセスオブジェクトである。親−子の関係は、ホストオペレーティングシステムのものを映す。各プロセスオブジェクト６０３は、必要に応じて過去のアクションへの参照を保持する状態オブジェクト６０４へのポインタを含む。好ましい実施形態では、各アクションは、操作、操作データ、および操作を要求したソースプロセス識別子から構成することができる。実際には、例えば操作の結果、成功または失敗およびその結果コード、操作に関するタイミングまたは寿命情報、および操作のセキュリティ資格情報など、他のデータが格納される。

プロセスまたはスレッドがアクションに関連付けられている場合、アクションが現在の要求に一致するかどうかを識別するために、プロセスリストが検索される。前のＷｉｎｄｏｗｓ（登録商標） Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｉｃｅの例では、発信側プログラムによるＡＰＩ呼び出しによって、Ｗｉｎｄｏｗｓ（登録商標） Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｉｃｅプロセスオブジェクト下に状態オブジェクトが作成される。この状態オブジェクトは、発信側プログラムが要求されたアクションのソースであったことを識別する。ファイルを作成したり変更したりするなどのアクションを行うことによって、Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｉｃｅがＡＰＩ要求を満たそうと試行したとき、プロセスマネージャは、Ｗｉｎｄｏｗｓ（登録商標） Ａｐｐｌｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ ｓｅｒｖｉｃｅのプロセスオブジェクト下で、呼び出しに関連付けられている状態オブジェクトを見つけるが、実際には、そのファイルは、そのサービスを使用している発信側プログラムによって作成されていることを戻す。

要求ソースが理解されると、プロセスマネージャ５０４は、要求の所有者のプロセスおよびスレッドＩＤ、および、これらが同じである可能性はあるが、その真のソースをコンテキストマネージャ５０３に戻し、そこでその１つまたは複数のコンテキストと一致させる。一実施形態では、コンテキストマネージャ５０３は、図１１に示されるように、システムの使用可能なコンテキストのテーブル、およびコンテキスト間の関連付けを含む。コンテキストは、そのコンテキストタイプ（ＣＴｙｐｅ）と共に、基本識別子（ＣＩＤ）を含む。次いで、コンテキスト自体は、機能上の相関関係を使用可または使用不可にする１つまたは複数のポリシーオブジェクト７０５へのポインタ（ＰｏＰｔｒ）を必要とする。ポリシーオブジェクトは、それ自体の識別子、およびマシンサブシステムを識別するマッチニーモニックを含むとともに、リソースの名前空間コンテナおよび名前付きオブジェクトの変換操作などの要求相関パラメータ、および操作を適用するルールを含む。ポリシー例は、例えば書き込み、削除など、ローカルシステム名前空間コンテナに加えられるべき、例えばＭｉｃｒｏｓｏｆｔ Ｗｏｒｄファイルタイプ（＊．ｄｏｃ）などに一致するファイルへの任意の変更である。このポリシーを様々な形で体系化できることを当業者は理解されよう。

このテーブルは、静的および／または動的に構築することができる。というのは、アプリケーションは、システムで使用され、ハッシュテーブル、リストなど、任意の技術を使用して行うことができるからである。アプリケーションが開始されると、アプリケーションの関連のプログラム、名前空間コンテナ、およびコンテキストの関係のすべてを示すために、このテーブルをロードすることができる。本発明のシステムの実施形態によって、コンテキストマネージャ５０３は、管理インターフェイスを介して、外的にクエリを行い、新しいコンテキストをロードしたり、システム構成の変更に応答したりすることができる。したがって、稼働中のプログラムと同位のアプリケーションが追加された場合、そのコンテキスト情報をライブシステムにロードすることができる。さらに、コンテキストマネージャ５０３は、これらを他のマシンと共有できるように、その稼働中の、またはロードされたコンテキストを、このインターフェイスを介して外部管理システムに通知することができる。これを別のマシンと直接に行うことができることを当業者は理解されよう。

コンテキストマネージャは、コンテキストの候補リストをポリシーエンジン５０６に送る。特定のコンテキスト内で要求を解決する必要を決定したり、セキュリティを実施したりするために、各コンテキストのポリシーは、さらに、ユーザ、マシン、またはシステム固有のポリシーに適用される。このプロセスによって、要求をその中で評価するコンテキスト候補の数が迅速に制限される。ポリシーエンジン５０６については、以下のセクションでより詳しく説明する。

次いで要求は、ファイルシステム、レジストリ、その他のどれであろうと、関連のソース管理サブシステムによって、各コンテキスト内で１回または複数回評価される。次いで、各要求の結果は、コンテキストマネージャによって分析することができ、最終結果は呼び出し側プロセスに戻される。コンテキストマネージャは、その環境テーブルを介して要求を適切なサブシステムにマッピングすることができ、そこで仮想アプリケーションおよびオブジェクト、または管理されているが、完全にそのホストにインストールされ、またはそこで構成されているアプリケーションを追跡する。

実際に、このやり方で管理される必要があるいくつかのクラスの操作がある。それは、読み取り、書き込み、クエリ／ルックアップ、作成、名前変更／変更、列挙、および削除である。他の多くの操作が処理される好ましい実施形態では、処理されたすべての操作の詳細なしに、基本のシステムモデルを記述することがより簡単である。各クラスの操作を別々に処理することによって、システムは、ポリシーを作成することができ、これによって、リソースへの読み取りアクセスは可能になるが、代替リソース、名前空間コンテナ、その他への書き込みアクセスを拒否したり、転送したりすることができる。

読み取り操作では、システムには、読み取り要求を満たすための選択肢がたくさんある。読み取りがファイルに関するものである場合、このファイルは、１つまたは複数のコンテキスト内に存在し得る。評価すべきことを決定することは、コンテキストマネージャの責任である。これはいくつかの方法で対応できることを当業者は理解されよう。要求は、すべてのコンテキストにおいて行うことができ、次いでどの応答を使用するか、または応答をどのように組み合わせるかの決定は、そのルールに従って行うことができる。要求は、使用可能なコンテキストによってフィルタリングでき、どのコンテキストが優先であるかを決定し、そのコンテキスト内でのみ要求を行う。または、一例として、一部の成功基準が満たされるまで、要求は、各コンテキスト内で連続的に評価することができる。読み取り操作の場合、成功は、読み取り操作のデータをサポートするコンテキストの機能によって示されることができる。

また、コンテキストマネージャは、あるパターンに従い、全解決段階を必要としない共通の要求を行うために、その解決処理の結果をキャッシュすることもできる。さらに、コンテキストマネージャは、コンテキストのハッシングを介してクエリを配布することができる。このハッシングプロセスによって、システムは、完全な操作クエリを行うことなく、迅速にそのテーブルに対して照会を行い、他のテーブルに対してクエリを行うことができる。

上記の例のファイルを１つのアプリケーションプログラムのコンテキストから読み取ることができ、しかし、それが書き込まれる場合、実際の書き込み操作が別のコンテキスト内で行われる場合、コンテキスト手法の重要性がわかる。システムのこの挙動は、２つのシステムが互いに相互運用し、しかし依然として互いに分離され、または独立したままであるようにすることができることである。オペレーティングシステムガードの明細書によって記載されているように、オペレーティングシステムの一部であるファイルを、稼働中のプログラムのコンテキスト内で見ることはできるが、プログラムがファイルを変更しようと試行した場合、その変更は、プログラムコンテキスト内で保持することができ、オペレーティングシステムを介してフィルタリングされない。

同じことは、名前変更および削除の操作でも真である。あるコンテキストで削除されるファイルは、別のものに必要である可能性がある。したがって、本発明のシステムは、存在情報および構成だけではなく、例えば、削除および名前変更についての情報の追跡も保持する。

クエリプロセスは、最も単純である。読み取り操作と同様に、これは、グループの優先順位、またはシステムが選択する任意の手段を介して、階層的に実行することができる。しかし、操作の目的は、ハンドルの存在を確認したり、ハンドルを正しいコンテキスト内の名前付きオブジェクトに戻したりすることである。本発明のシステムは、正しいオブジェクトはどれか、それが現在のコンテキストで可視かどうか、およびその範囲をどのように内部で管理するかを決定するために、コンテキストポリシーを適用する。

本発明の一実施形態では、システムは、コンテキストの列挙およびインターリーブドクエリ（ｉｎｔｅｒｌｅａｖｅｄ ｑｕｅｒｙ）を処理することもできる。オペレーティングシステムまたはそのアプリケーション内の多くのデータ構造またはリソースは、ツリー構造をトラバースしたり、システムに一部のリソースの内容のリストを求めたりすることによってアクセスされる。実際には、これらの操作は、コンテキストおよびリソースのインターリーブを必要とする。一例として、アプリケーションは、それに関連付けられているリソースを有し得る。しかし、このリソースは、別のプログラムがそれ自体に関連付けられており、アクティブな場合のみ有効である。

図１２に示されるように、リソースは、別のプログラムのリソースツリーに付加することができる。そのため、このリソースについてのクエリ中、システムは、２つの別々の構成の名前空間をインターリーブすることができなければならない。しかし、ポリシーが結合操作を許可しない場合、名前付きオブジェクトへの直接アクセスもそれの列挙も起こらない。図で示される例では、アプリケーション、Ａｐｐｌｉｃａｔｉｏｎ Ａは、Ｗｉｎｄｏｗｓ（登録商標）レジストリキーオブジェクトを表す３つの項目で構成される。オブジェクトＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ｄｒａｗｉｎｇ Ｖｅｎｄｏｒ＼Ｐｈｏｔｏ Ｅｄｉｔｏｒ＼Ｐｌｕｇｉｎｓ＼Ｐｉｎｈｅａｄ Ｓｏｆｔｗａｒｅ＼Ｉｎｌｉｎｅ Ｐｌｕｇｉｎｓ＼Ｓｎａｐｓｈｏｔ８０５は、第２のアプリケーション、Ａｐｐｌｉｃａｔｉｏｎ ＢがＡｐｐｌｉｃａｔｉｏｎ Ａと共有されるコンテキスト内で構成される場合のみ存在する。

オブジェクトが実際にＡｐｐｌｉｃａｔｉｏｎ Ａに存在していてもそうである。項目「Ｐｉｎｈｅａｄソフトウェア」８０２は、Ａｐｐｌｉｃａｔｉｏｎ Ａのコンテキストに存在しない場合、取り残され得る。システムは、２次アプリケーションが存在しない限り、それに従うパスがないため、このリソースへの列挙をせず、それへの直接アクセスも行わないように設計されている。さらに、Ａｐｐｌｉｃａｔｉｏｎ Ｂが単独でインスタンス化される場合、他の８０２、８０３下に付属するそのリソースは、同じ理由で存在しない。

名前空間の管理
そのほとんどの基本的な形では、コンテキストは、アプリケーションのリソースを公開するための個別の名前空間、およびこれらの項目に加えられる操作を持続する方法である。名前空間は、一意の名前を識別可能な何らかのリソースにマッピングする領域または範囲である。オペレーティングシステムガードレイヤは、この代替の名前空間を作成し、管理する媒介（ｉｎｔｅｒｍｅｄｉａｒｙ）である。アプリケーションは、この媒介に気付かない。アプリケーションは単に、所与の名前付きのオブジェクトを作成し、後で同じ名前でそれらを参照することができると予想するだけである。このレイヤは、複数の名前空間を管理するが、それらを、実行中のアプリケーション、またはシステムの残りから単一の名前空間に見えるようにすることができる。このように、オペレーティングネットワーク１５０に提示される単一のリソースは、実際には、様々な異なる名前空間からの複数のリソースによって戻すことができる。

デフォルトでは、媒介レイヤは、ロードする各プログラムインスタンスがプライベートの名前空間を有する隔離コンテキストを作成する。アプリケーションがリソースを作成し、使用するとき、オブジェクト名は、特定のアプリケーションインスタンス内にのみ存在するように局限される。これは一般に、オブジェクトが実際にプログラムの範囲内にのみ存在することを確実にすることによって行われるが、より大きい名前空間内でオブジェクト名をハッシュし、逆プロセスを介して、それを取り出すことによっても行うことができる。このように、別のプログラムは、媒介の機能をリバースエンジニアリングすることなく、その名前空間内に存在しないオブジェクトを要求することができない。

オブジェクトを参照するためにアプリケーションが使用する名前は、一般名と呼ばれる。システム上の２つの別々のアプリケーションは、同じ一般名を使用するが、異なるオブジェクトを参照することができる。この媒介は、正しいオブジェクトに相当するインスタンス固有の名前を作成する役割を果たす。これは、ローカル名と呼ばれる。ローカル名ごとに、さらに、システム全体にわたって一意の絶対名がある。その絶対名を使用したオブジェクトへのすべての参照は、同じオブジェクトを参照する。

一般名は、アプリケーションによって指定される。ローカル名は、そのコンテキスト内で一般名を評価することによって、実行時に媒介によって動的に生成される。システムは、絶対名を生成する必要はなく、プログラムの従属関係およびそのコンテキスト関係に基づいて、そうすることを選択することができる。アプリケーションは、決して絶対名を知らされない。ローカル名を絶対名にマッピングする、正しい一般名をローカル名にマッピングする、またその逆を行うことは、この媒介の責任である。

コンテキストの存在下で、同じコンテキスト内の２つのアプリケーションは、同じ一般名を使用してオブジェクトを作成し、それにアクセスする場合、同じオブジェクトを参照することができる。オブジェクト要求を接続することは、この媒介の責任である。これらの要求を接続する方法はいくつかある。好ましい実施形態では、媒介レイヤは、同じ方法で同じコンテキストでオブジェクト名をハッシュすることを選択することが多い。他のいくつかの操作は、単に、要求を異なる名前のオブジェクトに転送することによって実行することができる。疎接続されたコンテキストにおけるアプリケーションの場合、システムによって使用される機能によって、迅速な検索方法を使用して、オブジェクトを探し、オブジェクト間を関連付けることができる。好ましい実施形態では、名前を迅速に解決するために、ローカル結果キャッシングによる分散ルックアップ（ｄｉｓｔｒｉｂｕｔｅｄ ｌｏｏｋｕｐ ｗｉｔｈ ｌｏｃａｌ ｒｅｓｕｌｔ ｃａｃｈｉｎｇ）が使用される。

システムの一例では、プログラムは、３つの場所で使用可能なリソースを使用しようと試みることができる。まず、プログラムの１次構成および２次依存構成で使用可能である。また、オペレーティングシステムの一部としても使用可能である。ここでの例では、ファイルＭＳＣＯＭＣＴＬ．ＯＣＸを選択する。通常、このリソースは、Ｃ：＼Ｗｉｎｄｏｗｓ（登録商標）＼Ｓｙｓｔｅｍ３２＼ＭＳＣＯＭＣＴＬ．ＯＣＸの一般名を有する。オペレーティングシステムガードを使用すると、媒介レイヤによって、この名前は、３つすべての構成に存在することができる。すべての構成にとって、オブジェクトの一般名は同じである。

媒介レイヤによって、当該のプログラムは、同じ名前のオブジェクトのコピーを有することができる。さらに、２次構成は、異なる名前を有するオブジェクトを有しているが、その構成において、オブジェクトの一般名がＣ：＼Ｗｉｎｄｏｗｓ（登録商標）＼Ｓｙｓｔｅｍ３２＼ＭＳＣＯＭＣＴＬ．ＯＣＸであることをシステムに伝える仮想化コマンドを指定することができる。これによって、オペレーティングシステムガードは、オブジェクトを、それが実際に使用されている名前空間または格納場所とは異なる別のものの中に格納することができ、実行時にこれらの名前空間をマッピングすることによって、その挙動を表面化させる。

この例では、３つのオブジェクトはすべて、同じ一般名を有する。コンテキスト解決プロセスは、どのオブジェクトが実際の優先順位をとるかを選択する。次いで、システムは、適切に局限された名前を生成し、使用する。この場合、システムは、１次構成のオブジェクトを選択し、そのプログラムインスタンスのコンテキスト内でローカル名をマッピングすることを選択することができる。

コンテキストの範囲がより大きく広くなるにつれて、システムは、名前空間マッピングの作成、クエリ、取り出しを行う名前空間マネージャ５０８機能を提供することもできる。通常、プログラムが一般名を有するリソースを使用しようと試みるとき、マネージャは、この一般名のリソースを使用して、他のプログラムのそのリストに対してクエリを行うことができる。次いでこれは、追加プログラムのいずれかがコンテキストを共有する場合、コンテキストマネージャによって使用することができる。そうである場合、共有プログラムが同じリソースを使用することを確実にするために、マッピングを行うことができる。これは、同じローカル名の使用を実施することによって、またはシステム絶対名の使用によって行うことができる。これは、特に、マシンの範囲を超えて広がるコンテキストに有用である。

この操作は、名前空間コンテナを取り出し、それに含まれているリソースのメタデータをロードするローダ５０９の副作用をもたらす可能性があることに留意されたい。リソースは、可変の寿命を有し得るため、名前空間マネージャ５０８は、コンテナの参照カウント／追跡、ロード、および確定、および一部の場合、推論的仮想化（ｓｐｅｃｕｌａｔｉｖｅ ｖｉｒｔｕａｌｉｚａｔｉｏｎ）を含めて、リソース管理操作を実施する。

推論的仮想化とは、ファイル、レジストリキー、または他のリソースへの読み取りおよび書き込み操作など、操作中に使用されるプロセスである。リソースが開かれたり、それに対するクエリが行われるとき、システムは、リソースが後で変更されることを想定し、書き込みなどの別の操作がシステムにおいて実行し得るものを決定するために、追加のポリシーを実行することができる。次いで、システムは、前もって、またはバックグラウンドでこれらの操作を実行して、それらが実際に実行される場合にさらなるコストまたは待ち時間を避けることができる。すべての推論的操作と同じく、その後の操作が実行されない場合、システムは、アクションを取り消すことができなければならない。本発明の一実施形態では、システムは、推論的仮想化を使用して、高コストのコピーオンライト操作となり得ることを避けるのを助ける。ファイルが変更されたとき、ファイルが大きい、離れている、またはその両方である場合、コピーオンライトセマンティックは、高いコストを招く可能性がある。この手順によって、コピーオンライトアクションは、バックグラウンドで早期に進めて、操作の実行時のコストを避けることができる。

また、この名前空間マネージャは、システムの管理レイヤ内で動作することもでき、オペレーティングシステムガード内で動作する同じ実際のマネージャであってもよいが、システム全体のクエリに応答するように構成することもできる。または、専用のアプリケーションとすることができる。この管理機能は、構成された絶対名のリポジトリを提供し、絶対名を大規模なコンテキストにマッピングするよう働く。

この名前空間マネージャは、各名前空間内の名前の時間発展を管理することもできる。これは、ハッシュするための標準アルゴリズムが時間変数を含み得るとしても、特定のオブジェクト名が毎回同じ方法でハッシュされることを確実にするために使用することができる。これを行うことによって、時間依存型のコンテキストまたはセマンティクスを操作に提供することができる。さらにこれは、使用を格納し、システム内で情報をマッピングすることによって行うことができる。

過去に、あるインターフェイスでプログラムによってオブジェクトが要求され、同じ名前の新しいインターフェイスが使用可能である場合、この時間依存型の挙動は、システムが古いインターフェイスにマッピングすることを確実にすることができる。これは、デフォルトとしてこのシステムで行われる。新しいインターフェイスにマッピングすることが望ましい場合、新しいバージョンの使用を断定的に断言することができる。複数のバージョンのソフトウェアシステム、および本明細書で検討されているものなどのシステムの存在下で、ソフトウェアシステムの作成者またはマネージャによってそうするように構成されるまさにその方法でリソースの作成および使用を確実にすることができる。

関連の例として、多くのシステムは、ＤＣＯＭ、ＣＯＲＢＡ、さらにはＨＴＴＰ ＲＰＣなど、分散された関数の呼び出しを使用する。２つのプログラムは、通信を行うことができるように、互いに依存するように構成することができる。プログラムを接続するために使用された一般名は、アドレスおよびインターフェイスを含む。ＤＣＯＭの場合、分散クエリ、およびそのインターフェイスを公表するそのＣＯＭ ＵＩＤをホストするマシンがある。ホストは、その一般名をすでにローカル名にマッピングしておいてもよい。リモートプログラムは、ホストおよびＵＩＤをアドレス指定しようと試みるため、システムは、そのローカル名に対応するようにアドレスおよびＵＩＤをマッピングすることができ、または、代替ホストを起動させて、インターフェイスの適切なバージョンが提供されることを確実にすることができる。上述したように、リモートプログラムによって使用される一般名の、ホストによって使用されるローカル名へのマッピングは、名前空間マネージャ内でリソースの絶対名を探すことによって、またはホストシステムの名前空間マネージャに対して、その共通名からローカル名へのマッピングについてクエリを行うことによって、システムによって内部で行うことができる。インターフェイスの２次バージョンが存在する場合、名前空間マネージャは、リモートの起動に適切なバージョンを反映する代替マッピングで応答することができる。

コンテキストポリシー
操作が複数のコンテキストにわたる可能性がある場合を管理するために、適した機構が必要であることを上述した。これらの相互運用の性質は、命名の衝突、優先順位を決定する必要が生じるケース、または変更操作の効果を解決するための状況を招く可能性がある。上記で定義されたコンテキストの存在に対して、システム管理者、または望む場合、エンドユーザまたはソフトウェアベンダーは、操作を制御するためのポリシーを確立することができる。コンテキストのマクロおよびミクロの調整が迅速な構成、しかしきめの細かい制御を可能にする能力を提供することが望ましい。

本発明のシステムの一実施形態は、ＸＭＬベースの構成ファイルを介してアプリケーションおよびオペレーティングシステムの相互依存を記述する手段を提供する。ここには１つしか記載されていないが、このプロセスは多くの方法で対応できることを当業者であれば理解されたい。

図８のシステムでは、Ａｐｐｌｉｃａｔｉｏｎ Ａは、構成ファイルａ．ｃｏｎｆｉｇ４０８を有し、Ａｐｐｌｉｃａｔｉｏｎ Ｂは、ｂ．ｃｏｎｆｉｇ４０９の構成ファイル、およびｃ．ｃｏｎｆｉｇ４１０に記述されている共有リソースセットを有する。プログラム間の相互依存を確立するために、＜ＣＯＮＴＥＸＴ＞コマンドは、２つのプログラムが共有コンテキスト内に共存すべきであることを示すａ．ｃｏｎｆｉｇ４０８ファイルに入れられる。この例では、コンテキストは、ＥＸＡＭＰＬＥの名前およびＰｅｅｒのコンテキスト範囲を有する共有コンテキストである。

システムにおいて、このタグは、それが使用されるには、両方のプログラム記述に必要なわけではない。それが評価されるために、特定のセキュリティ領域内で関連性を有していなければならないことだけが求められる。したがって、別のものと共有できるプログラムは、ユーザが両方のプログラムへの権利を有している場合を除いて、コンテキストを確立しない。

さらに、コンテキストの理解および評価を助けるシステムを提供することができる。一例として、管理コンテキストが望ましい場合、どのシステムがコンテキストに参加するかを理解することをシステムによって求められる。これは、コンテキストの各メンバによって、またはグローバルにシステム全体のサービスによって評価され、このコンテキストを評価するとき、各マシンに提供することができる。これについては、コンテキストマネージャシステムおよびその管理インターフェイスの一部として上述している。本発明のシステムは、ソフトウェアパケットの記述とは別のコンテキスト関係を記述するポリシーファイルを作成できるようにすることによって、この挙動を容易にする。

ポリシーファイルは、システムのデフォルトの挙動を作成したり、システムによって使用するために基本のコンテキストを確立したりするために使用することができる。常に、システムは、ポリシーを、そのサブシステムによって使用するために、そのポリシーエンジンにロードしたり、再ロードしたりすることができる。ポリシーを特定のユーザ、グループ、マシン、または他の関連の構成のみに適用できるようにする追加の修飾子および変数を適用することができる。これらのポリシーの適用を制御するために、任意の数の変形をこの技術に適用することができるが、基本制御は、コンテキストが適用されるかどうか、およびその実行時の挙動が何であるかを決定することであることは理解されよう。また、システム全体にわたってその保全性を確実にし、コンテキスト上の挙動を変更するためにユーザがポリシーを作成するのを避けるために、ポリシーは、デジタル署名することもできる。

個々の構成項目レベルで、システムは、特定のリソースのみがコンテキスト制御に公開されることを指定することもできる。このユーティリティは、２つのプログラムが通信する必要があり、その通信インターフェイスを接続できるだけでよく、しかし、任意の構成の詳細を理解する必要がない場合に非常に有用である。また、これは、別のプログラムを変更するあるプログラムの機能を構成全体のわずかな部分で包囲するのに有用である。この例で、共有リソースセットは、ｃ．ｃｏｎｆｉｇで、リソース＼＼ｐｉｐｅ＼ｔｅｓｔｒｅｓｏｕｒｃｅのホストとして働くセッションコンテキストが存在することを宣言している。このリソースセットと同じセッションで稼働している任意のアプリケーションは、この名前付きリソースを使用することができるとともに、ＨＫＬＭ＼Ｓｏｆｔｗａｒｅ＼Ｔｅｓｔ＼Ｖａｌｕｅでその他の構成データを見ることができる。システムの一実施形態において、任意の特定のリソースに名前が付けられた場合、こうしたリソースのみが共有される。そうでない場合、指定がないと、すべてのリソースがコンテキスト指示に従って共有されると暗示されることになる。

ポリシー指示は、操作のクラスの結果を定義するのにも有用である。このタイプの指示の簡単な一例は、Ｗｉｎｄｏｗｓ（登録商標）レジストリへの任意の変更がユーザの個人設定名前空間コンテナに入るべきであることを宣言するポリシーである。これらのタイプのポリシーによって、特定のアプリケーションだけではなく複数のコンテキストおよび複数の名前空間およびコンテナに適用される相交わる定義を可能にする。

また、修飾子は、各仕様を読み取り専用または読み取り−書き込み可能にすることができるすべてのコンテキスト構成に許可される。デフォルトの挙動は、コンテキスト固有である。さらに、コンテキスト認識の関連付けへの書き込みを可能にする場合、どのコンテキスト内で書き込みが行われるかを識別することが重要である。これについては、後でさらに詳しく説明する。しかし、構成ファイルは、システムの通常の挙動をオーバーライドして、特定の対象を指定することができる。

本発明のシステムによって提供された別の修飾子は、確立されたコンテキストの優先順位をオーバーライドする機能である。任意の特定の関係は、ピア間であると決定することができる。この場合、情報の一部の所有者がその寿命の責任を負うことは自然であり得る。しかし、変更を行ったプログラムがそれ自体内の変更のみを見ることが望ましい。２つのプログラムが共有コンテキスト内にある場合、変更は、このように持続しない。修飾子は、この代替挙動を強要することができる。

コンテキストの決定および制御
システムが実行可能であるために、最適な挙動を決定する何らかの自動化手段を提供する必要がある。デフォルトでは、オペレーティングシステムガードは、プログラムが同じコンテキスト内になるように明示的にパッケージされない限り、それらを隔離コンテキストに存在するように構成する。同じアプリケーション環境下でパッケージされたすべてのプログラムは、その１つのコンテキストを共有する。しかし、上述したように、相互運用可能なコンテキストの作成をさらに自動化することが望ましい。本発明のシステムは、挙動を制御するために、これらのコンテキストおよびポリシーを検出し、構成するためのいくつかの手段を提供する。

アプリケーションのインストール中、システムは、インストールがその対象のコンテキストを直接構成できるようにする。仮想インストールソフトウェアまたはオペレーティングシステムガードの場合、これは、特定のプログラムの隔離コンテキストである。新しい構成環境は、特にインストールされるアプリケーションまたはアプリケーションの組のために作成される。例えば、既存のアプリケーションのコンテキスト内でインストールプログラムを実行するなど、システムに既存の構成要素を増やしたいという望みを示すことによって、インストールは、付加的なやり方で環境内で行うことができる。

ＥＳＤシステムを介するなど、標準の手段で配布され、インストールされるソフトウェアの場合、ソフトウェアは、通常、ローカルシステムコンテキストにインストールされる。オペレーティングシステムガードのシステムとは反対に、通常のアプリケーションレベルソフトウェアおよびオペレーティングシステムは、マシン内の同じ場所に存在する。好ましい実施形態のシステムにおいて、ソフトウェアは、インストール時に選択された個別のコンテキストにインストールされるように構成することができる。これは、通常、所望の挙動に応じてベンダーコンテキスト、ユーザコンテキスト、またはセッションコンテキストのうちの１つであるが、使用可能なコンテキストのいずれかとすることができる。一例として、ベンダーのＭｉｃｒｏｓｏｆｔからのすべてのソフトウェアは、Ｍｉｃｒｏｓｏｆｔアプリケーションのコンテキスト内にインストールすることができる。

この方法を使用して、システムは、インストールされたオブジェクトを代替の格納場所に転送し、実行時にマッピングするために一般名を作成することができる。これによって、マシンまたはその黙示のオブジェクト名前空間に損傷を与えることなく、アプリケーションをマシン上にインストールすることができる。また、システムは、対象のマシンへの実際のインストールに先立って構成を作成するために、再対象化されたシステム、仮想マシン、シミュレーション環境、または宛先ホストへのソフトウェアのインストールを可能にすることができる。これによって、実行中に仮想環境を作成することができ、仮想インストールのためにソフトウェアを準備する先験的なステップを必要としない。

先行出願で記載したように、インストールが完了すると、オペレーティングシステムガードは、その構成をダウンロードする。このダウンロード中、構成は、作成パターンについて分析することができる。これらのパターンは、プログラムを計装し、一般的な命名問題からプログラムを取り出すために使用される。一例として、多くのプログラムは、インストールされるときにそれ自体を「個人専用にし」、インストールするユーザまたはプログラムが稼働されるマシンについての情報をその構成に書き込む。このシステムは、これらのローカル名を削除し、それらを一般名に置き換える。または、そのインストール中のプログラムがＯＤＢＣ ＤＳＮを作成する場合、ＯＤＢＣサブシステムの適切なバージョンへの従属関係を作成することがシステムにはわかっている。

これらのパターンは、インストール中にライブで有効にすることもできる。パターンは、アプリケーション固有のテンプレート、または一般の経験則とすることができる。一例は、Ｍｉｃｒｏｓｏｆｔ ＯｆｆｉｃｅにインストールするプログラムがＨＫＥＹ＿ＬＯＣＡＬ＿ＭＡＣＨＩＮＥ＼Ｓｏｆｔｗａｒｅ＼Ｍｉｃｒｏｓｏｆｔ＼Ｏｆｆｉｃｅレジストリキーを検索することである。これらの方法を実施するシステムは、これらのテンプレートを実施するための内部ルール、または１組の構成可能なインストール可能テンプレートを提供することができる。

システムの一実施形態では、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅを検索しているプログラムは、上記の名前付きレジストリキーについてクエリを行う。そのクエリ中、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅソフトウェアがローカルマシン上にインストールされると、プログラムが機能するためにＯｆｆｉｃｅが存在することを確実にするために、従属関係を新しいソフトウェアパッケージ内で作成することができ、またプログラムがローカルマシン上で互いに可視であることを確実にするためのコンテキストを作成することができる。Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅソフトウェアが仮想インストールパッケージの一部である場合、システムは、その名前空間マネージャ内でこのレジストリキーを見つけ、新しいソフトウェアパッケージが相互運用する必要があり得るコンテキストのリストを見つける。次いで、仮想パッケージへの従属関係を作成し、相互運用性のために共有コンテキストを作成することができる。

システムの一実施形態では、使用可能なソフトウェアパッケージは、１つまたは複数のリポジトリに格納される。構成およびコンテキスト情報は、システムのコンテキストマネージャによって容易にクエリが行われる。要求が行われるとき、その要求は、候補のコンテキストおよび従属関係の全リポジトリと照合することができる。Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅ例の場合、システムは、テンプレートを必要としないが、代わりに、Ｍｉｃｒｏｓｏｆｔ Ｏｆｆｉｃｅに対するクエリを、リポジトリ内のアプリケーションから発信しているものと解決する。次いでシステムは、Ｏｆｆｉｃｅアプリケーションおよびその構成をインスタンス化し、インストールされているプログラムのコンテキストおよび従属関係を作成することができる。

デフォルトでは、システムは、できるだけ制限的になることを試み、できるだけ最小の開いたまたは共有のコンテキストを、共有に必要なリソースのみで構成する。コンテキストポリシーおよび構成を変更するとともに、リソースレベルコマンドを迅速に削除し、パッケージ全体の共有を設定するか、コンテキストを変更するためのインターフェイスが提供される。

本発明の原理を適用できる広範な実施形態を鑑み、示された実施形態は、例にすぎず、本発明の範囲を制限するものとみなされるべきではないことを理解されたい。例えば、フロー図のステップは、記載されているもの以外の順序で行うことができ、より多くのまたはより少ない要素を図に使用することができる。実施形態の様々な要素がソフトウェアに実装されるものとして記載してきたが、ファームウェア実装のハードウェアでの他の実施形態を代わりに使用したり、その逆を使用したりしてもよい。

システムに関与する方法およびコンテキストポリシー制御を介したアプリケーション間の関連付けを制御する方法は、コンピュータ使用可能媒体を含むコンピュータプログラム製品に組み込まれてもよいことを当業者であれば理解されよう。例えば、コンピュータ使用可能媒体は、コンピュータ可読プログラムコードセグメントを格納する、ハードドライブ装置、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはコンピュータディスケットなど、読み取り可能メモリ装置を含み得る。また、コンピュータ可読媒体は、デジタルまたはアナログのデータ信号としてプログラムコードセグメントを運ぶ光、配線、無線などのバスまたは通信リンクなどの通信または送信媒体を含み得る。

他の態様、変更、および実施形態は、特許請求の範囲内に含まれる。

オペレーティングシステムとソフトウェアアプリケーションとの本発明の相対的な関係を図示するブロック図である。 ２つのアプリケーションがプライベートコンテキストおよびサービスで稼働している様子を図示するブロック図である。 オペレーティングシステムがシステムリソースの共有ビューを提供する間、２つのアプリケーションが稼働している様子を図示するブロック図である。 オペレーティングシステムガードおよびサブシステムを図示するブロック図である。 システム全体のビューがグローバルコンテキストに対応する本発明の一態様による１つまたは複数のコンピューティング装置を有する複数のシステムを含むホストオペレーティングシステム例を示す図である。 グローバル、管理、ローカルシステム、システム仮想、ベンダー、ユーザ、セッション、共有、および隔離など、図５に関して示されたシステム例の実施形態による異なるコンテキストを示す図である。 グローバル、管理、ローカルシステム、システム仮想、ベンダー、ユーザ、セッション、共有、および隔離など、図５に関して示されたシステム例の実施形態による異なるコンテキストを示す図である。 本発明の一実施形態による、互いのリソースおよびオペレーティングシステムを使用する２つのアプリケーション、およびリソースの３つの異なる構成ファイル示すブロック図である。 本発明の一実施形態による関連のコンテキストおよび使用可能な範囲を決定するために使用されるソフトウェアコアを示すブロック図である。 本発明の一実施形態によるプロセスマネージャによって使用されるプロセスツリーを示す図である。 本発明の一実施形態による、システムの使用可能なコンテキストのテーブル、およびコンテキスト間の関連付けを含むコンテキストマネージャを示す図である。 本発明の一実施形態による別のプログラムのリソースに付加されるリソースを示す図である。

Claims (15)

1. 複数のソフトウェアアプリケーションおよびリソースの相互運用を制御する方法であって、
   第１のアプリケーションから第２のアプリケーションまたはリソースへの通信をインターセプトするステップと、
   前記通信をコンテキスト管理システムに向けるステップと、
   前記通信用のコンテキスト候補リストを生成するステップと、
   これらのコンテキストのために定義された少なくとも１つのポリシーに従って前記候補リストを評価して、前記通信のために結果として生じたアクションおよび名前空間を識別するステップと、
   前記識別された名前空間内の前記少なくとも１つのポリシーによって定義された通りに前記アクションを行うステップと
   を含むことを特徴とする方法。
2. 前記第２のアプリケーションの、１つまたは複数のバージョンを追跡するステップをさらに含むことを特徴とする請求項１に記載の方法。
3. アプリケーションおよび／またはリソース名の進化を追跡するステップをさらに含むことを特徴とする請求項１に記載の方法。
4. 前記候補リスト上のコンテキストに関連付けられている１つまたは複数の操作を識別するステップと、
   その後の通信の前に前記識別された１つまたは複数の操作を実行するステップと
   をさらに含むことを特徴とする請求項１に記載の方法。
5. 前記候補リストを生成する前記ステップは、１つまたは複数の分散されたコンテキストからコンテキストを供給するステップを含むことを特徴とする請求項１に記載の方法。
6. 通信は、プロセス間通信、オペレーティングシステム呼び出し、ＡＰＩ呼び出し、およびライブラリ呼び出しのうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
7. コンテキストは、グローバルコンテキスト、管理コンテキスト、ローカルシステムコンテキスト、システム仮想コンテキスト、ベンダーコンテキスト、ユーザコンテキスト、セッションコンテキスト、共有コンテキスト、または隔離コンテキストのうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
8. 前記少なくとも１つのポリシーは、前記ポリシーをいつ適用するかを識別するマッチニーモニック、複数の要求相関パラメータ、および前記ポリシーを適用するルールのうちの少なくとも１つを含むことを特徴とする請求項１に記載の方法。
9. 他のアプリケーションまたはリソース内で実行されるアプリケーションのための代替名前空間を定義する方法であって、
   一般名のリソースの呼び出しをインターセプトするステップと、
   前記呼び出しの対象の名前空間を識別するステップと、
   前記一般名をその名前空間内のアプリケーションによって使用可能なローカル名に変換するステップと、
   そのローカル名によって識別される前記リソースへのアクセスを提供するステップと
   を含むことを特徴とする方法。
10. アプリケーションの、１つまたは複数のバージョンを追跡するステップをさらに含むことを特徴とする請求項９に記載の方法。
11. アプリケーションまたはリソース名の進化を追跡するステップをさらに含むことを特徴とする請求項９に記載の方法。
12. 前記ローカル名によって識別された前記リソースへのアクセスが、代替名前空間における異なるローカル名によって識別されるリソースに対して容易になりうるように、前記ローカル名を絶対名に変換することもできることを特徴とする請求項９に記載の方法。
13. 前記対象の名前空間を識別する前記ステップは、１つまたは複数の分散されたクエリを含むことを特徴とする請求項９に記載の方法。
14. 前記対象の名前空間についての少なくとも１つのクエリは、１つまたは複数のシステムに共通する名前空間を追跡する管理システムに対して行うことができることを特徴とする請求項１３に記載の方法。
15. 複数のソフトウェアアプリケーションおよびリソースの相互運用を制御するシステムであって、
    通信用のコンテキスト候補リストを生成するコンテキスト管理システムと、
    前記コンテキストのために定義された少なくとも１つのポリシーに従って前記候補リストを評価するポリシーエンジンであって、前記通信のために結果として生じたアクションおよび名前空間をさらに識別するポリシーエンジンと、
    前記通信を第１のアプリケーションから第２のアプリケーションまたはリソースに向ける仮想環境マネージャであって、前記識別された名前空間内の前記少なくとも１つのポリシーによって定義された通りに、前記結果として生じたアクションを示す指示を受信する仮想環境マネージャと
    を含むことを特徴とするシステム。

Images