JP2004272908A - システムの設計、展開、管理のフェーズを統合する方法 - Google Patents

Abstract

【課題】 システムの設計、展開、管理のフェーズを統合する。
【解決手段】 いくつかの態様によれば、システムの設計、展開、管理のフェーズを統合することは、システム定義モデルを使用してシステムを設計することを含む。その後、システム定義モデルを使用して、システムを１つまたは複数のコンピューティングデバイス上に展開し、システムの展開後、システム定義モデルを使用して、１つまたは複数のコンピューティングデバイス上に展開されたシステムを管理する。
【選択図】 図２

Description

本発明は、分散コンピューティングシステムのためのアーキテクチャに関する。

インターネットの使用は、過去数年にわたって爆発的に増加しており、引き続き増加中である。人々は、電子メール、オンラインショッピング、ニュースおよび情報の収集、音楽鑑賞、ビデオクリップ視聴、求職など、ワールドワイドウェブ（または単に「ウェブ」）上で提供される多くのサービスによって非常に快適になった。インターネットベースのサービスに対する需要の増加についていくため、ウェブサイトをホストし、これらのサイトのためのバックエンドサービスを提供し、サイトに関連するデータを記憶するための専用のコンピュータシステムは、著しく増加した。

分散コンピュータシステムのタイプの１つは、データセンタ（インターネットデータセンタ（ＩＤＣ）やエンタープライズデータセンタ（ＥＤＣ）など）だが、これは、ネットワークベースのサービスをホストするための多くのコンピュータを収容する特別設計された複合体である。データセンタは「ウェブファーム」または「サーバファーム」という名前で呼ばれることもあるが、通常、温度と湿度が調節された物理的に安全な建物内に、何百台から何千台までものコンピュータを収容する。データセンタは一般に、インターネットアクセス、信頼性のある電力供給、および安全な動作環境を提供する。

今日、大規模なデータセンタは複雑であり、しばしば複数のアプリケーションをホストすることが要求される。例えばウェブサイトの中には、数千台のコンピュータを運用し、多くの分散アプリケーションをホストするものもある。これらの分散アプリケーションは複雑なネットワーキング要件を有する場合が多く、複雑なアプリケーションをサポートするために、オペレータがコンピュータを一定のネットワークスイッチに物理接続すること、ならびにデータセンタ内の配線構成を手作業で構成することが必要である。この結果、アプリケーション要件に適合するように物理ネットワークトポロジを構築するこの作業は、時間のかかる厄介なプロセスになる可能性があり、人為的ミスを被りやすい。

したがって、分散アプリケーションを物理的なコンピューティングシステム上で設計および展開する（ｄｅｐｌｏｙ）ための、改善された技法が必要とされている。

本発明は、このような状況に鑑みてなされたもので、その目的とするところは、効率的にシステムを設計、展開、管理可能な、システムの設計、展開、管理のフェーズを統合する方法を提供することにある。

システムの設計、展開、管理のフェーズを統合することについて本明細書に述べる。

いくつかの態様によれば、システム定義モデルを使用してシステムを設計する。その後、システム定義モデルを使用して、システムを１つまたは複数のコンピューティングデバイス上に展開する。システム展開後、システム定義モデルを使用して、１つまたは複数のコンピューティングデバイス上に展開されたシステムを管理する。

以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。各図面を通して、同じ機構を参照する場合には同じ番号を使用する。

以下の開示では、大規模なアプリケーションサービスを有する分散コンピューティングシステムを設計および実現するためのアーキテクチャに関連するいくつかの態様について述べる。この開示は、システム定義モデル（ＳＤＭ）（サービス定義モデル（ＳＤＭ）と呼ばれることもある）と、ＳＤＭランタイム環境とに関する解説を含む。ＳＤＭは、アプリケーション設計者が分散コンピュータアプリケーションおよびデータセンタを抽象的な方式で設計するためのツールおよびコンテキストを提供する。このモデルは、物理的なコンピュータリソースおよびソフトウェアによって最終的に実施されることになるアプリケーションの機能単位を表す要素のセットを定義する。モデル要素には、コンポーネントによって表される機能動作をどのように指定すべきかを指示するスキーマが関連する。

本明細書では、用語「配線」を「接続」、「通信」または「通信関係」と言う場合もある。また、用語「システム」を「モジュール」と言い、用語「リソース空間」を「リソース」と言う場合もある。さらに、用語「アプリケーション空間」を「アプリケーション」と言い、用語「インスタンス空間」を「インスタンス」と言う場合もある。さらに、用語「クラス」を「抽象定義」と言い、用語「ポート」を「エンドポイント」と言い、用語「型」を「定義」と言う場合もある。

図１に、例示的なネットワーク１００を示す。ネットワーク１００の設定では、複数（ｘ）のコンピューティングデバイス１０２（１）、１０２（２）、．．．、１０２（ｘ）がネットワーク１０６に結合されている。ネットワーク１０６は、様々な従来型のネットワークプロトコル（公衆および／またはプロプラエタリプロトコルを含む）を採用した、様々な従来型のネットワークトポロジおよびタイプ（配線および／または無線ネットワークを含む）のいずれかを表すものとする。ネットワーク１０６には、例えばローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネットの一部、その他を含めることができる。ネットワーク１００の設定は、例えばデータセンタ（例えばインターネットデータセンタ（ＩＤＣ））、オフィスまたはビジネス設定、家庭設定、教育または研究施設、小売または販売設定、データストレージ設定などを含めた、幅広い設定のいずれかを表す。

コンピューティングデバイス１０２は、デスクトップＰＣ（personal computer）、ワークステーション、メインフレームコンピュータ、サーバコンピュータ、インターネット装置、ゲーム用コンソール、ハンドヘルドコンピュータ、携帯電話、パーソナルディジタルアシスタント（ＰＤＡ）などを含めた、様々な従来型のコンピューティングデバイスのいずれかとすることができる。１つまたは複数のデバイス１０２は、同じタイプのデバイスでもよく、あるいは異なるタイプのデバイスでもよい。さらに、複数のデバイスが同じタイプのデバイスである場合でも、複数のデバイスはなお、異なる形で構成することもできる（例えば、２つのデバイス１０２はサーバコンピュータだが、異なるプロセッサ、異なる容量のランダムアクセスメモリ（ＲＡＭ）、異なるサイズのハードディスクドライブなど、異なるハードウェア構成を有することもできる）。

１つまたは複数のコンピューティングデバイス１０２は、ネットワーク１００の設定に追加した後で再構成することもできる。例えば、特定のコンピューティングデバイス１０２が、ある期間にわたって（例えば分、時間、日、月などの単位で）動作して１つの機能を実施し、次いで管理者が、異なる機能が望ましいと決定することもできる（例えば、サーバコンピュータからワークステーションコンピュータへの変更、ウェブサーバからローカルなファイルサーバへの変更）。

図２は、システム定義モデルを使用する例示的なアーキテクチャ２００を示すブロック図である。ＳＤＭは、システムのライフサイクル全体にわたって使用されるように設計される。システムは、協働して共通の機能を達成することのできる関連するソフトウェアおよび／またはハードウェアリソースのセットである。このようなシステムの一例はアプリケーションであり、アプリケーションは、コンピューティングデバイスによって稼動または実行されて様々な機能を実施することのできる命令のセットを指す。アプリケーションの例としては、ゲームなどの娯楽アプリケーション、ワードプロセッサなどの生産性アプリケーション、電子百科辞典などの参照アプリケーション、ウェブサービスや財務分析に使用できる分散アプリケーションなどが挙げられる。このようなシステムの別の例は、アプリケーション（または別の環境）を展開することのできる環境である。環境は、アプリケーション（または別の環境）の展開先であるソフトウェアおよび／またはハードウェアリソースを指す。このような環境は、後でより詳細に論じるようにレイヤ化することができる。

システムのライフサイクルは通常、３つの主要フェーズ（ステージとも言う）を含む。すなわち、設計または開発フェーズと、それに続く展開またはインストールフェーズと、それに続く運用または管理フェーズである。このモデルは、システムライフサイクルの３つのフェーズすべてに適用されるので、システムライフサイクルの様々なフェーズのための統合ポイントと見なすことができ、３つのフェーズのそれぞれを容易にする。さらに、このモデルを使用することにより、これらのフェーズの間で知識を移すことができる。知識は、システムの管理に関する知識（例えば、設計開発チームが将来のバージョンのためまたは現バージョンの性能改善のためにシステムを修正できるように、設計開発チームにフィードバックされる知識）や、システムの構造、展開要件、動作挙動（vehavior）の知識や、デスクトップからデータセンタへの動作環境の知識や、エンドユーザによって観察されたサービスレベルの知識などである。

一般に、設計フェーズの間、ＳＤＭに影響を与える開発ツールを使用して、通信ソフトウェアおよびハードウェアコンポーネントからなるシステムを定義する。システム定義は、必要なリソース、構成、動作特徴、ポリシーなどを含めて、分散システムを展開および運用するのに必要なすべての情報を含む。展開フェーズの間、システム定義を使用してシステムを自動的に展開し、必要なソフトウェアおよびハードウェア（例えばサーバ、ストレージ、およびネットワーク）リソースを動的に割り振り、構成する。同じシステム定義を、異なるホスト環境および異なる規模への展開に使用することができる。管理フェーズの間、オペレーティングシステム中のＳＤＭサービスが、システムを管理するためのシステムレベルのビューを提供する。これにより、新しい管理ツールが、リソース割振り、構成管理、アップグレード、およびプロセス自動化をシステムの視点から推進することができる。

アーキテクチャ２００は、ＳＤＭ定義モデルと、ＳＤＭ定義モデル内の機能動作を定義するスキーマとを採用する。定義モデルは、異なる様々な種類のデータ構造を含み、これらは「定義」と総称される。ＳＤＭの機能は、アプリケーションプログラムインタフェース（ＡＰＩ）など、１つまたは複数のプラットフォームサービスを介して開示（expose）される。

システムの設計フェーズの間、開発システム２０２が、ＳＤＭ文書２０４のようなシステム定義を含む文書を生成する。開発システム２０２は、米国ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＶｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）開発システムなど、様々な開発システムのいずれかとすることができる。ＳＤＭ文書２０４は、システムの展開および管理に関係するすべての情報（本明細書では知識とも言う）を定義する。システムを展開または管理する際に必要なまたは使用されるどんな知識も、ＳＤＭ文書２０４に含まれる。本明細書では知識を単一の文書として述べるが、別法として複数の文書に分散させて維持してもよいことを理解されたい。

システム定義は、システムを、１つまたは複数のリソース、エンドポイント、関係（relationship）、およびサブシステムの点から定義する。システム定義はＳＤＭ文書（例えばＸＭＬ（Extensible Markup Language）文書）中で宣言される。リソースは、ハードウェアリソースまたはソフトウェアリソースとすることができる。エンドポイントは、システムを越えた通信を表す。関係は、システム、リソース、エンドポイントの関連を定義する。サブシステムは、完全なシステムとして扱うことができ、通常はより大きいシステムの一部である。

システム定義は、動的システムの基本構造を取り込む。これは、他のすべての情報がその上に追加される骨格と見なすことができる。この構造は一般に、開発プロセスの間に設計者および開発者によって指定され、通常は頻繁に変更されることはない。構造の他に、ＳＤＭは、展開情報、インストールプロセス、構成やイベントや計測のためのスキーマ、自動化タスク、ヘルスモデル、運用ポリシーなども含むことができる。分散システムの存続期間を通して、運用スタッフ、ベンダ、および／または管理システムがその他の情報を追加することができる。

ＳＤＭ文書２０４は、システムが展開および／または実行されることになる環境が満たさなければならない１つまたは複数のシステム制約（要件とも言う）を含む。環境自体も、ＳＤＭ文書を使用して記述される。このような環境は、単一のコンピューティングデバイスとすることもでき、あるいは、コンピューティングデバイスの集合（例えばデータセンタ）、アプリケーションホストの集合などとすることもできる。異なるシステムを異なる環境にインストールすることができる。例えば、データセンタが５０台のコンピューティングデバイスを含む場合に、あるシステムをこれらのコンピューティングデバイスのうちの５台に展開し、別のシステムをこれらのコンピューティングデバイスのうちの３５台に展開することができる。これらの要件は、次のような様々な形をとる可能性がある。すなわち、システムの展開先であるコンピューティングデバイスに関するハードウェア要件（例えば最低プロセッサ速度、最低メモリ容量、最低ハードドライブ空き容量、利用可能なネットワーク帯域幅の最低量、利用可能な特定のセキュリティ機構など）や、システムの展開先であるコンピューティングデバイスに関するソフトウェア要件（例えば特定のオペレーティングシステム、共にインストールしなければならない１つまたは複数の他のアプリケーション、特定のシステムおよび／またはオペレーティングシステムをどのように構成するかに関する指定、使用される特定タイプのセキュリティまたは暗号化など）や、システムの展開先であるコンピューティングデバイスに関するその他の要件（例えば利用可能なセキュリティ鍵、施行しなければならないデータセンタポリシー、使用される認証、環境トポロジなど）等である。

要件は別な方向に向かう可能性もある。すなわち、環境が、インストールされるシステムの構成に対して制約または要件を有する可能性もある（例えば環境の基準またはポリシーを実施するため）。これらは、環境のオペレータによって生み出される「明示的な」要件とすることができ、システムが有さなければならない特定の設定または構成や、システムが提供またはサポートしなければならない特定の機能や、システムがサポートしなければならない特定のセキュリティ機構などである。これらはまた、環境の特定の構成によって生じる「暗黙的な」要件とすることもできる。例えば、環境中のホストコンピューティングデバイスが特定タイプのファイルシステムを使用している場合に、このファイルシステムを使用して実施することができないアクションがある場合がある（別のファイルシステムを使用すればこれらのアクションを実施することができるにもかかわらず）。

システムの設計および開発フェーズの間、ＳＤＭ文書２０４を使用して、１つまたは複数の特定の環境についてシステムを妥当性検査することができる。これは両方向の妥当性検査である。すなわち、システムを環境について妥当性検査し、環境をシステムについて妥当性検査する。環境をシステムについて妥当性検査することは、ＳＤＭ文書２０４中で識別される要件を環境と比較して、すべての要件が環境によって満たされるかどうかを決定することによって行うことができる。システムを環境について妥当性検査することは、ＳＤＭ文書中で環境に関して識別される要件をシステムと比較して、すべての要件がシステムによって満たされるかどうかを判定することによって行うことができる。すべての要件が環境およびシステムによって満たされる場合、設計者または開発者には、システムをこの環境で展開できること、およびシステムがこの環境で実行されることがわかる。しかし、すべての要件が環境および／またはシステムによって満たされない場合は、設計者または開発者には、任意選択で、満たされなかった要件が通知され、それにより、システムをこの環境で展開して実行するためにどんな変更をＳＤＭ文書２０４に（かつそれに対応してシステムに）および／または環境に加えるべきかが通知される。

ＳＤＭ文書２０４に含まれるシステム展開に関する知識は、システムをどのように１つまたは複数の環境で展開するかを記述する。ＳＤＭ文書２０４は、コントローラ２０６に利用可能とされ、コントローラ２０６は、展開モジュール２０８および管理モジュール２１０を備える。ある実施形態では、ＳＤＭ文書２０４、ならびにシステムをインストールするのに必要なシステムファイルすべて（例えばバイナリ、データ、ライブラリなど）は、ＳＤＵ（システム定義ユニット）と呼ぶ単一のコンテナ（例えば単一のファイル）に共にパッケージされる。コントローラ２０６は、図１のコンピューティングデバイス１０２の１つまたは複数とすることができる。例えば、図１の単一のデバイス１０２が特定のデータセンタ用のコントローラであってもよく、あるいは、コントローラの任務は複数のデバイス１０２に分散されてもよい。

展開モジュール２０８は、システムを環境中に展開するのに使用されるサービスを含む。図２では、システムが展開される環境は、１つまたは複数のターゲットデバイス２１２である（またはこれらのデバイス上に展開されている）。システムはまた、コントローラ２０６に展開することもできる。展開モジュール２０８のこれらのサービスには、１つまたは複数のシステムを環境中にインストールまたは展開するために呼び出すことのできる１つまたは複数の関数が含まれる。

ＳＤＭ文書２０４には、異なる環境で展開するための異なる知識を含めることができる。この展開知識は、環境中で行う必要のある任意の変更（例えば、システムレジストリ、作成する必要のあるフォルダ、ディレクトリ、またはファイル、特定の値に設定する必要のある、コンピューティングデバイスのその他の設定パラメータまたは構成パラメータなどの変更）、ならびに、環境中でどのファイル（例えばプログラムファイルおよび／またはデータファイル）をコンピューティングデバイスにコピーする必要があるか、またこれらのファイルに対して実施する必要のある任意の操作（例えば圧縮解除および／または暗号化解除が必要なファイルもある）を記述する。多くの実装形態では、ＳＤＭ文書２０４中の展開知識は、例えば、システムのための通常のセットアッププログラムまたはインストールプログラム中に現在みられるような情報に類似する情報を含む。

展開プロセスの間、コントローラ２０６は、展開に関与するソフトウェアおよびハードウェアリソースの、ならびにこれらの関係の、記録または記憶を生成する。この記録または記憶は、後で管理フェーズの間にコントローラ２０６が使用することができる。

管理モジュール２１０は、システムが環境にインストールされた後でシステムを管理するのに使用されるサービスを含む。サービス管理モジュール２１０のこれらのサービスには、環境中でシステムを管理するために呼び出すことのできる１つまたは複数の関数が含まれる。ＳＤＭ文書２０４に含まれるシステム管理に関する知識は、システムをどのように１つまたは複数の環境で管理するかを記述する。

ＳＤＭ文書２０４には、システムを異なる環境で管理するための異なる知識を含めることができる。管理知識には、システムの管理または運用で使用される任意の知識が含まれる。管理には、例えば、構成（および任意選択で後の再構成）、パッチおよびアップグレード、保守作業（例えばバックアップ）、ヘルス監視または性能監視などが含まれる。

展開されたシステムに対する変更は、管理モジュール２１０を介して行う。管理モジュール２１０のサービスには、環境中に展開された１つまたは複数のシステムに変更を加えるために呼び出すことのできる１つまたは複数の関数が含まれる。管理モジュール２１０を介してこれらの変更を行うことにより、いくつかの利点を実現することができる。このような利点の１つは、加えられた変更の記録をコントローラ２０６が維持できることである。コントローラ２０６は、システムについてのＳＤＭ文書２０４のコピーを維持し、システムに加えられたどんな変更もＳＤＭ文書２０４に記録することができる。あるいはコントローラ２０６は、システムに加えられた変更に関する別個の記録を維持してもよい。

コントローラ２０６によって維持されるこの変更記録は、システムおよび／または環境に関する問題を解決するときや、ハードウェア障害によりシステムを再インストールしなければならないとき（システムを再インストールして障害時と同じパラメータ／設定で稼動するよう元に戻せるようにする）などに、後続の操作を単純化することができる。コントローラ２０６によってこのような変更が行われるようにすることにより、またコントローラ２０６が記録を維持するようにすることにより、いくらかの人為的ミスを環境からなくすことができる（例えば、変更を行う管理者が変更を帳面に記録することになっているのにそうするのを忘れた場合、この変更の記録はないことになる。この問題は、コントローラ２０６に記録を維持させることによって解決する）。

さらに、コントローラ２０６を介してシステムに変更を加えることにより、またコントローラ２０６を介してシステムを展開することにより、コントローラ２０６は、環境と、環境中に展開されるシステムと、これらの間の対話とに関する知識のリポジトリとして働くことができる。環境および／または環境中に展開されるシステムに関する知識は、コントローラ２０６から容易に得ることができる。この知識を使用して、中央のコントローラ２０６に記憶されている状態を環境中の被制御デバイスが反映していることを妥当性検査することにより、被制御環境の一貫性を保証することができる。

状況によっては、コントローラ２０６を介さずに、システムおよび／または環境に変更が加えられる場合もあることに留意されたい。例えば、コンピューティングデバイスが誤ってオフにされたり、作動しなくなったりすることがある。これらの状況では、このような変更をコントローラ２０６中に反映させるよう試みる。これらの変更は、自動的にコントローラ２０６中に反映させることもでき（例えば、デバイス障害を検出して、このような障害を管理モジュール２１０のサービスを使用してコントローラ２０６に通知するシステムを稼動させることができる）、あるいは手動でコントローラ２０６中に反映させることもできる（例えば、管理者が管理モジュール２１０のサービスを使用して、このような変更をコントローラ２０６に通知することができる）。あるいは、加えられた変更を元に戻し、システムおよび／または環境の一部を、コントローラ２０６によって記録された所望のシステム状態と再び一致させることもできる。

したがって、ＳＤＭ文書２０４は、「生きた」文書と見なすことができる。すなわち、環境の変化および／またはシステムの変化に基づいて、システムのライフサイクルを通して継続的に変化することができる。

ＳＤＭは、システムを横軸と縦軸にわたって機能構成することを可能にする。横軸に沿った構成は、システムおよびサブシステムによって行う。縦軸に沿った構成は、「レイヤ」によって行う。アプリケーション、サービス、ネットワークトポロジ、およびハードウェアは、分散システムにおける役割を果たすが、通常は、独立して定義され、異なるチームまたは組織によって所有されている。レイヤ化は、コンポーネントがホストに対して制約セットを定義することによって、またその逆によって達成される。

図３に、例示的なレイヤ化設定を示す。図３には、４つのレイヤすなわちレイヤ３０２、レイヤ３０４、レイヤ３０６、レイヤ３０８が示されている。４つのレイヤが図３に示されているが、実際のレイヤの数は様々とすることができ、４つよりも多いか少ない可能性もある。さらに、種々のレイヤの内容も、実施形態に応じて様々とすることができる。図３からわかるように、種々のレイヤは他のレイヤの上および／または下に位置する（例えばレイヤ３０６は、レイヤ３０４の上にあるがレイヤ３０８の下にある）。

レイヤ内の種々のシステムおよびサブシステムが、相互に対話することができ、また、異なるレイヤのシステムおよびサブシステムと対話することができる。例えばレイヤ３０８中のサブシステム３１０は、レイヤ３０８中のサブシステム３１２、ならびにレイヤ３０６中のサブシステム３１４と対話することができる。さらに、各レイヤは、より高い次のレイヤに対する環境と見なすことができる。例えばレイヤ３０６は、レイヤ３０８中のシステムおよびサブシステムに対する環境であり、レイヤ３０４は、レイヤ３０６中のシステムおよびサブシステムに対する環境である。各レイヤ３０２、３０４、３０６、３０８は、それ自体の関連するＳＤＭ文書を有する。

種々のレイヤ３０２、３０４、３０６、３０８は、異なる内容を表すものとすることができる。いくつかの実施形態では、レイヤ３０２はハードウェアレイヤであり、レイヤ３０４はネットワークトポロジおよびオペレーティングシステムレイヤであり、レイヤ３０６はアプリケーションホストレイヤであり、レイヤ３０８はアプリケーションレイヤである。ハードウェアレイヤは、レイヤ化されたシステムがその上に構築される物理デバイス（例えばコンピューティングデバイス）を表す（例えば図１のデバイス１０２）。ネットワークトポロジおよびオペレーティングシステムレイヤは、コンピューティングデバイスのネットワークトポロジ（例えば図１のネットワーク１００の設定）、ならびにこれらのコンピューティングデバイス上にインストールされるオペレーティングシステムを表す。アプリケーションホストレイヤは、コンピューティングデバイスにインストールされた、他のアプリケーションをホストすることのできるアプリケーションを表す（例えばＳＱＬ（Structured Query Language）サーバ、ＩＩＳ（Internet information service）（商標）など）。アプリケーションレイヤは、コンピューティングデバイスにインストールされた、他のアプリケーションをホストしないアプリケーションを表す（例えばゲームなどの娯楽アプリケーション、ワードプロセッサなどの生産性アプリケーション、電子百科辞典などの参照アプリケーション、ウェブサービスや財務分析に使用できる分散アプリケーションなど）。

図４は、システムのライフサイクル全体にわたってＳＤＭを使用するための例示的なプロセス４００を示すフローチャートである。図４のプロセス４００の様々な動作は、ソフトウェア、ファームウェア、ハードウェア、またはこれらの組合せにおいて実施することができる。

最初に、ＳＤＭに基づいてシステムを設計する（動作４０２）。システムは、システムが環境中で展開され実行されるために環境が満たさなければならない要件、ならびにシステムの展開および管理に使用されるその他の知識を含むように設計する。この知識は、システムに関連するＳＤＭ文書に含まれている。設計後、任意選択で、ＳＤＭを使用してシステムを妥当性検査することができる（動作４０４）。この妥当性検査により、設計者または開発者は、妥当性検査している環境でシステムを展開および実行できることを検証することができる。上で論じたように、システムをシステムの展開先である環境に対して妥当性検査するだけでなく、環境をシステムに対して妥当性検査することも行う。特定の環境についての妥当性検査が失敗した場合は、追加の設計ステップを実施して、システムをこの環境で実行できるようにシステムを改変することができる（あるいは環境を改変するステップを実施することができる）。

妥当性検査の後、ＳＤＭを使用してシステムを展開することができる（動作４０６）。システムを環境中に展開するときは、システムを、後でこの環境で実行することができるように環境中にインストールする。システムをインストールするのに使用される知識は、システムに関連するＳＤＭ文書に含まれている。展開後、ＳＤＭを使用してシステムを監視および／または管理する（動作４０８）。システムに関連するＳＤＭ文書中の知識は、システムをどのように監視および／または管理するかを識別し、システムは、この知識に従って環境内で監視および／または管理される。

図４のプロセス４００は、アプリケーションとしてのシステム、ならびに環境としてのシステムで使用することができる。例えば、アプリケーションをその環境のＳＤＭに対して妥当性検査することができる（例えば、図３のレイヤ３０８中のアプリケーションを、図３のレイヤ３０６の環境に対して妥当性検査する）。別の例として、オペレータまたはシステム設計者が、環境（例えば図３のレイヤ３０６またはレイヤ３０４）を設計し、これらの環境を、その展開先である環境（例えばそれぞれレイヤ３０４および３０２）に対して妥当性検査することができる。

システムおよび／または環境に対する制約をランタイムの間に（システムが監視／管理されている間に）使用して、システムおよび／または環境に対する変更をランタイムの間に妥当性検査することもできる。このようなランタイム妥当性検査により、例えば、ある環境のオペレータが、環境に対する変更がどのように実行中のシステムに影響するかを判定することができ、あるいはシステム設計者が、システムに対する変更がどのように環境中のその実行に影響するかを判定することができる。

以下の解説では、ランタイムに関するフローおよび設定フローに言及する。フローは、分散システムの各部分の間で構成情報を渡すのに使用される（例えば、開発者がある位置の構成情報を指定できるようにする。または、オペレータが単一のエントリだけを提供できるようにする）。フローはまた、システムの各部分の間の設定データのフローを追うことによって構成に対する変更の影響を判定するのにも使用される。

図５に、ＳＤＭランタイムを使用する例示的なアーキテクチャ５００を示す。アーキテクチャ５００は、図２のアーキテクチャ２００の一例であり、ＳＤＭランタイム５１０と、後で「例示的なＳＤＭ実装形態」の章で論じるＳＤＭの例示的な実装形態とを使用する。ＳＤＭランタイム５１０は、ＳＤＭファイルを受領して妥当性検査し、ＳＤＵ（システム定義ユニット。１つまたは複数のＳＤＭファイルおよびそれらに関係するファイルのパッケージ）をロードし、ＳＤＭ変更要求を生成して実行し、ＳＤＭベースのシステムをターゲット環境に展開するための、コンポーネントおよびプロセスのセットを含む。このランタイム機能により、ＳＤＭを使用して記述されたシステムを定義および妥当性検査し、コンピューティングデバイスのセットに展開し、管理することができる。

ＳＤＭは、後で「例示的なＳＤＭ実装形態」の章でより詳細に論じるが、分散システム（モデル化システム）中のコンポーネントの構成、対話、および変更の記述（description）をサポートするように設計される。ＳＤＭは、オブジェクト関係（relational）モデルに基づく。「定義」が、システム中に存在するエンティティを記述し、「関係（relationship）」が、様々なエンティティ間のリンクを識別する。定義および関係はさらに、ＳＤＭに関連するセマンティクス情報を取り込むように定義される。具体的には、定義はコンポーネント、エンドポイント、リソースに分けられる。関係は、接続（通信とも言う）、包含、ホスティング、委任、参照に分けられる。定義および関係に関するこれ以上の詳細は後で提供する。

ＳＤＭは「抽象定義」を含む。これは、システムの各部分の共通範疇化と、幅広いシステムのためのツールサポートと、設計時の定義チェックのための基盤とを提供する。抽象定義のセットは、サービス設計のための包括的な基盤を提供する。「具象定義」が、実際のシステム設計またはデータセンタ設計の各部分を表す。具象定義の生成は、抽象定義を選択し、具象定義のメンバとそのプロパティの設定値とを定義する実装を提供することによって行う。分散アプリケーションは、これらの具象定義の集合を使用して生成する。

ＳＤＭは「制約（constraint）」も含む。制約は、関係のインスタンスが参与することのできる許容される関係のセットに基づく制限をモデル化する。制約は、関係に関与するオブジェクトの構成に応じた要件を記述する際に有用である。例えば、制約を使用して、通信プロトコルの両端の参与者が互換性のあるセキュリティ設定を使用しているかどうかを判定することができる。

ターゲットシステムに対する変更を実施するために、ＳＤＭは、「変更要求」またはＣＲと呼ばれる、必要とされる変更の宣言記述を使用する。ＳＤＭは、「ＳＤＭ実行モデル」の一部として変更要求を展開（ｅｘｐａｎｄ）、妥当性検査、および実行するのに使用されるプロセスを定義する。

「インスタンス空間」は、管理されるアプリケーションの所望状態と現在状態の両方を取り込む。インスタンス空間中の変更は、追跡され、その変更を開始した変更要求に関連付けられる。インスタンス空間は、ＳＤＭランタイム内に記憶され、モデル化システムの現在状態を反映する。ランタイムは、生成されたインスタンスと、これらのインスタンス間の関係との完全な記録を含む。各インスタンスにはバージョン履歴が関連し、バージョン履歴中では、各バージョンが変更要求にリンクされている。新しいインスタンスを生成するプロセスは、変更要求によって開始される。変更要求は、既存のインスタンスの特定メンバに関連する定義および関係に対する、生成、更新、削除要求のセットを定義する。

以下は、図５のコンポーネントがどのように協働するかについての簡単な機能上の解説である。オペレータまたは管理者が、データセンタのトポロジなど、アプリケーションを展開（deploy）できる環境を記述することができる。オペレータまたは管理者は、環境を記述するＳＤＭファイルを作成するが、このファイルは、「論理インフラストラクチャ」（ＬＩＭ）５０２、あるいはデータセンタ記述またはデータセンタモデルと呼ばれる。このＳＤＭファイルは、米国ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＶｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）開発システムなど、様々な開発システムのいずれかを使用して生成することができる。

さらに、アプリケーション開発者は、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）開発システムなどの様々な開発システムのいずれかを使用して、自分のアプリケーションを設計および開発することができる。開発者は、アプリケーションのコンポーネントと、これらのコンポーネントがどのように相互に関係するかを定義するので、アプリケーション記述をデータセンタ記述５０２に対して妥当性検査することができる。これを「設計時妥当性検査」とも呼ぶ。

アプリケーションが完成すると、開発者は記述をＳＤＭに保存し、アプリケーションがＳＤＵ５０４として展開されるようにアプリケーションのパッケージングを要求する。ＳＤＵは、アプリケーションＳＤＭと、アプリケーションをインストールするのに使用されるアプリケーションバイナリおよびその他の参照ファイルとを含む。

ＬＩＭ５０２およびＳＤＵ５０４は、展開（deployment）に向けて、コントローラデバイス５２０の展開ツール５０６に供給される。展開ツール５０６は、オペレータが所望のＳＤＵ５０４をロードできるようにするためのユーザインタフェース（ＵＩ）を備える。展開ツール５０６は、ＣＲ生成モジュール５３０と協働して、ＳＤＵ５０４に関連するアプリケーションを、ＳＤＵ５０４内のＳＤＭ中の情報に従ってインストールする。さらに、ＳＤＵ５０４からのＳＤＭ定義およびインスタンスが、ＳＤＭランタイム５１０のＳＤＭ記憶域（store）５０８にポピュレートされる。ＳＤＵは、ＳＤＭランタイム５１０中でＳＤＵ管理モジュール５４０によって管理され、ＳＤＵ管理モジュール５４０は、ランタイム５１０の他のコンポーネントおよびターゲット５２２がＳＤＵの適切な部分を利用できるようにする。

オペレータはまた、展開中のアプリケーションの展開先であるターゲット５２２（例えばターゲットコンピューティングデバイス）に対してオペレータがどんなアクションを取りたいかを指定することができる。オペレータは、展開ファイルを介してこれを行うことができ、この展開ファイルは、本明細書では変更要求（ＣＲ）とも呼ばれる。ＣＲは、１つまたは複数のエンジン５１２、５１４、５１６、５１８を通して実行される。一般に、ＣＲ展開エンジン５１２は、ＣＲを展開して、関連するすべてのコンポーネントならびにそれらの接続およびアクションを識別する。値フローエンジン５１４は、コンポーネントに関する値（接続ストリングなど）をフローする。制約チェックエンジン５１６は、環境とアプリケーションとの間の制約をチェックする。アクション順序付けエンジン５１８は、ＣＲに関する必要なすべてのアクションの順序を指定する。

システムに対する変更（アプリケーションの展開を含む）、またはモデルの妥当性検査を開始するために、オペレータまたはプロセスは、ＣＲをサブミット（submit）する。ＣＲは、オペレータがランタイム５１０中のインスタンスを介して実施したいアクションのセットを含む。これらのアクションは、例えば生成アクション、更新アクション、および／または削除アクションとすることができる。

ユーザまたはオペレータによって開始される変更要求に加えて、展開／自動生成の変更要求があるものとすることもでき、これは、後でより詳細に論じる展開プロセスの一部として生成される。変更要求は、そのソースにかかわらず、完全に展開されチェックされた後で、ターゲットインスタンスの発見、インストール、アンインストール、変更などのアクションをターゲット５２２に送ることによって実行される。

ＣＲは、グループとして完了または失敗する原子アクションセットとして扱われる。これにより例えば、制約チェックエンジン５１６は、妥当性をテストするときにすべてのアクションを考慮することができる。

設計時妥当性検査では、ＣＲは、ＳＤＭコンパイラ５２８によって生成され、ＳＤＭファイル中の各ＳＤＭコンポーネントの１つまたは最小限を含むことになる。この、インスタンス生成コマンドのＣＲは、ＣＲ展開エンジン５１２、値フローエンジン５１４、および制約チェックエンジン５１６の中をフローする。この３つのフェーズで見つかったエラーは、ユーザが使用している開発システムを介してユーザに返される。

展開時は、オペレータは、展開ツール５０６によって提示されるＵＩ（user interface）でＣＲを生成する。ＣＲは、ＳＤＭランタイム５１０中のすべてのエンジン５１２、５１４、５１６、５１８の中をフローし、適切なアクションおよび情報がＣＲ実行モジュール５３２から適切なターゲット５２２に送られ、ターゲット５２２で要求が実行される（例えばアプリケーションがインストールされる）。特定のインストールの場合の適切なターゲット５２２は、通常、アプリケーションがインストールされることになるターゲットである。

ＣＲの処理を開始する際、定義解決フェーズで、ＣＲ生成モジュール５３０は、変更要求の中で参照されるすべての定義およびメンバを解決する。変更要求は、これらがすでにランタイム５１０によってロードされていると見なす。これらが存在しない場合は、ＣＲ生成モジュール５３０はロード／コンパイルアクションを開始する。ＣＲ生成モジュール５３０はパス解決フェーズも実施し、変更要求内の、既存のインスタンスおよび生成アクションによって定義されたインスタンスへの参照を解決する。

ＣＲ展開エンジン５１２によって実施される展開は、所与の変更要求について、この要求を実行するのに必要な残りのすべてのアクションをポピュレートするプロセスである。一般にこれらのアクションは、定義インスタンスおよび関係インスタンスに対する構築（construction）アクションおよび破壊（destruction）アクションである。オペレータは任意選択で、インスタンスを構築または破壊するのに必要なすべてのアクションに関する詳細を提供することもでき、あるいはこのプロセスの一部は自動化することもできる。例えばオペレータは、メンバ（例えばｂｙＲｅｆｅｒｅｎｃｅメンバ）に対するアクションを識別することにより、オペレータが望む変更に関するキー情報を提供する。すると、ネストされたメンバ（例えばｂｙＲｅｆｅｒｅｎｃｅメンバおよびｂｙＶａｌｕｅメンバ）と関係に対して、アクションの残りが埋められる。別の例として、自動化された展開は、外部リソースマネージャを参照することもでき、外部リソースマネージャは、利用可能なリソースを有するデバイスを選択することや、それが必要とするデータに近いアプリケーションを突き止めることなどに基づいて、展開決定を行うことができる。

ＣＲ展開エンジン５１２は、「自動記述（writing）」も実施する。自動記述の間、ＣＲ展開エンジン５１２は、ＳＤＭ中で指定されているコンポーネントおよび複合コンポーネントのスケール不変のグループ化を分析し、コンポーネントが要求のレベルにスケールされたときにコンポーネントがどのようにグループ化され相互接続されるべきかを判定する。

ＣＲ展開エンジン５１２は、値（value）メンバ展開、参照（reference）メンバ展開、および関係展開も実施する。

値メンバ展開は、すべての非参照定義メンバを識別することを指す。これらのメンバのカーディナリティ（cardinality）が示され、必要なパラメータはすべてわかるので、各メンバごとに、親の生成中であるメンバについては生成要求が変更要求に追加される。変更要求が破壊動作を含む場合は、それらに含まれるすべてのインスタンスについて破壊動作が追加される。

参照メンバ展開は、参照メンバを指す（非参照定義メンバとは反対に）。参照メンバのカーディナリティはしばしば未定義であり、参照メンバは、インスタンスが構築されるための値を必要とする展開時設定を有する可能性がある。したがって、参照メンバ（例えばｂｙＲｅｆｅｒｅｎｃｅメンバ）を展開するプロセスは、インスタンスに関する情報として、ランタイムが提供できるよりも多くの情報を必要とする可能性がある。

参照メンバ展開には、発見と呼ばれるプロセスが関係するが、これは、すでに展開されたインスタンスを見つけるのに使用されるプロセスである。発見は、通常は環境のオペレータによって開始されるアクションである。例えばインストール要求の間、ＣＲ展開エンジン５１２は、インスタンスがすでに存在するかどうかを判定し、存在する場合は何が存在するかを判定し、存在しない場合はそれを生成する。コントローラ５２０上のインスタンスマネージャ（ＩＭ）５３４が、ターゲットデバイス５２２上のインスタンスマネージャ５２６と通信して、発見プロセスを開始する。発見プロセスは、インスタンスに関するデータをターゲットデバイス５２２からコントローラ５２０に返す。

発見のプロセスは、構築または更新アクションの一部として参照定義メンバをポピュレートする。通常、発見をサポートするオブジェクトマネージャ（発見を実施もするインスタンスマネージャ）に関する参照メンバだけが、このプロセスに参与する。

新しいインスタンスが発見されたときは、インスタンス特有のキー値を使用して、このインスタンスがまだＳＤＭデータベース中に存在しないことをチェックする。新しいインスタンスであることがわかれば、発見されているメンバの定義に従ってインスタンスを分類する。インスタンスがメンバにマッチしない場合、または曖昧なマッチがある場合は、メンバ参照は空白のままにされ、インスタンスはオフラインおよび不完全としてマークされる。

関係展開は、構築されることになる定義インスタンスがすべてわかった後で、定義インスタンスを共にバインドする関係インスタンスを生成することを指す。定義インスタンスの破壊中である場合は、定義インスタンスを参照するすべての関係インスタンスを削除する。

関係を生成するには、メンバ空間を使用して、インスタンス間に存在すべき関係の構成を識別する。定義メンバが１よりも大きいカーディナリティを有する場合、関係のトポロジは基底関係定義から推論する。例えば、通信関係の場合は「自動記述」を実施することができ、ホスト関係の場合は、ホスティング関係に関連するアルゴリズムに基づいてホストを選択する。

フローステージの間、値フローエンジン５１４は、すべての関係インスタンスにわたってフローを評価する。値フローエンジン５１４は、改変されたパラメータフローの影響を受けたインスタンスについて、変更要求に更新要求を追加することができる。値フローエンジン５１４は、変更要求の結果として設定が更新されたインスタンスのセットを判定することにより、フローを評価する。これらのそれぞれにつき、修正された設定に依存する送出設定フローがあればそれを評価し、変更されたインスタンスのセットにターゲットノードを追加する。このプロセスは、そのセットが空になるまで、またはそのセットが循環を含むまで継続する。

フローステージの後、重複検出のプロセスを実施する。重複検出は、図５に示すエンジンのうちの１つ（例えば値フローエンジン５１４や制約チェックエンジン５１６）によって実施することもでき、あるいは、図５に示していない別のエンジンによって実施することもできる（例えば重複検出エンジンをＳＤＭランタイム５１０に含めることができる）。重複検出のプロセスは、展開されたインスタンスを、ＳＤＭデータ記憶域中にすでに存在するインスタンスと照合する。例えばこのプロセスは、別のアプリケーションが共有ファイルをインストールしたかどうかを検出する。すでに存在するインスタンスが検出されたときは、存在するインスタンスのバージョンに応じて、いくつかのアクションの１つを実施することができる。すなわち、インストールを失敗にすること、インスタンスを参照カウントすること、インスタンスをアップグレードすること、またはインストールを並行して実施することができる。

制約チェックエンジン５１６は、制約評価フェーズを実施する。このフェーズでは、モデル中のすべての制約をチェックして、変更要求が処理された後でもこれらがまだ有効となるかどうかを調べる。

制約チェックエンジン５１６が制約評価フェーズを終了した後には、完全なアクションリストが利用可能である。したがって、アクション順序付けエンジン５１８は、コンポーネント間の関係を使用して、有効な変更順序付けを判定することができる。この判定は、様々なアルゴリズムのいずれかを使用して行うことができる。

アクション順序付けエンジン５１８が順序付けを終了すると、マシン特有の順序付けされたアクションセットのサブセットを配信することによって展開を実施することができる。アクションがマシンによって順序付けされグループ化された後、アクションと、インスタンス情報を含むランタイムのＳＤＭ記憶域５０８の必要部分のコピーとが、ターゲットコンピューティングデバイス５２２に送られる。ＳＤＭは、一時的にターゲットデバイスの記憶キャッシュ５３８に記憶することができる。

ターゲットコンピューティングデバイスは、ＳＤＭランタイム５１０と通信するＳＤＭランタイムのターゲット部分５３６を備える。ターゲットコンピューティングデバイス５２２はエージェントも備えており、このエージェントは、実行エンジン５２４を備え、ターゲットデバイス上の適切なインスタンスマネージャ（ＩＭ）５２６と通信して、生成、更新、削除アクションなどの変更をターゲットに対して行うことができる。各アクションは、原子呼出しとしてインスタンスマネージャ５２６に送られる。インスタンスマネージャ５２６は、ステータスメッセージを返し、アクションによってはデータも返す（例えば発見の場合）。すべてのアクションがターゲット５２２上で完了すると、ターゲットのエージェントは、エラーがあればエラーと、ステータスとをコントローラ５２０に返す。次いでコントローラ５２０は、この情報を使用してランタイムのＳＤＭ記憶域５０８を更新する。

上で論じたように、変更は、影響を受ける関係に基づいて変更要求を配信可能部分に分解することによって行われる。すべての部分が完了すると（あるいは１つまたは複数の部分が失敗した後で）、ランタイム５１０中で結果が照合され、概要がオペレータに返される。失敗の場合は、すべてのアクションを「ロールバック」することができ、システムを変更開始前の状態に戻すことができる。

いくつかの実施形態では、上で論じた設計時妥当性検査の間、ＳＤＭコンパイラ５２８がＳＤＭファイルを受け取り、テストＣＲを生成し、ＳＤＭランタイムの展開エンジン、値フローエンジン、および制約チェックエンジンを通してテストＣＲを実行し、エラーがあればエラーを開発システムに返す。このプロセスにより、展開に向けたＳＤＭ妥当性検査が、設計時の間に開発者にもたらされる。

ＳＤＭランタイム５１０および／またはコントローラ５２０への公開インタフェースは、オブジェクトモデル（ＡＰＩ）ライブラリを介する。このライブラリは、マネージドコードオブジェクトモデルであり、以下の項目の実施を可能にする。
・ランタイム内でＳＤＭを管理する。−ＳＤＭファイルをランタイムにロードすることができる。ＳＤＭは不変であり、一度に１つロードされる（すなわち、ファイルの一部だけ（例えばＳＤＭファイルからの個々の定義、クラス、またはマッピングの１つ１つ）ではなく、１つのＳＤＭファイルをロードすることができる）。ＳＤＭをランタイムから削除することができ、ランタイム内のＳＤＭについてのＸＭＬ文書を作成することができる。
・ランタイムによって知られるＳＤＵを管理する。
・ＳＤＭ定義を管理する。−ＳＤＭ要素を見つけて検討する（ランタイムにロードされたＳＤＭから）。新しいＳＤＭをオーサリングするために提供される公開ＡＰＩはない（すなわちこれは、ＳＤＭの不変要素に対する読出し専用オブジェクトモデルである）。これは、ＳＤＭ、ＳＤＵ、識別、バージョン、クラス、定義、バインド／マッピング、およびバージョニングポリシーを含む。
・ＳＤＭインスタンスを管理する。−コンポーネント、エンドポイント、リソース、および関係のインスタンスを見つけて検討する。インスタンス空間では、各インスタンスを、ＧＵＩＤ、安定パス、またはアレイベースのパスで識別することができる。パスはストリングであり、相対的とすることができる。相対パスを含めたこれらの識別子により、変更要求文書などの文書中でインスタンスを見つけて参照することができる。
・インスタンスを操作する。−生成、トポロジ変更、アップグレード、設定変更、削除を含めて、ＳＤＭインスタンスに対して変更を行う。インスタンス変更は変更要求の範囲内で行われ、変更要求は、エラーまたは制約違反があれば要求が完全に失敗するように、更新の原子単位を提供する。インスタンス要求はまた、インスタンスが一時的にホストへのバインドなしでも存在できるようにする。というのは、要求がコミットされるときはインスタンスはホストを有さなければならないからである。また、単一のコンポーネントのインストールまたは設定に影響を与える多くの操作が行われることを可能にし、単一の更新がコンポーネント上で行われるように、インストールまたは設定の更新がコミットまで延期されるようにする。変更要求のコミット前またはコミット時にＳＤＭモデルチェックを実施し、モデル違反または制約違反があればコミットは失敗する。
・変更要求をロードする。−変更要求は、インスタンス空間操作のセットを提示する文書、例えばＸＭＬファイルである。この文書は、相対パスを利用して、アプリケーションインスタンスを生成または削除するための再使用可能「スクリプト」となることができる。
・変更要求を見つけて検討する。−インストール／更新タスクおよびすべてのエラー情報を得ること、ならびに要求の影響を受けるコンポーネントのインストール／更新を再試行することを含む。
・データベース中の変更要求から変更要求文書を生成する。このような文書はいくぶん移植性がある。
・進行状況、ログ、または更新されたステータスなど、変更要求タスクに関するイベントの通知に申し込む。これらのイベント加入の存続期間は、クライアントライブラリをロードしたプロセスの存続期間によって制限される（すなわちこれらは定期ＣＬＲイベントである）。

ＳＤＭランタイムエンジンは、ＳＤＭモデル、およびＡＰＩによって表面化された関数に対して、推論を実施する。ライブラリは、ＳＤＭをロードする、コンポーネントインスタンスを生成する、ＳＤＭ全体を得る（ＳＤＭエンティティを検討するため）など、かなり粗な呼出しを使用してウェブサービスとしてランタイムエンジンに通信する。このウェブサービスに関する多くのパラメータのフォーマットは、ＳＤＭファイルの場合と同じスキーマを有するＸＭＬである。エンジンはまた、許可に対するチェックも実施することができる。

コントローラ５２０は、インスタンスマネージャ（ＩＭ）を利用することができ、ＩＭは、モデル中の任意の定義または関係に関連付けることができる。ＩＭは、以下の役割の１つまたは複数を実施することができる。
・インスタンスの展開をサポートする。
・インスタンスが展開された後のインスタンスの妥当性検査をサポートする(監査)。
・ランタイムを介して展開されたのではない展開済みインスタンスの発見をサポートする。
・設定値のフローをサポートする。
・制約の評価をサポートする。
・変更要求の展開をサポートする。
・ＡＰＩを介してインスタンスをＣＬＲクラスとしてユーザに提示することをサポートする。

展開のために、コントローラ５２０上のインスタンスマネージャ（ＩＭ）プラグインがクラスホスト関係に関連付けられるが、このプラグインは、開発システム中で使用される、クラスに関する設計経験を提供し、ＳＤＵ５０４中および設定スキーマ中の関連バイナリを作成するプラグインとは別である。インスタンスマネージャは、インスタンスマネージャインタフェースを実装するかまたは抽象クラスから継承するＣＬＲクラスとして（例えばｄｌｌアセンブリ中で）ＳＤＭランタイム５１０に供給される。ＳＤＭインスタンスマネージャは、インスタンスマネージャ（ＩＭ）プラグインとも呼ばれ、以下の機能をコントローラ５２０に提供する。
・コンポーネントインスタンスをそれらのホストにインストール、アンインストール、または再インストールするためのファイルおよびコマンド（タスク）を生成する。−変更要求の結果、新しいコンポーネントインスタンス、またはコンポーネントインスタンスの削除、またはアンインストールおよび再インストールが必要なコンポーネント変更が生じるとき、インスタンスマネージャは、ＳＤＵ５０４中のインスタンス、ホストインスタンス、コンポーネントに関連する定義、これらの定義に関連するバイナリの設定を利用し、手動実行の準備または展開エンジンを介したディスパッチの準備ができたターゲットサーバ上でインストールまたはアンインストールを実施するのに必要なファイルおよびコマンドを作成する。
・コンポーネントインスタンスの設定が変化したとき、またはそのエンドポイントの１つからのビューが変化したとき（例えば通信関係トポロジが変化したせいで、または見えるエンドポイントが設定変更を有するせいで）、コンポーネントインスタンスを更新するためのファイルおよびコマンド（例えばタスク）を生成する。

・コンポーネントインスタンスのエンドポイント上で見えるエンドポイントインスタンスを、コンポーネントインスタンス上の設定にマッピングする。−ＳＤＭ中で、コンポーネントインスタンスは、何らかの通信関係トポロジの結果として他のエンドポイントインスタンスが見えるエンドポイントインスタンスを有する。他のエンドポイントインスタンスの詳細は、コンポーネントインスタンスがランタイム時にフェッチすることのできる、したがって通常はそれにバインドすることのできる設定にマッピングされる。例えば、ウェブサイトがデータベースクライアントエンドポイントを有し、したがって通信関係はデータベースを使用して確立することができる。正しく確立されたとき、そのデータベースクライアントエンドポイントは、このサーバエンドポイント上の単一のデータベースサーバエンドポイントインスタンスおよび設定を見ることができる。この情報をインスタンスマネージャが使用して、サーバに関する接続ストリングを、クライアントエンドポイントという名前で構成ファイル中に配置する。この結果、コードは単に、データベースに関する接続ストリングをその構成設定から読む。
・コンポーネントインスタンスを監査するためのファイルおよびコマンド（タスク）を生成する。−監査は、存在および正しい設定を確認する。これはホストインスタンス設定にも適用することができる。
・任意のタスクについてステータスを報告する。−ＩＭは、取り込まれた出力の一部または全部を変換し、タスクのステータスを成功、失敗、または不完全として提供し、任意選択で、不完全に関する進行状況（％または最終応答）、失敗に関する詳細（エラーメッセージ）、および任意のステータスに関する人間に読めるログを提供する。インスタンスマネージャに戻ってタスクの出力を解釈することにより、インスタンスマネージャは、診断に十分なログを作成してそれを人間に読めるように維持しなければならないのではなく、そのタスクをログ構造化情報（例えばＸＭＬ、さらにはＳＯＡＰ（Simple Object Access Protocol））にすることが自由にできる。
・インスタンスマネージャはまた、ホストとそれらのゲストとの間の制約チェックを実施するコードを提供することもできる。インストーラは、共通の制約言語、例えばＸＭＬ、ＸＰａｔｈ、ＸＱｕｅｒｙに基づく言語を使用することができる。

例示的なＳＤＭ実装形態
以下の解説では、ＳＤＭの要素を定義するスキーマの一実施形態について述べる。

１ 定義

２ アーキテクチャの概観
システム定義モデル（ＳＤＭ）は、分散システム（モデル化システム）中のコンポーネントの構成、対話、および変更の記述をサポートするように設計される。

ＳＤＭは、オブジェクト関係モデルに基づく。オブジェクトを使用して、システム中に存在するエンティティを記述し、関係を使用して、それらの間のリンクを識別する。ＳＤＭではさらに、ＳＤＭにとって重要なセマンティクスを取り込むようにオブジェクトおよび関係が改良される。具体的には、オブジェクトはシステム、エンドポイント、リソースに分けられ、関係は通信、包含、ホスティング、委任、参照に分けられる。

自分のフィーチャのアーキテクチャを記述せよ。必要なブロック図があれば含めよ。コンポーネント（このフィーチャによってどれが変更されるか、または残されるかを識別するもの）、内部インタフェース、データフロー、およびその他の対話を記述せよ。

抽象定義を使用して、システムの各部分の共通範疇化を提供する。これにより、幅広いアプリケーションに対するツールサポートが可能になり、設計時の型チェックのための基盤がもたらされる。抽象定義のセットは、システム設計のための包括的な基盤を提供すると考えられ、これらは時の経過に伴ってゆっくり変化すると考えられる。

実際のアプリケーションまたはデータセンタの設計の各部分を表す具象オブジェクト定義を構築する。抽象オブジェクト定義を利用して、具象型のメンバとそのプロパティの設定値とを定義する実装を提供する。次いで、これらの定義の集合からシステムを構築する。

制約を使用して、インスタンスが参与することのできる許容される関係のセットに対する制限をモデル化する。制約は、関係に関与するオブジェクトの構成に応じたきめ細かい要件を取り込むのに使用する。例えば、制約を使用して、通信プロトコルの両端の参与者が互換性のあるセキュリティ設定を使用していることを妥当性検査することができる。

ターゲットシステムに対する変更を実施するために、ＳＤＭは、変更要求と呼ばれる、必要とされる変更の宣言記述を使用する。ＳＤＭは、ＳＤＭ実行モデルの一部として変更要求を展開、妥当性検査、および実行するのに使用されるプロセスを定義する。

インスタンス空間が、管理されるアプリケーションの所望状態と現在状態の両方を取り込む。インスタンス空間中の変更は、追跡され、その変更を開始した変更要求に関連付けられる。

後続のＵＭＬ（unified modeling language）図は、ＳＤＭモデル中のオブジェクト間の広範な対話を取り込むものである。簡単にするために、これらの対話のいくつかは基底型の間で定義されているが、実際の対話は派生型の間に存在し、その結果、より特殊化されている。例えば、通信関係は抽象エンドポイント定義だけを参照する場合がある。

ＳＤＭ文書は、文書と、文書中の定義に対するマネージャと、他の文書を参照するインポートステートメントと、定義セットとを記述する情報を含む。

図６に例示的な文書を示す。

図７に示すように、すべてのＳＤＭ定義は、共通基底定義から派生し、メンバを含むことができる。定義とメンバの間の関係は、後続の図に示すものよりも複雑にすることもできる。

図８に示すように、メンバは、それらが参照する定義の種類によって分けられる。

設定宣言は、設定定義を参照する。図９に示すように、設定値および値リストが、設定に関する値を提供する。

２．１ ＳＤＭアプリケーションのライフサイクル
図１０に、いくつかの実施形態による例示的なＳＤＭアプリケーションのライフサイクルを示す。

アプリケーションをＶｉｓｕａｌ Ｓｔｕｄｉｏ（登録商標）環境内で設計および実装する（ブロック１００２）。開発者は、コンポーネントを実装し、次いでそれらを複合コンポーネント内で結合する。アプリケーションはＳＤＭファイル内に記述する。開発者のアプリケーションが特定のデータセンタ内で展開されることを検証するために、開発者はアプリケーションを、やはりＳＤＭファイル中に記述されたデータセンタ表現にバインドする（ブロック１００４）。この表現は、開発者のアプリケーションコンポーネントのホストに関する定義と、開発者のアプリケーションの構成に対する制約とを含む。バインドが失敗した場合は、開発者はアプリケーション設計を修正することができる。

開発者が自分のアプリケーションに満足すれば、開発者はアプリケーションに署名して公表することができ、したがって、今やアプリケーションには厳密名（strong name）およびバージョンが関連付けられている（ブロック１００６）。アプリケーションの公表された形は、ソフトウェア配信ユニット（ＳＤＵ）と呼ばれる。オペレータは、開発者からのＳＤＵを採用し、アプリケーションをＳＤＭランタイムにロードする（ブロック１００８）。アプリケーションをロードするプロセスの間、オペレータは、アプリケーションをバインドしたいと思うデータセンタのモデルを選択する。オペレータは、アプリケーションを展開することを決定すると、展開時パラメータをアプリケーションに供給し、アプリケーションのスケールを判定する（ブロック１０１０）。これは変更要求を使用して行う。

アプリケーションを展開すると、オペレータはランタイムと対話して、アプリケーションの構成およびアプリケーションの各部分に関する設定を判定することができる（ブロック１０１２）。ランタイムはまた、アプリケーションの実際の構成が、ランタイム内に記録されている所望の構成とマッチすることを検証することもできる。オペレータは、変更要求をサブミットすることにより、展開したアプリケーションを削除することができる（ブロック１０１４）。オペレータはまた、サービスパックの削除など、実行中のアプリケーションに加えられた個々の変更をロールバックすることもできる。ブロック１０１６で、展開されたアプリケーションの一部をウェブフロントエンドなどに対して追加または削除することにより、実行中のアプリケーションの構成を変更することができる。アプリケーションはまた、１つまたは複数のアプリケーションコンポーネントのより新しいバージョンをインストールすることによってアップグレードすることもできる。

２．２ 抽象オブジェクト定義および関係定義
抽象オブジェクト定義は、設計時にアプリケーション構成をチェックしてからランタイム時にアプリケーションを展開および管理するために必要な構成単位を定義する。これらの構成単位は、モデル化システム中に存在するエンティティを表す。例えば、抽象オブジェクト定義を使用して、ファイルおよびディレクトリ、ウェブサーバ内部の構成、またはＳＱＬサーバ内部のデータベースがモデル化される。

抽象関係定義は、抽象オブジェクト定義間で行われる可能性のある対話をモデル化するのに使用する。関係は、バイナリおよび有向であり、関係の発現に参与するインスタンスを定義するオブジェクト定義を識別する。関係は、オブジェクト間の包含、構築、通信のリンクをモデル化できるようにオブジェクトを共に結ぶ方法を提供する。

次いで、オブジェクトが制約を使用して、オブジェクトの参与する関係を制約し、関係が制約を使用して、リンクできるオブジェクトを制約する。これらの制約は、関係への参与者の定義と設定の両方をターゲットにすることができる。これにより制約は、関係への参与者を特定の定義から派生するインスタンスに限定することができ、また、インスタンスが特定の範囲に含まれる設定値を有することを必要とすることができる。

オブジェクト定義は、システム、エンドポイント、リソースという３つのカテゴリに分けられる。

抽象システム定義は、アプリケーションの自己完結型かつ独立展開可能な部分を記述するのに使用する。これらの定義は、プロセスおよびマシンの境界を横断することのできる明確に定義された通信チャネルを介して対話するアプリケーション部分を表す。

抽象エンドポイント定義は、システムが開示する（expose）ことのできる通信エンドポイントを記述するのに使用する。これらを使用して、設計時にシステム接続性を検証するためおよびランタイム時に接続を可能にするためにシステムが意識すべきすべての形の通信をモデル化する。

抽象リソース定義は、システム内に含まれる挙動を記述する。リソース定義は、他のリソース定義への強力な従属性を有する場合がある。これらの従属性には、特定のインストール順序を必要とすることや、公式に文書化されていない通信機構を介したランタイム対話を開始することを含めることができる。

すべての抽象オブジェクト定義は、設定を開示する能力を共有する。これらの設定は、名前と値の単純な対であり、ＸＭＬスキーマを使用して設定の型を定義する。設定は動的でも静的でもよいが、静的の場合は、展開プロセスの間だけ設定することができ、動的の場合は、展開後に変更することができる。実行中のシステムに設定値を適用することを担うコードは、ＳＤＭランタイム中でホストされる。

ＳＤＭは、抽象オブジェクト定義を越えた継承をサポートする。派生した定義は、その親によって開示されたプロパティを拡張することができ、その親のプロパティに関する値を設定することができる。派生した定義は、その親を参与者として識別する関係のいずれにも参与することができる。

関係定義は、通信、包含、委任、ホスティング、参照という５つのカテゴリに分けられる。

通信関係は、抽象エンドポイント定義間の可能性ある通信対話を取り込むのに使用する。通信関係があることは、識別された定義のエンドポイントを開示しているシステムが通信することが可能かもしれないことを示す。実際のリンク確立は、エンドポイントおよびエンドポイントの開示（exposure）に対する制約を受ける。

包含関係は、抽象オブジェクト定義が別の抽象オブジェクト定義のメンバを含むことができることを記述する。より具体的には、２つの抽象オブジェクト定義ＡとＢの間の包含関係では、Ａを実装する具象オブジェクト定義が、Ｂを実装する具象オブジェクト定義のメンバを含むことができる。

包含を使用して、開発者がアプリケーションを構築するときに生じる自然なネスト構造がモデル化される。メンバオブジェクトを含めることにより、親は、含まれたオブジェクトの存続期間および可視性を制御することができる。ランタイム空間中のすべてのオブジェクトインスタンスは、他のオブジェクトインスタンスのメンバとして存在し、完全に接続されたインスタンスセットを形成する。したがって、包含関係のセットは、インスタンス空間で生じる許容される包含パターンを記述する。

委任関係は、含まれるオブジェクトメンバを選択的に開示するのに使用する。具体的には、委任を使用して、システム定義からのエンドポイントメンバを開示する。サブシステムからエンドポイントを委任することにより、外側のシステムは、特定のプロトコル上で、プロトコルの奥にある実装を開示することなく通信する能力を呈する。

ホスティング関係および参照関係は、従属関係の２つの形である。ホスティング関係は、具象オブジェクトのインスタンスを生成できるようになる前に存在すべき抽象オブジェクトの間の主要な従属性を記述する。あらゆるインスタンスは、ちょうど１つのホスティング関係にゲストとして参与すべきであり、この結果、ホスティング関係はまた、完全に接続されたツリーをインスタンス空間にわたって形成する。参照関係は、パラメータフローおよび構築順序付けに使用することのできる追加の従属性を取り込む。

２．３ 具象オブジェクト定義および関係定義
抽象オブジェクト定義から具象オブジェクト定義を構築し、抽象関係定義から具象関係定義を構築する。

抽象オブジェクト定義と抽象関係定義の組合せは、ターゲットシステムをモデル化するためのスキーマを定義する。具象オブジェクト定義の役割は、抽象定義空間のサブセットを使用して、１つまたは複数の抽象定義に基づく再使用可能な構成を生み出すことである。単純な類比として、抽象定義空間は、データベースに関するスキーマに例えることができる。この場合、具象オブジェクト定義は、データベース中の行のセットのための再使用可能テンプレートを表すことになる。行は、具象オブジェクトのインスタンスが生成されたときだけデータベース中に生成される。設計時妥当性検査を行うために、データベース中の行をスキーマの制約（例えば外部キーなど）に対して妥当性検査するのと同じようにして、具象オブジェクト定義を抽象定義空間に対して妥当性検査することができる。

各具象オブジェクト定義は、特定の抽象オブジェクト定義に対する実装を提供する。実装は、設定スキーマに対する拡張と、設定に関する値と、オブジェクトメンバ、関係メンバ、制約メンバ、フローメンバに関する宣言とを含む。具象オブジェクトの挙動は、抽象オブジェクトの定義に従う。すなわち、抽象システム定義が具象システム定義になり、抽象エンドポイント定義が具象エンドポイント定義になり、抽象リソース定義が具象リソース定義になる。

各具象関係定義は、特定の抽象関係定義に対する実装を提供する。実装は、設定宣言および値と、同じ関係カテゴリ（ホスティング、包含、通信など）のネストされたメンバと、関係に参与することのできる型に対する制約とを含むことができる。

具象ホスティング関係は、ある具象オブジェクトのメンバを別の具象オブジェクト上にマッピングすることを定義するのに使用する。例えば、具象ホスティング関係を使用して、ウェブアプリケーションとそれが展開されることになるＩＩＳホストとの間のバインドを識別することができる。所与の型に対して複数の具象ホスティング関係が存在することができ、これにより開発者は、特定のトポロジに対して種々の展開構成を定義することができる。

２．４ メンバ
具象型は、他の具象または抽象オブジェクトのメンバを宣言することができる。これらをオブジェクトメンバと呼ぶ。この場合、これらのメンバは、オブジェクトメンバ間の関係を定義する関係メンバから参照される。

オブジェクトメンバは、特定のオブジェクト定義のインスタンスを生成するのに使用される。設定フローを使用して、オブジェクトに関する値を提供することができる。オブジェクトメンバを宣言するとき、ユーザは、オブジェクトメンバが、外側のシステムが生成されるのと同時に生成されるか（値セマンティクス）、あるいはいくらか後で行われる新しい明示的動作によって生成されるか（参照セマンティクス）を決定することができる。

関係メンバは、オブジェクトメンバが生成されたときにそれらが参与することになる関係を定義する。オブジェクトメンバがその親に含まれる場合は、包含関係メンバを型メンバと外側の型との間で宣言する。オブジェクトメンバが委任される場合は、委任関係メンバを、オブジェクトメンバとネストされたオブジェクトメンバとの間で定義する。通信関係メンバは、オブジェクトメンバ上のエンドポイント間で宣言することができ、従属関係メンバ（参照およびホスティング）は、オブジェクトメンバまたはネストされたオブジェクトメンバ間で宣言することができる。

関係制約は、特定のオブジェクトが参与を望む関係のセットを限定するのに使用する。これらは、特定の関係に対する制約、および関係の他方の端の参与者に対する制約を識別する。

２．５ インスタンス空間
ＳＤＭランタイムに記憶されているインスタンス空間は、モデル化システムの現在状態を反映する。ランタイムは、生成されたインスタンスと、これらのインスタンス間の関係との完全な記録を含む。各インスタンスにはバージョン履歴が関連し、バージョン履歴中では、各バージョンが変更要求にリンクされている。

新しいインスタンスを生成するプロセスは、変更要求によって開始される。変更要求は、既存のインスタンスの特定メンバに関連する型および関係に対する、生成、更新、削除要求のセットを定義する。ルートは特別なケースである。

変更要求は、ランタイムによって展開され、すべての制約に対して検証されてから構築される。展開プロセスでは、オブジェクトの構築要求の一部として暗黙的に構築される、オブジェクトに含まれるオブジェクトインスタンスおよび関係インスタンスを識別し、次いで設定フローをすべての関係にわたって評価する。検証ステップでは、必要な関係がすべて存在すること、および関係がすべての制約を満たすことをチェックする。最後に構築プロセスでは、各インスタンスの展開、更新、または削除にわたる適切な順序付けを判定し、次いで、適切なアクションが実施されるように、各インスタンスを正しいシーケンスでインスタンスマネージャに渡す。

２．６ レイヤ化
ＳＤＭモデルの目標は、アプリケーション開発者と、ソフトウェアインフラストラクチャ設計者と、データセンタ構築者との間で、関心が分離されるようにすることである。これらの各グループは、特定のサービスに焦点を合わせ、異なる従属性セットを有する。

例えば、開発者は主に、ＳＱＬ、ＩＩＳ、ＣＬＲなど、開発者が依存するホストの間の構成および接続性を気にかける。ホスト構成の設計者は、ネットワークトポロジおよびＯＳ（operating system）構成を気にかけ、ネットワークトポロジ、ＯＳ構成、記憶マッピングを開発する構築者は、データセンタに存在するハードウェアについて知る必要がある。

この関心の分離をサポートするために、ＳＤＭは、レイヤ化の概念を呈示する。レイヤ化は、アプリケーションが依存するサービスをアプリケーションの包含構造の一部として宣言せずに、ホスティング関係を用いてアプリケーションをサービスにバインドするものである。

ＳＤＭモデルの一部として、以下の４つのレイヤが識別される。
アプリケーションレイヤ
・アプリケーションレイヤは、制約されたコンテキストでアプリケーションを構築することをサポートする。コンテキストは、ホストレイヤで定義されるホストの構成によって定義される。
・アプリケーションレイヤ中のシステム定義の例としては、ウェブサービス、データベース、およびＢｉｚＴａｌｋ（商標）スケジュールが挙げられる。
ホストレイヤ
・ソフトウェアコンポーネントからデータセンタを構築する。コンポーネント間の接続を構成する。これらのコンポーネントのいくつかは、アプリケーションレイヤのためのホストとして働く。
・このレイヤ中のシステム定義の例−ＩＩＳ（商標）、ＳＱＬ、ＡＤ、ＥＸＣＨＡＮＧＥ、ＤＮＳ（Domain Name System）、ＢｉｚＴａｌｋ（商標）
ネットワーク／ＯＳ／ストレージレイヤ
・データセンタネットワークおよびプラットフォームを構築する。ネットワークセキュリティモデルおよびオペレーティングシステムプラットフォーム構成を構成する。オペレーティングシステム構成にストレージを追加する。
・このレイヤ中のシステム定義の例−ＶＬＡＮ、Ｗｉｎｄｏｗｓ（登録商標）、Ｆｉｌｔｅｒ、Ｓｔｏｒａｇｅ
ハードウェアレイヤ
ハードウェアレイヤは、データセンタに存在するマシンのタイプ、およびこれらのマシン間に存在する物理接続を識別する。

図１１に、レイヤ４ウェブアプリケーションをレイヤ３ウェブサーバホストにマッピングする例を示す。各レイヤの外側のボックスはシステムを表し、境界上のボックスはエンドポイントを表し、内側のボックスはリソースを表す。これらの各要素を、ホスティング関係を介して下のレイヤにあるホストにマッピングする。

システムに必要な関係を満たすために、マッチする機能を有するホストシステムにこのシステムをバインドする。このプロセスを配置（ｐｌａｃｅｍｅｎｔ）と呼ぶ。設計時、可能な配置を表す具象ホスティング関係を構築する。展開時、具象ホスティング関係のインスタンスをインスタンス化して、ゲストシステムインスタンスをホストシステムインスタンスにバインドする。

２．７ モデル評価
ＳＤＭモデルには、分散システムに対する変更を管理するための明確に定義されたプロセスが関連付けられる。

各変更は、いくつかの処理ステップを経た宣言変更要求によって進められ、その後、要求中の動作が配信され、次いでターゲットシステムに対して実行される。

３ 実装の詳細
この設計の実装の詳細を記述せよ。例えば、各コンポーネントがどのように働くか、低レベルのアルゴリズムは何か、どんなクラスおよびデータ構造が実装にとって重要か、などである。誰かがこれを読むことによって、あなたのコードを読まなくてもあなたの実装を完全に理解できなければならない。

３．１ 名前付け
ＳＤＭ中には、オブジェクトを識別するための厳密な名前付けシステムが必要な場所がいくつかある。以下の名前付けシステムによれば、型の生成者は、開発者が元々公表した定義と同じ定義であることを定義のユーザが確信できるような形で、定義に署名することができる。

以下のヘッダは、ＳＤＭ名前空間における識別子の例である。

別の名前空間中の型を参照するには、その名前空間をインポートする必要がある。
<import alias=”FileSystem”name=”FileSystem”version=”0.1.0.0”publicKeyToken=”AAAABBBBCCCCDDDD”/>
次いで、エイリアスを使用して、その名前空間内の型を参照することができる。
FileSystem:file

３．１．１ 識別
ＳＤＭの名前は、それらが定義される名前空間を範囲とする。名前空間は、名前、バージョン、言語、および公開鍵トークンで識別され、単一のファイル内に含まれる。

識別の基本形は、名前、バージョン、カルチャ、プラットフォーム、および公開鍵トークンを含む。
<xs:attributeGroup name=”Identity”>
<xs:attribute name=”name” type=”simpleName” use=”required”/>
<xs:attribute name=”version” type=”fourPartVersionType” use=”required”/>
<xs:attribute name=”publicKeyToken” type=”publicKeyTokenType” use=”optional”/>
<xs:attribute name=”culture” type=”xs:string” use=”optional”/>
<xs:attribute name=”platform” type=”xs:string” use=”optional”/>
</xs:attributeGroup>

基底識別を使用して、既存の識別を参照することができ、あるいは、署名および公開鍵と共に、新しい厳密識別を生成することができる。文書には秘密鍵を使用して署名することになり、それにより文書のユーザは、公開鍵を使用してその内容を検証することができる。

公開鍵トークンは、公開鍵／秘密鍵の対の公開部分を識別する１６文字の１６進ストリングである。これは公開鍵ではなく、単に公開鍵の６４ビットハッシュである。
<xs:simpleType name=”publicKeyTokenType”>
<xs:annotation>
<xs:documentation>Public Key Token: 16 hex digits in size</xs:documentation>
</xs:annotation>
<xs:restriction base=”xs:string”>
<xs:pattern value=”([0-9]|[a-f]|[A-F]){16}”/>
</xs:restriction>
</xs:simpleType>

３．１．２ バージョン
ファイルバージョンは、Ｎ．Ｎ．Ｎ．Ｎの形をとる４部分の数で定義され、０≦Ｎ＜６５５３５である。慣例的に、この数はメジャー．マイナー．ビルド．リビジョンを表す。

３．１．３ 簡易名
簡易名は、英数字および限られた句読点からなる。名前は数字以外の文字で始まらなければならない。

識別子についてはＣ＃定義に準拠する予定である。適切な章（２．４．２）を以下に挿入してある。仕様は以下で見ることができる。

http://devdiv/SpecTool/Documents/Whidbey/VCSharp/Formal%20Language%20Specification/CSharp%20Language%20Specification.doc
ＳＤＭモデルでは、頭に「＠」の付く名前はサポートされないことに留意されたい。

３．１．４ 予約済みの名前
以下は、ユーザがＳＤＭモデル中のオブジェクトの名前を生成するときに使用できない予約済みの名前のリストである。

一定のコンテキスト内で、いくつかの名前が予約されている。

以下の名前は、ＣＬＲとの統合により予約されている。

３．１．５ 他の名前空間の参照
他の名前空間を現在の名前空間にインポートしてからエイリアスを名前空間に関連付けることにより、名前空間が他の名前空間を参照することを可能である。インポートされた名前空間は、名前、バージョン、および公開鍵トークンで参照される。バージョニングについては３．１６章で述べる。

３．１．６ 修飾パス
修飾パスはこの場合、現在の名前空間中またはエイリアシングされた名前空間中で定義される定義とマネージャとのいずれかを指す名前である。
[<alias>:] <simpleName> (.<simpleName>)*
エイリアスはインポートステートメント中で定義される。以下の簡易名は、型を識別し、パスの場合はネストされた型を識別する。

３．１．７ 定義およびメンバパス
パスは、メンバまたは設定を識別する一連の名前である。パスは、パスに関連するオブジェクトまたは関係によって定義される、周知の名前またはメンバ名で始まるべきである。

３．１．８ インスタンスパス
インスタンス空間中のパスはＸＰａｔｈに基づく。ＸＰａｔｈ中の要素名はメンバ名に対応し、ＸＰａｔｈ中の属性は設定に対応する。

３．１．９ 名前解決
エイリアスで始まらない名前は、完全修飾されていない。このことは、これらが評価される範囲が、得られるバインドを変化させる可能性があることを意味する。この一例は、ネストされた定義である。ネストされた定義名を解決するとき、ローカル範囲中の定義は、より広い範囲内の定義を隠蔽する。

３．２ 設定
すべての定義は、設定宣言を開示することができる。これらの設定は、抽象定義から具象定義を生成するとき、または定義を別の定義内のメンバから参照するときに、提供できる値を記述するのに使用することができる。

設定を定義するには、まずＸＳＤを使用して設定の定義を定義する必要がある。

次いで、この定義を使用する設定であって、設定の挙動を定義するための属性セットを含む設定を宣言することができる。
<settingDeclaration name=”valueType”type=”registryValueType”access=”readwrite”dynamic=”false”required=”true”/>
設定宣言が得られれば、この設定の値を提供することができる。
<settingValue name=”valueType” fixed=”true”>long</settingValue>

３．２．１ 設定定義
ＸＳＤスキーマを使用して、設定宣言によって使用される設定定義を定義する。スキーマからの単純型および複合型の使用がサポートされる。ただし、これらの型の定義をサポートする他のスキーマ要素がある場合もある。

設定定義のセクションは、名前空間宣言および名前空間インポートを含めた、完全なＸＭＬスキーマを含むべきである。ＸＳＤスキーマ中のインポートが、ＸＳＤスキーマの名前空間を除いてはＳＤＭファイル中のインポートとマッチすることをチェックする。このことは、参照されるすべての型が別のＳＤＭファイル中で定義されるべきであることを意味する。スキーマは、自由裁量のＸＳＤファイル中で定義される型を参照することはできない。
<xs:complexType name=”settingDefinitions”>
<xs:sequence>
<xs:element ref=”xs:schema”/>
</xs:sequence>
<xs:attribute name=”manager” type=”qualifiedName” use=”optional”/>
<xs:attribute name=”clrNamespace” type=”xs:string” use=”optional”/>
</xs:complexType>

設定は、以下の３つの分離可能な名前空間から解決可能であるべきである。
ａ）ＳＤＭ名前空間−システム、リソース、エンドポイント、関係、制約、またはフロー型内の設定型を指すとき。
ｂ）ＣＬＲ名前空間−ＣＬＲ内の強く型付けされたクラスを使用する設定を指すとき、および設定型が他の設定型上に構築されるとき。
ｃ）ＸＳＤ名前空間−設定型が他の設定型を使用して構築されるとき。

これが機能するためには、設定を宣言する方法に対していくつかの制約を課すべきである。
ａ）すべての設定は、ＣＬＲ、ＳＤＭ、およびＸＳＤの各名前空間内で同じグループにあるべきである。すなわち、２つの設定が１つの名前空間で共にある場合、これらは３つの名前空間すべてで共にあるべきである。
ｂ）ＸＳＤスキーマ定義内のインポートされた名前空間は、ＳＤＭファイル中のインポートされた名前空間、および関連するヘルパアセンブリ中のインポートされた名前空間とマッチすべきである。
ｃ）ＸＳＤ名前空間を除いては、ＸＳＤスキーマ中のすべてのインポートされた名前空間は、ＳＤＭファイル内で定義されるべきである。

インポートされたＳＤＭ文書からのＸＳＤ型へは、ＱＮａｍｅを使用してアクセス可能である。
<alias>:<type-name>
したがって例えば、以下の例に示すように、Ｆｏｏ．ｓｄｍがＢａｒ．ｓｄｍをインポートした場合、Ｂａｒ．ｓｄｍの設定型は、Ｆｏｏ．ｓｄｍのｓｅｔｔｉｎｇＴｙｐｅｓ要素中で参照することができる。
<!--Foo.sdm-->
・・・
<import alias=”bar” location=”Bar.sdm”・・・/>
・・・
<settingTypes>
・・・
<xs:simpleType name=”D”>
<xs:restriction base=”bar:B”・・・/>
</xs:simpleType>
・・・
</settingTypes>
<!--Bar.sdm-->
・・・
<settingTypes>
・・・
<xs:simpleType name=”B”>
<xs:restriction base=”xs:string”・・・/>
</xs:simpleType>
・・・
</settingTypes>

３．２．２． 組込み単純データ型
ＳＤＭは、ＸＳＤとＣ＃の名前空間の共通部分である限られた組込みデータ型のセットをサポートする。これらの型は、ＳＤＭランタイムによってネイティブにサポートされ、以下の表に定義される。これらの型に加えて、ユーザは、ＸＳＤとＣＬＳ型間のユーザ自身のマッピングを自由に構築して使用することができる。

これらの型は、Ｃ＃およびＸＳＤの型空間におけるこれらの型の互換派生物にフローすることができる。例えば、ｓｔｒｉｎｇの値を、ストリングに対する制限を定義したＸＳＤ型にフローすることができ、ａｎｙの値を、ｔｙｐｅ＝”ａｎｙ”を受け入れる設定にフローすることができる。

３．２．２．１ ＸＳＤ組込み型
図１２に、例示的な組込みデータ型階層を示す。

３．２．２．２ Ｃ＃データ型

３．２．２．３ サポートされる変換
以下は、ＸＳＤ型とＣＬＳ型の間に存在する変換である。

３．２．３ 設定宣言
設定宣言セクションでは、前のセクションからの設定宣言を使用して、名前付き設定を生成する。属性を使用して、各設定に関する情報をさらに提供する。

３．２．４ リストサポート
多値設定の操作をサポートするために、単純な設定値リストがサポートされる。リストは、設定宣言と同じ定義の値のシーケンスである。リストは、置換またはマージできる別のリストにフローすることができる。値をリストにマージする際の重複検出はサポートされない。というのは、これは、設定フローを使用すればよりフレキシブルに行うことができるからである。また、どんな形の順序付けもサポートされない。

リスト宣言は、以下のように真に設定された属性ｌｉｓｔを含む。
<settingDeclaration name=”roles”type=”xs:string”list=”true”/>
次いで、ｓｅｔｔｉｎｇＶａｌｕｅＬｉｓｔを使用して値を提供する。リストを提供するとき、ユーザは、前の値と置換またはマージするかどうかを指定することができる。

ＳＤＭは、値リストの単純な操作をサポートする。フローメンバからのパスが設定宣言をターゲットとするとき、結果的な挙動は、パスのどちらかの端における定義に依存する。

３．２．５ 設定属性
設定属性は、ランタイムが特定の設定の挙動を記述するのに使用する。

３．２．６ 設定値
設定が単一の値として宣言されたかリストとして宣言されたかに応じて、設定に関する値は、設定値要素と設定値リスト要素のどちらかを使用して提供することができる。

３．２．６．１ 設定値
設定値は、特定の設定宣言に関する値を提供するのに使用する。値は、宣言に関連する定義とマッチすべきである。値がｆｉｘｅｄに宣言された場合、提供された値は、値が固定されるポイントに応じて、すべての派生定義中でまたは参照するメンバ中で使用されることになる。値が固定された後は、オーバーライドすることはできない。

３．２．６．２ 設定値リスト
設定値リストは、リストとして宣言された設定に関する１つまたは複数の値を提供するのに使用する。値を宣言するとき、ユーザは、前の値とマージするか、あるいは前の値すべてを上書きするように決定することができる。

３．２．７ 設定継承
設定継承は、派生定義が基底定義からのすべての設定宣言を暗黙的に含むことを意味する。設定継承の重要な側面のいくつかを以下に示す。
・設定継承は推移的である。ＣがＢから派生し、ＢがＡから派生した場合、Ｃは、Ｂ中で宣言された設定ならびにＡ中で宣言された設定を継承する。
・派生定義は、それが拡張する基底定義から継承した設定宣言に新しい設定宣言を追加することができるが、継承した設定の定義を削除することはできない。

３．２．８ 型変換
組込み型間のロスレス（lossless）変換がサポートされる。他の型変換は、適切な変換を実行するためにフローが必要である。

３．３ 属性
ＳＤＭ中のオブジェクトの多くは、オブジェクトのコア挙動と直交する挙動を取り込むように属性付けることができる。以下のように定義される一般的な属性付けモデルが使用される。

３．４ 定義およびメンバ
３．４．１ 定義
定義（definition）は、オブジェクト定義、関係定義、制約定義、フロー定義が派生する基底である。すべての定義は、設定スキーマおよび設計表面（surface）データを含むことができる。各定義は、簡易名で識別され、マネージャを参照する。マネージャは、この特定の定義のためにＳＤＭランタイムに拡張サポートを提供することを担う。

設定スキーマは、この定義のインスタンス上に見られる値を定義する。ＤｅｓｉｇｎＤａｔａ要素を使用して、設計表面上でこの定義の表示および編集に特有のデータを含める。
<xs:complexType name=”Definition”>
<xs:sequence>
<xs:element name=”Description” type=”Description” minOccurs=”0”/>
<xs:element name=”DesignData” type=”DesignData” minOccurs=”0”/>
<xs:choice minOccurs=”0” maxOccurs=”unbounded”>
<xs:element name=”SettingDeclaration” type=”SettingDeclaration”/>
<xs:element name=”SettingValue” type=”SettingValue”/>
<xs:element name=”SettingValueList” type=”SettingValueList”/>
</xs:choice>
</xs:sequence>
<xs:attribute name=”Name” type=”SimpleName” use=”required”/>
<xs:attribute name=”Manager” type=”QualifiedName” use=”optional”/>
<xs:attribute name=”ClrClassName” type=”xs:string” use=”optional”/>
</xs:complexType>

３．４．２ メンバ
メンバは、ランタイム時に存在することのできる定義インスタンスを識別するのに使用する。すべてのメンバは、型の範囲内で固有の名前で識別され、それらが参照する定義に関する設定を提供することができ、設計表面特有のデータを含むことができる。

３．５ 設定フロー
設定フローは、オブジェクト定義のメンバ間および関係への参与者間でパラメータを渡すのに使用する。フローの一部として、ユーザは、変形を用いて設定値を結合または分離し、新しい設定値を計算することができる。

すべての設定フローメンバは、フロー定義を使用して変形を実装する。フロー定義は、ＳＤＭファイル中で宣言される。以下は、ＵＲＬ（Uniform Resource Locator）を解析するフロー型である。

次いで、フローメンバをオブジェクト内または関係内で宣言する。フローメンバは、フロー定義への入力を提供し、次いでフローからの出力をターゲット設定に向けて送る。

３．５．１ フロー定義
フロー定義は、設定値のセットに適用したいと思う特定の変形を定義するのに使用する。フロー定義は、入力設定（書込み専用設定）および出力設定（読出し専用設定）と、変換を定義するための入力インタフェースなど、設計表面特有の情報に関する設定データセクションと、ＳＤＭファイルを閲覧するときに使用される記述とを定義する設定スキーマを開示する。フロー定義は、それが定義される名前空間内の名前で識別される。定義はまた、ランタイムがフローを評価するときにランタイムをサポートすることになるマネージャも識別する。

簡単な変形が必要なときにフロー要素の構築を単純にするために、ランタイムはいくつかの標準フロー定義を含むものと考えられる。例としては、コピー、マージ、およびストリング代用が挙げられる。フロー定義はパラメータ化することができるので、構成パラメータに基づいて異なるアクションを実施する１つまたは複数の単純な変形があることも考えられる。

３．５．２ フローメンバ
各フロー要素は、１つまたは複数のソースノード、１つまたは複数の宛先ノード、いくつかの静的設定、およびフロー定義を識別する。フローが評価されるとき、ソースノードからソースデータが収集され、フロー要素からの設定と結合され、変換のためにフロー定義に渡される。出力データは宛先ノードに渡される。

ソース値の１つが変化したときは、フローの再評価がトリガされる。この理由で、値の反転を引き起こす循環フローを回避する必要がある。値が一定のままである場合は、ループは終了する。ランタイムは、スタック深度を常に把握していることによって、無限ループを検出し終了させる。

３．５．３ 設定ターゲット
設定ターゲットは、フローが定義されているコンテキストで周知である名前に関係するメンバまたはネストされたメンバ中の設定値へのパスを識別する。周知の名前の例としては、定義または参照宣言中のｔｈｉｓ、ホスティング関係宣言中のｈｏｓｔおよびｇｕｅｓｔ、または制約宣言内で定義されたｔａｒｇｅｔが挙げられる。設定ターゲットはまた、パスによって識別される設定のソース値と宛先設定のどちらかとして使用されることになる関連するフロー定義上の設定も識別する。

出力パスは、ターゲット値を固定および置換するためのセマンティクスをサポートする、設定ターゲットの変形である。

３．６ 設定制約
制約は、定義のメンバの設定値に対する制限、または関係への参与者に対する制限を識別するのに使用する。これらの制限は、設計時と展開時の両方においてインスタンス空間中で評価する。

すべての設定制約は、制約定義を使用して設定値を評価する。制約定義は、設定宣言を使用して、それが制約する値を識別する。以下の制約定義は、２つの引数および１つの演算子を利用する単純な比較関数を実装し、次いで制約を評価し、最後に成功またはエラーを返す。

次いで制約メンバを使用して、評価のために制約型に値を提供する。

３．６．１ 制約定義
制約定義は、入力値のセットに作用する制約を定義する。制約をパラメータ化して、カスタム挙動を選択することができ、あるいは、パラメータを使用してその挙動を定義する単純な制約エンジンをサポートすることができる。抽象オブジェクト間の既知の関係をサポートするために、単純なパラメータ値制約および複雑な制約セットについて、標準的な制約定義のセットが書かれることが考えられる。

３．６．２ 制約メンバ
制約メンバは、特定の制約定義に関する入力値のセットを識別する。メンバは、設定に関する静的な値を識別することができ、入力ステートメントを使用して制約設定をパスにバインドすることができる。

３．７ システムエンドポイント定義およびリソース定義
この章では、抽象および具象オブジェクト定義に関するスキーマについて述べる。

抽象オブジェクト定義は、設定宣言のセットを開示し、それが参与する関係に対する制約を含むことができ、関連するマネージャをランタイム内に有する。

以下は、ウェブサーバについての抽象システム定義である。ウェブサーバは２つの設定を有し、また、少なくとも１つのｖｓｉｔｅ型を含むことを要する関係制約を有する。

ｖｓｉｔｅは、サーババインド情報を含む抽象エンドポイント定義である。

フロントエンドウェブサーバについての具象システム定義は、ウェブサーバカテゴリを静的内容として識別し、１個から１００個までの間のエンドポイントインスタンスを表すことのできる単一のｂｙＲｅｆｅｒｅｎｃｅエンドポイントメンバを含む。エンドポイントに関する具象エンドポイント定義は、システム定義内部にネストされ、ｖｓｉｔｅに関するｉｐ ＥｎｄｐｏｉｎｔをＥｎｄｐｏｉｎｔ８０として定義する。
<SystemDefinition name=”FrontendWebServer” implements=”WebServer” >
<SettingValue name=”category” fixed=”true”>staticContentOnly</settingValue>
<Port name=”contentOnlyVsite” type=”port80Vsite” isReference=”true” minOccurs=”1” maxOccurs=”100”/>
<PortDefinition name=”port80Vsite” implements=”vsite”>
<SettingValue name=”Endpoint” fixed=”true”>80</settingValue>
</PortDefinition >
</SystemDefinition>

３．７．１ オブジェクト定義
抽象および具象オブジェクトは、以下の基底オブジェクト定義を拡張する。基底型定義の要素に加えて、これらは、オブジェクトが参与する関係を制約する能力も共有する。

３．７．２ 抽象オブジェクト定義
抽象オブジェクト定義は、設計表面が開示する構成単位であってすべての具象オブジェクトの派生源である構成単位を定義するのに使用する。すなわち、具象オブジェクト定義は抽象オブジェクト定義を実装すべきである。

抽象オブジェクト定義は、単純な継承を追加することによってＳＤＭオブジェクトを拡張する。すなわち、ｅｘｔｅｎｄｓ属性を使用して、抽象オブジェクト定義に対する基底オブジェクト定義を識別する。次いで抽象オブジェクト定義は、基底オブジェクト定義から設定および関係制約を継承する。継承を通して、オブジェクト定義は、新しい設定および制約を追加することによって抽象オブジェクト定義の設定および制約を拡張することができる。

抽象オブジェクト定義はまた、それらが参与したいと思う関係に対して制約を追加することもできる。例えば、抽象オブジェクト定義は、一定の関係が存在することを必要とすることができ、あるいは関係の他方の端に配置できるオブジェクト定義を制約することができ、あるいは所与の関係に参与するインスタンス上の設定を制約することができる。

３．７．２．１ 抽象オブジェクト定義
すべての抽象オブジェクトは、それらが関連付けられたいと思うレイヤを識別することができる。これが提供されない場合、オブジェクト定義はどのレイヤでも使用できると見なされる。抽象オブジェクト定義は、それらが拡張する基底オブジェクト定義を識別することができ、その場合、そのオブジェクト定義の設定および制約を継承し、基底オブジェクト定義が参与する関係中で基底オブジェクト定義の代わりになることができる。

３．７．２．２ 抽象エンドポイント、システム、およびリソースオブジェクト定義
ＳＤＭモデル中の抽象オブジェクト定義には３つの分類がある。すなわち、抽象エンドポイント定義、抽象システム定義、および抽象リソース定義である。これらはそれぞれ、抽象オブジェクト定義の単純なリネームである。

エンドポイント定義は、通信エンドポイントを表す。エンドポイント上の設定は、バインドプロセスにおけるその使用に関係する。例えばクライアントサーバプロトコルの場合、サーバエンドポイント定義は、設定スキーマを使用して、エンドポイントにバインドするのに必要な設定を識別することができ、クライアントエンドポイント定義は、クライアント特有の接続属性を開示することができる。

システム定義は、データ、ソフトウェア、またはハードウェアの要素の集合を表すのに使用する。例としては、ウェブサービス、データベース、およびスイッチが挙げられる。リソース定義は、システム定義の一部として識別することのできる特定要素を取り込むのに使用する。

３．７．３ 暗黙的な基底定義
図１３に示すように、別の抽象オブジェクト定義を拡張しないすべての抽象オブジェクトは、エンドポイント、システム、リソースの基底定義のうちの１つを暗黙的に拡張する。これらの基底定義は、関係宣言および制約宣言中で使用することのできる各ツリーのルートを形成する。これにより、関係または制約は、ルートから派生する任意の型を、識別されるルート定義の代わりに使用できることを示すことができる。これらのルート型は常に抽象であり、直接インスタンス化することはできない。

これらの型の定義は、モデル内におけるそのインスタンス化を制御する基底制約を含む。これらはＳｙｓｔｅｍ．ｓｄｍ．で見ることができる。

３．７．４ 具象オブジェクト定義
具象オブジェクト定義は、抽象オブジェクト定義に対する実装を提供する。実装は、オブジェクトメンバおよび関係メンバと、実装される抽象定義の設定に関する値と、新しい設定宣言と、メンバ間およびメンバに対する制約間のフローとから構築される。

具象定義はまた、ネストされた定義の宣言を含むこともできる。これらの定義は、含んでいる定義の範囲内のメンバについて使用することができ、定義の範囲外の制約中で参照することができる。

３．７．４．１ 基底具象オブジェクト定義
基底具象型は、オブジェクト定義、継承する設定宣言、設計データ、オプションのマネージャ参照、名前、参与できる関係に対する制約、抽象定義の設定に関する値を提供する能力、その設定間およびそのメンバの設定間のフローを記述する能力を拡張する。次いで、具象定義が、実装する抽象定義を識別する能力を追加し、いくつかのオプション属性が、定義のバインド挙動をカスタマイズする能力を追加する。

３．７．４．２ オブジェクトメンバ
オブジェクトメンバは、抽象と具象のどちらかのオブジェクト定義を参照すべきである。これらはインスタンスのアレイを表すことができ、その場合、アレイの上限と下限を定義することができる。これらが参照メンバである場合は、オブジェクトをインスタンス化するユーザは、メンバに対するインスタンスを明示的に構築すべきである。参照メンバでない場合は、ランタイムは、外側のオブジェクトが生成されるのと同時にインスタンスを生成することになる。

ＳＤＭモデルでは、親が構築されるときに生成され親が破壊されるときに破壊されるメンバを、親に関係なく存続期間を有するメンバから区別する必要がある。この目的で、ＩｓＲｅｆｅｒｅｎｃｅ属性を使用する。単純に例えると、インスタンスの生成にｎｅｗが使用されるかどうかに基づいてスタックベースとヒープベースの構築が可能なＣ＋＋宣言に似ている。メンバがＩｓＲｅｆｅｒｅｎｃｅとしてマークされた場合は、オペレータ側で、インスタンスを生成してメンバと関連付けるための明示的な新しい操作が必要である。

こうすることにはいくつかの理由がある。
１．オペレータがシステムを構築するとき、ＩｓＲｅｆｅｒｅｎｃｅメンバを構築できることが開示される。これはオペレータの経験を大幅に単純化する。
２．ＳＤＭ文書が処理されるとき、文書のインスタンス空間が具象定義空間のインスタンス空間から変化することのできる明確な境界がある。

３．７．４．３ 関係メンバ
関係メンバは、オブジェクトメンバが生成されたときにオブジェクトメンバ間に存在する関係を識別する。関係インスタンスは、オペレータによって明示的に生成されるか、あるいはランタイムによって暗黙的に生成される。前者の例はインスタンス間のホスティング関係であり、後者の例はシステム間の通信関係である。

３．７．４．３．１ ホスティングメンバ
ホストメンバは、２つのオブジェクトメンバ間のホスティング関係を宣言するのに使用する。オブジェクトメンバは、含んでいる定義の直接のメンバとすることもでき、定義とメンバシップ関係を有するネストされたメンバとすることもできる。参照されるメンバと含んでいる定義との間には、メンバシップ連鎖があるべきである。

３．７．４．３．２ 通信メンバ
通信メンバは、定義の直接のシステムメンバのエンドポイントメンバ間における通信関係を宣言するのに使用する。

３．７．４．３．３ 包含メンバ
包含メンバは、型メンバが型によって包含されることを宣言するのに使用する。各型メンバは、包含されるか委任されるかのどちらかとすることができる。包含メンバは、包含関係の親値を自動的に関係のｔｈｉｓポインタに設定する。

３．７．４．３．４ 委任メンバ
委任メンバは、外側の型上のエンドポイント定義メンバと、外側の型の直接のシステムメンバ上のエンドポイント定義メンバとの間の委任関係をセットアップするのに使用する。

３．７．４．３．５ 参照メンバ
参照メンバは、外側のシステムの２つの直接メンバ間またはネストされたメンバ間の参照関係をセットアップするのに使用する。

３．７．４．４ エンドポイント定義
エンドポイント定義は、ネストされたソース型、リソースメンバ、ホスト関係メンバ、包含関係メンバ、参照関係メンバを宣言する能力を追加することにより、基底オブジェクトを拡張する。

３．７．４．５ サービス定義
システム型は、ネストされたエンドポイント、システム型、リソース型、エンドポイントメンバ、システムメンバ、リソースメンバ、ホスト関係、包含関係、接続関係、委任関係、参照関係に対するサポートを追加することにより、基底型を拡張する。

３．７．４．６ リソース定義
リソース型は、ネストされたリソース型定義、リソースメンバ、ホスト関係メンバ、包含関係メンバ、参照関係メンバを含むことができる。

３．７．４．７ 関係規則
オブジェクト定義の特定のインスタンスについて、このインスタンスが果たすことのできる各役割に関連するカーディナリティを、以下の表に識別する。

３．７．４．７．１ システム規則

３．７．４．７．２ エンドポイント規則

３．７．４．７．３ リソース規則

３．７．４．７．４ 注
あらゆるインスタンスは、ちょうど１つの包含関係と、少なくとも１つのホスティング関係とに参与すべきである。

これは以下のことを意味する。
Ａ）非参照メンバは包含関係を識別すべきである。
ｂ）参照メンバが構築されるためには、参照メンバは包含関係を識別すべきである。
ｃ）包含関係を有さない参照メンバは、他のメンバに委任することができるだけである。

３．８ 関係
関係は、型間の可能な対話を識別するのに使用する。これらはバイナリおよび有向であり、それぞれは、関係に参与することのできるインスタンスの型を識別する。関係はまた、関係に参与するインスタンスの設定を制約することもでき、関係にわたって設定値をフローすることができる。

以下は、型のセクションで述べたウェブサーバ上のウェブアプリケーションについての可能なホスティング関係である。この関係は、２つのシステムのセキュリティモデルが互換性を有することを検証するという制約を含み、また、サーバ名をｖｓｉｔｅからｖｄｉｒにコピーする設定フローメンバを含む。

関係は、関係に参与することになる型メンバを識別する関係メンバを宣言することによって使用する。

３．８．１ 関係定義
基底関係定義は、オブジェクト制約およびフローを定義に追加する。オブジェクト制約は、この関係のインスタンスに参与するオブジェクトインスタンスの設定値に関するステートメントである。例えば、ＤＣＯＭ（Distributed Component Object Model）接続を表す通信関係が、クライアントとサーバのセキュリティ設定が互換性を有することをチェックすることができる。この場合、設定間には、設計プロセスの一部として容易に取り込むことのできる厳密な関係がある。関係に対して４つの階乗的な設定の組合せがあるが、有効な組合せはずっと少数である。

フローは、関係の開発者があるインスタンスから別のインスタンスに値を転送することを可能にする。これにより、オブジェクト定義をそれらの可能な対話とは別に開発することができ、インスタンスは、特定のインスタンスを完全に記述するための関係グラフのサブセットを必要とするのではなく、情報のための参照ポイントとして自立することができる。

関係の名前は、その関係を含んでいる名前空間内で固有であるべきである。
<xs:complexType name=”RelationshipDefinition”>
<xs:complexContent>
<xs:extension base=”Definition”>
<xs:choice minOccurs=”0” maxOccurs=”unbounded”>
<xs:element name=”ObjectConstraintGroup” type=”ObjectConstraintGroup”/>
<xs:element name=”ObjectConstraint” type=”ObjectConstraint”/>
<xs:element name=”Flow” type=”FlowMember”/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>

３．８．２ 抽象関係
抽象関係は、２つの抽象オブジェクト定義間で定義される関係である。これらは、２つの定義間の可能な対話を表す。

３．８．２．１ 抽象通信関係
通信関係は、エンドポイント定義間の可能な通信リンクを取り込むのに使用する。これらを使用して、独立して展開されるソフトウェア要素間の対話を記述する。通信関係スキーマは、クライアントおよびサーバエンドポイント参照を追加することによって、基底関係スキーマを拡張する。

通信関係では、以下の抽象型の対の組合せが有効である。

３．８．２．２ 抽象ホスティング関係
ホスティング関係は、ゲストが構築されるためにホストが必要であることを取り込むのに使用する。１つのゲストに対して複数の可能なホストがあり得るので、このことは、ホスティング関係がホスト上にゲストを構築する任務も負うことを意味する。したがって、オブジェクトのインスタンスを生成するためには、ゲストから適合するホストへのホスティング関係があるべきである。

例えば、ウェブサービスオブジェクト定義とＩＩＳオブジェクト定義との間にホスティング関係があるとする。この場合、ＭｙＷｅｂｓｅｒｖｉｃｅおよびＭｙＩＩＳがそれぞれウェブサービスおよびＩＩＳを実装するものとすると、この関係は、ホスティング関係に対するマネージャを使用してシステムＭｙＩＩＳのインスタンス上にシステムＭｙＷｅｂｓｅｒｖｉｃｅのインスタンスを生成することが可能かもしれないことを示している。システムと関係の両方に存在する制約を評価し終えるまでは、この関係を生成することが可能になるかどうかはわからない。

ホスティング関係では、以下の抽象定義の対の組合せが有効である。

３．８．２．３ 抽象包含関係
２つの抽象オブジェクト間の包含関係は、親型（parentType）に基づく具象型がメンバ型（memberType）に基づくメンバを包含できることを取り込む。包含は、親インスタンスがメンバインスタンスの存続期間を制御することができ、メンバインスタンスに挙動を委任することができることを意味する。

包含関係では、以下の抽象定義の対の組合せが有効である。

３．８．２．４ 抽象委任関係
委任関係は、外側のシステムから、含まれるシステムに挙動を転送するのに使用する。これは、外側のシステム上のエンドポイントを内側のシステム上のエンドポイントに委任することによって行う。これにより、外側のシステムに向けられたであろうすべての対話を効果的に内側のシステム上のエンドポイントに転送することができる。委任は連鎖させることができ、それにより内側のシステムは、さらにその挙動を別のシステムに委任することができる。

委任関係は、委任に参与することのできる抽象エンドポイント定義の対を定義する。各関係は、プロキシとして働くことのできる抽象エンドポイント定義と、挙動の委任先とすることのできる抽象エンドポイント定義とを識別する。

委任関係では、以下の抽象型の対の組合せが有効である。

リソースおよびシステムの委任がレイヤ間のバインドをサポートできるようにすることもできる。例えば、ＩＩＳがファイルシステムの一部を、展開する必要なしに開示できるようにすることができる。

３．８．２．５ 抽象参照関係
参照関係は、ホスティング関係の従属性の他にある、インスタンス間の強力な従属性を取り込むのに使用する。これらの従属性を使用して、展開中に構築順序を制御し、インストール中および更新中にシステム間でパラメータをフローする。参照関係は強力な従属性を示すので、参照関係がシステム境界を越えることは許容できない。これは、あるシステム内のリソースが別のシステム内のリソースに対して従属性を有することはできないことを意味する。このような従属性があれば、システムはもはや独立した展開単位ではなくなる。システム間に従属性がある場合は、通信関係を使用する。通信関係は、システムの再インストールを必要とせずに、時の経過に伴って変化することができる。

参照関係では、以下の抽象型の対の組合せが有効である。

３．８．３ 暗黙的な基底関係
図１４に示すように、すべての抽象関係は、基底関係定義の１つを暗黙的に拡張する。これらの定義は、各関係ツリーのルートを形成する。こうすることにより、制約定義内からルート定義を参照することができ、ルート型から共通型制約を継承することができる。

３．８．４ 具象関係
具象関係は、２つの具象オブジェクト定義間の関係である。各具象関係は抽象関係を実装すべきである。抽象関係は、具象オブジェクト定義によって直接的または間接的（継承によって）に実装される抽象オブジェクト定義の、マッチする対の間にあるべきである。

３．８．４．１ ホスティング関係
データセンタにアプリケーションを展開するとき、アプリケーション内のシステムに関するすべての未解決ホスティング関係を解決する必要がある。これを行うために、オペレータは、必要な各ホスティング関係につきホスティングメンバを生成することが必要になる。オペレータの作業を簡略化し、開発者が展開プロセスをガイドできるようにするために、開発者は、代わりに具象ホスティング関係を生成することができる。オペレータがアプリケーション展開時に単一のホスティングメンバを宣言するだけで済むような形で、具象ホスティング関係を使用してホスティング関係メンバのセットをグループ化する。
<xs:complexType name=”HostingDefinition”>
<xs:complexContent>
<xs:extension base=”ConcreteRelationship”>
<xs:sequence>
<xs:element name=”Hosting” type=”HostingMember” minOccurs=”0” maxOccurs=”unbounded”/>
</xs:sequence>
<xs:attribute name=”GuestDefinition” type=”QualifiedName” use=”required”/>
<xs:attribute name=”HostDefinition” type=”QualifiedName” use=”required”/>
</xs:extension>
</xs:complexContent>
</xs:complexType>

ホスティング関係では、以下の具象型の対の組合せが有効である。

ゲストは、以下の場合かつその場合に限って、ホストにバインドすることができる。
Ｇｕｅｓｔ中の各ｇｕｅｓｔＭｅｍｂｅｒにつき、
Ｈｏｓｔ中の１つまたは複数のｈｏｓｔＭｅｍｂｅｒがあり、この場合に、
ｇｕｅｓｔＭｅｍｂｅｒ．ＴｙｐｅがｈｏｓｔＭｅｍｂｅｒ．ｔｙｐｅとホスティング関係を有し、
ｇｕｅｓｔＭｅｍｂｅｒ．ｈｏｓｔＣｏｎｓｔｒａｉｎｔｓがｈｏｓｔＭｅｍｂｅｒ．ｓｅｔｔｉｎｇｓに対して妥当性を有し、
ｈｏｓｔＭｅｍｂｅｒ．ｇｕｅｓｔＣｏｎｓｔｒａｉｎｔｓがｇｕｅｓｔＭｅｍｂｅｒ．ｓｅｔｔｉｎｇｓに対して妥当性を有し、
ｇｕｅｓｔＭｅｍｂｅｒの各メンバにつき、ｈｏｓｔＭｅｍｂｅｒのメンバへのバインドがある。

例えば、以下の具象関係は、レイヤ３システム（Ｂｉｋｅ）をレイヤ２ホスト（ｏｐｅｒａｔｉｎｇＳｙｓｔｅｍ）にバインドする。この場合、ホスティング関係に関する設定が「ｓｙｓｔｅｍ ｆｏｌｄｅｒ」のデフォルト値で定義される。この設定が、レイヤ３アプリケーションのシステムとレイヤ２ホストのシステムとの間のホスティング関係を定義する３つのホスティングメンバのうちの１つにフローされる。
<HostingDefinition name=”DefaultBikePlacement” guestDefinition=”Bike” hostDefinition=”OperatingSystem:OperatingSystem”>
<settingDeclaration name=”fileLocationRelativeToRoot” definition=”xs:sting” access=”readwrite” dynamic=”false”/>
<settingValue name=”dirPath”>systemFolder</settingValue>
<flow name=”copyPath” definition=”copy”>
<input name=”source” path=”dirPath”/>
<output name=”destination” path=”bikeExecutableHost.hostRelativePath”/>
</flow>
<hosting name=”bikeExecutableHost” relationship=”fileDirectoryHost”
guestMember=”guest.bikeFile” hostMember=”host.FileSystem”/>
<hosting name=”bikeEventKeyHost” relationship=”registryKeyRegistryKeyHost”
guestMember=”guest.bikeEventKey” hostMember=”host.Registry.ApplicationEventKey”/>
<hosting name=”bikeSoftwareKeyHost” relationship=”registryKeyRegistryKeyHost”
guestMember=”guest.bikeSoftwareKey” hostMember=”host.Registry.HKLM”/>
</HostingDefinition >

３．８．４．２ 参照関係
２つの具象型間の具象参照関係を使用して、通信関係を含まないシステム間の特定の従属性を取り込むことができる。例えば、インストールされるあるアプリケーションに対して、別のアプリケーションがすでに存在すべきであることを取り込むことができる。

参照関係では、以下の具象型の対の組合せが有効である。

３．９ オブジェクト制約および関係制約
オブジェクト制約および関係制約は、具象空間のトポロジを定義し、オブジェクトが特定の関係中で使用されたときのオブジェクトの設定を制約するために使用する。

例えば、ある抽象オブジェクト定義（Ａ）内で、この抽象定義の実装が別の抽象オブジェクト定義（Ｂ）のインスタンス１つを含むべきであると識別したい場合がある。少なくとも１つの適切な制約関係がすでにあるとすると、こうするには、Ａ内で以下のように見える関係制約を使用したことになる。

この制約は、Ａの実装が親の役割を果たし、関係の他方の端（メンバ）における型が型Ｂであるという、包含関係が存在すべきであることを識別する。Ｂの構成に対してより多くの制御が欲しい場合は、以下のように、型Ｂの設定に対する制約を追加することができる。

この場合、メンバの名前がストリング「ｍｙＰｏｒｔ」に等しいことを必要とする制約が追加されている。

また、制約は関係に追加することもできる。これらをオブジェクト制約と呼ぶ。関係内から、関係に参与するオブジェクトを制約する。関係中の各役割につき、オブジェクト定義を識別することができ、次いでこれらのオブジェクト定義に設定制約を追加することができる。関係から見ると、カーディナリティは常にｍｉｎＯｃｃｕｒｓ＝１およびｍａｘＯｃｃｕｒｓ＝１であり、したがってこれは制約宣言には現れない。

最後に、制約はネストすることができる。これにより、制約を１つに連鎖させることができ、外側の制約が、内側の制約に関するコンテキストを設定する。以下は、ｗｅｂＡｐｐシステムをホストするＩＩＳシステムの例であり、ＩＩＳシステムはこの場合、ｗｅｂＡｐｐが特定の型のエンドポイントだけを含むように制約する。

この場合、オブジェクト制約のグループを使用して、少なくとも１つが真となる可能性セットを指定する。

ネストされた制約は、外から中へ評価できるパスを形成する。パス上の各制約は、パス上の前のインスタンスならびに現在のインスタンスの設定にアクセスすることができる。ネストされた制約の評価は、識別されるシステム内で制約が定義されているかのように行われる。

以下の２つのシナリオは、ｆｏｏから見て等価なはずである。第１のシナリオでは、ｆｏｏが、含まれるシステムｂａｒに対して、ネストされた制約を配置しており、第２のシナリオでは、型ｂａｒがすでに制約を含んでいる。

シナリオ１：

シナリオ２：

３．９．１ 制約モデル
制約モデルには、ガードと述語という２つの部分がある。ガードは、述語を実行するコンテキストを定義するのに使用する。例えば関係内では、ガードを使用して、述語を実行したい型の特定の組合せを識別する。オブジェクト内では、ガードを使用して、他のオブジェクトに対する関係のセットを識別する。

次いで、それらのガードの要件が満たされたときに述語が実行される。述語には２つの形がある。すなわち、設定値を妥当性検査する設定制約と、制約のセットを妥当性検査するグループ制約である。

ガードの中にガードをネストすることができ、その場合、内側のガードは外側のガードが満たされたときだけチェックされる。これにより、関係構造の検証をサポートするパスを構築することができる。

ガードとその述語の組合せは、ガードがマッチし述語が真に評価される回数を示すカーディナリティを有することができる。

より正式には以下のとおりである。

ガードは、ＯｂｊｅｃｔＣｏｎｓｔｒａｉｎｔとＲｅｌａｔｉｏｎｓｈｉｐＣｏｎｓｔｒａｉｎｔのどちらかとして定義される。オブジェクト制約は、関係のいずれかの端に関連する２つのオブジェクト定義を識別する。関係制約は、関係定義およびターゲットオブジェクト定義を識別する。オブジェクト制約は任意選択または必須とすることができ、関係制約は下限と上限を有する。このカーディナリティの違いは、関係は常に２つの型しか識別できないが、型は複数の関係に参与できることを反映している。

Predicate:==SettingsConstraint(rule)|group{(guard)*}
述語は、規則を含む設定制約と、ガードのセットを含むグループとのどちらかである。述語は、ガードのコンテキストで評価される。設定制約の場合、述語は、ルートガードのオーナからの設定と、ネストされた各ガードによって識別されるコンテキストとを識別することができる。グループは、マッチして真に評価されるべきガードを少なくとも１つ含むガードセットを識別するのに使用される。

例：
1. RelationshipConstraint(containmentRelationship,webapp,0,1{}
この例は、ｗｅｂａｐｐとの包含関係があるときは常に真に評価されるガードを示している。このガードは、多くても１回、真に評価されることができる。それ以上のマッチがある場合は、エラーがユーザに返される。

この例では、ガードに述語を追加している。ガードは、関係定義とターゲット定義がマッチし、設定制約が真に評価されるときだけ、真に評価される。関係定義とターゲット定義がマッチし、設定制約が真でない場合は、エラーがユーザに返される。関係とターゲット型がマッチし、設定制約が複数回にわたって真に評価される場合は、エラーがユーザに返される。

この例では、ガードの中にガードをネストしている。外側のガードが真であるとき（制約を含む型がｗｅｂａｐｐも含む）、内側のガードは外側のガードのコンテキストで評価される。これは、内側の関係制約がｗｅｂａｐｐインスタンスのコンテキストで評価されることを意味する。ｗｅｂＡｐｐが０または１個のｖｄｉｒを含む場合は、内側の制約は真を返す。複数のｖｄｉｒを含む場合は、制約はユーザにエラーを返す。

オブジェクト制約のコンテキストが、プライマリオブジェクト定義（第１のオブジェクト定義）である。これは、関係制約がｗｅｂａｐｐのコンテキストで評価されることを意味する。関係制約は２つの可能なコンテキストを定義する。第１は関係であり、これはオブジェクト制約のためのコンテキストになる。第２はターゲットオブジェクト定義であり、これは関係制約のためのコンテキストになる。

この例では、グループを使用して、共にｗｅｂａｐｐのコンテキストで評価されることになる２つの関係制約を含めている。グループは、関係の少なくとも一方が発火して真を返すまでエラーを生じる。この場合では、ｗｅｂａｐｐはｖｄｉｒとｄｉｒｅｃｔｏｒｙのどちらかを含むべきである。

３．９．２ 基底制約
<xs:complexType name=”Constraint”>
<xs:sequence>
<xs:element name=”Description” type=”Description” minOccurs=”0”/>
<xs:element name=”DesignData” type=”DesignData” minOccurs=”0”/>
</xs:sequence>
<xs:attribute name=”name” type=”SimpleName”/>
</xs:complexType>

３．９．３ オブジェクト制約
オブジェクト制約は、関係の役割の一方または両方に対する制約を記述する。制約は、制約が失敗した場合に制約の識別を助けるための名前を有し、役割に関連する型をターゲットとする設定制約のリストを含み、さらに、インスタンスを、役割に関連する定義から派生したオブジェクトのインスタンスになるよう制約することもできる。

３．９．４ オブジェクト制約グループ
オブジェクト制約グループは、オブジェクト制約のセットを少なくとも１つのセマンティクスを使用して評価できるよう１つにグループ化することを可能にする。グループは、オブジェクト制約の少なくとも１つが関係上のオブジェクトとマッチし、次いでそれに含まれる述語が真に評価されない限り、エラーを返す。型制約がグループの直接のメンバである場合は、制約に関するｒｅｑｕｉｒｅｄ属性は無視される。

３．９．５ 関係制約
関係制約は、オブジェクトが参与することのできる関係を制約するのに使用する。関係制約は、関係定義を識別し、任意選択で、関係の他方の端におけるインスタンスのオブジェクト定義と、関係のカーディナリティも識別する。エラーメッセージ中で制約を識別できるように、制約には名前が与えられる。関係制約の本体は、関係と、関係の他方の端におけるインスタンスとの両方に関する述語を含む。

関係制約は、いくつかの目的で使用することができる。述語を追加せず単純にカーディナリティを使用する場合、これらは、インスタンスを正しく動作させるために提供すべき関係を識別するのに使用することができる。述語を伴う場合は、このオブジェクトが対話したいインスタンスに関する構成のセットを限定するのに使用することができる。
<xs:complexType name=”RelationshipConstraint”>
<xs:complexContent>
<xs:extension base=”Constraint”>
<xs:choice minOccurs=”0” maxOccurs=”unbounded”>
<xs:element name=”SettingsConstraint” type=”ConstraintMember”/>
<xs:element name=”RelationshipConstraint” type=”RelationshipConstraint”/>
<xs:element name=”RelationshipConstraintGroup” type=”RelationshipConstraintGroup”/>
<xs:element name=”ObjectConstraint” type=”ObjectConstraint”/>
<xs:element name=”ObjectConstraintGroup” type=”ObjectConstraintGroup”/>
</xs:choice>
<xs:attribute name=”Relationship” type=”QualifiedName” use=”required”/>
<xs:attribute name=”MyRole” type=”RolesList” use=”required”/>
<xs:attribute name=”TargetObject” type=”QualifiedName” use=”optional”/>
<xs:attribute name=”MinOccurs” type=”MinOccurs” use=”optional”/>
<xs:attribute name=”MaxOccurs” type=”MaxOccurs” use=”optional”/>
</xs:extension>
</xs:complexContent>
</xs:complexType>

３．９．６ 関係制約グループ
関係制約グループは、関係制約のセットを少なくとも１つのセマンティクスを使用して述語として評価できるよう１つにグループ化することを可能にする。グループは、含まれる関係制約の少なくとも１つが関係定義およびターゲットオブジェクトとマッチし、それに含まれる述語が真を返さない限り、エラーを返す。含まれる制約中の述語のいずれかがエラーを返す場合は、これらのエラーがユーザに伝えられる。含まれる関係制約のｍｉｎＯｃｃｕｒｓカーディナリティは無視されるが、ｍａｘＯｃｃｕｒｓカーディナリティに違反した場合は、エラーがユーザに返される。

３．１０ オブジェクトマネージャ
オブジェクトマネージャは、型および関係がカスタム挙動をランタイム環境に挿入するのに使用する機構である。マネージャがサポートすることのできる役割は、管理する型ごとにいくつかある。すなわち、型のインストールに参与することができ、型のＣＬＲ表現を提供することができ、型間のバインドをどのように解決するかについてのポリシー決定に関与することができ、複雑な制約およびフローの実施を提供することができる。

オブジェクトマネージャのすべての役割は、厳密名が付いたクラスへのエントリポイントとしてＣＬＲを介して開示される。オブジェクトマネージャは、ＳＤＭ中の他の型と同じようにしてパッケージされバージョニングされる。すなわち、システム配信ユニットで配信され、それらのバージョンおよび厳密名は、それらが宣言されるＳＤＭファイルに由来する。
<xs:complexType name=”Manager”>
<xs:sequence>
<xs:element name=”Description” type=”Description” minOccurs=”0”/>
</xs:sequence>
<xs:attribute name=”Name” type=”SimpleName” use=”required”/>
<xs:attribute name=”AssemblyName” type=”xs:string” use=”required”/>
<xs:attribute name=”Version” type=”FourPartVersionType” use=”optional”/>
<xs:attribute name=”PublicKeyToken” type=”PublicKeyTokenType” use=”optional”/>
<xs:attribute name=”Culture” type=”xs:string” use=”optional”/>
<xs:attribute name=”Platform” type=”xs:string” use=”optional”/>
<xs:attribute name=”SourcePath” type=”xs:string” use=”optional”/>
</xs:complexType>

３．１０．１ 役割
オブジェクトマネージャは、それがサポートする型ごとに、１つまたは複数の役割をサポートすることができる。これらの役割には以下のものが含まれる。
ａ）型または関係に関する制約の評価
ｂ）型または関係に関するフローの評価
ｃ）型に関する構築／破壊／更新サポート
ｄ）型または関係上の設定に関するオブジェクト表現の開示
ｅ）型または関係に関する発見の実施
ｆ）型または関係をとりまく設計表面特有ＵＩのサポート

３．１１ ＳＤＭ文書構造
ＳＤＭ文書は、関係とオブジェクトとマネージャとのセットについて、強力な識別、バージョニング、およびローカライゼーション情報を提供する。
<xs:element name=”Sdm”>
<xs:complexType>
<xs:sequence>
<xs:element name=”Information” type=”Information” minOccurs=”0”/>
<xs:element name=”Import” type=”Import” minOccurs=”0” maxOccurs=”unbounded”/>
<xs:element name=”DesignData” type=”DesignData” minOccurs=”0”/>
<xs:element name=”SettingDefinitions” type=”SettingDefinitions” minOccurs=”0”/>
<xs:choice minOccurs=”0” maxOccurs=”unbounded”>
<xs:element name=”AbstractEndpointDefinition” type=”AbstractEndpointDefinition”/>
<xs:element name=”AbstractSystemDefinition” type=”AbstractSystemDefinition”/>
<xs:element name=”AbstractResourceDefinition” type=”AbstractResourceDefinition”/>
<xs:element name=”AbstractCommunicationDefinition” type=”AbstractCommunicationDefinition”/>
<xs:element name=”AbstractHostingDefinition” type=”AbstractHostingDefinition”/>
<xs:element name=”AbstractContainmentDefinition” type=”AbstractContainmentDefinition”/>
<xs:element name=”AbstractDelegationDefinition” type=”AbstractDelegationDefinition”/>
<xs:element name=”AbstractReferenceDefinition” type=”AbstractReferenceDefinition”/>
<xs:element name=”ReferenceDefinition” type=”ReferenceDefinition”/>
<xs:element name=”HostingDefinition” type=”HostingDefinition”/>
<xs:element name=”EndpointDefinition” type=”EndpointDefinition”/>
<xs:element name=”ResourceDefinition” type=”ResourceDefinition”/>
<xs:element name=”ServiceDefinition” type=”ServiceDefinition”/>
<xs:element name=”ConstraintDefinition” type=”ConstraintDefinition”/>
<xs:element name=”FlowDefinition” type=”FlowDefinition”/>
<xs:element name=”Manager” type=”Manager”/>
</xs:choice>
</xs:sequence>
<xs:attributeGroup ref=”NamespaceIdentity”/>
<xs:attribute name=”documentLanguage” type=”Culture”/>
</xs:complexType>
</xs:element>

３．１１．１ 情報
ＳＤＭ文書の情報セクションは、ＳＤＭ文書の識別および管理をサポートするための、人間に読める情報を含む。

３．１２ 変更要求
図１５に、変更要求の例を示す。変更要求は、ＳＤＭランタイムに対する変更のセットを識別する。ランタイムに対するすべての変更は、要求の構築を可能にするＡＰＩによる、またはＸＭＬフォーマットの、変更要求を使用して開始される。

初期の要求は、単一のアクショングループを含む。要求がランタイムによって処理されるにつれて、ネストされるグループ化によってより多くの構造が追加され、展開およびフロープロセスの結果、より多くのアクションが追加される。この評価プロセスを経て、今やターゲットマシンに対して実行される準備のできた変更要求を、完全修飾変更要求と呼ぶ。これ以上の情報については３．１３章を参照されたい。

３．１２．１ 一貫性規則
ＳＤＭインスタンス空間に対してアクションを実施する際は、アクション完了後にもＳＤＭインスタンス空間中のすべてのインスタンスが一貫した状態であることを妥当性検査する。一貫した状態とは、インスタンスに適用されるすべての制約が依然として有効であることを意味する。例えば、サーバへの接続を必要とするクライアントのインスタンスを生成する場合、クライアントを生成して接続するのに使用されるアクションのシーケンスが完了したときにも、クライアントとサーバとの間に接続が存在すべきである。

モデル一貫性を評価するのに使用される制約は、アクションベースで、またはアクションのセットの終わりに評価することができる。この２つの型の一貫性を、動作一貫性およびトランザクション一貫性と呼ぶ。

トランザクション完了後にオブジェクトの一貫性がなくなる場合、ユーザはこのインスタンスを明示的にオフラインとしてマークすることができる。インスタンスがオフラインのときは、インスタンスに適用される制約は評価されず、他のインスタンスからはこのインスタンスが存在するようには見えない。このことは、これらのインスタンスもまたすべてオフラインとしてマークすべきであることを意味する場合がある。オフラインは、親から子へ、ホストからゲストへ伝搬される。したがって、システムをオフラインとしてマークすることは、システムによって所有されるすべてのインスタンスをオフラインとしてマークし、システム上でホストされるすべてのインスタンスをオフラインとしてマークすることになる。

３．１３ モデル評価
この章では、ＳＤＭランタイムの範囲内におけるＳＤＭモデルの挙動について述べる。

３．１３．１ 定義空間
定義空間は、ＳＤＭランタイムに知られているすべての定義を含む。図１６の各ステップに、新しい定義をランタイム内にロードする例示的なプロセスを規定する。このプロセスはまた、設計表面がＳＤＭ文書を妥当性検査するときに行われるコンパイルプロセスでも共有される。

３．１３．１．１ ロード
ＳＤＭ文書は、ＳＤＵの一部として、またはスタンドアロン文書としてランタイムに提示される。ファイルをディスクからロードすることが試みられる。

３．１３．１．２ スキーマ妥当性検査
第１のステップでは、ＳＤＭ文書がＳＤＭスキーマとマッチすることを妥当性検査する。この時点で、すべての未知要素、必要要素の不足している型、無効なデータを含む属性または型については、エラーを返す。

３．１３．１．３ 設定値および型解決
型解決フェーズでは、ＳＤＭファイル内の型への参照をすべて解決する（スキーマ中で修飾名が使用されている位置ならどこでも）。まず、文書の範囲内にあるすべての型参照が有効であることを妥当性検査する。これらはすべて、エイリアスを含まない型参照である。次いで、すべてのインポートステートメントを解決することを試みる。インポートステートメントを解決することができない場合は、名前空間ロードエラーを生成し、インポートステートメントを解決することができる場合は、名前空間内で型を突き止めることを試みる。ＳＤＭファイルから名前空間をロードしなければならない場合、名前空間解決プロセスは他のエラーを生じる場合がある。

３．１３．１．４ パス解決
パス解決フェーズの間、文書中で定義されたメンバおよび設定へのパスをすべて解決することを試みる。未解決の型を有するメンバまたは設定を参照するパスはエラーを生じない。

３．１３．１．５ 関係への参与
型空間で、型宣言がそのメンバの関係参与に関してどんな制約にも違反しないことをチェックする。これを行うために、関連する設定制約を有さないすべての型および関係制約を評価する。

３．１３．１．６ インスタンスシミュレーション
インスタンスシミュレーションでは、失敗するとわかっている制約は識別し、ユーザ入力に基づいて失敗する場合としない場合がある制約にはフラグを立てないようにすることができるような方式で、値をフローして制約を評価することを試みる。こうするためには、インスタンス空間のモデルを構築し、このインスタンス空間に基づくフローおよび制約を評価する。フローまたは制約がエラーになることがわかっている場合はエラーを発し、エラーになる可能性がある場合は警告を発する。

すべてのｂｙＲｅｆｅｒｅｍｃｅシステム上のｍｉｎＯｃｃｕｒｓ制約を使用して、インスタンス空間変更要求を構築する。ｍｉｎＯｃｃｕｒｓが０のときは、単一のインスタンスを生成し、オプションとしてマークする。次いで、標準の変更要求に使用したのと同じ展開プロセスおよびフロープロセスを通して変更要求を渡す。

次いで、完全に定義された入力値を有するすべてのフローを評価する。入力値が固定でなく、ユーザによって変更できる場合は、このフローの出力を仮としてマークする。仮入力は、それを消費するどんなフロー演算によっても連鎖することになる。フローが完全な入力値を有さず、ユーザが値を提供できる場合は、このフローのすべての出力を未定義としてマークする。オプションのシステムからのフローもまた、仮の値を生じる。

値をフローした後は、これらの値に基づいて制約を評価する。値を供給できなかった制約には警告を発する。また、未定義の値であるために制約が評価できなかったときにも警告を発する。

３．１３．２ インスタンス空間
モデル評価プロセスは、宣言変更要求をサブミットすることによって開始する。この要求は、ランタイム内のインスタンスをターゲットとした生成、更新、または削除操作のセットを含む。次いで、図１７に示すように、要求を一連のパイプラインステージに通した後、必要な変更をターゲットシステムに対して実施する。

以下の各章で、各展開（expansion）ステップの役割を概説する。

３．１３．２．１ 要求のサブミット
システムに対する変更を開始するために、オペレータまたはプロセスは、変更要求をサブミットすべきである。変更要求は、オペレータがランタイム内のインスタンスに対して実施したいと思うアクションのセットを含む。これらのアクションは、３つのグループ、すなわち生成アクション、更新アクション、削除アクションに分類される。

次いで要求は、グループとして完了または失敗すべき原子アクションセットとして扱われる。これにより、制約妥当性検査プロセスは、アクションセットがモデルに対する有効な変更をもたらすかどうかを評価するときに、要求中のすべてのアクションを考慮することができる。

３．１３．２．１．１ 型解決
型解決フェーズでは、変更要求中で参照されるすべての型およびメンバを解決する。変更要求は、これらがすでにランタイムによってロードされていると見なす。これらが存在しない場合は、ランタイムはロード／コンパイルアクションを開始する必要がある。

３．１３．２．１．２ パス解決
パス解決フェーズの間に、変更要求内の、既存のインスタンスおよび生成アクションによって定義されたインスタンスへの参照を解決する。

３．１３．２．２ 展開（Expansion）
展開は、変更要求について、要求を実行するのに必要な残りのすべてのアクションをポピュレートするプロセスである。一般にこれらのアクションは、型インスタンスおよび関係インスタンスに対する構築アクションおよび破壊アクションである。理論的には、オペレータは、インスタンスを構築または破壊するのに必要なすべてのアクションに関する詳細を提供することができるが、これは変更要求オーサリングプロセスを非常に複雑にするので、必要とされない。そうではなく、このプロセスをできるだけ自動化することが試みられる。オペレータは、ｂｙＲｅｒｅｆｅｎｃｅメンバに対するアクションを識別することにより、オペレータが望む変更に関するキー情報を提供する。すると、ネストされたｂｙＲｅｆｅｒｅｎｃｅおよびｂｙＶａｌｕｅメンバと関係に対して、アクションの残りが埋められる。

３．１３．２．２．１ 値メンバ
展開ステージの間、すべての非参照型メンバを識別する。これらのメンバのカーディナリティはわかっており、必要なすべてのパラメータはわかっている。したがって、各メンバごとに、親の生成中であるメンバについては生成要求を変更要求に追加する。変更要求が破壊動作を含む場合は、それらに含まれるすべてのインスタンスについて破壊動作を追加する。

３．１３．２．２．２ 参照メンバの展開（発見）
一般に、参照メンバを構築するには、値メンバよりも多くの情報が必要である。これらのカーディナリティはしばしば未定義であり、インスタンスが構築されるための値を必要とする展開時設定を有する可能性がある。したがって、ｂｙＲｅｆｅｒｅｎｃｅメンバを展開するプロセスは、インスタンスに関する情報として、ランタイムが提供できるよりも多くの情報を必要とする可能性がある。この情報を得るためのプロセスを、発見と呼ぶ。

発見のプロセスは、構築または更新アクションの一部として参照型メンバをポピュレートする。発見をサポートするオブジェクトマネージャを有する参照メンバだけが、このプロセスに参与する。

新しいインスタンスが発見されたときは、まず、インスタンス特有のキー値を使用して、このインスタンスがまだＳＤＭデータベース中に存在しないことをチェックする。新しいインスタンスであることがわかれば、次いで、発見中のメンバの型に従ってインスタンスを分類する。インスタンスがメンバにマッチしない場合、または曖昧なマッチがある場合は、メンバ参照は空白のままにし、インスタンスはオフラインおよび不完全としてマークする。

３．１３．２．２．３ 関係の展開
構築されることになる型インスタンスがすべてわかった後で、型インスタンスを１つにバインドする関係インスタンスを生成する。型インスタンスの破壊中である場合は、型インスタンスを参照するすべての関係インスタンスを削除する。

関係を生成するには、メンバ空間に目を向けて、インスタンス間に存在すべき関係の構成を識別する。型メンバが１よりも大きいカーディナリティを有する場合は、関係のトポロジを推論しなければならない。これをどうやって行うかについては、ＸＸ章で詳細に論じる。

３．１３．２．３ フロー
フローステージの間、すべての関係インスタンスにわたってフローを評価する。このステージでは、改変されたパラメータフローの影響を受けたインスタンスについて、変更要求に更新要求を追加することができる。

フローは、変更要求の結果として設定が更新されたインスタンスのセットを判定することによって評価する。これらのそれぞれにつき、修正された設定に依存する送出設定フローがあればそれを評価し、変更されたインスタンスのセットにターゲットノードを追加する。このプロセスは、セットが空になるまで、またはセットが循環を含むまで継続する。

３．１３．２．４ 重複検出
重複検出のプロセスでは、展開されたインスタンスを、ＳＤＭデータ記憶域中にすでに存在するインスタンスと照合する。例えば、別のアプリケーションが共有ファイルをインストールしたかどうかを検出する。インスタンスがすでに存在することが検出されたときは、既存のインスタンスのバージョンに応じて、以下のようないくつかのアクションの１つを実施することができる。
ａ）インストールを失敗にする。
ｂ）インスタンスを参照カウントする。
ｃ）インスタンスをアップグレードする。
ｄ）インストールを並行して実施する。

３．１３．２．５ 制約評価
制約評価フェーズの間には、変更要求が処理された後でもモデル中のすべての制約がまだ有効となるかどうかをチェックする。

３．１３．２．６ 要求の順序付け
この時点では完全なアクションリストがあるので、システム間の関係を使用して、有効な変更順序付けを決定することができる。

３．１３．２．７ 実行
マシン特有の順序付けされたアクションセットのサブセットを配信する。これらのマシン特有セットのマシン間同期をサポートすべきである。

３．１３．２．８ 要求返却
変更は、影響を受けるホスティング関係に基づいて変更要求を配信可能部分に分解することによって行う。すべての部分が完了（または失敗）すると、ランタイム内で結果を照合し、概要をユーザに返す。

３．１３．３ 展開の詳細
この章では、型および関係に関する展開（expansion）プロセスについて詳細に検討する。

３．１３．３．１ 参照メンバの展開（発見）
ホスティング関係が、ある型の新しいインスタンスを構築することを担うのと同様にして、ホスティング関係は、既存の型インスタンスの発見を行うのにも使用される。ある型のインスタンスがホスト上で表される方式はホスティング関係だけが意識しているので、これを行うために、ホスティング関係を独特に配置する。

参照メンバに発見のマークが付されているとき、ホスティング関係が発見をサポートするかどうかをチェックする。サポートする場合は、その関係にホストインスタンスを渡し、関係がホスト上で見つけたゲストインスタンスに対する構築アクションを返すよう関係に要求する。

検証を使用して、インスタンスがもう存在しないことを発見する。この場合もまたホスティング関係を使用して、ホスト上のゲストの存在を検証する。ゲストがもう存在しない場合、ホスティング関係は、破壊アクションを変更要求に追加する。

３．１３．３．２ 非参照メンバの展開
ランタイムは、変更要求内の構築または破壊アクションについてすでに識別された型の各非参照メンバに対して構築または破壊アクションを単に追加することにより、すべての非参照メンバ展開を処理する。

３．１３．３．３ 通信関係の展開
２つの型メンバ間に通信関係メンバが存在する場合にオペレータが通信関係のインスタンスを指定していない場合は、完全に接続されたメッシュがメンバ間にあると仮定することにより、通信関係を展開する。

これは何を意味しているだろうか。２つのメンバがメンバ空間で接続されている場合、各メンバのすべてのインスタンスは相互に見えていなければならない。図１８に示すように、以下の２つのメンバがある場合、インスタンス空間トポロジはメンバのカーディナリティによって制約される。１８００に、例示的な２つのメンバを示す。１８０２に、最大の２つのインスタンス間の単純なポイントツーポイント関係を示す。１８０４に、接続のファンアウト（fun out）を示す。一例は、サーバのセット全体にわたって要求の負荷バランスをとることのできるクライアントであろう。１８０６に、接続のファンイン（fan in）を示す。一例は、単一のサーバを共有するクライアントグループであろう。１８０８に、これらの場合の組合せを示す。１８０８では、クライアントのセットがサーバのセットを共有している。

通信リンクを構築するとき、委任エンドポイントが削除されたとしても存在するであろうすべての通信関係とマッチする接続になるように、委任エンドポイントはトランスペアレントになる。図１９に、２つの構造１９０２および１９０４を示す。これらは、インスタンスＡ、Ｂ、Ｃ間の接続に関する限り等価である。

３．１３．３．４ ホスティング関係の展開
ホスティング関係が曖昧な場合、オペレータまたはホスティング関係のマネージャが正しいトポロジを判定することが必要である。

ホスティング関係が展開をサポートする場合は、ホストとゲストのセットを関係マネージャに渡し、正しい構築アクションを返すようマネージャに要求する。マネージャが展開をサポートしない場合は、オペレータがより多くの情報を提供することができるように、オペレータに変更要求を返す。

３．１３．３．５ 参照関係の展開
３．１３．３．６ 包含関係の展開
包含関係が曖昧であることはないので、ランタイムは常に適切な構築アクションを変更要求に追加することができる。

３．１３．３．７ 委任関係の展開
展開では、委任関係は通信関係と同じ規則に従う。

３．１３．４ フロー
３．１３．５ 実行

３．１４ ＳＤＭインスタンス空間
以下の章では、ＳＤＭランタイムのインスタンス空間に関するオブジェクトモデルを定義する。インスタンス空間を使用して、ＳＤＭによってモデル化されるシステムの構成に対する変更を追跡する。

図２０に、インスタンス空間の概観を提供する例示的なＵＭＬ図を示す。ボックス２００２、２００４、２００６、２００８は、この文書の他の章で定義した型を示す。

インスタンス空間は、変更要求によって開始されるバージョニングされた変更をとりまいて構築される。各インスタンスは、実行中のインスタンスに加えられた原子的な変更を表す線形に連続するバージョンを有することができる。将来のバージョンが、実行中のシステムに伝わる前にランタイム内に存在することもできる。

ＳＤＭモデルのこのバージョンでは、所与のインスタンスに対して線形変更だけが可能である。将来は、バージョン分岐が可能になり、バージョン解決モデルが導入されるであろう。これにより、特定のインスタンスに対して複数の変更を未解決とすることが可能になる。

線形バージョニングが可能なので、前の変更の上に形成される一連の変更要求をロードすることができる。これは、ローリングアップグレードなどのプロセス中に実施される場合のある一連のアクションの事前妥当性検査をサポートする。

３．１４．１ ＳＤＭインスタンス
すべてのインスタンスは、ＳＤＭインスタンスから派生する。これらは、設定スキーマに関する値を定義する要素と、インスタンスの定義上のメンバとマッチするメンバのリストを定義する要素とを共有する。これらはまた、インスタンスの固有の識別子と、インスタンスのバージョン番号と、インスタンスの名前と、このバージョンがシステムの実行状態を表すかどうかを示すフラグとを定義する属性のセットも共有する。

３．１４．２ メンバ
ｍｅｍｂｅｒは、インスタンスのメンバを、参照されるインスタンスのセットに関連付けるのに使用する。インスタンスのメンバは、インスタンスの定義によって定義される。参照されるインスタンスは、メンバに対して生成されたインスタンス、またはメンバが委任されるインスタンスである。メンバはアレイを表すことができ、その場合は複数の被参照インスタンスがあるものとすることができる。

３．１４．３ 変更
ｃｈａｎｇｅは、インスタンス状態に対する変更を表す。これは、変更要求を、影響を受けるインスタンスのセットに関連付ける。また、変更のステータス（ＸＸＸ章参照）、および変更が実行された場合の変更応答も識別する。

３．１４．３．１ 変更ステータス
変更要求は、以下の状態の１つまたは複数をとることができる。
・ｎｏｔＳｔａｒｔｅｄ−変更要求に対して実行が試みられていないことを示す。
・ｉｎＰｒｏｇｒｅｓｓ−現在実行されていることを示す。
・ｃｏｍｐｌｅｔｅ−変更要求がうまく完了したことを示す。
・ｆａｉｌｅｄ−変更要求が失敗し、変更が未完了の状態であることを示す。
・ｒｏｌｌｅｄＢａｃｋ−失敗した変更要求がうまくロールバックされたことを示す。

３．１４．４ 具象オブジェクトインスタンス
具象オブジェクトインスタンスは、型属性によって識別される具象型のインスタンスを表す。インスタンスには実世界表現がある可能性があるので、インスタンスがその実世界の相対物と同期しているかどうか追跡する必要がある。また、この変更の結果としてインスタンスがオンラインになるかどうかを知ることも望まれる。オンラインのインスタンスは、そのすべての制約に関して有効であるべきである。オフラインのインスタンスは、それが参与している通信関係の他の参与者には見えない。インスタンスが不完全な場合は、インスタンスをオンラインにできるようになる前に、さらに変更要求が必要である。
<xs:complexType name=”ObjectInstance”>
<xs:complexContent>
<xs:extension base=”sdmInstance”>
<xs:attribute name=”inSync” type=”xs:boolean” use=”required”/>
<xs:attribute name=”online” type=”xs:boolean” use=”required”/>
<xs:attribute name=”type” type=”qualifiedName” use=”required”/>
</xs:extension>
</xs:complexContent>
</xs:complexType>

３．１４．５ 関係インスタンス
ｒｅｌａｔｉｏｎｓｈｉｐ ｉｎｓｔａｎｃｅは、識別された関係型のインスタンスを表す。関係には直接的な実世界表現がないので、関係が同期しているまたはオンラインであるかどうかに関する情報を保持している必要がある。また関係は、それらの制約を満たせない可能性もあるが、相対的に単純なので、不完全であることは予想されない。

３．１４．５．１ ｃｏｎｔａｉｎｍｅｎｔ ｉｎｓｔａｎｃｅ
これは包含関係のインスタンスを表す。

３．１４．５．２ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｉｎｓｔａｎｃｅ
これは通信関係のインスタンスを表す。

３．１４．５．３ ｄｅｌｅｇａｔｉｏｎ ｉｎｓｔａｎｃｅ
これは委任関係のインスタンスを表す。

３．１４．５．４ ｈｏｓｔｉｎｇ ｉｎｓｔａｎｃｅ
これはホスティング関係のインスタンスを表す。

３．１４．５．５ ｒｅｆｅｒｅｎｃｅ ｉｎｓｔａｎｃｅ
これは参照関係のインスタンスを表す。

３．１４．６ インスタンス
ｉｎｓｔａｎｃｅｓグループは、ＳＤＭインスタンスファイル中に存在することのできるインスタンス要素のセットを表す。
<xs:group name=”instances”>
<xs:choice minOccurs=”0” maxOccurs=”unbounded”>
<xs:element name=”SystemInstance” type=”concreteTypeInstance”/>
<xs:element name=”portInstance” type=”concreteTypeInstance”/>
<xs:element name=”resourceInstance” type=”concreteTypeInstance”/>
<xs:element name=”member” type=”member”/>
<xs:element name=”containmentInstance” type=”containmentInstance”/>
<xs:element name=”communicationInstance” type=”communicationInstance”/>
<xs:element name=”hostingInstance” type=”hostingInstance”/>
<xs:element name=”delegationInstance” type=”delegationInstance”/>
<xs:element name=”referenceInstance” type=”referenceInstance”/>
<xs:element name=”placementInstance” type=”placementInstance”/>
</xs:choice>
</xs:group>

３．１４．７ インスタンス参照
３．１４．７．１ ｉｎｓｔａｎｃｅ Ｒｅｆ
ｉｎｓｔａｎｃｅ Ｒｅｆは、インスタンスへの単純な参照である。参照が変更要求のコンテキストでなされ、インスタンスが変更要求の影響を受けるのでない限り、デフォルトではｉｓＣｕｒｒｅｎｔインスタンスになる。

３．１４．７．２ ｉｎｓｔａｎｃｅ Ｖｅｒｓｉｏｎ Ｒｅｆ
ｉｎｓｔａｎｃｅ Ｖｅｒｓｉｏｎ Ｒｅｆは、インスタンスの特定のバージョンを識別する。

３．１５ 展開（deployment）ユニットの構造
要件
・ＳＤＭ型のセットをインストールするのに必要なすべてのビットを含む。
・署名およびバージョニングができる。
・容易に構築／パッケージ／出荷できる。
・参照または包含によって他のＳＤＵを参照することができる。
・ＳＤＭ型定義の展開セクションがＳＤＵ中のファイルを直接参照する。

３．１６ ローカライゼーション
ＳＤＭモデルのどの部分がローカライゼーションをサポートし、システムの設計および展開を通してどのようにローカライゼーションがサポートされるかを決定する必要がある。

第１の手法：
ローカライゼーションは、個々の型および管理すべき型に完全に任される。ローカライゼーションは、制約を介して暗黙的である。ローカライゼーションは第１タイプ市民（first type citizen）ではない。これは以下のことを意味する。
ａ）ＳＤＵは、特定バージョンの型の実装を含むことができる。すなわち、特定バージョンの実装が１つある。このことは、違いがローカライゼーションのみに基づく実装はあり得ないことを意味する。したがって、各実装は一定範囲のロケールをサポートすべきであり、あるいは実装は異なる型とすべきである（この目的でバージョニングを使用するのは良くないことである！）。
ｂ）次いで、リソースをｍｉｘｉｎとして使用して特定バージョンをサポートすることによって、あるいは、異なるバージョンをサポートする実装を識別する型のセットを使用することによって、ローカライゼーションを達成する。
ｃ）クライアントは、ローカライズされたバージョンのサーバを区別／要求することはできない。

第２の手法：
ローカライゼーションは、名前およびバージョンに沿った識別の第１タイプ市民である。このことは、型への参照が行われる位置ではどこでもローカライゼーションを考慮すべきであることを意味する。
ａ）クライアントはこの場合、包含関係、ホスティング関係、通信関係のいずれでも、ローカライズされたバージョンのサーバを区別することができる。
ｂ）展開エンジンは、ローカライゼーションを意識すべきであり、ローカライズされたバージョンの型間でオペレータが選択できるようにすべきである。
ｃ）ＳＤＵは名前、バージョン、およびロケールで識別される。あるいはＳＤＵは、違いが場所のみに基づく複数の実装を含むことができる。（第１の場合は、ローカライズされないコードを別個のＳＤＵ中に配置すべきなので、よりきめ細かいＳＤＵのパッケージングを意味する。第２の場合は、同じ名前で複数のＳＤＵを有することができることを意味する。）

第２の手法は、ロケールが制約として広く使用された場合、設計／ＵＩから見て非常に複雑になる可能性がある。例えば、エンドポイントがローカライズされた場合、またはホストがそれらのゲストをローカライズした場合、接続／配置を見つけるのはずっと複雑になる。第２の手法を、提案した機構として第１の手法のｂ）と共に使用した場合、複雑さはより扱いやすいかもしれないが、ローカライズされたリソースを誰かが識別し、パッケージし、発送しなければならない。

３．１７ バージョニングおよび変更管理
３．１７．１ 一般的なコメント
・システムをその場でバージョニングできることが望ましい。すなわち、インスタンス識別を変更せずにＱＦＥをＳＱＬに適用できることが望ましい。これは、インスタンスの型を変更することを意味する。
・バージョニングポリシーが、許容されるバージョン変更を制御できるようにすることが望ましい。例えば、システム型の設計者が、システムのメンバに対するバージョニングポリシーがどのくらい厳しいかを選択することができ、あるいはオペレータが、セキュリティ上の理由から一方的にメンバのバージョンをアップグレードすることができる。
・バージョニング変更の伝搬を制限することが望ましい。例えば、メンバの型を変更した場合に、システムの型を変更しなければならず、したがって型変更をルートに伝搬しなければならないのは望ましくない。
・途切れのある変更は、バージョン番号の最初の２つの部分の変化によって示され、途切れのない変更は、バージョン番号の第２の２つの部分の変化によって示される。

この文書を誰かに配布する場合は、ＮＤＡの下であっても、仕様書ＥＵＬＡをこの文書の最初に付加しなければならない。情報については<http://dealpoint/Info/Feedback/TDA.asp>を参照されたい。このＥＵＬＡなしで配布された文書は、当社にとって重大な法的リスクである。
この仕様書をＮＤＡの下で、かつ適切な同意の下で配布してもよいか？
この仕様書を一般に配布してもよいか？

４．テンプレート指示
４．１ フィーチャプロセス情報
目的は、Ｗｉｎｄｏｗｓ（登録商標）のすべてのフィーチャが同じ仕様書テンプレートを使用するようにすることである。あなたのフィーチャの分野によっては、いくつかのセクションは該当しない場合があることを理解されたい。

このテンプレートがあなたの必要性を満たさない場合、またはエラーを有する場合は、ｍａｉｌｔｏ：ｊｏｈｎｇｒａｙにコンタクトのこと。また、新しいＰＭおよびＤｅｖがテンプレートを記入するのに役立つベストプラクティス情報があれば、ｍａｉｌｔｏ：ｊｏｈｎｇｒａｙに提案を送信されたい。

フィーチャレビューに向けて予定どおりになるようにするために、カバーページ（コンタクトなど）、セクション１ 序文、セクション３．１ 依存、セクション６ スケジュール／スタッフ配置を記入する必要がある。最初はこれらのセクションを完全に完成させることができない場合があることは理解される。今わかっているところまで完成させるよう最大限に努力し、進むにつれて更新されたい。意図するところは、チームが可能性ある対話に備えることができるように、あなたのフィーチャの主要なインパクトを概説することである。

フィーチャレビューに備えるためには、この仕様書テンプレートの８０％を記入し、各セクションに何かがあるようにすべきである（たとえＮ／ＡやＴＢＤでも）。

４．２ テンプレートへの記入の仕方
新規ファイルを選択し、このテンプレートを文書として開く。あなたの仕様書の本体には、書式ツールバー上のスタイルコントロールから、見出し１〜５、本文テキスト、ブロック引用、リスト黒丸、リスト数字などのスタイルを使用する。

文書プロパティ中の文書タイトルの下にフィーチャ名を必ず記入すること。

４．２．１ 内容
各セクションには、何を書くべきか理解するのに役立つ基本的な指示がリストされている。すべての指示は青色でリストされている。

「書式マーク」の下のツール／オプション／表示タブで、「隠す」のチェックをオンまたはオフにすれば、このテキストを表示したり隠したりすることができる。また、ツールバー上の「段落」テキスト表示ボタン、または最終ページの「表示／隠す」指示ボタンを使用しても表示することができる（マクロをオンにする必要がある）。

４．２．２ 黒丸および数字リストの作り方
・このような黒丸リストを作成するには、１つまたは複数の段落を選択し、書式ツールバー上のスタイルドロップダウンリストからリスト黒丸スタイルを選択する。上の数字付き段落のような数字リストを作成するには、１つまたは複数の段落を選択し、スタイルドロップダウンリストからリスト番号スタイルを選択する。

４．２．３ 問題ブロックの作り方
あなたの仕様書の行の中で、問題を強調して言いたい場合があるかもしれない。問題ブロックを使用して、それらに注意を向けさせることができる。問題ブロックの見出しにしたいテキストと、問題ブロックに含めたいテキストの段落を書く。次に、見出しテキストをハイライトさせ、スタイルドロップダウンリストから問題ブロック見出しを選択する。次に、問題ブロックに含めたいテキストの段落をハイライトさせ、ドロップダウンリストから問題ブロックスタイルを選択する。

４．３ 目次の更新の仕方
この仕様書の目次を更新するには、ＴＯＣページにカーソルを合わせ、右クリックして更新フィールドを選択する。ページ番号だけの更新か、目次全体の更新かを選択することができる。

４．４ 仕様書テンプレートの改訂
これは仕様書テンプレート自体の改訂履歴を文書化する。このセクションは個々の仕様書から削除すべきである。

例示的なコンピュータ環境
図２１に、本明細書に述べた技法を実施するのに使用できる一般的なコンピュータ環境６００の例を示す。コンピュータ環境６００は、コンピューティング環境の一例にすぎず、コンピュータおよびネットワークアーキテクチャの使用または機能の範囲に関してどんな制限も意味するものではない。またコンピュータ環境６００は、この例示的なコンピュータ環境６００に示すコンポーネントのいずれか１つまたは組合せに関してどんな依存も要件も有するものと解釈すべきではない。

コンピュータ環境６００は、コンピュータ６０２の形の汎用コンピューティングデバイスを含む。コンピュータ６０２は、例えば図１のコンピューティングデバイス１０２とすることもでき、図２の開発システム２０２を実装することもでき、図２のコントローラ２０６とすることもでき、図２のターゲットデバイス２１２とすることもでき、図５のコントローラ５２０またはターゲット５２２とすることもできる。コンピュータ６０２のコンポーネントには、限定しないが、１つまたは複数のプロセッサまたは処理ユニット６０４と、システムメモリ６０６と、プロセッサ６０４を含めた様々なシステムコンポーネントをシステムメモリ６０６に結合するシステムバス６０８とを含めることができる。

システムバス６０８は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、ＡＧＰ（ａｃｃｅｌｅｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｏｒｔ）、プロセッサバスまたはローカルバスを含めて、いくつかのタイプのバス構造の任意の１つまたは複数を表す。例えばこのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスを含めることができる。

コンピュータ６０２は通常、様々なコンピュータ可読媒体を備える。このような媒体は、コンピュータ６０２からアクセス可能な任意の利用可能な媒体とすることができ、揮発性と不揮発性、リムーバブルとノンリムーバブルの両方の媒体が含まれる。

システムメモリ６０６は、ランダムアクセスメモリ（ＲＡＭ）６１０などの揮発性メモリ、および／または、読出し専用メモリ（ＲＯＭ）６１２などの不揮発性メモリの形のコンピュータ可読媒体を含む。ＲＯＭ６１２には、起動中などにコンピュータ６０２内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）６１４が記憶されている。ＲＡＭ６１０は通常、プロセッサ６０４からすぐにアクセス可能な、かつ／またはプロセッサ６０４が現在作用している、データおよび／またはプログラムモジュールを含む。

コンピュータ６０２は、その他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば図２１には、ノンリムーバブルかつ不揮発性の磁気媒体（図示せず）に対して読み書きするためのハードディスクドライブ６１６と、リムーバブルかつ不揮発性の磁気ディスク６２０（例えば「フロッピー（登録商標）ディスク」）に対して読み書きするための磁気ディスクドライブ６１８と、ＣＤ（compact disc）−ＲＯＭやＤＶＤ（Digital Versatile Disc）−ＲＯＭやその他の光媒体などリムーバブルかつ不揮発性の光ディスク６２４に対して読み書きするための光ディスクドライブ６２２を示す。ハードディスクドライブ６１６、磁気ディスクドライブ６１８、および光ディスクドライブ６２２はそれぞれ、１つまたは複数のデータ媒体インタフェース６２６によってシステムバス６０８に接続される。あるいは、ハードディスクドライブ６１６、磁気ディスクドライブ６１８、および光ディスクドライブ６２２は、１つまたは複数のインタフェース（図示せず）によってシステムバス６０８に接続されてもよい。

各ディスクドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性記憶域をコンピュータ６０２に提供する。この例では、ハードディスク６１６、リムーバブルな磁気ディスク６２０、およびリムーバブルな光ディスク６２４が示してあるが、磁気カセットまたは他の磁気記憶デバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、ＤＶＤまたは他の光記憶装置、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、ＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）など、コンピュータからアクセス可能なデータを記憶することのできる他のタイプのコンピュータ可読媒体も、この例示的なコンピューティングシステムおよび環境を実現するのに利用できることを理解されたい。

ハードディスク６１６、磁気ディスク６２０、光ディスク６２４、ＲＯＭ６１２、および／またはＲＡＭ６１０には、任意の数のプログラムモジュールを記憶することができる。例えばこれらには、オペレーティングシステム６２６、１つまたは複数のアプリケーションプログラム６２８、その他のプログラムモジュール６３０、およびプログラムデータ６３２が含まれる。このようなオペレーティングシステム６２６、１つまたは複数のアプリケーションプログラム６２８、その他のプログラムモジュール６３０、およびプログラムデータ６３２（またはこれらの何らかの組合せ）はそれぞれ、分散ファイルシステムをサポートする常駐コンポーネントの全部または一部を実装することができる。

ユーザは、キーボード６３４やポインティングデバイス６３６（例えば「マウス」）などの入力デバイスを介して、コンピュータ６０２にコマンドおよび情報を入力することができる。その他の入力デバイス６３８（具体的には図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星受信アンテナ、シリアルポート、スキャナ、および／またはその他を含めることができる。これらおよび他の入力デバイスは、システムバス６０８に結合された入出力インタフェース６４０を介してプロセッサ６０４に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、その他のインタフェースおよびバス構造で接続されてもよい。

モニタ６４２または他のタイプの表示デバイスも、ビデオアダプタ６４４などのインタフェースを介してシステムバス６０８に接続することができる。モニタ６４２に加えて、その他の出力周辺デバイスには、スピーカ（図示せず）やプリンタ６４６などのコンポーネントを含めることができ、これらは入出力インタフェース６４０を介してコンピュータ６０２に接続することができる。

コンピュータ６０２は、リモートコンピューティングデバイス６４８など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。例えばリモートコンピューティングデバイス６４８は、パーソナルコンピュータ、携帯コンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、またはその他の一般的なネットワークノードなどとすることができる。リモートコンピューティングデバイス６４８は、コンピュータ６０２に関して本明細書に述べた要素および機能の多くまたはすべてを備えることのできる携帯コンピュータとして示されている。

コンピュータ６０２とリモートコンピュータ６４８との間の論理接続を、ローカルエリアネットワーク（ＬＡＮ）６５０および一般的なワイドエリアネットワーク（ＷＡＮ）６５２として示す。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットでよくみられるものである。

コンピュータ６０２は、ＬＡＮネットワーキング環境で実現されるときは、ネットワークインタフェースまたはアダプタ６５４を介してローカルネットワーク６５０に接続される。ＷＡＮネットワーキング環境で実現されるときは通常、ワイドネットワーク６５２を介した通信を確立するためのモデム６５６または他の手段を備える。モデム６５６は、コンピュータ６０２に内蔵でも外付けでもよく、入出力インタフェース６４０または他の適切な機構を介してシステムバス６０８に接続することができる。図示のネットワーク接続は例示的なものであり、コンピュータ６０２と６４８の間に通信リンクを確立する他の手段を採用することもできることを理解されたい。

コンピューティング環境６００で示すようなネットワーク化された環境では、コンピュータ６０２に関して示すプログラムモジュールまたはその一部を、リモートのメモリ記憶デバイスに記憶することができる。例として、リモートアプリケーションプログラム６５８が、リモートコンピュータ６４８のメモリデバイス上にある。アプリケーションプログラム、およびオペレーティングシステムなどその他の実行可能プログラムコンポーネントは、ここでは説明のために個別のブロックとして示してある。ただし、このようなプログラムおよびコンポーネントは、様々な時点でコンピューティングデバイス６０２の種々の記憶コンポーネント中にあり、コンピュータのデータプロセッサによって実行されることを理解されたい。

本明細書で、様々なモジュールおよび技法は、１つまたは複数のコンピュータまたは他のデバイスによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で述べることができる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。通常、プログラムモジュールの機能は、様々な実施形態で望まれるように結合または分散させることができる。

これらのモジュールおよび技法の実装形態は、何らかの形のコンピュータ可読媒体に記憶するか、コンピュータ可読媒体を介して送信することができる。コンピュータ可読媒体は、コンピュータからアクセスできる任意の利用可能な媒体とすることができる。限定ではなく例として、コンピュータ可読媒体には、「コンピュータ記憶媒体」および「通信媒体」を含めることができる。

「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術で実現された、揮発性および不揮発性、リムーバブルおよびノンリムーバブルな媒体が含まれる。コンピュータ記憶媒体には、限定しないがＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤまたは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイスが含まれ、あるいは、所望の情報を記憶するのに使用できコンピュータからアクセスできる他の任意の媒体が含まれる。

「通信媒体」は通常、搬送波や他のトランスポート機構などの変調データ信号中に、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを組み入れたものである。通信媒体には、任意の情報送達媒体も含まれる。「変調データ信号」という語は、情報が信号中に符号化される形で１つまたは複数の特性が設定または変更された信号を意味する。限定ではなく例として、通信媒体には、配線式ネットワークや直接配線式接続などの配線式媒体と、音響、無線周波、赤外線、その他の無線媒体などの無線媒体とが含まれる。以上の任意の組合せもコンピュータ可読媒体の範囲に含めるべきである。

別法として、このフレームワークの一部をハードウェアで、あるいはハードウェア、ソフトウェア、および／またはファームウェアの組合せで実現することもできる。例えば、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）またはプログラム可能論理デバイス（ＰＬＤ）を、このフレームワークの１つまたは複数の部分を実現するように設計またはプログラムすることができる。

結び
本発明を構造上の特徴および／または方法上の動作に特定の言葉で述べたが、添付の特許請求の範囲に定義する本発明は、述べた具体的な特徴または動作に必ずしも限定されないことを理解されたい。そうではなく、これらの具体的な特徴および動作は、特許請求する本発明を実施する例示的な形として開示するものである。

本発明を適用できる実施形態の例示的なネットワーク設定を示す図である。 本発明を適用できる実施形態のＳＤＭ定義モデルを使用する例示的なアーキテクチャを示すブロック図である。 本発明を適用できる実施形態の例示的なレイヤ化設定を示す図である。 本発明を適用できる実施形態のシステムのライフサイクル全体にわたってシステム定義モデル（ＳＤＭ）を使用するための例示的なプロセスを示すフローチャートである。 本発明を適用できる実施形態のＳＤＭランタイムを使用する例示的なアーキテクチャを示す図である。 本発明を適用できる実施形態の例示的なＳＤＭ文書を示す図である。 本発明を適用できる実施形態の基底定義およびメンバを示す図である。 本発明を適用できる実施形態の例示的なメンバを示す図である。 例本発明を適用できる実施形態の示的な設定値および値リストを示す図である。 本発明を適用できる実施形態のいくつかの実施形態による例示的なＳＤＭアプリケーションのライフサイクルを示す図である。 本発明を適用できる実施形態のウェブアプリケーションをウェブサーバホストにマッピングする例を示す図である。 本発明を適用できる実施形態の例示的な組込みデータ型階層を示す図である。 本発明を適用できる実施形態の抽象オブジェクト定義の暗黙的な拡張の例を示す図である。 本発明を適用できる実施形態の抽象関係の暗黙的な拡張の例を示す図である。 本発明を適用できる実施形態の変更要求の例を示す図である。 新しい定義をランタイム内にロードする例示的なプロセスを示す図である。 本発明を適用できる実施形態の変更要求を実施する例を示す図である。 本発明を適用できる実施形態の接続されたメンバの例を示す図である。 接続に関する例示的な構造を示す図である。 本発明を適用できる実施形態のインスタンス空間の概観を提供する例示的なＵＭＬ図である。 本発明を適用できる実施形態の本明細書に述べる技法を実施するのに使用できる一般的なコンピュータ環境を示す図である。

符号の説明

２００ 例示的なアーキテクチャ
２０２ 開発システム
２０４ ＳＤＭ文書
２０６ コントローラ
２０８ 展開モジュール
２１０ 管理モジュール
２１２ ターゲットデバイス

Claims (47)

1. システム定義モデルを使用してシステムを設計するステップと、
   その後、前記システム定義モデルを使用して、前記システムを１つまたは複数のコンピューティングデバイス上に展開するステップと、
   前記システムの展開後、前記システム定義モデルを使用して、前記１つまたは複数のコンピューティングデバイス上に展開された前記システムを管理するステップと
   を備えることを特徴とする方法。
2. 前記システムはアプリケーションを含む
   ことを特徴とする請求項１に記載の方法。
3. 前記システムは環境を含む
   ことを特徴とする請求項１に記載の方法。
4. 前記システムを管理する間に得られた知識を使用して、前記システムの後続バージョンを設計するステップ
   をさらに備えることを特徴とする請求項１に記載の方法。
5. 前記システム定義モデルは、前記システムをどのように前記１つまたは複数のコンピューティングデバイス上に展開するかを記述した知識を含む
   ことを特徴とする請求項１に記載の方法。
6. 前記システム定義モデルは、前記システムをどのように複数の異なるコンピューティングデバイス上に展開するかを記述した知識を含み、前記知識は、前記システムをどのように前記複数の異なるコンピューティングデバイスのそれぞれに展開するかを記述した異なる知識を含む
   ことを特徴とする請求項１に記載の方法。
7. 前記システム定義モデルは、前記システムが前記１つまたは複数のコンピューティングデバイス上で実行されるために前記１つまたは複数のコンピューティングデバイスが満たさなければならない制約を含む
   ことを特徴とする請求項１に記載の方法。
8. 前記システムの設計中に、前記システム定義モデルを使用して、前記制約が前記１つまたは複数のコンピューティングデバイスによって満たされるかどうかをチェックすることができる
   ことを特徴とする請求項７に記載の方法。
9. 前記システムの設計中および前記システムの管理中に、前記システム定義モデルを使用して、前記制約が前記１つまたは複数のコンピューティングデバイスによって満たされるかどうかをチェックすることができる
   ことを特徴とする請求項７に記載の方法。
10. 前記システム定義モデルは、前記システムの展開後に前記システムをどのように管理するかを記述した知識を含む
    ことを特徴とする請求項１に記載の方法。
11. 前記システムの管理中に、フローを使用して自動的に前記システムに構成変更を伝えるステップ
    をさらに備えることを特徴とする請求項１に記載の方法。
12. 前記システムは前記１つまたは複数のコンピューティングデバイス上の環境に展開され、前記システムの設計、展開、および管理の前に、
    別のシステム定義モデルを使用して前記環境を設計するステップと、
    その後、前記別のシステム定義モデルを使用して、前記環境を前記１つまたは複数のコンピューティングデバイス上に展開するステップと、
    前記環境の展開後、前記別のシステム定義モデルを使用して、前記１つまたは複数のコンピューティングデバイス上に展開された環境を管理するステップと
    をさらに備えることを特徴とする請求項１に記載の方法。
13. 前記環境のための前記システム定義モデルは、１つまたは複数のコンピューティングデバイスの構成を検討することによって得られる
    ことを特徴とする請求項１２に記載の方法。
14. 前記システム定義モデルは、前記システムが前記１つまたは複数のコンピューティングデバイス上で実行されるために前記環境が満たさなければならない制約を含み、前記別のシステム定義モデルは、前記システムが前記１つまたは複数のコンピューティングデバイス上で実行されるために前記システムが満たさなければならない他の制約を含む
    ことを特徴とする請求項１２に記載の方法。
15. 前記１つまたは複数のコンピューティングデバイス上に複数の環境が展開され、
    複数の異なるシステム定義モデルを使用して、前記複数の環境のそれぞれを設計するステップであって、前記複数の環境はそれぞれ前記複数の異なるシステム定義モデルのうちの１つに関連するステップと、
    各環境ごとに、前記複数の異なるシステム定義モデルのうちの前記関連する１つを使用して、前記環境を展開するステップと、
    展開後、各環境ごとに、前記複数の異なるシステム定義モデルのうちの前記関連する１つを使用して、前記環境を管理するステップと
    をさらに備えることを特徴とする請求項１に記載の方法。
16. 前記複数の環境はそれぞれレイヤ化され、前記複数の環境はそれぞれ、前記複数の環境のうちの他の１つに対する環境として、または前記システムに対する環境として働く
    ことを特徴とする請求項１５に記載の方法。
17. スキーマを実装する複数の命令を記憶した１つまたは複数のコンピュータ読み取り可能な記録媒体であって、前記複数の命令は、プロセッサによって実行されたとき、
    システムの設計を容易にするステップと、
    前記システムの展開を容易にするステップと、
    前記システムの管理を容易にするステップと
    を前記プロセッサに行わせる
    ことを特徴とするコンピュータ読み取り可能な記録媒体。
18. 前記システムはアプリケーションを含む
    ことを特徴とする請求項１７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
19. 前記システムは環境を含む
    ことを特徴とする請求項１７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
20. 前記システムの展開を容易にするステップは、前記システムをどのように展開するかを記述した知識をシステム定義モデルに含めることである
    ことを特徴とする請求項１７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
21. 前記システムの展開を容易にするステップは、前記システムをどのように複数の異なる環境に展開するかを記述した知識をシステム定義モデルに含めることであり、前記知識は、前記システムをどのように前記複数の異なる環境のそれぞれに展開するかを記述した異なる知識を含む
    ことを特徴とする請求項１７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
22. 前記システムの設計を容易にするステップは、前記システムが環境で実行されるために前記環境が満たさなければならない制約を、システム定義モデルに含めることである
    ことを特徴とする請求項１７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
23. 前記システムの設計を容易にするステップは、前記システムの設計中に、前記システム定義モデルを使用して、前記制約が前記環境によって満たされるかどうかをチェックすることである
    ことを特徴とする請求項２２に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
24. 前記システムの管理を容易にするステップは、前記システムをどのように管理するかを記述した知識をシステム定義モデルに含めることである
    ことを特徴とする請求項１７に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
25. システムの設計を容易にする手段と、
    前記システムの展開を容易にする手段と、
    前記システムの管理を容易にする手段と
    を備えたスキーマを実装する
    ことを特徴とする装置。
26. 前記システムの展開を容易にする手段は、前記システムをどのように展開するかを記述した知識をシステム定義モデルに含める手段を含む
    ことを特徴とする請求項２５に記載の装置。
27. 前記システムの展開を容易にする手段は、前記システムをどのように複数の異なる環境に展開するかを記述した知識をシステム定義モデルに含める手段を含み、前記知識は、前記システムをどのように前記複数の異なる環境のそれぞれに展開するかを記述した異なる知識を含む
    ことを特徴とする請求項２５に記載の装置。
28. 前記システムの設計を容易にする手段は、前記システムが環境で実行されるために前記環境が満たさなければならない制約を、システム定義モデルに含める手段を含む
    ことを特徴とする請求項２５に記載の装置。
29. 前記システムの設計を容易にする手段は、前記システムの設計中に、前記システム定義モデルを使用して、前記制約が前記環境によって満たされるかどうかをチェックする手段を含む
    ことを特徴とする請求項２８に記載の装置。
30. 前記システムの管理を容易にする手段は、前記システムをどのように管理するかを記述した知識をシステム定義モデルに含める手段を含む
    ことを特徴とする請求項２５に記載の装置。
31. アプリケーションのライフサイクルを通して適用可能なシステム定義モデルを備えるシステムであって、前記アプリケーションの前記ライフサイクルは、前記アプリケーションの設計、前記アプリケーションの展開、および前記アプリケーションの管理を含むシステムと、
    前記システム定義モデル内の機能動作をどのように指定すべきかを指示するためのスキーマと
    を備えたことを特徴とするシステム。
32. 前記システム定義モデルは、前記アプリケーションをどのように展開するかを記述した情報を含む
    ことを特徴とする請求項３１に記載のシステム。
33. 前記システム定義モデルは、前記アプリケーションをどのように複数の異なる環境に展開するかを記述した情報を含み、前記情報は、前記アプリケーションをどのように前記複数の異なる環境のそれぞれに展開するかを記述した異なる情報を含む
    ことを特徴とする請求項３１に記載のシステム。
34. 前記システム定義モデルは、前記アプリケーションが環境で実行されるために前記環境が満たさなければならない制約を含む
    ことを特徴とする請求項３１に記載のシステム。
35. 前記アプリケーションの設計中および前記アプリケーションの管理中に、前記システム定義モデルを使用して、前記制約が前記システム中の１つまたは複数のコンピューティングデバイスによって満たされるかどうかをチェックすることができる
    ことを特徴とする請求項３４に記載のシステム。
36. 前記アプリケーションの設計中に、前記システム定義モデルを使用して、前記制約が前記環境によって満たされるかどうかをチェックすることができる
    ことを特徴とする請求項３４に記載のシステム。
37. 前記システム定義モデルは、前記アプリケーションをどのように管理するかを記述した情報を含む
    ことを特徴とする請求項３１に記載のシステム。
38. 環境のライフサイクルを通して適用可能な別のシステム定義モデルをさらに備え、前記環境の前記ライフサイクルは、前記環境の設計、前記環境の展開、および前記環境の管理を含み、
    前記スキーマはさらに、前記別のシステム定義モデル内の機能動作をどのように指定すべきかを指示するものである
    ことを特徴とする請求項３１に記載のシステム。
39. 前記環境のための前記システム定義モデルは、１つまたは複数のコンピューティングデバイスの構成を検討することによって得られる
    ことを特徴とする請求項３８に記載のシステム。
40. 前記システム定義モデルは、前記アプリケーションが前記環境で実行されるために前記環境が満たさなければならない制約を含み、前記別のシステム定義モデルは、前記アプリケーションが前記環境で実行されるために前記アプリケーションが満たさなければならない他の制約を含む
    ことを特徴とする請求項３８に記載のシステム。
41. 追加の環境のライフサイクルを通して適用可能な追加のシステム定義モデルをさらに備え、前記追加の環境の前記ライフサイクルは、前記追加の環境の設計、前記追加の環境の展開、および前記追加の環境の管理を含み、
    前記追加の環境は、前記環境の下にレイヤ化され、
    前記スキーマはさらに、前記追加のシステム定義モデル内の機能動作をどのように指定すべきかを指示するものである
    ことを特徴とする請求項３８に記載のシステム。
42. システムの設計中に使用され、かつ前記システムの展開中および管理中にシステム定義モデルランタイムと共に使用されるシステム定義モデルのインスタンスを定義するステップ
    を備えることを特徴とする方法。
43. 前記システム定義モデルは、前記システムをどのように展開するかを記述した情報を含む
    ことを特徴とする請求項４２に記載の方法。
44. 前記システム定義モデルは、前記システムをどのように複数の異なるランタイム内に展開するかを記述した情報を含み、前記情報は、前記システムをどのように前記複数の異なるランタイムのそれぞれに展開するかを記述した異なる情報を含む
    ことを特徴とする請求項４２に記載の方法。
45. 前記システム定義モデルは、前記システムが前記ランタイム内で実行されるために前記ランタイムが満たさなければならない制約を含む
    ことを特徴とする請求項４２に記載の方法。
46. 前記システムの設計中に、前記システム定義モデルを使用して、前記制約が前記ランタイムによって満たされるかどうかをチェックすることができる
    ことを特徴とする請求項４５に記載の方法。
47. 前記システム定義モデルは、前記システムをどのように前記ランタイム中で管理するかを記述した情報を含む
    ことを特徴とする請求項４２に記載の方法。
    

Images