(57)【要約】【課題】分散コンピューティングシステムと、分散アプリケーションの自動化された設計、展開、および管理とのためのアーキテクチャを提供する。【解決手段】分散アプリケーションを分散コンピューティングシステム上で設計、展開、および管理するためのアーキテクチャおよび方法は、システム定義モデルを使用してシステムを設計することを含む。その後、システム定義モデルを使用して、システムを１つまたは複数のコンピューティングデバイス上に展開し、システムの展開後、システム定義モデルを使用して、１つまたは複数のコンピューティングデバイス上に展開されたシステムを管理する。【選択図】図２
2011070707.tif 000002
【特許請求の範囲】
【請求項１】
スキーマに基づいて、分散コンピューティング環境内で分散コンピューティングシステムを実装する複数の命令を記憶した１つまたは複数のコンピュータ読み取り可能な記録媒体であって、前記スキーマは、
前記分散コンピューティング環境内で実装される分散コンピューティングシステムモジュールの少なくとも１つの定義であって、第１の定義が、第２の定義から派生する場合に、前記第２の定義から設定制約および関係制約を継承するようにする、継承プロパティを有する少なくとも１つの定義と、
前記分散コンピューティングシステムの前記モジュール間の可能性のある対話を識別する少なくとも１つの関係であって、前記スキーマが、前記定義および関係を修正する開発ツール、および前記定義および関係にしたがって前記モジュールを実装する展開ツールによって使用されるようにする、少なくとも１つの関係と、
前記分散コンピューティング環境を妥当性検査する第１の妥当性検査についての、前記分散コンピューティングシステムによって使用される前記分散コンピューティング環境の少なくとも１つの要件と、
前記分散コンピューティングシステムを妥当性検査する第２の妥当性検査についての、前記分散コンピューティング環境によって使用される前記分散コンピューティングシステムの少なくとも１つの要件と
を備えたことを特徴とする１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項２】
前記スキーマは、前記開発ツールのユーザが、前記少なくとも１つの分散コンピューティングシステムモジュールの所望の操作意図を識別するのを可能にする
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項３】
前記少なくとも１つの定義は、リソース定義、コンポーネント定義、およびエンドポイント定義を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項４】
前記少なくとも１つの定義は、前記分散コンピューティングシステムモジュールの中に含まれるランタイムの挙動を指定するリソース定義を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項５】
前記少なくとも１つの定義は、前記分散コンピューティングシステムの自己完結型かつ独立展開可能な部分を記述するコンポーネント定義を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項６】
前記少なくとも１つの定義は、前記分散コンピューティングシステムモジュールによって開示された通信エンドポイントを記述するエンドポイント定義を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項７】
前記少なくとも１つの関係は、２つまたは複数の分散コンピューティングシステムモジュールのエンドポイント定義間の少なくとも１つの可能性のある通信対話の形態であり、前記関係は、
包含関係、
委任関係、
接続関係、
ホスティング関係、および、
参照関係
の１つまたは複数を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項８】
前記少なくとも１つの関係は、特定の定義が他の定義のメンバを包含できることを記述
する包含関係を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項９】
前記少なくとも１つの関係は、特定の定義に含まれるメンバを開示する委任関係を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項１０】
前記少なくとも１つの関係は、複数の定義間の利用可能な通信対話を識別する接続関係
を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項１１】
前記少なくとも１つの関係は、複数の定義間の従属性を記述するホスティング関係を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項１２】
前記少なくとも１つの関係は、複数の定義間の順序付け関係を識別する参照関係を含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項１３】
分散アプリケーションのためのテンプレートに関連する抽象部分と、分散アプリケーションの特定の実装に関連する具象部分とをさらに含む
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項１４】
複数の関係をさらに含み、前記スキーマは、前記複数の関係にわたって設定の通信を提供する
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項１５】
複数の関係をさらに含み、前記スキーマは、前記複数の関係にわたってアプリケーションランタイムの挙動情報の通信を提供する
ことを特徴とする請求項１に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項１６】
コンピュータによって実行されると設計ツールを実装する複数の命令を記憶した１つまたは複数のコンピュータ読み取り可能な記憶媒体であって、前記設計ツールは、
分散コンピューティング環境および分散コンピューティングシステムの仕様を抽象的に定義することを可能にするシステム定義モデルと、
前記システム定義モデル内の機能動作モジュールをどのように指定すべきかを指示するスキーマとを備え、前記スキーマは、
前記分散コンピューティング環境を妥当性検査する、前記分散コンピューティングシステムによって使用される前記分散コンピューティング環境の少なくとも１つの要件と、
前記分散コンピューティングシステムを妥当性検査する、前記分散コンピューティング環境によって使用される前記分散コンピューティングシステムの少なくとも１つの要件とを備える
ことを特徴とする１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項１７】
前記設計ツールは、分散アプリケーション開発ツール、分散アプリケーション展開ツール、分散アプリケーション管理ツールのうちの１つである
ことを特徴とする請求項１６に記載の１つまたは複数のコンピュータ読み取り可能な記録媒体。
【請求項１８】
分散コンピューティング環境内で分散コンピューティングシステムのエンティティの定義をロードするステップと、
分散コンピューティングシステムの前記エンティティ間の可能性のある対話を指定する関係をロードするステップであって、前記定義および前記関係が、前記分散コンピューティングシステムの開発中、妥当性検査中、展開中、および管理中に使用されるようにし、前記妥当性検査は、
前記分散コンピューティングシステムの１つまたは複数の要件にしたがって、前記分散コンピューティング環境によって使用される前記分散コンピューティングシステムを妥当性検査するステップと、
前記分散コンピューティング環境の１つまたは複数の要件にしたがって、前記分散コンピューティングシステムによって使用される前記分散コンピューティング環境を妥当性検査するステップとを備えるステップと
を備えたことを特徴とする方法。
【請求項１９】
前記定義は、リソース定義、システム定義、およびエンドポイント定義を含む
ことを特徴とする請求項１８に記載の方法。
【請求項２０】
前記関係は、包含関係、委任関係、通信関係、ホスティング関係、および参照関係を含む
ことを特徴とする請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散コンピューティングシステムのためのアーキテクチャに関する。
【背景技術】
【０００２】
インターネットの使用は、過去数年にわたって爆発的に増加しており、引き続き増加中である。人々は、電子メール、オンラインショッピング、ニュースおよび情報の収集、音楽鑑賞、ビデオクリップ視聴、求職など、ワールドワイドウェブ（または単に「ウェブ」）上で提供される多くのサービスによって非常に快適になった。インターネットベースのサービスに対する需要の増加についていくため、ウェブサイトをホストし、これらのサイトのためのバックエンドサービスを提供し、サイトに関連するデータを記憶するための専用のコンピュータシステムは、著しく増加した。
【０００３】
分散コンピュータシステムのタイプの１つは、データセンタ（インターネットデータセンタ（ＩＤＣ）やエンタープライズデータセンタ（ＥＤＣ）など）だが、これは、ネットワークベースのサービスをホストするための多くのコンピュータを収容する特別設計された複合体である。データセンタは「ウェブファーム」または「サーバファーム」という名前で呼ばれることもあるが、通常、温度と湿度が調節された物理的に安全な建物内に、何百台から何千台までものコンピュータを収容する。データセンタは一般に、インターネットアクセス、信頼性のある電力供給、および安全な動作環境を提供する。
【０００４】
今日、大規模なデータセンタは複雑であり、しばしば複数のアプリケーションをホストすることが要求される。例えばウェブサイトの中には、数千台のコンピュータを運用し、多くの分散アプリケーションをホストするものもある。これらの分散アプリケーションは複雑なネットワーキング要件を有する場合が多く、複雑なアプリケーションをサポートするために、オペレータがコンピュータを一定のネットワークスイッチに物理接続すること、ならびにデータセンタ内の配線構成を手作業で構成することが必要である。この結果、アプリケーション要件に適合するように物理ネットワークトポロジを構築するこの作業は、時間のかかる厄介なプロセスになる可能性があり、人為的ミスを被りやすい。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
したがって、分散アプリケーションを物理的なコンピューティングシステム上で設計および展開する（ｄｅｐｌｏｙ）ための、改善された技法が必要とされている。
【０００６】
本発明は、このような状況に鑑みてなされたもので、その目的とするところは、分散アプリケーションを分散コンピューティングシステム上で設計、展開、および管理することが可能な、分散コンピューティングシステムと、分散アプリケーションの自動化された設計、展開、および管理とのためのアーキテクチャを提供することにある。
【課題を解決するための手段】
【０００７】
分散アプリケーションを分散コンピューティングシステム上で設計、展開、および管理するためのアーキテクチャおよび方法について述べる。
【図面の簡単な説明】
【０００８】
【図１】本発明を適用できる実施形態の例示的なネットワーク設定を示す図である。
【図２】本発明を適用できる実施形態のＳＤＭ定義モデルを使用する例示的なアーキテクチャを示すブロック図である。
【図３】本発明を適用できる実施形態のＳＤＭスキーマ設計仕様で定義される例示的な定義構造を示す図である。
【図４】本発明を適用できる実施形態のＳＤＭスキーマ設計仕様で定義される例示的な関係構造を示す図である。
【図５】本発明を適用できる実施形態のウェブアプリケーションをウェブサーバホストにマッピングする例を示す図である。
【図６】本発明を適用できる実施形態のＳＤＭランタイムを使用する例示的なアーキテクチャを示す図である。
【図７】本発明を適用できる実施形態の例示的なレイヤ化設定を示す図である。
【図８】本発明を適用できる実施形態の例示的なＳＤＭ文書を示す図である。
【図９】本発明を適用できる実施形態の基底定義およびメンバを示す図である。
【図１０】本発明を適用できる実施形態の例示的なメンバを示す図である。
【図１１】本発明を適用できる実施形態の例示的な設定値および値リストを示す図である。
【図１２】本発明を適用できる実施形態のいくつかの実施形態による例示的なＳＤＭアプリケーションのライフサイクルを示す図である。
【図１３】本発明を適用できる実施形態のウェブアプリケーションをウェブサーバホストにマッピングする例を示す図である。
【図１４】本発明を適用できる実施形態の例示的な組込みデータ型階層を示す図である。
【図１５】本発明を適用できる実施形態の抽象オブジェクト定義の暗黙的な拡張の例を示す図である。
【図１６】本発明を適用できる実施形態の抽象関係の暗黙的な拡張の例を示す図である。
【図１７】本発明を適用できる実施形態の変更要求の例を示す図である。
【図１８】本発明を適用できる実施形態の新しい定義をランタイム内にロードする例示的なプロセスを示す図である。
【図１９】本発明を適用できる実施形態の変更要求を実施する例を示す図である。
【図２０】本発明を適用できる実施形態の接続されたメンバの例を示す図である。
【図２１】本発明を適用できる実施形態の接続に関する例示的な構造を示す図である。
【図２２】本発明を適用できる実施形態のインスタンス空間の概観を提供する例示的なＵＭＬ図である。
【図２３】本発明を適用できる実施形態の本明細書に述べる技法を実施するのに使用できる一般的なコンピュータ環境を示す図である。
【発明を実施するための形態】
【０００９】
以下、図面を参照して本発明を適用できる実施形態を詳細に説明する。各図面を通して、同じ機構を参照する場合には同じ番号を使用する。
【００１０】
以下の開示では、大規模なアプリケーションサービスを有する分散コンピューティングシステムを設計および実現するためのアーキテクチャに関連するいくつかの態様について述べる。この開示は、システム定義モデル（ＳＤＭ）（サービス定義モデルとも呼ばれる）と、ＳＤＭランタイム環境とに関する解説を含む。本開示はさらに、様々なデータセンタコンポーネントをどのようにモデル化するかといった設計側面も含む。
【００１１】
本明細書では、用語「配線」を「接続」、「通信」または「通信関係」と言う場合もある。また、用語「システム」を「モジュール」と言い、用語「リソース空間」を「リソース」と言う場合もある。さらに、用語「アプリケーション空間」を「アプリケーション」と言い、用語「インスタンス空間」を「インスタンス」と言う場合もある。さらに、用語「クラス」を「抽象定義」と言い、用語「ポート」を「エンドポイント」と言い、用語「型」を「定義」と言う場合もある。
【００１２】
図１に、例示的なネットワーク１００を示す。ネットワーク１００の設定では、複数（ｘ）のコンピューティングデバイス１０２（１）、１０２（２）、．．．、１０２（ｘ）がネットワーク１０６に結合されている。ネットワーク１０６は、様々な従来型のネットワークプロトコル（公衆および／またはプロプラエタリプロトコルを含む）を採用した、様々な従来型のネットワークトポロジおよびタイプ（配線および／または無線ネットワークを含む）のいずれかを表すものとする。ネットワーク１０６には、例えばローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネットの一部、その他を含めることができる。ネットワーク１００の設定は、例えばデータセンタ（例えばインターネットデータセンタ（ＩＤＣ））、オフィスまたはビジネス設定、家庭設定、教育または研究施設、小売または販売設定、データストレージ設定などを含めた、幅広い設定のいずれかを表す。
【００１３】
コンピューティングデバイス１０２は、デスクトップＰＣ（personal computer）、ワークステーション、メインフレームコンピュータ、サーバコンピュータ、インターネット装置、ゲーム用コンソール、ハンドヘルドコンピュータ、携帯電話、パーソナルディジタルアシスタント（ＰＤＡ）などを含めた、様々な従来型のコンピューティングデバイスのいずれかとすることができる。１つまたは複数のデバイス１０２は、同じタイプのデバイスでもよく、あるいは異なるタイプのデバイスでもよい。さらに、複数のデバイスが同じタイプのデバイスである場合でも、複数のデバイスはなお、異なる形で構成することもできる（例えば、２つのデバイス１０２はサーバコンピュータだが、異なるプロセッサ、異なる容量のランダムアクセスメモリ（ＲＡＭ）、異なるサイズのハードディスクドライブなど、異なるハードウェア構成を有することもできる）。
【００１４】
１つまたは複数のコンピューティングデバイス１０２は、ネットワーク１００の設定に追加した後で再構成することもできる。例えば、特定のコンピューティングデバイス１０２が、ある期間にわたって（例えば分、時間、日、月などの単位で）動作して１つの機能を実施し、次いで管理者が、異なる機能が望ましいと決定することもできる（例えば、サーバコンピュータからワークステーションコンピュータへの変更、ウェブサーバからローカルなファイルサーバへの変更）。
【００１５】
図２は、システム定義モデルを使用する例示的なアーキテクチャ２００を示すブロック図である。ＳＤＭは、システムのライフサイクル全体にわたって使用されるように設計される。システムは、協働して共通の機能を達成することのできる関連するソフトウェアおよび／またはハードウェアリソースのセットである。このようなシステムの一例はアプリケーションであり、アプリケーションは、コンピューティングデバイスによって稼動または実行されて様々な機能を実施することのできる命令のセットを指す。アプリケーションの例としては、ゲームなどの娯楽アプリケーション、ワードプロセッサなどの生産性アプリケーション、電子百科辞典などの参照アプリケーション、ウェブサービスや財務分析に使用できる分散アプリケーションなどが挙げられる。このようなシステムの別の例は、アプリケーション（または別の環境）を展開することのできる環境である。環境は、アプリケーション（または別の環境）の展開先であるソフトウェアおよび／またはハードウェアリソースを指す。このような環境は、後でより詳細に論じるようにレイヤ化することができる。
【００１６】
システムのライフサイクルは通常、３つの主要フェーズ（ステージとも言う）を含む。すなわち、設計または開発フェーズと、それに続く展開またはインストールフェーズと、それに続く運用または管理フェーズである。このモデルは、システムライフサイクルの３つのフェーズすべてに適用されるので、システムライフサイクルの様々なフェーズのための統合ポイントと見なすことができ、３つのフェーズのそれぞれを容易にする。さらに、このモデルを使用することにより、これらのフェーズの間で知識を移すことができる。知識は、システムの管理に関する知識（例えば、設計開発チームが将来のバージョンのためまたは現バージョンの性能改善のためにシステムを修正できるように、設計開発チームにフィードバックされる知識）や、システムの構造、展開要件、動作挙動の知識や、デスクトップからデータセンタへの動作環境の知識や、エンドユーザによって観察されたサービスレベルの知識などである。
【００１７】
一般に、設計フェーズの間、ＳＤＭに影響を与える開発ツールを使用して、通信ソフトウェアおよびハードウェアコンポーネントからなるシステムを定義する。システム定義は、必要なリソース、構成、動作特徴、ポリシーなどを含めて、分散システムを展開および運用するのに必要なすべての情報を含む。展開フェーズの間、システム定義を使用してシステムを自動的に展開し、必要なソフトウェアおよびハードウェア（例えばサーバ、ストレージ、およびネットワーク）リソースを動的に割り振り、構成する。同じシステム定義を、異なるホスト環境および異なる規模への展開に使用することができる。管理フェーズの間、オペレーティングシステム中のＳＤＭサービスが、システムを管理するためのシステムレベルのビューを提供する。これにより、新しい管理ツールが、リソース割振り、構成管理、アップグレード、およびプロセス自動化をシステムの視点から推進することができる。
【００１８】
アーキテクチャ２００は、ＳＤＭ定義モデルと、ＳＤＭ定義モデル内の機能動作を定義するスキーマとを採用する。定義モデルは、異なる様々な種類のデータ構造を含み、これらは「定義」と総称される。ＳＤＭの機能は、アプリケーションプログラムインタフェース（ＡＰＩ）など、１つまたは複数のプラットフォームサービスを介して開示（expose）される。
【００１９】
システムの設計フェーズの間、開発システム２０２が、ＳＤＭ文書２０４のようなシステム定義を含む文書を生成する。開発システム２０２は、米国ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＶｉｓｕａｌ  Ｓｔｕｄｉｏ（登録商標）開発システムなど、様々な開発システムのいずれかとすることができる。ＳＤＭ文書２０４は、システムの展開および管理に関係するすべての情報（本明細書では知識とも言う）を定義する。システムを展開または管理する際に必要なまたは使用されるどんな知識も、ＳＤＭ文書２０４に含まれる。本明細書では知識を単一の文書として述べるが、別法として複数の文書に分散させて維持してもよいことを理解されたい。
【００２０】
ＳＤＭ文書２０４は、システムが展開および／または実行されることになる環境が満たさなければならない１つまたは複数のシステム制約（要件とも言う）を含む。環境自体も、ＳＤＭ文書を使用して記述される。このような環境は、単一のコンピューティングデバイスとすることもでき、あるいは、コンピューティングデバイスの集合（例えばデータセンタ）、アプリケーションホストの集合などとすることもできる。異なるシステムを異なる環境にインストールすることができる。例えば、データセンタが５０台のコンピューティングデバイスを含む場合に、あるシステムをこれらのコンピューティングデバイスのうちの５台に展開し、別のシステムをこれらのコンピューティングデバイスのうちの３５台に展開することができる。これらの要件は、次のような様々な形をとる可能性がある。すなわち、システムの展開先であるコンピューティングデバイスに関するハードウェア要件（例えば最低プロセッサ速度、最低メモリ容量、最低ハードドライブ空き容量、利用可能なネットワーク帯域幅の最低量、利用可能な特定のセキュリティ機構など）や、システムの展開先であるコンピューティングデバイスに関するソフトウェア要件（例えば特定のオペレーティングシステム、共にインストールしなければならない１つまたは複数の他のアプリケーション、特定のシステムおよび／またはオペレーティングシステムをどのように構成するかに関する指定、使用される特定タイプのセキュリティまたは暗号化など）や、システムの展開先であるコンピューティングデバイスに関するその他の要件（例えば利用可能なセキュリティ鍵、施行しなければならないデータセンタポリシー、使用される認証、環境トポロジなど）等である。
【００２１】
要件は別な方向に向かう可能性もある。すなわち、環境が、インストールされるシステムの構成に対して制約または要件を有する可能性もある（例えば環境の基準またはポリシーを実施するため）。これらは、環境のオペレータによって生み出される「明示的な」要件とすることができ、システムが有さなければならない特定の設定または構成や、システムが提供またはサポートしなければならない特定の機能や、システムがサポートしなければならない特定のセキュリティ機構などである。これらはまた、環境の特定の構成によって生じる「暗黙的な」要件とすることもできる。例えば、環境中のホストコンピューティングデバイスが特定タイプのファイルシステムを使用している場合に、このファイルシステムを使用して実施することができないアクションがある場合がある（別のファイルシステムを使用すればこれらのアクションを実施することができるにもかかわらず）。
【００２２】
システムの設計および開発フェーズの間、ＳＤＭ文書２０４を使用して、１つまたは複数の特定の環境についてシステムを妥当性検査することができる。これは両方向の妥当性検査である。すなわち、システムを環境について妥当性検査し、環境をシステムについて妥当性検査する。環境をシステムについて妥当性検査することは、ＳＤＭ文書２０４中で識別される要件を環境と比較して、すべての要件が環境によって満たされるかどうかを決定することによって行うことができる。システムを環境について妥当性検査することは、ＳＤＭ文書中で環境に関して識別される要件をシステムと比較して、すべての要件がシステムによって満たされるかどうかを判定することによって行うことができる。すべての要件が環境およびシステムによって満たされる場合、設計者または開発者には、システムをこの環境で展開できること、およびシステムがこの環境で実行されることがわかる。しかし、すべての要件が環境および／またはシステムによって満たされない場合は、設計者または開発者には、任意選択で、満たされなかった要件が通知され、それにより、システムをこの環境で展開して実行するためにどんな変更をＳＤＭ文書２０４に（かつそれに対応してシステムに）および／または環境に加えるべきかが通知される。
【００２３】
ＳＤＭ文書２０４に含まれるシステム展開に関する知識は、システムをどのように１つまたは複数の環境で展開するかを記述する。ＳＤＭ文書２０４は、コントローラ２０６に利用可能とされ、コントローラ２０６は、展開モジュール２０８および管理モジュール２１０を備える。ある実施形態では、ＳＤＭ文書２０４、ならびにシステムをインストールするのに必要なシステムファイルすべて（例えばバイナリ、データ、ライブラリなど）は、ＳＤＵ（システム定義ユニット）と呼ぶ単一のコンテナ（例えば単一のファイル）に共にパッケージされる。コントローラ２０６は、図１のコンピューティングデバイス１０２の１つまたは複数とすることができる。例えば、図１の単一のデバイス１０２が特定のデータセンタ用のコントローラであってもよく、あるいは、コントローラの任務は複数のデバイス１０２に分散されてもよい。
【００２４】
展開モジュール２０８は、システムを環境中に展開するのに使用されるサービスを含む。図２では、システムが展開される環境は、１つまたは複数のターゲットデバイス２１２である（またはこれらのデバイス上に展開されている）。システムはまた、コントローラ２０６に展開することもできる。展開モジュール２０８のこれらのサービスには、１つまたは複数のシステムを環境中にインストールまたは展開するために呼び出すことのできる１つまたは複数の関数が含まれる。
【００２５】
ＳＤＭ文書２０４には、異なる環境で展開するための異なる知識を含めることができる。この展開知識は、環境中で行う必要のある任意の変更（例えば、システムレジストリ、作成する必要のあるフォルダ、ディレクトリ、またはファイル、特定の値に設定する必要のある、コンピューティングデバイスのその他の設定パラメータまたは構成パラメータなどの変更）、ならびに、環境中でどのファイル（例えばプログラムファイルおよび／またはデータファイル）をコンピューティングデバイスにコピーする必要があるか、またこれらのファイルに対して実施する必要のある任意の操作（例えば圧縮解除および／または暗号化解除が必要なファイルもある）を記述する。多くの実装形態では、ＳＤＭ文書２０４中の展開知識は、例えば、システムのための通常のセットアッププログラムまたはインストールプログラム中に現在みられるような情報に類似する情報を含む。
【００２６】
展開プロセスの間、コントローラ２０６は、展開に関与するソフトウェアおよびハードウェアリソースの、ならびにこれらの関係の、記録または記憶を生成する。この記録または記憶は、後で管理フェーズの間にコントローラ２０６が使用することができる。
【００２７】
管理モジュール２１０は、システムが環境にインストールされた後でシステムを管理するのに使用されるサービスを含む。サービス管理モジュール２１０のこれらのサービスには、環境中でシステムを管理するために呼び出すことのできる１つまたは複数の関数が含まれる。ＳＤＭ文書２０４に含まれるシステム管理に関する知識は、システムをどのように１つまたは複数の環境で管理するかを記述する。
【００２８】
ＳＤＭ文書２０４には、システムを異なる環境で管理するための異なる知識を含めることができる。管理知識には、システムの管理または運用で使用される任意の知識が含まれる。管理には、例えば、構成（および任意選択で後の再構成）、パッチおよびアップグレード、保守作業（例えばバックアップ）、ヘルス監視または性能監視などが含まれる。
【００２９】
展開されたシステムに対する変更は、管理モジュール２１０を介して行う。管理モジュール２１０のサービスには、環境中に展開された１つまたは複数のシステムに変更を加えるために呼び出すことのできる１つまたは複数の関数が含まれる。管理モジュール２１０を介してこれらの変更を行うことにより、いくつかの利点を実現することができる。このような利点の１つは、加えられた変更の記録をコントローラ２０６が維持できることである。コントローラ２０６は、システムについてのＳＤＭ文書２０４のコピーを維持し、システムに加えられたどんな変更もＳＤＭ文書２０４に記録することができる。あるいはコントローラ２０６は、システムに加えられた変更に関する別個の記録を維持してもよい。
【００３０】
コントローラ２０６によって維持されるこの変更記録は、システムおよび／または環境に関する問題を解決するときや、ハードウェア障害によりシステムを再インストールしなければならないとき（システムを再インストールして障害時と同じパラメータ／設定で稼動するよう元に戻せるようにする）などに、後続の操作を単純化することができる。コントローラ２０６によってこのような変更が行われるようにすることにより、またコントローラ２０６が記録を維持するようにすることにより、いくらかの人為的ミスを環境からなくすことができる（例えば、変更を行う管理者が変更を帳面に記録することになっているのにそうするのを忘れた場合、この変更の記録はないことになる。この問題は、コントローラ２０６に記録を維持させることによって解決する）。
【００３１】
さらに、コントローラ２０６を介してシステムに変更を加えることにより、またコントローラ２０６を介してシステムを展開することにより、コントローラ２０６は、環境と、環境中に展開されるシステムと、これらの間の対話とに関する知識のリポジトリとして働くことができる。環境および／または環境中に展開されるシステムに関する知識は、コントローラ２０６から容易に得ることができる。この知識を使用して、中央のコントローラ２０６に記憶されている状態を環境中の被制御デバイスが反映していることを妥当性検査することにより、被制御環境の一貫性を保証することができる。
【００３２】
状況によっては、コントローラ２０６を介さずに、システムおよび／または環境に変更が加えられる場合もあることに留意されたい。例えば、コンピューティングデバイスが誤ってオフにされたり、作動しなくなったりすることがある。これらの状況では、このような変更をコントローラ２０６中に反映させるよう試みる。これらの変更は、自動的にコントローラ２０６中に反映させることもでき（例えば、デバイス障害を検出して、このような障害を管理モジュール２１０のサービスを使用してコントローラ２０６に通知するシステムを稼動させることができる）、あるいは手動でコントローラ２０６中に反映させることもできる（例えば、管理者が管理モジュール２１０のサービスを使用して、このような変更をコントローラ２０６に通知することができる）。あるいは、加えられた変更を元に戻し、システムおよび／または環境の一部を、コントローラ２０６によって記録された所望のシステム状態と再び一致させることもできる。
【００３３】
したがって、ＳＤＭ文書２０４は、「生きた」文書と見なすことができる。すなわち、環境の変化および／またはシステムの変化に基づいて、システムのライフサイクルを通して継続的に変化することができる。
【００３４】
システム定義モデル（ＳＤＭ） 
システム定義モデル（ＳＤＭ）は、システムの定義を生み出すのに使用されるモデル化技法である。システムは、協働して共通の機能を達成する関連するソフトウェアおよび／またはハードウェアリソースのセットである。例示的なシステムには、多層ＬＯＢ（ｌｉｎｅ−ｏｆ−ｂｕｓｉｎｅｓｓ）アプリケーション、ウェブサービス、電子商取引サイト、および企業データセンタが含まれる。ＳＤＭは、アプリケーション構築者、ネットワーク構築者、データセンタ構築者、またはその他の開発者が分散コンピュータアプリケーションおよびデータセンタを抽象方式で設計するためのツールおよびコンテキストを提供する。ＳＤＭは、物理的なコンピュータリソースおよびソフトウェアによって最終的に実現されることになるシステムの機能単位を表す要素のセットを定義する。ＳＤＭはまた、システムを管理することになるオペレータまたはその他の個人に関係する要素も定義する。さらにＳＤＭは、開発、展開、および運用に関係するデータも取り込む。ＳＤＭ要素には、コンポーネントによって表される機能動作をどのように指定すべきかを指示するスキーマが関連する。
【００３５】
システムは、リソース、エンドポイント、関係、およびサブシステムで構成される。これらの各項目の定義が、ＳＤＭ文書中で宣言される。ＳＤＭ文書は、システム、リソース、エンドポイント、および関係についての１つまたは複数の定義を含むＸＭＬ（Extensible Markup Language）文書である。リソースは、ハードウェアリソースまたはソフトウェアリソースとすることができる。エンドポイントは、システムを越えた通信を表す。関係は、システム、リソース、エンドポイントの関連を定義する。サブシステムは、完全なシステムとして扱うことができ、通常はより大きいシステムの一部である。
【００３６】
システム定義は、動的システムの基本構造を取り込む。これは、他のすべての情報がその上に追加される骨格と見なすことができる。この構造は一般に、開発プロセスの間に設計者および開発者によって指定され、通常は頻繁に変更されることはない。構造の他に、ＳＤＭは、展開情報、インストールプロセス、構成やイベントや計測のためのスキーマ、自動化タスク、ヘルスモデル、運用ポリシーなども含むことができる。分散システムの存続期間を通して、運用スタッフ、ベンダ、および／または管理システムがその他の情報を追加することができる。
【００３７】
ＳＤＭスキーマ設計仕様 
ＳＤＭは、分散システム（例えばモデル化システム）中のコンポーネントの構成、対話、および変更の記述（description）をサポートするように設計される。「定義（definition）」が、システム中に存在するエンティティを記述し、「関係（relationship）」が、様々なエンティティ間のリンクを識別する。定義および関係はさらに、ＳＤＭに関連するセマンティック情報を取り込むように定義される。図３に示すように、ＳＤＭ定義３０２は、リソース定義３０４、コンポーネント定義３０６、エンドポイント定義３０８という３つのサブ定義を含む。
【００３８】
図４に示すように、ＳＤＭ関係４０２は、包含関係４０４、委任関係４０６、接続関係４０８、ホスティング（hosting）関係４１０、参照関係４１２という５つのサブ関係を含む。接続関係４０８は、「通信関係」と呼ばれる場合もある。定義および関係に関するこれ以上の詳細は後で提供する。
【００３９】
ＳＤＭは「抽象定義」を含む。これは、システムの各部分の共通範疇化と、幅広いアプリケーションのためのツールサポートと、設計時の定義チェックのための基盤とを提供する。抽象定義のセットは、サービス設計のための包括的な基盤を提供する。「具象定義」が、実際のアプリケーション設計またはデータセンタ設計の各部分を表す。具象定義の生成は、抽象定義を選択し、具象定義のメンバとそのプロパティの設定値とを定義する実装を提供することによって行う。分散アプリケーションは、これらの具象定義の集合を使用して生成する。
【００４０】
ＳＤＭは「制約」も含む。制約は、関係のインスタンスが参与することのできる許容される関係のセットに基づく制限をモデル化する。制約は、関係に関与するオブジェクトの構成に応じた要件を記述する際に有用である。例えば、制約を使用して、通信プロトコルの両端の参与者が互換性のあるセキュリティ設定を使用しているかどうかを判定することができる。
【００４１】
定義および／またはリソースの一部として、フローを識別することができる。このフローを使用して、オペレータ設定をシステム、サブシステム、またはこのような設定を利用する他のコンポーネントに伝搬させることによって、ランタイム時のアプリケーション挙動を制御する。
【００４２】
抽象定義および抽象関係 
抽象定義は、設計時にアプリケーション構成をチェックしてからランタイム時にアプリケーションを展開および管理する構成単位を定義する。これらの構成単位は、モデル化システム中に存在するエンティティを表す。例えば抽象定義は、ファイルおよびディレクトリ、ウェブサーバ内部の構成、またはＳＱＬ（Structured Query Language）サーバ内部のデータベースをモデル化することができる。
【００４３】
抽象関係は、抽象定義間で行うことのできる対話をモデル化する。関係は、バイナリおよび有向であり、関係の発現に参与するインスタンスの定義を識別する。関係は、エンティティを相互に関連付ける方法を提供し、それにより、エンティティ間の包含、構築、通信のリンクをモデル化することを可能にする。
【００４４】
定義が制約を使用して、定義の参与する関係を制約する。さらに、関係が制約を使用して、リンクすることのできる定義を制約する。これらの制約は、関係への参与者の定義および設定をターゲットにすることができる。
【００４５】
抽象定義空間は、コンポーネント、エンドポイント、リソースという３つのカテゴリに分けられる。抽象コンポーネント定義は、アプリケーションの自己完結型かつ独立展開可能な部分を記述する。これらの定義は、プロセスおよびマシンの境界を横断することのできる明確に定義された通信チャネルを介して対話するアプリケーション部分を表す。抽象エンドポイント定義は、コンポーネントが開示することのできる通信エンドポイントを記述する。これらの抽象エンドポイント定義は、設計時にシステム接続性を検証するためおよびランタイム時に接続を可能にするために、システムが意識しているすべての形の通信をモデル化することができる。抽象リソース定義は、コンポーネント内に含まれる挙動（behavior）を記述する。リソース定義は、他のリソース定義への強力な従属性を有することができる。これらの従属性には、特定のインストール順序を必要とすることや、様々な通信機構を介したランタイム対話を開始することを含めることができる。
【００４６】
抽象定義は、設定を開示する（expose）能力を備える。一実施形態では、これらの設定は、名前と値の単純な対であり、ＸＭＬスキーマを使用して設定の定義を定義する。設定は動的としても静的としてもよい。静的設定は、展開プロセスの間にわたり設定される。動的設定は、展開後に変更することができる。実行中のシステムに設定値を適用することを担うコードは、ＳＤＭランタイム中でホストされる。
【００４７】
ＳＤＭモデルは、抽象定義を越えた継承をサポートする。派生した定義は、その親によって開示されたプロパティを拡張することができ、その親のプロパティに関する値を設定することができる。派生した定義は、その親を参与者として識別する関係に参与することができる。
【００４８】
前述のように、関係は、通信（または接続）、包含、委任、ホスティング、参照という５つのカテゴリに分けられる。通信関係は、抽象エンドポイント定義間の可能性ある通信対話を取り込む。通信関係があることは、識別された定義のエンドポイントを開示しているコンポーネントが通信することが可能かもしれないことを示す。実際のリンク確立は、エンドポイントおよびエンドポイントの開示（exposure）に対する制約を受ける。
【００４９】
包含関係は、抽象定義が他の抽象定義のメンバを含むことができることを記述する。より具体的には、２つの抽象定義ＡとＢの間の包含関係では、Ａを実装する具象定義が、Ｂを実装する定義のメンバを含むことができる。包含関係は、開発者がアプリケーションを構築するときに生じる自然なネスト構造をモデル化する。別の定義のメンバを含めることにより、親は、含まれる定義の存続期間および可視性を制御することができる。ランタイム空間中のすべての定義インスタンスは、他の定義インスタンスのメンバとして存在し、完全に接続されたインスタンスセットを形成する。したがって、包含関係のセットは、ランタイム空間で生じる許容される包含パターンを記述する。
【００５０】
委任関係は、含まれるメンバを選択的に開示する。例えば委任は、コンポーネント定義からのエンドポイントメンバを開示することができる。内側のコンポーネントからエンドポイントを委任することにより、外側のコンポーネントは、特定のプロトコルを使用して、プロトコルの奥にある実装を開示することなく通信する能力を呈する。
【００５１】
ホスティング関係および参照関係は、従属関係の２つの形を表す。ホスティング関係は、特定ホスト上に定義のインスタンスをどのように生成するかに関する知識を取り込むのに使用する。ホスティング関係により、開発者は、特定ホストの動作から独立した方式で自分自身の定義を生成することができる。この関係ではまた、ゲスト定義を書き換えずに単一の定義を複数のホストタイプ上に展開することができる。ホスティング関係は、具象定義のインスタンスが生成される前に存在する抽象定義間の主要な従属性を記述する。各インスタンスは、ホスティング関係にゲストとして参与し、それによりホスティング関係は、完全に接続されたツリーをインスタンス空間にわたって形成する。参照関係は、パラメータフローおよび構築順序付けに使用される追加の従属性を取り込む。
【００５２】
具象定義および具象関係 
抽象定義から具象定義を構築する。抽象関係から具象関係を構築する。抽象定義と抽象関係の組合せは、ターゲットシステムをモデル化するためのスキーマを定義する。具象定義は、抽象定義空間のサブセットを使用して、１つまたは複数の抽象定義の再使用可能な構成を生み出す。抽象定義空間は、データベースに関するスキーマに例えることができる。この類比では、具象定義空間は、データベース中の行のセットのための再使用可能テンプレートを表す。データベース中の行をスキーマの制約（例えば外部キーなど）に対して妥当性検査するのと同じようにして、具象定義を抽象定義空間に対して妥当性検査する。開発者は、抽象定義の知識から具象定義の知識を推論することができる。したがって、抽象定義に関連するツールが、抽象定義から派生する多くの実装と共に動作することができる。例えば、抽象ウェブサービスについて知っているツールが、開発者からの追加の情報を必要とせずに、データセンタ中に展開された任意のウェブサービスと共に動作することができる。
【００５３】
各具象定義は、特定の抽象定義に対する実装を提供し、実装は、設定スキーマに対する拡張と、設定に関する値と、定義メンバおよび関係メンバに関する宣言と、定義が参与することのできる関係に対する制約とを含む。具象定義の挙動は、抽象定義の定義に従う。具体的には、抽象コンポーネント定義がコンポーネント定義になり、抽象エンドポイント定義がエンドポイント定義になり、抽象リソース定義がリソース定義になる。
【００５４】
各具象関係は、特定の抽象関係に対する実装を提供し、実装は、設定スキーマおよび設定値と、同じ関係カテゴリ（ホスティング、包含、通信など）のネストされたメンバと、関係に参与することのできる定義に対する制約とを含む。
【００５５】
具象ホスティング関係は、ある具象定義のメンバを別の具象定義上にマッピングすることのできるホスティング関係のセットを定義する。例えば、具象ホスティング関係は、ウェブアプリケーションとそれが展開されることになるＩＩＳ（Internet information service）（商標）ホストとの間のバインドを識別することができる。特定の定義に対して複数の具象ホスティング関係が存在することができ、これにより開発者は、特定のトポロジに対して複数の展開（deployment）を定義することができる。
【００５６】
具象定義は、他の具象または抽象定義のメンバを宣言することができる。これらを「定義メンバ」と呼ぶ。この場合、これらの定義メンバは、定義メンバ間の関係を定義する「関係メンバ」から参照される。定義メンバは、特定の定義のインスタンスへの参照を含む。設定フローが、定義に関する値を提供することができ、あるいは、定義を生成するときに使用される構築パラメータを制約することができる。定義メンバを宣言するとき、ユーザ（例えば開発者）は、定義メンバが、外側のコンポーネントが生成されるのと同時に生成されるか（「値セマンティクス」と呼ばれる）、あるいは後で行われる新しい明示的動作によって生成されるか（「参照セマンティクス」と呼ばれる）を決定することができる。
【００５７】
関係メンバは、定義メンバが生成されたときにそれらが参与することになる関係を定義する。定義メンバが具象定義に含まれる場合は、包含関係メンバを、定義メンバと外側の定義に対するこの参照との間で宣言する。定義メンバが委任される場合は、委任関係メンバを、定義メンバとネストされる定義メンバとの間で定義する。通信関係メンバは、定義メンバ上のエンドポイント間で宣言することができ、従属関係メンバ（参照およびホスティング）は、定義メンバまたはネストされる定義メンバ間で宣言することができる。
【００５８】
関係制約は、特定の定義が参与を望む関係のセットを限定する。関係制約は、特定の関係に対する制約、および関係の他方の端の参与者に対する制約を識別する。
【００５９】
インスタンス空間 
ＳＤＭランタイムに記憶されているインスタンス空間は、モデル化システムの現在状態を識別する。ＳＤＭランタイムは、生成されたインスタンスと、これらのインスタンス間の関係との記録を含む。各インスタンスにはバージョン履歴が関連し、バージョン履歴は、各バージョンを変更要求にリンクする。変更要求は、新しいインスタンスを生成するプロセスである。変更要求は、既存のインスタンスの特定メンバに関連する定義および関係に対する、生成、更新、削除要求のセットを定義する。ルートは特別なケースとして扱われる。
【００６０】
変更要求は、ランタイムによって展開され、１つまたは複数の制約に対して検証されてから構築される。展開プロセスでは、含んでいる定義の構築要求の一部として暗黙的に構築される定義インスタンスおよび関係インスタンスを識別する。展開プロセスの一部として、設定フローをすべての関係にわたって評価する。検証ステップでは、必要な関係がすべて存在すること、および関係が必要な制約を満たすことをチェックする。最後に構築プロセスでは、各インスタンスの展開、更新、または削除にわたる適切な順序付けを判定する。次いで構築プロセスでは、適切なアクションが実施されるように、各インスタンスを正しいシーケンスでインスタンスマネージャに渡す。
【００６１】
データセンタは、複数のソフトウェアコンポーネントを使用して生み出すことができる。複数のソフトウェアコンポーネント間で、１つまたは複数の接続を構成する。これらのソフトウェアコンポーネントのいくつかは、アプリケーションレイヤに関するホストとして機能することができる。ホストレイヤ中の例示的なコンポーネント定義としては、ＩＩＳ（商標）、ＳＱＬ、ＡＤ、ＥＸＣＨＡＮＧＥ、ＤＮＳ（Domain Name System）、ＢｉｚＴａｌｋ（商標）が挙げられる。
【００６２】
ネットワーク／ＯＳ（operating system）／ストレージレイヤは、データセンタネットワークおよびプラットフォームの構築をサポートする。このレイヤはまた、ネットワークセキュリティモデルの構成、オペレーティングシステムプラットフォームの構成、および、１つまたは複数の記憶デバイスとオペレーティングシステムプラットフォームとの関連付けもサポートする。ネットワーク／ＯＳ／ストレージレイヤ中の例示的なコンポーネント定義としては、ＶＬＡＮ、Ｗｉｎｄｏｗｓ（登録商標）、Ｆｉｌｔｅｒ、Ｓｔｏｒａｇｅが挙げられる。
【００６３】
ハードウェアレイヤは、データセンタに存在するシステムの定義、およびこれらのシステム間に存在する物理接続を識別する。特定のコンポーネントに必要な関係を満たすために、このコンポーネントを、マッチする機能を有するホストコンポーネントにバインドする。このプロセスを「論理配置（ｌｏｇｉｃａｌ  ｐｌａｃｅｍｅｎｔ）」と呼ぶ。展開時、ゲストコンポーネントのインスタンスを、ホストコンポーネントのインスタンス上に配置する。このプロセスを「物理配置（ｐｈｙｓｉｃａｌ  ｐｌａｃｅｍｅｎｔ）」と呼ぶ。
【００６４】
図５に、ウェブアプリケーション５０２をウェブサーバホスト５０４にマッピングする例を示す。破線５０６で識別される境界が、アプリケーションレイヤをホストレイヤから分離している。ウェブアプリケーション５０２は、リモーティングサービスエンドポイント５０８、ウェブサービスエンドポイント５１０、およびウェブユーザインタフェースエンドポイント５１２を含み、これらはすべて、ウェブサーバ５０４中のウェブサイト５２２にマッピングする。さらに、ウェブアプリケーション５０２中の仮想ディレクトリ５１６が、ウェブサイト５２２にマッピングする。ウェブアプリケーション５０２はコンシューマエンドポイント５１４も含み、コンシューマエンドポイント５１４は、ウェブサーバ５０４中のコンシューマエンドポイント５２４にマッピングする。ウェブアプリケーション５０２のアセンブリ部分５１８が、ウェブサービス５０４のランタイム部分５２８にマッピングする。ウェブアプリケーション５０２中のコンテンツディレクトリ５２０が、ウェブサーバ５０４中のウェブルートディレクトリ５２６にマッピングする。
【００６５】
ＳＤＭモデルには、分散システムに対する変更を管理するプロセスが関連する。分散システムに対する変更は、１つまたは複数の処理ステップを経た変更要求によって進められ、その後、要求の中の動作が配信され、ターゲットシステムに対して実行される。
【００６６】
図６に、ＳＤＭランタイムを使用する例示的なアーキテクチャ６００を示す。アーキテクチャ６００は、図２のアーキテクチャ２００の一例であり、ＳＤＭランタイム６１０と、後で「例示的なＳＤＭ実装形態」の章で論じるＳＤＭの例示的な実装形態とを使用する。ＳＤＭランタイム６１０は、ＳＤＭファイルを受領して妥当性検査し、ＳＤＵ（システム定義ユニット。１つまたは複数のＳＤＭファイルおよびそれらに関係するファイルのパッケージ）をロードし、ＳＤＭ変更要求を生成して実行し、ＳＤＭベースのシステムをターゲット環境に展開するための、コンポーネントおよびプロセスのセットを含む。このランタイム機能により、ＳＤＭを使用して記述されたシステムを定義および妥当性検査し、コンピューティングデバイスのセットに展開し、管理することができる。
【００６７】
ＳＤＭは、後で「例示的なＳＤＭ実装形態」の章でより詳細に論じるが、分散システム（モデル化システム）中のコンポーネントの構成、対話、および変更の記述（description）をサポートするように設計される。ＳＤＭは、オブジェクト関係（relational）モデルに基づく。「定義」が、システム中に存在するエンティティを記述し、「関係（relationship）」が、様々なエンティティ間のリンクを識別する。定義および関係はさらに、ＳＤＭに関連するセマンティクス情報を取り込むように定義される。具体的には、定義はコンポーネント、エンドポイント、リソースに分けられる。関係は、接続（通信とも言う）、包含、ホスティング、委任、参照に分けられる。定義および関係に関するこれ以上の詳細は後で提供する。
【００６８】
ＳＤＭは「抽象定義」を含む。これは、システムの各部分の共通範疇化と、幅広いシステムのためのツールサポートと、設計時の定義チェックのための基盤とを提供する。抽象定義のセットは、サービス設計のための包括的な基盤を提供する。「具象定義」が、実際のシステム設計またはデータセンタ設計の各部分を表す。具象定義の生成は、抽象定義を選択し、具象定義のメンバとそのプロパティの設定値とを定義する実装を提供することによって行う。分散アプリケーションは、これらの具象定義の集合を使用して生成する。
【００６９】
ＳＤＭは「制約（constraint）」も含む。制約は、関係のインスタンスが参与することのできる許容される関係のセットに基づく制限をモデル化する。制約は、関係に関与するオブジェクトの構成に応じた要件を記述する際に有用である。例えば、制約を使用して、通信プロトコルの両端の参与者が互換性のあるセキュリティ設定を使用しているかどうかを判定することができる。
【００７０】
ターゲットシステムに対する変更を実施するために、ＳＤＭは、「変更要求」またはＣＲと呼ばれる、必要とされる変更の宣言記述を使用する。ＳＤＭは、「ＳＤＭ実行モデル」の一部として変更要求を展開（ｅｘｐａｎｄ）、妥当性検査、および実行するのに使用されるプロセスを定義する。
【００７１】
「インスタンス空間」は、管理されるアプリケーションの所望状態と現在状態の両方を取り込む。インスタンス空間中の変更は、追跡され、その変更を開始した変更要求に関連付けられる。インスタンス空間は、ＳＤＭランタイム内に記憶され、モデル化システムの現在状態を反映する。ランタイムは、生成されたインスタンスと、これらのインスタンス間の関係との完全な記録を含む。各インスタンスにはバージョン履歴が関連し、バージョン履歴中では、各バージョンが変更要求にリンクされている。新しいインスタンスを生成するプロセスは、変更要求によって開始される。変更要求は、既存のインスタンスの特定メンバに関連する定義および関係に対する、生成、更新、削除要求のセットを定義する。
【００７２】
以下は、図６のコンポーネントがどのように協働するかについての簡単な機能上の解説である。オペレータまたは管理者が、データセンタのトポロジなど、アプリケーションを展開（deploy）できる環境を記述することができる。オペレータまたは管理者は、環境を記述するＳＤＭファイルを作成するが、このファイルは、「論理インフラストラクチャ」（ＬＩＭ）６０２、あるいはデータセンタ記述またはデータセンタモデルと呼ばれる。このＳＤＭファイルは、米国ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ（登録商標）Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＶｉｓｕａｌ  Ｓｔｕｄｉｏ（登録商標）開発システムなど、様々な開発システムのいずれかを使用して生成することができる。
【００７３】
さらに、アプリケーション開発者は、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏ（登録商標）開発システムなどの様々な開発システムのいずれかを使用して、自分のアプリケーションを設計および開発することができる。開発者は、アプリケーションのコンポーネントと、これらのコンポーネントがどのように相互に関係するかを定義するので、アプリケーション記述をデータセンタ記述６０２に対して妥当性検査することができる。これを「設計時妥当性検査」とも呼ぶ。
【００７４】
アプリケーションが完成すると、開発者は記述をＳＤＭに保存し、アプリケーションがＳＤＵ６０４として展開されるようにアプリケーションのパッケージングを要求する。ＳＤＵは、アプリケーションＳＤＭと、アプリケーションをインストールするのに使用されるアプリケーションバイナリおよびその他の参照ファイルとを含む。
【００７５】
ＬＩＭ６０２およびＳＤＵ６０４は、展開（deployment）に向けて、コントローラデバイス６２０の展開ツール６０６に供給される。展開ツール６０６は、オペレータが所望のＳＤＵ６０４をロードできるようにするためのユーザインタフェース（ＵＩ）を備える。展開ツール６０６は、ＣＲ生成モジュール６３０と協働して、ＳＤＵ６０４に関連するアプリケーションを、ＳＤＵ６０４内のＳＤＭ中の情報に従ってインストールする。さらに、ＳＤＵ６０４からのＳＤＭ定義およびインスタンスが、ＳＤＭランタイム６１０のＳＤＭ記憶域（store）６０８にポピュレートされる。ＳＤＵは、ＳＤＭランタイム６１０中でＳＤＵ管理モジュール６４０によって管理され、ＳＤＵ管理モジュール６４０は、ランタイム６１０の他のコンポーネントおよびターゲット６２２がＳＤＵの適切な部分を利用できるようにする。
【００７６】
オペレータはまた、展開中のアプリケーションの展開先であるターゲット６２２（例えばターゲットコンピューティングデバイス）に対してオペレータがどんなアクションを取りたいかを指定することができる。オペレータは、展開ファイルを介してこれを行うことができ、この展開ファイルは、本明細書では変更要求（ＣＲ）とも呼ばれる。ＣＲは、１つまたは複数のエンジン６１２、６１４、６１６、６１８を通して実行される。一般に、ＣＲ展開エンジン６１２は、ＣＲを展開して、関連するすべてのコンポーネントならびにそれらの接続およびアクションを識別する。値フローエンジン６１４は、コンポーネントに関する値（接続ストリングなど）をフローする。制約チェックエンジン６１６は、環境とアプリケーションとの間の制約をチェックする。アクション順序付けエンジン６１８は、ＣＲに関する必要なすべてのアクションの順序を指定する。
【００７７】
システムに対する変更（アプリケーションの展開を含む）、またはモデルの妥当性検査を開始するために、オペレータまたはプロセスは、ＣＲをサブミット（submit）する。ＣＲは、オペレータがランタイム６１０中のインスタンスを介して実施したいアクションのセットを含む。これらのアクションは、例えば生成アクション、更新アクション、および／または削除アクションとすることができる。
【００７８】
ユーザまたはオペレータによって開始される変更要求に加えて、展開／自動生成の変更要求があるものとすることもでき、これは、後でより詳細に論じる展開プロセスの一部として生成される。変更要求は、そのソースにかかわらず、完全に展開されチェックされた後で、ターゲットインスタンスの発見、インストール、アンインストール、変更などのアクションをターゲット６２２に送ることによって実行される。
【００７９】
ＣＲは、グループとして完了または失敗する原子アクションセットとして扱われる。これにより例えば、制約チェックエンジン６１６は、妥当性をテストするときにすべてのアクションを考慮することができる。
【００８０】
設計時妥当性検査では、ＣＲは、ＳＤＭコンパイラ６２８によって生成され、ＳＤＭファイル中の各ＳＤＭコンポーネントの１つまたは最小限を含むことになる。この、インスタンス生成コマンドのＣＲは、ＣＲ展開エンジン６１２、値フローエンジン６１４、および制約チェックエンジン６１６の中をフローする。この３つのフェーズで見つかったエラーは、ユーザが使用している開発システムを介してユーザに返される。
【００８１】
展開時は、オペレータは、展開ツール６０６によって提示されるＵＩ（user interface）でＣＲを生成する。ＣＲは、ＳＤＭランタイム６１０中のすべてのエンジン６１２、６１４、６１６、６１８の中をフローし、適切なアクションおよび情報がＣＲ実行モジュール６３２から適切なターゲット６２２に送られ、ターゲット６２２で要求が実行される（例えばアプリケーションがインストールされる）。特定のインストールの場合の適切なターゲット６２２は、通常、アプリケーションがインストールされることになるターゲットである。
【００８２】
ＣＲの処理を開始する際、定義解決フェーズで、ＣＲ生成モジュール６３０は、変更要求の中で参照されるすべての定義およびメンバを解決する。変更要求は、これらがすでにランタイム６１０によってロードされていると見なす。これらが存在しない場合は、ＣＲ生成モジュール６３０はロード／コンパイルアクションを開始する。ＣＲ生成モジュール６３０はパス解決フェーズも実施し、変更要求内の、既存のインスタンスおよび生成アクションによって定義されたインスタンスへの参照を解決する。
【００８３】
ＣＲ展開エンジン６１２によって実施される展開は、所与の変更要求について、この要求を実行するのに必要な残りのすべてのアクションをポピュレートするプロセスである。一般にこれらのアクションは、定義インスタンスおよび関係インスタンスに対する構築（construction）アクションおよび破壊（destruction）アクションである。オペレータは任意選択で、インスタンスを構築または破壊するのに必要なすべてのアクションに関する詳細を提供することもでき、あるいはこのプロセスの一部は自動化することもできる。例えばオペレータは、メンバ（例えばｂｙＲｅｆｅｒｅｎｃｅメンバ）に対するアクションを識別することにより、オペレータが望む変更に関するキー情報を提供する。すると、ネストされたメンバ（例えばｂｙＲｅｆｅｒｅｎｃｅメンバおよびｂｙＶａｌｕｅメンバ）と関係に対して、アクションの残りが埋められる。別の例として、自動化された展開は、外部リソースマネージャを参照することもでき、外部リソースマネージャは、利用可能なリソースを有するデバイスを選択することや、それが必要とするデータに近いアプリケーションを突き止めることなどに基づいて、展開決定を行うことができる。
【００８４】
ＣＲ展開エンジン６１２は、「自動記述（writing）」も実施する。自動記述の間、ＣＲ展開エンジン６１２は、ＳＤＭ中で指定されているコンポーネントおよび複合コンポーネントのスケール不変のグループ化を分析し、コンポーネントが要求のレベルにスケールされたときにコンポーネントがどのようにグループ化され相互接続されるべきかを判定する。
【００８５】
ＣＲ展開エンジン６１２は、値（value）メンバ展開、参照（reference）メンバ展開、および関係展開も実施する。
【００８６】
値メンバ展開は、すべての非参照定義メンバを識別することを指す。これらのメンバのカーディナリティ（cardinality）が示され、必要なパラメータはすべてわかるので、各メンバごとに、親の生成中であるメンバについては生成要求が変更要求に追加される。変更要求が破壊動作を含む場合は、それらに含まれるすべてのインスタンスについて破壊動作が追加される。
【００８７】
参照メンバ展開は、参照メンバを指す（非参照定義メンバとは反対に）。参照メンバのカーディナリティはしばしば未定義であり、参照メンバは、インスタンスが構築されるための値を必要とする展開時設定を有する可能性がある。したがって、参照メンバ（例えばｂｙＲｅｆｅｒｅｎｃｅメンバ）を展開するプロセスは、インスタンスに関する情報として、ランタイムが提供できるよりも多くの情報を必要とする可能性がある。
【００８８】
参照メンバ展開には、発見と呼ばれるプロセスが関係するが、これは、すでに展開されたインスタンスを見つけるのに使用されるプロセスである。発見は、通常は環境のオペレータによって開始されるアクションである。例えばインストール要求の間、ＣＲ展開エンジン６１２は、インスタンスがすでに存在するかどうかを判定し、存在する場合は何が存在するかを判定し、存在しない場合はそれを生成する。コントローラ６２０上のインスタンスマネージャ（ＩＭ）６３４が、ターゲットデバイス６２２上のインスタンスマネージャ６２６と通信して、発見プロセスを開始する。発見プロセスは、インスタンスに関するデータをターゲットデバイス６２２からコントローラ６２０に返す。
【００８９】
発見のプロセスは、構築または更新アクションの一部として参照定義メンバをポピュレートする。通常、発見をサポートするオブジェクトマネージャ（発見を実施もするインスタンスマネージャ）に関する参照メンバだけが、このプロセスに参与する。
【００９０】
新しいインスタンスが発見されたときは、インスタンス特有のキー値を使用して、このインスタンスがまだＳＤＭデータベース中に存在しないことをチェックする。新しいインスタンスであることがわかれば、発見されているメンバの定義に従ってインスタンスを分類する。インスタンスがメンバにマッチしない場合、または曖昧なマッチがある場合は、メンバ参照は空白のままにされ、インスタンスはオフラインおよび不完全としてマークされる。
【００９１】
関係展開は、構築されることになる定義インスタンスがすべてわかった後で、定義インスタンスを共にバインドする関係インスタンスを生成することを指す。定義インスタンスの破壊中である場合は、定義インスタンスを参照するすべての関係インスタンスを削除する。
【００９２】
関係を生成するには、メンバ空間を使用して、インスタンス間に存在すべき関係の構成を識別する。定義メンバが１よりも大きいカーディナリティを有する場合、関係のトポロジは基底関係定義から推論する。例えば、通信関係の場合は「自動記述」を実施することができ、ホスト関係の場合は、ホスティング関係に関連するアルゴリズムに基づいてホストを選択する。
【００９３】
フローステージの間、値フローエンジン６１４は、すべての関係インスタンスにわたってフローを評価する。値フローエンジン６１４は、改変されたパラメータフローの影響を受けたインスタンスについて、変更要求に更新要求を追加することができる。値フローエンジン６１４は、変更要求の結果として設定が更新されたインスタンスのセットを判定することにより、フローを評価する。これらのそれぞれにつき、修正された設定に依存する送出設定フローがあればそれを評価し、変更されたインスタンスのセットにターゲットノードを追加する。このプロセスは、そのセットが空になるまで、またはそのセットが循環を含むまで継続する。
【００９４】
フローステージの後、重複検出のプロセスを実施する。重複検出は、図６に示すエンジンのうちの１つ（例えば値フローエンジン６１４や制約チェックエンジン６１６）によって実施することもでき、あるいは、図６に示していない別のエンジンによって実施することもできる（例えば重複検出エンジンをＳＤＭランタイム６１０に含めることができる）。重複検出のプロセスは、展開されたインスタンスを、ＳＤＭデータ記憶域中にすでに存在するインスタンスと照合する。例えばこのプロセスは、別のアプリケーションが共有ファイルをインストールしたかどうかを検出する。すでに存在するインスタンスが検出されたときは、存在するインスタンスのバージョンに応じて、いくつかのアクションの１つを実施することができる。すなわち、インストールを失敗にすること、インスタンスを参照カウントすること、インスタンスをアップグレードすること、またはインストールを並行して実施することができる。
【００９５】
制約チェックエンジン６１６は、制約評価フェーズを実施する。このフェーズでは、モデル中のすべての制約をチェックして、変更要求が処理された後でもこれらがまだ有効となるかどうかを調べる。
【００９６】
制約チェックエンジン６１６が制約評価フェーズを終了した後には、完全なアクションリストが利用可能である。したがって、アクション順序付けエンジン６１８は、コンポーネント間の関係を使用して、有効な変更順序付けを判定することができる。この判定は、様々なアルゴリズムのいずれかを使用して行うことができる。
【００９７】
アクション順序付けエンジン６１８が順序付けを終了すると、マシン特有の順序付けされたアクションセットのサブセットを配信することによって展開を実施することができる。アクションがマシンによって順序付けされグループ化された後、アクションと、インスタンス情報を含むランタイムのＳＤＭ記憶域６０８の必要部分のコピーとが、ターゲットコンピューティングデバイス６２２に送られる。ＳＤＭは、一時的にターゲットデバイスの記憶キャッシュ６３８に記憶することができる。
【００９８】
ターゲットコンピューティングデバイスは、ＳＤＭランタイム６１０と通信するＳＤＭランタイムのターゲット部分６３６を備える。ターゲットコンピューティングデバイス６２２はエージェントも備えており、このエージェントは、実行エンジン６２４を備え、ターゲットデバイス上の適切なインスタンスマネージャ（ＩＭ）６２６と通信して、生成、更新、削除アクションなどの変更をターゲットに対して行うことができる。各アクションは、原子呼出しとしてインスタンスマネージャ６２６に送られる。インスタンスマネージャ６２６は、ステータスメッセージを返し、アクションによってはデータも返す（例えば発見の場合）。すべてのアクションがターゲット６２２上で完了すると、ターゲットのエージェントは、エラーがあればエラーと、ステータスとをコントローラ６２０に返す。次いでコントローラ６２０は、この情報を使用してランタイムのＳＤＭ記憶域６０８を更新する。
【００９９】
上で論じたように、変更は、影響を受ける関係に基づいて変更要求を配信可能部分に分解することによって行われる。すべての部分が完了すると（あるいは１つまたは複数の部分が失敗した後で）、ランタイム６１０中で結果が照合され、概要がオペレータに返される。失敗の場合は、すべてのアクションを「ロールバック」することができ、システムを変更開始前の状態に戻すことができる。
【０１００】
いくつかの実施形態では、上で論じた設計時妥当性検査の間、ＳＤＭコンパイラ６２８がＳＤＭファイルを受け取り、テストＣＲを生成し、ＳＤＭランタイムの展開エンジン、値フローエンジン、および制約チェックエンジンを通してテストＣＲを実行し、エラーがあればエラーを開発システムに返す。このプロセスにより、展開に向けたＳＤＭ妥当性検査が、設計時の間に開発者にもたらされる。
【０１０１】
ＳＤＭランタイム６１０および／またはコントローラ６２０への公開インタフェースは、オブジェクトモデル（ＡＰＩ）ライブラリを介する。このライブラリは、マネージドコードオブジェクトモデルであり、以下の項目の実施を可能にする。  
・ランタイム内でＳＤＭを管理する。−ＳＤＭファイルをランタイムにロードすることができる。ＳＤＭは不変であり、一度に１つロードされる（すなわち、ファイルの一部だけ（例えばＳＤＭファイルからの個々の定義、クラス、またはマッピングの１つ１つ）ではなく、１つのＳＤＭファイルをロードすることができる）。ＳＤＭをランタイムから削除することができ、ランタイム内のＳＤＭについてのＸＭＬ文書を作成することができる。  
・ランタイムによって知られるＳＤＵを管理する。  
・ＳＤＭ定義を管理する。−ＳＤＭ要素を見つけて検討する（ランタイムにロードされたＳＤＭから）。新しいＳＤＭをオーサリングするために提供される公開ＡＰＩはない（すなわちこれは、ＳＤＭの不変要素に対する読出し専用オブジェクトモデルである）。これは、ＳＤＭ、ＳＤＵ、識別、バージョン、クラス、定義、バインド／マッピング、およびバージョニングポリシーを含む。  
・ＳＤＭインスタンスを管理する。−コンポーネント、エンドポイント、リソース、および関係のインスタンスを見つけて検討する。インスタンス空間では、各インスタンスを、ＧＵＩＤ、安定パス、またはアレイベースのパスで識別することができる。パスはストリングであり、相対的とすることができる。相対パスを含めたこれらの識別子により、変更要求文書などの文書中でインスタンスを見つけて参照することができる。  
・インスタンスを操作する。−生成、トポロジ変更、アップグレード、設定変更、削除を含めて、ＳＤＭインスタンスに対して変更を行う。インスタンス変更は変更要求の範囲内で行われ、変更要求は、エラーまたは制約違反があれば要求が完全に失敗するように、更新の原子単位を提供する。インスタンス要求はまた、インスタンスが一時的にホストへのバインドなしでも存在できるようにする。というのは、要求がコミットされるときはインスタンスはホストを有さなければならないからである。また、単一のコンポーネントのインストールまたは設定に影響を与える多くの操作が行われることを可能にし、単一の更新がコンポーネント上で行われるように、インストールまたは設定の更新がコミットまで延期されるようにする。変更要求のコミット前またはコミット時にＳＤＭモデルチェックを実施し、モデル違反または制約違反があればコミットは失敗する。  
・変更要求をロードする。−変更要求は、インスタンス空間操作のセットを提示する文書、例えばＸＭＬファイルである。この文書は、相対パスを利用して、アプリケーションインスタンスを生成または削除するための再使用可能「スクリプト」となることができる。  
・変更要求を見つけて検討する。−インストール／更新タスクおよびすべてのエラー情報を得ること、ならびに要求の影響を受けるコンポーネントのインストール／更新を再試行することを含む。  
・データベース中の変更要求から変更要求文書を生成する。このような文書はいくぶん移植性がある。  
・進行状況、ログ、または更新されたステータスなど、変更要求タスクに関するイベントの通知に申し込む。これらのイベント加入の存続期間は、クライアントライブラリをロードしたプロセスの存続期間によって制限される（すなわちこれらは定期ＣＬＲイベントである）。
【０１０２】
ＳＤＭランタイムエンジンは、ＳＤＭモデル、およびＡＰＩによって表面化された関数に対して、推論を実施する。ライブラリは、ＳＤＭをロードする、コンポーネントインスタンスを生成する、ＳＤＭ全体を得る（ＳＤＭエンティティを検討するため）など、かなり粗な呼出しを使用してウェブサービスとしてランタイムエンジンに通信する。このウェブサービスに関する多くのパラメータのフォーマットは、ＳＤＭファイルの場合と同じスキーマを有するＸＭＬである。エンジンはまた、許可に対するチェックも実施することができる。
【０１０３】
コントローラ６２０は、インスタンスマネージャ（ＩＭ）を利用することができ、ＩＭは、モデル中の任意の定義または関係に関連付けることができる。ＩＭは、以下の役割の１つまたは複数を実施することができる。  
・インスタンスの展開をサポートする。  
・インスタンスが展開された後のインスタンスの妥当性検査をサポートする(監査)。 
・ランタイムを介して展開されたのではない展開済みインスタンスの発見をサポートする。  
・設定値のフローをサポートする。  
・制約の評価をサポートする。  
・変更要求の展開をサポートする。  
・ＡＰＩを介してインスタンスをＣＬＲクラスとしてユーザに提示することをサポートする。
【０１０４】
展開のために、コントローラ６２０上のインスタンスマネージャ（ＩＭ）プラグインがクラスホスト関係に関連付けられるが、このプラグインは、開発システム中で使用される、クラスに関する設計経験を提供し、ＳＤＵ６０４中および設定スキーマ中の関連バイナリを作成するプラグインとは別である。インスタンスマネージャは、インスタンスマネージャインタフェースを実装するかまたは抽象クラスから継承するＣＬＲクラスとして（例えばｄｌｌアセンブリ中で）ＳＤＭランタイム６１０に供給される。ＳＤＭインスタンスマネージャは、インスタンスマネージャ（ＩＭ）プラグインとも呼ばれ、以下の機能をコントローラ６２０に提供する。  
・コンポーネントインスタンスをそれらのホストにインストール、アンインストール、または再インストールするためのファイルおよびコマンド（タスク）を生成する。−変更要求の結果、新しいコンポーネントインスタンス、またはコンポーネントインスタンスの削除、またはアンインストールおよび再インストールが必要なコンポーネント変更が生じるとき、インスタンスマネージャは、ＳＤＵ６０４中のインスタンス、ホストインスタンス、コンポーネントに関連する定義、これらの定義に関連するバイナリの設定を利用し、手動実行の準備または展開エンジンを介したディスパッチの準備ができたターゲットサーバ上でインストールまたはアンインストールを実施するのに必要なファイルおよびコマンドを作成する。  
・コンポーネントインスタンスの設定が変化したとき、またはそのエンドポイントの１つからのビューが変化したとき（例えば通信関係トポロジが変化したせいで、または見えるエンドポイントが設定変更を有するせいで）、コンポーネントインスタンスを更新するためのファイルおよびコマンド（例えばタスク）を生成する。  
・コンポーネントインスタンスのエンドポイント上で見えるエンドポイントインスタンスを、コンポーネントインスタンス上の設定にマッピングする。−ＳＤＭ中で、コンポーネントインスタンスは、何らかの通信関係トポロジの結果として他のエンドポイントインスタンスが見えるエンドポイントインスタンスを有する。他のエンドポイントインスタンスの詳細は、コンポーネントインスタンスがランタイム時にフェッチすることのできる、したがって通常はそれにバインドすることのできる設定にマッピングされる。例えば、ウェブサイトがデータベースクライアントエンドポイントを有し、したがって通信関係はデータベースを使用して確立することができる。正しく確立されたとき、そのデータベースクライアントエンドポイントは、このサーバエンドポイント上の単一のデータベースサーバエンドポイントインスタンスおよび設定を見ることができる。この情報をインスタンスマネージャが使用して、サーバに関する接続ストリングを、クライアントエンドポイントという名前で構成ファイル中に配置する。この結果、コードは単に、データベースに関する接続ストリングをその構成設定から読む。  
・コンポーネントインスタンスを監査するためのファイルおよびコマンド（タスク）を生成する。−監査は、存在および正しい設定を確認する。これはホストインスタンス設定にも適用することができる。  
・任意のタスクについてステータスを報告する。−ＩＭは、取り込まれた出力の一部または全部を変換し、タスクのステータスを成功、失敗、または不完全として提供し、任意選択で、不完全に関する進行状況（％または最終応答）、失敗に関する詳細（エラーメッセージ）、および任意のステータスに関する人間に読めるログを提供する。インスタンスマネージャに戻ってタスクの出力を解釈することにより、インスタンスマネージャは、診断に十分なログを作成してそれを人間に読めるように維持しなければならないのではなく、そのタスクをログ構造化情報（例えばＸＭＬ、さらにはＳＯＡＰ（Simple Object Access Protocol））にすることが自由にできる。  
・インスタンスマネージャはまた、ホストとそれらのゲストとの間の制約チェックを実施するコードを提供することもできる。インストーラは、共通の制約言語、例えばＸＭＬ、ＸＰａｔｈ、ＸＱｕｅｒｙに基づく言語を使用することができる。
【０１０５】
レイヤ化 
ＳＤＭモデルは、アプリケーション開発者と、ソフトウェアインフラストラクチャ設計者と、データセンタ構築者との間で関心が分離されるようにする。これらの各グループは、特定のサービスに焦点を合わせ、異なる関心のセットを有する。例えば、開発者は主に、ＳＱＬ、ＩＩＳ、ＣＬＲなど、開発者が利用するホストの間の構成および接続性に関心を持つ。ホスト構成の設計者は主に、ネットワークトポロジおよびＯＳ構成に関心を持つ。ネットワークトポロジ、ＯＳ構成、記憶マッピングを開発する構築者は主に、データセンタに存在するハードウェアに関心を持つ。
【０１０６】
ＳＤＭは、システムを横軸と縦軸にわたって機能構成することを可能にする。横軸に沿った構成は、システムおよびサブシステムによって行う。縦軸に沿った構成は、「レイヤ」によって行う。アプリケーション、サービス、ネットワークトポロジ、およびハードウェアは、分散システムにおける役割を果たすが、通常は、独立して定義され、異なるチームまたは組織によって所有されている。レイヤ化は、コンポーネントがホストに対して制約セットを定義することによって、またその逆によって達成される。
【０１０７】
この関心の分離をサポートするために、ＳＤＭは、レイヤ化の概念を呈示する。レイヤ化は、アプリケーションが依存するサービスをアプリケーションの包含構造の一部として宣言せずに、ホスティング関係を用いてアプリケーションをサービスにバインドすることを指す。レイヤ化により、異なる個人が異なる時に異なるレベルでシステムを開発することができる。
【０１０８】
図７に、例示的なレイヤ化設定を示す。図７には、４つのレイヤすなわちレイヤ７０２、レイヤ７０４、レイヤ７０６、レイヤ７０８が示されている。４つのレイヤが図７に示されているが、実際のレイヤの数は様々とすることができ、４つよりも多いか少ない可能性もある。さらに、種々のレイヤの内容も、実施形態に応じて様々とすることができる。図７からわかるように、種々のレイヤは他のレイヤの上および／または下に位置する（例えばレイヤ７０６は、レイヤ７０４の上にあるがレイヤ７０８の下にある）。
【０１０９】
レイヤ内の種々のシステムおよびサブシステムが、相互に対話することができ、また、異なるレイヤのシステムおよびサブシステムと対話することができる。例えばレイヤ７０８中のサブシステム７１０は、レイヤ７０８中のサブシステム７１２、ならびにレイヤ７０６中のサブシステム７１４と対話することができる。さらに、各レイヤは、より高い次のレイヤに対する環境と見なすことができる。例えばレイヤ７０６は、レイヤ７０８中のシステムおよびサブシステムに対する環境であり、レイヤ７０４は、レイヤ７０６中のシステムおよびサブシステムに対する環境である。各レイヤ７０２、７０４、７０６、７０８は、それ自体の関連するＳＤＭ文書を有する。
【０１１０】
種々のレイヤ７０２、７０４、７０６、７０８は、異なる内容を表すものとすることができる。いくつかの実施形態では、レイヤ７０２はハードウェアレイヤであり、レイヤ７０４はネットワークトポロジおよびオペレーティングシステムレイヤであり、レイヤ７０６はアプリケーションホストレイヤであり、レイヤ７０８はアプリケーションレイヤである。ハードウェアレイヤは、レイヤ化されたシステムがその上に構築される物理デバイス（例えばコンピューティングデバイス）を表す（例えば図１のデバイス１０２）。ネットワークトポロジおよびオペレーティングシステムレイヤは、コンピューティングデバイスのネットワークトポロジ（例えば図１のネットワーク１００の設定）、ならびにこれらのコンピューティングデバイス上にインストールされるオペレーティングシステムを表す。アプリケーションホストレイヤは、コンピューティングデバイスにインストールされた、他のアプリケーションをホストすることのできるアプリケーションを表す（例えばＳＱＬ（Structured Query Language）サーバ、ＩＩＳ（Internet information service）（商標）など）。アプリケーションレイヤは、コンピューティングデバイスにインストールされた、他のアプリケーションをホストしないアプリケーションを表す（例えばゲームなどの娯楽アプリケーション、ワードプロセッサなどの生産性アプリケーション、電子百科辞典などの参照アプリケーション、ウェブサービスや財務分析に使用できる分散アプリケーションなど）。
【０１１１】
例示的なＳＤＭ実装形態 
以下の解説では、ＳＤＭの要素を定義するスキーマの一実施形態について述べる。
【０１１２】
１  定義
【０１１３】
【表１】
2011070707.tif 000003
【０１１４】
２  アーキテクチャの概観
システム定義モデル（ＳＤＭ）は、分散システム（モデル化システム）中のコンポーネントの構成、対話、および変更の記述をサポートするように設計される。
【０１１５】
ＳＤＭは、オブジェクト関係モデルに基づく。オブジェクトを使用して、システム中に存在するエンティティを記述し、関係を使用して、それらの間のリンクを識別する。ＳＤＭではさらに、ＳＤＭにとって重要なセマンティクスを取り込むようにオブジェクトおよび関係が改良される。具体的には、オブジェクトはシステム、エンドポイント、リソースに分けられ、関係は通信、包含、ホスティング、委任、参照に分けられる。
【０１１６】
抽象定義を使用して、システムの各部分の共通範疇化を提供する。これにより、幅広いアプリケーションに対するツールサポートが可能になり、設計時の型チェックのための基盤がもたらされる。抽象定義のセットは、システム設計のための包括的な基盤を提供すると考えられ、これらは時の経過に伴ってゆっくり変化すると考えられる。
【０１１７】
実際のアプリケーションまたはデータセンタの設計の各部分を表す具象オブジェクト定義を構築する。抽象オブジェクト定義を利用して、具象型のメンバとそのプロパティの設定値とを定義する実装を提供する。次いで、これらの定義の集合からシステムを構築する。
【０１１８】
制約を使用して、インスタンスが参与することのできる許容される関係のセットに対する制限をモデル化する。制約は、関係に関与するオブジェクトの構成に応じたきめ細かい要件を取り込むのに使用する。例えば、制約を使用して、通信プロトコルの両端の参与者が互換性のあるセキュリティ設定を使用していることを妥当性検査することができる。
【０１１９】
ターゲットシステムに対する変更を実施するために、ＳＤＭは、変更要求と呼ばれる、必要とされる変更の宣言記述を使用する。ＳＤＭは、ＳＤＭ実行モデルの一部として変更要求を展開、妥当性検査、および実行するのに使用されるプロセスを定義する。
【０１２０】
インスタンス空間が、管理されるアプリケーションの所望状態と現在状態の両方を取り込む。インスタンス空間中の変更は、追跡され、その変更を開始した変更要求に関連付けられる。
【０１２１】
後続のＵＭＬ（unified modeling language）図は、ＳＤＭモデル中のオブジェクト間の広範な対話を取り込むものである。簡単にするために、これらの対話のいくつかは基底型の間で定義されているが、実際の対話は派生型の間に存在し、その結果、より特殊化されている。例えば、通信関係は抽象エンドポイント定義だけを参照する場合がある。
【０１２２】
ＳＤＭ文書は、文書と、文書中の定義に対するマネージャと、他の文書を参照するインポートステートメントと、定義セットとを記述する情報を含む。
【０１２３】
図８に例示的な文書を示す。
【０１２４】
図９に示すように、すべてのＳＤＭ定義は、共通基底定義から派生し、メンバを含むことができる。定義とメンバの間の関係は、後続の図に示すものよりも複雑にすることもできる。
【０１２５】
図１０に示すように、メンバは、それらが参照する定義の種類によって分けられる。
【０１２６】
設定宣言は、設定定義を参照する。図１１に示すように、設定値および値リストが、設定に関する値を提供する。
【０１２７】
２．１  ＳＤＭアプリケーションのライフサイクル
図１２に、いくつかの実施形態による例示的なＳＤＭアプリケーションのライフサイクルを示す。
【０１２８】
アプリケーションをＶｉｓｕａｌ  Ｓｔｕｄｉｏ（登録商標）環境内で設計および実装する（ブロック１２０２）。開発者は、コンポーネントを実装し、次いでそれらを複合コンポーネント内で結合する。アプリケーションはＳＤＭファイル内に記述する。開発者のアプリケーションが特定のデータセンタ内で展開されることを検証するために、開発者はアプリケーションを、やはりＳＤＭファイル中に記述されたデータセンタ表現にバインドする（ブロック１２０４）。この表現は、開発者のアプリケーションコンポーネントのホストに関する定義と、開発者のアプリケーションの構成に対する制約とを含む。バインドが失敗した場合は、開発者はアプリケーション設計を修正することができる。
【０１２９】
開発者が自分のアプリケーションに満足すれば、開発者はアプリケーションに署名して公表することができ、したがって、今やアプリケーションには厳密名（strong name）およびバージョンが関連付けられている（ブロック１２０６）。アプリケーションの公表された形は、ソフトウェア配信ユニット（ＳＤＵ）と呼ばれる。オペレータは、開発者からのＳＤＵを採用し、アプリケーションをＳＤＭランタイムにロードする（ブロック１２０８）。アプリケーションをロードするプロセスの間、オペレータは、アプリケーションをバインドしたいと思うデータセンタのモデルを選択する。オペレータは、アプリケーションを展開することを決定すると、展開時パラメータをアプリケーションに供給し、アプリケーションのスケールを判定する（ブロック１２１０）。これは変更要求を使用して行う。
【０１３０】
アプリケーションを展開すると、オペレータはランタイムと対話して、アプリケーションの構成およびアプリケーションの各部分に関する設定を判定することができる（ブロック１２１２）。ランタイムはまた、アプリケーションの実際の構成が、ランタイム内に記録されている所望の構成とマッチすることを検証することもできる。オペレータは、変更要求をサブミットすることにより、展開したアプリケーションを削除することができる（ブロック１２１４）。オペレータはまた、サービスパックの削除など、実行中のアプリケーションに加えられた個々の変更をロールバックすることもできる。ブロック１２１６で、展開されたアプリケーションの一部をウェブフロントエンドなどに対して追加または削除することにより、実行中のアプリケーションの構成を変更することができる。アプリケーションはまた、１つまたは複数のアプリケーションコンポーネントのより新しいバージョンをインストールすることによってアップグレードすることもできる。
【０１３１】
２．２  抽象オブジェクト定義および関係定義
抽象オブジェクト定義は、設計時にアプリケーション構成をチェックしてからランタイム時にアプリケーションを展開および管理するために必要な構成単位を定義する。これらの構成単位は、モデル化システム中に存在するエンティティを表す。例えば、抽象オブジェクト定義を使用して、ファイルおよびディレクトリ、ウェブサーバ内部の構成、またはＳＱＬサーバ内部のデータベースがモデル化される。
【０１３２】
抽象関係定義は、抽象オブジェクト定義間で行われる可能性のある対話をモデル化するのに使用する。関係は、バイナリおよび有向であり、関係の発現に参与するインスタンスを定義するオブジェクト定義を識別する。関係は、オブジェクト間の包含、構築、通信のリンクをモデル化できるようにオブジェクトを共に結ぶ方法を提供する。
【０１３３】
次いで、オブジェクトが制約を使用して、オブジェクトの参与する関係を制約し、関係が制約を使用して、リンクできるオブジェクトを制約する。これらの制約は、関係への参与者の定義と設定の両方をターゲットにすることができる。これにより制約は、関係への参与者を特定の定義から派生するインスタンスに限定することができ、また、インスタンスが特定の範囲に含まれる設定値を有することを必要とすることができる。
【０１３４】
オブジェクト定義は、システム、エンドポイント、リソースという３つのカテゴリに分けられる。
【０１３５】
抽象システム定義は、アプリケーションの自己完結型かつ独立展開可能な部分を記述するのに使用する。これらの定義は、プロセスおよびマシンの境界を横断することのできる明確に定義された通信チャネルを介して対話するアプリケーション部分を表す。
【０１３６】
抽象エンドポイント定義は、システムが開示する（expose）ことのできる通信エンドポイントを記述するのに使用する。これらを使用して、設計時にシステム接続性を検証するためおよびランタイム時に接続を可能にするためにシステムが意識すべきすべての形の通信をモデル化する。
【０１３７】
抽象リソース定義は、システム内に含まれる挙動を記述する。リソース定義は、他のリソース定義への強力な従属性を有する場合がある。これらの従属性には、特定のインストール順序を必要とすることや、公式に文書化されていない通信機構を介したランタイム対話を開始することを含めることができる。
【０１３８】
すべての抽象オブジェクト定義は、設定を開示する能力を共有する。これらの設定は、名前と値の単純な対であり、ＸＭＬスキーマを使用して設定の型を定義する。設定は動的でも静的でもよいが、静的の場合は、展開プロセスの間だけ設定することができ、動的の場合は、展開後に変更することができる。実行中のシステムに設定値を適用することを担うコードは、ＳＤＭランタイム中でホストされる。
【０１３９】
ＳＤＭは、抽象オブジェクト定義を越えた継承をサポートする。派生した定義は、その親によって開示されたプロパティを拡張することができ、その親のプロパティに関する値を設定することができる。派生した定義は、その親を参与者として識別する関係のいずれにも参与することができる。
【０１４０】
関係定義は、通信、包含、委任、ホスティング、参照という５つのカテゴリに分けられる。
【０１４１】
通信関係は、抽象エンドポイント定義間の可能性ある通信対話を取り込むのに使用する。通信関係があることは、識別された定義のエンドポイントを開示しているシステムが通信することが可能かもしれないことを示す。実際のリンク確立は、エンドポイントおよびエンドポイントの開示（exposure）に対する制約を受ける。
【０１４２】
包含関係は、抽象オブジェクト定義が別の抽象オブジェクト定義のメンバを含むことができることを記述する。より具体的には、２つの抽象オブジェクト定義ＡとＢの間の包含関係では、Ａを実装する具象オブジェクト定義が、Ｂを実装する具象オブジェクト定義のメンバを含むことができる。
【０１４３】
包含を使用して、開発者がアプリケーションを構築するときに生じる自然なネスト構造がモデル化される。メンバオブジェクトを含めることにより、親は、含まれたオブジェクトの存続期間および可視性を制御することができる。ランタイム空間中のすべてのオブジェクトインスタンスは、他のオブジェクトインスタンスのメンバとして存在し、完全に接続されたインスタンスセットを形成する。したがって、包含関係のセットは、インスタンス空間で生じる許容される包含パターンを記述する。
【０１４４】
委任関係は、含まれるオブジェクトメンバを選択的に開示するのに使用する。具体的には、委任を使用して、システム定義からのエンドポイントメンバを開示する。サブシステムからエンドポイントを委任することにより、外側のシステムは、特定のプロトコル上で、プロトコルの奥にある実装を開示することなく通信する能力を呈する。
【０１４５】
ホスティング関係および参照関係は、従属関係の２つの形である。ホスティング関係は、具象オブジェクトのインスタンスを生成できるようになる前に存在すべき抽象オブジェクトの間の主要な従属性を記述する。あらゆるインスタンスは、ちょうど１つのホスティング関係にゲストとして参与すべきであり、この結果、ホスティング関係はまた、完全に接続されたツリーをインスタンス空間にわたって形成する。参照関係は、パラメータフローおよび構築順序付けに使用することのできる追加の従属性を取り込む。
【０１４６】
２．３  具象オブジェクト定義および関係定義
抽象オブジェクト定義から具象オブジェクト定義を構築し、抽象関係定義から具象関係定義を構築する。
【０１４７】
抽象オブジェクト定義と抽象関係定義の組合せは、ターゲットシステムをモデル化するためのスキーマを定義する。具象オブジェクト定義の役割は、抽象定義空間のサブセットを使用して、１つまたは複数の抽象定義に基づく再使用可能な構成を生み出すことである。単純な類比として、抽象定義空間は、データベースに関するスキーマに例えることができる。この場合、具象オブジェクト定義は、データベース中の行のセットのための再使用可能テンプレートを表すことになる。行は、具象オブジェクトのインスタンスが生成されたときだけデータベース中に生成される。設計時妥当性検査を行うために、データベース中の行をスキーマの制約（例えば外部キーなど）に対して妥当性検査するのと同じようにして、具象オブジェクト定義を抽象定義空間に対して妥当性検査することができる。
【０１４８】
各具象オブジェクト定義は、特定の抽象オブジェクト定義に対する実装を提供する。実装は、設定スキーマに対する拡張と、設定に関する値と、オブジェクトメンバ、関係メンバ、制約メンバ、フローメンバに関する宣言とを含む。具象オブジェクトの挙動は、抽象オブジェクトの定義に従う。すなわち、抽象システム定義が具象システム定義になり、抽象エンドポイント定義が具象エンドポイント定義になり、抽象リソース定義が具象リソース定義になる。
【０１４９】
各具象関係定義は、特定の抽象関係定義に対する実装を提供する。実装は、設定宣言および値と、同じ関係カテゴリ（ホスティング、包含、通信など）のネストされたメンバと、関係に参与することのできる型に対する制約とを含むことができる。
【０１５０】
具象ホスティング関係は、ある具象オブジェクトのメンバを別の具象オブジェクト上にマッピングすることを定義するのに使用する。例えば、具象ホスティング関係を使用して、ウェブアプリケーションとそれが展開されることになるＩＩＳホストとの間のバインドを識別することができる。所与の型に対して複数の具象ホスティング関係が存在することができ、これにより開発者は、特定のトポロジに対して種々の展開構成を定義することができる。
【０１５１】
２．４  メンバ
具象型は、他の具象または抽象オブジェクトのメンバを宣言することができる。これらをオブジェクトメンバと呼ぶ。この場合、これらのメンバは、オブジェクトメンバ間の関係を定義する関係メンバから参照される。
【０１５２】
オブジェクトメンバは、特定のオブジェクト定義のインスタンスを生成するのに使用される。設定フローを使用して、オブジェクトに関する値を提供することができる。オブジェクトメンバを宣言するとき、ユーザは、オブジェクトメンバが、外側のシステムが生成されるのと同時に生成されるか（値セマンティクス）、あるいはいくらか後で行われる新しい明示的動作によって生成されるか（参照セマンティクス）を決定することができる。
【０１５３】
関係メンバは、オブジェクトメンバが生成されたときにそれらが参与することになる関係を定義する。オブジェクトメンバがその親に含まれる場合は、包含関係メンバを型メンバと外側の型との間で宣言する。オブジェクトメンバが委任される場合は、委任関係メンバを、オブジェクトメンバとネストされたオブジェクトメンバとの間で定義する。通信関係メンバは、オブジェクトメンバ上のエンドポイント間で宣言することができ、従属関係メンバ（参照およびホスティング）は、オブジェクトメンバまたはネストされたオブジェクトメンバ間で宣言することができる。
【０１５４】
関係制約は、特定のオブジェクトが参与を望む関係のセットを限定するのに使用する。これらは、特定の関係に対する制約、および関係の他方の端の参与者に対する制約を識別する。
【０１５５】
２．５  インスタンス空間
ＳＤＭランタイムに記憶されているインスタンス空間は、モデル化システムの現在状態を反映する。ランタイムは、生成されたインスタンスと、これらのインスタンス間の関係との完全な記録を含む。各インスタンスにはバージョン履歴が関連し、バージョン履歴中では、各バージョンが変更要求にリンクされている。
【０１５６】
新しいインスタンスを生成するプロセスは、変更要求によって開始される。変更要求は、既存のインスタンスの特定メンバに関連する型および関係に対する、生成、更新、削除要求のセットを定義する。ルートは特別なケースである。
【０１５７】
変更要求は、ランタイムによって展開され、すべての制約に対して検証されてから構築される。展開プロセスでは、オブジェクトの構築要求の一部として暗黙的に構築される、オブジェクトに含まれるオブジェクトインスタンスおよび関係インスタンスを識別し、次いで設定フローをすべての関係にわたって評価する。検証ステップでは、必要な関係がすべて存在すること、および関係がすべての制約を満たすことをチェックする。最後に構築プロセスでは、各インスタンスの展開、更新、または削除にわたる適切な順序付けを判定し、次いで、適切なアクションが実施されるように、各インスタンスを正しいシーケンスでインスタンスマネージャに渡す。
【０１５８】
２．６  レイヤ化
ＳＤＭモデルの目標は、アプリケーション開発者と、ソフトウェアインフラストラクチャ設計者と、データセンタ構築者との間で、関心が分離されるようにすることである。これらの各グループは、特定のサービスに焦点を合わせ、異なる従属性セットを有する。
【０１５９】
例えば、開発者は主に、ＳＱＬ、ＩＩＳ、ＣＬＲなど、開発者が依存するホストの間の構成および接続性を気にかける。ホスト構成の設計者は、ネットワークトポロジおよびＯＳ（operating system）構成を気にかけ、ネットワークトポロジ、ＯＳ構成、記憶マッピングを開発する構築者は、データセンタに存在するハードウェアについて知る必要がある。
【０１６０】
この関心の分離をサポートするために、ＳＤＭは、レイヤ化の概念を呈示する。レイヤ化は、アプリケーションが依存するサービスをアプリケーションの包含構造の一部として宣言せずに、ホスティング関係を用いてアプリケーションをサービスにバインドするものである。
【０１６１】
ＳＤＭモデルの一部として、以下の４つのレイヤが識別される。  
アプリケーションレイヤ  
・アプリケーションレイヤは、制約されたコンテキストでアプリケーションを構築することをサポートする。コンテキストは、ホストレイヤで定義されるホストの構成によって定義される。  
・アプリケーションレイヤ中のシステム定義の例としては、ウェブサービス、データベース、およびＢｉｚＴａｌｋ（商標）スケジュールが挙げられる。
【０１６２】
ホストレイヤ
・ソフトウェアコンポーネントからデータセンタを構築する。コンポーネント間の接続を構成する。これらのコンポーネントのいくつかは、アプリケーションレイヤのためのホストとして働く。  
・このレイヤ中のシステム定義の例−ＩＩＳ（商標）、ＳＱＬ、ＡＤ、ＥＸＣＨＡＮＧＥ、ＤＮＳ（Domain Name System）、ＢｉｚＴａｌｋ（商標）
【０１６３】
ネットワーク／ＯＳ／ストレージレイヤ
・データセンタネットワークおよびプラットフォームを構築する。ネットワークセキュリティモデルおよびオペレーティングシステムプラットフォーム構成を構成する。オペレーティングシステム構成にストレージを追加する。  
・このレイヤ中のシステム定義の例−ＶＬＡＮ、Ｗｉｎｄｏｗｓ（登録商標）、Ｆｉｌｔｅｒ、Ｓｔｏｒａｇｅ
【０１６４】
ハードウェアレイヤ
ハードウェアレイヤは、データセンタに存在するマシンのタイプ、およびこれらのマシン間に存在する物理接続を識別する。
【０１６５】
図１３に、レイヤ４ウェブアプリケーションをレイヤ３ウェブサーバホストにマッピングする例を示す。各レイヤの外側のボックスはシステムを表し、境界上のボックスはエンドポイントを表し、内側のボックスはリソースを表す。これらの各要素を、ホスティング関係を介して下のレイヤにあるホストにマッピングする。
【０１６６】
システムに必要な関係を満たすために、マッチする機能を有するホストシステムにこのシステムをバインドする。このプロセスを配置（ｐｌａｃｅｍｅｎｔ）と呼ぶ。設計時、可能な配置を表す具象ホスティング関係を構築する。展開時、具象ホスティング関係のインスタンスをインスタンス化して、ゲストシステムインスタンスをホストシステムインスタンスにバインドする。
【０１６７】
２．７  モデル評価
ＳＤＭモデルには、分散システムに対する変更を管理するための明確に定義されたプロセスが関連付けられる。
【０１６８】
各変更は、いくつかの処理ステップを経た宣言変更要求によって進められ、その後、要求中の動作が配信され、次いでターゲットシステムに対して実行される。
【０１６９】
３  実装の詳細
３．１  名前付け
ＳＤＭ中には、オブジェクトを識別するための厳密な名前付けシステムが必要な場所がいくつかある。以下の名前付けシステムによれば、型の生成者は、開発者が元々公表した定義と同じ定義であることを定義のユーザが確信できるような形で、定義に署名することができる。
【０１７０】
以下のヘッダは、ＳＤＭ名前空間における識別子の例である。
【０１７１】
【数１】
2011070707.tif 000004
【０１７２】
別の名前空間中の型を参照するには、その名前空間をインポートする必要がある。 
<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>
【０１７６】
【表２】
2011070707.tif 000005
【０１７７】
基底識別を使用して、既存の識別を参照することができ、あるいは、署名および公開鍵と共に、新しい厳密識別を生成することができる。文書には秘密鍵を使用して署名することになり、それにより文書のユーザは、公開鍵を使用してその内容を検証することができる。
【０１７８】
【数２】
2011070707.tif 000006
【０１７９】
【表３】
2011070707.tif 000007
【０１８０】
公開鍵トークンは、公開鍵／秘密鍵の対の公開部分を識別する１６文字の１６進ストリングである。これは公開鍵ではなく、単に公開鍵の６４ビットハッシュである。
【０１８１】
<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>
【０１８２】
３．１．２  バージョン
ファイルバージョンは、Ｎ．Ｎ．Ｎ．Ｎの形をとる４部分の数で定義され、０≦Ｎ＜６５５３５である。慣例的に、この数はメジャー．マイナー．ビルド．リビジョンを表す。
【０１８３】
【数３】
2011070707.tif 000008
【０１８４】
３．１．３  簡易名
簡易名は、英数字および限られた句読点からなる。名前は数字以外の文字で始まらなければならない。
【０１８５】
【数４】
2011070707.tif 000009
【０１８６】
識別子についてはＣ＃定義に準拠する予定である。適切な章（２．４．２）を以下に挿入してある。仕様は以下で見ることができる。  
http://devdiv/SpecTool/Documents/Whidbey/VCSharp/Formal%20Language%20Specification/CSharp%20Language%20Specification.doc
ＳＤＭモデルでは、頭に「＠」の付く名前はサポートされないことに留意されたい。
【０１８７】
【表４−１】
2011070707.tif 000010
【０１８８】
【表４−２】
2011070707.tif 000011
【０１８９】
【表４−３】
2011070707.tif 000012
【０１９０】
３．１．４  予約済みの名前
以下は、ユーザがＳＤＭモデル中のオブジェクトの名前を生成するときに使用できない予約済みの名前のリストである。 
一定のコンテキスト内で、いくつかの名前が予約されている。
【０１９１】
【表５】
2011070707.tif 000013
【０１９２】
以下の名前は、ＣＬＲとの統合により予約されている。
【０１９３】
【表６】
2011070707.tif 000014
【０１９４】
３．１．５  他の名前空間の参照
他の名前空間を現在の名前空間にインポートしてからエイリアスを名前空間に関連付けることにより、名前空間が他の名前空間を参照することを可能である。インポートされた名前空間は、名前、バージョン、および公開鍵トークンで参照される。バージョニングについては３．１６章で述べる。
【０１９５】
【数５】
2011070707.tif 000015
【０１９６】
【表７】
2011070707.tif 000016
【０１９７】
３．１．６  修飾パス
修飾パスはこの場合、現在の名前空間中またはエイリアシングされた名前空間中で定義される定義とマネージャとのいずれかを指す名前である。 
[<alias>:] <simpleName> (.<simpleName>)* 
エイリアスはインポートステートメント中で定義される。以下の簡易名は、型を識別し、パスの場合はネストされた型を識別する。
【０１９８】
【数６】
2011070707.tif 000017
【０１９９】
３．１．７  定義およびメンバパス
パスは、メンバまたは設定を識別する一連の名前である。パスは、パスに関連するオブジェクトまたは関係によって定義される、周知の名前またはメンバ名で始まるべきである。
【０２００】
【数７】
2011070707.tif 000018
【０２０１】
３．１．８  インスタンスパス
インスタンス空間中のパスはＸＰａｔｈに基づく。ＸＰａｔｈ中の要素名はメンバ名に対応し、ＸＰａｔｈ中の属性は設定に対応する。
【０２０２】
３．１．９  名前解決
エイリアスで始まらない名前は、完全修飾されていない。このことは、これらが評価される範囲が、得られるバインドを変化させる可能性があることを意味する。この一例は、ネストされた定義である。ネストされた定義名を解決するとき、ローカル範囲中の定義は、より広い範囲内の定義を隠蔽する。
【０２０３】
３．２  設定
すべての定義は、設定宣言を開示することができる。これらの設定は、抽象定義から具象定義を生成するとき、または定義を別の定義内のメンバから参照するときに、提供できる値を記述するのに使用することができる。
【０２０４】
設定を定義するには、まずＸＳＤを使用して設定の定義を定義する必要がある。
【０２０５】
【数８】
2011070707.tif 000019
【０２０６】
次いで、この定義を使用する設定であって、設定の挙動を定義するための属性セットを含む設定を宣言することができる。  
<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>
【０２１０】
【表８】
2011070707.tif 000020
【０２１１】
設定は、以下の３つの分離可能な名前空間から解決可能であるべきである。
ａ）ＳＤＭ名前空間−システム、リソース、エンドポイント、関係、制約、またはフロー型内の設定型を指すとき。  
ｂ）ＣＬＲ名前空間−ＣＬＲ内の強く型付けされたクラスを使用する設定を指すとき、および設定型が他の設定型上に構築されるとき。  
ｃ）ＸＳＤ名前空間−設定型が他の設定型を使用して構築されるとき。
【０２１２】
これが機能するためには、設定を宣言する方法に対していくつかの制約を課すべきである。  
ａ）すべての設定は、ＣＬＲ、ＳＤＭ、およびＸＳＤの各名前空間内で同じグループにあるべきである。すなわち、２つの設定が１つの名前空間で共にある場合、これらは３つの名前空間すべてで共にあるべきである。  
ｂ）ＸＳＤスキーマ定義内のインポートされた名前空間は、ＳＤＭファイル中のインポートされた名前空間、および関連するヘルパアセンブリ中のインポートされた名前空間とマッチすべきである。  
ｃ）ＸＳＤ名前空間を除いては、ＸＳＤスキーマ中のすべてのインポートされた名前空間は、ＳＤＭファイル内で定義されるべきである。
【０２１３】
インポートされたＳＤＭ文書からのＸＳＤ型へは、ＱＮａｍｅを使用してアクセス可能である。  
<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>
【０２１５】
３．２．２．  組込み単純データ型
ＳＤＭは、ＸＳＤとＣ＃の名前空間の共通部分である限られた組込みデータ型のセットをサポートする。これらの型は、ＳＤＭランタイムによってネイティブにサポートされ、以下の表に定義される。これらの型に加えて、ユーザは、ＸＳＤとＣＬＳ型間のユーザ自身のマッピングを自由に構築して使用することができる。
【０２１６】
【表９】
2011070707.tif 000021
【０２１７】
これらの型は、Ｃ＃およびＸＳＤの型空間におけるこれらの型の互換派生物にフローすることができる。例えば、ｓｔｒｉｎｇの値を、ストリングに対する制限を定義したＸＳＤ型にフローすることができ、ａｎｙの値を、ｔｙｐｅ＝”ａｎｙ”を受け入れる設定にフローすることができる。
【０２１８】
３．２．２．１  ＸＳＤ組込み型
図１４に、例示的な組込みデータ型階層を示す。
【０２１９】
３．２．２．２  Ｃ＃データ型
【０２２０】
【表１０】
2011070707.tif 000022
【０２２１】
３．２．２．３  サポートされる変換
以下は、ＸＳＤ型とＣＬＳ型の間に存在する変換である。
【０２２２】
【表１１−１】
2011070707.tif 000023
【０２２３】
【表１１−２】
2011070707.tif 000024
【０２２４】
３．２．３  設定宣言
設定宣言セクションでは、前のセクションからの設定宣言を使用して、名前付き設定を生成する。属性を使用して、各設定に関する情報をさらに提供する。
【０２２５】
【数９】
2011070707.tif 000025
【０２２６】
【表１２】
2011070707.tif 000026
【０２２７】
３．２．４  リストサポート
多値設定の操作をサポートするために、単純な設定値リストがサポートされる。リストは、設定宣言と同じ定義の値のシーケンスである。リストは、置換またはマージできる別のリストにフローすることができる。値をリストにマージする際の重複検出はサポートされない。というのは、これは、設定フローを使用すればよりフレキシブルに行うことができるからである。また、どんな形の順序付けもサポートされない。
【０２２８】
リスト宣言は、以下のように真に設定された属性ｌｉｓｔを含む。 
<settingDeclaration name=”roles”type=”xs:string”list=”true”/>
次いで、ｓｅｔｔｉｎｇＶａｌｕｅＬｉｓｔを使用して値を提供する。リストを提供するとき、ユーザは、前の値と置換またはマージするかどうかを指定することができる。
【０２２９】
【数１０】
2011070707.tif 000027
【０２３０】
ＳＤＭは、値リストの単純な操作をサポートする。フローメンバからのパスが設定宣言をターゲットとするとき、結果的な挙動は、パスのどちらかの端における定義に依存する。
【０２３１】
【表１３】
2011070707.tif 000028
【０２３２】
３．２．５  設定属性
設定属性は、ランタイムが特定の設定の挙動を記述するのに使用する。
【０２３３】
【数１１】
2011070707.tif 000029
【０２３４】
【表１４】
2011070707.tif 000030
【０２３５】
３．２．６  設定値
設定が単一の値として宣言されたかリストとして宣言されたかに応じて、設定に関する値は、設定値要素と設定値リスト要素のどちらかを使用して提供することができる。
【０２３６】
３．２．６．１  設定値
設定値は、特定の設定宣言に関する値を提供するのに使用する。値は、宣言に関連する定義とマッチすべきである。値がｆｉｘｅｄに宣言された場合、提供された値は、値が固定されるポイントに応じて、すべての派生定義中でまたは参照するメンバ中で使用されることになる。値が固定された後は、オーバーライドすることはできない。
【０２３７】
【数１２】
2011070707.tif 000031
【０２３８】
【表１５】
2011070707.tif 000032
【０２３９】
３．２．６．２  設定値リスト
設定値リストは、リストとして宣言された設定に関する１つまたは複数の値を提供するのに使用する。値を宣言するとき、ユーザは、前の値とマージするか、あるいは前の値すべてを上書きするように決定することができる。
【０２４０】
【数１３】
2011070707.tif 000033
【０２４１】
【表１６】
2011070707.tif 000034
【０２４２】
３．２．７  設定継承
設定継承は、派生定義が基底定義からのすべての設定宣言を暗黙的に含むことを意味する。設定継承の重要な側面のいくつかを以下に示す。  
・設定継承は推移的である。ＣがＢから派生し、ＢがＡから派生した場合、Ｃは、Ｂ中で宣言された設定ならびにＡ中で宣言された設定を継承する。  
・派生定義は、それが拡張する基底定義から継承した設定宣言に新しい設定宣言を追加することができるが、継承した設定の定義を削除することはできない。
【０２４３】
３．２．８  型変換
組込み型間のロスレス（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>
【０２４９】
【表１７】
2011070707.tif 000035
【０２５０】
３．４．２  メンバ
メンバは、ランタイム時に存在することのできる定義インスタンスを識別するのに使用する。すべてのメンバは、型の範囲内で固有の名前で識別され、それらが参照する定義に関する設定を提供することができ、設計表面特有のデータを含むことができる。
【０２５１】
【数１４】
2011070707.tif 000036
【０２５２】
【表１８】
2011070707.tif 000037
【０２５３】
３．５  設定フロー
設定フローは、オブジェクト定義のメンバ間および関係への参与者間でパラメータを渡すのに使用する。フローの一部として、ユーザは、変形を用いて設定値を結合または分離し、新しい設定値を計算することができる。
【０２５４】
すべての設定フローメンバは、フロー定義を使用して変形を実装する。フロー定義は、ＳＤＭファイル中で宣言される。以下は、ＵＲＬ（Uniform Resource Locator）を解析するフロー型である。
【０２５５】
【数１５】
2011070707.tif 000038
【０２５６】
次いで、フローメンバをオブジェクト内または関係内で宣言する。フローメンバは、フロー定義への入力を提供し、次いでフローからの出力をターゲット設定に向けて送る。
【０２５７】
【数１６】
2011070707.tif 000039
【０２５８】
３．５．１  フロー定義
フロー定義は、設定値のセットに適用したいと思う特定の変形を定義するのに使用する。フロー定義は、入力設定（書込み専用設定）および出力設定（読出し専用設定）と、変換を定義するための入力インタフェースなど、設計表面特有の情報に関する設定データセクションと、ＳＤＭファイルを閲覧するときに使用される記述とを定義する設定スキーマを開示する。フロー定義は、それが定義される名前空間内の名前で識別される。定義はまた、ランタイムがフローを評価するときにランタイムをサポートすることになるマネージャも識別する。
【０２５９】
簡単な変形が必要なときにフロー要素の構築を単純にするために、ランタイムはいくつかの標準フロー定義を含むものと考えられる。例としては、コピー、マージ、およびストリング代用が挙げられる。フロー定義はパラメータ化することができるので、構成パラメータに基づいて異なるアクションを実施する１つまたは複数の単純な変形があることも考えられる。
【０２６０】
【数１７】
2011070707.tif 000040
【０２６１】
３．５．２  フローメンバ
各フロー要素は、１つまたは複数のソースノード、１つまたは複数の宛先ノード、いくつかの静的設定、およびフロー定義を識別する。フローが評価されるとき、ソースノードからソースデータが収集され、フロー要素からの設定と結合され、変換のためにフロー定義に渡される。出力データは宛先ノードに渡される。
【０２６２】
ソース値の１つが変化したときは、フローの再評価がトリガされる。この理由で、値の反転を引き起こす循環フローを回避する必要がある。値が一定のままである場合は、ループは終了する。ランタイムは、スタック深度を常に把握していることによって、無限ループを検出し終了させる。
【０２６３】
【数１８】
2011070707.tif 000041
【０２６４】
【表１９】
2011070707.tif 000042
【０２６５】
３．５．３  設定ターゲット
設定ターゲットは、フローが定義されているコンテキストで周知である名前に関係するメンバまたはネストされたメンバ中の設定値へのパスを識別する。周知の名前の例としては、定義または参照宣言中のｔｈｉｓ、ホスティング関係宣言中のｈｏｓｔおよびｇｕｅｓｔ、または制約宣言内で定義されたｔａｒｇｅｔが挙げられる。設定ターゲットはまた、パスによって識別される設定のソース値と宛先設定のどちらかとして使用されることになる関連するフロー定義上の設定も識別する。
【０２６６】
【数１９】
2011070707.tif 000043
【０２６７】
【表２０】
2011070707.tif 000044
【０２６８】
出力パスは、ターゲット値を固定および置換するためのセマンティクスをサポートする、設定ターゲットの変形である。
【０２６９】
【数２０】
2011070707.tif 000045
【０２７０】
2011070707.tif 000046
【０２７１】
３．６  設定制約
制約は、定義のメンバの設定値に対する制限、または関係への参与者に対する制限を識別するのに使用する。これらの制限は、設計時と展開時の両方においてインスタンス空間中で評価する。
【０２７２】
すべての設定制約は、制約定義を使用して設定値を評価する。制約定義は、設定宣言を使用して、それが制約する値を識別する。以下の制約定義は、２つの引数および１つの演算子を利用する単純な比較関数を実装し、次いで制約を評価し、最後に成功またはエラーを返す。
【０２７３】
【数２１】
2011070707.tif 000047
【０２７４】
次いで制約メンバを使用して、評価のために制約型に値を提供する。
【０２７５】
【数２２】
2011070707.tif 000048
【０２７６】
３．６．１  制約定義
制約定義は、入力値のセットに作用する制約を定義する。制約をパラメータ化して、カスタム挙動を選択することができ、あるいは、パラメータを使用してその挙動を定義する単純な制約エンジンをサポートすることができる。抽象オブジェクト間の既知の関係をサポートするために、単純なパラメータ値制約および複雑な制約セットについて、標準的な制約定義のセットが書かれることが考えられる。
【０２７７】
【数２３】
2011070707.tif 000049
【０２７８】
３．６．２  制約メンバ
制約メンバは、特定の制約定義に関する入力値のセットを識別する。メンバは、設定に関する静的な値を識別することができ、入力ステートメントを使用して制約設定をパスにバインドすることができる。
【０２７９】
【数２４】
2011070707.tif 000050
【０２８０】
【表２１】
2011070707.tif 000051
【０２８１】
３．７  システムエンドポイント定義およびリソース定義
この章では、抽象および具象オブジェクト定義に関するスキーマについて述べる。
【０２８２】
抽象オブジェクト定義は、設定宣言のセットを開示し、それが参与する関係に対する制約を含むことができ、関連するマネージャをランタイム内に有する。
【０２８３】
以下は、ウェブサーバについての抽象システム定義である。ウェブサーバは２つの設定を有し、また、少なくとも１つのｖｓｉｔｅ型を含むことを要する関係制約を有する。
【０２８４】
【数２５】
2011070707.tif 000052
【０２８５】
ｖｓｉｔｅは、サーババインド情報を含む抽象エンドポイント定義である。
【０２８６】
【数２６】
2011070707.tif 000053
【０２８７】
フロントエンドウェブサーバについての具象システム定義は、ウェブサーバカテゴリを静的内容として識別し、１個から１００個までの間のエンドポイントインスタンスを表すことのできる単一のｂｙＲｅｆｅｒｅｎｃｅエンドポイントメンバを含む。エンドポイントに関する具象エンドポイント定義は、システム定義内部にネストされ、ｖｓｉｔｅに関するｉｐ  ＥｎｄｐｏｉｎｔをＥｎｄｐｏｉｎｔ８０として定義する。
【０２８８】
<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>
【０２８９】
３．７．１  オブジェクト定義
抽象および具象オブジェクトは、以下の基底オブジェクト定義を拡張する。基底型定義の要素に加えて、これらは、オブジェクトが参与する関係を制約する能力も共有する。
【０２９０】
【数２７】
2011070707.tif 000054
【０２９１】
【表２２】
2011070707.tif 000055
【０２９２】
３．７．２  抽象オブジェクト定義
抽象オブジェクト定義は、設計表面が開示する構成単位であってすべての具象オブジェクトの派生源である構成単位を定義するのに使用する。すなわち、具象オブジェクト定義は抽象オブジェクト定義を実装すべきである。
【０２９３】
抽象オブジェクト定義は、単純な継承を追加することによってＳＤＭオブジェクトを拡張する。すなわち、ｅｘｔｅｎｄｓ属性を使用して、抽象オブジェクト定義に対する基底オブジェクト定義を識別する。次いで抽象オブジェクト定義は、基底オブジェクト定義から設定および関係制約を継承する。継承を通して、オブジェクト定義は、新しい設定および制約を追加することによって抽象オブジェクト定義の設定および制約を拡張することができる。
【０２９４】
抽象オブジェクト定義はまた、それらが参与したいと思う関係に対して制約を追加することもできる。例えば、抽象オブジェクト定義は、一定の関係が存在することを必要とすることができ、あるいは関係の他方の端に配置できるオブジェクト定義を制約することができ、あるいは所与の関係に参与するインスタンス上の設定を制約することができる。
【０２９５】
３．７．２．１  抽象オブジェクト定義
すべての抽象オブジェクトは、それらが関連付けられたいと思うレイヤを識別することができる。これが提供されない場合、オブジェクト定義はどのレイヤでも使用できると見なされる。抽象オブジェクト定義は、それらが拡張する基底オブジェクト定義を識別することができ、その場合、そのオブジェクト定義の設定および制約を継承し、基底オブジェクト定義が参与する関係中で基底オブジェクト定義の代わりになることができる。
【０２９６】
【数２８】
2011070707.tif 000056
【０２９７】
【表２３】
2011070707.tif 000057
【０２９８】
３．７．２．２  抽象エンドポイント、システム、およびリソースオブジェクト定義
ＳＤＭモデル中の抽象オブジェクト定義には３つの分類がある。すなわち、抽象エンドポイント定義、抽象システム定義、および抽象リソース定義である。これらはそれぞれ、抽象オブジェクト定義の単純なリネームである。
【０２９９】
【数２９】
2011070707.tif 000058
【０３００】
エンドポイント定義は、通信エンドポイントを表す。エンドポイント上の設定は、バインドプロセスにおけるその使用に関係する。例えばクライアントサーバプロトコルの場合、サーバエンドポイント定義は、設定スキーマを使用して、エンドポイントにバインドするのに必要な設定を識別することができ、クライアントエンドポイント定義は、クライアント特有の接続属性を開示することができる。
【０３０１】
システム定義は、データ、ソフトウェア、またはハードウェアの要素の集合を表すのに使用する。例としては、ウェブサービス、データベース、およびスイッチが挙げられる。リソース定義は、システム定義の一部として識別することのできる特定要素を取り込むのに使用する。
【０３０２】
３．７．３  暗黙的な基底定義
図１５に示すように、別の抽象オブジェクト定義を拡張しないすべての抽象オブジェクトは、エンドポイント、システム、リソースの基底定義のうちの１つを暗黙的に拡張する。これらの基底定義は、関係宣言および制約宣言中で使用することのできる各ツリーのルートを形成する。これにより、関係または制約は、ルートから派生する任意の型を、識別されるルート定義の代わりに使用できることを示すことができる。これらのルート型は常に抽象であり、直接インスタンス化することはできない。
【０３０３】
これらの型の定義は、モデル内におけるそのインスタンス化を制御する基底制約を含む。これらはＳｙｓｔｅｍ．ｓｄｍ．で見ることができる。
【０３０４】
３．７．４  具象オブジェクト定義
具象オブジェクト定義は、抽象オブジェクト定義に対する実装を提供する。実装は、オブジェクトメンバおよび関係メンバと、実装される抽象定義の設定に関する値と、新しい設定宣言と、メンバ間およびメンバに対する制約間のフローとから構築される。
【０３０５】
具象定義はまた、ネストされた定義の宣言を含むこともできる。これらの定義は、含んでいる定義の範囲内のメンバについて使用することができ、定義の範囲外の制約中で参照することができる。
【０３０６】
３．７．４．１  基底具象オブジェクト定義
基底具象型は、オブジェクト定義、継承する設定宣言、設計データ、オプションのマネージャ参照、名前、参与できる関係に対する制約、抽象定義の設定に関する値を提供する能力、その設定間およびそのメンバの設定間のフローを記述する能力を拡張する。次いで、具象定義が、実装する抽象定義を識別する能力を追加し、いくつかのオプション属性が、定義のバインド挙動をカスタマイズする能力を追加する。
【０３０７】
【数３０】
2011070707.tif 000059
【０３０８】
【表２４】
2011070707.tif 000060
【０３０９】
３．７．４．２  オブジェクトメンバ
オブジェクトメンバは、抽象と具象のどちらかのオブジェクト定義を参照すべきである。これらはインスタンスのアレイを表すことができ、その場合、アレイの上限と下限を定義することができる。これらが参照メンバである場合は、オブジェクトをインスタンス化するユーザは、メンバに対するインスタンスを明示的に構築すべきである。参照メンバでない場合は、ランタイムは、外側のオブジェクトが生成されるのと同時にインスタンスを生成することになる。
【０３１０】
【数３１】
2011070707.tif 000061
【０３１１】
【表２５】
2011070707.tif 000062
【０３１２】
ＳＤＭモデルでは、親が構築されるときに生成され親が破壊されるときに破壊されるメンバを、親に関係なく存続期間を有するメンバから区別する必要がある。この目的で、ＩｓＲｅｆｅｒｅｎｃｅ属性を使用する。単純に例えると、インスタンスの生成にｎｅｗが使用されるかどうかに基づいてスタックベースとヒープベースの構築が可能なＣ＋＋宣言に似ている。メンバがＩｓＲｅｆｅｒｅｎｃｅとしてマークされた場合は、オペレータ側で、インスタンスを生成してメンバと関連付けるための明示的な新しい操作が必要である。
【０３１３】
こうすることにはいくつかの理由がある。  
１．オペレータがシステムを構築するとき、ＩｓＲｅｆｅｒｅｎｃｅメンバを構築できることが開示される。これはオペレータの経験を大幅に単純化する。  
２．ＳＤＭ文書が処理されるとき、文書のインスタンス空間が具象定義空間のインスタンス空間から変化することのできる明確な境界がある。
【０３１４】
３．７．４．３  関係メンバ
関係メンバは、オブジェクトメンバが生成されたときにオブジェクトメンバ間に存在する関係を識別する。関係インスタンスは、オペレータによって明示的に生成されるか、あるいはランタイムによって暗黙的に生成される。前者の例はインスタンス間のホスティング関係であり、後者の例はシステム間の通信関係である。
【０３１５】
【数３２】
2011070707.tif 000063
【０３１６】
３．７．４．３．１  ホスティングメンバ
ホストメンバは、２つのオブジェクトメンバ間のホスティング関係を宣言するのに使用する。オブジェクトメンバは、含んでいる定義の直接のメンバとすることもでき、定義とメンバシップ関係を有するネストされたメンバとすることもできる。参照されるメンバと含んでいる定義との間には、メンバシップ連鎖があるべきである。
【０３１７】
【数３３】
2011070707.tif 000064
【０３１８】
【表２６】
2011070707.tif 000065
【０３１９】
３．７．４．３．２  通信メンバ
通信メンバは、定義の直接のシステムメンバのエンドポイントメンバ間における通信関係を宣言するのに使用する。
【０３２０】
【数３４】
2011070707.tif 000066
【０３２１】
【表２７】
2011070707.tif 000067
【０３２２】
３．７．４．３．３  包含メンバ
包含メンバは、型メンバが型によって包含されることを宣言するのに使用する。各型メンバは、包含されるか委任されるかのどちらかとすることができる。包含メンバは、包含関係の親値を自動的に関係のｔｈｉｓポインタに設定する。
【０３２３】
【数３５】
2011070707.tif 000068
【０３２４】
【表２８】
2011070707.tif 000069
【０３２５】
３．７．４．３．４  委任メンバ
委任メンバは、外側の型上のエンドポイント定義メンバと、外側の型の直接のシステムメンバ上のエンドポイント定義メンバとの間の委任関係をセットアップするのに使用する。
【０３２６】
【数３６】
2011070707.tif 000070
【０３２７】
【表２９】
2011070707.tif 000071
【０３２８】
３．７．４．３．５  参照メンバ
参照メンバは、外側のシステムの２つの直接メンバ間またはネストされたメンバ間の参照関係をセットアップするのに使用する。
【０３２９】
【数３７】
2011070707.tif 000072
【０３３０】
【表３０】
2011070707.tif 000073
【０３３１】
３．７．４．４  エンドポイント定義
エンドポイント定義は、ネストされたソース型、リソースメンバ、ホスト関係メンバ、包含関係メンバ、参照関係メンバを宣言する能力を追加することにより、基底オブジェクトを拡張する。
【０３３２】
【数３８】
2011070707.tif 000074
【０３３３】
【表３１】
2011070707.tif 000075
【０３３４】
３．７．４．５  サービス定義
システム型は、ネストされたエンドポイント、システム型、リソース型、エンドポイントメンバ、システムメンバ、リソースメンバ、ホスト関係、包含関係、接続関係、委任関係、参照関係に対するサポートを追加することにより、基底型を拡張する。
【０３３５】
【数３９】
2011070707.tif 000076
【０３３６】
【表３２】
2011070707.tif 000077
【０３３７】
３．７．４．６  リソース定義
リソース型は、ネストされたリソース型定義、リソースメンバ、ホスト関係メンバ、包含関係メンバ、参照関係メンバを含むことができる。
【０３３８】
【数４０】
2011070707.tif 000078
【０３３９】
【表３３】
2011070707.tif 000079
【０３４０】
３．７．４．７  関係規則
オブジェクト定義の特定のインスタンスについて、このインスタンスが果たすことのできる各役割に関連するカーディナリティを、以下の表に識別する。
【０３４１】
３．７．４．７．１  システム規則
【０３４２】
【表３４】
2011070707.tif 000080
【０３４３】
３．７．４．７．２  エンドポイント規則
【０３４４】
【表３５】
2011070707.tif 000081
【０３４５】
３．７．４．７．３  リソース規則
【０３４６】
【表３６】
2011070707.tif 000082
【０３４７】
３．７．４．７．４  注
あらゆるインスタンスは、ちょうど１つの包含関係と、少なくとも１つのホスティング関係とに参与すべきである。  
これは以下のことを意味する。  
Ａ）非参照メンバは包含関係を識別すべきである。  
ｂ）参照メンバが構築されるためには、参照メンバは包含関係を識別すべきである。  
ｃ）包含関係を有さない参照メンバは、他のメンバに委任することができるだけである。
【０３４８】
３．８  関係
関係は、型間の可能な対話を識別するのに使用する。これらはバイナリおよび有向であり、それぞれは、関係に参与することのできるインスタンスの型を識別する。関係はまた、関係に参与するインスタンスの設定を制約することもでき、関係にわたって設定値をフローすることができる。
【０３４９】
以下は、型のセクションで述べたウェブサーバ上のウェブアプリケーションについての可能なホスティング関係である。この関係は、２つのシステムのセキュリティモデルが互換性を有することを検証するという制約を含み、また、サーバ名をｖｓｉｔｅからｖｄｉｒにコピーする設定フローメンバを含む。
【０３５０】
【数４１】
2011070707.tif 000083
【０３５１】
関係は、関係に参与することになる型メンバを識別する関係メンバを宣言することによって使用する。
【０３５２】
【数４２】
2011070707.tif 000084
【０３５３】
３．８．１  関係定義
基底関係定義は、オブジェクト制約およびフローを定義に追加する。オブジェクト制約は、この関係のインスタンスに参与するオブジェクトインスタンスの設定値に関するステートメントである。例えば、ＤＣＯＭ（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>
【０３５７】
【表３７】
2011070707.tif 000085
【０３５８】
３．８．２  抽象関係
抽象関係は、２つの抽象オブジェクト定義間で定義される関係である。これらは、２つの定義間の可能な対話を表す。
【０３５９】
【数４３】
2011070707.tif 000086
【０３６０】
３．８．２．１  抽象通信関係
通信関係は、エンドポイント定義間の可能な通信リンクを取り込むのに使用する。これらを使用して、独立して展開されるソフトウェア要素間の対話を記述する。通信関係スキーマは、クライアントおよびサーバエンドポイント参照を追加することによって、基底関係スキーマを拡張する。
【０３６１】
【数４４】
2011070707.tif 000087
【０３６２】
【表３８】
2011070707.tif 000088
【０３６３】
通信関係では、以下の抽象型の対の組合せが有効である。
【０３６４】
【表３９】
2011070707.tif 000089
【０３６５】
３．８．２．２  抽象ホスティング関係
ホスティング関係は、ゲストが構築されるためにホストが必要であることを取り込むのに使用する。１つのゲストに対して複数の可能なホストがあり得るので、このことは、ホスティング関係がホスト上にゲストを構築する任務も負うことを意味する。したがって、オブジェクトのインスタンスを生成するためには、ゲストから適合するホストへのホスティング関係があるべきである。
【０３６６】
例えば、ウェブサービスオブジェクト定義とＩＩＳオブジェクト定義との間にホスティング関係があるとする。この場合、ＭｙＷｅｂｓｅｒｖｉｃｅおよびＭｙＩＩＳがそれぞれウェブサービスおよびＩＩＳを実装するものとすると、この関係は、ホスティング関係に対するマネージャを使用してシステムＭｙＩＩＳのインスタンス上にシステムＭｙＷｅｂｓｅｒｖｉｃｅのインスタンスを生成することが可能かもしれないことを示している。システムと関係の両方に存在する制約を評価し終えるまでは、この関係を生成することが可能になるかどうかはわからない。
【０３６７】
【数４５】
2011070707.tif 000090
【０３６８】
【表４０】
2011070707.tif 000091
【０３６９】
ホスティング関係では、以下の抽象定義の対の組合せが有効である。
【０３７０】
【表４１】
2011070707.tif 000092
【０３７１】
３．８．２．３  抽象包含関係
２つの抽象オブジェクト間の包含関係は、親型（parentType）に基づく具象型がメンバ型（memberType）に基づくメンバを包含できることを取り込む。包含は、親インスタンスがメンバインスタンスの存続期間を制御することができ、メンバインスタンスに挙動を委任することができることを意味する。
【０３７２】
【数４６】
2011070707.tif 000093
【０３７３】
【表４２】
2011070707.tif 000094
【０３７４】
包含関係では、以下の抽象定義の対の組合せが有効である。
【０３７５】
【表４３】
2011070707.tif 000095
【０３７６】
３．８．２．４  抽象委任関係
委任関係は、外側のシステムから、含まれるシステムに挙動を転送するのに使用する。これは、外側のシステム上のエンドポイントを内側のシステム上のエンドポイントに委任することによって行う。これにより、外側のシステムに向けられたであろうすべての対話を効果的に内側のシステム上のエンドポイントに転送することができる。委任は連鎖させることができ、それにより内側のシステムは、さらにその挙動を別のシステムに委任することができる。
【０３７７】
委任関係は、委任に参与することのできる抽象エンドポイント定義の対を定義する。各関係は、プロキシとして働くことのできる抽象エンドポイント定義と、挙動の委任先とすることのできる抽象エンドポイント定義とを識別する。
【０３７８】
【数４７】
2011070707.tif 000096
【０３７９】
【表４４】
2011070707.tif 000097
【０３８０】
委任関係では、以下の抽象型の対の組合せが有効である。
【０３８１】
【表４５】
2011070707.tif 000098
【０３８２】
リソースおよびシステムの委任がレイヤ間のバインドをサポートできるようにすることもできる。例えば、ＩＩＳがファイルシステムの一部を、展開する必要なしに開示できるようにすることができる。
【０３８３】
３．８．２．５  抽象参照関係
参照関係は、ホスティング関係の従属性の他にある、インスタンス間の強力な従属性を取り込むのに使用する。これらの従属性を使用して、展開中に構築順序を制御し、インストール中および更新中にシステム間でパラメータをフローする。参照関係は強力な従属性を示すので、参照関係がシステム境界を越えることは許容できない。これは、あるシステム内のリソースが別のシステム内のリソースに対して従属性を有することはできないことを意味する。このような従属性があれば、システムはもはや独立した展開単位ではなくなる。システム間に従属性がある場合は、通信関係を使用する。通信関係は、システムの再インストールを必要とせずに、時の経過に伴って変化することができる。
【０３８４】
【数４８】
2011070707.tif 000099
【０３８５】
【表４６】
2011070707.tif 000100
【０３８６】
参照関係では、以下の抽象型の対の組合せが有効である。
【０３８７】
【表４７】
2011070707.tif 000101
【０３８８】
３．８．３  暗黙的な基底関係
図１６に示すように、すべての抽象関係は、基底関係定義の１つを暗黙的に拡張する。これらの定義は、各関係ツリーのルートを形成する。こうすることにより、制約定義内からルート定義を参照することができ、ルート型から共通型制約を継承することができる。
【０３８９】
３．８．４  具象関係
具象関係は、２つの具象オブジェクト定義間の関係である。各具象関係は抽象関係を実装すべきである。抽象関係は、具象オブジェクト定義によって直接的または間接的（継承によって）に実装される抽象オブジェクト定義の、マッチする対の間にあるべきである。
【０３９０】
【数４９】
2011070707.tif 000102
【０３９１】
３．８．４．１  ホスティング関係
データセンタにアプリケーションを展開するとき、アプリケーション内のシステムに関するすべての未解決ホスティング関係を解決する必要がある。これを行うために、オペレータは、必要な各ホスティング関係につきホスティングメンバを生成することが必要になる。オペレータの作業を簡略化し、開発者が展開プロセスをガイドできるようにするために、開発者は、代わりに具象ホスティング関係を生成することができる。オペレータがアプリケーション展開時に単一のホスティングメンバを宣言するだけで済むような形で、具象ホスティング関係を使用してホスティング関係メンバのセットをグループ化する。
【０３９２】
<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>
【０３９３】
【表４８】
2011070707.tif 000103
【０３９４】
ホスティング関係では、以下の具象型の対の組合せが有効である。
【０３９５】
【表４９】
2011070707.tif 000104
【０３９６】
ゲストは、以下の場合かつその場合に限って、ホストにバインドすることができる。  
Ｇｕｅｓｔ中の各ｇｕｅｓｔＭｅｍｂｅｒにつき、  
Ｈｏｓｔ中の１つまたは複数のｈｏｓｔＭｅｍｂｅｒがあり、この場合に、  
ｇｕｅｓｔＭｅｍｂｅｒ．ＴｙｐｅがｈｏｓｔＭｅｍｂｅｒ．ｔｙｐｅとホスティング関係を有し、  
ｇｕｅｓｔＭｅｍｂｅｒ．ｈｏｓｔＣｏｎｓｔｒａｉｎｔｓがｈｏｓｔＭｅｍｂｅｒ．ｓｅｔｔｉｎｇｓに対して妥当性を有し、  
ｈｏｓｔＭｅｍｂｅｒ．ｇｕｅｓｔＣｏｎｓｔｒａｉｎｔｓがｇｕｅｓｔＭｅｍｂｅｒ．ｓｅｔｔｉｎｇｓに対して妥当性を有し、  
ｇｕｅｓｔＭｅｍｂｅｒの各メンバにつき、ｈｏｓｔＭｅｍｂｅｒのメンバへのバインドがある。
【０３９７】
例えば、以下の具象関係は、レイヤ３システム（Ｂｉｋｅ）をレイヤ２ホスト（ｏｐｅｒａｔｉｎｇＳｙｓｔｅｍ）にバインドする。この場合、ホスティング関係に関する設定が「ｓｙｓｔｅｍ  ｆｏｌｄｅｒ」のデフォルト値で定義される。この設定が、レイヤ３アプリケーションのシステムとレイヤ２ホストのシステムとの間のホスティング関係を定義する３つのホスティングメンバのうちの１つにフローされる。
【０３９８】
<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 >
【０３９９】
３．８．４．２  参照関係
２つの具象型間の具象参照関係を使用して、通信関係を含まないシステム間の特定の従属性を取り込むことができる。例えば、インストールされるあるアプリケーションに対して、別のアプリケーションがすでに存在すべきであることを取り込むことができる。
【０４００】
【数５０】
2011070707.tif 000105
【０４０１】
【表５０】
2011070707.tif 000106
【０４０２】
参照関係では、以下の具象型の対の組合せが有効である。
【０４０３】
【表５１】
2011070707.tif 000107
【０４０４】
３．９  オブジェクト制約および関係制約
オブジェクト制約および関係制約は、具象空間のトポロジを定義し、オブジェクトが特定の関係中で使用されたときのオブジェクトの設定を制約するために使用する。
【０４０５】
例えば、ある抽象オブジェクト定義（Ａ）内で、この抽象定義の実装が別の抽象オブジェクト定義（Ｂ）のインスタンス１つを含むべきであると識別したい場合がある。少なくとも１つの適切な制約関係がすでにあるとすると、こうするには、Ａ内で以下のように見える関係制約を使用したことになる。
【０４０６】
【数５１】
2011070707.tif 000108
【０４０７】
この制約は、Ａの実装が親の役割を果たし、関係の他方の端（メンバ）における型が型Ｂであるという、包含関係が存在すべきであることを識別する。Ｂの構成に対してより多くの制御が欲しい場合は、以下のように、型Ｂの設定に対する制約を追加することができる。
【０４０８】
【数５２】
2011070707.tif 000109
【０４０９】
この場合、メンバの名前がストリング「ｍｙＰｏｒｔ」に等しいことを必要とする制約が追加されている。
【０４１０】
また、制約は関係に追加することもできる。これらをオブジェクト制約と呼ぶ。関係内から、関係に参与するオブジェクトを制約する。関係中の各役割につき、オブジェクト定義を識別することができ、次いでこれらのオブジェクト定義に設定制約を追加することができる。関係から見ると、カーディナリティは常にｍｉｎＯｃｃｕｒｓ＝１およびｍａｘＯｃｃｕｒｓ＝１であり、したがってこれは制約宣言には現れない。
【０４１１】
【数５３】
2011070707.tif 000110
【０４１２】
最後に、制約はネストすることができる。これにより、制約を１つに連鎖させることができ、外側の制約が、内側の制約に関するコンテキストを設定する。以下は、ｗｅｂＡｐｐシステムをホストするＩＩＳシステムの例であり、ＩＩＳシステムはこの場合、ｗｅｂＡｐｐが特定の型のエンドポイントだけを含むように制約する。
【０４１３】
この場合、オブジェクト制約のグループを使用して、少なくとも１つが真となる可能性セットを指定する。
【０４１４】
【数５４】
2011070707.tif 000111
【０４１５】
ネストされた制約は、外から中へ評価できるパスを形成する。パス上の各制約は、パス上の前のインスタンスならびに現在のインスタンスの設定にアクセスすることができる。ネストされた制約の評価は、識別されるシステム内で制約が定義されているかのように行われる。
【０４１６】
以下の２つのシナリオは、ｆｏｏから見て等価なはずである。第１のシナリオでは、ｆｏｏが、含まれるシステムｂａｒに対して、ネストされた制約を配置しており、第２のシナリオでは、型ｂａｒがすでに制約を含んでいる。
【０４１７】
シナリオ１：
【０４１８】
【数５５】
2011070707.tif 000112
【０４１９】
シナリオ２：
【０４２０】
【数５６】
2011070707.tif 000113
【０４２１】
３．９．１  制約モデル
制約モデルには、ガードと述語という２つの部分がある。ガードは、述語を実行するコンテキストを定義するのに使用する。例えば関係内では、ガードを使用して、述語を実行したい型の特定の組合せを識別する。オブジェクト内では、ガードを使用して、他のオブジェクトに対する関係のセットを識別する。
【０４２２】
次いで、それらのガードの要件が満たされたときに述語が実行される。述語には２つの形がある。すなわち、設定値を妥当性検査する設定制約と、制約のセットを妥当性検査するグループ制約である。
【０４２３】
ガードの中にガードをネストすることができ、その場合、内側のガードは外側のガードが満たされたときだけチェックされる。これにより、関係構造の検証をサポートするパスを構築することができる。
【０４２４】
ガードとその述語の組合せは、ガードがマッチし述語が真に評価される回数を示すカーディナリティを有することができる。
【０４２５】
より正式には以下のとおりである。
【０４２６】
【数５７】
2011070707.tif 000114
【０４２７】
ガードは、ＯｂｊｅｃｔＣｏｎｓｔｒａｉｎｔとＲｅｌａｔｉｏｎｓｈｉｐＣｏｎｓｔｒａｉｎｔのどちらかとして定義される。オブジェクト制約は、関係のいずれかの端に関連する２つのオブジェクト定義を識別する。関係制約は、関係定義およびターゲットオブジェクト定義を識別する。オブジェクト制約は任意選択または必須とすることができ、関係制約は下限と上限を有する。このカーディナリティの違いは、関係は常に２つの型しか識別できないが、型は複数の関係に参与できることを反映している。
【０４２８】
Predicate:==SettingsConstraint(rule)|group{(guard)*}
述語は、規則を含む設定制約と、ガードのセットを含むグループとのどちらかである。述語は、ガードのコンテキストで評価される。設定制約の場合、述語は、ルートガードのオーナからの設定と、ネストされた各ガードによって識別されるコンテキストとを識別することができる。グループは、マッチして真に評価されるべきガードを少なくとも１つ含むガードセットを識別するのに使用される。 
例：
1. RelationshipConstraint(containmentRelationship,webapp,0,1{}
この例は、ｗｅｂａｐｐとの包含関係があるときは常に真に評価されるガードを示している。このガードは、多くても１回、真に評価されることができる。それ以上のマッチがある場合は、エラーがユーザに返される。
【０４２９】
【数５８】
2011070707.tif 000115
【０４３０】
この例では、ガードに述語を追加している。ガードは、関係定義とターゲット定義がマッチし、設定制約が真に評価されるときだけ、真に評価される。関係定義とターゲット定義がマッチし、設定制約が真でない場合は、エラーがユーザに返される。関係とターゲット型がマッチし、設定制約が複数回にわたって真に評価される場合は、エラーがユーザに返される。
【０４３１】
【数５９】
2011070707.tif 000116
【０４３２】
この例では、ガードの中にガードをネストしている。外側のガードが真であるとき（制約を含む型がｗｅｂａｐｐも含む）、内側のガードは外側のガードのコンテキストで評価される。これは、内側の関係制約がｗｅｂａｐｐインスタンスのコンテキストで評価されることを意味する。ｗｅｂＡｐｐが０または１個のｖｄｉｒを含む場合は、内側の制約は真を返す。複数のｖｄｉｒを含む場合は、制約はユーザにエラーを返す。
【０４３３】
【数６０】
2011070707.tif 000117
【０４３４】
オブジェクト制約のコンテキストが、プライマリオブジェクト定義（第１のオブジェクト定義）である。これは、関係制約がｗｅｂａｐｐのコンテキストで評価されることを意味する。関係制約は２つの可能なコンテキストを定義する。第１は関係であり、これはオブジェクト制約のためのコンテキストになる。第２はターゲットオブジェクト定義であり、これは関係制約のためのコンテキストになる。
【０４３５】
【数６１】
2011070707.tif 000118
【０４３６】
この例では、グループを使用して、共にｗｅｂａｐｐのコンテキストで評価されることになる２つの関係制約を含めている。グループは、関係の少なくとも一方が発火して真を返すまでエラーを生じる。この場合では、ｗｅｂａｐｐはｖｄｉｒとｄｉｒｅｃｔｏｒｙのどちらかを含むべきである。
【０４３７】
３．９．２  基底制約
<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>
【０４３８】
【表５２】
2011070707.tif 000119
【０４３９】
３．９．３  オブジェクト制約
オブジェクト制約は、関係の役割の一方または両方に対する制約を記述する。制約は、制約が失敗した場合に制約の識別を助けるための名前を有し、役割に関連する型をターゲットとする設定制約のリストを含み、さらに、インスタンスを、役割に関連する定義から派生したオブジェクトのインスタンスになるよう制約することもできる。
【０４４０】
【数６２】
2011070707.tif 000120
【０４４１】
【表５３】
2011070707.tif 000121
【０４４２】
３．９．４  オブジェクト制約グループ
オブジェクト制約グループは、オブジェクト制約のセットを少なくとも１つのセマンティクスを使用して評価できるよう１つにグループ化することを可能にする。グループは、オブジェクト制約の少なくとも１つが関係上のオブジェクトとマッチし、次いでそれに含まれる述語が真に評価されない限り、エラーを返す。型制約がグループの直接のメンバである場合は、制約に関するｒｅｑｕｉｒｅｄ属性は無視される。
【０４４３】
【数６３】
2011070707.tif 000122
【０４４４】
【表５４】
2011070707.tif 000123
【０４４５】
３．９．５  関係制約
関係制約は、オブジェクトが参与することのできる関係を制約するのに使用する。関係制約は、関係定義を識別し、任意選択で、関係の他方の端におけるインスタンスのオブジェクト定義と、関係のカーディナリティも識別する。エラーメッセージ中で制約を識別できるように、制約には名前が与えられる。関係制約の本体は、関係と、関係の他方の端におけるインスタンスとの両方に関する述語を含む。
【０４４６】
関係制約は、いくつかの目的で使用することができる。述語を追加せず単純にカーディナリティを使用する場合、これらは、インスタンスを正しく動作させるために提供すべき関係を識別するのに使用することができる。述語を伴う場合は、このオブジェクトが対話したいインスタンスに関する構成のセットを限定するのに使用することができる。
【０４４７】
<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>
【０４４８】
【表５５】
2011070707.tif 000124
【０４４９】
３．９．６  関係制約グループ
関係制約グループは、関係制約のセットを少なくとも１つのセマンティクスを使用して述語として評価できるよう１つにグループ化することを可能にする。グループは、含まれる関係制約の少なくとも１つが関係定義およびターゲットオブジェクトとマッチし、それに含まれる述語が真を返さない限り、エラーを返す。含まれる制約中の述語のいずれかがエラーを返す場合は、これらのエラーがユーザに伝えられる。含まれる関係制約のｍｉｎＯｃｃｕｒｓカーディナリティは無視されるが、ｍａｘＯｃｃｕｒｓカーディナリティに違反した場合は、エラーがユーザに返される。
【０４５０】
【数６４】
2011070707.tif 000125
【０４５１】
【表５６】
2011070707.tif 000126
【０４５２】
３．１０  オブジェクトマネージャ
オブジェクトマネージャは、型および関係がカスタム挙動をランタイム環境に挿入するのに使用する機構である。マネージャがサポートすることのできる役割は、管理する型ごとにいくつかある。すなわち、型のインストールに参与することができ、型のＣＬＲ表現を提供することができ、型間のバインドをどのように解決するかについてのポリシー決定に関与することができ、複雑な制約およびフローの実施を提供することができる。
【０４５３】
オブジェクトマネージャのすべての役割は、厳密名が付いたクラスへのエントリポイントとしてＣＬＲを介して開示される。オブジェクトマネージャは、ＳＤＭ中の他の型と同じようにしてパッケージされバージョニングされる。すなわち、システム配信ユニットで配信され、それらのバージョンおよび厳密名は、それらが宣言されるＳＤＭファイルに由来する。
【０４５４】
<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>
【０４５５】
【表５７】
2011070707.tif 000127
【０４５６】
３．１０．１  役割
オブジェクトマネージャは、それがサポートする型ごとに、１つまたは複数の役割をサポートすることができる。これらの役割には以下のものが含まれる。 
ａ）型または関係に関する制約の評価
ｂ）型または関係に関するフローの評価
ｃ）型に関する構築／破壊／更新サポート
ｄ）型または関係上の設定に関するオブジェクト表現の開示
ｅ）型または関係に関する発見の実施
ｆ）型または関係をとりまく設計表面特有ＵＩのサポート
【０４５７】
３．１１  ＳＤＭ文書構造
ＳＤＭ文書は、関係とオブジェクトとマネージャとのセットについて、強力な識別、バージョニング、およびローカライゼーション情報を提供する。
【０４５８】
<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>
【０４５９】
３．１１．１  情報
ＳＤＭ文書の情報セクションは、ＳＤＭ文書の識別および管理をサポートするための、人間に読める情報を含む。
【０４６０】
【数６５】
2011070707.tif 000128
【０４６１】
【表５８】
2011070707.tif 000129
【０４６２】
３．１２  変更要求
図１７に、変更要求の例を示す。変更要求は、ＳＤＭランタイムに対する変更のセットを識別する。ランタイムに対するすべての変更は、要求の構築を可能にするＡＰＩによる、またはＸＭＬフォーマットの、変更要求を使用して開始される。
【０４６３】
初期の要求は、単一のアクショングループを含む。要求がランタイムによって処理されるにつれて、ネストされるグループ化によってより多くの構造が追加され、展開およびフロープロセスの結果、より多くのアクションが追加される。この評価プロセスを経て、今やターゲットマシンに対して実行される準備のできた変更要求を、完全修飾変更要求と呼ぶ。これ以上の情報については３．１３章を参照されたい。
【０４６４】
３．１２．１  一貫性規則
ＳＤＭインスタンス空間に対してアクションを実施する際は、アクション完了後にもＳＤＭインスタンス空間中のすべてのインスタンスが一貫した状態であることを妥当性検査する。一貫した状態とは、インスタンスに適用されるすべての制約が依然として有効であることを意味する。例えば、サーバへの接続を必要とするクライアントのインスタンスを生成する場合、クライアントを生成して接続するのに使用されるアクションのシーケンスが完了したときにも、クライアントとサーバとの間に接続が存在すべきである。
【０４６５】
モデル一貫性を評価するのに使用される制約は、アクションベースで、またはアクションのセットの終わりに評価することができる。この２つの型の一貫性を、動作一貫性およびトランザクション一貫性と呼ぶ。
【０４６６】
トランザクション完了後にオブジェクトの一貫性がなくなる場合、ユーザはこのインスタンスを明示的にオフラインとしてマークすることができる。インスタンスがオフラインのときは、インスタンスに適用される制約は評価されず、他のインスタンスからはこのインスタンスが存在するようには見えない。このことは、これらのインスタンスもまたすべてオフラインとしてマークすべきであることを意味する場合がある。オフラインは、親から子へ、ホストからゲストへ伝搬される。したがって、システムをオフラインとしてマークすることは、システムによって所有されるすべてのインスタンスをオフラインとしてマークし、システム上でホストされるすべてのインスタンスをオフラインとしてマークすることになる。
【０４６７】
３．１３  モデル評価
この章では、ＳＤＭランタイムの範囲内におけるＳＤＭモデルの挙動について述べる。
【０４６８】
３．１３．１  定義空間
定義空間は、ＳＤＭランタイムに知られているすべての定義を含む。図１８の各ステップに、新しい定義をランタイム内にロードする例示的なプロセスを規定する。このプロセスはまた、設計表面がＳＤＭ文書を妥当性検査するときに行われるコンパイルプロセスでも共有される。
【０４６９】
３．１３．１．１  ロード
ＳＤＭ文書は、ＳＤＵの一部として、またはスタンドアロン文書としてランタイムに提示される。ファイルをディスクからロードすることが試みられる。
【０４７０】
【表５９】
2011070707.tif 000130
【０４７１】
３．１３．１．２  スキーマ妥当性検査
第１のステップでは、ＳＤＭ文書がＳＤＭスキーマとマッチすることを妥当性検査する。この時点で、すべての未知要素、必要要素の不足している型、無効なデータを含む属性または型については、エラーを返す。
【０４７２】
【表６０】
2011070707.tif 000131
【０４７３】
３．１３．１．３  設定値および型解決
型解決フェーズでは、ＳＤＭファイル内の型への参照をすべて解決する（スキーマ中で修飾名が使用されている位置ならどこでも）。まず、文書の範囲内にあるすべての型参照が有効であることを妥当性検査する。これらはすべて、エイリアスを含まない型参照である。次いで、すべてのインポートステートメントを解決することを試みる。インポートステートメントを解決することができない場合は、名前空間ロードエラーを生成し、インポートステートメントを解決することができる場合は、名前空間内で型を突き止めることを試みる。ＳＤＭファイルから名前空間をロードしなければならない場合、名前空間解決プロセスは他のエラーを生じる場合がある。
【０４７４】
【表６１】
2011070707.tif 000132
【０４７５】
３．１３．１．４  パス解決
パス解決フェーズの間、文書中で定義されたメンバおよび設定へのパスをすべて解決することを試みる。未解決の型を有するメンバまたは設定を参照するパスはエラーを生じない。
【０４７６】
【表６２】
2011070707.tif 000133
【０４７７】
【表６３】
2011070707.tif 000134
【０４７８】
３．１３．１．５  関係への参与
型空間で、型宣言がそのメンバの関係参与に関してどんな制約にも違反しないことをチェックする。これを行うために、関連する設定制約を有さないすべての型および関係制約を評価する。
【０４７９】
【表６４】
2011070707.tif 000135
【０４８０】
【表６５】
2011070707.tif 000136
【０４８１】
３．１３．１．６  インスタンスシミュレーション
インスタンスシミュレーションでは、失敗するとわかっている制約は識別し、ユーザ入力に基づいて失敗する場合としない場合がある制約にはフラグを立てないようにすることができるような方式で、値をフローして制約を評価することを試みる。こうするためには、インスタンス空間のモデルを構築し、このインスタンス空間に基づくフローおよび制約を評価する。フローまたは制約がエラーになることがわかっている場合はエラーを発し、エラーになる可能性がある場合は警告を発する。
【０４８２】
すべてのｂｙＲｅｆｅｒｅｍｃｅシステム上のｍｉｎＯｃｃｕｒｓ制約を使用して、インスタンス空間変更要求を構築する。ｍｉｎＯｃｃｕｒｓが０のときは、単一のインスタンスを生成し、オプションとしてマークする。次いで、標準の変更要求に使用したのと同じ展開プロセスおよびフロープロセスを通して変更要求を渡す。
【０４８３】
【表６６】
2011070707.tif 000137
【０４８４】
次いで、完全に定義された入力値を有するすべてのフローを評価する。入力値が固定でなく、ユーザによって変更できる場合は、このフローの出力を仮としてマークする。仮入力は、それを消費するどんなフロー演算によっても連鎖することになる。フローが完全な入力値を有さず、ユーザが値を提供できる場合は、このフローのすべての出力を未定義としてマークする。オプションのシステムからのフローもまた、仮の値を生じる。
【０４８５】
【表６７】
2011070707.tif 000138
【０４８６】
値をフローした後は、これらの値に基づいて制約を評価する。値を供給できなかった制約には警告を発する。また、未定義の値であるために制約が評価できなかったときにも警告を発する。
【０４８７】
【表６８】
2011070707.tif 000139
【０４８８】
【表６９】
2011070707.tif 000140
【０４８９】
３．１３．２  インスタンス空間
モデル評価プロセスは、宣言変更要求をサブミットすることによって開始する。この要求は、ランタイム内のインスタンスをターゲットとした生成、更新、または削除操作のセットを含む。次いで、図１９に示すように、要求を一連のパイプラインステージに通した後、必要な変更をターゲットシステムに対して実施する。  
以下の各章で、各展開（expansion）ステップの役割を概説する。
【０４９０】
３．１３．２．１  要求のサブミット
システムに対する変更を開始するために、オペレータまたはプロセスは、変更要求をサブミットすべきである。変更要求は、オペレータがランタイム内のインスタンスに対して実施したいと思うアクションのセットを含む。これらのアクションは、３つのグループ、すなわち生成アクション、更新アクション、削除アクションに分類される。
【０４９１】
次いで要求は、グループとして完了または失敗すべき原子アクションセットとして扱われる。これにより、制約妥当性検査プロセスは、アクションセットがモデルに対する有効な変更をもたらすかどうかを評価するときに、要求中のすべてのアクションを考慮することができる。
【０４９２】
【表７０】
2011070707.tif 000141
【０４９３】
３．１３．２．１．１  型解決
型解決フェーズでは、変更要求中で参照されるすべての型およびメンバを解決する。変更要求は、これらがすでにランタイムによってロードされていると見なす。これらが存在しない場合は、ランタイムはロード／コンパイルアクションを開始する必要がある。
【０４９４】
３．１３．２．１．２  パス解決
パス解決フェーズの間に、変更要求内の、既存のインスタンスおよび生成アクションによって定義されたインスタンスへの参照を解決する。
【０４９５】
３．１３．２．２  展開（Expansion）
展開は、変更要求について、要求を実行するのに必要な残りのすべてのアクションをポピュレートするプロセスである。一般にこれらのアクションは、型インスタンスおよび関係インスタンスに対する構築アクションおよび破壊アクションである。理論的には、オペレータは、インスタンスを構築または破壊するのに必要なすべてのアクションに関する詳細を提供することができるが、これは変更要求オーサリングプロセスを非常に複雑にするので、必要とされない。そうではなく、このプロセスをできるだけ自動化することが試みられる。オペレータは、ｂｙＲｅｒｅｆｅｎｃｅメンバに対するアクションを識別することにより、オペレータが望む変更に関するキー情報を提供する。すると、ネストされたｂｙＲｅｆｅｒｅｎｃｅおよびｂｙＶａｌｕｅメンバと関係に対して、アクションの残りが埋められる。
【０４９６】
３．１３．２．２．１  値メンバ
展開ステージの間、すべての非参照型メンバを識別する。これらのメンバのカーディナリティはわかっており、必要なすべてのパラメータはわかっている。したがって、各メンバごとに、親の生成中であるメンバについては生成要求を変更要求に追加する。変更要求が破壊動作を含む場合は、それらに含まれるすべてのインスタンスについて破壊動作を追加する。
【０４９７】
３．１３．２．２．２  参照メンバの展開（発見）
一般に、参照メンバを構築するには、値メンバよりも多くの情報が必要である。これらのカーディナリティはしばしば未定義であり、インスタンスが構築されるための値を必要とする展開時設定を有する可能性がある。したがって、ｂｙＲｅｆｅｒｅｎｃｅメンバを展開するプロセスは、インスタンスに関する情報として、ランタイムが提供できるよりも多くの情報を必要とする可能性がある。この情報を得るためのプロセスを、発見と呼ぶ。
【０４９８】
発見のプロセスは、構築または更新アクションの一部として参照型メンバをポピュレートする。発見をサポートするオブジェクトマネージャを有する参照メンバだけが、このプロセスに参与する。
【０４９９】
新しいインスタンスが発見されたときは、まず、インスタンス特有のキー値を使用して、このインスタンスがまだＳＤＭデータベース中に存在しないことをチェックする。新しいインスタンスであることがわかれば、次いで、発見中のメンバの型に従ってインスタンスを分類する。インスタンスがメンバにマッチしない場合、または曖昧なマッチがある場合は、メンバ参照は空白のままにし、インスタンスはオフラインおよび不完全としてマークする。
【０５００】
３．１３．２．２．３  関係の展開
構築されることになる型インスタンスがすべてわかった後で、型インスタンスを１つにバインドする関係インスタンスを生成する。型インスタンスの破壊中である場合は、型インスタンスを参照するすべての関係インスタンスを削除する。
【０５０１】
関係を生成するには、メンバ空間に目を向けて、インスタンス間に存在すべき関係の構成を識別する。型メンバが１よりも大きいカーディナリティを有する場合は、関係のトポロジを推論しなければならない。これをどうやって行うかについては、ＸＸ章で詳細に論じる。
【０５０２】
３．１３．２．３  フロー
フローステージの間、すべての関係インスタンスにわたってフローを評価する。このステージでは、改変されたパラメータフローの影響を受けたインスタンスについて、変更要求に更新要求を追加することができる。
【０５０３】
フローは、変更要求の結果として設定が更新されたインスタンスのセットを判定することによって評価する。これらのそれぞれにつき、修正された設定に依存する送出設定フローがあればそれを評価し、変更されたインスタンスのセットにターゲットノードを追加する。このプロセスは、セットが空になるまで、またはセットが循環を含むまで継続する。
【０５０４】
【表７１】
2011070707.tif 000142
【０５０５】
３．１３．２．４  重複検出
重複検出のプロセスでは、展開されたインスタンスを、ＳＤＭデータ記憶域中にすでに存在するインスタンスと照合する。例えば、別のアプリケーションが共有ファイルをインストールしたかどうかを検出する。インスタンスがすでに存在することが検出されたときは、既存のインスタンスのバージョンに応じて、以下のようないくつかのアクションの１つを実施することができる。  
ａ）インストールを失敗にする。  
ｂ）インスタンスを参照カウントする。  
ｃ）インスタンスをアップグレードする。  
ｄ）インストールを並行して実施する。
【０５０６】
３．１３．２．５  制約評価
制約評価フェーズの間には、変更要求が処理された後でもモデル中のすべての制約がまだ有効となるかどうかをチェックする。
【０５０７】
【表７２】
2011070707.tif 000143
【０５０８】
３．１３．２．６  要求の順序付け
この時点では完全なアクションリストがあるので、システム間の関係を使用して、有効な変更順序付けを決定することができる。
【０５０９】
３．１３．２．７  実行
マシン特有の順序付けされたアクションセットのサブセットを配信する。これらのマシン特有セットのマシン間同期をサポートすべきである。
【０５１０】
３．１３．２．８  要求返却
変更は、影響を受けるホスティング関係に基づいて変更要求を配信可能部分に分解することによって行う。すべての部分が完了（または失敗）すると、ランタイム内で結果を照合し、概要をユーザに返す。
【０５１１】
３．１３．３  展開の詳細
この章では、型および関係に関する展開（expansion）プロセスについて詳細に検討する。
【０５１２】
３．１３．３．１  参照メンバの展開（発見）
ホスティング関係が、ある型の新しいインスタンスを構築することを担うのと同様にして、ホスティング関係は、既存の型インスタンスの発見を行うのにも使用される。ある型のインスタンスがホスト上で表される方式はホスティング関係だけが意識しているので、これを行うために、ホスティング関係を独特に配置する。
【０５１３】
参照メンバに発見のマークが付されているとき、ホスティング関係が発見をサポートするかどうかをチェックする。サポートする場合は、その関係にホストインスタンスを渡し、関係がホスト上で見つけたゲストインスタンスに対する構築アクションを返すよう関係に要求する。
【０５１４】
検証を使用して、インスタンスがもう存在しないことを発見する。この場合もまたホスティング関係を使用して、ホスト上のゲストの存在を検証する。ゲストがもう存在しない場合、ホスティング関係は、破壊アクションを変更要求に追加する。
【０５１５】
３．１３．３．２  非参照メンバの展開
ランタイムは、変更要求内の構築または破壊アクションについてすでに識別された型の各非参照メンバに対して構築または破壊アクションを単に追加することにより、すべての非参照メンバ展開を処理する。
【０５１６】
３．１３．３．３  通信関係の展開
２つの型メンバ間に通信関係メンバが存在する場合にオペレータが通信関係のインスタンスを指定していない場合は、完全に接続されたメッシュがメンバ間にあると仮定することにより、通信関係を展開する。
【０５１７】
【表７３】
2011070707.tif 000144
【０５１８】
これは何を意味しているだろうか。２つのメンバがメンバ空間で接続されている場合、各メンバのすべてのインスタンスは相互に見えていなければならない。図２０に示すように、以下の２つのメンバがある場合、インスタンス空間トポロジはメンバのカーディナリティによって制約される。１８００に、例示的な２つのメンバを示す。１８０２に、最大の２つのインスタンス間の単純なポイントツーポイント関係を示す。１８０４に、接続のファンアウト（fun out）を示す。一例は、サーバのセット全体にわたって要求の負荷バランスをとることのできるクライアントであろう。１８０６に、接続のファンイン（fan in）を示す。一例は、単一のサーバを共有するクライアントグループであろう。１８０８に、これらの場合の組合せを示す。１８０８では、クライアントのセットがサーバのセットを共有している。
【０５１９】
通信リンクを構築するとき、委任エンドポイントが削除されたとしても存在するであろうすべての通信関係とマッチする接続になるように、委任エンドポイントはトランスペアレントになる。図２１に、２つの構造１９０２および１９０４を示す。これらは、インスタンスＡ、Ｂ、Ｃ間の接続に関する限り等価である。
【０５２０】
３．１３．３．４  ホスティング関係の展開
ホスティング関係が曖昧な場合、オペレータまたはホスティング関係のマネージャが正しいトポロジを判定することが必要である。
【０５２１】
ホスティング関係が展開をサポートする場合は、ホストとゲストのセットを関係マネージャに渡し、正しい構築アクションを返すようマネージャに要求する。マネージャが展開をサポートしない場合は、オペレータがより多くの情報を提供することができるように、オペレータに変更要求を返す。
【０５２２】
３．１３．３．５  参照関係の展開
【０５２３】
３．１３．３．６  包含関係の展開
包含関係が曖昧であることはないので、ランタイムは常に適切な構築アクションを変更要求に追加することができる。
【０５２４】
３．１３．３．７  委任関係の展開
展開では、委任関係は通信関係と同じ規則に従う。
【０５２５】
３．１３．４  フロー
【０５２６】
３．１３．５  実行
【０５２７】
３．１４  ＳＤＭインスタンス空間
以下の章では、ＳＤＭランタイムのインスタンス空間に関するオブジェクトモデルを定義する。インスタンス空間を使用して、ＳＤＭによってモデル化されるシステムの構成に対する変更を追跡する。
【０５２８】
図２２に、インスタンス空間の概観を提供する例示的なＵＭＬ図を示す。ボックス２００２、２００４、２００６、２００８は、この文書の他の章で定義した型を示す。
【０５２９】
インスタンス空間は、変更要求によって開始されるバージョニングされた変更をとりまいて構築される。各インスタンスは、実行中のインスタンスに加えられた原子的な変更を表す線形に連続するバージョンを有することができる。将来のバージョンが、実行中のシステムに伝わる前にランタイム内に存在することもできる。
【０５３０】
ＳＤＭモデルのこのバージョンでは、所与のインスタンスに対して線形変更だけが可能である。将来は、バージョン分岐が可能になり、バージョン解決モデルが導入されるであろう。これにより、特定のインスタンスに対して複数の変更を未解決とすることが可能になる。
【０５３１】
線形バージョニングが可能なので、前の変更の上に形成される一連の変更要求をロードすることができる。これは、ローリングアップグレードなどのプロセス中に実施される場合のある一連のアクションの事前妥当性検査をサポートする。
【０５３２】
３．１４．１  ＳＤＭインスタンス
すべてのインスタンスは、ＳＤＭインスタンスから派生する。これらは、設定スキーマに関する値を定義する要素と、インスタンスの定義上のメンバとマッチするメンバのリストを定義する要素とを共有する。これらはまた、インスタンスの固有の識別子と、インスタンスのバージョン番号と、インスタンスの名前と、このバージョンがシステムの実行状態を表すかどうかを示すフラグとを定義する属性のセットも共有する。
【０５３３】
【数６６】
2011070707.tif 000145
【０５３４】
【表７４】
2011070707.tif 000146
【０５３５】
３．１４．２  メンバ
ｍｅｍｂｅｒは、インスタンスのメンバを、参照されるインスタンスのセットに関連付けるのに使用する。インスタンスのメンバは、インスタンスの定義によって定義される。参照されるインスタンスは、メンバに対して生成されたインスタンス、またはメンバが委任されるインスタンスである。メンバはアレイを表すことができ、その場合は複数の被参照インスタンスがあるものとすることができる。
【０５３６】
【数６７】
2011070707.tif 000147
【０５３７】
【表７５】
2011070707.tif 000148
【０５３８】
３．１４．３  変更
ｃｈａｎｇｅは、インスタンス状態に対する変更を表す。これは、変更要求を、影響を受けるインスタンスのセットに関連付ける。また、変更のステータス（ＸＸＸ章参照）、および変更が実行された場合の変更応答も識別する。
【０５３９】
【数６８】
2011070707.tif 000149
【０５４０】
【表７６】
2011070707.tif 000150
【０５４１】
３．１４．３．１  変更ステータス
変更要求は、以下の状態の１つまたは複数をとることができる。  
・ｎｏｔＳｔａｒｔｅｄ−変更要求に対して実行が試みられていないことを示す。  
・ｉｎＰｒｏｇｒｅｓｓ−現在実行されていることを示す。  
・ｃｏｍｐｌｅｔｅ−変更要求がうまく完了したことを示す。  
・ｆａｉｌｅｄ−変更要求が失敗し、変更が未完了の状態であることを示す。  
・ｒｏｌｌｅｄＢａｃｋ−失敗した変更要求がうまくロールバックされたことを示す。
【０５４２】
【数６９】
2011070707.tif 000151
【０５４３】
３．１４．４  具象オブジェクトインスタンス
具象オブジェクトインスタンスは、型属性によって識別される具象型のインスタンスを表す。インスタンスには実世界表現がある可能性があるので、インスタンスがその実世界の相対物と同期しているかどうか追跡する必要がある。また、この変更の結果としてインスタンスがオンラインになるかどうかを知ることも望まれる。オンラインのインスタンスは、そのすべての制約に関して有効であるべきである。オフラインのインスタンスは、それが参与している通信関係の他の参与者には見えない。インスタンスが不完全な場合は、インスタンスをオンラインにできるようになる前に、さらに変更要求が必要である。
【０５４４】
<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>
【０５４５】
【表７７】
2011070707.tif 000152
【０５４６】
３．１４．５  関係インスタンス
ｒｅｌａｔｉｏｎｓｈｉｐ  ｉｎｓｔａｎｃｅは、識別された関係型のインスタンスを表す。関係には直接的な実世界表現がないので、関係が同期しているまたはオンラインであるかどうかに関する情報を保持している必要がある。また関係は、それらの制約を満たせない可能性もあるが、相対的に単純なので、不完全であることは予想されない。
【０５４７】
【数７０】
2011070707.tif 000153
【０５４８】
【表７８】
2011070707.tif 000154
【０５４９】
３．１４．５．１  ｃｏｎｔａｉｎｍｅｎｔ  ｉｎｓｔａｎｃｅ
これは包含関係のインスタンスを表す。
【０５５０】
【数７１】
2011070707.tif 000155
【０５５１】
【表７９】
2011070707.tif 000156
【０５５２】
３．１４．５．２  ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｉｎｓｔａｎｃｅ
これは通信関係のインスタンスを表す。
【０５５３】
【数７２】
2011070707.tif 000157
【０５５４】
【表８０】
2011070707.tif 000158
【０５５５】
３．１４．５．３  ｄｅｌｅｇａｔｉｏｎ  ｉｎｓｔａｎｃｅ
これは委任関係のインスタンスを表す。
【０５５６】
【数７３】
2011070707.tif 000159
【０５５７】
【表８１】
2011070707.tif 000160
【０５５８】
３．１４．５．４  ｈｏｓｔｉｎｇ  ｉｎｓｔａｎｃｅ
これはホスティング関係のインスタンスを表す。
【０５５９】
【数７４】
2011070707.tif 000161
【０５６０】
【表８２】
2011070707.tif 000162
【０５６１】
３．１４．５．５  ｒｅｆｅｒｅｎｃｅ  ｉｎｓｔａｎｃｅ
これは参照関係のインスタンスを表す。
【０５６２】
【数７５】
2011070707.tif 000163
【０５６３】
【表８３】
2011070707.tif 000164
【０５６４】
３．１４．６  インスタンス
ｉｎｓｔａｎｃｅｓグループは、ＳＤＭインスタンスファイル中に存在することのできるインスタンス要素のセットを表す。
【０５６５】
<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>
【０５６６】
３．１４．７  インスタンス参照
【０５６７】
３．１４．７．１  ｉｎｓｔａｎｃｅ  Ｒｅｆ
ｉｎｓｔａｎｃｅ  Ｒｅｆは、インスタンスへの単純な参照である。参照が変更要求のコンテキストでなされ、インスタンスが変更要求の影響を受けるのでない限り、デフォルトではｉｓＣｕｒｒｅｎｔインスタンスになる。
【０５６８】
【数７６】
2011070707.tif 000165
【０５６９】
３．１４．７．２  ｉｎｓｔａｎｃｅ  Ｖｅｒｓｉｏｎ  Ｒｅｆ
ｉｎｓｔａｎｃｅ  Ｖｅｒｓｉｏｎ  Ｒｅｆは、インスタンスの特定のバージョンを識別する。
【０５７０】
【数７７】
2011070707.tif 000166
【０５７１】
３．１５  展開（deployment）ユニットの構造
要件
・ＳＤＭ型のセットをインストールするのに必要なすべてのビットを含む。 
・署名およびバージョニングができる。 
・容易に構築／パッケージ／出荷できる。 
・参照または包含によって他のＳＤＵを参照することができる。 
・ＳＤＭ型定義の展開セクションがＳＤＵ中のファイルを直接参照する。 
【０５７２】
３．１６  ローカライゼーション
ＳＤＭモデルのどの部分がローカライゼーションをサポートし、システムの設計および展開を通してどのようにローカライゼーションがサポートされるかを決定する必要がある。
【０５７３】
第１の手法：
ローカライゼーションは、個々の型および管理すべき型に完全に任される。ローカライゼーションは、制約を介して暗黙的である。ローカライゼーションは第１タイプ市民（first type citizen）ではない。これは以下のことを意味する。
【０５７４】
ａ）ＳＤＵは、特定バージョンの型の実装を含むことができる。すなわち、特定バージョンの実装が１つある。このことは、違いがローカライゼーションのみに基づく実装はあり得ないことを意味する。したがって、各実装は一定範囲のロケールをサポートすべきであり、あるいは実装は異なる型とすべきである（この目的でバージョニングを使用するのは良くないことである！）。 
ｂ）次いで、リソースをｍｉｘｉｎとして使用して特定バージョンをサポートすることによって、あるいは、異なるバージョンをサポートする実装を識別する型のセットを使用することによって、ローカライゼーションを達成する。 
ｃ）クライアントは、ローカライズされたバージョンのサーバを区別／要求することはできない。
【０５７５】
第２の手法：
ローカライゼーションは、名前およびバージョンに沿った識別の第１タイプ市民である。このことは、型への参照が行われる位置ではどこでもローカライゼーションを考慮すべきであることを意味する。 
ａ）クライアントはこの場合、包含関係、ホスティング関係、通信関係のいずれでも、ローカライズされたバージョンのサーバを区別することができる。 
ｂ）展開エンジンは、ローカライゼーションを意識すべきであり、ローカライズされたバージョンの型間でオペレータが選択できるようにすべきである。 
ｃ）ＳＤＵは名前、バージョン、およびロケールで識別される。あるいはＳＤＵは、違いが場所のみに基づく複数の実装を含むことができる。（第１の場合は、ローカライズされないコードを別個のＳＤＵ中に配置すべきなので、よりきめ細かいＳＤＵのパッケージングを意味する。第２の場合は、同じ名前で複数のＳＤＵを有することができることを意味する。）
【０５７６】
第２の手法は、ロケールが制約として広く使用された場合、設計／ＵＩから見て非常に複雑になる可能性がある。例えば、エンドポイントがローカライズされた場合、またはホストがそれらのゲストをローカライズした場合、接続／配置を見つけるのはずっと複雑になる。第２の手法を、提案した機構として第１の手法のｂ）と共に使用した場合、複雑さはより扱いやすいかもしれないが、ローカライズされたリソースを誰かが識別し、パッケージし、発送しなければならない。
【０５７７】
３．１７  バージョニングおよび変更管理
【０５７８】
３．１７．１  一般的なコメント
・システムをその場でバージョニングできることが望ましい。すなわち、インスタンス識別を変更せずにＱＦＥをＳＱＬに適用できることが望ましい。これは、インスタンスの型を変更することを意味する。 
・バージョニングポリシーが、許容されるバージョン変更を制御できるようにすることが望ましい。例えば、システム型の設計者が、システムのメンバに対するバージョニングポリシーがどのくらい厳しいかを選択することができ、あるいはオペレータが、セキュリティ上の理由から一方的にメンバのバージョンをアップグレードすることができる。 
・バージョニング変更の伝搬を制限することが望ましい。例えば、メンバの型を変更した場合に、システムの型を変更しなければならず、したがって型変更をルートに伝搬しなければならないのは望ましくない。 
・途切れのある変更は、バージョン番号の最初の２つの部分の変化によって示され、途切れのない変更は、バージョン番号の第２の２つの部分の変化によって示される。
【０５７９】
例示的なコンピュータ環境 
図２３に、本明細書に述べた技法を実施するのに使用できる一般的なコンピュータ環境２３００の例を示す。コンピュータ環境２３００は、コンピューティング環境の一例にすぎず、コンピュータおよびネットワークアーキテクチャの使用または機能の範囲に関してどんな制限も意味するものではない。またコンピュータ環境２３００は、この例示的なコンピュータ環境２３００に示すコンポーネントのいずれか１つまたは組合せに関してどんな依存も要件も有するものと解釈すべきではない。
【０５８０】
コンピュータ環境２３００は、コンピュータ２３０２の形の汎用コンピューティングデバイスを含む。コンピュータ２３０２は、例えば図１のコンピューティングデバイス１０２とすることもでき、図２の開発システム２０２を実装することもでき、図２のコントローラ２０６とすることもでき、図２のターゲットデバイス２３２とすることもでき、図６のコントローラ５２０またはターゲット５２２とすることもできる。コンピュータ２３０２のコンポーネントには、限定しないが、１つまたは複数のプロセッサまたは処理ユニット２３０４と、システムメモリ２３０６と、プロセッサ２３０４を含めた様々なシステムコンポーネントをシステムメモリ２３０６に結合するシステムバス２３０８とを含めることができる。
【０５８１】
システムバス２３０８は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、周辺バス、ＡＧＰ（ａｃｃｅｌｅｒａｔｅｄ  ｇｒａｐｈｉｃｓ  ｐｏｒｔ）、プロセッサバスまたはローカルバスを含めて、いくつかのタイプのバス構造の任意の１つまたは複数を表す。例えばこのようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ  Ｓｔａｎｄａｒｄ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ  Ｃｈａｎｎｅｌ  Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ  ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｓｔａｎｄａｒｄｓ  Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスを含めることができる。
【０５８２】
コンピュータ２３０２は通常、様々なコンピュータ可読媒体を備える。このような媒体は、コンピュータ２３０２からアクセス可能な任意の利用可能な媒体とすることができ、揮発性と不揮発性、リムーバブルとノンリムーバブルの両方の媒体が含まれる。
【０５８３】
システムメモリ２３０６は、ランダムアクセスメモリ（ＲＡＭ）２３１０などの揮発性メモリ、および／または、読出し専用メモリ（ＲＯＭ）２３１２などの不揮発性メモリの形のコンピュータ可読媒体を含む。ＲＯＭ２３１２には、起動中などにコンピュータ２３０２内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ  ｉｎｐｕｔ／ｏｕｔｐｕｔ  ｓｙｓｔｅｍ）２３１４が記憶されている。ＲＡＭ２３１０は通常、プロセッサ２３０４からすぐにアクセス可能な、かつ／またはプロセッサ２３０４が現在作用している、データおよび／またはプログラムモジュールを含む。
【０５８４】
コンピュータ２３０２は、その他のリムーバブル／ノンリムーバブル、揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例えば図２１には、ノンリムーバブルかつ不揮発性の磁気媒体（図示せず）に対して読み書きするためのハードディスクドライブ２３１６と、リムーバブルかつ不揮発性の磁気ディスク２３２０（例えば「フロッピー（登録商標）ディスク」）に対して読み書きするための磁気ディスクドライブ２３１８と、ＣＤ（compact disc）−ＲＯＭやＤＶＤ（Digital Versatile Disc）−ＲＯＭやその他の光媒体などリムーバブルかつ不揮発性の光ディスク２３２４に対して読み書きするための光ディスクドライブ２３２２を示す。ハードディスクドライブ２３１６、磁気ディスクドライブ２３１８、および光ディスクドライブ２３２２はそれぞれ、１つまたは複数のデータ媒体インタフェース２３２６によってシステムバス２３０８に接続される。あるいは、ハードディスクドライブ２３１６、磁気ディスクドライブ２３１８、および光ディスクドライブ２３２２は、１つまたは複数のインタフェース（図示せず）によってシステムバス２３０８に接続されてもよい。
【０５８５】
各ディスクドライブおよびそれらに関連するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびその他のデータの不揮発性記憶域をコンピュータ２３０２に提供する。この例では、ハードディスク２３１６、リムーバブルな磁気ディスク２３２０、およびリムーバブルな光ディスク２３２４が示してあるが、磁気カセットまたは他の磁気記憶デバイス、フラッシュメモリカード、ＣＤ−ＲＯＭ、ＤＶＤまたは他の光記憶装置、ランダムアクセスメモリ（ＲＡＭ）、読出し専用メモリ（ＲＯＭ）、ＥＥＰＲＯＭ（Electronically Erasable and Programmable Read Only Memory）など、コンピュータからアクセス可能なデータを記憶することのできる他のタイプのコンピュータ可読媒体も、この例示的なコンピューティングシステムおよび環境を実現するのに利用できることを理解されたい。
【０５８６】
ハードディスク２３１６、磁気ディスク２３２０、光ディスク２３２４、ＲＯＭ２３１２、および／またはＲＡＭ２３１０には、任意の数のプログラムモジュールを記憶することができる。例えばこれらには、オペレーティングシステム２３２６、１つまたは複数のアプリケーションプログラム２３２８、その他のプログラムモジュール２３３０、およびプログラムデータ２３３２が含まれる。このようなオペレーティングシステム２３２６、１つまたは複数のアプリケーションプログラム２３２８、その他のプログラムモジュール２３３０、およびプログラムデータ２３３２（またはこれらの何らかの組合せ）はそれぞれ、分散ファイルシステムをサポートする常駐コンポーネントの全部または一部を実装することができる。
【０５８７】
ユーザは、キーボード２３３４やポインティングデバイス２３３６（例えば「マウス」）などの入力デバイスを介して、コンピュータ２３０２にコマンドおよび情報を入力することができる。その他の入力デバイス２３３８（具体的には図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星受信アンテナ、シリアルポート、スキャナ、および／またはその他を含めることができる。これらおよび他の入力デバイスは、システムバス２３０８に結合された入出力インタフェース２３４０を介してプロセッサ２３０４に接続されるが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、その他のインタフェースおよびバス構造で接続されてもよい。
【０５８８】
モニタ２３４２または他のタイプの表示デバイスも、ビデオアダプタ２３４４などのインタフェースを介してシステムバス２３０８に接続することができる。モニタ２３４２に加えて、その他の出力周辺デバイスには、スピーカ（図示せず）やプリンタ２３４６などのコンポーネントを含めることができ、これらは入出力インタフェース２３４０を介してコンピュータ２３０２に接続することができる。
【０５８９】
コンピュータ２３０２は、リモートコンピューティングデバイス２３４８など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。例えばリモートコンピューティングデバイス２３４８は、パーソナルコンピュータ、携帯コンピュータ、サーバ、ルータ、ネットワークコンピュータ、ピアデバイス、またはその他の一般的なネットワークノードなどとすることができる。リモートコンピューティングデバイス２３４８は、コンピュータ２３０２に関して本明細書に述べた要素および機能の多くまたはすべてを備えることのできる携帯コンピュータとして示されている。
【０５９０】
コンピュータ２３０２とリモートコンピュータ２３４８との間の論理接続を、ローカルエリアネットワーク（ＬＡＮ）２３５０および一般的なワイドエリアネットワーク（ＷＡＮ）２３５２として示す。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットでよくみられるものである。
【０５９１】
コンピュータ２３０２は、ＬＡＮネットワーキング環境で実現されるときは、ネットワークインタフェースまたはアダプタ２３５４を介してローカルネットワーク２３５０に接続される。ＷＡＮネットワーキング環境で実現されるときは通常、ワイドネットワーク２３５２を介した通信を確立するためのモデム２３５６または他の手段を備える。モデム２３５６は、コンピュータ２３０２に内蔵でも外付けでもよく、入出力インタフェース２３４０または他の適切な機構を介してシステムバス２３０８に接続することができる。図示のネットワーク接続は例示的なものであり、コンピュータ２３０２と２３４８の間に通信リンクを確立する他の手段を採用することもできることを理解されたい。
【０５９２】
コンピューティング環境２３００で示すようなネットワーク化された環境では、コンピュータ２３０２に関して示すプログラムモジュールまたはその一部を、リモートのメモリ記憶デバイスに記憶することができる。例として、リモートアプリケーションプログラム２３５８が、リモートコンピュータ２３４８のメモリデバイス上にある。アプリケーションプログラム、およびオペレーティングシステムなどその他の実行可能プログラムコンポーネントは、ここでは説明のために個別のブロックとして示してある。ただし、このようなプログラムおよびコンポーネントは、様々な時点でコンピューティングデバイス２３０２の種々の記憶コンポーネント中にあり、コンピュータのデータプロセッサによって実行されることを理解されたい。
【０５９３】
本明細書で、様々なモジュールおよび技法は、１つまたは複数のコンピュータまたは他のデバイスによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な状況で述べることができる。一般にプログラムモジュールは、特定のタスクを実施するか特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。通常、プログラムモジュールの機能は、様々な実施形態で望まれるように結合または分散させることができる。
【０５９４】
これらのモジュールおよび技法の実装形態は、何らかの形のコンピュータ可読媒体に記憶するか、コンピュータ可読媒体を介して送信することができる。コンピュータ可読媒体は、コンピュータからアクセスできる任意の利用可能な媒体とすることができる。限定ではなく例として、コンピュータ可読媒体には、「コンピュータ記憶媒体」および「通信媒体」を含めることができる。
【０５９５】
「コンピュータ記憶媒体」には、コンピュータ可読命令、データ構造、プログラムモジュール、その他のデータなどの情報を記憶するための任意の方法または技術で実現された、揮発性および不揮発性、リムーバブルおよびノンリムーバブルな媒体が含まれる。コンピュータ記憶媒体には、限定しないがＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤまたは他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶デバイスが含まれ、あるいは、所望の情報を記憶するのに使用できコンピュータからアクセスできる他の任意の媒体が含まれる。
【０５９６】
「通信媒体」は通常、搬送波や他のトランスポート機構などの変調データ信号中に、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータを組み入れたものである。通信媒体には、任意の情報送達媒体も含まれる。「変調データ信号」という語は、情報が信号中に符号化される形で１つまたは複数の特性が設定または変更された信号を意味する。限定ではなく例として、通信媒体には、配線式ネットワークや直接配線式接続などの配線式媒体と、音響、無線周波、赤外線、その他の無線媒体などの無線媒体とが含まれる。以上の任意の組合せもコンピュータ可読媒体の範囲に含めるべきである。
【０５９７】
別法として、このフレームワークの一部をハードウェアで、あるいはハードウェア、ソフトウェア、および／またはファームウェアの組合せで実現することもできる。例えば、１つまたは複数の特定用途向け集積回路（ＡＳＩＣ）またはプログラム可能論理デバイス（ＰＬＤ）を、このフレームワークの１つまたは複数の部分を実現するように設計またはプログラムすることができる。
【０５９８】
結び 
本発明を構造上の特徴および／または方法上の動作に特定の言葉で述べたが、添付の特許請求の範囲に定義する本発明は、述べた具体的な特徴または動作に必ずしも限定されないことを理解されたい。そうではなく、これらの具体的な特徴および動作は、特許請求する本発明を実施する例示的な形として開示するものである。さらに、これらの特許請求の範囲は、範囲および主題の点で例示的なものである。本明細書に述べた特徴に関するその他多くの組合せおよび下位の組合せが、後に、本出願に対する優先権を主張する特許出願において請求される場合もある。
【符号の説明】
【０５９９】
２００  例示的なアーキテクチャ
２０２  開発システム
２０４  ＳＤＭ文書
２０６  コントローラ
２０８  展開モジュール
２１０  管理モジュール
２１２  ターゲットデバイス
【図１】
2011070707.tif 000167
【図２】
2011070707.tif 000168
【図３】
2011070707.tif 000169
【図４】
2011070707.tif 000170
【図５】
2011070707.tif 000171
【図６】
2011070707.tif 000172
【図７】
2011070707.tif 000173
【図８】
2011070707.tif 000174
【図９】
2011070707.tif 000175
【図１０】
2011070707.tif 000176
【図１１】
2011070707.tif 000177
【図１２】
2011070707.tif 000178
【図１３】
2011070707.tif 000179
【図１４】
2011070707.tif 000180
【図１５】
2011070707.tif 000181
【図１６】
2011070707.tif 000182
【図１７】
2011070707.tif 000183
【図１８】
2011070707.tif 000184
【図１９】
2011070707.tif 000185
【図２０】
2011070707.tif 000186
【図２１】
2011070707.tif 000187
【図２２】
2011070707.tif 000188
【図２３】
2011070707.tif 000189