スキーマに基づいて、分散コンピューティング環境内で分散コンピューティングシステムを実装する複数の命令を記憶した1つまたは複数のコンピュータ読み取り可能な記録媒体であって、前記スキーマは、前記分散コンピューティング環境内で実装される分散コンピューティングシステムモジュールの少なくとも1つの定義であって、第1の定義が、第2の定義から派生する場合に、前記第2の定義から設定制約および関係制約を継承するようにする、継承プロパティを有する少なくとも1つの定義と、前記分散コンピューティングシステムの前記モジュール間の可能性のある対話を識別する少なくとも1つの関係であって、前記スキーマが、前記定義および関係を修正する開発ツール、および前記定義および関係にしたがって前記モジュールを実装する展開ツールによって使用されるようにする、少なくとも1つの関係と、前記分散コンピューティング環境を妥当性検査する第1の妥当性検査についての、前記分散コンピューティングシステムによって使用される前記分散コンピューティング環境の少なくとも1つの要件と、前記分散コンピューティングシステムを妥当性検査する第2の妥当性検査についての、前記分散コンピューティング環境によって使用される前記分散コンピューティングシステムの少なくとも1つの要件とを備えたことを特徴とする1つまたは複数のコンピュータ読み取り可能な記録媒体。前記スキーマは、前記開発ツールのユーザが、前記少なくとも1つの分散コンピューティングシステムモジュールの所望の操作意図を識別するのを可能にすることを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの定義は、リソース定義、コンポーネント定義、およびエンドポイント定義を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの定義は、前記分散コンピューティングシステムモジュールの中に含まれるランタイムの挙動を指定するリソース定義を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの定義は、前記分散コンピューティングシステムの自己完結型かつ独立展開可能な部分を記述するコンポーネント定義を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの定義は、前記分散コンピューティングシステムモジュールによって開示された通信エンドポイントを記述するエンドポイント定義を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの関係は、2つまたは複数の分散コンピューティングシステムモジュールのエンドポイント定義間の少なくとも1つの可能性のある通信対話の形態であり、前記関係は、包含関係、委任関係、接続関係、ホスティング関係、および、参照関係の1つまたは複数を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの関係は、特定の定義が他の定義のメンバを包含できることを記述する包含関係を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの関係は、特定の定義に含まれるメンバを開示する委任関係を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの関係は、複数の定義間の利用可能な通信対話を識別する接続関係を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの関係は、複数の定義間の従属性を記述するホスティング関係を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。前記少なくとも1つの関係は、複数の定義間の順序付け関係を識別する参照関係を含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。分散アプリケーションのためのテンプレートに関連する抽象部分と、分散アプリケーションの特定の実装に関連する具象部分とをさらに含むことを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。複数の関係をさらに含み、前記スキーマは、前記複数の関係にわたって設定の通信を提供することを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。複数の関係をさらに含み、前記スキーマは、前記複数の関係にわたってアプリケーションランタイムの挙動情報の通信を提供することを特徴とする請求項1に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。コンピュータによって実行されると設計ツールを実装する複数の命令を記憶した1つまたは複数のコンピュータ読み取り可能な記憶媒体であって、前記設計ツールは、分散コンピューティング環境および分散コンピューティングシステムの仕様を抽象的に定義することを可能にするシステム定義モデルと、前記システム定義モデル内の機能動作モジュールをどのように指定すべきかを指示するスキーマとを備え、前記スキーマは、前記分散コンピューティング環境を妥当性検査する、前記分散コンピューティングシステムによって使用される前記分散コンピューティング環境の少なくとも1つの要件と、前記分散コンピューティングシステムを妥当性検査する、前記分散コンピューティング環境によって使用される前記分散コンピューティングシステムの少なくとも1つの要件とを備えることを特徴とする1つまたは複数のコンピュータ読み取り可能な記録媒体。前記設計ツールは、分散アプリケーション開発ツール、分散アプリケーション展開ツール、分散アプリケーション管理ツールのうちの1つであることを特徴とする請求項16に記載の1つまたは複数のコンピュータ読み取り可能な記録媒体。分散コンピューティング環境内で分散コンピューティングシステムのエンティティの定義をロードするステップと、分散コンピューティングシステムの前記エンティティ間の可能性のある対話を指定する関係をロードするステップであって、前記定義および前記関係が、前記分散コンピューティングシステムの開発中、妥当性検査中、展開中、および管理中に使用されるようにし、前記妥当性検査は、前記分散コンピューティングシステムの1つまたは複数の要件にしたがって、前記分散コンピューティング環境によって使用される前記分散コンピューティングシステムを妥当性検査するステップと、前記分散コンピューティング環境の1つまたは複数の要件にしたがって、前記分散コンピューティングシステムによって使用される前記分散コンピューティング環境を妥当性検査するステップとを備えるステップとを備えたことを特徴とする方法。前記定義は、リソース定義、システム定義、およびエンドポイント定義を含むことを特徴とする請求項18に記載の方法。前記関係は、包含関係、委任関係、通信関係、ホスティング関係、および参照関係を含むことを特徴とする請求項18に記載の方法。したがって、分散アプリケーションを物理的なコンピューティングシステム上で設計および展開するdeployための、改善された技法が必要とされている。本発明は、このような状況に鑑みてなされたもので、その目的とするところは、分散アプリケーションを分散コンピューティングシステム上で設計、展開、および管理することが可能な、分散コンピューティングシステムと、分散アプリケーションの自動化された設計、展開、および管理とのためのアーキテクチャを提供することにある。分散アプリケーションを分散コンピューティングシステム上で設計、展開、および管理するためのアーキテクチャおよび方法について述べる。以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。各図面を通して、同じ機構を参照する場合には同じ番号を使用する。以下の開示では、大規模なアプリケーションサービスを有する分散コンピューティングシステムを設計および実現するためのアーキテクチャに関連するいくつかの態様について述べる。この開示は、システム定義モデルSDMサービス定義モデルとも呼ばれると、SDMランタイム環境とに関する解説を含む。本開示はさらに、様々なデータセンタコンポーネントをどのようにモデル化するかといった設計側面も含む。本明細書では、用語配線を接続、通信または通信関係と言う場合もある。また、用語システムをモジュールと言い、用語リソース空間をリソースと言う場合もある。さらに、用語アプリケーション空間をアプリケーションと言い、用語インスタンス空間をインスタンスと言う場合もある。さらに、用語クラスを抽象定義と言い、用語ポートをエンドポイントと言い、用語型を定義と言う場合もある。図1に、例示的なネットワーク100を示す。ネットワーク100の設定では、複数xのコンピューティングデバイス1021、1022、...、102xがネットワーク106に結合されている。ネットワーク106は、様々な従来型のネットワークプロトコル公衆および/またはプロプラエタリプロトコルを含むを採用した、様々な従来型のネットワークトポロジおよびタイプ配線および/または無線ネットワークを含むのいずれかを表すものとする。ネットワーク106には、例えばローカルエリアネットワークLAN、ワイドエリアネットワークWAN、インターネットの一部、その他を含めることができる。ネットワーク100の設定は、例えばデータセンタ例えばインターネットデータセンタIDC、オフィスまたはビジネス設定、家庭設定、教育または研究施設、小売または販売設定、データストレージ設定などを含めた、幅広い設定のいずれかを表す。コンピューティングデバイス102は、デスクトップPCpersonalcomputer、ワークステーション、メインフレームコンピュータ、サーバコンピュータ、インターネット装置、ゲーム用コンソール、ハンドヘルドコンピュータ、携帯電話、パーソナルディジタルアシスタントPDAなどを含めた、様々な従来型のコンピューティングデバイスのいずれかとすることができる。1つまたは複数のデバイス102は、同じタイプのデバイスでもよく、あるいは異なるタイプのデバイスでもよい。さらに、複数のデバイスが同じタイプのデバイスである場合でも、複数のデバイスはなお、異なる形で構成することもできる例えば、2つのデバイス102はサーバコンピュータだが、異なるプロセッサ、異なる容量のランダムアクセスメモリRAM、異なるサイズのハードディスクドライブなど、異なるハードウェア構成を有することもできる。1つまたは複数のコンピューティングデバイス102は、ネットワーク100の設定に追加した後で再構成することもできる。例えば、特定のコンピューティングデバイス102が、ある期間にわたって例えば分、時間、日、月などの単位で動作して1つの機能を実施し、次いで管理者が、異なる機能が望ましいと決定することもできる例えば、サーバコンピュータからワークステーションコンピュータへの変更、ウェブサーバからローカルなファイルサーバへの変更。図2は、システム定義モデルを使用する例示的なアーキテクチャ200を示すブロック図である。SDMは、システムのライフサイクル全体にわたって使用されるように設計される。システムは、協働して共通の機能を達成することのできる関連するソフトウェアおよび/またはハードウェアリソースのセットである。このようなシステムの一例はアプリケーションであり、アプリケーションは、コンピューティングデバイスによって稼動または実行されて様々な機能を実施することのできる命令のセットを指す。アプリケーションの例としては、ゲームなどの娯楽アプリケーション、ワードプロセッサなどの生産性アプリケーション、電子百科辞典などの参照アプリケーション、ウェブサービスや財務分析に使用できる分散アプリケーションなどが挙げられる。このようなシステムの別の例は、アプリケーションまたは別の環境を展開することのできる環境である。環境は、アプリケーションまたは別の環境の展開先であるソフトウェアおよび/またはハードウェアリソースを指す。このような環境は、後でより詳細に論じるようにレイヤ化することができる。システムのライフサイクルは通常、3つの主要フェーズステージとも言うを含む。すなわち、設計または開発フェーズと、それに続く展開またはインストールフェーズと、それに続く運用または管理フェーズである。このモデルは、システムライフサイクルの3つのフェーズすべてに適用されるので、システムライフサイクルの様々なフェーズのための統合ポイントと見なすことができ、3つのフェーズのそれぞれを容易にする。さらに、このモデルを使用することにより、これらのフェーズの間で知識を移すことができる。知識は、システムの管理に関する知識例えば、設計開発チームが将来のバージョンのためまたは現バージョンの性能改善のためにシステムを修正できるように、設計開発チームにフィードバックされる知識や、システムの構造、展開要件、動作挙動の知識や、デスクトップからデータセンタへの動作環境の知識や、エンドユーザによって観察されたサービスレベルの知識などである。一般に、設計フェーズの間、SDMに影響を与える開発ツールを使用して、通信ソフトウェアおよびハードウェアコンポーネントからなるシステムを定義する。システム定義は、必要なリソース、構成、動作特徴、ポリシーなどを含めて、分散システムを展開および運用するのに必要なすべての情報を含む。展開フェーズの間、システム定義を使用してシステムを自動的に展開し、必要なソフトウェアおよびハードウェア例えばサーバ、ストレージ、およびネットワークリソースを動的に割り振り、構成する。同じシステム定義を、異なるホスト環境および異なる規模への展開に使用することができる。管理フェーズの間、オペレーティングシステム中のSDMサービスが、システムを管理するためのシステムレベルのビューを提供する。これにより、新しい管理ツールが、リソース割振り、構成管理、アップグレード、およびプロセス自動化をシステムの視点から推進することができる。アーキテクチャ200は、SDM定義モデルと、SDM定義モデル内の機能動作を定義するスキーマとを採用する。定義モデルは、異なる様々な種類のデータ構造を含み、これらは定義と総称される。SDMの機能は、アプリケーションプログラムインタフェースAPIなど、1つまたは複数のプラットフォームサービスを介して開示exposeされる。システムの設計フェーズの間、開発システム202が、SDM文書204のようなシステム定義を含む文書を生成する。開発システム202は、米国ワシントン州レドモンドのMicrosoft登録商標Corporationから入手可能なVisualStudio登録商標開発システムなど、様々な開発システムのいずれかとすることができる。SDM文書204は、システムの展開および管理に関係するすべての情報本明細書では知識とも言うを定義する。システムを展開または管理する際に必要なまたは使用されるどんな知識も、SDM文書204に含まれる。本明細書では知識を単一の文書として述べるが、別法として複数の文書に分散させて維持してもよいことを理解されたい。SDM文書204は、システムが展開および/または実行されることになる環境が満たさなければならない1つまたは複数のシステム制約要件とも言うを含む。環境自体も、SDM文書を使用して記述される。このような環境は、単一のコンピューティングデバイスとすることもでき、あるいは、コンピューティングデバイスの集合例えばデータセンタ、アプリケーションホストの集合などとすることもできる。異なるシステムを異なる環境にインストールすることができる。例えば、データセンタが50台のコンピューティングデバイスを含む場合に、あるシステムをこれらのコンピューティングデバイスのうちの5台に展開し、別のシステムをこれらのコンピューティングデバイスのうちの35台に展開することができる。これらの要件は、次のような様々な形をとる可能性がある。すなわち、システムの展開先であるコンピューティングデバイスに関するハードウェア要件例えば最低プロセッサ速度、最低メモリ容量、最低ハードドライブ空き容量、利用可能なネットワーク帯域幅の最低量、利用可能な特定のセキュリティ機構などや、システムの展開先であるコンピューティングデバイスに関するソフトウェア要件例えば特定のオペレーティングシステム、共にインストールしなければならない1つまたは複数の他のアプリケーション、特定のシステムおよび/またはオペレーティングシステムをどのように構成するかに関する指定、使用される特定タイプのセキュリティまたは暗号化などや、システムの展開先であるコンピューティングデバイスに関するその他の要件例えば利用可能なセキュリティ鍵、施行しなければならないデータセンタポリシー、使用される認証、環境トポロジなど等である。要件は別な方向に向かう可能性もある。すなわち、環境が、インストールされるシステムの構成に対して制約または要件を有する可能性もある例えば環境の基準またはポリシーを実施するため。これらは、環境のオペレータによって生み出される明示的な要件とすることができ、システムが有さなければならない特定の設定または構成や、システムが提供またはサポートしなければならない特定の機能や、システムがサポートしなければならない特定のセキュリティ機構などである。これらはまた、環境の特定の構成によって生じる暗黙的な要件とすることもできる。例えば、環境中のホストコンピューティングデバイスが特定タイプのファイルシステムを使用している場合に、このファイルシステムを使用して実施することができないアクションがある場合がある別のファイルシステムを使用すればこれらのアクションを実施することができるにもかかわらず。システムの設計および開発フェーズの間、SDM文書204を使用して、1つまたは複数の特定の環境についてシステムを妥当性検査することができる。これは両方向の妥当性検査である。すなわち、システムを環境について妥当性検査し、環境をシステムについて妥当性検査する。環境をシステムについて妥当性検査することは、SDM文書204中で識別される要件を環境と比較して、すべての要件が環境によって満たされるかどうかを決定することによって行うことができる。システムを環境について妥当性検査することは、SDM文書中で環境に関して識別される要件をシステムと比較して、すべての要件がシステムによって満たされるかどうかを判定することによって行うことができる。すべての要件が環境およびシステムによって満たされる場合、設計者または開発者には、システムをこの環境で展開できること、およびシステムがこの環境で実行されることがわかる。しかし、すべての要件が環境および/またはシステムによって満たされない場合は、設計者または開発者には、任意選択で、満たされなかった要件が通知され、それにより、システムをこの環境で展開して実行するためにどんな変更をSDM文書204にかつそれに対応してシステムにおよび/または環境に加えるべきかが通知される。SDM文書204に含まれるシステム展開に関する知識は、システムをどのように1つまたは複数の環境で展開するかを記述する。SDM文書204は、コントローラ206に利用可能とされ、コントローラ206は、展開モジュール208および管理モジュール210を備える。ある実施形態では、SDM文書204、ならびにシステムをインストールするのに必要なシステムファイルすべて例えばバイナリ、データ、ライブラリなどは、SDUシステム定義ユニットと呼ぶ単一のコンテナ例えば単一のファイルに共にパッケージされる。コントローラ206は、図1のコンピューティングデバイス102の1つまたは複数とすることができる。例えば、図1の単一のデバイス102が特定のデータセンタ用のコントローラであってもよく、あるいは、コントローラの任務は複数のデバイス102に分散されてもよい。展開モジュール208は、システムを環境中に展開するのに使用されるサービスを含む。図2では、システムが展開される環境は、1つまたは複数のターゲットデバイス212であるまたはこれらのデバイス上に展開されている。システムはまた、コントローラ206に展開することもできる。展開モジュール208のこれらのサービスには、1つまたは複数のシステムを環境中にインストールまたは展開するために呼び出すことのできる1つまたは複数の関数が含まれる。SDM文書204には、異なる環境で展開するための異なる知識を含めることができる。この展開知識は、環境中で行う必要のある任意の変更例えば、システムレジストリ、作成する必要のあるフォルダ、ディレクトリ、またはファイル、特定の値に設定する必要のある、コンピューティングデバイスのその他の設定パラメータまたは構成パラメータなどの変更、ならびに、環境中でどのファイル例えばプログラムファイルおよび/またはデータファイルをコンピューティングデバイスにコピーする必要があるか、またこれらのファイルに対して実施する必要のある任意の操作例えば圧縮解除および/または暗号化解除が必要なファイルもあるを記述する。多くの実装形態では、SDM文書204中の展開知識は、例えば、システムのための通常のセットアッププログラムまたはインストールプログラム中に現在みられるような情報に類似する情報を含む。展開プロセスの間、コントローラ206は、展開に関与するソフトウェアおよびハードウェアリソースの、ならびにこれらの関係の、記録または記憶を生成する。この記録または記憶は、後で管理フェーズの間にコントローラ206が使用することができる。管理モジュール210は、システムが環境にインストールされた後でシステムを管理するのに使用されるサービスを含む。サービス管理モジュール210のこれらのサービスには、環境中でシステムを管理するために呼び出すことのできる1つまたは複数の関数が含まれる。SDM文書204に含まれるシステム管理に関する知識は、システムをどのように1つまたは複数の環境で管理するかを記述する。SDM文書204には、システムを異なる環境で管理するための異なる知識を含めることができる。管理知識には、システムの管理または運用で使用される任意の知識が含まれる。管理には、例えば、構成および任意選択で後の再構成、パッチおよびアップグレード、保守作業例えばバックアップ、ヘルス監視または性能監視などが含まれる。展開されたシステムに対する変更は、管理モジュール210を介して行う。管理モジュール210のサービスには、環境中に展開された1つまたは複数のシステムに変更を加えるために呼び出すことのできる1つまたは複数の関数が含まれる。管理モジュール210を介してこれらの変更を行うことにより、いくつかの利点を実現することができる。このような利点の1つは、加えられた変更の記録をコントローラ206が維持できることである。コントローラ206は、システムについてのSDM文書204のコピーを維持し、システムに加えられたどんな変更もSDM文書204に記録することができる。あるいはコントローラ206は、システムに加えられた変更に関する別個の記録を維持してもよい。コントローラ206によって維持されるこの変更記録は、システムおよび/または環境に関する問題を解決するときや、ハードウェア障害によりシステムを再インストールしなければならないときシステムを再インストールして障害時と同じパラメータ/設定で稼動するよう元に戻せるようにするなどに、後続の操作を単純化することができる。コントローラ206によってこのような変更が行われるようにすることにより、またコントローラ206が記録を維持するようにすることにより、いくらかの人為的ミスを環境からなくすことができる例えば、変更を行う管理者が変更を帳面に記録することになっているのにそうするのを忘れた場合、この変更の記録はないことになる。この問題は、コントローラ206に記録を維持させることによって解決する。さらに、コントローラ206を介してシステムに変更を加えることにより、またコントローラ206を介してシステムを展開することにより、コントローラ206は、環境と、環境中に展開されるシステムと、これらの間の対話とに関する知識のリポジトリとして働くことができる。環境および/または環境中に展開されるシステムに関する知識は、コントローラ206から容易に得ることができる。この知識を使用して、中央のコントローラ206に記憶されている状態を環境中の被制御デバイスが反映していることを妥当性検査することにより、被制御環境の一貫性を保証することができる。状況によっては、コントローラ206を介さずに、システムおよび/または環境に変更が加えられる場合もあることに留意されたい。例えば、コンピューティングデバイスが誤ってオフにされたり、作動しなくなったりすることがある。これらの状況では、このような変更をコントローラ206中に反映させるよう試みる。これらの変更は、自動的にコントローラ206中に反映させることもでき例えば、デバイス障害を検出して、このような障害を管理モジュール210のサービスを使用してコントローラ206に通知するシステムを稼動させることができる、あるいは手動でコントローラ206中に反映させることもできる例えば、管理者が管理モジュール210のサービスを使用して、このような変更をコントローラ206に通知することができる。あるいは、加えられた変更を元に戻し、システムおよび/または環境の一部を、コントローラ206によって記録された所望のシステム状態と再び一致させることもできる。したがって、SDM文書204は、生きた文書と見なすことができる。すなわち、環境の変化および/またはシステムの変化に基づいて、システムのライフサイクルを通して継続的に変化することができる。システム定義モデルSDMシステム定義モデルSDMは、システムの定義を生み出すのに使用されるモデル化技法である。システムは、協働して共通の機能を達成する関連するソフトウェアおよび/またはハードウェアリソースのセットである。例示的なシステムには、多層LOBline-of-businessアプリケーション、ウェブサービス、電子商取引サイト、および企業データセンタが含まれる。SDMは、アプリケーション構築者、ネットワーク構築者、データセンタ構築者、またはその他の開発者が分散コンピュータアプリケーションおよびデータセンタを抽象方式で設計するためのツールおよびコンテキストを提供する。SDMは、物理的なコンピュータリソースおよびソフトウェアによって最終的に実現されることになるシステムの機能単位を表す要素のセットを定義する。SDMはまた、システムを管理することになるオペレータまたはその他の個人に関係する要素も定義する。さらにSDMは、開発、展開、および運用に関係するデータも取り込む。SDM要素には、コンポーネントによって表される機能動作をどのように指定すべきかを指示するスキーマが関連する。システムは、リソース、エンドポイント、関係、およびサブシステムで構成される。これらの各項目の定義が、SDM文書中で宣言される。SDM文書は、システム、リソース、エンドポイント、および関係についての1つまたは複数の定義を含むXMLExtensibleMarkupLanguage文書である。リソースは、ハードウェアリソースまたはソフトウェアリソースとすることができる。エンドポイントは、システムを越えた通信を表す。関係は、システム、リソース、エンドポイントの関連を定義する。サブシステムは、完全なシステムとして扱うことができ、通常はより大きいシステムの一部である。システム定義は、動的システムの基本構造を取り込む。これは、他のすべての情報がその上に追加される骨格と見なすことができる。この構造は一般に、開発プロセスの間に設計者および開発者によって指定され、通常は頻繁に変更されることはない。構造の他に、SDMは、展開情報、インストールプロセス、構成やイベントや計測のためのスキーマ、自動化タスク、ヘルスモデル、運用ポリシーなども含むことができる。分散システムの存続期間を通して、運用スタッフ、ベンダ、および/または管理システムがその他の情報を追加することができる。SDMスキーマ設計仕様SDMは、分散システム例えばモデル化システム中のコンポーネントの構成、対話、および変更の記述descriptionをサポートするように設計される。定義definitionが、システム中に存在するエンティティを記述し、関係relationshipが、様々なエンティティ間のリンクを識別する。定義および関係はさらに、SDMに関連するセマンティック情報を取り込むように定義される。図3に示すように、SDM定義302は、リソース定義304、コンポーネント定義306、エンドポイント定義308という3つのサブ定義を含む。図4に示すように、SDM関係402は、包含関係404、委任関係406、接続関係408、ホスティングhosting関係410、参照関係412という5つのサブ関係を含む。接続関係408は、通信関係と呼ばれる場合もある。定義および関係に関するこれ以上の詳細は後で提供する。SDMは抽象定義を含む。これは、システムの各部分の共通範疇化と、幅広いアプリケーションのためのツールサポートと、設計時の定義チェックのための基盤とを提供する。抽象定義のセットは、サービス設計のための包括的な基盤を提供する。具象定義が、実際のアプリケーション設計またはデータセンタ設計の各部分を表す。具象定義の生成は、抽象定義を選択し、具象定義のメンバとそのプロパティの設定値とを定義する実装を提供することによって行う。分散アプリケーションは、これらの具象定義の集合を使用して生成する。SDMは制約も含む。制約は、関係のインスタンスが参与することのできる許容される関係のセットに基づく制限をモデル化する。制約は、関係に関与するオブジェクトの構成に応じた要件を記述する際に有用である。例えば、制約を使用して、通信プロトコルの両端の参与者が互換性のあるセキュリティ設定を使用しているかどうかを判定することができる。定義および/またはリソースの一部として、フローを識別することができる。このフローを使用して、オペレータ設定をシステム、サブシステム、またはこのような設定を利用する他のコンポーネントに伝搬させることによって、ランタイム時のアプリケーション挙動を制御する。抽象定義および抽象関係抽象定義は、設計時にアプリケーション構成をチェックしてからランタイム時にアプリケーションを展開および管理する構成単位を定義する。これらの構成単位は、モデル化システム中に存在するエンティティを表す。例えば抽象定義は、ファイルおよびディレクトリ、ウェブサーバ内部の構成、またはSQLStructuredQueryLanguageサーバ内部のデータベースをモデル化することができる。抽象関係は、抽象定義間で行うことのできる対話をモデル化する。関係は、バイナリおよび有向であり、関係の発現に参与するインスタンスの定義を識別する。関係は、エンティティを相互に関連付ける方法を提供し、それにより、エンティティ間の包含、構築、通信のリンクをモデル化することを可能にする。定義が制約を使用して、定義の参与する関係を制約する。さらに、関係が制約を使用して、リンクすることのできる定義を制約する。これらの制約は、関係への参与者の定義および設定をターゲットにすることができる。抽象定義空間は、コンポーネント、エンドポイント、リソースという3つのカテゴリに分けられる。抽象コンポーネント定義は、アプリケーションの自己完結型かつ独立展開可能な部分を記述する。これらの定義は、プロセスおよびマシンの境界を横断することのできる明確に定義された通信チャネルを介して対話するアプリケーション部分を表す。抽象エンドポイント定義は、コンポーネントが開示することのできる通信エンドポイントを記述する。これらの抽象エンドポイント定義は、設計時にシステム接続性を検証するためおよびランタイム時に接続を可能にするために、システムが意識しているすべての形の通信をモデル化することができる。抽象リソース定義は、コンポーネント内に含まれる挙動behaviorを記述する。リソース定義は、他のリソース定義への強力な従属性を有することができる。これらの従属性には、特定のインストール順序を必要とすることや、様々な通信機構を介したランタイム対話を開始することを含めることができる。抽象定義は、設定を開示するexpose能力を備える。一実施形態では、これらの設定は、名前と値の単純な対であり、XMLスキーマを使用して設定の定義を定義する。設定は動的としても静的としてもよい。静的設定は、展開プロセスの間にわたり設定される。動的設定は、展開後に変更することができる。実行中のシステムに設定値を適用することを担うコードは、SDMランタイム中でホストされる。SDMモデルは、抽象定義を越えた継承をサポートする。派生した定義は、その親によって開示されたプロパティを拡張することができ、その親のプロパティに関する値を設定することができる。派生した定義は、その親を参与者として識別する関係に参与することができる。前述のように、関係は、通信または接続、包含、委任、ホスティング、参照という5つのカテゴリに分けられる。通信関係は、抽象エンドポイント定義間の可能性ある通信対話を取り込む。通信関係があることは、識別された定義のエンドポイントを開示しているコンポーネントが通信することが可能かもしれないことを示す。実際のリンク確立は、エンドポイントおよびエンドポイントの開示exposureに対する制約を受ける。包含関係は、抽象定義が他の抽象定義のメンバを含むことができることを記述する。より具体的には、2つの抽象定義AとBの間の包含関係では、Aを実装する具象定義が、Bを実装する定義のメンバを含むことができる。包含関係は、開発者がアプリケーションを構築するときに生じる自然なネスト構造をモデル化する。別の定義のメンバを含めることにより、親は、含まれる定義の存続期間および可視性を制御することができる。ランタイム空間中のすべての定義インスタンスは、他の定義インスタンスのメンバとして存在し、完全に接続されたインスタンスセットを形成する。したがって、包含関係のセットは、ランタイム空間で生じる許容される包含パターンを記述する。委任関係は、含まれるメンバを選択的に開示する。例えば委任は、コンポーネント定義からのエンドポイントメンバを開示することができる。内側のコンポーネントからエンドポイントを委任することにより、外側のコンポーネントは、特定のプロトコルを使用して、プロトコルの奥にある実装を開示することなく通信する能力を呈する。ホスティング関係および参照関係は、従属関係の2つの形を表す。ホスティング関係は、特定ホスト上に定義のインスタンスをどのように生成するかに関する知識を取り込むのに使用する。ホスティング関係により、開発者は、特定ホストの動作から独立した方式で自分自身の定義を生成することができる。この関係ではまた、ゲスト定義を書き換えずに単一の定義を複数のホストタイプ上に展開することができる。ホスティング関係は、具象定義のインスタンスが生成される前に存在する抽象定義間の主要な従属性を記述する。各インスタンスは、ホスティング関係にゲストとして参与し、それによりホスティング関係は、完全に接続されたツリーをインスタンス空間にわたって形成する。参照関係は、パラメータフローおよび構築順序付けに使用される追加の従属性を取り込む。具象定義および具象関係抽象定義から具象定義を構築する。抽象関係から具象関係を構築する。抽象定義と抽象関係の組合せは、ターゲットシステムをモデル化するためのスキーマを定義する。具象定義は、抽象定義空間のサブセットを使用して、1つまたは複数の抽象定義の再使用可能な構成を生み出す。抽象定義空間は、データベースに関するスキーマに例えることができる。この類比では、具象定義空間は、データベース中の行のセットのための再使用可能テンプレートを表す。データベース中の行をスキーマの制約例えば外部キーなどに対して妥当性検査するのと同じようにして、具象定義を抽象定義空間に対して妥当性検査する。開発者は、抽象定義の知識から具象定義の知識を推論することができる。したがって、抽象定義に関連するツールが、抽象定義から派生する多くの実装と共に動作することができる。例えば、抽象ウェブサービスについて知っているツールが、開発者からの追加の情報を必要とせずに、データセンタ中に展開された任意のウェブサービスと共に動作することができる。各具象定義は、特定の抽象定義に対する実装を提供し、実装は、設定スキーマに対する拡張と、設定に関する値と、定義メンバおよび関係メンバに関する宣言と、定義が参与することのできる関係に対する制約とを含む。具象定義の挙動は、抽象定義の定義に従う。具体的には、抽象コンポーネント定義がコンポーネント定義になり、抽象エンドポイント定義がエンドポイント定義になり、抽象リソース定義がリソース定義になる。各具象関係は、特定の抽象関係に対する実装を提供し、実装は、設定スキーマおよび設定値と、同じ関係カテゴリホスティング、包含、通信などのネストされたメンバと、関係に参与することのできる定義に対する制約とを含む。具象ホスティング関係は、ある具象定義のメンバを別の具象定義上にマッピングすることのできるホスティング関係のセットを定義する。例えば、具象ホスティング関係は、ウェブアプリケーションとそれが展開されることになるIISInternetinformationservice商標ホストとの間のバインドを識別することができる。特定の定義に対して複数の具象ホスティング関係が存在することができ、これにより開発者は、特定のトポロジに対して複数の展開deploymentを定義することができる。具象定義は、他の具象または抽象定義のメンバを宣言することができる。これらを定義メンバと呼ぶ。この場合、これらの定義メンバは、定義メンバ間の関係を定義する関係メンバから参照される。定義メンバは、特定の定義のインスタンスへの参照を含む。設定フローが、定義に関する値を提供することができ、あるいは、定義を生成するときに使用される構築パラメータを制約することができる。定義メンバを宣言するとき、ユーザ例えば開発者は、定義メンバが、外側のコンポーネントが生成されるのと同時に生成されるか値セマンティクスと呼ばれる、あるいは後で行われる新しい明示的動作によって生成されるか参照セマンティクスと呼ばれるを決定することができる。関係メンバは、定義メンバが生成されたときにそれらが参与することになる関係を定義する。定義メンバが具象定義に含まれる場合は、包含関係メンバを、定義メンバと外側の定義に対するこの参照との間で宣言する。定義メンバが委任される場合は、委任関係メンバを、定義メンバとネストされる定義メンバとの間で定義する。通信関係メンバは、定義メンバ上のエンドポイント間で宣言することができ、従属関係メンバ参照およびホスティングは、定義メンバまたはネストされる定義メンバ間で宣言することができる。関係制約は、特定の定義が参与を望む関係のセットを限定する。関係制約は、特定の関係に対する制約、および関係の他方の端の参与者に対する制約を識別する。インスタンス空間SDMランタイムに記憶されているインスタンス空間は、モデル化システムの現在状態を識別する。SDMランタイムは、生成されたインスタンスと、これらのインスタンス間の関係との記録を含む。各インスタンスにはバージョン履歴が関連し、バージョン履歴は、各バージョンを変更要求にリンクする。変更要求は、新しいインスタンスを生成するプロセスである。変更要求は、既存のインスタンスの特定メンバに関連する定義および関係に対する、生成、更新、削除要求のセットを定義する。ルートは特別なケースとして扱われる。変更要求は、ランタイムによって展開され、1つまたは複数の制約に対して検証されてから構築される。展開プロセスでは、含んでいる定義の構築要求の一部として暗黙的に構築される定義インスタンスおよび関係インスタンスを識別する。展開プロセスの一部として、設定フローをすべての関係にわたって評価する。検証ステップでは、必要な関係がすべて存在すること、および関係が必要な制約を満たすことをチェックする。最後に構築プロセスでは、各インスタンスの展開、更新、または削除にわたる適切な順序付けを判定する。次いで構築プロセスでは、適切なアクションが実施されるように、各インスタンスを正しいシーケンスでインスタンスマネージャに渡す。データセンタは、複数のソフトウェアコンポーネントを使用して生み出すことができる。複数のソフトウェアコンポーネント間で、1つまたは複数の接続を構成する。これらのソフトウェアコンポーネントのいくつかは、アプリケーションレイヤに関するホストとして機能することができる。ホストレイヤ中の例示的なコンポーネント定義としては、IIS商標、SQL、AD、EXCHANGE、DNSDomainNameSystem、BizTalk商標が挙げられる。ネットワーク/OSoperatingsystem/ストレージレイヤは、データセンタネットワークおよびプラットフォームの構築をサポートする。このレイヤはまた、ネットワークセキュリティモデルの構成、オペレーティングシステムプラットフォームの構成、および、1つまたは複数の記憶デバイスとオペレーティングシステムプラットフォームとの関連付けもサポートする。ネットワーク/OS/ストレージレイヤ中の例示的なコンポーネント定義としては、VLAN、Windows登録商標、Filter、Storageが挙げられる。ハードウェアレイヤは、データセンタに存在するシステムの定義、およびこれらのシステム間に存在する物理接続を識別する。特定のコンポーネントに必要な関係を満たすために、このコンポーネントを、マッチする機能を有するホストコンポーネントにバインドする。このプロセスを論理配置logicalplacementと呼ぶ。展開時、ゲストコンポーネントのインスタンスを、ホストコンポーネントのインスタンス上に配置する。このプロセスを物理配置physicalplacementと呼ぶ。図5に、ウェブアプリケーション502をウェブサーバホスト504にマッピングする例を示す。破線506で識別される境界が、アプリケーションレイヤをホストレイヤから分離している。ウェブアプリケーション502は、リモーティングサービスエンドポイント508、ウェブサービスエンドポイント510、およびウェブユーザインタフェースエンドポイント512を含み、これらはすべて、ウェブサーバ504中のウェブサイト522にマッピングする。さらに、ウェブアプリケーション502中の仮想ディレクトリ516が、ウェブサイト522にマッピングする。ウェブアプリケーション502はコンシューマエンドポイント514も含み、コンシューマエンドポイント514は、ウェブサーバ504中のコンシューマエンドポイント524にマッピングする。ウェブアプリケーション502のアセンブリ部分518が、ウェブサービス504のランタイム部分528にマッピングする。ウェブアプリケーション502中のコンテンツディレクトリ520が、ウェブサーバ504中のウェブルートディレクトリ526にマッピングする。SDMモデルには、分散システムに対する変更を管理するプロセスが関連する。分散システムに対する変更は、1つまたは複数の処理ステップを経た変更要求によって進められ、その後、要求の中の動作が配信され、ターゲットシステムに対して実行される。図6に、SDMランタイムを使用する例示的なアーキテクチャ600を示す。アーキテクチャ600は、図2のアーキテクチャ200の一例であり、SDMランタイム610と、後で例示的なSDM実装形態の章で論じるSDMの例示的な実装形態とを使用する。SDMランタイム610は、SDMファイルを受領して妥当性検査し、SDUシステム定義ユニット。1つまたは複数のSDMファイルおよびそれらに関係するファイルのパッケージをロードし、SDM変更要求を生成して実行し、SDMベースのシステムをターゲット環境に展開するための、コンポーネントおよびプロセスのセットを含む。このランタイム機能により、SDMを使用して記述されたシステムを定義および妥当性検査し、コンピューティングデバイスのセットに展開し、管理することができる。SDMは、後で例示的なSDM実装形態の章でより詳細に論じるが、分散システムモデル化システム中のコンポーネントの構成、対話、および変更の記述descriptionをサポートするように設計される。SDMは、オブジェクト関係relationalモデルに基づく。定義が、システム中に存在するエンティティを記述し、関係relationshipが、様々なエンティティ間のリンクを識別する。定義および関係はさらに、SDMに関連するセマンティクス情報を取り込むように定義される。具体的には、定義はコンポーネント、エンドポイント、リソースに分けられる。関係は、接続通信とも言う、包含、ホスティング、委任、参照に分けられる。定義および関係に関するこれ以上の詳細は後で提供する。SDMは抽象定義を含む。これは、システムの各部分の共通範疇化と、幅広いシステムのためのツールサポートと、設計時の定義チェックのための基盤とを提供する。抽象定義のセットは、サービス設計のための包括的な基盤を提供する。具象定義が、実際のシステム設計またはデータセンタ設計の各部分を表す。具象定義の生成は、抽象定義を選択し、具象定義のメンバとそのプロパティの設定値とを定義する実装を提供することによって行う。分散アプリケーションは、これらの具象定義の集合を使用して生成する。SDMは制約constraintも含む。制約は、関係のインスタンスが参与することのできる許容される関係のセットに基づく制限をモデル化する。制約は、関係に関与するオブジェクトの構成に応じた要件を記述する際に有用である。例えば、制約を使用して、通信プロトコルの両端の参与者が互換性のあるセキュリティ設定を使用しているかどうかを判定することができる。ターゲットシステムに対する変更を実施するために、SDMは、変更要求またはCRと呼ばれる、必要とされる変更の宣言記述を使用する。SDMは、SDM実行モデルの一部として変更要求を展開expand、妥当性検査、および実行するのに使用されるプロセスを定義する。インスタンス空間は、管理されるアプリケーションの所望状態と現在状態の両方を取り込む。インスタンス空間中の変更は、追跡され、その変更を開始した変更要求に関連付けられる。インスタンス空間は、SDMランタイム内に記憶され、モデル化システムの現在状態を反映する。ランタイムは、生成されたインスタンスと、これらのインスタンス間の関係との完全な記録を含む。各インスタンスにはバージョン履歴が関連し、バージョン履歴中では、各バージョンが変更要求にリンクされている。新しいインスタンスを生成するプロセスは、変更要求によって開始される。変更要求は、既存のインスタンスの特定メンバに関連する定義および関係に対する、生成、更新、削除要求のセットを定義する。以下は、図6のコンポーネントがどのように協働するかについての簡単な機能上の解説である。オペレータまたは管理者が、データセンタのトポロジなど、アプリケーションを展開deployできる環境を記述することができる。オペレータまたは管理者は、環境を記述するSDMファイルを作成するが、このファイルは、論理インフラストラクチャLIM602、あるいはデータセンタ記述またはデータセンタモデルと呼ばれる。このSDMファイルは、米国ワシントン州レドモンドのMicrosoft登録商標Corporationから入手可能なVisualStudio登録商標開発システムなど、様々な開発システムのいずれかを使用して生成することができる。さらに、アプリケーション開発者は、VisualStudio登録商標開発システムなどの様々な開発システムのいずれかを使用して、自分のアプリケーションを設計および開発することができる。開発者は、アプリケーションのコンポーネントと、これらのコンポーネントがどのように相互に関係するかを定義するので、アプリケーション記述をデータセンタ記述602に対して妥当性検査することができる。これを設計時妥当性検査とも呼ぶ。アプリケーションが完成すると、開発者は記述をSDMに保存し、アプリケーションがSDU604として展開されるようにアプリケーションのパッケージングを要求する。SDUは、アプリケーションSDMと、アプリケーションをインストールするのに使用されるアプリケーションバイナリおよびその他の参照ファイルとを含む。LIM602およびSDU604は、展開deploymentに向けて、コントローラデバイス620の展開ツール606に供給される。展開ツール606は、オペレータが所望のSDU604をロードできるようにするためのユーザインタフェースUIを備える。展開ツール606は、CR生成モジュール630と協働して、SDU604に関連するアプリケーションを、SDU604内のSDM中の情報に従ってインストールする。さらに、SDU604からのSDM定義およびインスタンスが、SDMランタイム610のSDM記憶域store608にポピュレートされる。SDUは、SDMランタイム610中でSDU管理モジュール640によって管理され、SDU管理モジュール640は、ランタイム610の他のコンポーネントおよびターゲット622がSDUの適切な部分を利用できるようにする。オペレータはまた、展開中のアプリケーションの展開先であるターゲット622例えばターゲットコンピューティングデバイスに対してオペレータがどんなアクションを取りたいかを指定することができる。オペレータは、展開ファイルを介してこれを行うことができ、この展開ファイルは、本明細書では変更要求CRとも呼ばれる。CRは、1つまたは複数のエンジン612、614、616、618を通して実行される。一般に、CR展開エンジン612は、CRを展開して、関連するすべてのコンポーネントならびにそれらの接続およびアクションを識別する。値フローエンジン614は、コンポーネントに関する値接続ストリングなどをフローする。制約チェックエンジン616は、環境とアプリケーションとの間の制約をチェックする。アクション順序付けエンジン618は、CRに関する必要なすべてのアクションの順序を指定する。システムに対する変更アプリケーションの展開を含む、またはモデルの妥当性検査を開始するために、オペレータまたはプロセスは、CRをサブミットsubmitする。CRは、オペレータがランタイム610中のインスタンスを介して実施したいアクションのセットを含む。これらのアクションは、例えば生成アクション、更新アクション、および/または削除アクションとすることができる。ユーザまたはオペレータによって開始される変更要求に加えて、展開/自動生成の変更要求があるものとすることもでき、これは、後でより詳細に論じる展開プロセスの一部として生成される。変更要求は、そのソースにかかわらず、完全に展開されチェックされた後で、ターゲットインスタンスの発見、インストール、アンインストール、変更などのアクションをターゲット622に送ることによって実行される。CRは、グループとして完了または失敗する原子アクションセットとして扱われる。これにより例えば、制約チェックエンジン616は、妥当性をテストするときにすべてのアクションを考慮することができる。設計時妥当性検査では、CRは、SDMコンパイラ628によって生成され、SDMファイル中の各SDMコンポーネントの1つまたは最小限を含むことになる。この、インスタンス生成コマンドのCRは、CR展開エンジン612、値フローエンジン614、および制約チェックエンジン616の中をフローする。この3つのフェーズで見つかったエラーは、ユーザが使用している開発システムを介してユーザに返される。展開時は、オペレータは、展開ツール606によって提示されるUIuserinterfaceでCRを生成する。CRは、SDMランタイム610中のすべてのエンジン612、614、616、618の中をフローし、適切なアクションおよび情報がCR実行モジュール632から適切なターゲット622に送られ、ターゲット622で要求が実行される例えばアプリケーションがインストールされる。特定のインストールの場合の適切なターゲット622は、通常、アプリケーションがインストールされることになるターゲットである。CRの処理を開始する際、定義解決フェーズで、CR生成モジュール630は、変更要求の中で参照されるすべての定義およびメンバを解決する。変更要求は、これらがすでにランタイム610によってロードされていると見なす。これらが存在しない場合は、CR生成モジュール630はロード/コンパイルアクションを開始する。CR生成モジュール630はパス解決フェーズも実施し、変更要求内の、既存のインスタンスおよび生成アクションによって定義されたインスタンスへの参照を解決する。CR展開エンジン612によって実施される展開は、所与の変更要求について、この要求を実行するのに必要な残りのすべてのアクションをポピュレートするプロセスである。一般にこれらのアクションは、定義インスタンスおよび関係インスタンスに対する構築constructionアクションおよび破壊destructionアクションである。オペレータは任意選択で、インスタンスを構築または破壊するのに必要なすべてのアクションに関する詳細を提供することもでき、あるいはこのプロセスの一部は自動化することもできる。例えばオペレータは、メンバ例えばbyReferenceメンバに対するアクションを識別することにより、オペレータが望む変更に関するキー情報を提供する。すると、ネストされたメンバ例えばbyReferenceメンバおよびbyValueメンバと関係に対して、アクションの残りが埋められる。別の例として、自動化された展開は、外部リソースマネージャを参照することもでき、外部リソースマネージャは、利用可能なリソースを有するデバイスを選択することや、それが必要とするデータに近いアプリケーションを突き止めることなどに基づいて、展開決定を行うことができる。CR展開エンジン612は、自動記述writingも実施する。自動記述の間、CR展開エンジン612は、SDM中で指定されているコンポーネントおよび複合コンポーネントのスケール不変のグループ化を分析し、コンポーネントが要求のレベルにスケールされたときにコンポーネントがどのようにグループ化され相互接続されるべきかを判定する。CR展開エンジン612は、値valueメンバ展開、参照referenceメンバ展開、および関係展開も実施する。値メンバ展開は、すべての非参照定義メンバを識別することを指す。これらのメンバのカーディナリティcardinalityが示され、必要なパラメータはすべてわかるので、各メンバごとに、親の生成中であるメンバについては生成要求が変更要求に追加される。変更要求が破壊動作を含む場合は、それらに含まれるすべてのインスタンスについて破壊動作が追加される。参照メンバ展開は、参照メンバを指す非参照定義メンバとは反対に。参照メンバのカーディナリティはしばしば未定義であり、参照メンバは、インスタンスが構築されるための値を必要とする展開時設定を有する可能性がある。したがって、参照メンバ例えばbyReferenceメンバを展開するプロセスは、インスタンスに関する情報として、ランタイムが提供できるよりも多くの情報を必要とする可能性がある。参照メンバ展開には、発見と呼ばれるプロセスが関係するが、これは、すでに展開されたインスタンスを見つけるのに使用されるプロセスである。発見は、通常は環境のオペレータによって開始されるアクションである。例えばインストール要求の間、CR展開エンジン612は、インスタンスがすでに存在するかどうかを判定し、存在する場合は何が存在するかを判定し、存在しない場合はそれを生成する。コントローラ620上のインスタンスマネージャIM634が、ターゲットデバイス622上のインスタンスマネージャ626と通信して、発見プロセスを開始する。発見プロセスは、インスタンスに関するデータをターゲットデバイス622からコントローラ620に返す。発見のプロセスは、構築または更新アクションの一部として参照定義メンバをポピュレートする。通常、発見をサポートするオブジェクトマネージャ発見を実施もするインスタンスマネージャに関する参照メンバだけが、このプロセスに参与する。新しいインスタンスが発見されたときは、インスタンス特有のキー値を使用して、このインスタンスがまだSDMデータベース中に存在しないことをチェックする。新しいインスタンスであることがわかれば、発見されているメンバの定義に従ってインスタンスを分類する。インスタンスがメンバにマッチしない場合、または曖昧なマッチがある場合は、メンバ参照は空白のままにされ、インスタンスはオフラインおよび不完全としてマークされる。関係展開は、構築されることになる定義インスタンスがすべてわかった後で、定義インスタンスを共にバインドする関係インスタンスを生成することを指す。定義インスタンスの破壊中である場合は、定義インスタンスを参照するすべての関係インスタンスを削除する。関係を生成するには、メンバ空間を使用して、インスタンス間に存在すべき関係の構成を識別する。定義メンバが1よりも大きいカーディナリティを有する場合、関係のトポロジは基底関係定義から推論する。例えば、通信関係の場合は自動記述を実施することができ、ホスト関係の場合は、ホスティング関係に関連するアルゴリズムに基づいてホストを選択する。フローステージの間、値フローエンジン614は、すべての関係インスタンスにわたってフローを評価する。値フローエンジン614は、改変されたパラメータフローの影響を受けたインスタンスについて、変更要求に更新要求を追加することができる。値フローエンジン614は、変更要求の結果として設定が更新されたインスタンスのセットを判定することにより、フローを評価する。これらのそれぞれにつき、修正された設定に依存する送出設定フローがあればそれを評価し、変更されたインスタンスのセットにターゲットノードを追加する。このプロセスは、そのセットが空になるまで、またはそのセットが循環を含むまで継続する。フローステージの後、重複検出のプロセスを実施する。重複検出は、図6に示すエンジンのうちの1つ例えば値フローエンジン614や制約チェックエンジン616によって実施することもでき、あるいは、図6に示していない別のエンジンによって実施することもできる例えば重複検出エンジンをSDMランタイム610に含めることができる。重複検出のプロセスは、展開されたインスタンスを、SDMデータ記憶域中にすでに存在するインスタンスと照合する。例えばこのプロセスは、別のアプリケーションが共有ファイルをインストールしたかどうかを検出する。すでに存在するインスタンスが検出されたときは、存在するインスタンスのバージョンに応じて、いくつかのアクションの1つを実施することができる。すなわち、インストールを失敗にすること、インスタンスを参照カウントすること、インスタンスをアップグレードすること、またはインストールを並行して実施することができる。制約チェックエンジン616は、制約評価フェーズを実施する。このフェーズでは、モデル中のすべての制約をチェックして、変更要求が処理された後でもこれらがまだ有効となるかどうかを調べる。制約チェックエンジン616が制約評価フェーズを終了した後には、完全なアクションリストが利用可能である。したがって、アクション順序付けエンジン618は、コンポーネント間の関係を使用して、有効な変更順序付けを判定することができる。この判定は、様々なアルゴリズムのいずれかを使用して行うことができる。アクション順序付けエンジン618が順序付けを終了すると、マシン特有の順序付けされたアクションセットのサブセットを配信することによって展開を実施することができる。アクションがマシンによって順序付けされグループ化された後、アクションと、インスタンス情報を含むランタイムのSDM記憶域608の必要部分のコピーとが、ターゲットコンピューティングデバイス622に送られる。SDMは、一時的にターゲットデバイスの記憶キャッシュ638に記憶することができる。ターゲットコンピューティングデバイスは、SDMランタイム610と通信するSDMランタイムのターゲット部分636を備える。ターゲットコンピューティングデバイス622はエージェントも備えており、このエージェントは、実行エンジン624を備え、ターゲットデバイス上の適切なインスタンスマネージャIM626と通信して、生成、更新、削除アクションなどの変更をターゲットに対して行うことができる。各アクションは、原子呼出しとしてインスタンスマネージャ626に送られる。インスタンスマネージャ626は、ステータスメッセージを返し、アクションによってはデータも返す例えば発見の場合。すべてのアクションがターゲット622上で完了すると、ターゲットのエージェントは、エラーがあればエラーと、ステータスとをコントローラ620に返す。次いでコントローラ620は、この情報を使用してランタイムのSDM記憶域608を更新する。上で論じたように、変更は、影響を受ける関係に基づいて変更要求を配信可能部分に分解することによって行われる。すべての部分が完了するとあるいは1つまたは複数の部分が失敗した後で、ランタイム610中で結果が照合され、概要がオペレータに返される。失敗の場合は、すべてのアクションをロールバックすることができ、システムを変更開始前の状態に戻すことができる。いくつかの実施形態では、上で論じた設計時妥当性検査の間、SDMコンパイラ628がSDMファイルを受け取り、テストCRを生成し、SDMランタイムの展開エンジン、値フローエンジン、および制約チェックエンジンを通してテストCRを実行し、エラーがあればエラーを開発システムに返す。このプロセスにより、展開に向けたSDM妥当性検査が、設計時の間に開発者にもたらされる。SDMランタイム610および/またはコントローラ620への公開インタフェースは、オブジェクトモデルAPIライブラリを介する。このライブラリは、マネージドコードオブジェクトモデルであり、以下の項目の実施を可能にする。ランタイム内でSDMを管理する。-SDMファイルをランタイムにロードすることができる。SDMは不変であり、一度に1つロードされるすなわち、ファイルの一部だけ例えばSDMファイルからの個々の定義、クラス、またはマッピングの1つ1つではなく、1つのSDMファイルをロードすることができる。SDMをランタイムから削除することができ、ランタイム内のSDMについてのXML文書を作成することができる。ランタイムによって知られるSDUを管理する。SDM定義を管理する。-SDM要素を見つけて検討するランタイムにロードされたSDMから。新しいSDMをオーサリングするために提供される公開APIはないすなわちこれは、SDMの不変要素に対する読出し専用オブジェクトモデルである。これは、SDM、SDU、識別、バージョン、クラス、定義、バインド/マッピング、およびバージョニングポリシーを含む。SDMインスタンスを管理する。-コンポーネント、エンドポイント、リソース、および関係のインスタンスを見つけて検討する。インスタンス空間では、各インスタンスを、GUID、安定パス、またはアレイベースのパスで識別することができる。パスはストリングであり、相対的とすることができる。相対パスを含めたこれらの識別子により、変更要求文書などの文書中でインスタンスを見つけて参照することができる。インスタンスを操作する。-生成、トポロジ変更、アップグレード、設定変更、削除を含めて、SDMインスタンスに対して変更を行う。インスタンス変更は変更要求の範囲内で行われ、変更要求は、エラーまたは制約違反があれば要求が完全に失敗するように、更新の原子単位を提供する。インスタンス要求はまた、インスタンスが一時的にホストへのバインドなしでも存在できるようにする。というのは、要求がコミットされるときはインスタンスはホストを有さなければならないからである。また、単一のコンポーネントのインストールまたは設定に影響を与える多くの操作が行われることを可能にし、単一の更新がコンポーネント上で行われるように、インストールまたは設定の更新がコミットまで延期されるようにする。変更要求のコミット前またはコミット時にSDMモデルチェックを実施し、モデル違反または制約違反があればコミットは失敗する。変更要求をロードする。-変更要求は、インスタンス空間操作のセットを提示する文書、例えばXMLファイルである。この文書は、相対パスを利用して、アプリケーションインスタンスを生成または削除するための再使用可能スクリプトとなることができる。変更要求を見つけて検討する。-インストール/更新タスクおよびすべてのエラー情報を得ること、ならびに要求の影響を受けるコンポーネントのインストール/更新を再試行することを含む。データベース中の変更要求から変更要求文書を生成する。このような文書はいくぶん移植性がある。進行状況、ログ、または更新されたステータスなど、変更要求タスクに関するイベントの通知に申し込む。これらのイベント加入の存続期間は、クライアントライブラリをロードしたプロセスの存続期間によって制限されるすなわちこれらは定期CLRイベントである。SDMランタイムエンジンは、SDMモデル、およびAPIによって表面化された関数に対して、推論を実施する。ライブラリは、SDMをロードする、コンポーネントインスタンスを生成する、SDM全体を得るSDMエンティティを検討するためなど、かなり粗な呼出しを使用してウェブサービスとしてランタイムエンジンに通信する。このウェブサービスに関する多くのパラメータのフォーマットは、SDMファイルの場合と同じスキーマを有するXMLである。エンジンはまた、許可に対するチェックも実施することができる。コントローラ620は、インスタンスマネージャIMを利用することができ、IMは、モデル中の任意の定義または関係に関連付けることができる。IMは、以下の役割の1つまたは複数を実施することができる。インスタンスの展開をサポートする。インスタンスが展開された後のインスタンスの妥当性検査をサポートする。ランタイムを介して展開されたのではない展開済みインスタンスの発見をサポートする。設定値のフローをサポートする。制約の評価をサポートする。変更要求の展開をサポートする。APIを介してインスタンスをCLRクラスとしてユーザに提示することをサポートする。展開のために、コントローラ620上のインスタンスマネージャIMプラグインがクラスホスト関係に関連付けられるが、このプラグインは、開発システム中で使用される、クラスに関する設計経験を提供し、SDU604中および設定スキーマ中の関連バイナリを作成するプラグインとは別である。インスタンスマネージャは、インスタンスマネージャインタフェースを実装するかまたは抽象クラスから継承するCLRクラスとして例えばdllアセンブリ中でSDMランタイム610に供給される。SDMインスタンスマネージャは、インスタンスマネージャIMプラグインとも呼ばれ、以下の機能をコントローラ620に提供する。コンポーネントインスタンスをそれらのホストにインストール、アンインストール、または再インストールするためのファイルおよびコマンドタスクを生成する。-変更要求の結果、新しいコンポーネントインスタンス、またはコンポーネントインスタンスの削除、またはアンインストールおよび再インストールが必要なコンポーネント変更が生じるとき、インスタンスマネージャは、SDU604中のインスタンス、ホストインスタンス、コンポーネントに関連する定義、これらの定義に関連するバイナリの設定を利用し、手動実行の準備または展開エンジンを介したディスパッチの準備ができたターゲットサーバ上でインストールまたはアンインストールを実施するのに必要なファイルおよびコマンドを作成する。コンポーネントインスタンスの設定が変化したとき、またはそのエンドポイントの1つからのビューが変化したとき例えば通信関係トポロジが変化したせいで、または見えるエンドポイントが設定変更を有するせいで、コンポーネントインスタンスを更新するためのファイルおよびコマンド例えばタスクを生成する。コンポーネントインスタンスのエンドポイント上で見えるエンドポイントインスタンスを、コンポーネントインスタンス上の設定にマッピングする。-SDM中で、コンポーネントインスタンスは、何らかの通信関係トポロジの結果として他のエンドポイントインスタンスが見えるエンドポイントインスタンスを有する。他のエンドポイントインスタンスの詳細は、コンポーネントインスタンスがランタイム時にフェッチすることのできる、したがって通常はそれにバインドすることのできる設定にマッピングされる。例えば、ウェブサイトがデータベースクライアントエンドポイントを有し、したがって通信関係はデータベースを使用して確立することができる。正しく確立されたとき、そのデータベースクライアントエンドポイントは、このサーバエンドポイント上の単一のデータベースサーバエンドポイントインスタンスおよび設定を見ることができる。この情報をインスタンスマネージャが使用して、サーバに関する接続ストリングを、クライアントエンドポイントという名前で構成ファイル中に配置する。この結果、コードは単に、データベースに関する接続ストリングをその構成設定から読む。コンポーネントインスタンスを監査するためのファイルおよびコマンドタスクを生成する。-監査は、存在および正しい設定を確認する。これはホストインスタンス設定にも適用することができる。任意のタスクについてステータスを報告する。-IMは、取り込まれた出力の一部または全部を変換し、タスクのステータスを成功、失敗、または不完全として提供し、任意選択で、不完全に関する進行状況または最終応答、失敗に関する詳細エラーメッセージ、および任意のステータスに関する人間に読めるログを提供する。インスタンスマネージャに戻ってタスクの出力を解釈することにより、インスタンスマネージャは、診断に十分なログを作成してそれを人間に読めるように維持しなければならないのではなく、そのタスクをログ構造化情報例えばXML、さらにはSOAPSimpleObjectAccessProtocolにすることが自由にできる。インスタンスマネージャはまた、ホストとそれらのゲストとの間の制約チェックを実施するコードを提供することもできる。インストーラは、共通の制約言語、例えばXML、XPath、XQueryに基づく言語を使用することができる。レイヤ化SDMモデルは、アプリケーション開発者と、ソフトウェアインフラストラクチャ設計者と、データセンタ構築者との間で関心が分離されるようにする。これらの各グループは、特定のサービスに焦点を合わせ、異なる関心のセットを有する。例えば、開発者は主に、SQL、IIS、CLRなど、開発者が利用するホストの間の構成および接続性に関心を持つ。ホスト構成の設計者は主に、ネットワークトポロジおよびOS構成に関心を持つ。ネットワークトポロジ、OS構成、記憶マッピングを開発する構築者は主に、データセンタに存在するハードウェアに関心を持つ。SDMは、システムを横軸と縦軸にわたって機能構成することを可能にする。横軸に沿った構成は、システムおよびサブシステムによって行う。縦軸に沿った構成は、レイヤによって行う。アプリケーション、サービス、ネットワークトポロジ、およびハードウェアは、分散システムにおける役割を果たすが、通常は、独立して定義され、異なるチームまたは組織によって所有されている。レイヤ化は、コンポーネントがホストに対して制約セットを定義することによって、またその逆によって達成される。この関心の分離をサポートするために、SDMは、レイヤ化の概念を呈示する。レイヤ化は、アプリケーションが依存するサービスをアプリケーションの包含構造の一部として宣言せずに、ホスティング関係を用いてアプリケーションをサービスにバインドすることを指す。レイヤ化により、異なる個人が異なる時に異なるレベルでシステムを開発することができる。図7に、例示的なレイヤ化設定を示す。図7には、4つのレイヤすなわちレイヤ702、レイヤ704、レイヤ706、レイヤ708が示されている。4つのレイヤが図7に示されているが、実際のレイヤの数は様々とすることができ、4つよりも多いか少ない可能性もある。さらに、種々のレイヤの内容も、実施形態に応じて様々とすることができる。図7からわかるように、種々のレイヤは他のレイヤの上および/または下に位置する例えばレイヤ706は、レイヤ704の上にあるがレイヤ708の下にある。レイヤ内の種々のシステムおよびサブシステムが、相互に対話することができ、また、異なるレイヤのシステムおよびサブシステムと対話することができる。例えばレイヤ708中のサブシステム710は、レイヤ708中のサブシステム712、ならびにレイヤ706中のサブシステム714と対話することができる。さらに、各レイヤは、より高い次のレイヤに対する環境と見なすことができる。例えばレイヤ706は、レイヤ708中のシステムおよびサブシステムに対する環境であり、レイヤ704は、レイヤ706中のシステムおよびサブシステムに対する環境である。各レイヤ702、704、706、708は、それ自体の関連するSDM文書を有する。種々のレイヤ702、704、706、708は、異なる内容を表すものとすることができる。いくつかの実施形態では、レイヤ702はハードウェアレイヤであり、レイヤ704はネットワークトポロジおよびオペレーティングシステムレイヤであり、レイヤ706はアプリケーションホストレイヤであり、レイヤ708はアプリケーションレイヤである。ハードウェアレイヤは、レイヤ化されたシステムがその上に構築される物理デバイス例えばコンピューティングデバイスを表す例えば図1のデバイス102。ネットワークトポロジおよびオペレーティングシステムレイヤは、コンピューティングデバイスのネットワークトポロジ例えば図1のネットワーク100の設定、ならびにこれらのコンピューティングデバイス上にインストールされるオペレーティングシステムを表す。アプリケーションホストレイヤは、コンピューティングデバイスにインストールされた、他のアプリケーションをホストすることのできるアプリケーションを表す例えばSQLStructuredQueryLanguageサーバ、IISInternetinformationservice商標など。アプリケーションレイヤは、コンピューティングデバイスにインストールされた、他のアプリケーションをホストしないアプリケーションを表す例えばゲームなどの娯楽アプリケーション、ワードプロセッサなどの生産性アプリケーション、電子百科辞典などの参照アプリケーション、ウェブサービスや財務分析に使用できる分散アプリケーションなど。例示的なSDM実装形態以下の解説では、SDMの要素を定義するスキーマの一実施形態について述べる。1定義2アーキテクチャの概観システム定義モデルSDMは、分散システムモデル化システム中のコンポーネントの構成、対話、および変更の記述をサポートするように設計される。SDMは、オブジェクト関係モデルに基づく。オブジェクトを使用して、システム中に存在するエンティティを記述し、関係を使用して、それらの間のリンクを識別する。SDMではさらに、SDMにとって重要なセマンティクスを取り込むようにオブジェクトおよび関係が改良される。具体的には、オブジェクトはシステム、エンドポイント、リソースに分けられ、関係は通信、包含、ホスティング、委任、参照に分けられる。抽象定義を使用して、システムの各部分の共通範疇化を提供する。これにより、幅広いアプリケーションに対するツールサポートが可能になり、設計時の型チェックのための基盤がもたらされる。抽象定義のセットは、システム設計のための包括的な基盤を提供すると考えられ、これらは時の経過に伴ってゆっくり変化すると考えられる。実際のアプリケーションまたはデータセンタの設計の各部分を表す具象オブジェクト定義を構築する。抽象オブジェクト定義を利用して、具象型のメンバとそのプロパティの設定値とを定義する実装を提供する。次いで、これらの定義の集合からシステムを構築する。制約を使用して、インスタンスが参与することのできる許容される関係のセットに対する制限をモデル化する。制約は、関係に関与するオブジェクトの構成に応じたきめ細かい要件を取り込むのに使用する。例えば、制約を使用して、通信プロトコルの両端の参与者が互換性のあるセキュリティ設定を使用していることを妥当性検査することができる。ターゲットシステムに対する変更を実施するために、SDMは、変更要求と呼ばれる、必要とされる変更の宣言記述を使用する。SDMは、SDM実行モデルの一部として変更要求を展開、妥当性検査、および実行するのに使用されるプロセスを定義する。インスタンス空間が、管理されるアプリケーションの所望状態と現在状態の両方を取り込む。インスタンス空間中の変更は、追跡され、その変更を開始した変更要求に関連付けられる。後続のUMLunifiedmodelinglanguage図は、SDMモデル中のオブジェクト間の広範な対話を取り込むものである。簡単にするために、これらの対話のいくつかは基底型の間で定義されているが、実際の対話は派生型の間に存在し、その結果、より特殊化されている。例えば、通信関係は抽象エンドポイント定義だけを参照する場合がある。SDM文書は、文書と、文書中の定義に対するマネージャと、他の文書を参照するインポートステートメントと、定義セットとを記述する情報を含む。図8に例示的な文書を示す。図9に示すように、すべてのSDM定義は、共通基底定義から派生し、メンバを含むことができる。定義とメンバの間の関係は、後続の図に示すものよりも複雑にすることもできる。図10に示すように、メンバは、それらが参照する定義の種類によって分けられる。設定宣言は、設定定義を参照する。図11に示すように、設定値および値リストが、設定に関する値を提供する。2.1SDMアプリケーションのライフサイクル図12に、いくつかの実施形態による例示的なSDMアプリケーションのライフサイクルを示す。アプリケーションをVisualStudio登録商標環境内で設計および実装するブロック1202。開発者は、コンポーネントを実装し、次いでそれらを複合コンポーネント内で結合する。アプリケーションはSDMファイル内に記述する。開発者のアプリケーションが特定のデータセンタ内で展開されることを検証するために、開発者はアプリケーションを、やはりSDMファイル中に記述されたデータセンタ表現にバインドするブロック1204。この表現は、開発者のアプリケーションコンポーネントのホストに関する定義と、開発者のアプリケーションの構成に対する制約とを含む。バインドが失敗した場合は、開発者はアプリケーション設計を修正することができる。開発者が自分のアプリケーションに満足すれば、開発者はアプリケーションに署名して公表することができ、したがって、今やアプリケーションには厳密名strongnameおよびバージョンが関連付けられているブロック1206。アプリケーションの公表された形は、ソフトウェア配信ユニットSDUと呼ばれる。オペレータは、開発者からのSDUを採用し、アプリケーションをSDMランタイムにロードするブロック1208。アプリケーションをロードするプロセスの間、オペレータは、アプリケーションをバインドしたいと思うデータセンタのモデルを選択する。オペレータは、アプリケーションを展開することを決定すると、展開時パラメータをアプリケーションに供給し、アプリケーションのスケールを判定するブロック1210。これは変更要求を使用して行う。アプリケーションを展開すると、オペレータはランタイムと対話して、アプリケーションの構成およびアプリケーションの各部分に関する設定を判定することができるブロック1212。ランタイムはまた、アプリケーションの実際の構成が、ランタイム内に記録されている所望の構成とマッチすることを検証することもできる。オペレータは、変更要求をサブミットすることにより、展開したアプリケーションを削除することができるブロック1214。オペレータはまた、サービスパックの削除など、実行中のアプリケーションに加えられた個々の変更をロールバックすることもできる。ブロック1216で、展開されたアプリケーションの一部をウェブフロントエンドなどに対して追加または削除することにより、実行中のアプリケーションの構成を変更することができる。アプリケーションはまた、1つまたは複数のアプリケーションコンポーネントのより新しいバージョンをインストールすることによってアップグレードすることもできる。2.2抽象オブジェクト定義および関係定義抽象オブジェクト定義は、設計時にアプリケーション構成をチェックしてからランタイム時にアプリケーションを展開および管理するために必要な構成単位を定義する。これらの構成単位は、モデル化システム中に存在するエンティティを表す。例えば、抽象オブジェクト定義を使用して、ファイルおよびディレクトリ、ウェブサーバ内部の構成、またはSQLサーバ内部のデータベースがモデル化される。抽象関係定義は、抽象オブジェクト定義間で行われる可能性のある対話をモデル化するのに使用する。関係は、バイナリおよび有向であり、関係の発現に参与するインスタンスを定義するオブジェクト定義を識別する。関係は、オブジェクト間の包含、構築、通信のリンクをモデル化できるようにオブジェクトを共に結ぶ方法を提供する。次いで、オブジェクトが制約を使用して、オブジェクトの参与する関係を制約し、関係が制約を使用して、リンクできるオブジェクトを制約する。これらの制約は、関係への参与者の定義と設定の両方をターゲットにすることができる。これにより制約は、関係への参与者を特定の定義から派生するインスタンスに限定することができ、また、インスタンスが特定の範囲に含まれる設定値を有することを必要とすることができる。オブジェクト定義は、システム、エンドポイント、リソースという3つのカテゴリに分けられる。抽象システム定義は、アプリケーションの自己完結型かつ独立展開可能な部分を記述するのに使用する。これらの定義は、プロセスおよびマシンの境界を横断することのできる明確に定義された通信チャネルを介して対話するアプリケーション部分を表す。抽象エンドポイント定義は、システムが開示するexposeことのできる通信エンドポイントを記述するのに使用する。これらを使用して、設計時にシステム接続性を検証するためおよびランタイム時に接続を可能にするためにシステムが意識すべきすべての形の通信をモデル化する。抽象リソース定義は、システム内に含まれる挙動を記述する。リソース定義は、他のリソース定義への強力な従属性を有する場合がある。これらの従属性には、特定のインストール順序を必要とすることや、公式に文書化されていない通信機構を介したランタイム対話を開始することを含めることができる。すべての抽象オブジェクト定義は、設定を開示する能力を共有する。これらの設定は、名前と値の単純な対であり、XMLスキーマを使用して設定の型を定義する。設定は動的でも静的でもよいが、静的の場合は、展開プロセスの間だけ設定することができ、動的の場合は、展開後に変更することができる。実行中のシステムに設定値を適用することを担うコードは、SDMランタイム中でホストされる。SDMは、抽象オブジェクト定義を越えた継承をサポートする。派生した定義は、その親によって開示されたプロパティを拡張することができ、その親のプロパティに関する値を設定することができる。派生した定義は、その親を参与者として識別する関係のいずれにも参与することができる。関係定義は、通信、包含、委任、ホスティング、参照という5つのカテゴリに分けられる。通信関係は、抽象エンドポイント定義間の可能性ある通信対話を取り込むのに使用する。通信関係があることは、識別された定義のエンドポイントを開示しているシステムが通信することが可能かもしれないことを示す。実際のリンク確立は、エンドポイントおよびエンドポイントの開示exposureに対する制約を受ける。包含関係は、抽象オブジェクト定義が別の抽象オブジェクト定義のメンバを含むことができることを記述する。より具体的には、2つの抽象オブジェクト定義AとBの間の包含関係では、Aを実装する具象オブジェクト定義が、Bを実装する具象オブジェクト定義のメンバを含むことができる。包含を使用して、開発者がアプリケーションを構築するときに生じる自然なネスト構造がモデル化される。メンバオブジェクトを含めることにより、親は、含まれたオブジェクトの存続期間および可視性を制御することができる。ランタイム空間中のすべてのオブジェクトインスタンスは、他のオブジェクトインスタンスのメンバとして存在し、完全に接続されたインスタンスセットを形成する。したがって、包含関係のセットは、インスタンス空間で生じる許容される包含パターンを記述する。委任関係は、含まれるオブジェクトメンバを選択的に開示するのに使用する。具体的には、委任を使用して、システム定義からのエンドポイントメンバを開示する。サブシステムからエンドポイントを委任することにより、外側のシステムは、特定のプロトコル上で、プロトコルの奥にある実装を開示することなく通信する能力を呈する。ホスティング関係および参照関係は、従属関係の2つの形である。ホスティング関係は、具象オブジェクトのインスタンスを生成できるようになる前に存在すべき抽象オブジェクトの間の主要な従属性を記述する。あらゆるインスタンスは、ちょうど1つのホスティング関係にゲストとして参与すべきであり、この結果、ホスティング関係はまた、完全に接続されたツリーをインスタンス空間にわたって形成する。参照関係は、パラメータフローおよび構築順序付けに使用することのできる追加の従属性を取り込む。2.3具象オブジェクト定義および関係定義抽象オブジェクト定義から具象オブジェクト定義を構築し、抽象関係定義から具象関係定義を構築する。抽象オブジェクト定義と抽象関係定義の組合せは、ターゲットシステムをモデル化するためのスキーマを定義する。具象オブジェクト定義の役割は、抽象定義空間のサブセットを使用して、1つまたは複数の抽象定義に基づく再使用可能な構成を生み出すことである。単純な類比として、抽象定義空間は、データベースに関するスキーマに例えることができる。この場合、具象オブジェクト定義は、データベース中の行のセットのための再使用可能テンプレートを表すことになる。行は、具象オブジェクトのインスタンスが生成されたときだけデータベース中に生成される。設計時妥当性検査を行うために、データベース中の行をスキーマの制約例えば外部キーなどに対して妥当性検査するのと同じようにして、具象オブジェクト定義を抽象定義空間に対して妥当性検査することができる。各具象オブジェクト定義は、特定の抽象オブジェクト定義に対する実装を提供する。実装は、設定スキーマに対する拡張と、設定に関する値と、オブジェクトメンバ、関係メンバ、制約メンバ、フローメンバに関する宣言とを含む。具象オブジェクトの挙動は、抽象オブジェクトの定義に従う。すなわち、抽象システム定義が具象システム定義になり、抽象エンドポイント定義が具象エンドポイント定義になり、抽象リソース定義が具象リソース定義になる。各具象関係定義は、特定の抽象関係定義に対する実装を提供する。実装は、設定宣言および値と、同じ関係カテゴリホスティング、包含、通信などのネストされたメンバと、関係に参与することのできる型に対する制約とを含むことができる。具象ホスティング関係は、ある具象オブジェクトのメンバを別の具象オブジェクト上にマッピングすることを定義するのに使用する。例えば、具象ホスティング関係を使用して、ウェブアプリケーションとそれが展開されることになるIISホストとの間のバインドを識別することができる。所与の型に対して複数の具象ホスティング関係が存在することができ、これにより開発者は、特定のトポロジに対して種々の展開構成を定義することができる。2.4メンバ具象型は、他の具象または抽象オブジェクトのメンバを宣言することができる。これらをオブジェクトメンバと呼ぶ。この場合、これらのメンバは、オブジェクトメンバ間の関係を定義する関係メンバから参照される。オブジェクトメンバは、特定のオブジェクト定義のインスタンスを生成するのに使用される。設定フローを使用して、オブジェクトに関する値を提供することができる。オブジェクトメンバを宣言するとき、ユーザは、オブジェクトメンバが、外側のシステムが生成されるのと同時に生成されるか値セマンティクス、あるいはいくらか後で行われる新しい明示的動作によって生成されるか参照セマンティクスを決定することができる。関係メンバは、オブジェクトメンバが生成されたときにそれらが参与することになる関係を定義する。オブジェクトメンバがその親に含まれる場合は、包含関係メンバを型メンバと外側の型との間で宣言する。オブジェクトメンバが委任される場合は、委任関係メンバを、オブジェクトメンバとネストされたオブジェクトメンバとの間で定義する。通信関係メンバは、オブジェクトメンバ上のエンドポイント間で宣言することができ、従属関係メンバ参照およびホスティングは、オブジェクトメンバまたはネストされたオブジェクトメンバ間で宣言することができる。関係制約は、特定のオブジェクトが参与を望む関係のセットを限定するのに使用する。これらは、特定の関係に対する制約、および関係の他方の端の参与者に対する制約を識別する。2.5インスタンス空間SDMランタイムに記憶されているインスタンス空間は、モデル化システムの現在状態を反映する。ランタイムは、生成されたインスタンスと、これらのインスタンス間の関係との完全な記録を含む。各インスタンスにはバージョン履歴が関連し、バージョン履歴中では、各バージョンが変更要求にリンクされている。新しいインスタンスを生成するプロセスは、変更要求によって開始される。変更要求は、既存のインスタンスの特定メンバに関連する型および関係に対する、生成、更新、削除要求のセットを定義する。ルートは特別なケースである。変更要求は、ランタイムによって展開され、すべての制約に対して検証されてから構築される。展開プロセスでは、オブジェクトの構築要求の一部として暗黙的に構築される、オブジェクトに含まれるオブジェクトインスタンスおよび関係インスタンスを識別し、次いで設定フローをすべての関係にわたって評価する。検証ステップでは、必要な関係がすべて存在すること、および関係がすべての制約を満たすことをチェックする。最後に構築プロセスでは、各インスタンスの展開、更新、または削除にわたる適切な順序付けを判定し、次いで、適切なアクションが実施されるように、各インスタンスを正しいシーケンスでインスタンスマネージャに渡す。2.6レイヤ化SDMモデルの目標は、アプリケーション開発者と、ソフトウェアインフラストラクチャ設計者と、データセンタ構築者との間で、関心が分離されるようにすることである。これらの各グループは、特定のサービスに焦点を合わせ、異なる従属性セットを有する。例えば、開発者は主に、SQL、IIS、CLRなど、開発者が依存するホストの間の構成および接続性を気にかける。ホスト構成の設計者は、ネットワークトポロジおよびOSoperatingsystem構成を気にかけ、ネットワークトポロジ、OS構成、記憶マッピングを開発する構築者は、データセンタに存在するハードウェアについて知る必要がある。この関心の分離をサポートするために、SDMは、レイヤ化の概念を呈示する。レイヤ化は、アプリケーションが依存するサービスをアプリケーションの包含構造の一部として宣言せずに、ホスティング関係を用いてアプリケーションをサービスにバインドするものである。SDMモデルの一部として、以下の4つのレイヤが識別される。アプリケーションレイヤアプリケーションレイヤは、制約されたコンテキストでアプリケーションを構築することをサポートする。コンテキストは、ホストレイヤで定義されるホストの構成によって定義される。アプリケーションレイヤ中のシステム定義の例としては、ウェブサービス、データベース、およびBizTalk商標スケジュールが挙げられる。ホストレイヤソフトウェアコンポーネントからデータセンタを構築する。コンポーネント間の接続を構成する。これらのコンポーネントのいくつかは、アプリケーションレイヤのためのホストとして働く。このレイヤ中のシステム定義の例-IIS商標、SQL、AD、EXCHANGE、DNSDomainNameSystem、BizTalk商標ネットワーク/OS/ストレージレイヤデータセンタネットワークおよびプラットフォームを構築する。ネットワークセキュリティモデルおよびオペレーティングシステムプラットフォーム構成を構成する。オペレーティングシステム構成にストレージを追加する。このレイヤ中のシステム定義の例-VLAN、Windows登録商標、Filter、Storageハードウェアレイヤハードウェアレイヤは、データセンタに存在するマシンのタイプ、およびこれらのマシン間に存在する物理接続を識別する。図13に、レイヤ4ウェブアプリケーションをレイヤ3ウェブサーバホストにマッピングする例を示す。各レイヤの外側のボックスはシステムを表し、境界上のボックスはエンドポイントを表し、内側のボックスはリソースを表す。これらの各要素を、ホスティング関係を介して下のレイヤにあるホストにマッピングする。システムに必要な関係を満たすために、マッチする機能を有するホストシステムにこのシステムをバインドする。このプロセスを配置placementと呼ぶ。設計時、可能な配置を表す具象ホスティング関係を構築する。展開時、具象ホスティング関係のインスタンスをインスタンス化して、ゲストシステムインスタンスをホストシステムインスタンスにバインドする。2.7モデル評価SDMモデルには、分散システムに対する変更を管理するための明確に定義されたプロセスが関連付けられる。各変更は、いくつかの処理ステップを経た宣言変更要求によって進められ、その後、要求中の動作が配信され、次いでターゲットシステムに対して実行される。3実装の詳細3.1名前付けSDM中には、オブジェクトを識別するための厳密な名前付けシステムが必要な場所がいくつかある。以下の名前付けシステムによれば、型の生成者は、開発者が元々公表した定義と同じ定義であることを定義のユーザが確信できるような形で、定義に署名することができる。以下のヘッダは、SDM名前空間における識別子の例である。別の名前空間中の型を参照するには、その名前空間をインポートする必要がある。次いで、エイリアスを使用して、その名前空間内の型を参照することができる。FileSystemfile3.1.1識別SDMの名前は、それらが定義される名前空間を範囲とする。名前空間は、名前、バージョン、言語、および公開鍵トークンで識別され、単一のファイル内に含まれる。識別の基本形は、名前、バージョン、カルチャ、プラットフォーム、および公開鍵トークンを含む。基底識別を使用して、既存の識別を参照することができ、あるいは、署名および公開鍵と共に、新しい厳密識別を生成することができる。文書には秘密鍵を使用して署名することになり、それにより文書のユーザは、公開鍵を使用してその内容を検証することができる。公開鍵トークンは、公開鍵/秘密鍵の対の公開部分を識別する16文字の16進ストリングである。これは公開鍵ではなく、単に公開鍵の64ビットハッシュである。PublicKeyToken16hexdigitsinsize3.1.2バージョンファイルバージョンは、N.N.N.Nの形をとる4部分の数で定義され、0≦N<65535である。慣例的に、この数はメジャー.マイナー.ビルド.リビジョンを表す。3.1.3簡易名簡易名は、英数字および限られた句読点からなる。名前は数字以外の文字で始まらなければならない。識別子についてはC定義に準拠する予定である。適切な章2.4.2を以下に挿入してある。仕様は以下で見ることができる。httpdevdivSpecToolDocumentsWhidbeyVCSharpFormal20Language20SpecificationCSharp20Language20SpecificationdocSDMモデルでは、頭にの付く名前はサポートされないことに留意されたい。3.1.4予約済みの名前以下は、ユーザがSDMモデル中のオブジェクトの名前を生成するときに使用できない予約済みの名前のリストである。一定のコンテキスト内で、いくつかの名前が予約されている。以下の名前は、CLRとの統合により予約されている。3.1.5他の名前空間の参照他の名前空間を現在の名前空間にインポートしてからエイリアスを名前空間に関連付けることにより、名前空間が他の名前空間を参照することを可能である。インポートされた名前空間は、名前、バージョン、および公開鍵トークンで参照される。バージョニングについては3.16章で述べる。3.1.6修飾パス修飾パスはこの場合、現在の名前空間中またはエイリアシングされた名前空間中で定義される定義とマネージャとのいずれかを指す名前である。エイリアスはインポートステートメント中で定義される。以下の簡易名は、型を識別し、パスの場合はネストされた型を識別する。3.1.7定義およびメンバパスパスは、メンバまたは設定を識別する一連の名前である。パスは、パスに関連するオブジェクトまたは関係によって定義される、周知の名前またはメンバ名で始まるべきである。3.1.8インスタンスパスインスタンス空間中のパスはXPathに基づく。XPath中の要素名はメンバ名に対応し、XPath中の属性は設定に対応する。3.1.9名前解決エイリアスで始まらない名前は、完全修飾されていない。このことは、これらが評価される範囲が、得られるバインドを変化させる可能性があることを意味する。この一例は、ネストされた定義である。ネストされた定義名を解決するとき、ローカル範囲中の定義は、より広い範囲内の定義を隠蔽する。3.2設定すべての定義は、設定宣言を開示することができる。これらの設定は、抽象定義から具象定義を生成するとき、または定義を別の定義内のメンバから参照するときに、提供できる値を記述するのに使用することができる。設定を定義するには、まずXSDを使用して設定の定義を定義する必要がある。次いで、この定義を使用する設定であって、設定の挙動を定義するための属性セットを含む設定を宣言することができる。設定宣言が得られれば、この設定の値を提供することができる。long3.2.1設定定義XSDスキーマを使用して、設定宣言によって使用される設定定義を定義する。スキーマからの単純型および複合型の使用がサポートされる。ただし、これらの型の定義をサポートする他のスキーマ要素がある場合もある。設定定義のセクションは、名前空間宣言および名前空間インポートを含めた、完全なXMLスキーマを含むべきである。XSDスキーマ中のインポートが、XSDスキーマの名前空間を除いてはSDMファイル中のインポートとマッチすることをチェックする。このことは、参照されるすべての型が別のSDMファイル中で定義されるべきであることを意味する。スキーマは、自由裁量のXSDファイル中で定義される型を参照することはできない。設定は、以下の3つの分離可能な名前空間から解決可能であるべきである。aSDM名前空間-システム、リソース、エンドポイント、関係、制約、またはフロー型内の設定型を指すとき。bCLR名前空間-CLR内の強く型付けされたクラスを使用する設定を指すとき、および設定型が他の設定型上に構築されるとき。cXSD名前空間-設定型が他の設定型を使用して構築されるとき。これが機能するためには、設定を宣言する方法に対していくつかの制約を課すべきである。aすべての設定は、CLR、SDM、およびXSDの各名前空間内で同じグループにあるべきである。すなわち、2つの設定が1つの名前空間で共にある場合、これらは3つの名前空間すべてで共にあるべきである。bXSDスキーマ定義内のインポートされた名前空間は、SDMファイル中のインポートされた名前空間、および関連するヘルパアセンブリ中のインポートされた名前空間とマッチすべきである。cXSD名前空間を除いては、XSDスキーマ中のすべてのインポートされた名前空間は、SDMファイル内で定義されるべきである。インポートされたSDM文書からのXSD型へは、QNameを使用してアクセス可能である。したがって例えば、以下の例に示すように、Foo.sdmがBar.sdmをインポートした場合、Bar.sdmの設定型は、Foo.sdmのsettingTypes要素中で参照することができる。3.2.2.組込み単純データ型SDMは、XSDとCの名前空間の共通部分である限られた組込みデータ型のセットをサポートする。これらの型は、SDMランタイムによってネイティブにサポートされ、以下の表に定義される。これらの型に加えて、ユーザは、XSDとCLS型間のユーザ自身のマッピングを自由に構築して使用することができる。これらの型は、CおよびXSDの型空間におけるこれらの型の互換派生物にフローすることができる。例えば、stringの値を、ストリングに対する制限を定義したXSD型にフローすることができ、anyの値を、type=anyを受け入れる設定にフローすることができる。3.2.2.1XSD組込み型図14に、例示的な組込みデータ型階層を示す。3.2.2.2Cデータ型3.2.2.3サポートされる変換以下は、XSD型とCLS型の間に存在する変換である。3.2.3設定宣言設定宣言セクションでは、前のセクションからの設定宣言を使用して、名前付き設定を生成する。属性を使用して、各設定に関する情報をさらに提供する。3.2.4リストサポート多値設定の操作をサポートするために、単純な設定値リストがサポートされる。リストは、設定宣言と同じ定義の値のシーケンスである。リストは、置換またはマージできる別のリストにフローすることができる。値をリストにマージする際の重複検出はサポートされない。というのは、これは、設定フローを使用すればよりフレキシブルに行うことができるからである。また、どんな形の順序付けもサポートされない。リスト宣言は、以下のように真に設定された属性listを含む。次いで、settingValueListを使用して値を提供する。リストを提供するとき、ユーザは、前の値と置換またはマージするかどうかを指定することができる。SDMは、値リストの単純な操作をサポートする。フローメンバからのパスが設定宣言をターゲットとするとき、結果的な挙動は、パスのどちらかの端における定義に依存する。3.2.5設定属性設定属性は、ランタイムが特定の設定の挙動を記述するのに使用する。3.2.6設定値設定が単一の値として宣言されたかリストとして宣言されたかに応じて、設定に関する値は、設定値要素と設定値リスト要素のどちらかを使用して提供することができる。3.2.6.1設定値設定値は、特定の設定宣言に関する値を提供するのに使用する。値は、宣言に関連する定義とマッチすべきである。値がfixedに宣言された場合、提供された値は、値が固定されるポイントに応じて、すべての派生定義中でまたは参照するメンバ中で使用されることになる。値が固定された後は、オーバーライドすることはできない。3.2.6.2設定値リスト設定値リストは、リストとして宣言された設定に関する1つまたは複数の値を提供するのに使用する。値を宣言するとき、ユーザは、前の値とマージするか、あるいは前の値すべてを上書きするように決定することができる。3.2.7設定継承設定継承は、派生定義が基底定義からのすべての設定宣言を暗黙的に含むことを意味する。設定継承の重要な側面のいくつかを以下に示す。設定継承は推移的である。CがBから派生し、BがAから派生した場合、Cは、B中で宣言された設定ならびにA中で宣言された設定を継承する。派生定義は、それが拡張する基底定義から継承した設定宣言に新しい設定宣言を追加することができるが、継承した設定の定義を削除することはできない。3.2.8型変換組込み型間のロスレスlossless変換がサポートされる。他の型変換は、適切な変換を実行するためにフローが必要である。3.3属性SDM中のオブジェクトの多くは、オブジェクトのコア挙動と直交する挙動を取り込むように属性付けることができる。以下のように定義される一般的な属性付けモデルが使用される。3.4定義およびメンバ3.4.1定義定義definitionは、オブジェクト定義、関係定義、制約定義、フロー定義が派生する基底である。すべての定義は、設定スキーマおよび設計表面surfaceデータを含むことができる。各定義は、簡易名で識別され、マネージャを参照する。マネージャは、この特定の定義のためにSDMランタイムに拡張サポートを提供することを担う。設定スキーマは、この定義のインスタンス上に見られる値を定義する。DesignData要素を使用して、設計表面上でこの定義の表示および編集に特有のデータを含める。3.4.2メンバメンバは、ランタイム時に存在することのできる定義インスタンスを識別するのに使用する。すべてのメンバは、型の範囲内で固有の名前で識別され、それらが参照する定義に関する設定を提供することができ、設計表面特有のデータを含むことができる。3.5設定フロー設定フローは、オブジェクト定義のメンバ間および関係への参与者間でパラメータを渡すのに使用する。フローの一部として、ユーザは、変形を用いて設定値を結合または分離し、新しい設定値を計算することができる。すべての設定フローメンバは、フロー定義を使用して変形を実装する。フロー定義は、SDMファイル中で宣言される。以下は、URLUniformResourceLocatorを解析するフロー型である。次いで、フローメンバをオブジェクト内または関係内で宣言する。フローメンバは、フロー定義への入力を提供し、次いでフローからの出力をターゲット設定に向けて送る。3.5.1フロー定義フロー定義は、設定値のセットに適用したいと思う特定の変形を定義するのに使用する。フロー定義は、入力設定書込み専用設定および出力設定読出し専用設定と、変換を定義するための入力インタフェースなど、設計表面特有の情報に関する設定データセクションと、SDMファイルを閲覧するときに使用される記述とを定義する設定スキーマを開示する。フロー定義は、それが定義される名前空間内の名前で識別される。定義はまた、ランタイムがフローを評価するときにランタイムをサポートすることになるマネージャも識別する。簡単な変形が必要なときにフロー要素の構築を単純にするために、ランタイムはいくつかの標準フロー定義を含むものと考えられる。例としては、コピー、マージ、およびストリング代用が挙げられる。フロー定義はパラメータ化することができるので、構成パラメータに基づいて異なるアクションを実施する1つまたは複数の単純な変形があることも考えられる。3.5.2フローメンバ各フロー要素は、1つまたは複数のソースノード、1つまたは複数の宛先ノード、いくつかの静的設定、およびフロー定義を識別する。フローが評価されるとき、ソースノードからソースデータが収集され、フロー要素からの設定と結合され、変換のためにフロー定義に渡される。出力データは宛先ノードに渡される。ソース値の1つが変化したときは、フローの再評価がトリガされる。この理由で、値の反転を引き起こす循環フローを回避する必要がある。値が一定のままである場合は、ループは終了する。ランタイムは、スタック深度を常に把握していることによって、無限ループを検出し終了させる。3.5.3設定ターゲット設定ターゲットは、フローが定義されているコンテキストで周知である名前に関係するメンバまたはネストされたメンバ中の設定値へのパスを識別する。周知の名前の例としては、定義または参照宣言中のthis、ホスティング関係宣言中のhostおよびguest、または制約宣言内で定義されたtargetが挙げられる。設定ターゲットはまた、パスによって識別される設定のソース値と宛先設定のどちらかとして使用されることになる関連するフロー定義上の設定も識別する。出力パスは、ターゲット値を固定および置換するためのセマンティクスをサポートする、設定ターゲットの変形である。3.6設定制約制約は、定義のメンバの設定値に対する制限、または関係への参与者に対する制限を識別するのに使用する。これらの制限は、設計時と展開時の両方においてインスタンス空間中で評価する。すべての設定制約は、制約定義を使用して設定値を評価する。制約定義は、設定宣言を使用して、それが制約する値を識別する。以下の制約定義は、2つの引数および1つの演算子を利用する単純な比較関数を実装し、次いで制約を評価し、最後に成功またはエラーを返す。次いで制約メンバを使用して、評価のために制約型に値を提供する。3.6.1制約定義制約定義は、入力値のセットに作用する制約を定義する。制約をパラメータ化して、カスタム挙動を選択することができ、あるいは、パラメータを使用してその挙動を定義する単純な制約エンジンをサポートすることができる。抽象オブジェクト間の既知の関係をサポートするために、単純なパラメータ値制約および複雑な制約セットについて、標準的な制約定義のセットが書かれることが考えられる。3.6.2制約メンバ制約メンバは、特定の制約定義に関する入力値のセットを識別する。メンバは、設定に関する静的な値を識別することができ、入力ステートメントを使用して制約設定をパスにバインドすることができる。3.7システムエンドポイント定義およびリソース定義この章では、抽象および具象オブジェクト定義に関するスキーマについて述べる。抽象オブジェクト定義は、設定宣言のセットを開示し、それが参与する関係に対する制約を含むことができ、関連するマネージャをランタイム内に有する。以下は、ウェブサーバについての抽象システム定義である。ウェブサーバは2つの設定を有し、また、少なくとも1つのvsite型を含むことを要する関係制約を有する。vsiteは、サーババインド情報を含む抽象エンドポイント定義である。フロントエンドウェブサーバについての具象システム定義は、ウェブサーバカテゴリを静的内容として識別し、1個から100個までの間のエンドポイントインスタンスを表すことのできる単一のbyReferenceエンドポイントメンバを含む。エンドポイントに関する具象エンドポイント定義は、システム定義内部にネストされ、vsiteに関するipEndpointをEndpoint80として定義する。staticContentOnly803.7.1オブジェクト定義抽象および具象オブジェクトは、以下の基底オブジェクト定義を拡張する。基底型定義の要素に加えて、これらは、オブジェクトが参与する関係を制約する能力も共有する。3.7.2抽象オブジェクト定義抽象オブジェクト定義は、設計表面が開示する構成単位であってすべての具象オブジェクトの派生源である構成単位を定義するのに使用する。すなわち、具象オブジェクト定義は抽象オブジェクト定義を実装すべきである。抽象オブジェクト定義は、単純な継承を追加することによってSDMオブジェクトを拡張する。すなわち、extends属性を使用して、抽象オブジェクト定義に対する基底オブジェクト定義を識別する。次いで抽象オブジェクト定義は、基底オブジェクト定義から設定および関係制約を継承する。継承を通して、オブジェクト定義は、新しい設定および制約を追加することによって抽象オブジェクト定義の設定および制約を拡張することができる。抽象オブジェクト定義はまた、それらが参与したいと思う関係に対して制約を追加することもできる。例えば、抽象オブジェクト定義は、一定の関係が存在することを必要とすることができ、あるいは関係の他方の端に配置できるオブジェクト定義を制約することができ、あるいは所与の関係に参与するインスタンス上の設定を制約することができる。3.7.2.1抽象オブジェクト定義すべての抽象オブジェクトは、それらが関連付けられたいと思うレイヤを識別することができる。これが提供されない場合、オブジェクト定義はどのレイヤでも使用できると見なされる。抽象オブジェクト定義は、それらが拡張する基底オブジェクト定義を識別することができ、その場合、そのオブジェクト定義の設定および制約を継承し、基底オブジェクト定義が参与する関係中で基底オブジェクト定義の代わりになることができる。3.7.2.2抽象エンドポイント、システム、およびリソースオブジェクト定義SDMモデル中の抽象オブジェクト定義には3つの分類がある。すなわち、抽象エンドポイント定義、抽象システム定義、および抽象リソース定義である。これらはそれぞれ、抽象オブジェクト定義の単純なリネームである。エンドポイント定義は、通信エンドポイントを表す。エンドポイント上の設定は、バインドプロセスにおけるその使用に関係する。例えばクライアントサーバプロトコルの場合、サーバエンドポイント定義は、設定スキーマを使用して、エンドポイントにバインドするのに必要な設定を識別することができ、クライアントエンドポイント定義は、クライアント特有の接続属性を開示することができる。システム定義は、データ、ソフトウェア、またはハードウェアの要素の集合を表すのに使用する。例としては、ウェブサービス、データベース、およびスイッチが挙げられる。リソース定義は、システム定義の一部として識別することのできる特定要素を取り込むのに使用する。3.7.3暗黙的な基底定義図15に示すように、別の抽象オブジェクト定義を拡張しないすべての抽象オブジェクトは、エンドポイント、システム、リソースの基底定義のうちの1つを暗黙的に拡張する。これらの基底定義は、関係宣言および制約宣言中で使用することのできる各ツリーのルートを形成する。これにより、関係または制約は、ルートから派生する任意の型を、識別されるルート定義の代わりに使用できることを示すことができる。これらのルート型は常に抽象であり、直接インスタンス化することはできない。これらの型の定義は、モデル内におけるそのインスタンス化を制御する基底制約を含む。これらはSystem.sdm.で見ることができる。3.7.4具象オブジェクト定義具象オブジェクト定義は、抽象オブジェクト定義に対する実装を提供する。実装は、オブジェクトメンバおよび関係メンバと、実装される抽象定義の設定に関する値と、新しい設定宣言と、メンバ間およびメンバに対する制約間のフローとから構築される。具象定義はまた、ネストされた定義の宣言を含むこともできる。これらの定義は、含んでいる定義の範囲内のメンバについて使用することができ、定義の範囲外の制約中で参照することができる。3.7.4.1基底具象オブジェクト定義基底具象型は、オブジェクト定義、継承する設定宣言、設計データ、オプションのマネージャ参照、名前、参与できる関係に対する制約、抽象定義の設定に関する値を提供する能力、その設定間およびそのメンバの設定間のフローを記述する能力を拡張する。次いで、具象定義が、実装する抽象定義を識別する能力を追加し、いくつかのオプション属性が、定義のバインド挙動をカスタマイズする能力を追加する。3.7.4.2オブジェクトメンバオブジェクトメンバは、抽象と具象のどちらかのオブジェクト定義を参照すべきである。これらはインスタンスのアレイを表すことができ、その場合、アレイの上限と下限を定義することができる。これらが参照メンバである場合は、オブジェクトをインスタンス化するユーザは、メンバに対するインスタンスを明示的に構築すべきである。参照メンバでない場合は、ランタイムは、外側のオブジェクトが生成されるのと同時にインスタンスを生成することになる。SDMモデルでは、親が構築されるときに生成され親が破壊されるときに破壊されるメンバを、親に関係なく存続期間を有するメンバから区別する必要がある。この目的で、IsReference属性を使用する。単純に例えると、インスタンスの生成にnewが使用されるかどうかに基づいてスタックベースとヒープベースの構築が可能なC宣言に似ている。メンバがIsReferenceとしてマークされた場合は、オペレータ側で、インスタンスを生成してメンバと関連付けるための明示的な新しい操作が必要である。こうすることにはいくつかの理由がある。1.オペレータがシステムを構築するとき、IsReferenceメンバを構築できることが開示される。これはオペレータの経験を大幅に単純化する。2.SDM文書が処理されるとき、文書のインスタンス空間が具象定義空間のインスタンス空間から変化することのできる明確な境界がある。3.7.4.3関係メンバ関係メンバは、オブジェクトメンバが生成されたときにオブジェクトメンバ間に存在する関係を識別する。関係インスタンスは、オペレータによって明示的に生成されるか、あるいはランタイムによって暗黙的に生成される。前者の例はインスタンス間のホスティング関係であり、後者の例はシステム間の通信関係である。3.7.4.3.1ホスティングメンバホストメンバは、2つのオブジェクトメンバ間のホスティング関係を宣言するのに使用する。オブジェクトメンバは、含んでいる定義の直接のメンバとすることもでき、定義とメンバシップ関係を有するネストされたメンバとすることもできる。参照されるメンバと含んでいる定義との間には、メンバシップ連鎖があるべきである。3.7.4.3.2通信メンバ通信メンバは、定義の直接のシステムメンバのエンドポイントメンバ間における通信関係を宣言するのに使用する。3.7.4.3.3包含メンバ包含メンバは、型メンバが型によって包含されることを宣言するのに使用する。各型メンバは、包含されるか委任されるかのどちらかとすることができる。包含メンバは、包含関係の親値を自動的に関係のthisポインタに設定する。3.7.4.3.4委任メンバ委任メンバは、外側の型上のエンドポイント定義メンバと、外側の型の直接のシステムメンバ上のエンドポイント定義メンバとの間の委任関係をセットアップするのに使用する。3.7.4.3.5参照メンバ参照メンバは、外側のシステムの2つの直接メンバ間またはネストされたメンバ間の参照関係をセットアップするのに使用する。3.7.4.4エンドポイント定義エンドポイント定義は、ネストされたソース型、リソースメンバ、ホスト関係メンバ、包含関係メンバ、参照関係メンバを宣言する能力を追加することにより、基底オブジェクトを拡張する。3.7.4.5サービス定義システム型は、ネストされたエンドポイント、システム型、リソース型、エンドポイントメンバ、システムメンバ、リソースメンバ、ホスト関係、包含関係、接続関係、委任関係、参照関係に対するサポートを追加することにより、基底型を拡張する。3.7.4.6リソース定義リソース型は、ネストされたリソース型定義、リソースメンバ、ホスト関係メンバ、包含関係メンバ、参照関係メンバを含むことができる。3.7.4.7関係規則オブジェクト定義の特定のインスタンスについて、このインスタンスが果たすことのできる各役割に関連するカーディナリティを、以下の表に識別する。3.7.4.7.1システム規則3.7.4.7.2エンドポイント規則3.7.4.7.3リソース規則3.7.4.7.4注あらゆるインスタンスは、ちょうど1つの包含関係と、少なくとも1つのホスティング関係とに参与すべきである。これは以下のことを意味する。A非参照メンバは包含関係を識別すべきである。b参照メンバが構築されるためには、参照メンバは包含関係を識別すべきである。c包含関係を有さない参照メンバは、他のメンバに委任することができるだけである。3.8関係関係は、型間の可能な対話を識別するのに使用する。これらはバイナリおよび有向であり、それぞれは、関係に参与することのできるインスタンスの型を識別する。関係はまた、関係に参与するインスタンスの設定を制約することもでき、関係にわたって設定値をフローすることができる。以下は、型のセクションで述べたウェブサーバ上のウェブアプリケーションについての可能なホスティング関係である。この関係は、2つのシステムのセキュリティモデルが互換性を有することを検証するという制約を含み、また、サーバ名をvsiteからvdirにコピーする設定フローメンバを含む。関係は、関係に参与することになる型メンバを識別する関係メンバを宣言することによって使用する。3.8.1関係定義基底関係定義は、オブジェクト制約およびフローを定義に追加する。オブジェクト制約は、この関係のインスタンスに参与するオブジェクトインスタンスの設定値に関するステートメントである。例えば、DCOMDistributedComponentObjectModel接続を表す通信関係が、クライアントとサーバのセキュリティ設定が互換性を有することをチェックすることができる。この場合、設定間には、設計プロセスの一部として容易に取り込むことのできる厳密な関係がある。関係に対して4つの階乗的な設定の組合せがあるが、有効な組合せはずっと少数である。フローは、関係の開発者があるインスタンスから別のインスタンスに値を転送することを可能にする。これにより、オブジェクト定義をそれらの可能な対話とは別に開発することができ、インスタンスは、特定のインスタンスを完全に記述するための関係グラフのサブセットを必要とするのではなく、情報のための参照ポイントとして自立することができる。関係の名前は、その関係を含んでいる名前空間内で固有であるべきである。3.8.2抽象関係抽象関係は、2つの抽象オブジェクト定義間で定義される関係である。これらは、2つの定義間の可能な対話を表す。3.8.2.1抽象通信関係通信関係は、エンドポイント定義間の可能な通信リンクを取り込むのに使用する。これらを使用して、独立して展開されるソフトウェア要素間の対話を記述する。通信関係スキーマは、クライアントおよびサーバエンドポイント参照を追加することによって、基底関係スキーマを拡張する。通信関係では、以下の抽象型の対の組合せが有効である。3.8.2.2抽象ホスティング関係ホスティング関係は、ゲストが構築されるためにホストが必要であることを取り込むのに使用する。1つのゲストに対して複数の可能なホストがあり得るので、このことは、ホスティング関係がホスト上にゲストを構築する任務も負うことを意味する。したがって、オブジェクトのインスタンスを生成するためには、ゲストから適合するホストへのホスティング関係があるべきである。例えば、ウェブサービスオブジェクト定義とIISオブジェクト定義との間にホスティング関係があるとする。この場合、MyWebserviceおよびMyIISがそれぞれウェブサービスおよびIISを実装するものとすると、この関係は、ホスティング関係に対するマネージャを使用してシステムMyIISのインスタンス上にシステムMyWebserviceのインスタンスを生成することが可能かもしれないことを示している。システムと関係の両方に存在する制約を評価し終えるまでは、この関係を生成することが可能になるかどうかはわからない。ホスティング関係では、以下の抽象定義の対の組合せが有効である。3.8.2.3抽象包含関係2つの抽象オブジェクト間の包含関係は、親型parentTypeに基づく具象型がメンバ型memberTypeに基づくメンバを包含できることを取り込む。包含は、親インスタンスがメンバインスタンスの存続期間を制御することができ、メンバインスタンスに挙動を委任することができることを意味する。包含関係では、以下の抽象定義の対の組合せが有効である。3.8.2.4抽象委任関係委任関係は、外側のシステムから、含まれるシステムに挙動を転送するのに使用する。これは、外側のシステム上のエンドポイントを内側のシステム上のエンドポイントに委任することによって行う。これにより、外側のシステムに向けられたであろうすべての対話を効果的に内側のシステム上のエンドポイントに転送することができる。委任は連鎖させることができ、それにより内側のシステムは、さらにその挙動を別のシステムに委任することができる。委任関係は、委任に参与することのできる抽象エンドポイント定義の対を定義する。各関係は、プロキシとして働くことのできる抽象エンドポイント定義と、挙動の委任先とすることのできる抽象エンドポイント定義とを識別する。委任関係では、以下の抽象型の対の組合せが有効である。リソースおよびシステムの委任がレイヤ間のバインドをサポートできるようにすることもできる。例えば、IISがファイルシステムの一部を、展開する必要なしに開示できるようにすることができる。3.8.2.5抽象参照関係参照関係は、ホスティング関係の従属性の他にある、インスタンス間の強力な従属性を取り込むのに使用する。これらの従属性を使用して、展開中に構築順序を制御し、インストール中および更新中にシステム間でパラメータをフローする。参照関係は強力な従属性を示すので、参照関係がシステム境界を越えることは許容できない。これは、あるシステム内のリソースが別のシステム内のリソースに対して従属性を有することはできないことを意味する。このような従属性があれば、システムはもはや独立した展開単位ではなくなる。システム間に従属性がある場合は、通信関係を使用する。通信関係は、システムの再インストールを必要とせずに、時の経過に伴って変化することができる。参照関係では、以下の抽象型の対の組合せが有効である。3.8.3暗黙的な基底関係図16に示すように、すべての抽象関係は、基底関係定義の1つを暗黙的に拡張する。これらの定義は、各関係ツリーのルートを形成する。こうすることにより、制約定義内からルート定義を参照することができ、ルート型から共通型制約を継承することができる。3.8.4具象関係具象関係は、2つの具象オブジェクト定義間の関係である。各具象関係は抽象関係を実装すべきである。抽象関係は、具象オブジェクト定義によって直接的または間接的継承によってに実装される抽象オブジェクト定義の、マッチする対の間にあるべきである。3.8.4.1ホスティング関係データセンタにアプリケーションを展開するとき、アプリケーション内のシステムに関するすべての未解決ホスティング関係を解決する必要がある。これを行うために、オペレータは、必要な各ホスティング関係につきホスティングメンバを生成することが必要になる。オペレータの作業を簡略化し、開発者が展開プロセスをガイドできるようにするために、開発者は、代わりに具象ホスティング関係を生成することができる。オペレータがアプリケーション展開時に単一のホスティングメンバを宣言するだけで済むような形で、具象ホスティング関係を使用してホスティング関係メンバのセットをグループ化する。ホスティング関係では、以下の具象型の対の組合せが有効である。ゲストは、以下の場合かつその場合に限って、ホストにバインドすることができる。Guest中の各guestMemberにつき、Host中の1つまたは複数のhostMemberがあり、この場合に、guestMember.TypeがhostMember.typeとホスティング関係を有し、guestMember.hostConstraintsがhostMember.settingsに対して妥当性を有し、hostMember.guestConstraintsがguestMember.settingsに対して妥当性を有し、guestMemberの各メンバにつき、hostMemberのメンバへのバインドがある。例えば、以下の具象関係は、レイヤ3システムBikeをレイヤ2ホストoperatingSystemにバインドする。この場合、ホスティング関係に関する設定がsystemfolderのデフォルト値で定義される。この設定が、レイヤ3アプリケーションのシステムとレイヤ2ホストのシステムとの間のホスティング関係を定義する3つのホスティングメンバのうちの1つにフローされる。systemFolder3.8.4.2参照関係2つの具象型間の具象参照関係を使用して、通信関係を含まないシステム間の特定の従属性を取り込むことができる。例えば、インストールされるあるアプリケーションに対して、別のアプリケーションがすでに存在すべきであることを取り込むことができる。参照関係では、以下の具象型の対の組合せが有効である。3.9オブジェクト制約および関係制約オブジェクト制約および関係制約は、具象空間のトポロジを定義し、オブジェクトが特定の関係中で使用されたときのオブジェクトの設定を制約するために使用する。例えば、ある抽象オブジェクト定義A内で、この抽象定義の実装が別の抽象オブジェクト定義Bのインスタンス1つを含むべきであると識別したい場合がある。少なくとも1つの適切な制約関係がすでにあるとすると、こうするには、A内で以下のように見える関係制約を使用したことになる。この制約は、Aの実装が親の役割を果たし、関係の他方の端メンバにおける型が型Bであるという、包含関係が存在すべきであることを識別する。Bの構成に対してより多くの制御が欲しい場合は、以下のように、型Bの設定に対する制約を追加することができる。この場合、メンバの名前がストリングmyPortに等しいことを必要とする制約が追加されている。また、制約は関係に追加することもできる。これらをオブジェクト制約と呼ぶ。関係内から、関係に参与するオブジェクトを制約する。関係中の各役割につき、オブジェクト定義を識別することができ、次いでこれらのオブジェクト定義に設定制約を追加することができる。関係から見ると、カーディナリティは常にminOccurs=1およびmaxOccurs=1であり、したがってこれは制約宣言には現れない。最後に、制約はネストすることができる。これにより、制約を1つに連鎖させることができ、外側の制約が、内側の制約に関するコンテキストを設定する。以下は、webAppシステムをホストするIISシステムの例であり、IISシステムはこの場合、webAppが特定の型のエンドポイントだけを含むように制約する。この場合、オブジェクト制約のグループを使用して、少なくとも1つが真となる可能性セットを指定する。ネストされた制約は、外から中へ評価できるパスを形成する。パス上の各制約は、パス上の前のインスタンスならびに現在のインスタンスの設定にアクセスすることができる。ネストされた制約の評価は、識別されるシステム内で制約が定義されているかのように行われる。以下の2つのシナリオは、fooから見て等価なはずである。第1のシナリオでは、fooが、含まれるシステムbarに対して、ネストされた制約を配置しており、第2のシナリオでは、型barがすでに制約を含んでいる。シナリオ1:シナリオ2:3.9.1制約モデル制約モデルには、ガードと述語という2つの部分がある。ガードは、述語を実行するコンテキストを定義するのに使用する。例えば関係内では、ガードを使用して、述語を実行したい型の特定の組合せを識別する。オブジェクト内では、ガードを使用して、他のオブジェクトに対する関係のセットを識別する。次いで、それらのガードの要件が満たされたときに述語が実行される。述語には2つの形がある。すなわち、設定値を妥当性検査する設定制約と、制約のセットを妥当性検査するグループ制約である。ガードの中にガードをネストすることができ、その場合、内側のガードは外側のガードが満たされたときだけチェックされる。これにより、関係構造の検証をサポートするパスを構築することができる。ガードとその述語の組合せは、ガードがマッチし述語が真に評価される回数を示すカーディナリティを有することができる。より正式には以下のとおりである。ガードは、ObjectConstraintとRelationshipConstraintのどちらかとして定義される。オブジェクト制約は、関係のいずれかの端に関連する2つのオブジェクト定義を識別する。関係制約は、関係定義およびターゲットオブジェクト定義を識別する。オブジェクト制約は任意選択または必須とすることができ、関係制約は下限と上限を有する。このカーディナリティの違いは、関係は常に2つの型しか識別できないが、型は複数の関係に参与できることを反映している。PredicateSettingsConstraintgroup述語は、規則を含む設定制約と、ガードのセットを含むグループとのどちらかである。述語は、ガードのコンテキストで評価される。設定制約の場合、述語は、ルートガードのオーナからの設定と、ネストされた各ガードによって識別されるコンテキストとを識別することができる。グループは、マッチして真に評価されるべきガードを少なくとも1つ含むガードセットを識別するのに使用される。例:1RelationshipConstraintcontainmentRelationshipwebapp01この例は、webappとの包含関係があるときは常に真に評価されるガードを示している。このガードは、多くても1回、真に評価されることができる。それ以上のマッチがある場合は、エラーがユーザに返される。この例では、ガードに述語を追加している。ガードは、関係定義とターゲット定義がマッチし、設定制約が真に評価されるときだけ、真に評価される。関係定義とターゲット定義がマッチし、設定制約が真でない場合は、エラーがユーザに返される。関係とターゲット型がマッチし、設定制約が複数回にわたって真に評価される場合は、エラーがユーザに返される。この例では、ガードの中にガードをネストしている。外側のガードが真であるとき制約を含む型がwebappも含む、内側のガードは外側のガードのコンテキストで評価される。これは、内側の関係制約がwebappインスタンスのコンテキストで評価されることを意味する。webAppが0または1個のvdirを含む場合は、内側の制約は真を返す。複数のvdirを含む場合は、制約はユーザにエラーを返す。オブジェクト制約のコンテキストが、プライマリオブジェクト定義第1のオブジェクト定義である。これは、関係制約がwebappのコンテキストで評価されることを意味する。関係制約は2つの可能なコンテキストを定義する。第1は関係であり、これはオブジェクト制約のためのコンテキストになる。第2はターゲットオブジェクト定義であり、これは関係制約のためのコンテキストになる。この例では、グループを使用して、共にwebappのコンテキストで評価されることになる2つの関係制約を含めている。グループは、関係の少なくとも一方が発火して真を返すまでエラーを生じる。この場合では、webappはvdirとdirectoryのどちらかを含むべきである。3.9.2基底制約3.9.3オブジェクト制約オブジェクト制約は、関係の役割の一方または両方に対する制約を記述する。制約は、制約が失敗した場合に制約の識別を助けるための名前を有し、役割に関連する型をターゲットとする設定制約のリストを含み、さらに、インスタンスを、役割に関連する定義から派生したオブジェクトのインスタンスになるよう制約することもできる。3.9.4オブジェクト制約グループオブジェクト制約グループは、オブジェクト制約のセットを少なくとも1つのセマンティクスを使用して評価できるよう1つにグループ化することを可能にする。グループは、オブジェクト制約の少なくとも1つが関係上のオブジェクトとマッチし、次いでそれに含まれる述語が真に評価されない限り、エラーを返す。型制約がグループの直接のメンバである場合は、制約に関するrequired属性は無視される。3.9.5関係制約関係制約は、オブジェクトが参与することのできる関係を制約するのに使用する。関係制約は、関係定義を識別し、任意選択で、関係の他方の端におけるインスタンスのオブジェクト定義と、関係のカーディナリティも識別する。エラーメッセージ中で制約を識別できるように、制約には名前が与えられる。関係制約の本体は、関係と、関係の他方の端におけるインスタンスとの両方に関する述語を含む。関係制約は、いくつかの目的で使用することができる。述語を追加せず単純にカーディナリティを使用する場合、これらは、インスタンスを正しく動作させるために提供すべき関係を識別するのに使用することができる。述語を伴う場合は、このオブジェクトが対話したいインスタンスに関する構成のセットを限定するのに使用することができる。3.9.6関係制約グループ関係制約グループは、関係制約のセットを少なくとも1つのセマンティクスを使用して述語として評価できるよう1つにグループ化することを可能にする。グループは、含まれる関係制約の少なくとも1つが関係定義およびターゲットオブジェクトとマッチし、それに含まれる述語が真を返さない限り、エラーを返す。含まれる制約中の述語のいずれかがエラーを返す場合は、これらのエラーがユーザに伝えられる。含まれる関係制約のminOccursカーディナリティは無視されるが、maxOccursカーディナリティに違反した場合は、エラーがユーザに返される。3.10オブジェクトマネージャオブジェクトマネージャは、型および関係がカスタム挙動をランタイム環境に挿入するのに使用する機構である。マネージャがサポートすることのできる役割は、管理する型ごとにいくつかある。すなわち、型のインストールに参与することができ、型のCLR表現を提供することができ、型間のバインドをどのように解決するかについてのポリシー決定に関与することができ、複雑な制約およびフローの実施を提供することができる。オブジェクトマネージャのすべての役割は、厳密名が付いたクラスへのエントリポイントとしてCLRを介して開示される。オブジェクトマネージャは、SDM中の他の型と同じようにしてパッケージされバージョニングされる。すなわち、システム配信ユニットで配信され、それらのバージョンおよび厳密名は、それらが宣言されるSDMファイルに由来する。3.10.1役割オブジェクトマネージャは、それがサポートする型ごとに、1つまたは複数の役割をサポートすることができる。これらの役割には以下のものが含まれる。a型または関係に関する制約の評価b型または関係に関するフローの評価c型に関する構築/破壊/更新サポートd型または関係上の設定に関するオブジェクト表現の開示e型または関係に関する発見の実施f型または関係をとりまく設計表面特有UIのサポート3.11SDM文書構造SDM文書は、関係とオブジェクトとマネージャとのセットについて、強力な識別、バージョニング、およびローカライゼーション情報を提供する。3.11.1情報SDM文書の情報セクションは、SDM文書の識別および管理をサポートするための、人間に読める情報を含む。3.12変更要求図17に、変更要求の例を示す。変更要求は、SDMランタイムに対する変更のセットを識別する。ランタイムに対するすべての変更は、要求の構築を可能にするAPIによる、またはXMLフォーマットの、変更要求を使用して開始される。初期の要求は、単一のアクショングループを含む。要求がランタイムによって処理されるにつれて、ネストされるグループ化によってより多くの構造が追加され、展開およびフロープロセスの結果、より多くのアクションが追加される。この評価プロセスを経て、今やターゲットマシンに対して実行される準備のできた変更要求を、完全修飾変更要求と呼ぶ。これ以上の情報については3.13章を参照されたい。3.12.1一貫性規則SDMインスタンス空間に対してアクションを実施する際は、アクション完了後にもSDMインスタンス空間中のすべてのインスタンスが一貫した状態であることを妥当性検査する。一貫した状態とは、インスタンスに適用されるすべての制約が依然として有効であることを意味する。例えば、サーバへの接続を必要とするクライアントのインスタンスを生成する場合、クライアントを生成して接続するのに使用されるアクションのシーケンスが完了したときにも、クライアントとサーバとの間に接続が存在すべきである。モデル一貫性を評価するのに使用される制約は、アクションベースで、またはアクションのセットの終わりに評価することができる。この2つの型の一貫性を、動作一貫性およびトランザクション一貫性と呼ぶ。トランザクション完了後にオブジェクトの一貫性がなくなる場合、ユーザはこのインスタンスを明示的にオフラインとしてマークすることができる。インスタンスがオフラインのときは、インスタンスに適用される制約は評価されず、他のインスタンスからはこのインスタンスが存在するようには見えない。このことは、これらのインスタンスもまたすべてオフラインとしてマークすべきであることを意味する場合がある。オフラインは、親から子へ、ホストからゲストへ伝搬される。したがって、システムをオフラインとしてマークすることは、システムによって所有されるすべてのインスタンスをオフラインとしてマークし、システム上でホストされるすべてのインスタンスをオフラインとしてマークすることになる。3.13モデル評価この章では、SDMランタイムの範囲内におけるSDMモデルの挙動について述べる。3.13.1定義空間定義空間は、SDMランタイムに知られているすべての定義を含む。図18の各ステップに、新しい定義をランタイム内にロードする例示的なプロセスを規定する。このプロセスはまた、設計表面がSDM文書を妥当性検査するときに行われるコンパイルプロセスでも共有される。3.13.1.1ロードSDM文書は、SDUの一部として、またはスタンドアロン文書としてランタイムに提示される。ファイルをディスクからロードすることが試みられる。3.13.1.2スキーマ妥当性検査第1のステップでは、SDM文書がSDMスキーマとマッチすることを妥当性検査する。この時点で、すべての未知要素、必要要素の不足している型、無効なデータを含む属性または型については、エラーを返す。3.13.1.3設定値および型解決型解決フェーズでは、SDMファイル内の型への参照をすべて解決するスキーマ中で修飾名が使用されている位置ならどこでも。まず、文書の範囲内にあるすべての型参照が有効であることを妥当性検査する。これらはすべて、エイリアスを含まない型参照である。次いで、すべてのインポートステートメントを解決することを試みる。インポートステートメントを解決することができない場合は、名前空間ロードエラーを生成し、インポートステートメントを解決することができる場合は、名前空間内で型を突き止めることを試みる。SDMファイルから名前空間をロードしなければならない場合、名前空間解決プロセスは他のエラーを生じる場合がある。3.13.1.4パス解決パス解決フェーズの間、文書中で定義されたメンバおよび設定へのパスをすべて解決することを試みる。未解決の型を有するメンバまたは設定を参照するパスはエラーを生じない。3.13.1.5関係への参与型空間で、型宣言がそのメンバの関係参与に関してどんな制約にも違反しないことをチェックする。これを行うために、関連する設定制約を有さないすべての型および関係制約を評価する。3.13.1.6インスタンスシミュレーションインスタンスシミュレーションでは、失敗するとわかっている制約は識別し、ユーザ入力に基づいて失敗する場合としない場合がある制約にはフラグを立てないようにすることができるような方式で、値をフローして制約を評価することを試みる。こうするためには、インスタンス空間のモデルを構築し、このインスタンス空間に基づくフローおよび制約を評価する。フローまたは制約がエラーになることがわかっている場合はエラーを発し、エラーになる可能性がある場合は警告を発する。すべてのbyReferemceシステム上のminOccurs制約を使用して、インスタンス空間変更要求を構築する。minOccursが0のときは、単一のインスタンスを生成し、オプションとしてマークする。次いで、標準の変更要求に使用したのと同じ展開プロセスおよびフロープロセスを通して変更要求を渡す。次いで、完全に定義された入力値を有するすべてのフローを評価する。入力値が固定でなく、ユーザによって変更できる場合は、このフローの出力を仮としてマークする。仮入力は、それを消費するどんなフロー演算によっても連鎖することになる。フローが完全な入力値を有さず、ユーザが値を提供できる場合は、このフローのすべての出力を未定義としてマークする。オプションのシステムからのフローもまた、仮の値を生じる。値をフローした後は、これらの値に基づいて制約を評価する。値を供給できなかった制約には警告を発する。また、未定義の値であるために制約が評価できなかったときにも警告を発する。3.13.2インスタンス空間モデル評価プロセスは、宣言変更要求をサブミットすることによって開始する。この要求は、ランタイム内のインスタンスをターゲットとした生成、更新、または削除操作のセットを含む。次いで、図19に示すように、要求を一連のパイプラインステージに通した後、必要な変更をターゲットシステムに対して実施する。以下の各章で、各展開expansionステップの役割を概説する。3.13.2.1要求のサブミットシステムに対する変更を開始するために、オペレータまたはプロセスは、変更要求をサブミットすべきである。変更要求は、オペレータがランタイム内のインスタンスに対して実施したいと思うアクションのセットを含む。これらのアクションは、3つのグループ、すなわち生成アクション、更新アクション、削除アクションに分類される。次いで要求は、グループとして完了または失敗すべき原子アクションセットとして扱われる。これにより、制約妥当性検査プロセスは、アクションセットがモデルに対する有効な変更をもたらすかどうかを評価するときに、要求中のすべてのアクションを考慮することができる。3.13.2.1.1型解決型解決フェーズでは、変更要求中で参照されるすべての型およびメンバを解決する。変更要求は、これらがすでにランタイムによってロードされていると見なす。これらが存在しない場合は、ランタイムはロード/コンパイルアクションを開始する必要がある。3.13.2.1.2パス解決パス解決フェーズの間に、変更要求内の、既存のインスタンスおよび生成アクションによって定義されたインスタンスへの参照を解決する。3.13.2.2展開Expansion展開は、変更要求について、要求を実行するのに必要な残りのすべてのアクションをポピュレートするプロセスである。一般にこれらのアクションは、型インスタンスおよび関係インスタンスに対する構築アクションおよび破壊アクションである。理論的には、オペレータは、インスタンスを構築または破壊するのに必要なすべてのアクションに関する詳細を提供することができるが、これは変更要求オーサリングプロセスを非常に複雑にするので、必要とされない。そうではなく、このプロセスをできるだけ自動化することが試みられる。オペレータは、byRerefenceメンバに対するアクションを識別することにより、オペレータが望む変更に関するキー情報を提供する。すると、ネストされたbyReferenceおよびbyValueメンバと関係に対して、アクションの残りが埋められる。3.13.2.2.1値メンバ展開ステージの間、すべての非参照型メンバを識別する。これらのメンバのカーディナリティはわかっており、必要なすべてのパラメータはわかっている。したがって、各メンバごとに、親の生成中であるメンバについては生成要求を変更要求に追加する。変更要求が破壊動作を含む場合は、それらに含まれるすべてのインスタンスについて破壊動作を追加する。3.13.2.2.2参照メンバの展開発見一般に、参照メンバを構築するには、値メンバよりも多くの情報が必要である。これらのカーディナリティはしばしば未定義であり、インスタンスが構築されるための値を必要とする展開時設定を有する可能性がある。したがって、byReferenceメンバを展開するプロセスは、インスタンスに関する情報として、ランタイムが提供できるよりも多くの情報を必要とする可能性がある。この情報を得るためのプロセスを、発見と呼ぶ。発見のプロセスは、構築または更新アクションの一部として参照型メンバをポピュレートする。発見をサポートするオブジェクトマネージャを有する参照メンバだけが、このプロセスに参与する。新しいインスタンスが発見されたときは、まず、インスタンス特有のキー値を使用して、このインスタンスがまだSDMデータベース中に存在しないことをチェックする。新しいインスタンスであることがわかれば、次いで、発見中のメンバの型に従ってインスタンスを分類する。インスタンスがメンバにマッチしない場合、または曖昧なマッチがある場合は、メンバ参照は空白のままにし、インスタンスはオフラインおよび不完全としてマークする。3.13.2.2.3関係の展開構築されることになる型インスタンスがすべてわかった後で、型インスタンスを1つにバインドする関係インスタンスを生成する。型インスタンスの破壊中である場合は、型インスタンスを参照するすべての関係インスタンスを削除する。関係を生成するには、メンバ空間に目を向けて、インスタンス間に存在すべき関係の構成を識別する。型メンバが1よりも大きいカーディナリティを有する場合は、関係のトポロジを推論しなければならない。これをどうやって行うかについては、XX章で詳細に論じる。3.13.2.3フローフローステージの間、すべての関係インスタンスにわたってフローを評価する。このステージでは、改変されたパラメータフローの影響を受けたインスタンスについて、変更要求に更新要求を追加することができる。フローは、変更要求の結果として設定が更新されたインスタンスのセットを判定することによって評価する。これらのそれぞれにつき、修正された設定に依存する送出設定フローがあればそれを評価し、変更されたインスタンスのセットにターゲットノードを追加する。このプロセスは、セットが空になるまで、またはセットが循環を含むまで継続する。3.13.2.4重複検出重複検出のプロセスでは、展開されたインスタンスを、SDMデータ記憶域中にすでに存在するインスタンスと照合する。例えば、別のアプリケーションが共有ファイルをインストールしたかどうかを検出する。インスタンスがすでに存在することが検出されたときは、既存のインスタンスのバージョンに応じて、以下のようないくつかのアクションの1つを実施することができる。aインストールを失敗にする。bインスタンスを参照カウントする。cインスタンスをアップグレードする。dインストールを並行して実施する。3.13.2.5制約評価制約評価フェーズの間には、変更要求が処理された後でもモデル中のすべての制約がまだ有効となるかどうかをチェックする。3.13.2.6要求の順序付けこの時点では完全なアクションリストがあるので、システム間の関係を使用して、有効な変更順序付けを決定することができる。3.13.2.7実行マシン特有の順序付けされたアクションセットのサブセットを配信する。これらのマシン特有セットのマシン間同期をサポートすべきである。3.13.2.8要求返却変更は、影響を受けるホスティング関係に基づいて変更要求を配信可能部分に分解することによって行う。すべての部分が完了または失敗すると、ランタイム内で結果を照合し、概要をユーザに返す。3.13.3展開の詳細この章では、型および関係に関する展開expansionプロセスについて詳細に検討する。3.13.3.1参照メンバの展開発見ホスティング関係が、ある型の新しいインスタンスを構築することを担うのと同様にして、ホスティング関係は、既存の型インスタンスの発見を行うのにも使用される。ある型のインスタンスがホスト上で表される方式はホスティング関係だけが意識しているので、これを行うために、ホスティング関係を独特に配置する。参照メンバに発見のマークが付されているとき、ホスティング関係が発見をサポートするかどうかをチェックする。サポートする場合は、その関係にホストインスタンスを渡し、関係がホスト上で見つけたゲストインスタンスに対する構築アクションを返すよう関係に要求する。検証を使用して、インスタンスがもう存在しないことを発見する。この場合もまたホスティング関係を使用して、ホスト上のゲストの存在を検証する。ゲストがもう存在しない場合、ホスティング関係は、破壊アクションを変更要求に追加する。3.13.3.2非参照メンバの展開ランタイムは、変更要求内の構築または破壊アクションについてすでに識別された型の各非参照メンバに対して構築または破壊アクションを単に追加することにより、すべての非参照メンバ展開を処理する。3.13.3.3通信関係の展開2つの型メンバ間に通信関係メンバが存在する場合にオペレータが通信関係のインスタンスを指定していない場合は、完全に接続されたメッシュがメンバ間にあると仮定することにより、通信関係を展開する。これは何を意味しているだろうか。2つのメンバがメンバ空間で接続されている場合、各メンバのすべてのインスタンスは相互に見えていなければならない。図20に示すように、以下の2つのメンバがある場合、インスタンス空間トポロジはメンバのカーディナリティによって制約される。1800に、例示的な2つのメンバを示す。1802に、最大の2つのインスタンス間の単純なポイントツーポイント関係を示す。1804に、接続のファンアウトfunoutを示す。一例は、サーバのセット全体にわたって要求の負荷バランスをとることのできるクライアントであろう。1806に、接続のファンインfaninを示す。一例は、単一のサーバを共有するクライアントグループであろう。1808に、これらの場合の組合せを示す。1808では、クライアントのセットがサーバのセットを共有している。通信リンクを構築するとき、委任エンドポイントが削除されたとしても存在するであろうすべての通信関係とマッチする接続になるように、委任エンドポイントはトランスペアレントになる。図21に、2つの構造1902および1904を示す。これらは、インスタンスA、B、C間の接続に関する限り等価である。3.13.3.4ホスティング関係の展開ホスティング関係が曖昧な場合、オペレータまたはホスティング関係のマネージャが正しいトポロジを判定することが必要である。ホスティング関係が展開をサポートする場合は、ホストとゲストのセットを関係マネージャに渡し、正しい構築アクションを返すようマネージャに要求する。マネージャが展開をサポートしない場合は、オペレータがより多くの情報を提供することができるように、オペレータに変更要求を返す。3.13.3.5参照関係の展開3.13.3.6包含関係の展開包含関係が曖昧であることはないので、ランタイムは常に適切な構築アクションを変更要求に追加することができる。3.13.3.7委任関係の展開展開では、委任関係は通信関係と同じ規則に従う。3.13.4フロー3.13.5実行3.14SDMインスタンス空間以下の章では、SDMランタイムのインスタンス空間に関するオブジェクトモデルを定義する。インスタンス空間を使用して、SDMによってモデル化されるシステムの構成に対する変更を追跡する。図22に、インスタンス空間の概観を提供する例示的なUML図を示す。ボックス2002、2004、2006、2008は、この文書の他の章で定義した型を示す。インスタンス空間は、変更要求によって開始されるバージョニングされた変更をとりまいて構築される。各インスタンスは、実行中のインスタンスに加えられた原子的な変更を表す線形に連続するバージョンを有することができる。将来のバージョンが、実行中のシステムに伝わる前にランタイム内に存在することもできる。SDMモデルのこのバージョンでは、所与のインスタンスに対して線形変更だけが可能である。将来は、バージョン分岐が可能になり、バージョン解決モデルが導入されるであろう。これにより、特定のインスタンスに対して複数の変更を未解決とすることが可能になる。線形バージョニングが可能なので、前の変更の上に形成される一連の変更要求をロードすることができる。これは、ローリングアップグレードなどのプロセス中に実施される場合のある一連のアクションの事前妥当性検査をサポートする。3.14.1SDMインスタンスすべてのインスタンスは、SDMインスタンスから派生する。これらは、設定スキーマに関する値を定義する要素と、インスタンスの定義上のメンバとマッチするメンバのリストを定義する要素とを共有する。これらはまた、インスタンスの固有の識別子と、インスタンスのバージョン番号と、インスタンスの名前と、このバージョンがシステムの実行状態を表すかどうかを示すフラグとを定義する属性のセットも共有する。3.14.2メンバmemberは、インスタンスのメンバを、参照されるインスタンスのセットに関連付けるのに使用する。インスタンスのメンバは、インスタンスの定義によって定義される。参照されるインスタンスは、メンバに対して生成されたインスタンス、またはメンバが委任されるインスタンスである。メンバはアレイを表すことができ、その場合は複数の被参照インスタンスがあるものとすることができる。3.14.3変更changeは、インスタンス状態に対する変更を表す。これは、変更要求を、影響を受けるインスタンスのセットに関連付ける。また、変更のステータスXXX章参照、および変更が実行された場合の変更応答も識別する。3.14.3.1変更ステータス変更要求は、以下の状態の1つまたは複数をとることができる。notStarted-変更要求に対して実行が試みられていないことを示す。inProgress-現在実行されていることを示す。complete-変更要求がうまく完了したことを示す。failed-変更要求が失敗し、変更が未完了の状態であることを示す。rolledBack-失敗した変更要求がうまくロールバックされたことを示す。3.14.4具象オブジェクトインスタンス具象オブジェクトインスタンスは、型属性によって識別される具象型のインスタンスを表す。インスタンスには実世界表現がある可能性があるので、インスタンスがその実世界の相対物と同期しているかどうか追跡する必要がある。また、この変更の結果としてインスタンスがオンラインになるかどうかを知ることも望まれる。オンラインのインスタンスは、そのすべての制約に関して有効であるべきである。オフラインのインスタンスは、それが参与している通信関係の他の参与者には見えない。インスタンスが不完全な場合は、インスタンスをオンラインにできるようになる前に、さらに変更要求が必要である。3.14.5関係インスタンスrelationshipinstanceは、識別された関係型のインスタンスを表す。関係には直接的な実世界表現がないので、関係が同期しているまたはオンラインであるかどうかに関する情報を保持している必要がある。また関係は、それらの制約を満たせない可能性もあるが、相対的に単純なので、不完全であることは予想されない。3.14.5.1containmentinstanceこれは包含関係のインスタンスを表す。3.14.5.2communicationinstanceこれは通信関係のインスタンスを表す。3.14.5.3delegationinstanceこれは委任関係のインスタンスを表す。3.14.5.4hostinginstanceこれはホスティング関係のインスタンスを表す。3.14.5.5referenceinstanceこれは参照関係のインスタンスを表す。3.14.6インスタンスinstancesグループは、SDMインスタンスファイル中に存在することのできるインスタンス要素のセットを表す。3.14.7インスタンス参照3.14.7.1instanceRefinstanceRefは、インスタンスへの単純な参照である。参照が変更要求のコンテキストでなされ、インスタンスが変更要求の影響を受けるのでない限り、デフォルトではisCurrentインスタンスになる。3.14.7.2instanceVersionRefinstanceVersionRefは、インスタンスの特定のバージョンを識別する。3.15展開deploymentユニットの構造要件SDM型のセットをインストールするのに必要なすべてのビットを含む。署名およびバージョニングができる。容易に構築/パッケージ/出荷できる。参照または包含によって他のSDUを参照することができる。SDM型定義の展開セクションがSDU中のファイルを直接参照する。3.16ローカライゼーションSDMモデルのどの部分がローカライゼーションをサポートし、システムの設計および展開を通してどのようにローカライゼーションがサポートされるかを決定する必要がある。第1の手法:ローカライゼーションは、個々の型および管理すべき型に完全に任される。ローカライゼーションは、制約を介して暗黙的である。ローカライゼーションは第1タイプ市民firsttypecitizenではない。これは以下のことを意味する。aSDUは、特定バージョンの型の実装を含むことができる。すなわち、特定バージョンの実装が1つある。このことは、違いがローカライゼーションのみに基づく実装はあり得ないことを意味する。したがって、各実装は一定範囲のロケールをサポートすべきであり、あるいは実装は異なる型とすべきであるこの目的でバージョニングを使用するのは良くないことである。b次いで、リソースをmixinとして使用して特定バージョンをサポートすることによって、あるいは、異なるバージョンをサポートする実装を識別する型のセットを使用することによって、ローカライゼーションを達成する。cクライアントは、ローカライズされたバージョンのサーバを区別/要求することはできない。第2の手法:ローカライゼーションは、名前およびバージョンに沿った識別の第1タイプ市民である。このことは、型への参照が行われる位置ではどこでもローカライゼーションを考慮すべきであることを意味する。aクライアントはこの場合、包含関係、ホスティング関係、通信関係のいずれでも、ローカライズされたバージョンのサーバを区別することができる。b展開エンジンは、ローカライゼーションを意識すべきであり、ローカライズされたバージョンの型間でオペレータが選択できるようにすべきである。cSDUは名前、バージョン、およびロケールで識別される。あるいはSDUは、違いが場所のみに基づく複数の実装を含むことができる。第1の場合は、ローカライズされないコードを別個のSDU中に配置すべきなので、よりきめ細かいSDUのパッケージングを意味する。第2の場合は、同じ名前で複数のSDUを有することができることを意味する。第2の手法は、ロケールが制約として広く使用された場合、設計/UIから見て非常に複雑になる可能性がある。例えば、エンドポイントがローカライズされた場合、またはホストがそれらのゲストをローカライズした場合、接続/配置を見つけるのはずっと複雑になる。第2の手法を、提案した機構として第1の手法のbと共に使用した場合、複雑さはより扱いやすいかもしれないが、ローカライズされたリソースを誰かが識別し、パッケージし、発送しなければならない。3.17バージョニングおよび変更管理3.17.1一般的なコメントシステムをその場でバージョニングできることが望ましい。すなわち、インスタンス識別を変更せずにQFEをSQLに適用できることが望ましい。これは、インスタンスの型を変更することを意味する。バージョニングポリシーが、許容されるバージョン変更を制御できるようにすることが望ましい。例えば、システム型の設計者が、システムのメンバに対するバージョニングポリシーがどのくらい厳しいかを選択することができ、あるいはオペレータが、セキュリティ上の理由から一方的にメンバのバージョンをアップグレードすることができる。バージョニング変更の伝搬を制限することが望ましい。例えば、メンバの型を変更した場合に、システムの型を変更しなければならず、したがって型変更をルートに伝搬しなければならないのは望ましくない。途切れのある変更は、バージョン番号の最初の2つの部分の変化によって示され、途切れのない変更は、バージョン番号の第2の2つの部分の変化によって示される。例示的なコンピュータ環境図23に、本明細書に述べた技法を実施するのに使用できる一般的なコンピュータ環境2300の例を示す。コンピュータ環境2300は、コンピューティング環境の一例にすぎず、コンピュータおよびネットワークアーキテクチャの使用または機能の範囲に関してどんな制限も意味するものではない。またコンピュータ環境2300は、この例示的なコンピュータ環境2300に示すコンポーネントのいずれか1つまたは組合せに関してどんな依存も要件も有するものと解釈すべきではない。コンピュータ環境2300は、コンピュータ2302の形の汎用コンピューティングデバイスを含む。コンピュータ2302は、例えば図1のコンピューティングデバイス102とすることもでき、図2の開発システム202を実装することもでき、図2のコントローラ206とすることもでき、図2のターゲットデバイス232とすることもでき、図6のコントローラ520またはターゲット522とすることもできる。コンピュータ2302のコンポーネントには、限定しないが、1つまたは複数のプロセッサまたは処理ユニット2304と、システムメモリ2306と、プロセッサ2304を含めた様々なシステムコンポーネントをシステムメモリ2306に結合するシステムバス2308とを含めることができる。システムバス2308は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、AGPacceleratedgraphicsport、プロセッサバスまたはローカルバスを含めて、いくつかのタイプのバス構造の任意の1つまたは複数を表す。例えばこのようなアーキテクチャには、ISAIndustryStandardArchitectureバス、MCAMicroChannelArchitectureバス、EISAEnhancedISAバス、VESAVideoElectronicsStandardsAssociationローカルバス、およびメザニンバスとも呼ばれるPCIPeripheralComponentInterconnectsバスを含めることができる。コンピュータ2302は通常、様々なコンピュータ可読媒体を備える。このような媒体は、コンピュータ2302からアクセス可能な任意の利用可能な媒体とすることができ、揮発性と不揮発性、リムーバブルとノンリムーバブルの両方の媒体が含まれる。システムメモリ2306は、ランダムアクセスメモリRAM2310などの揮発性メモリ、および/または、読出し専用メモリROM2312などの不揮発性メモリの形のコンピュータ可読媒体を含む。ROM2312には、起動中などにコンピュータ2302内の要素間で情報を転送するのを助ける基本ルーチンを含むBIOSbasicinput/outputsystem2314が記憶されている。RAM2310は通常、プロセッサ2304からすぐにアクセス可能な、かつ/またはプロセッサ2304が現在作用している、データおよび/またはプログラムモジュールを含む。コンピュータ2302は、その他のリムーバブル/ノンリムーバブル、揮発性/不揮発性コンピュータ記憶媒体を備えることもできる。例えば図21には、ノンリムーバブルかつ不揮発性の磁気媒体図示せずに対して読み書きするためのハードディスクドライブ2316と、リムーバブルかつ不揮発性の磁気ディスク2320例えばフロッピー登録商標ディスクに対して読み書きするための磁気ディスクドライブ2318と、CDcompactdisc-ROMやDVDDigitalVersatileDisc-ROMやその他の光媒体などリムーバブルかつ不揮発性の光ディスク2324に対して読み書きするための光ディスクドライブ2322を示す。ハードディスクドライブ2316、磁気ディスクドライブ2318、および光ディスクドライブ2322はそれぞれ、1つまたは複数のデータ媒体インタフェース2326によってシステムバス2308に接続される。あるいは、ハードディスクドライブ2316、磁気ディスクドライブ2318、および光ディスクドライブ2322は、1つまたは複数のインタフェース図示せずによってシステムバス2308に接続されてもよい。各ディスクドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性記憶域をコンピュータ2302に提供する。この例では、ハードディスク2316、リムーバブルな磁気ディスク2320、およびリムーバブルな光ディスク2324が示してあるが、磁気カセットまたは他の磁気記憶デバイス、フラッシュメモリカード、CD-ROM、DVDまたは他の光記憶装置、ランダムアクセスメモリRAM、読出し専用メモリROM、EEPROMElectronicallyErasableandProgrammableReadOnlyMemoryなど、コンピュータからアクセス可能なデータを記憶することのできる他のタイプのコンピュータ可読媒体も、この例示的なコンピューティングシステムおよび環境を実現するのに利用できることを理解されたい。ハードディスク2316、磁気ディスク2320、光ディスク2324、ROM2312、および/またはRAM2310には、任意の数のプログラムモジュールを記憶することができる。例えばこれらには、オペレーティングシステム2326、1つまたは複数のアプリケーションプログラム2328、その他のプログラムモジュール2330、およびプログラムデータ2332が含まれる。このようなオペレーティングシステム2326、1つまたは複数のアプリケーションプログラム2328、その他のプログラムモジュール2330、およびプログラムデータ2332またはこれらの何らかの組合せはそれぞれ、分散ファイルシステムをサポートする常駐コンポーネントの全部または一部を実装することができる。ユーザは、キーボード2334やポインティングデバイス2336例えばマウスなどの入力デバイスを介して、コンピュータ2302にコマンドおよび情報を入力することができる。その他の入力デバイス2338具体的には図示せずには、マイクロホン、ジョイスティック、ゲームパッド、衛星受信アンテナ、シリアルポート、スキャナ、および/またはその他を含めることができる。これらおよび他の入力デバイスは、システムバス2308に結合された入出力インタフェース2340を介してプロセッサ2304に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバスUSBなど、その他のインタフェースおよびバス構造で接続されてもよい。モニタ2342または他のタイプの表示デバイスも、ビデオアダプタ2344などのインタフェースを介してシステムバス2308に接続することができる。モニタ2342に加えて、その他の出力周辺デバイスには、スピーカ図示せずやプリンタ2346などのコンポーネントを含めることができ、これらは入出力インタフェース2340を介してコンピュータ2302に接続することができる。コンピュータ2302は、リモートコンピューティングデバイス2348など1つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。例えばリモートコンピューティングデバイス2348は、パーソナルコンピュータ、携帯コンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、またはその他の一般的なネットワークノードなどとすることができる。リモートコンピューティングデバイス2348は、コンピュータ2302に関して本明細書に述べた要素および機能の多くまたはすべてを備えることのできる携帯コンピュータとして示されている。コンピュータ2302とリモートコンピュータ2348との間の論理接続を、ローカルエリアネットワークLAN2350および一般的なワイドエリアネットワークWAN2352として示す。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットでよくみられるものである。コンピュータ2302は、LANネットワーキング環境で実現されるときは、ネットワークインタフェースまたはアダプタ2354を介してローカルネットワーク2350に接続される。WANネットワーキング環境で実現されるときは通常、ワイドネットワーク2352を介した通信を確立するためのモデム2356または他の手段を備える。モデム2356は、コンピュータ2302に内蔵でも外付けでもよく、入出力インタフェース2340または他の適切な機構を介してシステムバス2308に接続することができる。図示のネットワーク接続は例示的なものであり、コンピュータ2302と2348の間に通信リンクを確立する他の手段を採用することもできることを理解されたい。コンピューティング環境2300で示すようなネットワーク化された環境では、コンピュータ2302に関して示すプログラムモジュールまたはその一部を、リモートのメモリ記憶デバイスに記憶することができる。例として、リモートアプリケーションプログラム2358が、リモートコンピュータ2348のメモリデバイス上にある。アプリケーションプログラム、およびオペレーティングシステムなどその他の実行可能プログラムコンポーネントは、ここでは説明のために個別のブロックとして示してある。ただし、このようなプログラムおよびコンポーネントは、様々な時点でコンピューティングデバイス2302の種々の記憶コンポーネント中にあり、コンピュータのデータプロセッサによって実行されることを理解されたい。本明細書で、様々なモジュールおよび技法は、1つまたは複数のコンピュータまたは他のデバイスによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で述べることができる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。通常、プログラムモジュールの機能は、様々な実施形態で望まれるように結合または分散させることができる。これらのモジュールおよび技法の実装形態は、何らかの形のコンピュータ可読媒体に記憶するか、コンピュータ可読媒体を介して送信することができる。コンピュータ可読媒体は、コンピュータからアクセスできる任意の利用可能な媒体とすることができる。限定ではなく例として、コンピュータ可読媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術で実現された、揮発性および不揮発性、リムーバブルおよびノンリムーバブルな媒体が含まれる。コンピュータ記憶媒体には、限定しないがRAM、ROM、EEPROM、フラッシュメモリまたは他のメモリ技術、CD-ROM、DVDまたは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイスが含まれ、あるいは、所望の情報を記憶するのに使用できコンピュータからアクセスできる他の任意の媒体が含まれる。通信媒体は通常、搬送波や他のトランスポート機構などの変調データ信号中に、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを組み入れたものである。通信媒体には、任意の情報送達媒体も含まれる。変調データ信号という語は、情報が信号中に符号化される形で1つまたは複数の特性が設定または変更された信号を意味する。限定ではなく例として、通信媒体には、配線式ネットワークや直接配線式接続などの配線式媒体と、音響、無線周波、赤外線、その他の無線媒体などの無線媒体とが含まれる。以上の任意の組合せもコンピュータ可読媒体の範囲に含めるべきである。別法として、このフレームワークの一部をハードウェアで、あるいはハードウェア、ソフトウェア、および/またはファームウェアの組合せで実現することもできる。例えば、1つまたは複数の特定用途向け集積回路ASICまたはプログラム可能論理デバイスPLDを、このフレームワークの1つまたは複数の部分を実現するように設計またはプログラムすることができる。結び本発明を構造上の特徴および/または方法上の動作に特定の言葉で述べたが、添付の特許請求の範囲に定義する本発明は、述べた具体的な特徴または動作に必ずしも限定されないことを理解されたい。そうではなく、これらの具体的な特徴および動作は、特許請求する本発明を実施する例示的な形として開示するものである。さらに、これらの特許請求の範囲は、範囲および主題の点で例示的なものである。本明細書に述べた特徴に関するその他多くの組合せおよび下位の組合せが、後に、本出願に対する優先権を主張する特許出願において請求される場合もある。