(57)【要約】【課題】  分散コンピューティングシステムのためのアーキテクチャ、ならびに分散アプリケーションの自動化された設計、展開、および管理を提供する。【解決手段】  設計ツールが、分散コンピューティングシステムおよび分散アプリケーションの抽象的記述を可能にするサービス定義モデルを含む。設計ツールは、また、サービス定義モデル内の機能上のオペレーションをどのように指定すべきかを指令するスキーマも含む。機能上のオペレーションには、分散アプリケーションの設計、分散アプリケーションの展開、および分散アプリケーションの管理が含まれる。【選択図】  図３
2004272912.tif 000002
【特許請求の範囲】
【請求項１】
分散コンピューティングシステムおよび分散アプリケーションの抽象記述を可能にするサービス定義モデルと、
分散アプリケーションの設計、分散アプリケーションの展開、および分散アプリケーションの管理を含む前記サービス定義モデル内の機能上のオペレーションをどのように指定すべきかを指令するスキーマと
を備えたことを特徴とする設計ツール。
【請求項２】
サービス定義モデル（ＳＤＭ）を使用してアーキテクチャ設計された分散システムの実装をホストすることと、
ＳＤＭタイプを取り扱うための１組のＡＰＩを公開することと、
分散アプリケーションの展開および管理のためにＳＤＭインスタンスを追跡することと
を備えることを特徴とする方法。
【請求項３】
設計時検証のためにＳＤＭインスタンスを追跡することをさらに備えることを特徴とする請求項２に記載の方法。
【請求項４】
前記分散システム上の分散アプリケーションを設計することをさらに備えることを特徴とする請求項２に記載の方法。
【請求項５】
前記サービス定義モデルを使用して前記分散システム上の分散アプリケーションを設計することをさらに備えることを特徴とする請求項２に記載の方法。
【請求項６】
分散アプリケーションを設計することに関連するサービス、分散アプリケーションを展開することに関連するサービス、および分散アプリケーションを管理することに関連するサービスを含むサービス定義モデルに従って物理データセンタを記述することにより、前記物理データセンタを表わすスケール不変の仮想データセンタの設計を容易にすることを備えることを特徴とする方法。
【請求項７】
前記仮想データセンタは、第１のデータセンタおよび第２のデータセンタによってサポートされ、アプリケーション部分と前記仮想データセンタ部分との間の論理モデルマッピングの変更を要することなく、前記アプリケーションを前記第１のデータセンタ、または前記第２のデータセンタに展開することができるようにすることを特徴とする請求項６に記載の方法。
【請求項８】
前記物理データセンタのある特定の論理コンポーネントに関して作成されるインスタンスの数を決定することと、
前記物理データセンタを実装する配線トポロジを決定することと
をさらに備えることを特徴とする請求項６に記載の方法。
【請求項９】
物理リソースおよび分散アプリケーションを自動的に展開することをさらに備えることを特徴とする請求項６に記載の方法。
【請求項１０】
モデルベースの管理アプローチを使用して前記物理データセンタ上で分散アプリケーションを管理することをさらに備えることを特徴とする請求項６に記載の方法。
【請求項１１】
前記物理データセンタは、トリガイベントに応答して一続きのオペレーションタスクを統合するためのオペレーションエンジンを含むことを特徴とする請求項６に記載の方法。
【請求項１２】
前記トリガイベントは、前記サービス定義モデルからのアプリケーションコンテキストにより注釈付されることを特徴とする請求項１１に記載の方法。
【請求項１３】
前記一続きのオペレーションタスクは、リソース管理システムを使用して新たなリソースを展開することを含むことを特徴とする請求項１１に記載の方法。
【請求項１４】
仮想データセンタおよび分散アプリケーションの設計を容易にすることと、
前記仮想データセンタ上に前記分散アプリケーションの部分を論理的に配置することと、
前記仮想データセンタに基づいて物理データセンタを実装することと
を備えることを特徴とする方法。
【請求項１５】
前記仮想データセンタに前記分散アプリケーションの部分を論理的に配置するとき、前記仮想データセンタの運用者のビューは、前記分散アプリケーションの前記配置に関連する部分だけを収容するように制限されることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記仮想データセンタは、複数のサービス定義モデルレイヤを含み、各レイヤはその下のレイヤの上に論理的に配置されるようにすることを特徴とする請求項１４に記載の方法。
【請求項１７】
前記分散アプリケーションをサポートするように前記仮想データセンタのリソースを割り振ることをさらに備えることを特徴とする請求項１４に記載の方法。
【請求項１８】
仮想データセンタおよび分散アプリケーションの設計を容易にすることと、
前記仮想データセンタ上に前記分散アプリケーションの部分を論理的に配置することと、
前記分散アプリケーションの前記部分の前記配置が有効であるかどうかを判定することと
を備えることを特徴とする方法。
【請求項１９】
前記分散アプリケーションの前記部分の前記配置が有効でない場合、警告メッセージを生成することをさらに備えることを特徴とする請求項１８に記載の方法。
【請求項２０】
前記仮想データセンタに基づいて物理データセンタを実装することをさらに備えることを特徴とする請求項１８に記載の方法。
【請求項２１】
前記分散アプリケーションをサポートするように前記仮想データセンタのリソースを割り振ることをさらに備えることを特徴とする請求項１８に記載の方法。
【請求項２２】
分散コンピューティングシステム上で分散アプリケーションを設計し、展開し、管理する際に使用するためのソフトウェアアーキテクチャであって、
マシンを前記分散コンピューティングシステムにて使用されるサーバに変換するために使用するツールのための第１のソフトウェアレイヤと、
分散アプリケーションのネットワーク管理および仮想トポロジ生成のための第２のソフトウェアレイヤと、
前記分散コンピューティングシステムの物理モデルを維持管理する第３のソフトウェアレイヤと、
前記分散アプリケーションによって要求される論理リソースの割り振りを容易にする第４のソフトウェアレイヤと、
オペレーションプロセスを記述するための名前空間およびコンテキストと、アプリケーションイントロスペクションおよびアプリケーションリソースの制御のためのＡＰＩとを提供するサービス定義モデル（ＳＤＭ）のための第５のソフトウェアレイヤと、
分散アプリケーションの再使用可能なビルディングブロックを定義し、コンテキスト、名前付け、およびバインド化のために前記ＳＤＭのＡＰＩを使用する第６のソフトウェアレイヤと、
前記分散アプリケーションのオペレーション上の管理のための第７のソフトレイヤと
を備えたことを特徴とするソフトウェアアーキテクチャ。
【請求項２３】
分散コンピューティングシステム内のリソースを割り振るための手段と、
利用可能なハードウェアを発見するための手段と、
リソース割り振り要求を処理するための手段と、
リソースの所有権を追跡するための手段と、
リソースを制御するための手段と、
前記分散コンピューティングシステム内のすべてのリソース管理のために共通のＡＰＩを提供するための手段と
を備えたことを特徴とするリソースマネージャ。
【請求項２４】
リソースを割り振るための前記手段は、前記分散コンピューティングシステム内の論理リソースおよび物理リソースを割り振るように構成されていることを特徴とする請求項２３に記載のリソースマネージャ。
【請求項２５】
前記分散コンピューティングシステム上で分散アプリケーションを管理するための手段をさらに備えたことを特徴とする請求項２３に記載のリソースマネージャ。
【請求項２６】
リソースを制御するための前記手段は、イベントに応答して一続きのオペレーションタスクを統合するように構成されていることを特徴とする請求項２３に記載のリソースマネージャ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、分散コンピューティングシステムのためのアーキテクチャ、ならびに分散コンピューティングシステム上の分散アプリケーションの自動化された設計、展開、および管理に関する。
【背景技術】
【０００２】
インターネットの使用が、ここ数年に急増し、増加しつづけている。人々は、電子メール、オンラインショッピング、ニュースや情報の収集、音楽の傾聴、ビデオクリップの視聴、職探しなど、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（または、単に「Ｗｅｂ」）上で提供される多くのサービスに非常に満足するようになってきた。インターネットベースのサービスに対する増大する要望に歩調を合わせるように、Ｗｅｂサイトをホストすること、それらのサイトのためのバックエンドサービスを提供すること、およびそれらサイトに関連するデータを格納することに特化したコンピュータシステムが途方もなく成長している。
【０００３】
１つのタイプの分散コンピュータシステムは、インターネットデータセンタ（ＩＤＣ）であり、ＩＤＣは、インターネットベースのサービスをホストするための多くのコンピュータを収容する特別に設計された複合体である。ＩＤＣは、「Ｗｅｂファーム（Ｗｅｂｆａｒｍ）」や「サーバファーム（ｓｅｒｖｅｒ  ｆａｒｍ）」の名前でも通っている空調管理された物理的に安全な建造物に、通常、数百から数千のコンピュータを収容している。これらのコンピュータは、１つまたは複数のインターネットサービスまたはＷｅｂサイトをサポートする１つまたは複数のプログラムを実行するよう互いに接続されている。ＩＤＣは、信頼できるインターネットアクセス、信頼できる電力供給、およびセキュリティで保護された動作環境を提供している。
【０００４】
図１にインターネットデータセンタ１００を示す。インターネットデータセンタ１００は、特別に構築された部屋の中に配置された多くのコンピュータ１０２を有する。コンピュータは、通常サーバとして構成された汎用コンピュータである。インターネットデータセンタは、単一のエンティティのために単一のサイトを収容するように（例えば、Ｙａｈｏｏ！またはＭＳＮのデータセンタ）構築するか、または複数のエンティティのために複数のサイトを収容するように（例えば、複数の会社のサイトをホストするＥｘｏｄｕｓセンタ）構築することができる。
【０００５】
ＩＤＣ１００は、コンピュータリソースを共用する３つのエンティティ、エンティティＡ、エンティティＢ、およびエンティティＣと共に示されている。これらのエンティティは、Ｗｅｂサイト上のプレゼンスを望む様々な会社を表している。ＩＤＣ１００は、大量トラフィックがある場合にこれらのエンティティによって使用することができる追加のコンピュータのプール１０４を有している。例えば、オンライン小売業を行っているエンティティは、クリスマスシーズン中に極めて多くの需要を経験する場合がある。追加のコンピュータにより、その需要を満たすようＩＤＣに柔軟性が与えられる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
今日、大型のＩＤＣは複雑であり、複数のアプリケーションをホストするように求められることが多い。例えば、一部のＷｅｂサイトは、数千のコンピュータを動作させ、多くの分散アプリケーションをホストしている。これらの分散アプリケーションには、運用者がコンピュータをあるネットワークスイッチに物理的に接続するとともに、ＩＤＣ内の配線構成を手作業で配置構成して複雑なアプリケーションをサポートすることを要する複雑なネットワーキング要件があることが多い。この結果、アプリケーション要件に適合するように物理ネットワークトポロジを構築するこの作業は、人間の誤りが生じやすい煩雑で時間のかかるプロセスになる可能性がある。したがって、物理コンピューティングシステム上で分散アプリケーションを設計して展開するための改良された技法の必要性が存在する。
【課題を解決するための手段】
【０００７】
分散コンピューティングシステム上で分散アプリケーションを設計し、展開し、管理するためのアーキテクチャおよび方法を説明する。
【０００８】
図面を通して同様なコンポーネントおよび／または特徴を指すために同様な符号を使用している。
【０００９】
以下の開示では、大規模アプリケーションサービスを伴う分散コンピューティングシステムを設計し、実装するためのアーキテクチャに関するいくつかの態様を説明する。本開示は、サービス定義モデル（ＳＤＭ）およびＳＤＭランタイム環境の説明を含む。本開示は、データセンタコンポーネントをどのようにモデル化するか、分散アプリケーション記述をどのようにモデル化するか、ならびにモデル化されたアプリケーションをモデル化されたデータセンタ上に論理的に配置し、設計時にこの論理配置を検証するための技法などの設計の態様をさらに含む。本開示は、物理リソースを使用してモデルをどのようにインスタンス化するか、物理データセンタにおけるアプリケーション展開を容易にする物理リソース上の分散アプリケーションの物理的配置などの展開の態様をさらに説明する。また、本開示は、ＳＤＭを使用してコンテキスト上の管理フィードバック、追跡（ｔｒａｃｋｉｎｇ）、およびオペレーション（ｏｐｅｒａｔｉｏｎｓ）フィードバックを提供することを含む管理の態様も扱う。本開示は、物理リソースにわたるアプリケーションの展開において使用され、管理の態様をサポートする様々なリソースマネージャについて検討する。
【発明を実施するための最良の形態】
【００１０】
（サービス定義モデル（ＳＤＭ））
サービス定義モデル（ＳＤＭ）は、アプリケーションアーキテクチャ設計者が抽象的な形で分散コンピュータアプリケーションおよびデータセンタを設計するためのツールおよびコンテキストを提供する。モデルは、物理コンピュータリソースおよびソフトウェアによって最終的に実装されることになるアプリケーションの機能単位を表わす１組の要素を定義する。モデル要素は、コンポーネントによって代表される機能オペレーションがどのように指定されるかを指示するスキーマである。
【００１１】
（ＳＤＭの概要）
（序論）
インターネット時代
ここ十年の間に、インターネットがコンピューティングプラットフォームとして現れるのを目の当たりにした。ますます多くのソフトウェア会社が、「サービスとしてのソフトウェア」モデルを取り入れている。それらのサービスは、通常、サーバ、ネットワーキング機器、およびその他の特殊化されたハードウェアを含む多くのマシン上で稼動するいくつかのコンポーネントから成る。緩やかに結合された、非同期プログラミングモデルが標準になりつつある。スケーラビリティ、可用性、および信頼性が、これらの分散サービスの成功には不可欠である。
【００１２】
また、ハードウェアの動向の変化も目の当たりにしている。高密度サーバおよび特化したネットワークハードウェアが、データセンタにおいて普及している。スイッチファブリック（ｓｗｉｔｃｈｅｄ  ｆａｂｒｉｃｓ）が、システムバスに取って代わり、システム構成においてより高い柔軟性を提供している。現在、ハードウェアコストは、専用のオペレーションスタッフの訓練と維持のコストに比べて総所有コスト（ＴＣＯ：Ｔｏｔａｌ  Ｃｏｓｔ  ｏｆ  Ｏｗｎｅｒｓｈｉｐ）の算定基準（ｍｅｔｒｉｃ）において小さな役割しか演じていない。可用性の高いどのサービスにも磐石なオペレーション上の実践がきわめて重要であるが、それらの実践は、人々がマニュアルの手続きを実行することからくる誤謬性のために、首尾一貫して繰り返すのが困難である。台頭するサービスとしてのソフトウェア時代において、開発の焦点は、デスクトップを離れてサーバに移行している。この焦点の変化に伴って、ソフトウェア開発者、ハードウェアベンダ、およびＩＴ専門技術者にあまたの新たな問題が生じている。
【００１３】
◆サービスが大規模化し、複雑化している−サービスは開発するのに時間がかかり、維持管理するのが困難で高いコストがかかり、追加の機能により拡張することに危険が伴う。
◆サービスがモノリシック（ｍｏｎｏｌｉｔｈｉｃ）になりがちである−サービスはカスタムコンポーネントおよび特定の構成に依拠する傾向がある。多くのサービスの部分は、サービスの可用性に影響を及ぼすことなく削除したり、独立してアップグレードしたり、または代替物で置き換えたりすることができない。
◆サービスが特定のハードウェア構成に依拠している−特定のネットワークトポロジであれ、特定のネットワーク機器に対する依存性であれ、ハードウェアとソフトウェアの間のバインド化により、異なるデータセンタ環境においてサービスをホストする能力が大幅に低下する。
◆サービスがオペレーション上の一貫性を要求する−ほとんどのサービスは機能するのにオペレーション担当のスタッフを必要とする。共通プラットフォームの欠如により、コードを再使用し、サービスにわたってオペレーション上の最良の実践を制定する能力が低下する。残念ながら、オペレーションスタッフは各サービスの詳細において訓練されていなければならず、各サービスが発展するに応じてさらに訓練されなければならない。
【００１４】
本明細書を通して、「サービス」および「アプリケーション」という用語は、互換可能なように使用する。一般に、アプリケーションは、分散サービスの集合と見なすことが可能である。例えば、Ｈｏｔｍａｉｌは、各サービスが異なる機能を実行する複数のサービスから成るアプリケーションである。
【００１５】
以上の問題は、デスクトップとＤＯＳの時代（１９８０年代頃）の問題とそれほど違わない。ＤＯＳは、ディスク管理、ファイルシステム、コンソール機能などのアプリケーション開発者にとって価値あるコアサービスを定義した。しかし、ＤＯＳは、多くの複雑なタスクを独立系ソフトウェアベンダ（ＩＳＶ）に任せていた。例として、ＷｏｒｄＰｅｒｆｅｃｔとＬｏｔｕｓ１２３はともに、それぞれのアプリケーション内で印刷をサポートするために、プリンタドライバを独自に書かなければならなかった。同様に、プリンタハードウェアベンダは、製品を成功させるためにソフトウェア会社と取引きしなければならなかった。ＩＳＶおよびハードウェアベンダにとっての参入障壁は、並外れて高かった。これにより、この時代には、数社のソフトウェア会社およびハードウェア会社だけが成功することになった。マイクロソフトは、Ｗｉｎｄｏｗｓ（登録商標）プラットフォームを作成することによってこの問題に対処し、このプラットフォームによって参入の障壁が劇的に下げられた。Ｗｉｎｄｏｗｓ（登録商標）は、ＰＣプラットフォーム上のほとんどのハードウェアデバイスに関する抽象化レイヤを定義した。これにより、ＩＳＶは、特定のハードウェアデバイスをサポートすることに気を配らなければならないことから解放された。Ｗｉｎｄｏｗｓ（登録商標）は、メモリ、ディスク、およびネットワークを含むＰＣ内のすべてのリソースを管理した。また、Ｗｉｎｄｏｗｓ（登録商標）には、ＩＶＳによって利用することが可能な豊かな追加のサービスも付いてきた。このプラットフォームにより、業界の莫大な成長が引き起こされた。Ｗｉｎｄｏｗｓ（登録商標）プラットフォームを対象としたＩＳＶは、極めて生産的であった。共通のプラットフォーム、すなわち、Ｗｉｎｄｏｗｓ（登録商標）を有することの商品化効果により、より安価なハードウェアを提供する多くの新たなハードウェアベンダが登場した。
【００１６】
（サービス定義モデル（ＳＤＭ））
ＳＤＭの基本
ＳＤＭは、
●分散アプリケーション／サービスの設計を容易にする抽象化を定義する。
●オペレーション上の実践の再使用および自動化のためのフレームワークを可能にする。
●分散アプリケーションおよび分散サービスの展開とオペレーションを簡単化する。
【００１７】
ＳＤＭが何であるかを理解するには、今日、サービスの運用者の近くの壁に掲げられた複雑な図として、多々見られるものをＳＤＭが取り込むことを考えると容易になる。これらの図では、ボックスは、通常、サービスの稼動中の要素を表わし、ボックスを結ぶ線は、サービス要素間の通信パスを表わしている。例えば、負荷分散装置が、いくつかのＩＩＳフロントエンドマシンに接続され、それらは、１つまたは複数の中間層（ｍｉｄｄｌｅ−ｔｉｅｒ）サービスまたはバックエンドサービスに接続されている。
【００１８】
ＳＤＭについての別の考え方は、ＳＤＭが分散アプリケーション／サービスの振る舞いのメタモデルであり、そのコンピューティング環境における稼動中のアプリケーション／サービスの「活動中」の青写真でもあるということである。ＳＤＭは、許容可能なソフトウェア動作を含め、そのコンピューティング環境内におけるアプリケーションの構造を宣言的（ｄｅｃｌａｒａｔｉｖｅ）にスケール不変（ｓｃａｌｅ−ｉｎｖａｒｉａｎｔ）の形で取り込む。ハードウェアおよびネットワークリソース間のバインド化、ならびにソフトウェアコンポーネントの有効な動作を含め、サービスのトポロジを宣言的に記述することができることは、極めて強力である。
【００１９】
喩えとして、マイクロソフトのコモンオブジェクトモデル（ＣＯＭ：Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｍｏｄｅｌ）を見ることにする。ＣＯＭは、どのようにコンポーネントがパッケージ化され、登録され、アクティブ化され、発見（ｄｉｓｃｏｖｅｒ）されるかなどを標準化した。ＣＯＭは、存続期間（ｌｉｆｅｔｉｍｅ）、メモリ管理、およびインターフェース実装に関連する厳密な規則を指図する。これらのプリミティブは、コンポーネントをブラックボックスとして扱えるようにするので、相互運用性に不可欠である。ＣＯＭは、イベンティング、自動化、およびＯＬＥなどのより高度なサービスのための基礎である。
【００２０】
同様に、ＳＤＭは、より高度な機能を構築する基礎となるいくつかの基本プリミティブを定義する必要がある。これらのプリミティブは、次のとおりである。
●コンポーネント−実装、展開、および管理の単位
●ポート−関連するタイプおよび１組の有効な操作を有する名前付きエンドポイント
●ワイヤ−ポート間の許容された通信パス
●レイヤ−リソース管理所有権とバインド化の分離
●マッピング−各レイヤにおけるコンポーネント、ポート、およびワイヤの間のバインド化
本明細書の以下の部分では、これらプリミティブのそれぞれについてより詳細に説明する。
【００２１】
コンポーネント、ポート、およびワイヤ
本明細書では、コンポーネント、ポート、およびワイヤを使用して描かれたＭｙＳｅｒｖｉｃｅと呼ばれる簡単なサービスの図式表現を検討することが有用である。図２を参照されたい。この図では、ボックスがコンポーネントを表わし、菱形がポートを表わし、破線がワイヤを表わしている。
●ＭｙＳｅｒｖｉｃｅは、コンポーネントＭｙＦｒｏｎｔＥｎｄおよびＭｙＢａｃｋＥｎｄを使用しているので、複合コンポーネントである。
●ＭｙＳｅｒｖｉｃｅは、ＭｙＦｒｏｎｔＥｎｄコンポーネントによって実装された委任ポートであるＷｅｂと呼ばれる１つの可視ポートを有している。
●ＭｙＦｒｏｎｔＥｎｄは、２つのポート、委任ポート、およびカタログとラベル付けされたポートを有している。
●ＭｙＢａｃｋＥｎｄは、データとラベル付けされた１つのポートを有している。
●ＭｙＦｒｏｎｔＥｎｄおよびＭｙＢａｃｋＥｎｄコンポーネントは、ワイヤを介してカタログポートをデータポートにバインドする潜在的な通信関係を有している。
【００２２】
コンポーネント
コンポーネントは、実装、展開、および管理の単位である。コンポーネントの例は、Ｗｉｎｄｏｗｓ（登録商標）サーバ、ＩＩＳ仮想Ｗｅｂサイト、またはＳＱＬデータベースが稼動している専用サーバである。コンポーネントは、一般に、マシン境界を有するが、単一のＩＩＳサーバ上でホストされるＷｅｂサービスによって証されるように必須ではない。
【００２３】
コンポーネントは、ポートを通して機能を公開し、ワイヤを通して通信する。単純なコンポーネントは、メンバとしてポートのみを有することができる。他のコンポーネントを使用するコンポーネントは、複合コンポーネントと呼ばれ、他のコンポーネントに加えてメンバとしてポートおよびワイヤを有することができる。
【００２４】
複合コンポーネントは、コンポジションを通じて作成され、それらに関連する実装をまったく持たない。複合コンポーネントポートは、内部コンポーネントからの委任されたポートである。複合コンポーネントは、コロケーション、カプセル化、および再使用を可能にし、したがって、アプリケーション／サービス、そしてその振る舞いを編成する方法と考えることができる。
【００２５】
コンポーネントの公開ポートだけが、コンポーネントの外部に可視である。複合コンポーネントは、外界には、使用するコンポーネントの内部構造がカプセル化を通して隠された状態で、単純なコンポーネントのように見える。実際、単純なコンポーネントと複合コンポーネントの両方によってサポートされるポートタイプおよび動作がまったく同じである限りこれらを置き換えることが可能である。
【００２６】
ポート
ポートは、１組の振る舞いを定義する名前付きエンドポイントである。ポートは、関連するタイプまたは役割を有し、通常、１組の許可された操作に関連している。ポートの例は、ＨＴＴＰサーバポート、１組の許可された操作を有するＳＯＡＰポートなどである。ポートは、委任することができ、これは、外部コンポーネントが内部コンポーネントのポートを自らのポートとして公開できることを意味する。ポートは、コンポーネントに対して公開インターフェース（振る舞い）を形成する。ポートだけが、公開（可視に）することができるコンポーネントメンバである。
【００２７】
ワイヤ
ワイヤは、ポート間の許可されたバインド化であり、ポート（およびコンポーネント）間のトポロジ上の関係を表わす。ワイヤは、何らインスタンス相互接続トポロジを指定せず、代わりに、インスタンス相互接続トポロジに関する「可能性」を表現する。
【００２８】
ワイヤは、基本的には、バスであり、１つまたは複数のポートメンバを収容することができる。ワイヤをポイントツーポイントの関係ととらえてはならない。ある所与のポートが同一ワイヤ内で再び現れることはできない。
【００２９】
スキーマ
アプリケーション／サービスを記述するために、ＳＤＭに関する標準スキーマを有することが必要である。ＳＤＭスキーマは、ＸＳＤおよびＸＭＬ文法を使用して表現可能であるべきである。ＳＤＭスキーマを詳細に説明することは本明細書の範囲外であるが、本明細書で後に説明する主題の文脈としていくらかの簡潔な説明を提供することが必要である。以下は、ＳＤＭスキーマの簡略図である。
＜sdm＞
＜identityReference /＞
＜portClasses/＞
＜wireClasses /＞
＜componentClasses /＞
＜hostRelations /＞
＜portTypes /＞
＜wireTypes /＞
＜componentTypes /＞
＜/sdm＞
ＳＤＭスキーマに関するさらに詳細な情報については、http://big/にあるＳＤＭスキーマ仕様およびサンプルＸＳＤファイルを閲覧されたい。
【００３０】
ＳＤＭクラス
アプリケーション／サービスにおけるどのコンポーネント、ポート、およびワイヤもクラスの使用を通じて作成されたタイプである。新しいタイプを既存のクラスおよびタイプから作成することができる。ＳＤＭクラスは、基本的に、共通の特徴に関する抽象化である。例えば、Ｗｅｂ  Ｓｅｒｖｉｃｅは、ＳＱＬ  Ｄａｔａｂａｓｅと同様に、クラスとしてモデル化することができる。ＭｙＳｅｒｖｉｃｅアプリケーションにおいて、ＭｙＦｒｏｎｔＥｎｄは、クラスＷｅｂサービスから導出された新たなタイプであり、ＭｙＢａｃｋＥｎｄは、クラスＳＱＬデータベースから導出された新たなタイプである。
【００３１】
以下は、ポート、ワイヤ、およびコンポーネントに関するクラススキーマの例である。
-----------------------------------------------------------------
＜portClass name＝”ServerDataAccess” layer＝”Application”＞
＜settingSchema＞
＜xs:element name＝”databaseName” type＝”xs:string” /＞ 
＜/settingSchema＞
＜/portClass＞
-----------------------------------------------------------------
-----------------------------------------------------------------
＜wireClass name＝”DataConnection” layer＝”Application”＞
＜settingSchema＞
＜xs:element name＝”useSSL” type＝”xs:boolean” /＞ 
＜/settingSchema＞
＜portClassesAllowed＞
＜portClassRef name＝”ServerDataAccess” maxOccurs＝”1” /＞ 
＜portClassRef name＝”ClientDataAccess” /＞ 
＜/portClassesAllowed＞
＜/wireClass＞
-----------------------------------------------------------------
-----------------------------------------------------------------
＜componentClass name＝”Database” layer＝”Application”＞
＜deploymentSchema＞
＜xs:element name＝”sqlScriptFilePath” type＝”xs:string” maxOccurs＝”unbounded” /＞ 
＜/deploymentSchema＞
＜settingSchema＞
＜xs:element name＝”databaseName” type＝”xs:string”/＞ 
＜/settingSchema＞
＜portClassesAllowed closed＝”true”＞
＜portClassRef name＝”ServerDataAccess” /＞ 
＜/portClassesAllowed＞
＜/componentClass＞
-----------------------------------------------------------------  
【００３２】
各ｃｏｍｐｏｎｅｔＣｌａｓｓスキーマおよび各ｗｉｒｅＣｌａｓｓスキーマは、設定スキーマ、展開スキーマ、および許容されたポートクラスを収容することができることに注目されたい。このｐｏｒｔＣｌａｓｓは、許容ポートクラスのセクションを有していない。これらのスキーマは、以下のとおり定義される。
●設定スキーマは、設計時に検証することができるコンポーネント、ポート、およびワイヤに関する構成パラメータのＸＳＤである。
●展開スキーマは、コンポーネント、ポート、またはワイヤがインストールされるためにどのようなインストールパラメータが設定される必要があるかを表現するＸＳＤである。このマニフェストは、Ｆｕｓｉｏｎ、または何らかの他のインストーラ技術に関するスキーマとすることができる。
●許容ポートクラスは、コンポーネントおよびワイヤが宣言されたポートクラスを参照することによって許容可能なポートを宣言するところである。
クラススキーマに関するさらなる詳細については、http://bigにあるＳＤＭスキーマ設計仕様を参照されたい。
【００３３】
クラス関係
他のコンポーネントをホストすることができるコンポーネント、ポート、またはワイヤは、自らがホストすることができるインストーラおよびコンポーネントクラスを特定するｈｏｓｔＲｅｌａｔｉｏｎｓスキーマを使用して宣言される。このｈｏｓｔＲｅｌａｔｉｏｎｓ要素は、コンポーネント、ポート、またはワイヤの１つが、他のホストとして働いているクラス間の方向リンクと考えることができる。
【００３４】
コンポーネントをホストすることは、コンポーネントのコードのための実行環境を提供することを意味する。例えば、ＳＱＬは、以下の例に示すとおり、クラスＤａｔａｂａｓｅのコンポーネントのためのホストとなることができる。
＜hostRelations＞
＜installer name＝”DatabaseInstaller” codeType＝“InstallerPlugIn“ /＞
＜hostRelation classRef＝”database” componentHostClassRef＝“host:SQL” installerRef＝”DatabaseInstaller” /＞ 
＜/hostRelations＞
【００３５】
ＳＤＭタイプ
ＳＤＭがモデル化する３つの異なる空間、リソース、アプリケーション、およびインスタンスが存在する。インスタンス空間については、本明細書で後に説明する。リソース空間は、クラスが存続するところであり、アプリケーションを構築するビルディングブロックである。アプリケーション空間は、タイプが存在するところである。以下は、ポートタイプ、ワイヤタイプ、およびコンポーネントタイプに関するＸＭＬの例である。
-----------------------------------------------------------------
＜portType name＝“UserDataServer” class＝“ServerDataAccess”＞
＜deployment /＞
＜setttings /＞
＜/portType＞
-----------------------------------------------------------------
-----------------------------------------------------------------
＜wireType name＝“UserData” class＝“DataConnection”＞
＜deployment /＞
＜settings＞
＜useSSL＞false＜/useSSL＞
＜/settings＞
＜portTypeRefs＞
＜portTypeRef name＝“UserDataServer”/＞
＜portTypeRef name＝“UserDataClient”/＞
＜/portTypeRefs＞
＜/wireType＞
-----------------------------------------------------------------
-----------------------------------------------------------------
＜componentType name＝“SQLBackEnd” class＝“Database”＞
＜deployment＞
＜sqlScriptFilePath＞%install%￥mydatabaseDfn.sql＜/sqlScriptFilePath＞
＜/deployment＞
＜settings＞
＜databaseName＞UserData＜/databaseName＞
＜/settings＞
＜ports＞
＜port name＝“userData” type＝“UserDataServer”/＞
＜/ports＞
＜/componentType＞
-----------------------------------------------------------------
【００３６】
ＳＤＭスキーマにおける各ｐｏｒｔＴｙｐｅ、ｗｉｒｅＴｙｐｅ、およびｃｏｍｐｏｎｅｎｔＴｙｐｅは、設定値および展開値を収容することに注目されたい。
●設定は、コンポーネント、ポート、およびワイヤに関する構成値を提供する設定スキーマのためのＸＭＬであり、設計時に検証することができる。
●展開は、コンポーネント、ポート、またはワイヤを適切にインストールするために構成パラメータを設定する必要がある値を表現する展開マニフェストのためのＸＭＬである。
タイプに関するさらなる詳細に関しては、http://bigにあるＳＤＭスキーマ設計仕様を参照されたい。
【００３７】
複合コンポーネント
複合コンポーネントを使用してアプリケーション、ならびに他のコンポーネント、ポート、およびワイヤに対するアプリケーションのトポロジ上の関係を定義することができる。複合コンポーネントは、関連する実装を持たず、代わりに、ポートの委任、およびホスト関係を使用してメンバコンポーネントおよびメンバポートの振る舞いを公開する。以下のＸＭＬは、ＳＤＭを使用してどのように複合コンポーネントＭｙＳｅｒｖｉｃｅを記述することができるかを示している。
＜compoundComponentType name＝“MyService”＞
＜components＞
＜component name＝“MyFrontEnd” type＝“IISFrontEnd” /＞ 
＜component name＝“MyBackEnd” type＝“SQLBackEnd” /＞ 
＜/components＞
＜wires＞
＜wire name＝”data” type＝“UserData”＞
＜members＞
＜member componentName＝“MyFrontEnd” portName＝“serverData” /＞ 
＜member componentName＝“MyBackEnd” portName＝“userData” /＞ 
＜/members＞
＜/wire＞
＜/wires＞
＜/compoundComponentType＞
【００３８】
インスタンス
コンポーネント、ポート、およびワイヤは、アプリケーション／サービスの構造および振る舞いを定義するが、実行インスタンスは定義しない。あらゆるコンポーネントタイプ宣言、ポートタイプ宣言、およびワイヤタイプ宣言は、１つまたは複数のインスタンスを有することができる。インスタンスは、物理リソース（サーバ、ネットワークスイッチポート、およびディスク）が割り振られ、ソフトウェアリソース（オペレーティングシステム、ランタイムホスト、アプリケーションコード）がインストールおよび構成されるようにアプリケーション／サービスを展開した結果である。すべてのインスタンスを作成の時点から、インスタンスが削除されるまで追跡するのは、ＳＤＭランタイムの仕事である。
【００３９】
ＳＤＭランタイム
ＳＤＭランタイムはそれ自体、コンポーネント、ポート、およびワイヤのインスタンスを作成せず、代わりに、ＳＤＭインスタンスの作成と管理を調整するために使用される１組のＡＰＩを提供する。ＩＩＳでＷｅｂサービスコンポーネントのホストとしてＷｉｎｄｏｗｓ（登録商標）サーバを稼動しているサーバなどのインスタンスの実際の作成には、通常、複数のエンティティがかかわり、場合により、完了するまでに数時間、または数日かかることがある。
【００４０】
ＳＤＭランタイムは、「ＳＤＭインスタンス作成」プロセスがいつ開始し、成功または失敗して、いつ終わるかを知っている。また、ＳＤＭランタイムは、ＳＤＭインスタンスの存続期間中に、ＳＤＭインスタンスにどのような変更が行われるかも知っている。ＳＤＭランタイムについての１つの考え方は、ＳＤＭランタイムは、ある所与のアプリケーション／サービスＳＤＭに関連するすべてのトランザクションを記録し、指定されたＳＤＭに関連するインスタンスについての情報を問い合わせることができるアカウンタント（ａｃｃｏｕｎｔａｎｔ）であるということである。ＳＤＭインスタンスを作成する最初のステップは、ＳＤＭランタイムとのアプリケーション／サービスＳＤＭの登録である。ＳＤＭランタイムがある所与のＳＤＭについて知ると、ファクトリおよびリソースマネージャ（以下に説明する）を使用して、インスタンス作成プロセスを呼び出すことができる。  
ＡＰＩおよびランタイム設計に関するより詳細な情報については、http://big/にあるＳＤＭランタイムアーキテクチャ仕様を閲覧されたい。
【００４１】
ホストおよびファクトリ
他のコンポーネントを「ホスト」することができるコンポーネントは、ホストと呼ばれ、自らがサポートするクラスに関するファクトリとして働く。コンポーネントは、前述したＳＤＭスキーマ、ｈｏｓｔＲｅｌａｔｉｏｎｓエレメントを使用して、１つまたは複数のコンポーネントクラスのホストと宣言することができる。
【００４２】
ホストは、コンポーネントのコードに対する実行環境を提供するが、ファクトリは、ある所与のタイプのＳＤＭインスタンスを作成し、ＳＤＭランタイムＡＰＩを介してＳＤＭランタイムとやりとりする実際のサービスである。ファクトリは、１つまたは複数のコンポーネントクラスをサポートすることができ、そのコンポーネントクラスを自らがサポートするかを指定してＳＤＭランタイムに登録しなければならない。
【００４３】
ある所与のファクトリが異なる構成を有する同一タイプの複数のホストをサポートすることも、個々のファクトリが各タイプのホスト構成のために存在することも可能である。例えば、ＩＩＳファクトリは、ＷｅｂサービスおよびＷｅｂアプリケーションなどの複数のクラスをサポートすることができる。同様に、ＳＱＬファクトリは、データベース、区画化されたデータベース、および可用性の高いデータベースなどの異なるデータベースタイプをサポートすることができる。
【００４４】
ファクトリはそれ自体、ストレージ、ネットワーク、およびサーバなどの物理リソースを管理しない。ファクトリは、リソースマネージャを通じて物理リソース（およびそれらの論理等価物）とやりとりする。
【００４５】
リソースマネージャ
リソースマネージャは、（１）ブートストラッププロセスの一部として発見または作成されるか、あるいは（２）物理環境の何らかの宣言的ＸＭＬベースの記述を通して指定される物理リソースおよび論理リソースを管理する。リソースマネージャは、すべてのストレージリソース、ネットワークリソース、およびサーバリソースを所有しており、共通リソース管理ＡＰＩを公開してリソース割り振り要求を処理し、これらのリソースの所有権を追跡する。
【００４６】
リソースマネージャの例は、ＮＲＭ（ネットワークリソースマネージャ）、ＳＲＭ（ストレージリソースマネージャ）、およびＰＲＭ（ＰＣリソースマネージャ）である。以上のリソースマネージャのそれぞれが、物理ポートもしくはディスク、またはサーバ、およびＶＬＡＮ、論理ディスクボリューム、ファイル共用、Ｗｅｂサーバなどの自らが公開する論理リソースの割り振りを担う。また、リソースマネージャは、物理デバイスをプログラムして割り振り、および割り振り解除を実現する責も担う。
【００４７】
物理ハードウェアをプログラムするため、リソースマネージャは、ハードウェアデバイスの実装の詳細を隠しているリソースプロバイダを通じてハードウェアとやりとりし、例えば、複数のベンダからのネットワークスイッチを互換的に使用することができるようにする（製造業者のデバイスに関するプロバイダが存在することを仮定して）。Ｗｉｎｄｏｗｓ（登録商標）におけるハードウェア抽象化レイヤ（ＨＡＬ）およびデバイスドライバモデルのように、サーバ、ネットワークデバイス、およびストレージデバイスにわたるデータセンタ環境に関する等価の抽象化レイヤが存在する。
【００４８】
レイヤおよびマッピング
コンポーネント、ポート、およびワイヤは、ホスト、ファクトリ、リソースマネージャ、およびＳＤＭランタイムと組み合わせられると、強力な抽象化となるが、分散アプリケーション／サービスを展開し、管理するために十分ではない。これらの論理抽象化の物理インスタンスを作成し、管理するために、いくつかの追加の構成が必要とされる。それらの追加の構成がレイヤおよびマッピングである。
【００４９】
レイヤ
レイヤの必要性は、アプリケーション／サービスの展開要件を設計時に検証する要望によって動機づけられている。図３は、ＳＤＭによって定義されたレイヤ抽象化を示している。
●アプリケーションレイヤは、分散可能なコンポーネント、それらの展開の要件および制約、ならびにアプリケーション／サービスのコンテキストにおけるそれらの通信関係を記述する。
●ホストレイヤは、特にＩＩＳ、ＣＬＲ、およびＳＱＬなどのホストに関する構成およびポリシー設定、ならびに制約を記述する。
●仮想データセンタ（ＶＤＣ）レイヤは、オペレーティングシステムからネットワークトポロジを経由してサーバ、ネットワークデバイス、およびストレージデバイスまでのデータセンタ環境の設定および制約を記述する。
●ハードウェアレイヤは、物理データセンタ環境を記述し、発見されるか、例えば、ＸＭＬを使用して宣言的な形で指定される。このレイヤは、スケール不変ではなく、それゆえＳＤＭでモデル化されないが、完全性のために含められている。
【００５０】
マッピング
ＳＤＭはレイヤ化されているので、様々なレイヤ間をバインドする方法が必要である。マッピングは、基本的に、１つのレイヤにおけるコンポーネントまたはポートを次の下位のレイヤにおけるコンポーネントまたはポートにバインドすることである。マッピングは、以下のとおり記述することができる。
ＭＴ＝［Ｔｎ→Ｔｎ−１］＋［Ｔｎ−１→Ｔｎ−２］＋［Ｔｎ−２→Ｔｎ−３］［．．．］
ここで、Ｍはマッピングを表わし、Ｔはコンポーネント、ポート、またはワイヤを表わし、ｎはレイヤを表わしている。矢印はマッピングの方向を表わし、常に上位のレイヤから下位のレイヤに向かっている。
【００５１】
例えば、図４で、ＭｙＦｒｏｎｔＥｎｄという名前のアプリケーションレイヤにおけるコンポーネントが、ＩＩＳと呼ばれるホストレイヤにおけるコンポーネントにマッピングされている。同様に、ＭｙＢａｃｋＥｎｄという名前のコンポーネントが、ホストレイヤにおけるＳＱＬコンポーネントにマッピングされている。
【００５２】
設計時の検証
コンポーネントと下位のレイヤにあるそのホストコンポーネントの間のバインドにより、アプリケーション／サービスが活動状態のデータセンタにおいて実際に展開される前に、開発者に対して問題を表面化させることができる。その問題は、互換性がないタイプ、構成上の競合、合致しない動作、トポロジ上の関係の欠落などに起因することがある。図５は、認証に関してコンポーネントとそのホストの間における設定および制約の検査のエラーを描いている。
【００５３】
図６で、以下の図に描かれたマッピングの試みでは、展開レイヤにおいてＩＩＳとＳＱＬコンポーネント間に潜在的な通信関係が存在しないので、エラーという結果になっている。
【００５４】
ＭｙＢａｃｋＥｎｄコンポーネントからＳＱＬホストコンポーネントに対するマッピングは、コンポーネントとホストのタイプの適合性、および構成上の競合がないことに基づいて有効なバインドになる可能性があったが、ＭｙＳｅｒｖｉｃｅ  ＳＤＭが、指定された展開レイヤにおいて存在していないＭｙＦｒｏｎｔＥｎｄとＭｙＢａｃｋＥｎｄ間のトポロジ上の関係を定義したため、無効である。
【００５５】
設定および制約の検査
アプリケーションレイヤから展開レイヤ（など）へマップする能力は、極めて強力である。というのは、ホストの制約に照らしてコンポーネントの設定を設計時に検証することを可能にし、またコンポーネントの制約に照らしてホストの設定を検証することを可能にするためである。
【００５６】
図７は、異なるレイヤにおけるコンポーネントとホスト間の関係のより詳細な図を示している。１つのレイヤにあるコンポーネントと次の下位の層にあるホストコンポーネントの間のバインドが、ＶＤＣレイヤに至るまで存在することに注目されたい。
【００５７】
図７で、ＭｙＦｒｏｎｔＥｎｄは、ＩＩＳによってホストされるＷｅｂサービスであり、これは、Ｗｉｎｄｏｗｓ（登録商標）サーバによってホストされるＷｉｎｄｏｗｓ（登録商標）アプリケーションである。ＩＩＳおよびＳＱＬのインスタンスの作成および削除を担うＷｉｎｄｏｗｓ（登録商標）アプリケーションファクトリが存在するのと同様に、ＷｅｂサービスおよびＷｅｂアプリケーションのコンポーネントインスタンスの作成および削除をサポートするＩＩＳファクトリが存在する。
【００５８】
図８は、設計時の検証が、前述したＳＤＭの設定および制約の意味構造を使用して、異なるレイヤにおけるコンポーネント間でどのように機能するかを示している。
【００５９】
上位のレイヤにおけるコンポーネントの制約は、下位のレイヤにおけるホストコンポーネントの設定に照らして検証されることに注目されたい。また、ホストコンポーネントの制約は、ホストされるべきコンポーネントの設定に照らして検証されることにも注目されたい。
【００６０】
この双方向の設定および制約の検査により、開発者が、最下位までＳＤＭ意味構造を使用して記述した動作環境のコンテキストにおいて自身のアプリケーション／サービスを確実に開発することが可能になる。開発プロセス中にデータセンタの記述に依拠することができるようにデータセンタを記述するために、ＶＤＣと呼ばれるデータセンタの抽象化を作成することが必要である。
【００６１】
仮想データセンタ（ＶＤＣ）
ＶＤＣは、データセンタの開発者のビューを簡単化する物理データセンタ環境の論理表現である。理想的には、ＩＴ専門技術者またはＩＴアーキテクチャ設計者は、開発者が分散アプリケーション／サービスを記述することができるのと同じスケール不変の形でデータセンタを記述することができなければならない。ＶＤＣについての考え方は、ＶＤＣは、データセンタ内のサーバリソース、ネットワークリソース、およびストレージリソース、ならびにそれらのトポロジ上の関係の抽象化であるということである。通常のデータセンタ図は、複数の互いに接続されたサーバ、ネットワーク機器、ＩＰアドレス、ＶＬＡＮ、オペレーティングシステム、ストレージ等がすべて、Ｖｉｓｉｏ、または同様なツールを使用して描かれた単一の図の上に表現されており、極めて複雑である。図に加えて、通常、どのようにデータセンタが区画化され、構成され、管理されるかを正確に規定する長大なドキュメントが存在する。
【００６２】
この複雑さの例が、マイクロソフトシステムズアーキテクチャ（ＭＳＡ：Ｍｉｃｒｏｓｏｆｔ  Ｓｙｓｔｅｍｓ  Ａｒｃｈｉｔｅｃｔｕｒｅ）エンタープライズデータセンタ（ＥＤＣ：Ｅｎｔｅｒｐｒｉｓｅ  Ｄａｔａ  Ｃｅｎｔｅｒ）である。更新およびアップグレードが適用される際の時間の経過にわたってデータセンタの状態に対して手書きの図およびドキュメントを最新に保つことが、不可能でないにしても、コストのかかる作業になることは明白であろう。同様に、ドキュメントの規定に照らして環境を検証する能力は、困難であり、人間による誤りが生じやすい。
【００６３】
スケール不変の形でＭＳＡ  ＥＤＣのような複雑なデータセンタを表現できることは、開発者およびＩＴ専門技術者の両者にとって極めて強力であろう。コンポーネント、ポート、およびワイヤを使用してデータセンタを記述できることにより、今日の設計および展開のプロセスに欠落している展開要件をモデル化し、検証する強力なフレームワークが提供される。
【００６４】
ＳＤＭの基本
ＳＤＭは、
●分散アプリケーション／サービスの設計を容易にする抽象化を定義する。
●オペレーション上の実践の再使用および自動化のためのフレームワークを可能にする。
●分散アプリケーションおよび分散サービスの展開およびオペレーションを簡単化する。
【００６５】
ＳＤＭが何であるかを理解するには、今日、サービスの運用者の近くの壁に掲げられた複雑な図として多々見られるものをＳＤＭが取り込むことを考えると、容易になる。これらの図では、ボックスは、通常、サービスの稼動中の要素を表わし、ボックスを結ぶ線は、サービス要素間の通信パスを表わしている。例えば、負荷分散装置がいくつかのＩＩＳフロントエンドマシンに接続され、それらが１つまたは複数の中間層サービスまたはバックエンドサービスに接続されている。
【００６６】
ＳＤＭについての別の考え方は、ＳＤＭが分散アプリケーション／サービスの振る舞いのメタモデルであるとともに、コンピューティング環境内の実行中のアプリケーション／サービスの「活動中」の青写真でもあるということである。ＳＤＭは、許容可能なソフトウェア動作を含め、そのコンピューティング環境内におけるアプリケーションの構造を宣言的にスケール不変の形で取り込む。ハードウェアおよびネットワークリソース間のバインド化、およびソフトウェアコンポーネントの有効な動作を含め、サービスのトポロジを宣言的に記述することができることは、極めて強力である。
【００６７】
喩えとして、マイクロソフトのコモンオブジェクトモデル（ＣＯＭ）を見ることにする。ＣＯＭは、どのようにコンポーネントがパッケージ化され、登録され、アクティブ化され、発見されるかなどを標準化した。ＣＯＭは、存続期間、メモリ管理、およびインターフェース実装に関連する厳密な規則を指図する。これらのプリミティブは、コンポーネントをブラックボックスとして扱えるようにするので、相互運用性に不可欠である。ＣＯＭは、イベンティング、自動化、およびＯＬＥなどのより高度なサービスのための基礎である。
【００６８】
同様に、ＳＤＭは、より高度な機能を構築する基礎となるいくつかの基本プリミティブを定義する必要がある。これらのプリミティブは、次のとおりである。
●コンポーネント−実装、展開、および管理の単位
●ポート−関連するタイプおよび１組の有効な操作を有する名前付きエンドポイント
●ワイヤ−ポート間の許容された通信パス
●レイヤ−リソース管理所有権とバインド化の分離
●マッピング−各レイヤにおけるコンポーネント、ポート、およびワイヤの間のバインド化
本明細書の以下の部分では、これらプリミティブのそれぞれについてより詳細に説明する。
【００６９】
コンポーネント、ポート、およびワイヤ
本明細書では、コンポーネント、ポート、およびワイヤを使用して描かれたＭｙＳｅｒｖｉｃｅと呼ばれる簡単なサービスの図式表現を検討することが有用である。図２では、ボックスがコンポーネントを表わし、菱形がポートを表わし、破線がワイヤを表わしている。
●ＭｙＳｅｒｖｉｃｅは、コンポーネントＭｙＦｒｏｎｔＥｎｄおよびＭｙＢａｃｋＥｎｄを使用しているので、複合コンポーネントである。
●ＭｙＳｅｒｖｉｃｅは、ＭｙＦｒｏｎｔＥｎｄコンポーネントによって実装された委任ポートであるＷｅｂと呼ばれる１つの可視ポートを有している。
●ＭｙＦｒｏｎｔＥｎｄは、２つのポート、委任ポート、およびカタログとラベル付けされたポートを有している。
●ＭｙＢａｃｋＥｎｄは、データとラベル付けされた１つのポートを有している。
●ＭｙＦｒｏｎｔＥｎｄおよびＭｙＢａｃｋＥｎｄコンポーネントは、ワイヤを介してカタログポートをデータポートにバインドする潜在的な通信関係を有している。
【００７０】
コンポーネント
コンポーネントは、実装、展開、および管理の単位である。コンポーネントの例は、Ｗｉｎｄｏｗｓ（登録商標）サーバ、ＩＩＳ仮想Ｗｅｂサイト、またはＳＱＬデータベースが稼動している専用サーバである。コンポーネントは、一般に、マシン境界を有するが、単一のサーバ上でホストされる複数のＩＩＳ仮想Ｗｅｂサイトによって証されるように必須ではない。
【００７１】
コンポーネントは、ポートを通して機能を公開し、ワイヤを通して通信する。単純なコンポーネントは、メンバとしてポートのみを有することができる。他のコンポーネントを使用するコンポーネントは、複合コンポーネントと呼ばれ、他のコンポーネントに加えてメンバとしてポートおよびワイヤを有することができる。
【００７２】
複合コンポーネントは、コンポジションを通じて作成され、それらに関連する実装をまったく持たない。複合コンポーネントポートは、内部コンポーネントからの委任されたポートである。複合コンポーネントは、コロケーション、カプセル化、および再使用を可能にし、したがって、アプリケーション／サービス、そしてその振る舞いを編成する方法と考えることができる。
【００７３】
コンポーネントの公開ポートだけが、コンポーネントの外部に可視である。複合コンポーネントは、外界には、使用するコンポーネントの内部構造がカプセル化を通して隠された状態で、単純なコンポーネントのように見える。実際、単純なコンポーネントと複合コンポーネントの両方によってサポートされるポートタイプおよび動作がまったく同じである限りこれらを置き換えることが可能である。
【００７４】
ポート
ポートは、関連するタイプを有する名前付きエンドポートであり、通常、プロトコルの役割、および１組の許可された操作に関連している。ポートの例は、ＨＴＴＰサーバポート、１組の許可された操作を有するＳＯＡＰポートなどである。ポートは、委任することができ、これは、外部コンポーネントが内部コンポーネントのポートを自らのポートとして公開できることを意味する。
【００７５】
ポートは、コンポーネントに対して公開インターフェース（振る舞い）を形成する。ポートだけが、公開（可視に）することができるコンポーネントメンバである。
【００７６】
ワイヤ
ワイヤは、ポート間の許可されたバインド化であり、ポート（およびコンポーネント）間のトポロジ上の関係を表わす。ワイヤは、何らインスタンス相互接続トポロジを指定せず、代わりに、インスタンス相互接続トポロジに関する「可能性」を表現する。
【００７７】
ワイヤは、基本的には、バスであり、１つまたは複数のポートメンバを収容することができる。ワイヤをポイントツーポイントの関係ととらえてはならない。ある所与のポートが同一ワイヤ内で再び現れることはできない。
【００７８】
スキーマ
アプリケーション／サービスを記述するために、ＳＤＭに関する標準スキーマを有することが必要である。ＳＤＭスキーマは、ＸＳＤおよびＸＭＬ文法を使用して表現可能であるべきである。ＳＤＭスキーマを詳細に説明することは本明細書の範囲外であるが、本明細書で後に説明する主題の文脈としていくらかの簡潔な説明を提供することが必要である。以下は、ＳＤＭスキーマの簡略図である。
＜sdm＞ 
＜import /＞
＜identityReference /＞
＜information /＞
＜portImplementationType /＞
＜wireImplementationType /＞
＜componentImplementationType /＞
＜hostRelations /＞
＜portTypes /＞
＜wireTypes /＞
＜componentTypes /＞
＜/sdm＞
ＳＤＭスキーマに関するさらに詳細な情報については、http://big/にあるＳＤＭスキーマ仕様およびサンプルＸＳＤファイルを閲覧されたい。
【００７９】
タイプ
アプリケーション／サービスにおいて使用されるあらゆるコンポーネント、ポート、およびワイヤがタイプである。タイプは、基本的に、Ｃ＋＋やＣ＃のようなオブジェクト指向言語におけるクラスと等価であり、クラスの場合と同様に、新たなタイプが既存のタイプから作成することができる。スケール不変の空間は、ＳＤＭスキーマにおいてｐｏｒｔＴｙｐｅｓ、ｗｉｒｅＴｙｐｅｓ、およびｃｏｍｐｏｎｅｎｔＴｙｐｅｓによって表わされる。スケール不変とは、コンポーネント、ポート、またはワイヤがそれぞれの複数のインスタンスが実際のデータセンタ内に存在していても、アプリケーション／サービスＳＤＭにおいて、１度、表わすことができることを意味する。
【００８０】
タイプは、最終的には実装タイプから導出され、これは基本的に共通の技術特徴についての抽象化である。例えば、Ｗｅｂサービスは、ＳＱＬデータベースの場合と同様に、実装タイプとしてモデル化することができる。ＭｙＳｅｒｖｉｃｅアプリケーションでは、ＭｙＦｒｏｎｔＥｎｄは、実装タイプＷｅｂサービスから導出された新たなタイプであり、ＭｙＢａｃｋＥｎｄは、実装タイプＳＱＬデータベースから導出された新たなタイプであろう。
【００８１】
各ｃｏｍｐｏｎｅｎｔＩｍｐｌｅｍｅｎｔａｔｉｏｎＴｙｐｅおよびｗｉｒｅＩｍｐｌｅｍｅｎｔａｔｉｏｎＴｙｐｅＳＤＭスキーマ要素は、設定スキーマ、展開マニフェスト、およびポート実装リファレンスを収容することができる。ｐｏｒｔＩｍｐｌｅｍｅｎｔａｔｉｏｎＴｙｐｅ要素は、ポート実装リファレンスを有していない。図９は、ＳＤＭ実装タイプ空間がどのようなものであるかを示している。
●設定スキーマは、設計時に検証することができるコンポーネント、ポート、およびワイヤに関する構成パラメータのためのＸＳＤである。
●展開マニフェストは、コンポーネント、ポート、またはワイヤをインストールするためにどのようなインストールパラメータを設定する必要があるかを表現するＸＳＤである。このマニフェストは、Ｆｕｓｉｏｎ、または何らかの他のインストーラ技術に関するスキーマであることができる。
●ポート実装リファレンスは、コンポーネントおよびワイヤが宣言されたポート実装タイプを参照することによって許容可能なポートを宣言するところである。
【００８２】
さらに、他のコンポーネントをホストすることができるコンポーネントは、インストーラ、および自らがホストすることができるコンポーネント実装タイプを特定するｈｏｓｔＲｅｌａｔｉｏｎｓＳＤＭスキーマを使用して宣言される。ｈｏｓｔＲｅｌａｔｉｏｎｓ要素は、コンポーネントの１つが他のコンポーネントのホストとして働いているコンポーネント実装タイプ間の方向リンクと考えることができる。コンポーネントをホストすることは、コンポーネントのコードのための実行環境を提供することを意味する。例えば、ＩＩＳは、実装タイプＷｅｂサービスおよびＷｅｂアプリケーションのコンポーネントのためのホストである。ホストは、本明細書で後により詳細に説明することになる。
【００８３】
ＳＤＭスキーマにおける各ｐｏｒｔＴｙｐｅ、ｗｉｒｅＴｙｐｅ、およびｃｏｍｐｏｎｅｔＴｙｐｅ要素は、アプリケーション制約値、展開値、およびホスト制約値を収容する。さらに、ｗｉｒｅＴｙｐｅ要素は、指定されたワイヤタイプ上の許容可能なポートタイプを定義するポートタイプ要素を収容し、ｃｏｍｐｏｎｅｎｔＴｙｐｅ要素は、指定されたコンポーネントタイプ上でホストすることができる実装タイプを特定するホストされたタイプリスト要素を収容する。図１０は、ＳＤＭタイプ空間を示している。
●設定値は、コンポーネント、ポート、およびワイヤに関する構成値を提供する設定スキーマのためのＸＭＬであり、ホストの制約値に照らして設計時に検証することができる。
●展開値は、コンポーネント、ポート、またはワイヤが適切に機能するために構成パラメータを設定する必要がある値を表現する展開マニフェストのためのＸＭＬである。
●制約値は、ホストのコンポーネント、ポート、またはワイヤが設定されなければならない構成パラメータ値を提供する設定スキーマのためのＸＭＬである。制約値は、その基礎となるホストの設定値に照らして設計時に検証することができる。
●ポートタイプは、指定されたワイヤのメンバであることができる許容可能なポートタイプをリストするＸＭＬである。
●ホストされたタイプリストは、コンポーネントが、自らがホストすることができるコンポーネント実装タイプのリストを宣言するＸＭＬである。
【００８４】
インスタンス
コンポーネント、ポート、およびワイヤは、アプリケーション／サービスの構造および振る舞いを定義するが、実行インスタンスは定義しない。あらゆるコンポーネントタイプ宣言、ポートタイプ宣言、およびワイヤタイプ宣言は、１つまたは複数のインスタンスを有することができる。インスタンスは、物理リソース（サーバ、ネットワークスイッチポート、およびディスク）が割り振られ、ソフトウェアリソース（オペレーティングシステム、ランタイムホスト、アプリケーションコード）がインストールおよび構成されるようにアプリケーション／サービスを展開した結果である。
【００８５】
すべてのインスタンスを作成の時点から、インスタンスが削除されるまで追跡するのは、ＳＤＭランタイムの仕事である。
【００８６】
ＳＤＭランタイム
ＳＤＭランタイムはそれ自体、コンポーネント、ポート、およびワイヤのインスタンスを作成せず、代わりに、ＳＤＭインスタンスの作成と管理を調整するために使用される１組のＡＰＩを提供する。ＩＩＳでＷｅｂサービスコンポーネントのホストとしてＷｉｎｄｏｗｓ（登録商標）サーバを稼動しているサーバなどのインスタンスの実際の作成には、通常、複数のエンティティがかかわり、場合により、完了するまでに数時間、または数日かかることがある。
【００８７】
ＳＤＭランタイムは、「ＳＤＭインスタンス作成」プロセスがいつ開始し、成功または失敗して、いつ終わるかを知っている。また、ＳＤＭランタイムは、ＳＤＭインスタンスの存続期間中に、ＳＤＭインスタンスにどのような変更が行われるかも知っている。ＳＤＭランタイムについての１つの考え方は、ＳＤＭランタイムは、ある所与のアプリケーション／サービスＳＤＭに関連するすべてのトランザクションを記録し、指定されたＳＤＭに関連するインスタンスについての情報を問い合わせることができるアカウンタントであるということである。
【００８８】
ＳＤＭインスタンスを作成する最初のステップは、ＳＤＭランタイムとのアプリケーション／サービスＳＤＭの登録である。ＳＤＭランタイムがある所与のＳＤＭについて知ると、ファクトリおよびリソースマネージャ（以下に説明する）を使用して、インスタンス作成プロセスを呼び出すことができる。
【００８９】
ＡＰＩおよびランタイム設計に関するより詳細な情報については、http://big/にあるＳＤＭランタイムアーキテクチャ仕様を閲覧されたい。
【００９０】
ホストおよびファクトリ
他のコンポーネントを「ホスト」することができるコンポーネントは、ホストと呼ばれ、自らがサポートする実装タイプに関するファクトリとして働く。コンポーネントは、前述したＳＤＭスキーマ、ｈｏｓｔＲｅｌａｔｉｏｎｓエレメントを使用して、１つまたは複数のコンポーネント実装タイプのホストと宣言することができる。
【００９１】
ホストは、コンポーネントのコードに対する実行環境を提供するが、ファクトリは、ある所与のタイプのＳＤＭインスタンスを作成し、ＳＤＭランタイムＡＰＩを介してＳＤＭランタイムとやりとりする実際のサービスである。ファクトリは、１つまたは複数のコンポーネント実装タイプをサポートすることができ、どのコンポーネント実装タイプを自らがサポートするかを指定してＳＤＭランタイムに登録しなければならない。ある所与のファクトリが異なる構成を有する同一タイプの複数のホストをサポートすることも、個々のファクトリが各タイプのホスト構成のために存在することも可能である。例えば、ＩＩＳファクトリは、ＷｅｂサービスおよびＷｅｂアプリケーションなどの複数の実装タイプをサポートすることができる。同様に、ＳＱＬファクトリは、データベース、区画化されたデータベース、および可用性の高いデータベースなどの異なるデータベースタイプをサポートすることができる。
【００９２】
ファクトリはそれ自体、ストレージ、ネットワーク、およびサーバなどの物理リソースを管理しない。ファクトリは、リソースマネージャを通じて物理リソース（およびそれらの論理等価物）とやりとりする。
【００９３】
リソースマネージャ
リソースマネージャは、（１）ブートストラッププロセスの一部として発見または作成されるか、あるいは（２）物理環境の何らかの宣言的ＸＭＬベースの記述を通して指定される物理リソースおよび論理リソースを管理する。リソースマネージャは、すべてのストレージリソース、ネットワークリソース、およびサーバリソースを所有しており、共通リソース管理ＡＰＩを公開してリソース割り振り要求を処理し、これらのリソースの所有権を追跡する。
【００９４】
リソースマネージャの例は、ＮＲＭ（ネットワークリソースマネージャ）、ＳＲＭ（ストレージリソースマネージャ）、およびＰＲＭ（ＰＣリソースマネージャ）である。以上のリソースマネージャのそれぞれが、物理ポートもしくはディスク、またはサーバ、およびＶＬＡＮ、論理ディスクボリューム、ファイル共用、Ｗｅｂサーバなどの自らが公開する論理リソースの割り振りを担う。また、リソースマネージャは、物理デバイスをプログラムして割り振り、および割り振り解除を実現する責も担う。
【００９５】
物理ハードウェアをプログラムするため、リソースマネージャは、ハードウェアデバイスの実装の詳細を隠しているリソースプロバイダを通じてハードウェアとやりとりし、例えば、複数のベンダからのネットワークスイッチを互換的に使用することができるようにする（製造業者のデバイスに関するプロバイダが存在することを仮定して）。Ｗｉｎｄｏｗｓ（登録商標）におけるハードウェア抽象化レイヤ（ＨＡＬ）およびデバイスドライバモデルのように、サーバ、ネットワークデバイス、およびストレージデバイスにわたるデータセンタ環境に関する等価の抽象化レイヤが存在する。
【００９６】
レイヤおよびマッピング
コンポーネント、ポート、およびワイヤは、ホスト、ファクトリ、リソースマネージャ、およびＳＤＭランタイムと組み合わせられると、強力な抽象化となるが、分散アプリケーション／サービスを展開し、管理するために十分ではない。これらの論理抽象化の物理インスタンスを作成し、管理するために、いくつかの追加の構成が必要とされる。それらの追加の構成がレイヤおよびマッピングである。
【００９７】
レイヤ
レイヤの必要性は、アプリケーション／サービスの展開要件を設計時に検証する要望によって動機づけられている。図１１は、ＳＤＭによって定義されたレイヤ抽象化を示している。
●アプリケーションレイヤは、分散可能なコンポーネント、それらの展開の要件および制約、ならびにアプリケーション／サービスのコンテキストにおけるそれらの通信関係を記述する。
●展開レイヤは、特にＩＩＳ、ＣＬＲ、およびＳＱＬなどのホストに関する構成およびポリシー設定、ならびに制約を記述する。
●仮想データセンタ（ＶＤＣ）レイヤは、オペレーティングシステムからネットワークトポロジを経由してサーバ、ネットワークデバイス、およびストレージデバイスまでのデータセンタ環境の設定および制約を記述する。
●ハードウェアレイヤは、物理データセンタ環境を記述し、発見されるか、例えば、ＸＭＬを使用して宣言的な形で指定される。このレイヤは、スケール不変ではなく、それゆえ、ＳＤＭでモデル化されないが、完全性のために含められている。
【００９８】
マッピング
ＳＤＭはレイヤ化されているので、様々なレイヤ間をバインドする方法が必要である。マッピングは、基本的に、１つのレイヤにおけるコンポーネントまたはポートを次の下位のレイヤにおけるコンポーネントまたはポートにバインドすることである。マッピングは、以下のとおり記述することができる。
ＭＴ＝［Ｔｎ→Ｔｎ−１］＋［Ｔｎ−１→Ｔｎ−２］＋［Ｔｎ−２→Ｔｎ−３］［．．．］
ここで、Ｍはマッピングを表わし、Ｔはコンポーネント、ポート、またはワイヤを表わし、ｎはレイヤを表わしている。矢印はマッピングの方向を表わし、常に上位のレイヤから下位のレイヤに向かっている。
【００９９】
例えば、図１２で、ＭｙＦｒｏｎｔＥｎｄという名前のアプリケーションレイヤにおけるコンポーネントが、ＩＩＳと呼ばれる展開レイヤにおけるコンポーネントにマッピングされている。同様に、ＭｙＢａｃｋＥｎｄという名前のコンポーネントが、展開レイヤにおけるＳＱＬコンポーネントにマッピングされている。
【０１００】
設計時の検証
コンポーネントと下位のレイヤにあるそのホストコンポーネントの間のバインドにより、アプリケーション／サービスが活動状態のデータセンタにおいて実際に展開される前に、開発者に対して問題を表面化させることができる。その問題は、互換性がないタイプ、構成上の競合、合致しない動作、トポロジ上の関係の欠落などに起因することがある。例えば、図１３に描かれたマッピングの試みでは、展開レイヤにおいてＩＩＳとＳＱＬコンポーネント間に潜在的な通信関係が存在しないので、エラーという結果になっている。
【０１０１】
ＭｙＢａｃｋＥｎｄコンポーネントからＳＱＬホストコンポーネントに対するマッピングは、コンポーネントとホストのタイプの適合性、および構成上の競合がないことに基づいて有効なバインドになる可能性があったが、ＭｙＳｅｒｖｉｃｅ  ＳＤＭが、指定された展開レイヤにおいて存在していないＭｙＦｒｏｎｔＥｎｄとＭｙＢａｃｋＥｎｄ間のトポロジ上の関係を定義したため、無効である。
【０１０２】
設定および制約の検査
アプリケーションレイヤから展開レイヤ（など）へマップする能力は、極めて強力である。というのは、ホストの制約に照らしてコンポーネントの設定を設計時に検証することを可能にし、またコンポーネントの制約に照らしてホストの設定を検証することを可能にするためである。
【０１０３】
図１４は、異なるレイヤにおけるコンポーネントとホスト間の関係のより詳細な図を示している。１つのレイヤにあるコンポーネントと次の下位の層にあるホストコンポーネントの間のバインドが、ＶＤＣレイヤに至るまで存在することに注目されたい。
【０１０４】
図１４で、ＭｙＦｒｏｎｔＥｎｄは、ＩＩＳによってホストされるＷｅｂサービスであり、これは、Ｗｉｎｄｏｗｓ（登録商標）サーバによってホストされるＷｉｎｄｏｗｓ（登録商標）アプリケーションである。ＩＩＳおよびＳＱＬのインスタンスの作成および削除を担うＷｉｎｄｏｗｓ（登録商標）アプリケーションファクトリが存在するのと同様に、ＷｅｂサービスおよびＷｅｂアプリケーションのコンポーネントインスタンスの作成および削除をサポートするＩＩＳファクトリが存在する。
【０１０５】
図１５は、設計時の検証が、前述したＳＤＭの設定および制約の意味構造を使用して、異なるレイヤにおけるコンポーネント間でどのように機能するかを示している。
【０１０６】
上位のレイヤにおけるコンポーネントの制約は、下位のレイヤにおけるホストコンポーネントの設定に照らして検証されることに注目されたい。また、ホストコンポーネントの制約は、ホストされるべきコンポーネントの設定に照らして検証されることにも注目されたい。
【０１０７】
この双方向の設定および制約の検査により、開発者が、最下位までＳＤＭ意味構造を使用して記述した動作環境のコンテキストにおいて自身のアプリケーション／サービスを確実に開発することが可能になる。開発プロセス中にデータセンタの記述に依拠することができるようにデータセンタを記述するために、ＶＤＣと呼ばれるデータセンタの抽象化を作成することが必要である。
【０１０８】
仮想データセンタ（ＶＤＣ）
ＶＤＣは、データセンタの開発者のビューを簡単化する物理データセンタ環境の論理表現である。理想的には、ＩＴ専門技術者またはＩＴアーキテクチャ設計者は、開発者が分散アプリケーション／サービスを記述することができるのと同じスケール不変の形でデータセンタを記述することができなければならない。ＶＤＣについての考え方は、ＶＤＣは、データセンタ内のサーバリソース、ネットワークリソース、およびストレージリソース、ならびにそれらのトポロジ上の関係の抽象化であるということである。通常のデータセンタ図は、複数の互いに接続されたサーバ、ネットワーク機器、ＩＰアドレス、ＶＬＡＮ、オペレーティングシステム、ストレージ等がすべて、Ｖｉｓｉｏ、または同様なツールを使用して描かれた単一の図の上に表現されており、極めて複雑である。図に加えて、通常、どのようにデータセンタが区画化され、構成され、管理されるかを正確に規定する長大なドキュメントが存在する。
【０１０９】
この複雑さの例が、マイクロソフトシステムズアーキテクチャ（ＭＳＡ）エンタープライズデータセンタ（ＥＤＣ）である。更新およびアップグレードが適用される際の時間の経過にわたってデータセンタの状態に対して手書きの図およびドキュメントを最新に保つことが、不可能でないにしても、コストのかかる作業になることは明白であろう。同様に、ドキュメントの規定に照らして環境を検証する能力は、困難であり、人間による誤りが生じやすい。
【０１１０】
スケール不変の形でＭＳＡ  ＥＤＣのような複雑なデータセンタを表現できることは、開発者およびＩＴ専門技術者の両者にとって極めて強力であろう。コンポーネント、ポート、およびワイヤを使用してデータセンタを記述できることにより、今日の設計および展開のプロセスに欠落している展開要件をモデル化し、検証する強力なフレームワークが提供される。
【０１１１】
議題として、概要、ＳＤＭビルディングブロック、例示的なアプリケーション、例示的なホスト、論理配置、展開、ステータスについて説明する。
【０１１２】
ＳＤＭは、分散アプリケーションおよびその展開環境の要素的断片を取り込むのによく適したメタモデルである。ＳＤＭには、権限がある（ａｕｔｈｏｒｉａｔｉｖｅ）。すなわち、アプリケーションおよび環境は、それらのＳＤＭから構築され、アプリケーションおよび環境に対する変更は、ＳＤＭを介して行われる。管理プロセスのための名前空間を提供する。
【０１１３】
サービス定義モデルは、以下の互いに関連するスキーマを指す。
クラス、クラス関係、およびインストーラのスキーマ
コンポーネントタイプ、ポートタイプ、およびワイヤタイプのスキーマ
論理配置スキーマ
物理配置スキーマ
インスタンス化要求スキーマ
インスタンススキーマ
【０１１４】
ＳＤＭクラスは、すべての分散アプリケーションおよび展開環境のための基本ビルディングブロックである。アプリケーションクラスは、ＡＳＰ．Ｎｅｔ  Ｗｅｂサービス、ＡＳＰ．Ｎｅｔ  Ｗｅｂサイト、ＢｉｚＴａｌｋ統合スケジュール、サービスコンポーネント（ＣＯＭ＋）等である。サービスクラスは、ＩＩＳサーバ、ＳＱＬサーバ、ＢｉｚＴａｌｋサーバである。ＯＳ、ネットワークおよびストレージクラスは、Ｗｉｎｄｏｗｓ（登録商標）ＶＬＡＮ、フィルタ、ディスク等である。ハードウェアクラスは、サーバ、スイッチ、ファイアウォール、負荷分散装置、ＳＡＮ等である。クラスは、システムレベル開発者によって作成され、頻繁には変わらない。クラスは、ＳＤＭにおけるあらゆるコンポーネント、ポート、およびワイヤの背後にある。各クラスは、その公開設定（単に設定と呼ばれる）および非公開設定（展開と呼ばれる）に関するスキーマを収容する。クラス間の関係、すなわち、コンポーネントクラスからポートクラス、ワイヤクラスからポートクラス、およびコンポーネントクラスからコンポーネントクラスの関係が取り込まれる。
【０１１５】
ＡＳＰ．Ｎｅｔ  Ｗｅｂサイトクラス
＜componentClass name＝”WebSite” layer＝”Application”＞http://big/
＜settingSchema＞＜xs:schema＞＜xs:complexType＞＜xs:sequence＞
＜xs:element name＝“webSiteName” type＝”xs:string”/＞
＜xs:element name＝“authentication” type＝”xs:string”/＞
＜xs:element name＝“sessionState” type＝”xs:boolean”/＞
＜/xs:sequence＞＜/xs:complexType＞＜/xs:schema＞＜/settingSchema＞
＜deploymentSchema＞＜xs:schema＞＜xs:complexType＞＜xs:sequence＞
＜xs:element name＝“fusionManifest” type＝”xs:string”/＞
＜/xs:sequence＞＜/xs:complexType＞＜/xs:schema＞＜/deploymentSchema＞
＜portClassesAllowed closed＝”true”＞
＜portClassRef name＝”ClientDataAccess” /＞ 
＜portClassRef name＝“WebServer“ maxOccurs＝“1”/＞ 
＜portClassRef name＝”SoapClientInterface” /＞ 
＜portClassRef name＝”RemotingClientInterface” /＞ 
＜/portClassesAllowed＞
＜/componentClass＞
【０１１６】
ＳＯＡＰクライアントポートクラス
＜portClass name＝“SoapClientInterface“ layer＝“Application”＞http://big/
＜settingSchema＞＜xs:schema＞＜xs:complexType＞＜xs:sequence＞
＜xs:element name＝“formatter” type＝”xs:string”/＞
＜xs:element name＝“transport” type＝”xs:string”/＞
＜/xs:sequence＞＜/xs:complexType＞＜/xs:schema＞＜/settingSchema＞
＜deploymentSchema＞＜xs:schema＞＜xs:complexType＞＜xs:sequence＞
＜xs:element name＝“wsdlFile” type＝”xs:string”/＞
＜/xs:sequence＞＜/xs:complexType＞＜/xs:schema＞＜/deploymentSchema＞
＜/portClass＞
【０１１７】
ＳＯＡＰワイヤクラス
＜wireClass name＝”SoapConnnection” layer＝”Application”＞
＜settingSchema/＞
＜deploymentSchema/＞
＜portClassesAllowed＞
＜portClassRef name＝”SoapServerInterface”/＞ 
＜portClassRef name＝”SoapClientInterface”/＞ 
＜/portClassesAllowed＞
＜/wireClass＞
【０１１８】
ＩＩＳコンポーネントクラス
＜componentClass name＝”IIS” layer＝”Service”＞
＜settingSchema＞＜xs:schema＞＜xs:complexType＞＜xs:sequence＞
＜xs:element name＝“certificateAuth” type＝”xs:boolean”/＞
＜xs:element name＝“ntlmAuth” type＝”xs:boolean”/＞
＜xs:element name＝“sessionStateType” type＝”xs:string”/＞
＜/xs:sequence＞＜/xs:complexType＞＜/xs:schema＞＜/settingSchema＞
＜deploymentSchema＞＜xs:schema＞＜xs:complexType＞＜xs:sequence＞
＜xs:element name＝“fusionManifest” type＝”xs:string”/＞
＜/xs:sequence＞＜/xs:complexType＞＜/xs:schema＞＜/deploymentSchema＞
- ＜portClassesAllowed＞
＜portClassRef name＝”HTTPServer”/＞ 
＜portClassRef name＝”HTTPClient”/＞ 
＜portClassRef name＝”TDSClient”/＞ 
＜/portClassesAllowed＞
＜/componentClass＞
【０１１９】
クラス関係およびインストーラ
＜hostRelation classRef＝“WebSite” hostClassRef＝”IIS” installerRef＝”WebSiteInstaller”/＞ 
＜installer name＝“WebSiteInstaller” code＝“WebSiteInstaller, IISInstaller” codeType＝“assembly“ /＞
【０１２０】
＜ＨｏｓｔＲｅｌａｔｉｏｎ＞は、クラス間のホスト関係を取り込む。すなわち、ＩＩＳが、Ｗｅｂサイトをホストすることができる。
【０１２１】
インストーラは、コンポーネントクラス、ポートクラス、および／またはワイヤクラスの新しいインスタンスを作成することを担うＳＤＭランタイムへの「プラグイン」である。また、インストーラは、クラスのインスタンスを構成することも担う。異なるインストーラが、ＦｕｓｉｏｎまたはＷＭＩ．Ｃｏｎｆｉｇのような同一の基礎となる展開および構成技術を使用することが可能である。
【０１２２】
分散アプリケーション
分散アプリケーションは、コンポーネントクラス、ポートクラス、およびワイヤクラスから構築される。開発者は、クラスからコンポーネントタイプ、ポートタイプ、およびワイヤタイプを作成する。タイプは、クラスの「使用」であり、設定および展開スキーマの値を提供する。タイプは、再使用の単位である。タイプは、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏにいて単一のプロジェクトにマップされる。
【０１２３】
ＳＤＭは、複合コンポーネントタイプを通じてタイプのコンポジションをサポートする。コンポジションにより、より大きい分散アプリケーションをより小さいものから構築することが可能になる。複合コンポーネントタイプは、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏにおける新しいプロジェクト、Ｗｈｉｔｅｈｏｒｓｅにマップされる。
【０１２４】
ＦＭＳｔｏｃｋｓ．Ｗｅｂコンポーネントタイプ
＜componentType name＝“FMStocks.Web” class＝”WebSite”＞
＜ports＞
＜port name＝“web” type＝“webServer”/＞ 
＜port name＝“stock” type＝“StockClient”/＞ 
＜port name＝“accounts” type＝“AccountClient”/＞ 
＜port name＝“trades” type＝“TradeClient”/＞ 
＜/ports＞
＜settings＞
＜webSiteName＞FMStocks.Web＜/webSiteName＞
＜authentication＞Certificate＜/authentication＞
＜sessionState＞true＜/sessionState＞
＜/settings＞
＜deployment＞
＜fusionManifest＞fmstocks.web.manifest＜/fusionManifest＞        
＜/deployment＞
＜/componentType＞
【０１２５】
ＦＭＳｔｏｃｋｓ７複合コンポーネントタイプ
＜compoundComponentType name＝“FMStocks”＞
＜components＞
＜component name＝“web” type＝“FMStocks.Web”/＞
＜component name＝“svc” type＝“FMStocks.WebService”/＞
＜component name＝“biz” type＝“FMStocks.BusinessService”/＞
＜component name＝“custdb” type＝“FMStocks.CustomerDatabase”/＞
＜/components＞
＜wires/＞
＜delegatePorts＞
＜port name＝“web” componentname＝“web” portname＝“web”/＞ 
＜port name＝“svc” componentname＝“svc” portname＝“svc”/＞ 
＜/delegateports＞
＜/componentType＞
【０１２６】
ＳＤＵおよび展開環境
分散アプリケーションのコンポーネントタイプ、ポートタイプ、およびワイヤタイプは、サービス展開ユニット（ＳＤＵ）のバイナリとともにパッケージ化される。バイナリには、すべての．ＤＬＬ、．ＥＸＥ、．ｃｏｎｆｉｇ、静的コンテンツ等が含まれる。ＳＤＵは、ポータブルで独立してインストール可能な分散アプリケーションを表わす。デスクトップアプリケーションのＷｉｎｄｏｗｓ（登録商標）インストーラＭＳＩファイルに類似する。しかし、一様な環境（Ｗｉｎｄｏｗｓ（登録商標））を主に対象とするデスクトップアプリケーションとは異なり、分散アプリケーションは、大きく変わる異なる展開環境上でホストすることができ、展開環境上で自らの要件を表現することができなければならず、自らの展開環境のすべてのポリシーを遵守しなければならない。
【０１２７】
したがって、アプリケーションと展開環境の両方の要件および制約を表現するモデルを必要とする。ＭｙＷｅｂＳｉｔｅコンポーネントタイプは、セッション状態がＳＱＬデータベースに格納された状態で構成されているＩＩＳサーバを必要とする。Ｗｅｂゾーンは、証明書認証を使用しているＷｅｂＳｉｔｅコンポーネントのみをホストすることになる。
【０１２８】
ＩＩＳコンポーネントタイプ
＜componentType name＝“WebTierIIS” class＝“IIS”＞
＜ports/＞
＜settings＞
＜certificateAuth＞true＜/certificateAuth＞
＜ntlmAuth＞false＜/ntlmAuth＞
＜sessionStateType＞true＜/sessionStateType＞
＜/settings＞
＜deployment/＞
＜hostedClasses＞
＜hostedClass class＝“WebSite”＞
＜!-- XPathを用いて表現された制約言語 --＞
＜constraint＞/[authentication＝“certificate”＜/constraint＞ 
＜/hostedClass＞
＜/hostedClasses＞
＜/componentType＞
【０１２９】
ＦＭＳｔｏｃｋｓ．Ｗｅｂコンポーネントタイプ（再掲）
＜componentType name＝“FMStocks.Web” class＝”WebSite”＞
＜ports/＞
＜settings＞
＜webSiteName＞FMStocks.Web＜/webSiteName＞
＜authentication＞Certificate＜/authentication＞
＜sessionState＞true＜/sessionState＞
＜/settings＞
＜deployment＞
＜fusionManifest＞fmstocks.web.manifest＜/fusionManifest＞        
＜/deployment＞
＜hostConstraints＞
＜hostConstraint hostClass＝“IIS”＞
＜constraints＞/[sessiontStateType＝“SQL”]＜/constraints＞
＜/hostConstraint＞
＜/hostConstraints＞
＜/componentType＞
【０１３０】
論理配置
ターゲットの展開環境にタイプの論理配置をまず行ってからでないと、ＳＤＵを展開することができない。論理配置は、設計時に行うことができる。要件および制約が検査され、エラーまたは警告があれば、開発者にアラートされる。論理配置の結果は、ＳＤＵから別個のファイルに取り込まれる。ＳＤＵは、異なる展開環境（開発、試験、製造など）に関して異なる論理配置を有することができる。制約検査は、各コンポーネントクラス、ポートクラス、およびワイヤクラス上で指定されたＸＰａｔｈおよびＸＳＤを使用して実施される。
【０１３１】
展開環境の構築
展開環境は、ＳＤＭモデルを使用して構築される。図２２を参照されたい。基本的に、これらは、異なるレイヤにおけるＳＤＭアプリケーションである。コンポーネントタイプ、ポートタイプ、およびワイヤタイプを同じように使用して、サービスホスト、ネットワークアーキテクチャ、およびハードウェアを構成している。Ｗｈｉｄｂｅｙのタイムフレームでは、アプリケーションレイヤの展開のみをサポートする。ＡＤＳ  Ｖ２．０では、サービスホストレイヤ、ネットワークレイヤ、およびハードウェアレイヤを展開することができるようになる。Ｖｉｓｕａｌ  Ｓｔｕｄｉｏが、展開環境を作成すためのデザイナを構築している。Ｖｉｓｕａｌ  Ｓｔｕｄｉｏでは、これを論理インフラストラクチャモデルと呼ぶ。図２３は、例示的な展開を示している。
【０１３２】
インスタンス要求ドキュメント
ＳＭＤタイプは、スケール不変であり、任意のスケールに対して作成することができる。インスタンス要求ドキュメントは、作成される必要のあるインスタンスの宣言的定義であり、配線（ｗｉｒｉｎｇ）トポロジを含む。図２４は、例示的なタイプを示し、図２５は、例示的なインスタンス要求を示している。
【０１３３】
物理配置
物理配置は、展開のターゲットである特定のホストインスタンスを選択する動作である。物理配置は、論理配置によって制約される。制約は、物理配置中に再検証される。図２６を参照されたい。
【０１３４】
展開
ＳＤＵ、論理配置ファイル、インスタンス要求、および物理配置ファイルが、ＳＤＭランタイムに送り込まれる。すると、ＳＤＭランタイムは、クラスおよびホストの関係に基づいて適切なインストーラを呼び出すことになる。インストーラは、ホスト上で新たなインスタンスを作成し、そのタイプ上の設定値に適合するようにそのインスタンスを構成する責を担う。ＳＤＭランタイムは、すべてのインスタンス、それらの最終設定値、および配置のデータベースを維持管理することになる。ランタイムＡＰＩは、インスタンス空間の照会をサポートすることになる。
【０１３５】
ＳＤＭスキーマ設計仕様
ＳＤＭスキーマの３つのコア要素、ポート、ワイヤ、およびコンポーネントがある。ポートは通信エンドポイントを表わし、コンポーネントは分散アプリケーションの部分を表わし、ワイヤはアプリケーション部分間の通信リンクを表わす。これらは、３つの別々の空間、すなわち、リソース空間、アプリケーション空間、およびインスタンス空間において異なる形態で現れる。
【０１３６】
リソース空間では、アプリケーション空間のアプリケーションを構築するのに用いられるリソースクラスが定義される。これらのクラスにより、アプリケーション部分の共通のカテゴリ化が提供されて、多種多様なアプリケーションに関するツールサポートが可能になり、設計時のタイプ検査のための基礎が提供される。これらのコアクラスにより、サービス設計のための包括的な１組の機能（ｆｅａｔｕｒｅ）が提供されるものと見込まれ、これらのコアクラスは、時間とともにゆっくりと変化するものと見込まれる。
【０１３７】
アプリケーション空間では、アプリケーションタイプが構築される。リソースクラスを取り込み、コンテンツへのリンクを提供したり、プロパティに関する設定値を提供したりすることのように詳細を埋める。次に、ポートタイプをコンポーネントタイプに関連付け、複合コンポーネントタイプ内のコンポーネントタイプを使用し、ワイヤタイプを使用することによって複合コンポーネントタイプのメンバ間の通信関係を記述することにより、これらのタイプから分散アプリケーションを構築する。
【０１３８】
インスタンス空間は、アプリケーションを展開し、実行するプロセス中に作成されるインスタンスから成る。アプリケーション空間で定義した通信関係を、ＳＤＭランタイムを介して公開して、インスタンスが他のインスタンスを見つけることができるようにする。
【０１３９】
リソースクラス
設計時に構成を検査して、実行時に展開するために、リソースクラスを使用して、知る必要があるアプリケーションの要素を定義する。それらの要素は、以下のとおりである。
【０１４０】
ａ）アプリケーションが通信する相手。ネットワークトポロジに照らして分散アプリケーションを検証するために、アプリケーションの部分が互いに通信するために使用することができるプロトコルについて知る必要がある。ポートクラスを使用して、プロトコルエンドポイントが記述される。ワイヤクラスを使用して、それらのエンドポイントの間で構築することができる関係が記述される。
【０１４１】
ｂ）どのような設定がアプリケーションに適用され、どのようにアプリケーションが展開されるか。コンポーネントクラスが、アプリケーションを構築するために使用することができるビルディングブロックを定義する。コンポーネントクラスが、コンポーネントに特有の振る舞いを制御するために使用することができる設定を定義し、そのコンポーネントを展開するために提供することができるファイルおよびスクリプトのスキーマを定義する。
【０１４２】
ｃ）アプリケーションが、正しく機能するために何に依存するか。正しく機能するために、コンポーネントは、ターゲット環境内に既に存在していなければならないある機能に依存する可能性がある。例は、ＩＩＳに依存するＷｅｂサービスである。それらの要件は、リソース間のホスト関係として表現する。それらの関係を使用して、特定のアプリケーションが特定の環境で実行されるかどうかを前もって検査することを可能にするリソースタイプのセットにわたる依存関係ツリーを構築することができる。
【０１４３】
アプリケーションタイプ
リソース空間にて定義されたリソースクラスを使用してアプリケーションタイプを構築する。これらのクラスから、ポートタイプおよびワイヤタイプを導出してアプリケーション特有の通信リンクをモデル化し、コンポーネントタイプを構築してアプリケーションの別々の部分をモデル化する。
【０１４４】
ポートタイプは、アプリケーションに特定の振る舞いを記述する通信エンドポイントである。ポートリソースを取り込み、アプリケーション内でのポートリソースの使用に特有の情報を提供する。例は、ＳＯＡＰリソースを取り込み、ＷＳＤＬファイルを提供してアプリケーションが公開する機能を定義するポートタイプであろう。
【０１４５】
ワイヤタイプは、アプリケーション特有の通信パスを定義する。ワイヤタイプは、特定のワイヤリソースを２つの互換性のあるアプリケーションエンドポイントの接続に限定する。例えば、ＳＯＡＰワイヤリソースを取り込み、それらを上記に定義したＳＯＡＰポートタイプの接続に限定することが可能である。
【０１４６】
コンポーネントタイプを使用して、独立に展開することができ、マシン境界を越えて分散させることもできるアプリケーションの部分がモデル化される。例えば、Ｗｅｂフロントエンドとデータベースバックエンドを有するアプリケーションは、いくつかのコンポーネントタイプから成る可能性が高い。この場合、Ｗｅｂサービスリソースを取り込み、このリソースを使用してＷｅｂフロントエンドコンポーネントタイプを作成し、データベースリソースを使用してデータベースバックエンドコンポーネントタイプを作成することが可能である。次に、アプリケーションインターフェースをモデル化するために、そのコンポーネントタイプに適切なポートタイプを追加するであろう。それらをポートメンバと呼ぶ。
【０１４７】
使用される複合コンポーネントタイプは、グループコンポーネントであって共に新しいコンポーネントタイプを形成する。複合コンポーネント内部のコンポーネントタイプの使用は、コンポーネントメンバと呼ばれる。上記に定義したワイヤタイプを使用して、コンポーネントメンバが公開するインターフェースを他のメンバに接続する。それらが、複合コンポーネントのワイヤメンバとなる。
【０１４８】
複合コンポーネントがコンポーネントのように見えるためには、複合コンポーネントは、コンポーネントと同様にインターフェース、機能、および要件を公開する必要がある。これは、複合コンポーネントのコンポーネントメンバからポートメンバのサブセットを外に委任することによって行う。
【０１４９】
コンポーネントの要件を満たすために、合致する機能を有する別のコンポーネントにそのコンポーネントをバインドしなければならない。このプロセスをバインド化と呼ぶ。
【０１５０】
例示的な実装
このセクションでは、ＳＤＭモデルの要素を定義するために使用するＸＭＬスキーマを説明する。設定はアプリケーションとリソースの両方によって使用されるので、まずそれを説明し、次にリソースクラスを、そしてアプリケーションタイプを説明し、最後にインスタンス空間を説明する。
【０１５１】
名前付け
名前空間を使用して、クラスおよびタイプを定義することができる名前付け範囲が定義される。名前空間内では、すべてのクラス名およびすべてのタイプ名が固有である。名前空間は、名前空間の内容を検証するために使用することができる名前、バージョン、および暗号キーによって定義される。
＜xs:attributeGroup name＝”identity”＞ 
＜xs:attribute name＝”name” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”version” type＝”fourPartVersionType” 
use＝”required”/＞
＜xs:attribute name＝”publicKeyToken” type＝”publicKeyTokenType” 
use＝”optional”/＞
＜/xs:attributeGroup＞
【０１５２】
ファイルバージョンは、Ｎ．Ｎ．Ｎ．Ｎ．形式の４つの部分から成る番号によって定義され、ここで０＜Ｎ＜６５５３５である。
＜xs:simpleType name＝”fourPartVersionType”＞
＜xs:annotation＞
＜xs:documentation＞Four part version numbers where the segments are in the range 0-65535 ＜/xs:documentation＞
＜/xs:annotation＞
＜xs:restriction base＝”xs:string”＞
＜xs:pattern value＝”(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？).(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？).(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？).(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？)”/＞
＜/xs:restriction＞
＜/xs:simpleType＞
【０１５３】
公開キートークンは、公開／秘密キーペアの公開部分を特定する１６文字の１６進ストリングである。ドキュメントは、秘密キーを使用して署名され、ドキュメントのユーザが、公開キーを使用してその内容を検証することを可能にする。
＜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＞
【０１５４】
次に、名前空間内の単純名が、ストリングを使用して構築される。名前空間を現在の名前空間にインポートし、エイリアスをその名前空間に関連付けることにより、名前空間が他の名前空間を参照することを可能にする。
＜xs:complexType name＝”import”＞
＜xs:attribute name＝”alias” type＝”xs:string” use＝”required”/＞
＜xs:attributeGroup ref＝”identity”/＞
＜/xs:complexType＞
【０１５５】
クラスおよびタイプに対する参照は、現在の名前空間内で定義されたオブジェクトを参照する単純名であるか、または別の名前空間内で定義されたオブジェクトを特定するためにエイリアスと単純名の両方を使用する複合名である。
【０１５６】
設定
リソースクラスとアプリケーションタイプはともに、設定スキーマを公開することができる。このスキーマを使用して、新たなポートタイプ、ワイヤタイプ、またはコンポーネントタイプがクラスから作成されるとき、ポートタイプがコンポーネントタイプに追加されるとき、またはワイヤタイプまたはコンポーネントタイプが複合コンポーネントタイプにて使用されるときに提供することができる値が記述される。
【０１５７】
設定スキーマ
ＸＳＤを使用して設定スキーマを記述する。最初のリリースでは、単純なタイプ、および要素タイプのリストに限定されるＸＳＤのサブセットを使用する。
＜xs:complexType name＝”settingSchema”＞
＜xs:sequence＞
＜xs:any namespace＝”http://www.w3.org/2001/XMLSchema” 
processContents＝”skip” minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
【０１５８】
設定値
設定値は、タイプがクラスに基づいて作成されるとき、またはタイプがコンポーネントもしくは複合コンポーネント内部で使用されるときに提供される。設定値は、適切な設定スキーマに準拠するＸＭＬブロックである。
＜xs:complexType name＝”settingValues”＞
＜xs:sequence＞
＜xs:any namespace＝”##other” processContents＝”lax”/＞
＜/xs:sequence＞
＜/xs:complexType＞
【０１５９】
設定フロー
設定フローを使用して、設定値が、コンポーネントタイプからコンポーネントタイプのメンバに受け渡されることを可能にする。設定フローは、タイプによって定義された設定スキーマから値を選択する値設定セクションにおいてＸＰＡＴＨを使用して実装される。
ＳＤＭ名前空間内で定義される特別な属性の使用により、コンテンツを流したい値を特定する。この属性がある要素上に存在する場合、その属性値は、そのタイプの設定スキーマへのＸＰａｔｈであると考える。
【０１６０】
設定制約
設定制約を使用して、設定値が検証され、制約される。例えば、ＩＩＳサーバは、自らがホストするすべてのＷｅｂサービスがその設定値の一部を特定の値または特定の範囲の値に限定することを要求することができる。ＸＰＡＴＨを使用して設定値を検証する（または、ＸＱＵＥＲＹが完全にサポートされるとＸＱＵＥＲＹ）。以下の形態の照会をサポートする。
●パスが存在しなければならない
●パスが存在してはならない
●パスが存在するのであれば［（パスが存在しなければならない｜パスが存在してはならない）＊］
【０１６１】
第１の形態を使用して、設定が特定の値、または特定の１組の値に設定されることを要求することができ、第２の形態を使用して、設定がある値、またはある１組の値に設定されないことを要求することができ、第３の形態を使用して、設定の組合せが一緒に設定されることを要求する設定間の関係を構築することができる。
＜xs:complexType name＝”settingConstraints”＞
＜xs:sequence＞
＜xs:element name＝”mustExist” type＝”simpleTest” 
minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜xs:element name＝”mustNotExist” type＝”simpleTest” 
minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜xs:element name＝”ifExists” type＝”nestedTest” 
minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜xs:element name＝”ifNotExists” type＝”nestedTest” 
minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:attributeGroup name＝”testAttributes”＞
＜xs:attribute name＝”path” type＝”xs:string”/＞
＜xs:attribute name＝”ifNullPath” type＝”ifNullPath”/＞
＜xs:attribute name＝”error” type＝”xs:int”/＞
＜xs:attribute name＝”errorDesc” type＝”xs:string”/＞
＜/xs:attributeGroup＞
＜xs:complexType name＝”simpleTest”＞
＜xs:attributeGroup ref＝”testAttributes”/＞
＜/xs:complexType＞
＜xs:complexType name＝”nestedTest”＞
＜xs:sequence＞
＜xs:element name＝”mustExist” type＝”simpleTest” 
minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜xs:element name＝”mustNotExist” type＝”simpleTest” 
minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜xs:element name＝”ifExists” type＝”nestedTest” 
minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜xs:element name＝”ifNotExists” type＝”nestedTest” 
minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜xs:attributeGroup ref＝”testAttributes”/＞
＜/xs:complexType＞
【０１６２】
パスが存在しないケースに対処するためのオプションを公開する必要がある。以下により、設計者が、エラーを生じさせること、値を挿入すること、または試験を無視することを選択することができるようにする。
＜xs:simpleType name＝”ifNullPath”＞
＜xs:restriction base＝”xs:string”＞
＜xs:enumeration value＝”skip”/＞
＜xs:enumeration value＝”override”/＞
＜xs:enumeration value＝”returnError”/＞
＜/xs:restriction＞
＜/xs:simpleType＞
【０１６３】
例
以下は、コンピュータクラスが公開することができる値をモデル化している単純なスキーマである。このスキーマは、設定グループを特定する単一のトップレベルノード、およびそのノードの下の３つのプロパティを有する。
＜settingSchema＞
＜xs:schema＞
＜xs:element name＝”processorSettings”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”numberOfCpus” type＝”xs:int”/＞
＜xs:element name＝”memory” type＝”xs:int” /＞
＜xs:element name＝”dualHomed” type＝”xs:boolean”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:schema＞
＜/settingSchema＞
【０１６４】
タイプ内のスキーマに以下の値を提供することが可能である。
＜settings＞
＜processorSettings＞
＜numberOfCpus＞4＜/numberOfCpus＞
＜memory＞8000＜/memory＞
＜dualHomed＞false＜/dualHomed＞
＜/processorSettings＞
＜/settings＞
【０１６５】
タイプが使用されたときに設定値を提供することを望む場合、設定フローを使用する。
これらの値に対して制約を書くことができる。この例では、最初のものが、単純なｍｕｓｔＥｘｉｔ制約である。第２の制約は試験を使用してネストされた制約を評価するかどうかを決める。
＜constraints＞
＜mustExist  path＝”ProcessorSettings/[memory ＞＝ 1000]” 
errorDesc＝”Host machine does not have enough memory”/＞
＜ifExists path＝”ProcessorSettings/[cpu ＞＝ 2]” 
errorDesc＝”Host machine has two processors but not enough resources”＞
＜mustExist  path＝”ProcessorSettings/[memory ＞＝ 2000]” 
errorDesc＝”Host machine does not have enough memory”/＞
＜/ifExists ＞
＜/constraints＞
【０１６６】
リソース
基本クラス
すべてのリソースクラススキーマは、クラスから導出される。これらのスキーマは、設定スキーマ、展開スキーマ、名前属性およびレイヤ属性を共有する。設定スキーマは、そのクラス、タイプがとることができる値、および各タイプの記述に基づき、タイプに適用される設定を記述する。展開スキーマは、そのリソースに基づいているタイプを展開するのため必要とされる情報を記述する。レイヤ属性は、リソースを設計空間の１つのレイヤに関連付けている。名前属性は、クラスに名前空間内で固有の名前を与えるために使用される。
＜xs:complexType name＝”class”＞
＜xs:sequence＞
＜xs:element name＝”deploymentSchema” type＝”deploymentSchema” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”settingSchema” type＝”settingsSchema” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”layer” type＝”layer” use＝”required”/＞
＜/xs:complexType＞
【０１６７】
展開スキーマについて、名前空間は未定義のままにされる。スキーマ上の制約はそのクラスに関するインストーラが全面的に担う。
＜xs:complexType name＝”deploymentSchema”＞
＜xs:sequence＞
＜xs:any namespace＝”##other” processContents＝”lax”/＞
＜/xs:sequence＞
＜/xs:complexType＞
【０１６８】
展開セクションの一部として提供される値は、関連する展開スキーマに合致しなければならない。
＜xs:complexType name＝”deploymentValues”＞
＜xs:sequence＞
＜xs:any namespace＝”##other” processContents＝”lax”/＞
＜/xs:sequence＞
＜/xs:complexType＞
【０１６９】
レイヤ属性は、４つのレイヤタイプの列挙である。アプリケーションレイヤは、データベースやＷｅｂサーバなどの高レベルのアプリケーションコンポーネントを収容する。サービスレイヤは、ＩＩＳやＳＱＬなどのミドルウェアサービスを収容する。ネットワークレイヤは、オペレーティングシステム定義、ストレージ定義、およびネットワーク定義を収容する。ハードウェアレイヤは、データセンタのハードウェアコンポーネントの定義を収容する。
＜xs:simpleType name＝”layer”＞
＜xs:restriction base＝”xs:string”＞
＜xs:enumeration value＝”Application”/＞
＜xs:enumeration value＝”Service”/＞
＜xs:enumeration value＝”Network”/＞
＜xs:enumeration value＝”Hardware”/＞
＜/xs:restriction＞
＜/xs:simpleType＞
【０１７０】
ポートクラス
ポートクラスは、リソース基本タイプにおいて定義された情報より上の情報を一切収容しない。
＜xs:complexType name＝”portClass”＞
＜xs:complexContent＞
＜xs:extension base＝”class”＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
【０１７１】
コンポーネントクラス
コンポーネントクラスは、許可されたポートクラスのリストを追加することによって基本クラスを拡張する。
＜xs:complexType name＝”componentClass”＞
＜xs:complexContent＞
＜xs:extension base＝”class”＞
＜xs:sequence＞
＜xs:element name＝”portClassesAllowed”
type＝”portClassesAllowed” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
【０１７２】
ポートクラスのリストは開いていることも、または閉じていることもでき、閉じている場合、リストに現れるクラスに基づくこうしたポートタイプだけが、関連するコンポーネントタイプ上で使用することができる。ｍｉｎＯｃｃｕｒｓ属性およびｍａｘＯｃｃｕｒｓ属性は、それらのポートの１つを使用することができる回数を定義する。
＜xs:complexType name＝”portClassesAllowed”＞
＜xs:sequence＞
＜xs:element name＝”portClassRef” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”minOccurs” type＝”xs:int” use＝”optional”/＞
＜xs:attribute name＝”maxOccurs” type＝”xs:string” use＝”optional”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜xs:attribute name＝”closed” type＝”xs:boolean” 
default＝”true” use＝”optional”/＞
＜/xs:complexType＞
【０１７３】
ワイヤクラス
ワイヤクラスも、許可されたポートのリストを追加することによって基本スキーマを拡張する。この場合、リストは、ワイヤタイプに関連付けることができるポートタイプのクラスを定義する。
＜xs:complexType name＝”wireClass”＞
＜xs:complexContent＞
＜xs:extension base＝”class”＞
＜xs:sequence＞
＜xs:element name＝”portClassesAllowed” type＝”portClassesAllowed” minOccurs＝”0” maxOccurs＝”1”/＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
【０１７４】
ホスト関係
ホスト関係は、ソースクラス、ターゲットクラス、およびインストーラを特定する３つを定義する。その関係が存在することにより、ソースクラスに基づくタイプのインスタンスが、ターゲットクラスに基づくタイプのインスタンス、およびその関係に関連するインストーラを使用して作成される得ることが示される。ターゲットクラスは、コンポーネントクラスでなければならない。
【０１７５】
例えば、Ｗｅｂサービスクラスは、ＩＩＳクラスおよびＷｅｂサービスインストーラとのホスト関係においてソースクラスであることがある。この場合、その関係はインストーラを使用して、タイプＭｙＩＩＳ上のタイプＭｙＷｅｂｓｅｒｖｉｃｅのインスタンスを作成することが可能であることを示す。アプリケーション空間とインスタンス空間の両方に存在する制約を評価するまで、その関係を作成することが可能であるかどうかは分からない。
＜xs:complexType name＝”hostRelation”＞
＜xs:attribute name＝”classRef” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”componentHostClassRef” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”installerRef” type＝”xs:string” use＝”required”/＞
＜/xs:complexType＞
【０１７６】
インストーラは、名前、コードタイプ、およびインストーラを実装するバイナリへのリンクによって特定される。
＜xs:complexType name＝”installer”＞
＜xs:sequence＞
＜xs:element name＝”binary” type＝”xs:string” minOccurs＝”1” maxOccurs＝”1”/＞
＜/xs:sequence＞
＜xs:attribute name＝”codeType” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required”/＞
＜/xs:complexType＞
【０１７７】
例
以上の例は、拡張された４層の例からの抜粋である。詳細については、完全な例示的ファイルを参照されたい。
【０１７８】
まず、いくつかのポートクラスを作成してデータベースへのアクセスをモデル化する。このケースでは、サーバポートおよびクライアントポートを有する。
＜portClass name＝”ServerDataAccess” layer＝”Application”＞
＜settingSchema＞
＜xs:schema＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”databaseName” type＝”xs:string”/＞
＜!-- 他の接続ストリングプロパティ --＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:schema＞
＜/settingSchema＞
＜/portClass＞
＜portClass name＝”ClientDataAccess” layer＝”Application”/＞
【０１７９】
次に、２つのポートクラス間で通信リンクをモデル化するワイヤクラスを作成する。ワイヤクラスは、上記で２つのポートクラスが定義したいくつかの設定、および参照を有する。このケースでは、ワイヤにより、接続上に１つのサーバだけが存在するように制約され、クライアントポートが複数のサーバにわたる接続をどのように負荷分散するかを知らないことがモデル化されている。より複雑なワイヤ実装により、複数のサーバを許容しと、接続を解決する何らかの形態の管理を実装する。
＜wireClass name＝”DataConnection” layer＝”Application”＞
＜settingSchema＞
＜xs:schema＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”useSSL” type＝”xs:boolean”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:schema＞
＜/settingSchema＞
＜portClassesAllowed＞
＜portClassRef name＝”ServerDataAccess”  maxOccurs＝”1”/＞
＜portClassRef name＝”ClientDataAccess”/＞
＜/portClassesAllowed＞
＜/wireClass＞
【０１８０】
最後に、データベースをモデル化するコンポーネントクラスを作成する。このクラスは、設定と展開スキーマの両方を有し、そのクラスに基づいてコンポーネント上に存在することができるポートを特定する。
＜componentClass name＝”Database” layer＝”Application”＞
＜deploymentSchema＞
＜xs:schema＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”sqlScriptFilePath” type＝”xs:string” 
maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:schema＞
＜/deploymentSchema＞
＜settingSchema＞
＜xs:schema＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”databaseName” type＝”xs:string”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:schema＞
＜/settingSchema＞
＜portClassesAllowed closed＝”true”＞
＜portClassRef name＝”ServerDataAccess”/＞
＜/portClassesAllowed＞
＜/componentClass＞
【０１８１】
以上すべてのコンポーネントは、互換性のあるホストタイプへのマッピングを必要とする。このケースでは、ＳＱＬサーバがサーバポートおよびデータベースのホストとして働き、ＩＩＳがｓｑｌクライアントポートのホストとして働いている。それらのクラスは、ミドルウェアにエイリアスさられた別個の名前空間にて定義される。
＜hostRelations＞
＜installer name＝”DatabaseInstaller” codeType＝”InstallerPlugin”/＞
＜hostRelation classRef＝”database” 
componentHostClassRef＝”middleware:SQL” 
installerRef＝”DatabaseInstaller”/＞
＜hostRelation classRef＝”ServerDataAccess” 
componentHostClassRef＝” middleware:SQL” 
installerRef＝”DatabaseInstaller”/＞
＜hostRelation classRef＝”ClientDataAccess” 
componentHostClassRef＝” middleware:IIS” 
installerRef＝”WebServiceInstaller”/＞
＜/hostRelations＞
【０１８２】
アプリケーション
アプリケーション開発者は、アプリケーション空間にてコンポーネントタイプ、ポートタイプ、およびワイヤタイプを作成して自身のアプリケーションをモデル化する。それらのタイプは、開発者が作業しているレイヤに合致するクラスを選択し、次に、そのクラスに値を供給することによって作成される。
【０１８３】
アプリケーション基本タイプ
すべてのアプリケーションタイプスキーマは、以下のアプリケーション基本スキーマに基づく。基本スキーマ属性は、タイプが基づくクラス、およびそのタイプの名前を特定する。スキーマの本文において、そのタイプを展開することができるようにする展開値、および関連するクラス上の設定スキーマに関する設定を特定する。タイプは、そのタイプが他のタイプ内で使用されるときに提供可能な値を特定する新たな設定スキーマを定義することもできる。最後に、基本タイプは、ホスト制約のためのセクションを含む。このセクションは、そのタイプに関連するクラスのリソース空間に存在するホスト関係に基づき、そのタイプについての可能なホストに関する制約を特定する。
＜xs:complexType name＝”baseType”＞
＜xs:sequence＞
＜xs:element name＝”deployment” type＝”deploymentValues” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”settings” type＝”settingsValues” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”settingSchema” type＝”settingSchema” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”hostConstraints” type＝”hostConstraints”
minOccurs＝”0” maxOccurs＝”1”/＞
＜/xs:sequence＞
＜xs:attribute name＝”class” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required”/＞
＜/xs:complexType＞
【０１８４】
ｈｏｓｔＣｏｎｓｔｒａｉｎｔｓセクションは、そのタイプに関連するクラスをホストすることが可能なクラスのそれぞれについての１組の制約を含んでいる。それらのクラスは、リソース空間においてホスト関係によって特定される。各クラスに関連する制約は、そのクラスの設定スキーマに関する。制約の形態は、上記に定義した。
＜xs:complexType name＝”hostConstraints”＞
＜xs:sequence＞
＜xs:element name＝”hostConstraint” minOccurs＝”1” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”constraint” type＝”settingConstraint”/＞
＜/xs:sequence＞
＜xs:attribute name＝”host” type＝”xs:string” use＝”required”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
【０１８５】
ポートタイプ
ポートタイプは、単に基本タイプを使用する。ポートタイプに関連する情報はさらにはない。
＜xs:complexType name＝”portType”＞
＜xs:complexContent＞
＜xs:extension base＝”baseType”＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
【０１８６】
ワイヤタイプ
ワイヤタイプは、基本タイプを拡張して許可されたポートタイプのリストを追加する。次に、それらのポートタイプの使用を複合コンポーネント内のワイヤタイプの使用に関連付けることができる。このようにワイヤタイプを定義することにより、アプリケーション設計者は、互換性のあるポートタイプに関するワイヤタイプを作成するだけで、自身のアプリケーションの部分間の許容可能な接続のセットを制約することができる。
＜xs:complexType name＝”wireType”＞
＜xs:complexContent＞
＜xs:extension base＝”baseType”＞
＜xs:sequence＞
＜xs:element name＝”portTypeRefs” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portTypeRef” 
minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:attribute name＝”name” type＝”xs:string” 
use＝”required”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
【０１８７】
コンポーネントタイプ
コンポーネントタイプは、基本タイプを拡張して、ポートメンバのリスト、およびホストされたクラスのリストを追加する。
【０１８８】
各ポートメンバは、既存のポートタイプの使用である。ホストされるクラスのリストにより、そのコンポーネントがホストすることができるクラスが特定される。それらのクラスは、そのタイプのクラスが潜在的なホストとして特定される、リソース空間においてホスト関係によって特定されたクラスのサブセットである。
＜xs:complexType name＝”componentType”＞
＜xs:complexContent＞
＜xs:extension base＝”baseType”＞
＜xs:sequence＞
＜xs:element name＝”ports” type＝”portsList” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”hostedClasses” type＝”hostedClassesList” 
minOccurs＝”0” maxOccurs＝”1”＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
【０１８９】
ポートリスト内の各ポートメンバは、名前およびタイプによって特定される。ポート名は、コンポーネント内で固有でなければならない。ポートタイプは、そのコンポーネントタイプと関連するコンポーネントクラス上で許可されている関連ポートクラスを有していなければならない。各ポートメンバについて、ポートタイプによって定義されたスキーマに合致する設定のリストを提供することができる。
＜xs:complexType name＝”portsList”＞
＜xs:sequence＞
＜xs:element name＝”port” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”settings” type＝”settingValues” minOccurs＝”0” maxOccurs＝”1”/＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”type” type＝”xs:string”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
【０１９０】
ホストされたクラスのリスト内の各クラスについて、制約のリストを関連付けることができる。それらの制約は、ホストされたクラスの設定スキーマに関して書かれる。
＜xs:complexType name＝”hostedClassesList”＞
＜xs:sequence＞
＜xs:element name＝”hostedClass” minOccurs＝”1” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”constraints” type＝”settingConstraints” minOccurs＝”1” maxOccurs＝”1”/＞
＜/xs:sequence＞
＜xs:attribute name＝”class” type＝”xs:string” use＝”required”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
【０１９１】
複合コンポーネントタイプ
複合コンポーネントタイプ（以降、複合コンポーネントと呼ぶ）は、新しいコンポーネントタイプを定義する。複合コンポーネントを定義する際、そのタイプのメンバがコロケートされるべきことを指定するオプションがある。メンバがコロケートされる場合、タイプが展開される際に、そのタイプのすべてのメンバが、単一のホスト上に展開されなければならない。また、複合コンポーネントは、コンポーネントメンバのリスト、ワイヤメンバのリスト、コンポーネントが委任するポートを定義しているセクション、およびコンポーネントがホストすることができるクラスを特定しているするリストを含む。
＜xs:complexType name＝”compoundComponentType”＞
＜xs:sequence＞
＜xs:element name＝”components” type＝”components” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”wires” type＝”wires” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”delegatePorts” type＝”delegatePorts” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”delegateHostedClasses” type＝”delegateHostedClasses” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”colocate” type＝”xs:boolean” 
use＝”optional” default＝”false”/＞
＜/xs:complexType＞
【０１９２】
コンポーネントリストは、既に定義済みのコンポーネントタイプの使用を特定し、それらを複合コンポーネントのコンポーネントメンバと呼ぶ。各メンバは、複合コンポーネント内で固有の名前、そのメンバを定義するタイプに対する参照、およびそのメンバがシングルトンであるかどうかを示すフラグを有している。
【０１９３】
コンポーネントメンバがシングルトンとマークされている場合、そのインスタンスを収容している複合コンポーネントのインスタンス内にそのコンポーネントメンバのインスタンスが１つだけ存在することができる。シングルトンとマークされていない場合、メンバのインスタンスが、負荷の変化などの外的要因に応じて作成され、削除されることができる。これは、シングルトンでないメンバに接続されているいずれのコンポーネントメンバも、実行時にそのメンバの１つまたは複数のインスタンスを見ることがあることを意味する。
【０１９４】
各コンポーネントメンバは、関連するコンポーネントタイプにおいて定義された設定スキーマに関する設定値を提供することもできる。
＜xs:complexType name＝”components”＞
＜xs:sequence＞
＜xs:element name＝”component” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”settings” type＝”settingValues” 
minOccurs＝”0” maxOccurs＝”1”/＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”type” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”singleton” type＝”xs:boolean” 
use＝”optional” default＝”false”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
【０１９５】
複合コンポーネント内のワイヤタイプの使用は、ワイヤメンバと呼ばれる。各ワイヤメンバは、複合コンポーネントに固有であり、関連するワイヤタイプを特定する名前を有する。ワイヤメンバは、ワイヤタイプにて定義された設定スキーマに関する設定値を提供することもできる。
【０１９６】
ワイヤメンバの重要な役割は、複合コンポーネント内でコンポーネントメンバ間の接続を特定することである。これが行なわれる方法は、ポート参照をワイヤメンバに追加することである。各ポート参照は、複合コンポーネント内でコンポーネントメンバ上のポートを特定する。参照ポートのポートタイプは、ワイヤタイプに関連するポートタイプと合致しなければならない。
＜xs:complexType name＝”wires”＞
＜xs:sequence＞
＜xs:element name＝”wire” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”settings” type＝”settingValues” minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”members” minOccurs＝”1” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”member” type＝”componentPortRef” minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required”/＞
＜xs:attribute name＝”type” type＝”xs:string”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
【０１９７】
ポート参照は、同じ収容複合コンポーネント内のコンポーネントメンバを特定する。ポート名は、コンポーネントメンバに関連するコンポーネントタイプ上のポートメンバの名前である。
＜xs:complexType name＝”componentPortRef”＞
＜xs:attribute name＝”componentName” type＝”xs:string”/＞
＜xs:attribute name＝”portName” type＝”xs:string” use＝”required”/＞
＜/xs:complexType＞
【０１９８】
複合コンポーネントは、ポートタイプを直接に使用することができない。というのは、ポートメンバがバインドすることが可能な複合コンポーネントに関連するコードが存在しないためである。代わりに、複合コンポーネントのコンポーネントメンバからポートメンバを外に委任する。これは、複合コンポーネントがコンポーネントタイプとして使用される際、それらのポートがあたかもその複合コンポーネントに属しているかのように見えることを意味する。
【０１９９】
ポートが委任されると、まず、コンポーネントメンバをを特定し、次に、そのコンポーネント内のポートメンバを特定することによって特定される。このポートは、このプロセスの一環として名前を変更することができる。これは同じ名前を有するポートが異なるコンポーネントメンバから委任される場合に名前の競合を回避するためである。
＜xs:complexType name＝”delegatePorts”＞
＜xs:sequence＞
＜xs:element name＝”delegatePort” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:attribute name＝”name” type＝”xs:string”/＞
＜xs:attribute name＝”componentName” type＝”xs:string”/＞
＜xs:attribute name＝”portName” type＝”xs:string” use＝”optional”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
【０２００】
ある範囲の異なるクラスに関するサービスを提供することができるホストを構成するため、複合コンポーネントが、自らのコンポーネントメンバからホストされたクラスの宣言を公開することを可能にする。複合コンポーネントがコンポーネントタイプとして使用されると、複合コンポーネントは、すべての宣言されたクラスのホストとして働くことができるように見える。
【０２０１】
それらのホストされたクラスの宣言を公開するために、ポートメンバを委任したのと同様の方法で委任を使用する。ホストされたクラスを収容するコンポーネントメンバを特定し、次に、コンポーネントがホストすることができると主張するクラスを特定する。
＜xs:complexType name＝”delegateHostedClasses”＞
＜xs:sequence＞
＜xs:element name＝”hostedClassRef” 
minOccurs＝”1” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:attribute name＝”componentName” type＝”xs:string”/＞
＜xs:attribute name＝”hostedClass” type＝”xs:string” 
use＝”required”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
【０２０２】
バインド化
バインド化は、特定の複合コンポーネントのメンバについてのホストを特定するプロセスである。これを行うのは、アプリケーションとアプリケーションがホストされることになる環境との互換性を検査し、アプリケーションを展開するためである。アプリケーションとホスト環境はともに、複合コンポーネントを使用してモデル化され、バインドするプロセスが、メンバ間の接続トポロジをサポートする両方のコンポーネントから合致するメンバを見つけるようにする。
【０２０３】
メンバについて互換性のあるホストを特定するため、リソース空間においてクラス間の関係を調べることから始める。ワイヤメンバまたはコンポーネントメンバのタイプを調べて、そのメンバに関連するクラスを特定する。次に、コンポーネントタイプに関連する互換性のあるクラスを有するホストコンポーネント内のコンポーネントメンバを探す。次に、そのメンバに関連するタイプに関するホスト制約を調べて、その制約がホストメンバのタイプに関する設定に合致するかどうかを検討する。次に、その逆を行い、ホストしたいと望むメンバのタイプに関する設定に照らして、ホストメンバのタイプに関するｈｏｓｔｅｄＣｌａｓｓ制約をチェックする。
【０２０４】
コンポーネントメンバを合致させようと試みているのであれば、そのコンポーネントメンバのタイプのすべてのポートメンバも、そのコンポーネントメンバに対する任意の潜在的なホスト上にホストすることができることを確かめる必要がある。
【０２０５】
ワイヤメンバを合致させようと試みているのであれば、ホストしようと試みている複合コンポーネント内のコンポーネントメンバのために選択するホスト間のパス上に存在するどのコンポーネントメンバも合致させなければならない。
【０２０６】
前述の例で説明したポートクラスに基づき、２つのポートタイプを作成する。
＜xs:complexType name＝”delegateHostedClasses”＞
＜xs:sequence＞
＜xs:element name＝”hostedClassRef” 
minOccurs＝”1” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:attribute name＝”componentName” type＝”xs:string”/＞
＜xs:attribute name＝”hostedClass” type＝”xs:string” 
use＝”required”/＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
【０２０７】
これらのタイプは、ワイヤタイプによって補完される。
＜wireType name＝”UserData” class＝”DataConnection”＞
＜deployment/＞
＜settings＞
＜useSSL＞false＜/useSSL＞
＜/settings＞
＜portTypeRefs＞
＜portTypeRef name＝”UserDataServer”/＞
＜portTypeRef name＝”UserDataClient”/＞
＜/portTypeRefs＞
＜/wireType＞
【０２０８】
次に、データベースクラスに基づいてコンポーネントタイプを作成する。データベースタイプは、１つのサーバデータポートを公開する。
＜componentType name＝”UserData” class＝”Database”＞
＜deployment＞
＜sqlScriptFilePath＞%install%￥mydatabaseDfn.sql＜/sqlScriptFilePath＞
＜/deployment＞
＜settings＞
＜databaseName＞UserData＜/databaseName＞
＜/settings＞
＜ports＞
＜port name＝”userData” type＝”UserDataServer”/＞
＜/ports＞
＜/componentType＞
【０２０９】
これらのタイプのいくつかを使用する複合コンポーネントタイプを作成することが可能である。以下の複合コンポーネントは、３つのコンポーネントタイプを使用している。第１のタイプＵｓｅｒＰａｇｅｓは、２つのアクセスポイントを有するＷｅｂサービスを表わし、第２のタイプＱｕｅｒｙＭａｎａｇｅｍｅｎｔは、中間層の論理コンポーネントを表わし、最後のタイプはデータベースタイプである。２つのワイヤタイプＵｓｅｒＤａｔａおよびＱｕｅｒｙＭａｎａｇｅｒを使用して、これらのコンポーネントを接続する。データワイヤが中間層をデータベースに接続し、クエリワイヤがフロントエンドを中間層に接続する。次に、委任を使用してフロントエンドから２つのポート、サインアップ（ｓｉｇｎｕｐ）および問い合わせ（ｅｎｑｕｉｒｙ）を公開する。
＜compoundComponentType name＝”UserManagementApplication”＞
＜components＞
＜component name＝”userPages” type＝”UserPages”/＞
＜component name＝”queryLogic” type＝”QueryManagement”/＞
＜component name＝”userData” type＝”UserData” singleton＝”true”/＞
＜/components＞
＜wires＞
＜wire name＝”data” type＝”UserData”＞
＜members＞
＜member componentName＝”queryLogic” portName＝”userData”/＞
＜member componentName＝”userData” portName＝”userData”/＞
＜/members＞
＜/wire＞
＜wire name＝”query” type＝”QueryManager”＞
＜members＞
＜member componentName＝”userPages” portName＝”queryManager1”/＞
＜member componentName＝”userPages” portName＝”queryManager2”/＞
＜member componentName＝”queryLogic” portName＝”queryManager”/＞
＜/members＞
＜/wire＞
＜/wires＞
＜delegatePorts＞
＜delegatePort name＝”signup” componentName＝”userPages” 
portName＝”signup”/＞
＜delegatePort name＝”enquiry” componentName＝”userPages” 
portName＝”enquiry”/＞
＜/delegatePorts＞
＜/compoundComponentType＞
【０２１０】
ＳＤＭドキュメント構造
ＳＤＭドキュメントは、ドキュメントの名前空間を定義する厳密な識別情報（ｓｔｒｏｎｇ  ｉｄｅｎｔｉｔｙ）を有する。それは他の名前空間のリファレンスリストをインポートする。また、ドキュメントは、ドキュメント所有者、会社名、および改訂日などのドキュメント特有の属性を特定する情報セクションを収容する。次に、ドキュメントは、ポートクラス、ワイヤクラス、およびコンポーネントクラスのリスト、続いてホスト関係のリスト、続いてポートタイプ、ワイヤタイプ、およびコンポーネントタイプのリストを収容する。
＜xs:element name＝”sdm”＞
＜xs:annotation＞
＜xs:documentation＞SDM root element. It is a container for SDM types.＜/xs:documentation＞
＜/xs:annotation＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”import” type＝”import” minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜xs:element name＝”information” type＝”information” minOccurs＝”0” maxOccurs＝”1”/＞
＜xs:element name＝”portClasses” minOccurs＝”0” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portClass” type＝”portClass” minOccurs＝”1” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”wireClasses” minOccurs＝”0” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”wireClass” type＝”wireClass” minOccurs＝”1” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”componentClasses” minOccurs＝”0” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”componentClass” type＝”componentClass” minOccurs＝”1” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”hostRelations” minOccurs＝”0” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”installer” type＝”installer” minOccurs＝”1” maxOccurs＝”unbounded”/＞
＜xs:element name＝”hostRelation” type＝”hostRelation” minOccurs＝”1” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”portTypes” minOccurs＝”0” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portType” type＝”portType” minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”wireTypes” minOccurs＝”0” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”wireType” type＝”wireType” minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”componentTypes” minOccurs＝”0” maxOccurs＝”1”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”componentType” type＝”componentType” minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜xs:element name＝”compoundComponentType” type＝”compoundComponentType” minOccurs＝”0” maxOccurs＝”unbounded”/＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜xs:attributeGroup ref＝”identity”/＞
＜/xs:complexType＞
＜/xs:element＞
【０２１１】
関連ＸＳＤ
以下は、変更要求の例示的な構造である。
＜？xml version＝”1.0” encoding＝”utf-8” ？＞
＜xs:schema targetNamespace＝”urn:schemas-microsoft-com:sdmChangeRequest” xmlns＝”urn:schemas-microsoft-com:sdmChangeRequest” xmlns:settings＝”urn:schemas-microsoft-com:sdmSettings” xmlns:mstns＝”http://tempuri.org/XMLSchema.xsd” xmlns:xs＝”http://www.w3.org/2001/XMLSchema” elementFormDefault＝”qualified” version＝”0.7” id＝”sdmChangeRequest”＞
＜xs:import namespace＝”urn:schemas-microsoft-com:sdmSettings” schemaLocation＝”SDM7Settings.xsd” /＞
＜xs:import namespace＝”urn:schemas-microsoft-com:sdmNames” schemaLocation＝”SDM7Names.xsd” /＞
＜xs:complexType name＝”ChangeRequestType”＞
＜xs:sequence＞
＜xs:element name＝”group” type＝”groupType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:complexType name＝”groupType”＞
＜xs:sequence＞
＜xs:element name＝”group” type＝”groupType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”addInstance” type＝”addInstanceType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”updateInstance” type＝”updateInstanceType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”deleteInstance” type＝”deleteInstanceType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”addConnection” type＝”addConnectionType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”deleteConnection” type＝”deleteConnectionType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜xs:attribute name＝”canLeConcurrentlyExecuted” type＝”xs:boolean” /＞
＜/xs:complexType＞
＜xs:complexType name＝”addInstanceType”＞
＜xs:sequence＞
＜xs:element name＝”classSettings” type＝”settings:settingValues” minOccurs＝”0” /＞
＜xs:element name＝”typeSettings” type＝”settings:settingValues” minOccurs＝”0” /＞
＜!-- クラスの値を設定 --＞
＜!-- タイプの値を設定 --＞
＜/xs:sequence＞
＜xs:attribute name＝”parent” type＝”reference” use＝”optional” /＞
＜xs:attribute name＝”host” type＝”reference” use＝”optional” /＞
＜xs:attribute name＝”member” type＝”xs:string” use＝”optional” /＞
＜xs:attribute name＝”type” type＝”xs:string” use＝”optional” /＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”optional” /＞
＜!-- このインスタンスの親 --＞
＜!-- このインスタンスのホスト --＞
＜!-- 親タイプ上のメンバの名前 --＞
＜!-- これがそのインスタンスである完全修飾されたタイプ --＞
＜!-- インスタンスが作成されると充てんできるIDのエイリアス
この名前は同じメンバのすべてのインスタンスに対して固有でなければならない --＞
＜/xs:complexType＞
＜!-- インスタンスに関して何を変えることができる？ --＞
＜xs:complexType name＝”updateInstanceType”＞
＜xs:sequence＞
＜xs:element name＝”classSettings” type＝”settings:settingValues” minOccurs＝”0” /＞
＜xs:element name＝”typeSettings” type＝”settings:settingValues” minOccurs＝”0” /＞
＜!-- クラスの値を設定 --＞
＜!-- タイプの値を設定 --＞
＜/xs:sequence＞
＜xs:attribute name＝”id” type＝”reference” use＝”required” /＞
＜xs:attribute name＝”parent” type＝”reference” use＝”optional” /＞
＜xs:attribute name＝”host” type＝”reference” use＝”optional” /＞
＜xs:attribute name＝”member” type＝”xs:string” use＝”optional” /＞
＜xs:attribute name＝”type” type＝”xs:string” use＝”optional” /＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”optional” /＞
＜!-- SDMランタイムにスコープした固有の識別子
これは、t_u101 ？ SDMランタイムによって生成され、不変とすることができる --＞
＜!-- このインスタンスの親 --＞
＜!-- このインスタンスのホスト --＞
＜!-- 親タイプ上のメンバの名前 --＞
＜!-- これがそのインスタンスである完全修飾されたタイプ --＞
＜!-- インスタンスが作成されると充てんできるIDのエイリアス
この名前は同じメンバのすべてのインスタンスに対して固有でなければならない --＞
＜/xs:complexType＞
＜xs:complexType name＝”deleteInstanceType”＞
＜xs:attribute name＝”id” type＝”reference” use＝”required” /＞
＜xs:attribute name＝”option” type＝”deleteOptionType” use＝”required” /＞
＜!-- SDMランタイムにスコープした固有の識別子
これはSDMランタイムによって生成され、不変とすることができる -_cf2 ＞
＜/xs:complexType＞
＜xs:complexType name＝”addConnectionType”＞
＜xs:attribute name＝”port” type＝”reference” use＝”required” /＞
＜xs:attribute name＝”wire” type＝”reference” use＝”required” /＞
＜/xs:complexType＞
＜xs:complexType name＝”deleteConnectionType”＞
＜xs:attribute name＝”port” type＝”reference” use＝”required” /＞
＜xs:attribute name＝”wire” type＝”reference” use＝”required” /＞
＜/xs:complexType＞
＜!-- リファレンスはguidまたはpathとすることができる --＞
＜xs:simpleType name＝”reference”＞
＜xs:union＞＜/xs:union＞
＜/xs:simpleType＞
＜!-- 削除オプションは: ？？？ --＞
＜xs:simpleType name＝”deleteOptionType”＞
＜xs:union＞＜/xs:union＞
＜/xs:simpleType＞
＜/xs:schema＞
【０２１２】
以下は、クラスの例示的な構造である。
＜？xml version＝”1.0” encoding＝”utf-8” ？＞
＜xs:schema targetNamespace＝”urn:schemas-microsoft-com:sdmClasses” xmlns＝”urn:schemas-microsoft-com:sdmClasses” xmlns:names＝”urn:schemas-microsoft-com:sdmNames” xmlns:settings＝”urn:schemas-microsoft-com:sdmSettings” xmlns:xs＝”http://www.w3.org/2001/XMLSchema” elementFormDefault＝”qualified” version＝”0.7” id＝”sdmClasses”＞
＜xs:import namespace＝”http://www.w3.org/2001/XMLSchema” /＞
＜xs:import namespace＝”urn:schemas-microsoft-com:sdmSettings” schemaLocation＝”SDM7Settings.xsd” /＞
＜xs:import namespace＝”urn:schemas-microsoft-com:sdmNames” schemaLocation＝”SDM7Names.xsd” /＞
＜!-- やるべきこと [BassamT]: ワイヤクラス、ワイヤタイプおよびワイヤメンバに関するポートクラス参照、ポートタイプ参照およびポートメンバを正規化 --＞
＜!-- やるべきこと [BassamT]: クラスに関してレイヤ属性は必須？ --＞
＜!-- やるべきこと [BassamT]: 検証のためにキーおよびキー参照を追加 --＞
＜!-- やるべきこと [BassamT]: インラインタイプのサポートを追加 --＞
＜!-- やるべきこと [BassamT]: minOccursとmaxOccursをスクラブ --＞
＜!-- やるべきこと [BassamT]: 「クラス」の新しい名前、たぶん「deployment」 --＞
＜!-- やるべきこと [BassamT]: 「ホスト」の新しい名前、たぶん「provider」 --＞
＜!-- レビュー事項 [BassamT]: このXSDでポート、コンポーネントおよびワイヤクラスの定義をマージできる？ もっと構文分析すれば、くどくならなくなるだろう --＞
＜!-- 検討事項 [BassamT]: シングルトン、コロケーション、インラインのようなものの一般属性メカニズム --＞
＜!-- やるべきこと [BassamT]: バインディング: メンバからコンポーネントメンバ --＞
＜!-- やるべきこと [geoffo]: ポート  これらはシングルトン？ --＞
＜!-- やるべきこと [geoffo]: 委任  どのようにポートを組み合わせるか？ --＞
＜!-- やるべきこと [geoffo] 適切な場所に＜any＞追加し戻す --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- SDMルートエレメント --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:element name＝”sdmClasses”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”import” type＝”names:import” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”information” type＝”information” minOccurs＝”0” /＞
＜xs:element name＝”portClasses” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portClass” type＝”portClass” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”componentClasses” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”componentClass” type＝”componentClass” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”protocols” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”protocol” type＝”protocol” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”hostRelations” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”installer” type＝”installer” maxOccurs＝”unbounded” /＞
＜xs:element name＝”hostRelation” type＝”hostRelation” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜xs:attributeGroup ref＝”names:namespaceIdentity” /＞
＜/xs:complexType＞
＜/xs:element＞
＜!-- SDMタイプライブラリ情報 --＞
＜xs:complexType name＝”information”＞
＜xs:annotation＞
＜xs:documentation＞Human readable information about the SDM type library.＜/xs:documentation＞
＜/xs:annotation＞
＜xs:sequence＞
＜xs:element name＝”friendlyName” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”companyName” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”copyright” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”trademark” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”description” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”comments” type＝”xs:string” minOccurs＝”0” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- クラス --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:complexType name＝”baseClass”＞
＜xs:sequence＞
＜xs:element name＝”deploymentSchema” type＝”settings:deploymentSchema” minOccurs＝”0” /＞
＜xs:element name＝”settingSchema” type＝”settings:settingSchema” minOccurs＝”0” /＞
＜!-- どのようにクラスを展開するかのXSDスキーマ --＞
＜!-- スキーマを設定 --＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”layer” type＝”xs:string” use＝”required” /＞
＜!-- レビュー事項 [BassamT] これらのレイヤはツールのためだけか、
それともSDMモデルで厳しく強制されている？
これらは、異なるレイヤからのコンポーネントをミックスするのが理にかなうケース
例えば、フィルタコンポーネントはレイヤ３にあるISAサーバでホストされたコンポーネントメタタイプかもしれない。
でも、レイヤ２のFilterメタタイプを使いたい --＞
＜/xs:complexType＞
＜!-- ポートクラス --＞
＜xs:complexType name＝”portClass”＞
＜xs:complexContent＞
＜xs:extension base＝”baseClass” /＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜!-- コンポーネントクラス --＞
＜xs:complexType name＝”componentClass”＞
＜xs:complexContent＞
＜xs:extension base＝”baseClass”＞
＜xs:sequence＞
＜xs:element name＝”portClassesAllowed” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portClassRef” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜xs:attribute name＝”closed” type＝”xs:boolean” use＝”optional” default＝”true” /＞
＜!-- 許容ポートはクローズリストかどうか --＞
＜!-- この値が「真」なら、ポートのこのリストは拡張不可. この値が「偽」なら、ポートのこのリストはオープンエンドで、リストされたポートは、必須とみなすことになる --＞
＜/xs:complexType＞
＜/xs:element＞
＜!-- このメタタイプのコンポーネントタイプに現れることができる許容ポートのセットについて制約のセットを指定することになる --＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜xs:complexType name＝”portClassRef”＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”required” type＝”xs:boolean” use＝”required” /＞
＜xs:attribute name＝”singleton” type＝”xs:boolean” use＝”required” /＞
＜!-- シングルトンは、親スコープ内にこのポートのインスタンスが１つしかないことを意味する --＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- 関係 --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:complexType name＝”relation”＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”installer” type＝”xs:string” use＝”optional” /＞
＜/xs:complexType＞
＜!-- プロトコルは、１つまたは複数のクラス間の関係である --＞
＜xs:complexType name＝”protocol”＞
＜xs:complexContent＞
＜xs:extension base＝”relation”＞
＜xs:sequence＞
＜xs:element name＝”portClassRef” type＝”portClassRef” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜!-- ２つのクラス間のホストの関係を定義 --＞
＜xs:complexType name＝”hostRelation”＞
＜xs:complexContent＞
＜xs:extension base＝”relation”＞
＜xs:attribute name＝”classRef” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”hostClassRef” type＝”xs:string” use＝”required” /＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜!-- このインストーラタイプは、関係のインスタント化を担うコードを識別する --＞
＜xs:complexType name＝”installer”＞
＜xs:sequence＞
＜xs:element name＝”binary” type＝”xs:string” /＞
＜/xs:sequence＞
＜xs:attribute name＝”codeType” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜/xs:complexType＞
＜/xs:schema＞
【０２１３】
以下は、展開ユニットの例示的な構造である。
＜？xml version＝”1.0” encoding＝”UTF-8” ？＞
＜xs:schema targetNamespace＝”urn:schemas-microsoft-com:sdmSDU” xmlns:xs＝”http://www.w3.org/2001/XMLSchema” xmlns:names＝”urn:schemas-microsoft-com:sdmNames” xmlns＝”urn:schemas-microsoft-com:sdmSDU” elementFormDefault＝”qualified” version＝”0.7” id＝”sdmSDU”＞
＜xs:import namespace＝”http://www.w3.org/2001/XMLSchema” /＞
＜xs:import namespace＝”urn:schemas-microsoft-com:sdmNames” schemaLocation＝”SDM7Names.xsd” /＞
＜!-- SDM展開ユニットは、１つまたは複数のSDMタイプファイルをインポートし、このSDMタイプファイルはタイプのサブセットについてインポートファイルからのマッピングを含む --＞
＜xs:element name＝”sdmDeploymentUnit”＞
＜xs:annotation＞
＜xs:documentation＞
The sdu contains a mapping of SDM types to their implementation.
＜/xs:documentation＞
＜/xs:annotation＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”import” type＝”names:import” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”implementation” type＝”implementationMap” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜!-- この展開ユニットの記述 --＞
＜xs:complexType name＝”deploymentDescription”＞
＜xs:attribute name＝”name” type＝”xs:string” /＞
＜xs:attribute name＝”dateCreated” type＝”xs:string” /＞
＜xs:attribute name＝”creator” type＝”xs:string” /＞
＜/xs:complexType＞
＜!-- タイプからこのタイプの実装へのマッピング --＞
＜xs:complexType name＝”implementationMap”＞
＜xs:sequence＞
＜xs:element name＝”version” type＝”xs:string” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜xs:attribute name＝”type” type＝”xs:string” /＞
＜xs:attribute name＝”path” type＝”xs:string” /＞
＜/xs:complexType＞
＜/xs:schema＞
【０２１４】
以下は、インスタンスの例示的な構造である。
＜？xml version＝”1.0” encoding＝”utf-8” ？＞
＜xs:schema targetNamespace＝”urn:schemas-microsoft-com:sdmInstances” xmlns:xs＝”http://www.w3.org/2001/XMLSchema” xmlns:settings＝”urn:schemas-microsoft-com:sdmSettings” xmlns＝”urn:schemas-microsoft-com:sdmInstances” elementFormDefault＝”qualified” version＝”0.7” id＝”sdmInstances”＞
＜xs:import namespace＝”http://www.w3.org/2001/XMLSchema” /＞
＜xs:import namespace＝”urn:schemas-microsoft-com:sdmSettings” schemaLocation＝”SDM7Settings.xsd” /＞
＜xs:element name＝”sdmInstances”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”import” type＝”import” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”portInstances” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portInstance” type＝”portInstance” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”wireInstances” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”wireInstance” type＝”wireInstance” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”componentInstances” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”componentInstance” type＝”componentInstance” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”compoundComponentInstance” type＝”compoundComponentInstance” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:complexType name＝”import”＞
＜xs:attribute name＝”alias” type＝”xs:string” use＝”required” /＞
＜xs:attributeGroup ref＝”identity” /＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ インスタンススキーマ ＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:complexType name＝”instanceBase”＞
＜xs:sequence＞
＜xs:element name＝”classSettings” type＝”settings:settingValues” minOccurs＝”0” /＞
＜xs:element name＝”typeSettings” type＝”settings:settingValues” minOccurs＝”0” /＞
＜!-- クラスの値を設定 --＞
＜!-- タイプの値を設定 --＞
＜/xs:sequence＞
＜xs:attribute name＝”id” type＝”guid” use＝”required” /＞
＜xs:attribute name＝”parent” type＝”guid” use＝”optional” /＞
＜xs:attribute name＝”host” type＝”guid” use＝”optional” /＞
＜xs:attribute name＝”member” type＝”xs:string” use＝”optional” /＞
＜xs:attribute name＝”type” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”optional” /＞
＜!-- ランタイムにスコープする固有の識別子. これはSDMランタイムによって生成され、不変とすることができる --＞
＜!-- このインスタンスの親 --＞
＜!-- このインスタンスのホスト --＞
＜!-- 親タイプ上のメンバの名前 --＞
＜!-- これはそのインスタンスである完全修飾されたタイプ --＞
＜!-- インスタンスが作成されると充てんできるIDのエイリアス
この名前は同じメンバのすべてのインスタンスに対して固有でなければならない --＞
＜/xs:complexType＞
＜xs:complexType name＝”componentInstance”＞
＜xs:complexContent＞
＜xs:extension base＝”instanceBase”＞
＜xs:sequence＞
＜xs:element name＝”portInstances”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portInstance” type＝”instanceRef” /＞
＜!-- 所有しているポートインスタンス --＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜xs:complexType name＝”compoundComponentInstance”＞
＜xs:complexContent＞
＜xs:extension base＝”instanceBase”＞
＜xs:sequence＞
＜xs:element name＝”portInstances”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portInstance” type＝”instanceRef” /＞
＜!-- 委任しているポートインスタンス --＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”componentInstances”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”componentInstance” type＝”instanceRef” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”wireInstances”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”wireInstance” type＝”instanceRef” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜xs:complexType name＝”portInstance”＞
＜xs:complexContent＞
＜xs:extension base＝”instanceBase”＞
＜xs:sequence /＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜xs:complexType name＝”wireInstance”＞
＜xs:complexContent＞
＜xs:extension base＝”instanceBase”＞
＜xs:sequence＞
＜xs:element name＝”portInstances”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portInstance” type＝”instanceRef” /＞
＜!-- アタッチしたポート --＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜xs:complexType name＝”instanceRef”＞
＜xs:attribute name＝”uniqueId” type＝”xs:string” /＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ シンプルタイプ ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:simpleType name＝”fourPartVersionType”＞
＜xs:annotation＞
＜xs:documentation＞Four part version numbers where the segments are in the range 0-65535 ＜/xs:documentation＞
＜/xs:annotation＞
＜xs:restriction base＝”xs:string”＞
＜xs:pattern value＝”(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？).(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？).(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？).(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？)” /＞
＜/xs:restriction＞
＜/xs:simpleType＞
＜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＞
＜xs:attributeGroup name＝”identity”＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”version” type＝”fourPartVersionType” use＝”required” /＞
＜xs:attribute name＝”publicKeyToken” type＝”publicKeyTokenType” use＝”optional” /＞
＜/xs:attributeGroup＞
＜xs:simpleType name＝”guid”＞
＜xs:restriction base＝”xs:string”＞
＜xs:pattern value＝”[0-9a-fA-F]｛8｝-[0-9a-fA-F]｛4｝-[0-9a-fA-F]｛4｝-[0-9a-fA-F]｛4｝-[0-9a-fA-F]｛12｝” /＞
＜/xs:restriction＞
＜/xs:simpleType＞
＜/xs:schema＞
【０２１５】
以下は、マッピングの例示的な構造である。
＜？xml version＝”1.0” encoding＝”utf-8” ？＞
＜xs:schema targetNamespace＝”urn:schemas-microsoft-com:sdmMapping” xmlns:xs＝”http://www.w3.org/2001/XMLSchema” xmlns:names＝”urn:schemas-microsoft-com:sdmNames” xmlns＝”urn:schemas-microsoft-com:sdmMapping” elementFormDefault＝”qualified” version＝”0.7” id＝”sdmMapping”＞
＜!-- レビュー事項 [BassamT]: 同じ複合コンポーネント内でコンポーネントへのマッピングを許可するか？ --＞
＜xs:import namespace＝”urn:schemas-microsoft-com:sdmNames” schemaLocation＝”SDM7Names.xsd” /＞
＜xs:element name＝”logicalPlacement”＞
＜xs:annotation＞
＜xs:documentation＞
This file contains the mapping information between SDM members.
Mappings are constructed in a outside in fashion, first binding the outer compound component, then its members and so on.
＜/xs:documentation＞
＜/xs:annotation＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”import” type＝”names:import” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”placement” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”memberBinding” type＝”memberBinding” maxOccurs＝”unbounded” /＞
＜xs:element name＝”wireBinding” type＝”wireBinding” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜xs:attribute name＝”sourceComponentType” type＝”xs:string” /＞
＜xs:attribute name＝”targetComponentType” type＝”xs:string” /＞
＜xs:attribute name＝”name” type＝”xs:string” /＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜!-- メンババインディングには、次の場合がある:
1. 複合コンポーネントメンバ − このケースでは、複合コンポーネントのすべてのメンバとワイヤをバインドする
2. シンプルコンポーネントメンバ − このケースでは、このコンポーネントとそのポートをバインドする
3. ポートメンバ − このケースでは、ポートにバインドし、さらなるバインディングはない
--＞
＜xs:complexType name＝”memberBinding”＞
＜xs:sequence＞
＜xs:element name＝”memberBinding” type＝”memberBinding” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”wireBinding” type＝”wireBinding” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜xs:attribute name＝”sourceMember” type＝”xs:string” use＝”required” /＞
＜!-- ターゲットメンバが提供されなければ、このコンポーネントは複合コンポーネントのはずであり、そのメンバはその親がバインドされている複合コンポーネントのメンバにバインドされることになる
ターゲットメンバが提供されれば、複合コンポーネントをバインドし、ソース複合コンポーネント上のポートはこのターゲットコンポーネント上のポートにバインドされ得るはずである --＞
＜xs:attribute name＝”targetMember” type＝”xs:string” use＝”optional” /＞
＜/xs:complexType＞
＜!-- ワイヤはターゲット複合コンポーネントのパスにバインドされる 
このパスはポート、ワイヤ、およびコンポーネントインスタンスからなる--＞
＜xs:complexType name＝”wireBinding”＞
＜xs:sequence＞
＜xs:element name＝”path”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”element” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:attribute name＝”name” type＝”xs:string” /＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜xs:attribute name＝”sourceWire” type＝”xs:string” /＞
＜/xs:complexType＞
＜!-- インポート --＞
＜/xs:schema＞
【０２１６】
以下は、名前の例示的な構造である。
＜？xml version＝”1.0” encoding＝”UTF-8” ？＞
＜xs:schema targetNamespace＝”urn:schemas-microsoft-com:sdmNames” xmlns:xs＝”http://www.w3.org/2001/XMLSchema” xmlns＝”urn:schemas-microsoft-com:sdmNames” elementFormDefault＝”qualified” version＝”0.7” id＝”sdmNames”＞
＜xs:import namespace＝”http://www.w3.org/2001/XMLSchema” /＞
＜!-- インポートは別のSDMファイルへのエイリアスを作成する --＞
＜xs:complexType name＝”import”＞
＜xs:attribute name＝”alias” type＝”xs:NCName” use＝”required” /＞
＜xs:attribute name＝”location” type＝”xs:NCName” use＝”optional” /＞
＜xs:attributeGroup ref＝”Identity” /＞
＜/xs:complexType＞
＜!-- クラスおよびタイプファイルは、名前、バージョンおよび公開キーで識別される --＞
＜xs:attributeGroup name＝”Identity”＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”version” type＝”fourPartVersionType” use＝”required” /＞
＜xs:attribute name＝”publicKeyToken” type＝”publicKeyTokenType” use＝”optional” /＞
＜/xs:attributeGroup＞
＜xs:attributeGroup name＝”namespaceIdentity”＞
＜xs:attributeGroup ref＝”Identity” /＞
＜xs:attribute name＝”signature” type＝”xs:string” use＝”optional” /＞
＜xs:attribute name＝”publicKey” type＝”xs:string” use＝”optional” /＞
＜/xs:attributeGroup＞
＜!-- シンプルバージョン番号 --＞
＜xs:simpleType name＝”fourPartVersionType”＞
＜xs:annotation＞
＜xs:documentation＞Four part version numbers where the segments are in the range 0-65535 ＜/xs:documentation＞
＜/xs:annotation＞
＜xs:restriction base＝”xs:string”＞
＜xs:pattern value＝”(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？).(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？).(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？).(0|[1-5][0-9]｛0,4｝|[7-9][0-9]｛0,3｝|6[0-4][0-9]｛0,3｝|6[6-9][0-9]｛0,2｝|65|65[0-4][0-9]｛0,2｝|65[6-9][0-9]？|655|655[0-2][0-9]？|655[4-9]|6553[0-5]？)” /＞
＜/xs:restriction＞
＜/xs:simpleType＞
＜!-- 署名付き文書を検証するための公開キー --＞
＜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＞
＜/xs:schema＞
【０２１７】
以下は、設定の例示的な構造である。
＜？xml version＝”1.0” encoding＝”utf-8” ？＞
＜xs:schema targetNamespace＝”urn:schemas-microsoft-com:sdmSettings” xmlns:xs＝”http://www.w3.org/2001/XMLSchema” xmlns＝”urn:schemas-microsoft-com:sdmSettings” elementFormDefault＝”qualified” version＝”0.7” id＝”sdmSettings”＞
＜xs:import namespace＝”http://www.w3.org/2001/XMLSchema” /＞
＜!-- スキーマ、値および制約を設定 --＞
＜xs:complexType name＝”openSchema”＞
＜xs:sequence＞
＜xs:any namespace＝”##other” processContents＝”lax” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:complexType name＝”settingSchema”＞
＜xs:sequence＞
＜xs:any namespace＝”http://www.w3.org/2001/XMLSchema” processContents＝”skip” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:complexType name＝”settingValues”＞
＜xs:sequence＞
＜xs:any namespace＝”##other” processContents＝”lax” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜!-- 制約 --＞
＜xs:attributeGroup name＝”testAttributes”＞
＜xs:attribute name＝”path” type＝”xs:string” /＞
＜xs:attribute name＝”ifNullPath” type＝”ifNullPath” /＞
＜xs:attribute name＝”error” type＝”xs:int” /＞
＜xs:attribute name＝”errorDesc” type＝”xs:string” /＞
＜/xs:attributeGroup＞
＜xs:complexType name＝”simpleTest”＞
＜xs:attributeGroup ref＝”testAttributes” /＞
＜/xs:complexType＞
＜xs:complexType name＝”settingConstraints”＞
＜xs:sequence＞
＜xs:element name＝”mustExist” type＝”simpleTest” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”mustNotExist” type＝”simpleTest” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”ifExists” type＝”nestedTest” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”ifNotExists” type＝”nestedTest” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:complexType name＝”nestedTest”＞
＜xs:sequence＞
＜xs:element name＝”mustExist” type＝”simpleTest” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”mustNotExist” type＝”simpleTest” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”ifExists” type＝”nestedTest” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”ifNotExists” type＝”nestedTest” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜xs:attributeGroup ref＝”testAttributes” /＞
＜/xs:complexType＞
＜xs:complexType name＝”deploymentSchema”＞
＜xs:sequence＞
＜xs:any namespace＝”##other” processContents＝”lax” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:complexType name＝”deploymentValues”＞
＜xs:sequence＞
＜xs:any namespace＝”##other” processContents＝”lax” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ シンプルタイプ ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:simpleType name＝”ifNullPath”＞
＜xs:restriction base＝”xs:string”＞
＜xs:enumeration value＝”skip” /＞
＜xs:enumeration value＝”override” /＞
＜xs:enumeration value＝”returnError” /＞
＜/xs:restriction＞
＜/xs:simpleType＞
＜/xs:schema＞
【０２１８】
以下は、タイプの例示的な構造である。
＜？xml version＝”1.0” encoding＝”utf-8” ？＞
＜xs:schema targetNamespace＝”urn:schemas-microsoft-com:sdmTypes” xmlns:xs＝”http://www.w3.org/2001/XMLSchema” xmlns＝”urn:schemas-microsoft-com:sdmTypes” xmlns:names＝”urn:schemas-microsoft-com:sdmNames” xmlns:settings＝”urn:schemas-microsoft-com:sdmSettings” elementFormDefault＝”qualified” version＝”0.7” id＝”sdmTypes”＞
＜xs:import namespace＝”http://www.w3.org/2001/XMLSchema” /＞
＜xs:import namespace＝”urn:schemas-microsoft-com:sdmSettings” schemaLocation＝”SDM7Settings.xsd” /＞
＜xs:import namespace＝”urn:schemas-microsoft-com:sdmNames” schemaLocation＝”SDM7Names.xsd” /＞
＜!-- やるべきこと [BassamT]: ワイヤクラス、ワイヤタイプおよびワイヤメンバに関するポートクラス参照、ポートタイプ参照およびポートメンバを正規化 --＞
＜!-- やるべきこと [BassamT]: 検証のためキーおよびキー参照を追加 --＞
＜!-- やるべきこと [BassamT]: インラインタイプのサポートを追加 --＞
＜!-- やるべきこと [BassamT]: minOccursおよびmaxOccursをスクラブ  --＞
＜!-- やるべきこと [BassamT]: 「クラス」の新しい名前、たぶん「deployment」 --＞
＜!-- やるべきこと [BassamT]: 「ホスト」の新しい名前、たぶん「provider」 --＞
＜!-- レビュー事項 [BassamT]: このXSDでポート、コンポーネントおよびワイヤクラスの定義をマージできるか？ 構文分析をすれば、くどくならなくなるだろう --＞
＜!-- 検討事項 [BassamT]: シングルトン、コロケーション、インラインのようなものの一般属性メカニズム --＞
＜!-- やるべきこと [BassamT]: バインディング: メンバからコンポーネントメンバ --＞
＜!-- やるべきこと [geoffo]: ポート  これらはシングルトン？ --＞
＜!-- やるべきこと [geoffo]: 委任  どのようにポートを組み合わせるか？ --＞
＜!-- やるべきこと [geoffo] 適切な場所に＜any＞追加し戻す --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- SDMルートエレメント --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:element name＝”sdmTypes”＞
＜xs:annotation＞
＜xs:documentation＞SDM root element. It is a container for SDM types.＜/xs:documentation＞
＜/xs:annotation＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”import” type＝”names:import” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”information” type＝”information” minOccurs＝”0” /＞
＜xs:element name＝”portTypes” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”portType” type＝”portType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜xs:element name＝”componentTypes” minOccurs＝”0”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”componentType” type＝”componentType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜xs:element name＝”compoundComponentType” type＝”compoundComponentType” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜xs:attributeGroup ref＝”names:namespaceIdentity” /＞
＜/xs:complexType＞
＜/xs:element＞
＜!-- SDMタイプライブラリ情報 --＞
＜xs:complexType name＝”information”＞
＜xs:annotation＞
＜xs:documentation＞Human readable information about the SDM type library.＜/xs:documentation＞
＜/xs:annotation＞
＜xs:sequence＞
＜xs:element name＝”friendlyName” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”companyName” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”copyright” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”trademark” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”description” type＝”xs:string” minOccurs＝”0” /＞
＜xs:element name＝”comments” type＝”xs:string” minOccurs＝”0” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝_u61 ？＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- コンポーネント、ポート、およびワイヤタイプの基本complexType --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:complexType name＝”baseType”＞
＜xs:annotation＞
＜xs:documentation＞base type for Component Type and Port Type.＜/xs:documentation＞
＜/xs:annotation＞
＜xs:sequence＞
＜xs:element name＝”deployment” type＝”settings:deploymentValues” minOccurs＝”0” /＞
＜xs:element name＝”settings” type＝”settings:settingValues” minOccurs＝”0” /＞
＜xs:element name＝”settingSchema” type＝”settings:settingSchema” minOccurs＝”0” /＞
＜xs:element name＝”hostConstraints” type＝”hostConstraints” minOccurs＝”0” /＞
＜xs:element name＝”hostedClasses” type＝”hostedClassesList” minOccurs＝”0” /＞
＜!-- 展開セクションには、タイプの展開命令が入っている
この展開のスキーマは、「ユニット」上で指定される --＞
＜!-- このコンポーネントの設定.
これらはユニット上で指定されるスキーマに関する --＞
＜!-- スキーマを設定
タイプによって公開することができる新しい設定スキーマ
このスキーマの値は、このタイプのメンバに関して設定される
設定値をユニット上の設定にフローすることをサポートすることになることに注意 --＞
＜!-- このセクションには、このユニットをホストしているホストの設定に関するあらゆる制約が入っている
各ホストに１つ以上のホストがある場合があり、それぞれについて制約を供給することができることに注意 --＞
＜!-- このセクションには、ホストされたユニットのリストおよびクラスの設定に関するあらゆる制約が入っている
これらの制約は、クラスのスキーマに関して指定される
ここではホストされるクラスが１つ以上ある場合があることに注意 --＞
＜/xs:sequence＞
＜xs:attribute name＝”class” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- 制約 --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:complexType name＝”hostConstraints”＞
＜xs:annotation＞
＜xs:documentation＞Host constraints are constrains against the classes that can host this component or port type.＜/xs:documentation＞
＜/xs:annotation＞
＜xs:sequence＞
＜xs:element name＝”hostConstraint”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”constraints” type＝”settings:settingConstraints” /＞
＜/xs:sequence＞
＜xs:attribute name＝”host” type＝”xs:string” use＝”required” /＞
＜!-- ホストであるコンポーネントユニットの名前 
エイリアスを含むことがある、例えば、 ”otherSDM:myPortType” --＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:complexType name＝”hostedClassesList”＞
＜xs:annotation＞
＜xs:documentation＞These are constraint against the classes that this type can host＜/xs:documentation＞
＜/xs:annotation＞
＜xs:sequence＞
＜xs:element name＝”hostedClass” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”constraints” type＝”settings:settingConstraints” /＞
＜/xs:sequence＞
＜xs:attribute name＝”class” type＝”xs:string” use＝”required” /＞
＜!-- ホストしているコンポーネントクラスの名前 
エイリアスを含むことがある、例えば、 ”otherSDM:myPortType” --＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- ポート --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:complexType name＝”portType”＞
＜xs:complexContent＞
＜xs:extension base＝”baseType”＞
＜xs:sequence＞
＜xs:element name＝”portConstraints” type＝”portConstraints” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜xs:complexType name＝”portConstraints”＞
＜xs:annotation＞
＜xs:documentation＞These are constraint against the classes that this type can host＜/xs:documentation＞
＜/xs:annotation＞
＜xs:sequence＞
＜xs:element name＝”portConstraint”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”constraints” type＝”settings:settingConstraints” /＞
＜/xs:sequence＞
＜xs:attribute name＝”portClass” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”portType” type＝”xs:string” use＝”optional” /＞
＜xs:attribute name＝”minOccurs” type＝”xs:int” use＝”optional” /＞
＜xs:attribute name＝”maxOccurs” type＝”xs:int” use＝”optional” /＞
＜xs:attribute name＝”visible” type＝”xs:boolean” use＝”optional” /＞
＜!-- ポートタイプは、ここで、設定を通じて公開されていない振る舞いを持つポートタイプにバインドすることができる
このケースでは、設定は適切なポートを識別するには不十分であろう --＞
＜!-- アプリケーションがこの制約と一致するポートを知りたいかどうかを可視識別する 
アプリケーションは、エンドポイントの接続値を要求することなく、接続されているポートを制約することを選ぶだけの場合もある --＞
＜/xs:complexType＞
＜/xs:element＞
＜!-- たぶん、ここで、ポートがオプションのポートエンドポイントのセットを識別できるメカニズムが必要になる
すなわち、X、Y、またはZにバインドできるが、すくなくとも１つにバインドしなければならない --＞
＜/xs:sequence＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- コンポーネント --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:complexType name＝”componentType”＞
＜xs:complexContent＞
＜xs:extension base＝”baseType”＞
＜xs:sequence＞
＜xs:element name＝”ports” type＝”portsList” minOccurs＝”0” /＞
＜/xs:sequence＞
＜!-- 排他的属性は、このレイヤより下のタイプのインスタンスが他のタイプのインスタンスをホストできるかどうかを示す 
- 浅い（shallow）とは、インスタンスによってホストされるインスタンスのみがこのタイプのインスタンスであることを意味する
- 深い（deep）とは、ホストも排他的とマーク付けされなければならないことを意味する --＞
＜xs:attribute name＝”exclusive” type＝”depth” use＝”optional” default＝”notSet” /＞
＜/xs:extension＞
＜/xs:complexContent＞
＜/xs:complexType＞
＜xs:complexType name＝”portsList”＞
＜xs:sequence＞
＜xs:element name＝”port” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”settings” type＝”settings:settingValues” minOccurs＝”0” /＞
＜!-- メンバ設定値
これらはタイプ上で指定された設定スキーマに関する --＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”type” type＝”xs:string” /＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- 複合コンポーネントタイプ --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜xs:complexType name＝”compoundComponentType”＞
＜xs:sequence＞
＜xs:element name＝”components” type＝”components” minOccurs＝”0” /＞
＜xs:element name＝”wires” type＝”wires” minOccurs＝”0” /＞
＜xs:element name＝”delegatePorts” type＝”delegatePorts” minOccurs＝”0” /＞
＜xs:element name＝”delegateHostedClasses” type＝”delegateHostedClasses” minOccurs＝”0” /＞
＜!-- 委任ポート --＞
＜!-- 委任ホスト. これにより、複合コンポーネントがちょうどシンプルコンポーネントのようにホストとして動作することができるようになる --＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜!-- 浅いコロケーションは、この複合コンポーネントのメンバのインスタンスがこのレイヤの下の同じホストインスタンス上に配置されることになることを意味する
深いコロケーションは、ホストもコロケートされることを意味する--＞
＜xs:attribute name＝”colocate” type＝”depth” use＝”optional” default＝”notSet” /＞
＜!-- オープン属性は、バインディングが複合コンポーネントの内部構造を見ることができるか、あるいはあたかもシンプルコンポーネントであるかのように複合コンポーネントに単純にバインドされるかどうかを示す --＞
＜xs:attribute name＝”open” type＝”xs:boolean” use＝”optional” default＝”false” /＞
＜!-- 排他的属性は、このレイヤより下のタイプのインスタンスが他のタイプのインスタンスをホストできるかどうかを示す
- 浅いとは、このインスタンスによってホストされたインスタンスのみがこのタイプのインスタンスであることを意味する
- 深いとは、このホストも排他的とマーク付けされなければならないことを意味する --＞
＜xs:attribute name＝”exclusive” type＝”depth” use＝”optional” default＝”notSet” /＞
＜/xs:complexType＞
＜xs:complexType name＝”components”＞
＜xs:sequence＞
＜xs:element name＝”component” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”settings” type＝”settings:settingValues” minOccurs＝”0” /＞
＜!-- メンバ設定値
これらはタイプ上で指定された設定スキーマに関する --＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”type” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”singleton” type＝”xs:boolean” use＝”optional” default＝”false” /＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:complexType name＝”wires”＞
＜xs:sequence＞
＜xs:element name＝”wire” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”members”＞
＜xs:complexType＞
＜xs:sequence＞
＜xs:element name＝”member” type＝”componentPortRef” minOccurs＝”0” maxOccurs＝”unbounded” /＞
＜/xs:sequence＞
＜/xs:complexType＞
＜/xs:element＞
＜!-- メンバ設定値
これらはタイプ上で設定された設定スキーマに関する --＞
＜/xs:sequence＞
＜xs:attribute name＝”name” type＝”xs:string” use＝”required” /＞
＜xs:attribute name＝”protocol” type＝”xs:string” /＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:complexType name＝”delegatePorts”＞
＜xs:sequence＞
＜xs:element name＝”delegatePort” minOccurs＝”0” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:attribute name＝”name” type＝”xs:string” /＞
＜xs:attribute name＝”componentName” type＝”xs:string” /＞
＜xs:attribute name＝”portName” type＝”xs:string” use＝”optional” /＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜xs:complexType name＝”componentPortRef”＞
＜xs:attribute name＝”componentName” type＝”xs:string” /＞
＜xs:attribute name＝”portName” type＝”xs:string” use＝”required” /＞
＜/xs:complexType＞
＜xs:complexType name＝”delegateHostedClasses”＞
＜xs:sequence＞
＜xs:element name＝”hostedClassRef” maxOccurs＝”unbounded”＞
＜xs:complexType＞
＜xs:attribute name＝”componentName” type＝”xs:string” /＞
＜xs:attribute name＝”hostedClass” type＝”xs:string” use＝”required” /＞
＜/xs:complexType＞
＜/xs:element＞
＜/xs:sequence＞
＜/xs:complexType＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- シンプルタイプ --＞
＜!-- ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ --＞
＜!-- 深さは、設定が次のレイヤにのみ適用されるか（浅い）、あるいは次のレイヤに適用し、次のレイヤ上で設定されなければならないか（深い）を識別する --＞
＜xs:simpleType name＝”depth”＞
＜xs:restriction base＝”xs:string”＞
＜xs:enumeration value＝”notSet” /＞
＜xs:enumeration value＝”shallow” /＞
＜xs:enumeration value＝”deep” /＞
＜/xs:restriction＞
＜/xs:simpleType＞
＜/xs:schema＞
【０２１９】
ＳＤＭランタイム
ＳＤＭランタイム（または単にランタイム）は、ＳＤＭの実装をホストする。ＳＤＭランタイムは、ＳＤＭタイプ空間、メンバ空間、およびインスタンス空間を操作するための所定のＡＰＩを公開する可用性の高い分散型サービスである。このランタイムは、一貫性のある形ですべてのＳＤＭインスタンスを追跡する責を担う。ランタイムは、展開、バージョン管理、セキュリティ、および回復のための機構を提供する。図２７は、ＳＤＭランタイムの論理アーキテクチャを表している。
【０２２０】
ＳＤＭランタイムは、以下から成る。
●ＳＤＭランタイム−これは、ＳＤＭランタイムの実装である。ＳＤＭランタイムは、１つまたは複数の物理マシン上で稼動する分散された実装である。ランタイムは、ＳＤＭおよびインスタンスを操作するコールのセットであるＳＤＭ  ＡＰＩを通じて自らの機能を公開する。
●ＳＤＭストア−これは、ＳＤＭモデルおよびインスタンスのための耐久性のある記憶装置である。このストアは、可用性が高く、一貫性が不可欠である。このストアは、大惨事にも耐える。
●サービス展開ユニット−これは、ＳＤＵのための読み取り専用ストアである。ＳＤＭストアと同様に、サービス展開ユニットは、可用性が高く、大惨事にも耐える。
●コンポーネント実装ホスト−これは、ＳＤＭコンポーネントから参照されるＣＬＲコードをホストするためのフレームワークである。
【０２２１】
ＳＤＭランタイムは、通常、以下のクライアントクラスによって使用される。
●コンポーネントインスタンス−これは、ＳＤＭランタイムライブラリ（ＲＴＬ）を使用してランタイムと通信するコンポーネントインスタンスである。２つのタイプのコンポーネントインスタンスであるランタイムでホストされるコンポーネントインスタンスおよびランタイムでホストされないコンポーネントインスタンスを区別する。
●開発ツールおよび展開ツール−これらには、ＳＤＭコンパイラ、ＳＤＵインストールツール、ならびに他の開発ツールが含まれる。
●管理ツール−これは、ランタイム自体を管理し、運営するために使用される特権ツールである。
【０２２２】
クライアントは、ＳＤＭランタイムライブラリ（ＲＴＬ）を通じてランタイムと通信する。クライアントは、通常、以下を含む操作を行う。
●ＳＤＵをインストール／アンインストールすること：これは、ＳＤＭランタイムの実行インスタンスに新しいＳＤＵを追加および削除するプロセスである。
●ＳＤＭタイプおよびインスタンスを追加、削除、および変更すること。すなわち、クライアントは、新しいコンポーネントタイプ、ポートタイプ、およびワイヤタイプを作成することができる。
●インスタンスを作成および削除すること。すなわち、クライアントは、新しいコンポーネントインスタンス、ポートインスタンス、およびワイヤインスタンスを作成することができる。
●イベントのソースおよびシンクを行うこと。すなわち、タイプ空間および／またはインスタンス空間に変更が行われた場合、ランタイムは、影響を受けたクライアントにイベントを送ることになる。また、イベントは、ポートバインド化情報を設定するなどの特定の操作時にトリガされることもできる。
●タイプ空間およびインスタンス空間の照会。すなわち、クライアントは、タイプ空間およびインスタンス空間を反映することができる。
【０２２３】
（サービス定義モデルランタイムアーキテクチャ）
（序論）
本明細書は、サービス定義モデル（ＳＤＭ）およびＳＤＭランタイムを説明する。ランタイムアーキテクチャ、コア機能、および実装の技術的論考を提供する。対象とする読者は、ＢＩＧの技術評価者、サービスおよびコンポーネントを作成しようとしている開発者、またはこのシステムの詳細に関心を有するその他の人々である。
【０２２４】
サービス時代
ここ十年の間に、インターネットがコンピューティングプラットフォームとして現れるのを目の当たりにした。ますます多くのソフトウェア会社が、「サービスとしてのソフトウェア」モデルを取り入れている。サービスは、通常、サーバ、ネットワーキング機器、およびその他の特殊化されたハードウェアを含む多くのマシン上で稼動するいくつかのコンポーネントから成る。緩やかに結合された、非同期プログラミングモデルが標準になりつつある。スケーラビリティ、可用性、および信頼性が、そのような分散サービスの成功には不可欠である。
【０２２５】
また、ハードウェアの動向の変化も目の当たりにしている。高密度サーバおよび特化したネットワークハードウェアが、データセンタにおいて普及している。スイッチファブリックが、システムバスに取って代わり、システム構成においてより高い柔軟性を提供している。ハードウェアコストは、総所有コスト（ＴＣＯ）算定基準において小さな役割しか演じていない。このコストは、専用のオペレーションスタッフを維持するコストが取って代わっられている。磐石なオペレーション上の実践は稀であるが、いずれのサービスにも絶対に不可欠である。それらの実践は、大部分、人々によって実施されている。
【０２２６】
実質上、開発の焦点は、単一のＰＣからＰＣのネットワークに移行している。しかし、すべてのこうした変化に伴って、サービス開発者、ソフトウェアベンダ、ハードウェアベンダ、およびエンドユーザにあまたの新たな問題が生じている。
◆サービスが大規模で、複雑である−サービスは開発するのに時間がかかり、維持管理するのが困難で高いコストがかかり、追加の機能により拡張することに危険が伴う。
◆サービスがモノリシックである−サービスはカスタムコンポーネントおよびカスタム構成に依拠している。サービスの部分を削除したり、独立してアップグレードしたり、または代替物で置き換えたりすることができない。
◆サービスが特定のハードウェア構成に依拠している−それが特定のネットワークトポロジであれ、特定のネットワーク機器に対する依存関係であれ。これにより、異なる環境においてサービスをホストする能力が大幅に低下する。
◆サービスが連携のない形で開発されている−共通のプラットフォームがないために、コードや最良のオペレーション上の実践さえも共有することが困難な作業である。
◆オペレーション上の悪夢−ほとんどのサービスは、機能するのにオペレーション担当のスタッフを必要とする。オペレーションスタッフは、各サービスの詳細において訓練されていなければならず、サービスが発展すると、再訓練されなければならない。
【０２２７】
以上の問題の一部は、ＤＯＳ時代（１９８０年代頃）の問題とあまり変わらない。ＤＯＳは、ディスク管理、ファイルシステム、コンソール機能などのアプリケーション開発者にとって価値あるコアサービスを定義した。しかし、ＤＯＳは、多くの複雑なタスクをＩＳＶに任せていた。例として、ＷｏｒｄＰｅｒｆｅｃｔとＬｏｔｕｓ１２３はともに、それぞれのアプリケーション内で印刷をサポートするために、プリンタドライバを独自に書かなければならなかった。同様に、プリンタハードウェアベンダは、製品を成功させるためにソフトウェア会社と取引きしなければならなかった。ＤＯＳアプリケーションを書くこと、およびハードウェアベンダにとっての参入障壁は、並外れて高かった。これにより、数社のソフトウェア会社だけが成功することになった。
【０２２８】
Ｗｉｎｄｏｗｓ（登録商標）は、プラットフォームを定義することによってこの問題に対処し、このプラットフォームによって参入の障壁が劇的に下げられた。Ｗｉｎｄｏｗｓ（登録商標）は、ＰＣプラットフォーム上のほとんどのハードウェアに関する抽象化レイヤを定義した。これにより、開発者は、特定のハードウェアデバイスをサポートすることに気を配らなければならないことから解放された。Ｗｉｎｄｏｗｓ（登録商標）は、メモリ、ディスク、およびネットワークを含むＰＣ内のすべてのリソースを管理した。また、Ｗｉｎｄｏｗｓ（登録商標）には、アプリケーション開発者によって利用することが可能な豊かなサービスも付いてきた。このプラットフォームにより、業界の莫大な成長が引き起こされた。Ｗｉｎｄｏｗｓ（登録商標）プラットフォームを対象としたソフトウェアベンダは、極めて生産的であった。Ｗｉｎｄｏｗｓ（登録商標）の商品化効果により、より安価なハードウェアとともに多くの新たなハードウェアベンダが登場した。
【０２２９】
サービス時代は、まだそのような成長を見せていない。つまり、デスクトップマシンに関して起きた革命が、サービスでも起きる必要がある。
【０２３０】
ＢＩＧサービスプラットフォーム
ＢＩＧは、可用性の高いスケーラブルなサービスのためのプラットフォームを創造する。このプラットフォームにより、以下のことが可能になる。
◆Ｖｉｓｕａｌ  Ｓｔｕｄｉｏ、ならびにＳＱＬ、ＩＩＳ等のような再使用可能なビルディングブロックを使用した分散型のスケーラブルで可用性の高いサービスの開発
◆自動的に割り振られ、目的化され、構成される１組の抽象化されたハードウェアリソースおよびソフトウェアリソースにわたる展開
◆オペレーション上の最良の実践の自動化を通じての所有コストの低減
◆商品経済をてことして利用する標準化されたデータセンタハードウェアの調達
ＢＩＧプラットフォームは、Ｗｉｎｄｏｗｓ（登録商標）プラットフォームの拡張であり、．ＮＥＴ、ＳＱＬサーバ、および他のマイクロソフトの資産などの既存の技術の上に構築される。ＢＩＧサービスプラットフォームは、以下のものを含め、多くの部分から構成される。
◆商品ハードウェアを集約して、ＢＩＧコンピュータと呼ばれる単一の大型コンピュータを構築するハードウェアリファレンスプラットフォーム。このプラットフォームは、多くの互いに接続されたサーバ、ネットワークデバイス、およびストレージを含む。
◆リソースを仮想化するハードウェア抽象化レイヤ。動的ハードウェアバインド化、再展開、および自動化されたネットワーク構成を可能にする。
◆開発者がサービス全体を記述するためのサービス定義モデル（ＳＤＭ）。開発者が、可用性の高いＳＱＬ、ＩＩＳ、および他の再使用可能なビルディングブロックコンポーネントを使用して新たなサービスを迅速に構築することが可能になる。
◆ＳＤＭをサポートする可用性の高いランタイム。ＢＩＧコンピュータ内で複数のスケーラブルなサービスをホストすることが可能になる。
◆オペレーション上の最良の実践を自動化するためのオペレーションロジックフレームワーク。ポリシーの表現および施行を可能にする。
【０２３１】
本明細書は、ＳＤＭおよびＳＤＭランタイムについてのみ中心に扱う。
【０２３２】
サービス定義モデル
このセクションでは、サービス定義モデル（ＳＤＭ）について説明する。ＳＤＭおよびＳＤＭ言語の完全な技術的説明については、「サービス定義モデル言語」のドキュメントを参照されたい。
【０２３３】
ＳＤＭは、すべてのサービスを構築する基盤である。ＳＤＭは、
◆より小さいユニットからサービスを組み立てることを可能にする。それらのユニットは、ハードウェア抽象化およびソフトウェア抽象化の基礎を成している。
◆サービスの活動中の青写真としての役立つ−ＳＤＭは、スケール不変の形でサービスの全体的な構造を取り込む。
◆オペレーション上の実践を自動化するためのフレームワークを提供し、その実践の再使用を促進する。
◆サービスの展開、再使用、発見、バージョン管理、および回復のための標準を定義する。
【０２３４】
サービスのためのコンポーネントモデル
基本的に、ＳＤＭは、サービスのためのコンポーネントモデルである。従来のコンポーネントモデルと同様に、ＳＤＭは、より複雑な機能を構築することができるプリミティブを定義する。喩えを考えてみる。マイクロソフトのコンポーネントオブジェクトモデル（ＣＯＭ）は、コンポーネントを作成するためのプログラミングモデルを定義した。ＣＯＭは、コンポーネントがどのようにパッケージ化され、登録され、アクティブ化され、発見されるか等に関して標準化した。ＣＯＭは、存続期間、メモリ管理、およびインターフェース実装に関連する厳密な規則を規定した。それらのプリミティブは、相互運用性に不可欠であった。すなわち、コンポーネントをブラックボックスとして扱えるようにした。ＣＯＭは、永続的ストレージ、イベンティング、自動化、およびＯＬＥなどのより高度なサービスのための基礎であった。
【０２３５】
ＳＤＭは、サービスのためのコンポーネントモデルを定義している。このモデルは、緩やかに結合された分散型の非同期サービスによく適している。ＳＤＭは、展開、バージョン管理、回復、およびスコーピング（ｓｃｏｐｉｎｇ）について標準を定義する。ＳＤＭは、ネットワーク管理、ハードウェア管理、ストレージ抽象化などのより高度なサービスが提供されるモデルである。ＳＤＭは、他のコンポーネントモデルと比べてどのようなものであるか？
確かに、とりわけ、ＤＣＯＭやＣＯＲＢＡなどの技術は、再使用可能なコンポーネントに基づくアプリケーション開発のために明確に定義された方法を有している。しかし、既存のコンポーネント技術は強力であるが、インターネットまたは緩やかに結合されたシナリオにおいて広く成功を収めていない。これは、主に以下に起因する。
◆既存のコンポーネント技術は、大規模向けに設計されていない−ほとんどの実装は、単独のマシン、または少数のマシンに最適化されている。インターネットアプリケーションには、通常、多くのマシン上で稼動する多くの相互に関連したコンポーネントがかかわっている。
◆既存のコンポーネント技術は、ＲＰＣなどの呼び出しプロトコルを指令する−既存のコンポーネント技術は、確立されたネットワークプロトコルを活用したり、異なるプロトコルを許容したりしていない。
◆既存のコンポーネント技術には、アプリケーションの概念が欠けている−ほとんどは、コンポーネントのうまく開発された定義を有しているが、より小さいコンポーネントから成るアプリケーションの全体的な定義を欠いている。
◆既存のコンポーネント技術は、汎用コンピュータ上で稼動するソフトウェアに限定されている−単一目的のネットワークデバイスは、コンポーネントとして参加することができない。
とはいうものの、サービスの世界にも十分に関連性がある既存のコンポーネント技術に盛り込まれた多くの考えがある。
【０２３６】
ＳＤＭの基盤
ＳＤＭは、サービスの構造の宣言的定義である。この定義は、以下のとおり、コンポーネント、ポート、およびワイヤに関する。
◆コンポーネントは、実装、展開、およびオペレーションの単位である。コンポーネントは、．ＮＥＴサーバが稼動している専用サーバ、共用マシン上のＩＩＳ仮想Ｗｅｂサイト、またはシスコのＬｏｃａｌＤｉｒｅｃｔｏｒなどのネットワーク機器とすることができる。コンポーネントは、ポートを通して機能を公開し、ワイヤを通して通信パスを確立する。コンポーネントは、外部のコンポーネント内でネストすることができ、複合コンポーネントと呼ばれる。
◆ポートは、関連するタイプを有する名前付きエンドポイントである。ポートタイプは、多くの場合、プロトコルを表わす。例えば、ＨＴＴＰサーバ。ポートは、通信を確立するために必要とされる情報を取り込む。
◆ワイヤは、ポート間の許容された通信パスである。ワイヤは、ポート間のトポロジ上の関係を宣言する。
【０２３７】
サービスは、宣言型のサービス定義モデル言語（ＳＤＭＬ）を使用して作成される。以下の例を検討する。
using System；
using System.Iis；
using System.Sql；
[sdmassembly：name(“MyService”)]；
[sdmassembly：version(1)]；
componenttype MyFrontEnd ： AspApplication
｛
port SqlClient catalog；
implementation ”MyFE, MyClrAssembly”；
｝
componenttype MyBackEnd ： SqlDatabase
｛
implementation ”MyBE, MyClrAssembly”；
｝
componenttype MyService
｛
component MyFrontEnd fe；
component MyBackEnd be；
port http ＝ fe.http；
wire SqlTds tds
｛
fe.catalog；
be.sqlServer；
｝
implementation ”MyService, MyClrAssembly”；
｝
【０２３８】
見て取ることができるとおり、ＳＤＭＬの構文は、Ｃ＃から大幅に取り入れている。ＳＤＭＬは、コンポーネントタイプ、ポートタイプ、およびワイヤタイプを定義する。この定義を一通り見ると、以下のとおりである。
◆ディレクティブ（ｄｉｒｅｃｔｉｖｅ）の使用は、ＳＤＭタイプの名前空間を参照する。ＳＤＭタイプの名前空間は、ＳＤＭランタイムによって提供され、ｈｔｔｐワイヤタイプなどの基本タイプを定義するシステム名前空間を含む。その他の名前空間は、ＩＩＳおよびＳＱＬサーバに関連するタイプを定義する。
◆アセンブリ名およびアセンブリバージョンは、ＳＤＭアセンブリの厳密名を提供する。これはＣＬＲアセンブリとは関係ないことに留意されたい。ＳＤＭアセンブリは、ＳＤＭ展開の最小単位である。ＡＤＭアセンブリには、名前が付けられ、コンポーネントタイプ、ポートタイプ、およびワイヤタイプの集合を収容する。ＳＤＭアセンブリをＣＬＲアセンブリと混同してはならない−これらは、完全に別ものである。
◆ＭｙＦｒｏｎｔＥｎｄと呼ばれるコンポーネントタイプが宣言される。これは、Ｓｙｓｔｅｍ．Ｉｉｓ  ＳＤＭアセンブリにて定義された被参照タイプであるコンポーネントタイプＡｓｐＡｐｐｌｉｃａｔｉｏｎから継承される。コンポーネントは抽象である。すなわち、コンポーネントはインスタンスではなっく、クラスを参照する。ＭｙＦｒｏｎｔＥｎｄは、ゼロまたはそれ以上のコンポーネントインスタンスを作成することができるコンポーネントを特定する。
◆ｐｏｒｔ  ＳｑｌＣｌｉｅｎｔ  ｃａｔａｌｏｇ。これは、タイプＳｑｌＣｌｉｅｎｔのＭｙＦｒｏｎｔＥｎｄコンポーネント上でポートを宣言する。このポートは、「ｃａｔａｌｏｇ」と呼ばれる。このポートは、ＭｙＦｒｏｎｔＥｎｄが基本コンポーネントタイプＡｓｐＡｐｐｌｉｃａｔｉｏｎから継承するポート、コンポーネント、およびワイヤに追加のものである。
◆実装キーワードは、コンポーネントタイプに関する実装を参照する。この実装は、ＣＬＲアセンブリ内のＣＬＲクラスに対する参照である。これは、このコンポーネントタイプに関するエントリポートまたはコンストラクタと考えることができる。コンポーネントインスタンスが作成されるときにこのコードが呼び出される。
◆ＭｙＳｅｒｖｉｃｅコンポーネントタイプは、ｆｅおよびｂｅと呼ばれる２つのサブコンポーネントにより定義される。これらは、タイプＭｙＦｒｏｎｔＥｎｄおよびＭｙＢａｃｋＥｎｄのものである。コンポーネントＭｙＳｅｒｖｉｃｅのインスタンスは、後に、コンポーネントインスタンスの階層を形成するｆｅおよびｂｅのインスタンスを有することができる。
◆ｐｏｒｔ  ｈｔｔｐ＝ｆｅ．ｈｔｔｐ。これは、ｆｅコンポーネント上のｈｔｔｐポートに委任されるＭｙＳｅｒｖｉｃｅコンポーネントタイプ上のポートを宣言する。
◆ｗｉｒｅ  ＳｑｌＴｄｓ  ｔｄｓは、名前ｔｄｓを有するタイプＳｑｌＴｄｓのＭｙＳｅｒｖｉｃｅコンポーネントタイプにてワイヤを宣言する。２つのポートがこのワイヤに取り付けられる。この宣言は、ＭｙＳｅｒｖｉｃｅのインスタンスが、ワイヤｔｄｓのゼロまたはそれ以上のインスタンスを有することができ、それらのワイヤインスタンスのそれぞれが、ｆｅコンポーネントからのｃａｔａｌｏｇポート、およびそれらに接続されたｂｅコンポーネントからのｓｑｌポートを有することができることを意味する。
【０２３９】
しばしば、サービスの図式表現を検討することが役立つ。図２８を参照されたい。ボックスはコンポーネントを表わし、菱形はポートを表わし、線はワイヤを表わしている。
【０２４０】
コンポーネント実装
あらゆるコンポーネントは、ＣＬＲアセンブリ内のＣＬＲクラスの形態の実装を参照することができる。ＣＬＲアセンブリは、ＳＤＭランタイムによってホストされ、コンポーネントインスタンス化時に呼び出されることになる。ＳＤＭコンポーネントを実装するＣＬＲクラスは、ＳＤＭランタイムＡＰＩをコールすることによってＳＤＭ操作を実行することができる。これについては本明細書で後により詳細に説明する。以下は、上記からのＭｙＳｅｒｖｉｃｅＳＤＭコンポーネントタイプの実装に関するＣ＃コードの断片である。
using System；
using Microsoft.SDM；
public class MyService: SDMComponentInstance
｛
public override OnCreate(・・・) 
｛
SDMComponent fe1 ＝ CreateComponentInstance(“fe”, “”)；
SDMComponent fe2 ＝ CreateComponentInstance(“fe”, “”)；
SDMComponent be1 ＝ CreateComponentInstance(“be”, “”)；
SDMWire tds1 ＝ CreateWire instanceance(“tds”)；
tds1.Members.Add(fe1.Ports[“catalog”])；
tds1.Members.Add(fe2.Ports[“catalog”])；
tds1.Members.Add(be1.Ports[“sqlServer”])；
｝
｝
【０２４１】
このコードは、ＳＤＭＣｏｍｐｏｎｅｎｔから継承するＣ＃クラスＭｙＳｅｒｖｉｃｅを定義する。このクラスは、ＯｎＣｒｅａｔｅ（）メソッドをオーバライドし、ｆｅコンポーネントの２つのインスタンスと、ｂｅコンポーネントの１つのインスタンスと、１つのワイヤインスタンスを作成する。次に、このクラスは、３つのポートをワイヤインスタンスに追加する。
【０２４２】
このＣＬＲコードは、ＭｙＳｅｒｖｉｃｅに関してＳＤＭ内で参照されるＭｙＣｌｒＡｓｓｅｍｂｌｙと呼ばれるアセンブリにコンパイルされる。タイプＭｙＳｅｒｖｉｃｅのコンポーネントがインスタンス化されるときにこのコードが呼び出され、ＯｎＣｒｅａｔｅメソッドがコールされる。
------------------------------------------------------------------------
[BassamT]  C#コードの強いタイプ（型）のバージョンを示すことを検討する。
------------------------------------------------------------------------
【０２４３】
インスタンス
ＳＤＭＬは、コンポーネントタイプ、ポートタイプ、およびワイヤタイプを定義するために使用され、インスタンスを定義しない。インスタンスは、前掲のＣ＃コードで見たとおり、ＳＤＭランタイムＡＰＩを使用して作成することができる。前掲のＣ＃コードは、いくつかのインスタンスを作成し、インスタンス空間において配線（ｗｉｒｉｎｇ）トポロジを形成した。これらのインスタンスは、ＳＤＭランタイムによって追跡されることになる。例えば、ＳＤＭランタイムは、前述のＯｎＣｒｅａｔｅコールが完了した後に、以下の情報を格納することになる。
component instance ms[1]
port instance http[1]
component instance fe[1]
component instance fe[2]
component instance be[1]
wire instance tds[1]
fe[1].catalog
fe[2].catalog
be[1].SqlServer；
注：ここで使用している構文は、ＳＤＭＬではなく、ＳＤＭランタイムによって追跡されるインスタンス空間を例示するために使用している。
【０２４４】
ｍｓ［１］は、３つの子コンポーネントインスタンスｆｅ［１］、ｆｅ［２］、およびｂｅ［１］を有するコンポーネントインスタンスである。ｆｅ［１］およびｆｅ［２］は、ｆｅコンポーネントのインスタンスである。ｂｅ［１］は、ｂｅコンポーネントのインスタンスである。ｔｄｓ［１］は、３つのメンバが入っているワイヤインスタンスである。図式的には、図２９に示されたインスタンス空間である。
【０２４５】
コンポーネントインスタンスは、実際の物理的な表明（ｍａｎｉｆｅｓｔａｔｉｏｎｓ）を有する−この例におけるｆｅ［１］およびｆｅ［２］は、Ｗｉｎｄｏｗｓ（登録商標）マシン上で稼動しているＩＩＳ上で実行されている２つのＡＳＰ．ＮＥＴアプリケーションである。ＣｒｅａｔｅＣｏｍｐｏｎｅｎｔＩｎｓｔａｎｃｅに対するコールが行われたとき、新たなＡＳＰ．ＮＥＴアプリケーションがＩＩＳボックス上に作成および構成された。いくつかの中間ステップを呼び出すことも可能であった−例えば、コール元のクレジットカードが新たなリソースを使用したことに対して課金されたり、または容量の不足のために新たなマシンが割り振られたりする。本明細書で後に、コンポーネントインスタンス化の背後の機構を検討する。
【０２４６】
サービス展開ユニット
ＭｙＳｅｒｖｉｃｅのＳＤＭモデルは、コンポーネント、ポート、およびワイヤに関してサービスの構造を定義した。これにより、ＳＤＭランタイムマシン上にインストールすることができるＳＤＭアセンブリがもたらされた。明らかに、ＳＤＭアセンブリは、サービスをインスタンス化するのに十分ではない。ＳＤＭアセンブリに加えて、コンポーネントの実装であるＣＬＲアセンブリについても考慮しなければならない。また、ＡＳＰ．ＮＥＴコード、ＳＱＬスクリプト、そしてサービスによって必要とされるそれ以外のものすべてについて考慮しなければならない。これらすべての部分の総和が、サービス展開ユニット（またはＳＤＵ）の中にパッケージ化される。図３０を参照されたい。
【０２４７】
ＳＤＭランタイム
ＳＤＭランタイム（または、単にランタイム）は、ＳＤＭの実装をホストする。ＳＤＭランタイムは、ＳＤＭタイプ空間、メンバ空間、およびインスタンス空間を操作するための所定のＡＰＩを公開する可用性の高い分散型サービスである。このランタイムは、一貫性のある形ですべてのＳＤＭインスタンスを追跡する責を担う。ランタイムは、展開、バージョン管理、セキュリティ、および回復のための機構を提供する。
【０２４８】
このセクションは、ＢＩＧ  Ｖ１．０リリースに関して提案されるＳＤＭランタイムの設計および実装を説明する。確かにＳＤＭランタイムの異なる実施形態が存在することがあるが、本明細書を通じて、一実施形態だけを中心に扱う−ＢＩＧコンピュータ上でホストされる可用性の高いＳＤＭランタイム実装である。
【０２４９】
ランタイムアーキテクチャ
図２７は、ＳＤＭランタイムの論理アーキテクチャを表している。
【０２５０】
ＳＤＭランタイムは、以下から成る。
◆ＳＤＭランタイム−これは、ＳＤＭランタイムの実装である。ＳＤＭランタイムは、１つまたは複数の物理マシン上で稼動する分散された実装である。ランタイムは、ＳＤＭおよびインスタンスを操作するコールのセットであるＳＤＭ  ＡＰＩを通じて自らの機能を公開する。
◆ＳＤＭストア−これはＳＤＭモデルおよびインスタンスのための耐久性のある記憶装置である。このストアは、可用性が高く、一貫性が不可欠である。このストアは、大惨事にも耐える。
◆サービス展開ユニット−これは、ＳＤＵのための読み取り専用ストアである。ＳＤＭストアと同様に、サービス展開ユニットは、可用性が高く、大惨事にも耐える。
◆コンポーネント実装ホスト−これは、ＳＤＭコンポーネントから参照されるＣＬＲコードをホストするためのフレームワークである。
【０２５１】
ＳＤＭランタイムは、通常、以下のクライアントクラスによって使用される。
◆コンポーネントインスタンス−これは、ＳＤＭランタイムライブラリ（ＲＴＬ）を使用してランタイムと通信するコンポーネントインスタンスである。２つのタイプのコンポーネントインスタンスであるランタイムでホストされるコンポーネントインスタンスおよびランタイムでホストされないコンポーネントインスタンスを区別する。
◆開発ツールおよび展開ツール−これらには、ＳＤＭコンパイラ、ＳＤＵインストールツール、ならびに他の開発ツールが含まれる。
◆管理ツール−これは、ランタイム自体を管理し、運営するために使用される特権ツールである。
【０２５２】
クライアントは、ＳＤＭランタイムライブラリ（ＲＴＬ）を通じてランタイムと通信する。クライアントは、通常、以下を含む操作を行う。
◆ＳＤＵをインストール／アンインストールすること：これは、ＳＤＭランタイムの実行インスタンスに新しいＳＤＵを追加および削除するプロセスである。
◆ＳＤＭタイプおよびインスタンスを追加、削除、および変更すること。すなわち、クライアントは、新しいコンポーネントタイプ、ポートタイプ、およびワイヤタイプを作成することができる。
◆インスタンスを作成および削除すること。すなわち、クライアントは、新しいコンポーネントインスタンス、ポートインスタンス、およびワイヤインスタンスを作成することができる。
◆イベントのソースおよびシンクを行うこと。すなわち、タイプ空間および／またはインスタンス空間に変更が行われた場合、ランタイムは、影響を受けたクライアントにイベントを送ることになる。また、イベントは、ポートバインド化情報を設定するなどの特定の操作時にトリガされることもできる。
◆タイプ空間およびインスタンス空間の照会。すなわち、クライアントは、タイプ空間およびインスタンス空間を反映することができる。
【０２５３】
タイプ空間、メンバ空間、およびインスタンス空間
コンポーネントタイプ、コンポーネント、およびコンポーネントインスタンスの間の関係は、最新のオブジェクト指向言語におけるクラス、クラスメンバ、およびオブジェクトに例えられる。ＳＤＭは、タイプ空間、メンバ空間、およびインスタンス空間の分離を定義する。コンポーネントタイプはタイプ空間にあり、コンポーネントはメンバ空間にあり、コンポーネントインスタンスはインスタンス空間にある。図３１は、この３つの空間の分離を示している。
【０２５４】
「メンバ空間」は、タイプ空間のインスタンスを収容する。「インスタンス空間」は、メンバ空間のインスタンスを収容する。ＳＤＭランタイムは、３つすべての空間、ならびに３つの空間の間の関係を追跡する責を担う。この情報は、ＳＤＭストア内部に格納され、ランタイムＡＰＩを使用することによって照会することができる。コンポーネントおよびワイヤは、ゼロまたはそれ以上のインスタンスを有することができる。ポートは、１つのインスタンスしか有することができない。
【０２５５】
ＳＤＭメンバ空間およびインスタンス空間は、厳密な階層に準拠する。メンバ空間およびインスタンス空間内のすべてのコンポーネントは、ツリー状に配置構成される。ルートコンポーネントは、「ルート」または「ユニバーサル」コンポーネントと呼ばれる特別なコンポーネントである。前のセクションのＭｙＳｅｒｖｉｃｅの例からメンバツリーを見てみる（図３２）。ボックスはコンポーネントを表わし、線は親／子関係である。ｍｙＳｅｒｖｉｃｅは、ルートコンポーネントのメンバコンポーネントである。このインスタンスツリーは、図３３に示したように見ることができる。異なる数の子インスタンスを有するｍｙＳｅｒｖｉｃｅコンポーネントの２つのインスタンスが存在することに注目されたい。ｍｙＳｅｒｖｉｃｅ［１］．ｆｅ［１］およびｍｙＳｅｒｖｉｃｅ［２］．ｆｅ［１］は、同じコンポーネントメンバ「ｆｅ」を有し、同じコンポーネントタイプ「ＭｙＦｒｏｎｔＥｎｄ」を有するが、それ以外では、完全に別個のコンポーネントインスタンスである。「ｒｏｏｔ［１］」が、ルートコンポーネントの唯一のインスタンスである。
【０２５６】
コンポーネントインスタンス化
ＳＤＭランタイムによって提供される基本的な操作の１つが、コンポーネントインスタンス化である。これは、コンポーネントインスタンスが存在するようになるプロセスである。インスタンス（またはオブジェクト）を作成するには、通常、そのインスタンスに関するひとかたまりのメモリを割り振り、初期化することを伴う従来のコンポーネントモデルとは異なり、ＳＤＭコンポーネントには、通常、異なるパーティによって実行される多くのステップを伴い、完了するまでに数時間、場合によっては数日かかることがある。例えば、タイプＡＳＰ．ＮＥＴアプリケーションのコンポーネントがインスタンス化されると、その結果は、ＩＩＳが稼動するマシン上の新たな仮想Ｗｅｂサイトとなり、続いて構成動作が行われる。ＩＩＳマシン上の容量に達し、ＡＳＰ．ＮＥＴアプリケーションをインスタンス化する前に、新たなマシンを割り振らなければならないシナリオを考えてみる。このプロセスには、数時間かかる可能性がある。というのは、このプロセスには、プールから新たなマシンを割り振り、場合によっては、料金請求が課され、ＩＩＳを含むオペレーティングシステムをインストールすることを伴うことになるためである。ＳＤＭランタイムは、コンポーネントをインスタンス化する２つの方法、１）ファクトリでインスタンス化されたコンポーネント、および２）ランタイムでインスタンス化されたコンポーネントをサポートする。これらの方法について以下に簡単に説明する。さらなる詳細については、「コンポーネントインスタンス化」仕様を参照されたい。
【０２５７】
ファクトリインスタンス化コンポーネント
コンポーネントファクトリ（または、単にファクトリ）は、１つまたは複数のコンポーネントタイプに関するインスタンスを作成する責を担うエンティティである。ファクトリはそれ自体コンポーネントであり、インスタンス化の目的のために１つまたは複数のポートを公開する。ファクトリについての１つの考え方は、リソースマネージャとしてである。ファクトリが管理しているリソースは、コンポーネントタイプである。ファクトリは、どのようにリソースをコンポーネントのインスタンスにマップするかを知っている。例えば、タイプ「ファイルストレージ」のコンポーネントを有しているものと想定する。このコンポーネントがインスタンス化されると、ＮＴＦＳディレクトリが作成され、適切なＡＣＬが用意されることになる。このコンポーネントに関するファクトリは、ストレージを割り振る目的でいくつかのＷｉｎｄｏｗｓ（登録商標）マシンを管理することが可能である。ファクトリは、ＮＴＦＳ共用を作成し、ＡＣＬ、クォータ（ｑｕｏｔａｓ）等を設定する責を担う。コンポーネントファクトリは、ＳＤＭランタイムにおいて重要な役割を果たす。コンポーネントファクトリは、通常、サービスに代行してリソースを管理しているので、信頼でき、可用性が高いものと期待されている。ＳＤＭランタイムによってサポートされるコンポーネントファクトリの数は、制限がないが、ＢＩＧ  Ｖ１．０は、少数の基本コンポーネントファクトリを有するものと見込まれる。その基本コンポーネントファクトリは、以下のとおりである。
◆ハードウェア−これは、ハードウェアのインスタンスを割り振り、そのインスタンスを管理する責を担う基本レベルファクトリである。例えば、これは、１ＧＢのメモリ、またはＮＡＳなどの記憶装置をサーバマシンに割り振ることができる。
◆ネットワーク−このファクトリは、ＶＬＡＮ、公開ＩＰアドレス、ＤＮＳ名等を担う。
◆ＰＣ−このファクトリは、マシンを割り振り、そのマシン上に完全なＯＳイメージを展開することができる。
◆ストレージ−このファクトリは、ストレージを管理し、割り振る責を担う。
◆ソフトウェアリソース−ＡＳＰ．ＮＥＴ、ＩＩＳ  Ｗｅｂサイト、ＳＱＬサーバデータベースなど
【０２５８】
インスタンス化プロセス
ファクトリは、ＳＤＭランタイムに登録して、自らが、どのコンポーネントタイプについてインスタンスを作成する責を担うかを指定しなければならない。高レベルでは、インスタンス化のプロセスは、以下のとおりである。すなわち、コール元が、所与のコンポーネントタイプに関するコンポーネントファクトリをＳＤＭランタイムに求める。
１．ＳＤＭランタイムは、適切なコンポーネントファクトリを見つけ出し、そのファクトリをコール元に戻す責を担う。
２．次に、コール元が、そのコンポーネントファクトリと直接通信し、１つまたは複数のインスタンスを作成するようにに求める。
【０２５９】
実行ファクトリテーブル
ＳＤＭランタイムは、コンポーネントタイプと、それらの適切なファクトリのテーブルを保持することになる。あらゆるコンポーネントインスタンスが、実行ファクトリテーブル（ｒｕｎｎｉｎｇ  ｆａｃｔｏｒｙ  ｔａｂｌｅ）を有する。実行ファクトリテーブルの構造は、以下のとおりである。
(ComponentTypeID, PortType) -＞ (PortInstance, [cookie])
【０２６０】
コンポーネントインスタンスは、自らのテーブルのエントリ、ならびに、自らの直接の子のテーブルのエントリを追加／削除することができる。デフォルトでは、新たな子コンポーネントインスタンスが作成されるときに、親の実行ファクトリテーブルが継承される。
【０２６１】
実行ファクトリテーブルは、異なるコンテキストにおいて同じコンポーネントタイプに対して異なるファクトリをサポートするために、あらゆるコンポーネントインスタンスについて追跡される。ファクトリは、通常、リソースの割り振りが行われるところなので、ホスト環境がリソース割り振りに関して異なるポリシーを指令することが可能である。例えば、Ｄｉｇｅｘなどのホストエンティティが、自らの顧客について異なる計画を有するシナリオを考えてみる。ゴールドの代金を支払った顧客が、専用のＩＩＳボックスを獲得し、シルバーの代金を支払った顧客が、共用のＩＩＳボックスを獲得することになる。顧客のサービスは、タイプ「ＡＳＰ．ＮＥＴアプリケーション」のコンポーネントを収容し、そのサービスが、専用のＩＩＳマシン上でホストされるか、または共用のＩＩＳマシン上でホストされるかについて認識していない。Ｄｉｇｅｘは、これを図３４に示ように実装することが可能である。
【０２６２】
Ｄｉｇｅｘは、２つのコンポーネントファクトリ、ゴールドファクトリおよびシルバーファクトリを有するコンポーネントである。ファクトリ自体が、コンポーネントである。また、Ｄｉｇｅｘは、「ゴールド」および「シルバー」と呼ばれる他のコンポーネントも定義する。この「ゴールド」コンポーネントは、ゴールドサービスの代金を支払ったすべてのサービスの親となる。
【０２６３】
Ｄｉｇｅｘは、インスタンス化されるときに、ファクトリのインスタンスを作成し、「ゴールド」コンポーネントおよび「シルバー」コンポーネントのインスタンスも作成することになる。ゴールド［１］は、独自の実行ファクトリテーブルを有することになる。Ｄｉｇｅｘは、適切なＳＤＭランタイムＡＰＩをコールすることによってこのテーブルにゴールドファクトリを登録することになる。新たな顧客のサービスがゴールド［１］の子としてインスタンス化されると、Ｄｉｇｅｘは、ゴールド［１］の実行ファクトリテーブルを継承することになる。これは、「ＡＳＰ．ＮＥＴアプリケーション」のコンポーネントインスタンスが作成されると、ゴールドファクトリがその要求を扱い、顧客のアカウントに適切に課金することになることを意味する。
【０２６４】
ファクトリ追跡
ＳＤＭランタイムは、各コンポーネントインスタンスを作成したファクトリを常に把握している。図３５を参照されたい。破線は、コンポーネントインスタンスとそのインスタンスを作成したファクトリの間の「作成者（ｃｒｅａｔｅｄ  ｂｙ）」関係を表わしている。前述したとおり、ファクトリはそれ自体、コンポーネントであり、それゆえファクトリを有していなければならない。無限再帰を終わらせるため、ランタイムは、以下に説明するとおり、「ランタイムでホストされるコンポーネント」のためのファクトリになる。また、ルートコンポーネントインスタンスは、特別であり、自ら自身のファクトリであることに留意されたい。
【０２６５】
ファクトリおよびトランザクション
ファクトリは、サービス開発者が複雑なロールバック（ｒｏｌｌｂａｃｋ）およびエラー処理ロジックに気を配らなくてはならないことから解放するためのトランザクションをサポートする。被トランザクションサブシステム（ｔｒａｎｓａｃｔｅｄ  ｓｕｂｓｙｓｔｅｍ）の上に構築されていないファクトリは、補正をサポートする必要があることになる。ファクトリは、また、分散トランザクションに加入する（ｅｎｌｉｓｔ  ｉｎ）ことをサポートしなければならない。
【０２６６】
ファクトリは、通常、インスタンス化に関連する多くの記帳（ｂｏｏｋｋｅｅｐｉｎｇ）情報を保持することになる。記帳情報は、適切な回復を保証するためにＳＤＭランタイムと整合性を保っていなければならない。これを容易にするため、ＳＤＭランタイムは、ファクトリを含むコンポーネントインスタンスに関する被トランザクションストレージ（ｔｒａｎｓａｃｔｅｄ  ｓｔｏｒａｇｅ）サービスを提供することになる。うまく作成されたファクトリは、このストアに自らのすべての記帳情報を格納することになる。
【０２６７】
ファクトリポート
ファクトリは、通常、コンポーネントインスタンス化のために使用することができる１つまたは複数のポートを公開する。ポートタイプは、ＳＤＭランタイムによって指令されないが、すべてのコンポーネントファクトリがＳＤＭ＿Ｆａｃｔｏｒｙポートをサポートすることを推奨する。ＳＤＭ＿Ｆａｃｔｏｒｙは、新たなコンポーネントインスタンスをインスタンス化するためにコールされるＳＯＡＰベースのポートである。このポートに関するＣ＃インターフェースは、以下のとおりである。
public interface ISDMFactory
｛
ComponentInstance Instantiate(
ComponentInstance parent, 
Component component, 
ComponentType componentType, 
object args)；
void Alloc(ComponentInstance allocInstance)； 
void Construct(ComponentInstance constructInstance)；
｝
【０２６８】
ＩＳＤＭＦａｃｔｏｒｙは、３つの受け渡し（ｐａｓｓ）インスタンス化プロセスをサポートする。
インスタンス化受け渡し：この受け渡しは、ＳＤＭランタイムを使用してすべてのコンポーネントインスタンスを再帰的に作成することになる。しかし、インスタンス化受け渡しは、割り振り、または構築を行わない。インスタンス化受け渡しは、単に必要とされる「スケルトン」コンポーネントを作成するだけである。
割り振り受け渡し：この受け渡し期間中、すべての該当するコンポーネントファクトリが、インスタンス化のために必要とされるリソースは何でも割り振る。
構築受け渡し：割り振りが成功した場合、構築受け渡しが開始することになる。これが、通常、最長の実行受け渡しである。ファクトリは、通常、構築受け渡し期間中すべての実際の作業を行うことになる。
【０２６９】
ファクトリは、確かに、インスタンス化に関して他のポートタイプをサポートすることができるが、ＳＤＭランタイムおよびランタイムＡＰＩは、ＳＤＭ＿Ｆａｃｔｏｒｙ実装と共にうまく機能する多くのヘルパ機能を有する。これらのＡＰＩにより、確かに、大多数の開発者にとって開発者としての経験が向上する。
【０２７０】
ランタイムでホストされるコンポーネントインスタンス
ファクトリの他に、ＳＤＭランタイムは、実装ＳＤＭＬキーワードを使用してＣＬＲアセンブリを参照するＳＤＭコンポーネントに関する実装もホストすることになる。参照されるＣＬＲアセンブリは、ＣＬＲクラスの完全修飾名であるリテラルストリングである。例えば、以下のとおりである。
componenttype A
｛
port pt x；
implementation “MyNamespace.MyClassName,MyClrAssemblyName”
｝
【０２７１】
あるいは、厳密な名前の付いたＣＬＲアセンブリについて、以下のように、国／地域別環境（ｃｕｌｔｕｒｅ）、バージョン、およびキーを指定することができる。
componenttype A
｛
port pt x；
implementation “MyNamespace.MyClassName, MyClrAssemblyName, culture＝neutral, version＝1.0.0.1234, PublicKeyToken＝9a33f27632997fcc”
｝
【０２７２】
そのようなコンポーネントについて、ＳＤＭランタイムは、ファクトリとして働き、それらのＣＬＲクラスをホストし、管理することになる。また、これにより、前述したファクトリの無限回帰を終わらせる。というのは、基本レベルファクトリが、ＳＤＭランタイムによってホストされるＣＬＲアセンブリとして実装されるからである。
【０２７３】
ＣＬＲアセンブリは、マイクロソフトのＩＩＳサーバを使用してホストされる。実装キーワードは、ＭａｒｓｈａｌＢｙＲｅｆＯｂｊｅｃｔから継承されなければならず、ＩＲｕｎｔｉｍｅＨｏｓｔｅｄＩｍｐｌｅｍｅｎｔａｔｉｏｎインターフェースおよびＩＳＤＭＦａｃｔｏｒｙインターフェースを実装しなければならないクラスを参照する。便宜上、基本クラスＳｄｍＣｏｍｐｏｎｅｎｔＩｎｓｔａｎｃｅが、それらのインターフェースに関するデフォルトの実装を提供する。以下は、前述のコンポーネントタイプＡに関するランタイムでホストされたＣＬＲ実装の例である。
public class A : SdmComponentInstance
｛
protected override void OnCreate(object args) 
｛
// 何かする
｝
｝
【０２７４】
ｃｌａｓｓ  Ａは、ＳｄｍＣｏｍｐｏｎｅｎｔＩｎｓｔａｎｃｅから継承され、それゆえ、ＳＤＭランタイムによってホストすることができるＣ＃クラスである。また、このクラスのＣＬＲアセンブリも、適切に働くために、ＳＤＵの￥ｂｉｎサブディレクトリに入れられなければならない。タイプＡのコンポーネントのインスタンスが作成されるとき、ランタイムは、利用可能なホストＩＩＳマシンを見つけ出し、そのマシン上でＣＬＲコードをインスタンス化する責を担う。ＣＬＲコードは、ＩＩＳによってホストされる．ＮＥＴリモート化（ｒｅｍｏｔｉｎｇ）アプリケーションとしてホストされる。ＳＤＵ内のすべてのＣＬＲアセンブリは、ＩＩＳプロセスを共有し、そのプロセス内でそれ自身のＡｐｐＤｏｍａｉｎを有することになる。
【０２７５】
ＣＬＲアセンブリがロードされると、ランタイムが、ＩＲｕｎｔｉｍｅＨｏｓｔｅｄＩｍｐｌｅｍｅｎｔａｔｉｏｎインターフェース上で明確に定義されたエントリポイントに対する．ＮＥＴリモート化コールを行う。この時点で、ＣＬＲクラスは、コンポーネントファクトリと等価であり、前のセクションで見たとおり、ＩＳＤＭＦａｃｔｏｒｙインターフェースが利用される。
【０２７６】
ポートおよびワイヤ
ポートおよびワイヤは、ＳＤＭランタイム内の通信のための基礎である。ポートおよびワイヤは、今日のサービス展開に共通ないくつかの問題を解決する。
【０２７７】
通信情報のハードコーディング−多くのサービスは、通常、それらのサーバ、またはＩＰアドレスをそれらのコード内にハードコーディングしている。例えば、フロントエンドサーバは、通常、ＳＱＬサーバマシン名、ならびにデータベース名、ログイン、およびパスワードなどの接続情報をハードコーディングすることになる。
【０２７８】
通信トポロジを定義すること−ほとんどのサービス展開は、通常、通信に関する境界を定義するための唯一のメカニズムとしてＤＭＺを使用している。他の制約は施行されず、例えば、フロントエンドサーバが他のフロントエンドサーバと通信する必要性が生じた場合、これは、どこにも取り込まれない。
【０２７９】
発見−サービスに追加された新たなコンポーネント、およびサービスから削除されたコンポーネントを見つけ出すことは、今日のサービスが直面する典型的な問題である。
【０２８０】
ＳＤＭは、ポートおよびワイヤを使用してこれらの問題を解決する。ポートは、コンポーネント上で公開されるタイプ付き（ｔｙｐｅｄ）エンティティである。ポートは、サービスアクセスポイントに類似している−それは、コンポーネントが明確に定義された機能を公開するところのものである。例えば、「ストレージ」コンポーネントは、ファイルシステム操作のために使用することができるタイプＳＭＢ．Ｓｅｒｖｅｒのポートを定義するであろう。ワイヤは、ポート間の許容されたバインド化を定義する。ワイヤは、通信パスを制約することができる通信トポロジを形成する。
【０２８１】
前述のＭｙＳｅｒｖｉｃｅ例を再び検討してみる。
componenttype MyService
｛ 
component MyFrontEnd fe；
component MyBackEnd be；
port http ＝ fe.http；
wire SqlTds tds
｛
fe.catalog；
be.sqlServer；
｝
implementation ”MyService, MyClrAssembly”；
｝
【０２８２】
ＭｙＳｅｒｖｉｃｅは、ｔｄｓと呼ばれる単一のワイヤを収容する。ワイヤは、ちょうどコンポーネントと同様に、インスタンスを有することができる。例えば、以下は、２つの異なるワイヤインスタンストポロジを有するＭｙＳｅｒｖｉｃｅの２つのコンポーネントインスタンスｍｓ［１］およびｍｓ［２］である。
component instance ms[1]
wire instance tds[1]
fe[1].catalog
fe[2].catalog
be[1].SqlServer；
component instance ms[2]
wire instance tds[1]
fe[1].catalog
be[1].SqlServer；
wire instance tds[2]
fe[2].catalog
be[1].SqlServer；
【０２８３】
ｍｓ［１］は、３つのポートインスタンスが入っている単一のワイヤインスタンスｔｄｓ［１］を有する。ｍｓ［２］は、それぞれ２つのポートインスタンスを有する２つのワイヤインスタンスｔｄｓ［１］およびｔｄｓ［２］を有する。第１のケースでは、ｆｅ［１］とｆｅ［２］が互いに見ることができる。第２のケースでは、ｆｅ［１］とｆｅ［２］は互いに見えないであろう。
【０２８４】
ワイヤインスタンスは、物理通信トポロジを形成する。ポートインスタンスは、ワイヤインスタンスのメンバである。これは、以下のことを行うことができる。
１）互いに照会または発見を行う−ランタイムＡＰＩは、同一のワイヤインスタンス上の他のポートインスタンスの照会および発見を行うための機能をサポートする。すべてのメンバは、同一のワイヤインスタンス内で可視である。さらに、ワイヤインスタンスの所有者は、いつでもメンバを紹介することができる。
２）イベントを受け取る−ワイヤのメンバは、メンバポートインスタンス上のＳＤＭ操作によってトリガされるイベントを受け取ることになる。さらなる詳細については、下記の「イベント」を参照されたい。
３）通信を制約する−ワイヤインスタンスは、コンポーネントインスタンス間で許容可能な通信パスを制約する。
【０２８５】
ポートバインド化情報
ポートは、コンポーネントによって公開されるタイプ付きエンティティである。ポートは、まさに１つのインスタンスしか有することができない。ポートインスタンスは、バインド化情報を担うことができ、この情報が、通常、コンポーネント間の通信チャネルを確立するのに必要とされるすべてである。例えば、前述の「ｂｅ［１］．ＳｑｌＳｅｒｖｅｒ」ポートインスタンスは、ＳＱＬバックエンドに接続するための以下のバインド化情報を有することがある。
“server＝mySQLServer；uid＝myLogin；pwd＝myPwd；”
このストリングは、ＡＤＯまたはＯＬＥＤＢに受け渡すことができ、ＴＤＳ接続をバックエンドのＳＱＬサーバに対して確立することができる。ＳＤＭランタイムは、通信パーティ間に割って入らない。ＳＤＭランタイムは、単に、通信を開始するために必要とされるあらゆる情報の保持者として働く。
【０２８６】
ポートの可視性およびワイヤインスタンス
コンポーネントインスタンス上のポートインスタンスは、同一のワイヤインスタンスに取り付けられている場合だけに、他のコンポーネントインスタンスに可視である。これは、サービスのための論理ネットワークトポロジを構築するのに非常に強力なメカニズムである。また、ＳＤＭランタイムは、物理仮想ネットワークを自動的に作成し、ワイヤインスタンス制約を実装するために必要に応じてパケットフィルタリングを使用するための手段もサポートする。さらなる情報に関しては、「ネットワーキングアーキテクチャ」ドキュメントを参照されたい。
【０２８７】
イベント
ＳＤＭランタイムは、ＳＤＭインスタンス空間上の操作の結果としていくつかの組み込み（ｉｎｔｒｉｎｉｓｉｃ）イベントをもたらす。例えば、コンポーネントインスタンスがポートインスタンスを作成するときにイベントがもたらされる。特定のイベントに応じて、デスティネーションは、ある所与のワイヤ上のポートインスタンスか、複合コンポーネントインスタンスである。
【０２８８】
すべてのイベントは、ランタイムポート上のコンポーネントインスタンスに送られる。ＳＤＭランタイムライブラリは、それらのイベントを捕らえて、言語特有のコールに翻訳する責を担う。例えば、ＣＬＲベースのＳＤＭランタイムライブラリにより、ＣＬＲイベントがもたらされることになる。
【０２８９】
コンポーネントインスタンスイベント
このイベントは、新たなコンポーネントインスタンスが作成されるとき、または既存のコンポーネントインスタンスが削除されるときにもたらされる。このイベントのデスティネーションは、常に、親の複合コンポーネントインスタンスである。このイベントは、直接の親コンポーネントインスタンスだけに送られる−このイベントは、インスタンスツリーの上には伝搬しない。前述の例から、コンポーネントインスタンス「ｕ［１］．ｆｏｏ［２］」が、メンバコンポーネント「ｃ」の新たなインスタンスを作成するようにランタイムに求めたものと想定する。図３６を参照されたい。
【０２９０】
コンポーネントインスタンス「ｕ［１］．ｆｏｏ［２］」のコードは、現在、マシン１上で稼動している。ＳＤＭ  ＲＴＬを使用して、このコードは、コンポーネント「ｃ」の新たなインスタンスを作成するようにランタイムに求める。ランタイムは、コール側コンポーネントインスタンスの識別情報を知っており、この操作を明確にし、範囲を決める（ｓｃｏｐｅ）ことができる。新たなコンポーネントインスタンスが作成され、イベントがもたらされ、コール側コンポーネントインスタンスに送り返される。インスタンスが破棄されるか、失敗すると、ランタイムは、適切なイベントを親コンポーネントインスタンスおよび適切なコンポーネントファクトリに送ることになる。
【０２９１】
ポートインスタンスイベント
コンポーネントインスタンスが、ポートインスタンスを作成するか、または既存のポートインスタンスを削除するとき、親コンポーネントインスタンスは、その変更について通知される。図３７を参照されたい。ポートインスタンスがワイヤインスタンスに取り付けられる場合、親コンポーネントインスタンスと同様に、そのワイヤインスタンスのすべてのメンバにもその変更が通知されることになる。これを次のセクションで説明する。
【０２９２】
ポート状態
あらゆるポートインスタンスは、以下の状態のいずれかにあることができる。
◆作成済み−これは、ポートが最初に作成されたときのポートの状態である。これにより、親コンポーネントインスタンスに送られるイベントがトリガされる。
◆取り付け済み−ポートは、ワイヤインスタンスに取り付けられたときこの状態に入る。これにより、親コンポーネントインスタンス、およびワイヤインスタンスのすべてのメンバに送られるイベントがトリガされる。
◆オンライン−ポートは、操作の準備ができたときこの状態に入る。これにより、親コンポーネントインスタンス、およびワイヤインスタンスのすべてのメンバに送られるイベントがトリガされる。
◆オフライン−ポートは、通常の操作を停止したいと望むときこの状態に入る。これにより、親コンポーネントインスタンス、およびワイヤインスタンスのすべてのメンバに送られるイベントがトリガされる。
◆取り付け解除−ポートは、ワイヤインスタンスから取り付け解除されたときこの状態に入る。これにより、親コンポーネントインスタンス、およびワイヤインスタンスのすべてのメンバに送られるイベントがトリガされる。
◆削除済み−ポートは、インスタンス空間から削除されるときこの状態になる。これにより、親コンポーネントインスタンスに送られるイベントがトリガされる。
【０２９３】
ワイヤインスタンスイベント
ワイヤインスタンスイベントは、ワイヤインスタンスが作成されるか、または削除されるときにもたらされる。このイベントのデスティネーションは、常に、そのワイヤを所有する親コンポーネントインスタンスである。図３８を参照されたい。
【０２９４】
ワイヤインスタンスはまた、そのメンバに対するポート参照を収容することができる。このワイヤメンバシップにより、あるメンバポートイベントのデスティネーションが決まる。前述の例を続ける。「ｆｏｏ［２］．ｃ［２］」が、以下のとおり、いくつかの新たなインスタンスを作成したものと想定する。
component instance universal[1]
component instance foo[2]
component instance c[2]
port instance y[1]
component instance b1[1]
port instance x[1]
component instance b2[1]
port instance x[1]
wire instance p[1]
b1[1].x[1]
b2[1].x[1]
【０２９５】
ワイヤインスタンス「ｐ［１］」は、２つのポートインスタンス「ｂ［１］．ｘ［１］」および「ｂ２［１］．ｘ［１］」に対する参照を収容していることに留意されたい。コンポーネントインスタンス「ｂ１［１］」および「ｂ２［１］」はそれぞれ、別個のマシン上で稼動するものと想定する。図３９は、「ｂ２［１］」がそのポート状態をオフラインに変更したときにもたらされるイベントを示している。
【０２９６】
「ｂ２［１］」は、マシン３上でホストされており、ランタイム上で「ポート状態設定」操作を呼び出すことに留意されたい。ランタイムは、その変更を記録し、３つのイベントを送る−１つのイベントをワイヤインスタンス所有者「ｕ［１］．ｆｏｏ［２］．ｃ［２］」へ、２つのイベントをワイヤポートインスタンスメンバ「ｂ１［１］．ｘ［１］」および「ｂ２［１］．ｘ［１］」へ送る。
【０２９７】
イベントデリバリおよびキュー
ランタイムは、イベントの順序どおりのデリバリを保証するが、ある所与のワイヤインスタンスのすべてのメンバ間で完全な仮想同期を保証することはない。言い換えれば、ＳＤＭランタイムにより、コンポーネントインスタンスがゆっくりと実行されているか、または停止している（ｄｅａｄ）場合でも、先に進むことが可能になる。
【０２９８】
ＳＤＭイベントは、各コンポーネントインスタンスに関してキューに置かれる。イベントをトリガした操作は、そのイベントがターゲットキューにうまくに置かれた場合、成功であったとみなされる。キューは、本質的に円環となっており、コンポーネントがひどく遅れているか、または停止している場合、循環させることができる。循環させることにより、新たな「循環」イベントが生成されることになる。このイベントは、コンポーネントインスタンス自体、ならびに親およびどの所有ファクトリにも送られる。
【０２９９】
ランタイムの区画化
多数のクライアントをサポートするために、ランタイムを区画化することができる。ＳＤＭインスタンス空間の厳密な階層のために、この問題はかなり扱いやすい。ＳＤＭランタイムは、特定の展開にわたって多くのマシン上でホストすることができる。各ＳＤＭランタイムインスタンスは、インスタンス空間の一部分を追跡する責を担う。コンポーネントインスタンスは、ＳＤＭランタイムライブラリを使用して適切なランタイムと通信する。図４０は、区画化されたランタイム、およびいくつかのクライアントを示している。
【０３００】
マシン１は、２つのコンポーネントインスタンス、およびＳＤＭランタイムライブラリを収容している。マシン２は、単一のコンポーネントインスタンス、およびランタイムライブラリを収容している。マシン３は、専用のＳＤＭランタイムをホストしている。マシン４は、ＳＤＭランタイム、およびコンポーネントインスタンスを有している。マシン３およびマシン４上の２つのＳＤＭランタイムは通信していることにも留意されたい。
【０３０１】
区画化
ランタイムは、ＳＤＭに本来備わっている自然の階層を活用して自らを区画化する。区画化する動作は、異なる実行中のランタイムインスタンスにわたってＳＤＭのタイプ空間およびインスタンス空間の部分を配分することにかかわる。区画化は、スケーラビリティには必要不可欠なことである。区画化は、タイプとインスタンスでは異なる形で行われる。
◆タイプ空間およびメンバ空間：ある所与のランタイムは、名前空間内で通常、編成される多くのタイプ定義を収容することができる。各ランタイムは、自らが追跡しているインスタンスによって定義されるタイプおよびメンバについてだけ知っているだけでよいことになる。これらは、複数のランタイム上に現れることができる。言い換えれば、タイプ空間およびメンバ空間において、オーバラップが許されている。
◆インスタンス空間：ある所与のランタイムは、インスタンス空間の一部分を追跡しているだけである。インスタンス空間は、複合コンポーネントインスタンス境界上で区画化される。インスタンス空間におけるオーバラップは、許容されていない。
【０３０２】
これは、以下の例によって最もよく説明される。以下のコンポーネントタイプ定義を検討する。
componenttype B ｛
port X x；
｝
componenttype C ｛
port Y y；
component B b1；
component B b2；
wire P p ｛ b1.x； b2.x； ｝
componenttype A ｛
port internal Z z；
component C c；
wire W w ｛ z； c.y｝
｝
componenttype universal u ｛
component A foo；
component A bar； 
｝
【０３０３】
この定義は、３つのコンポーネントタイプ、Ａ、Ｂ、およびＣを収容する。Ａは、ルートユニバーサルコンポーネントのメンバである。ＢおよびＣはＡのメンバである。図４１に示すとおり、メンバ空間を図形で表すと便利である。ボックスを使用して複合コンポーネントを表わす。他の複合コンポーネントではない複合コンポーネントメンバは、コンポーネントボックス内に記述されていることに留意されたい。この例では、ワイヤ「ｗ」が、複合コンポーネント「ｆｏｏ」および「ｂａｒ」のメンバであり、それゆえ、「ａ」ボックス内に表されている。
【０３０４】
インスタンス空間には、各コンポーネント、ポート、およびワイヤの多くのインスタンスが存在することができる。インスタンス階層は、図４２に示すように表わされる。この図では、ボックスは、コンポーネントインスタンスに関して追跡されたインスタンス状態を表わす−コンポーネントインスタンス実装コードではない。
【０３０５】
このＳＤＭモデルを３つのランタイム、ランタイム１、ランタイム２、およびランタイム３の区画化したいと想定する。図４３は、インスタンス空間を区画化する例である。この例では、ランタイム１は、「ｕｎｉｖｅｒａｓａｌ［１］」、「ｆｏｏ［１］」、「ｆｏｏ［２］」、および「ｂａｒ［１］」を追跡している。ランタイム２は、「ｆｏｏ［ｌ］．ｃ［１］」、「ｆｏｏ［１］．ｃ［２］」、および「ｆｏｏ［２］．ｃ［１］」を追跡している。ランタイム３は、「ｂａｒ［１］．ｃ［１］」を追跡している。さらに、ランタイムは、自らが追跡しているインスタンスに関するすべてのタイプについて知らなければならない。この例では、ランタイム３は、親「ｂａｒ」のために、コンポーネントタイプ「Ｃ」、「Ｂ」、および「Ａ」について知っていなければならない。ランタイム３は、ポートタイプ「Ｙ」およびワイヤ「Ｐ」についても知っていなければならない。
【０３０６】
また、異なるランタイムは、互いの関係も維持しなければならない。この関係は、ＳＤＭ階層によって指令される。先の例では、ランタイム１およびランタイム２は、「ｆｏｏ［１］．ｃ［１］」、「ｆｏｏ［１］．ｃ［２］」、および「ｆｏｏ［２］．ｃ［１］」の関係を管理するため、互いについて知っていなければならない。同様に、ランタイム１およびランタイム３は、「ｂａｒ［１］．ｃ［１］」を取り囲む作業を調整しなければならない。ランタイム２とランタイム３は、互いについて知らないことに留意されたい。
【０３０７】
区画化戦略
ランタイムは、自ら自らを区画化するのに十分な論理を収容することになる。特定の区画化戦略は、パフォーマンス、容量、およびＳＤＭ定義の制約に基づくことになる。この区画化は、動的であり、ＳＤＭモデルが成長するにつれて変化することになる。
【０３０８】
単一ルートランタイム
すべてが単一のルートコンポーネントインスタンスのインスタンスである複合コンポーネントインスタンスを追跡するランタイムは、単一ルートランタイムと呼ばれる。前述の例では、ランタイム１およびランタイム３が、単一ルートランタイムである。ランタイム１は、「ｕｎｉｖｅｒｓａｌ［１］」で開始するルートインスタンスツリーを有し、ランタイム３は、「ｂａｒ［１］．ｃ［１］」で開始するルートインスタンスツリーを有する。
【０３０９】
マルチルートランタイム
ルート複合コンポーネントインスタンスを有さない複合インスタンスを追跡するランタイムは、マルチルートランタイムと呼ばれる。前述の例では、ランタイム２が、マルチルートランタイムである。というのは、ランタイム２は、「ｆｏｏ［１］．ｃ［１］」、「ｆｏｏ［１］．ｃ［２］」、および「ｆｏｏ［２］．ｃ［１］」を追跡し、これらすべてがルートであるからである。
【０３１０】
サービスインストール
サービスはまず、インストールされてからでないと、所与のＳＤＭランタイム上でインスタンス化することができない。インストールプロセスには、以下のステップがかかわる。すなわち、
サービス展開ユニットをランタイム展開共用にコピーするステップ
ＳＤＭランタイムＡＰＩをコールしてインストールを開始するステップ
サービス展開ユニット
ＳＤＵは、サービス展開の単位である。ＳＤＵは、以下から構成される。すなわち、
ＳＤＭアセンブリ−これは、新たなサービスについてのタイプ情報である。ＳＤＭアセンブリは、そのサービスに関するすべてのコンポーネントタイプ、ワイヤタイプ、およびポートタイプを含む。このアセンブリは、サービスＳＤＭＬをコンパイルした結果である。
【０３１１】
ランタイムでホストされたコンポーネントインスタンスコード−ランタイムによってホストされ、ＳＤＭＬの実装キーワードによって参照されるどのＣＬＲコードも、ＳＤＵの中に含められなければならない。
【０３１２】
他のサービスバイナリ−構成ファイル、ＤＬＬ、ＧＩＦ、ＨＴＭＬ、ＳＱＬスクリプトなどの他のすべてのバイナリも展開ユニットの一部とみなされる。
【０３１３】
ＳＤＵは、不変である−ＳＤＵに対する変更は許されない。ＳＤＵは、インストールされると、変更することができない。もちろん、アップグレードし、古いバージョンを可能性として廃止させる新しいバージョンのＳＤＵをインストールすることはできる。
【０３１４】
ＳＤＵフォーマット
ＳＤＵは、ＳＤＵランタイムによって利用され、コンポーネントファクトリによっても利用される可能性があるバイナリのディレクトリである。このディレクトリは、ほとんど自由形式であるが、以下の構造が見込まれる。
￥sduroot
￥＜assembly name＞.＜version＞
￥＜assembly name＞.sdmassembly
￥bin
￥＜Runtime hosted CLR assembly_1＞.dll
￥＜Runtime hosted CLR assembly_2＞.dll
￥＜Runtime hosted CLR assembly_n＞.dll
￥＜other files and directories＞
ＳＤＵは、ＣＡＢファイルとしてパッケージ化されることになる。
【０３１５】
実装
ＳＤＭランタイムは、ＩＩＳ  Ｓｅｒｖｅｒ上で稼動している．ＮＥＴ  ＷｅｂＳｅｒｖｉｃｅとして実装される。ＳＤＭストアは、信頼できるＳＱＬサーバデータベースである。ＳＤＭランタイムＷｅｂサービスは、ステートレス（ｓｔａｔｅｌｅｓｓ）Ｗｅｂサービスである。言い換えれば、ＳＤＭランタイムサービスにおけるいずれの状態も一過性である。すべての持続する状態は、明確なトランザクション境界においてストアに書き込まれる。
【０３１６】
ＳＤＭランタイムサービスは、どの時点においても、また異なるマシン上においてさえシャットダウンし、再起動（ｒｅｓｔａｔｅ）することができる。サービスが同一のＳＤＭストアにてポイントされている場合、すべての作業が、ほとんど、またはまったく中断なく再開されることになる。
【０３１７】
ＳＤＭストア
ＳＤＭランタイムは、ＳＤＭおよびインスタンスのために耐久性のあるストアを利用する。このストアは、通常、ＳＤＭランタイムサービスと同じマシン上にコロケートされるが、もちろん、異なる形で展開することもできる。ＳＤＭストアは、すべてのＳＤＭモデル、およびそのインスタンスに関する情報が入っているＳＱＬサーバデータベースである。
【０３１８】
ＳＤＭストアのこの信頼性および可用性は、必須である。ＳＤＭに関する重要な設計目標の１つは、最後の既知の整合性のある状態でシステムをリスタートできることである。それゆえ、ＳＤＭは、高い信頼性が必要であり、致命的な災害のシナリオにも耐えなければならない。これは２つの方法で実装される。
【０３１９】
ＳＤＭストアは、複製され、冗長性のあるホットバックアップ（ｈｏｔ  ｂａｃｋｕｐ）が常に利用可能であることになる。これは、Ｙｕｋｏｎの冗長データベース技術を使用して実装される。
【０３２０】
ＳＤＭストアは、定期的にバックアップされ、情報がオフサイト（ｏｆｆ−ｓｉｔｅ）に格納されることになる。バックアップは、現在のモデル、インスタンス、およびＳＤＭストアに格納されたどのサービス状態の自己整合性のあるスナップショットとなる。
【０３２１】
サービスストレージ
ＳＤＭランタイムは、コンポーネントインスタンスレベルにおいてストレージの機能を提供することになる。あらゆるコンポーネントインスタンスが、ランタイムＡＰＩを使用してデータをＳＤＭストアに格納することができる。最低でも、このストアはＢＬＯＢストアであるが、半構造（ｓｅｍｉ―ｓｔｒｕｃｕｔｒｅ）ストレージも検討されている。
【０３２２】
ランタイムに格納されたサービス状態は、ＳＤＭランタイムと同等の信頼性および持続性があることが保証される。また、他のランタイム状態と整合性があることも保証される。もちろん、すべてのサービス状態がＳＤＭストアに格納されることを主張しているわけではなく、サービスが、その状態に対して十分な情報（ポインタとして）を格納することを見込んでいる。サービスは、回復し次第、そのデータに対するポインタを取り出し、必要なステップを行うことができる。下記の「回復」を参照されたい。
【０３２３】
（ＳＤＭランタイムセキュリティ）
シナリオの説明
ＳＤＭランタイムに関するセキュリティモデルを定義する次の２つの基本的なシナリオが存在する。すなわち、開発者テストランシナリオ、および運用者実動展開シナリオである。両方のシナリオに関する共通の要件は、以下のとおりである。
●ＳＤＭランタイムが実行されているコンピュータからターゲットサーバに接続する能力
●Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙドメインアカウントを使用するＷｉｎｄｏｗｓ（登録商標）認証
●ターゲットサーバリソースにアクセスして、インストール操作、更新操作、およびアンインストール操作を実行するための信頼できるサブシステムモデル
●Ｗｉｎｄｏｗｓ（登録商標）サービスとして実装され、信頼できるサービスアカウントととして実行されるＳＤＭランタイム
●Ｗｉｎｄｏｗｓ（登録商標）認証、ならびにＳＤＭのクラス情報、タイプ情報、およびインスタンス情報を追跡するデータベースの役割を使用するように構成されたデータベース（ＭＳＤＥ）
【０３２４】
開発者テストランシナリオ
開発者は、試験環境において１つまたは複数のサーバに分散アプリケーションを展開することができなくてはならない。ターゲットサーバは、独立型ワークグループの一部であるか、または同じＡｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙドメインにある。テストラン展開が開始されるコンピュータは、ターゲットサーバと同じワークグループ、または同じドメインになければならない。
１．開発者が、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏを使用してサービス展開ユニット（ＳＤＵ）パッケージを生成する。
２．生成されたＳＤＵが、ＳＤＭランタイムサービスが実行されているコンピュータ上の展開フォルダに入れられる。
３．開発者が、展開アクション（インストール、更新、アンインストール）を選択し、Ｗｉｎｄｏｗｓ（登録商標）認証証明書を求められる。
４．開発者が認証され、展開役割にマップされ、この展開役割により、認証されたユーザが要求された展開操作を行うよう許可されるかどうかが判定される。
５．開発者が、どのターゲットサーバ上でどのコンポーネントをインストールし、更新し、または削除するかを選択する。
６．ＳＤＭランタイムサービスが、次の２つの方法のどちらかで選択されたターゲットサーバに接続する。ＳＤＭランタイムサービスがＡｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙにて信頼できるサービスアカウントとして稼動している場合、ＳＤＭランタイムサービスは、ターゲットサーバ上のそのアカウントとして接続することになる。それ以外の場合、ＳＤＭランタイムサービスは、認証されたユーザとして接続することになり、これには、偽名の使用（ｉｍｐｅｒｓｏｎａｔｉｏｎ）が可能でなければ、ターゲットサーバにて追加の認証が必要とされる場合がある。
【０３２５】
運用者実動展開シナリオ
運用者は、データセンタ環境において１つまたは複数のサーバに分散アプリケーションを展開することができなければならない。ターゲットサーバは、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙドメインまたはフォレスト（ｆｏｒｅｓｔ）の一部でなければならない。テストラン展開が開始されるコンピュータは、ターゲットサーバと同じドメイン内、またはフォレスト内になければならない。
１．アプリケーションＳＤＵが、ＳＤＭランタイムサービスの実行されているコンピュータ上の展開フォルダに入れられる。
２．運用者が、展開アクション（インストール、更新、アンインストール）を選択し、ドメイン証明書を求められる。
３．運用者が認証され、展開役割にマップされ、この展開役割により、認証されたユーザが要求された展開操作を行うよう許可されているかどうかが判定される。
４．運用者が、どのターゲットサーバ上でどのコンポーネントをインストールし、更新し、または削除するかを選択する。
５．ＳＤＭランタイムサービスが、信頼できるサービスアカウントとして選択されたターゲットサーバに接続し、操作を行う。
【０３２６】
特徴の説明
振る舞い仕様
ＳＤＭランタイムは、すべてのＳＤＭクラス、ＳＤＭタイプ、およびＳＤＭインスタンスを追跡する責を担う。ＳＤＭランタイムは、分散アプリケーションを展開する目的で、ＳＤＭドキュメントに対して登録し、操作するための１組のＳＯＡＰインターフェースを公開する。
【０３２７】
ＳＤＭランタイムは、以下の主なコンポーネントから成る。
●関連ランタイムライブラリを有するＷｅｂサービス
●Ｗｉｎｄｏｗｓ（登録商標）サービス
●ＭＳＤＥ（またはＹｕｋｏｎ）などのデータベース
図４４は、ＳＤＭランタイムコンポーネント、展開ツール、およびターゲットサーバの間の関係を示している。図４４では、ユーザは、展開動作を開始するために展開ツールＵＩ、またはコマンドラインインターフェースとやりとりする。
【０３２８】
ランタイムライブラリは、Ｗｅｂサービスによって公開される１組のＳＯＡＰインターフェースを提供する。Ｗｅｂサービスは、展開動作を行うためにＷｉｎｄｏｗｓ（登録商標）サービスが取り出す情報をデータベースに書き込む。Ｗｅｂサービスは、Ｗｉｎｄｏｗｓ（登録商標）認証を使用してＳＤＭランタイムデータベースに対してユーザを認証し、データベースにて定義された役割に基づいて展開動作を許可する。
【０３２９】
実動環境において、Ｗｉｎｄｏｗｓ（登録商標）サービスが、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙサービスアカウントとして実行され、ターゲットサーバが、管理目的でドメインサービスアカウントを信頼するように構成されることになる。Ｗｉｎｄｏｗｓ（登録商標）サービスは、ＷＭＩを使用して、サービスアカウント（ユーザではなく）の偽名を使用してターゲットサーバに遠隔操作を行う。この信頼されるサービスモデルは、よりスケーラブルであるべきであり、ユーザアカウントごとにターゲットサーバＡＣＬを管理する必要性を最小限に抑えることになる。運用者は、展開操作を実行するためにターゲットサーバ上の管理者である必要はないことになる。
【０３３０】
テストラン環境において、Ｗｉｎｄｏｗｓ（登録商標）サービスは、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙアカウントか、またはＡｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙが存在しない場合、特権のないＮｅｔｗｏｒｋＳｅｒｖｉｃｅアカウントとして実行されることになる。後者の場合、ターゲットサーバ上の認証されたユーザアカウントの偽名が必要となる。
【０３３１】
ＵＩの説明
ＳＤＭランタイム自体にＵＩ（Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）は存在しない。ＳＤＭランタイムは、展開ツールＵＩを通じて、または１組のコマンドラインツールを通じて呼び出すことができる１組のＡＰＩを公開する。展開ツールＵＩについては、別の文献で明記することにする。
【０３３２】
セキュリティモデル
ＳＤＭランタイムに関するセキュリティモデルは、分散コンポーネントが展開されるターゲットサーバにアクセスするために固定の識別情報を使用する信頼できるサブシステムのセキュリティモデルである。認証されたユーザのセキュリティコンテキストは、このモデルではターゲットサーバに貫流しない。このセキュリティモデルの基本的な想定は、ターゲットサーバが、ＳＤＭランタイムサービスの固定識別情報を信頼し、これにより、ターゲットサーバ上で個々のユーザに関する管理権を管理する必要性をなくすことである。図４５は、固定識別情報の信頼関係を示している。
【０３３３】
信頼できるサブシステムモデルでは、信頼できるドメインアカウントの下でＳＤＭランタイムサービスを実行することがもちろん可能であり、またはローカルの特権のないＮｅｔｗｏｒｋＳｅｒｖｉｃｅとして実行することさえ可能である。理解すべき重要な点は、どの展開動作に関する許可も役割ベースの許可を使用してＳＤＭランタイムによって管理されること、およびＳＤＭランタイムサービスだけが、ユーザが認証され、要求された展開操作を許す役割にマップされると、ターゲットサーバ上でインストール動作、更新動作、およびアンインストール動作を行うことができる。
【０３３４】
認証
認証は、ユーザだけに知られているクリデンシャルの秘密（ｃｒｅｄｅｎｔｉａｌ  ｓｅｃｒｅｔ）、および基礎となるセキュリティインフラストラクチャに基づいてユーザの識別情報を検証するプロセスである。分散アプリケーション展開の目的で、ユーザは、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙドメインアカウント、またはローカルアカウントを通じてＷｉｎｄｏｗｓ（登録商標）認証を使用して認証されることになる。ローカルアカウントが使用される場合、展開コンピュータ上のローカルアカウント名およびパスワードが、ターゲットサーバのものと同じでなければならない。
【０３３５】
許可
ユーザが認証されると、インストール、更新、またはアンインストールなどの展開操作を行うための許可が、認証されたユーザがメンバであるデータベース役割に基づいて認められることになる。Ｗｉｎｄｏｗｓ（登録商標）のユーザおよびグループアカウントはＳＱＬサーバデータベース役割のメンバであることができるので、基本許可シーケンスは、以下のとおりである。
１．Ｗｅｂサービスが、Ｗｉｎｄｏｗｓ（登録商標）認証を使用してユーザを認証する。
２．Ｗｅｂサービスが、認証されたユーザとしてデータベースに接続する。
３．ユーザが、ユーザまたはグループアカウントメンバシップに基づいてデータベース役割にマップされる。
４．Ｗｅｂサービスが、ＳＤＭランタイムのＷｉｎｄｏｗｓ（登録商標）サービスコンポーネントによって非同期的に読み取ることができる適切なデータベーステーブルに展開動作情報を書き込む。
【０３３６】
オペレーティングシステムインフラストラクチャの外部でパスワードを管理する必要性も、ターゲットサーバ上でユーザＡＣＬごとに管理を行う必要性もないことに注目されたい。
【０３３７】
偽名
偽名は、現在のプロセス所有者以外の異なるアカウントのセキュリティコンテキストにおいてコードを実行する能力である。ターゲットサーバに対する遠隔接続が、偽名が有効にした状態でＷＭＩを使用して確立されることになる。偽名は、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙが存在するときに、信頼されるサービス識別情報に基づき、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙが利用可能でないときに（例えば、テストラン環境）、認証されたユーザのセキュリティコンテキストに基づくことになる。
【０３３８】
Ｗｉｎｄｏｗｓ（登録商標）サービス
ＳＤＭランタイムのＷｉｎｄｏｗｓ（登録商標）サービスコンポーネントは、ターゲットサーバ上の管理権を有するサービスアカウントとして実行されるべきである。管理権の必要性は、ターゲットサーバ上にソフトウェアをインストールし、ＩＩＳ、ＳＱＬ、およびレジストリに関する様々な設定を作成する要件に起因する。
【０３３９】
Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙドメインアカウントが存在しない場合、Ｗｉｎｄｏｗｓ（登録商標）サービスは、ターゲットサーバ上で管理動作を行うことが許可されたユーザアカウントの偽名を使用することになる。その場合、Ｗｉｎｄｏｗｓ（登録商標）サービスは、パスワードを必要とせず、ローカルコンピュータ上の特権のないユーザであるＮｅｔｗｏｒｋＳｅｒｖｉｃｅとして実行されることになる。Ｗｉｎｄｏｗｓ（登録商標）サービスは、接続するときに遠隔コンピュータにローカルコンピュータのクレデンシャルを提示することになる。
【０３４０】
ＩＩＳ
ＳＱＬサーバ
ＳＱＬサーバは、次の２つの認証モードで動作することができる。すなわち、Ｗｉｎｄｏｗｓ（登録商標）認証モードおよび混合モードである。Ｗｉｎｄｏｗｓ（登録商標）認証モードは、混合モードよりセキュリアであるので、ＳＤＭランタイムデータベースのためのＳＱＬサーバは、Ｗｉｎｄｏｗｓ（登録商標）認証モードだけで構成されることになる。これにより、ｓａアカウントがＳＤＭランタイムデータベースに対する認証のために使用されるるを防止することになる。ＳＤＭランタイムデータベースに関する管理特権は、Ａｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙ許可インフラストラクチャを活用するためにＷｉｎｄｏｗｓ（登録商標）グループメンバシップを通じて制御されるべきである。ＳＱＬサーバを管理するためのＡｃｔｉｖｅ  Ｄｉｒｅｃｔｏｒｙグループを作成し、このグループに特定のユーザを追加することにより、特化したアカウント上でパスワードを管理する必要なく、ＳＤＭランタイムデータベースに対するアクセスを制御することがより容易になる。
【０３４１】
ＳＤＭランタイムデータベースに加えて、ＳＱＬサーバが稼動しているターゲットサーバも、Ｗｉｎｄｏｗｓ（登録商標）認証モードを使用し、Ｗｉｎｄｏｗｓ（登録商標）グループメンバシップを通じて管理アクセスを管理するべきである。ＳＤＭランタイムデータベースに関するＷｉｎｄｏｗｓ（登録商標）グループとターゲットサーバに関するＷｉｎｄｏｗｓ（登録商標）グループは、異なるグループであるべきである。ＳＱＬサーバマシンを管理するための１つまたは複数のＷｉｎｄｏｗｓ（登録商標）グループを有するか否かは、顧客にとってのポリシー決定である。例えば、以下のとおりである。
ＳＤＭランタイム管理者グループ
ユーザＡ、ユーザＢ
ＳＱＬ  Ｓｅｒｖｅｒ層１管理者グループ
ユーザＣ、ユーザＤ
ＳＱＬ  Ｓｅｒｖｅｒ層２管理者グループ
ユーザＣ、ユーザＥ
【０３４２】
（ＳＤＭサーバの概要）
序論
ＳＤＭサーバとは何か−ＳＤＭサーバは、ＳＤＭを中心に構築されたサービスのセットである。現在、展開ツールのアーキテクチャに関してとることができる２つの一般的なアプローチがある。それぞれについてここで概説する。
【０３４３】
分散型アプローチ
このアプローチでは、ＳＤＭランタイムおよび展開エンジンを利用するツールが、ランタイムＯＭクライアントライブラリに対して構築され、このライブラリは、Ｗｅｂサービスを使用してＳＤＭランタイムエンジンおよびＳＤＵ（バイナリ）を配置するためのファイル共有と通信する。ＳＤＭエンジンおよび展開エンジンは、ＳＤＭエンティティおよび展開ジョブのデータベースを共用する。展開タスクは、ＷＭＩおよびＳＭＢ（ファイル共用）を使用して展開エンジンによって非同期に実行されて、ターゲットエンジンと通信する。
【０３４４】
単純化されたアプローチ
このアプローチでは、クライアント、ＳＤＭオブジェクトモデルライブラリ、ＳＤＭエンジン、展開エンジン、およびインストーラプラグインがすべて同一プロセスにおいて実行され、それゆえそのようなものとしてのサービスはない。ランタイムデータベースおよびバイナリライブラリは、異なるマシン上に存在することができる。ターゲットマシンに対するＷＭＩ接続およびＳＭＢ接続は、クライアントまたはＵＩが実行されているところから直接に行われる。
【０３４５】
ユーザインターフェースおよび他のクライアント
ＳＤＭサーバに関するユーザインターフェースは、以下を含むことになる。
●アプリケーションのテストインスタンスの展開、更新、または削除を行う簡単なメソッドを提供するＶｉｓｕａｌ  Ｓｔｕｄｉｏのウィザード
●ＳＤＭ、ＳＤＵ、およびインスタンス要求をロードするコマンドラインツール
●オブジェクトモデルのすべての機能を表出させ、ホストモデルおよびインスタンス要求を構成するためのグラフィカルツールをさらに提供する完全なＵＩ
【０３４６】
ランタイムＯＭライブラリ
ＳＤＭサーバに対する公開インターフェースは、このライブラリを介する。このライブラリは、管理されたコードオブジェクトモデルであり、このライブラリを使用して、以下のことを行うことができる。
●ランタイムにおいてＳＤＭを管理する。ＳＤＭをランタイムにロードすることができる。ＳＤＭは、厳密名を付けられ、不変であり、一度に１つのＳＤＭがロードされる（すなわち、個々のタイプ、クラス、またはマッピングではなく、１つのＳＤＭファイルをロードする）。ランタイムからＳＤＭを削除し、ランタイムにおいてＳＤＭに関するＸＭＬドキュメントを生成することができる。ＳＤＭは、ランタイムにおいて他のＳＤＭから、またはインスタンスからＳＤＭに対する参照が存在する限り、ランタイムから削除することはできない。
●ランタイムによって知られているＳＤＵを管理する
●（ランタイムにロードされたＳＤＭから）ＳＤＭ要素を見つけ出し、反映する。新たなＳＤＭを作成するために提供されるＡＰＩはない（すなわち、これは、ＳＤＭの不変な要素に対して読み取り専用オブジェクトモデルである）。これには、ＳＤＭ、ＳＤＵ、識別情報、バージョン、クラス、タイプ、バインド化／マッピング、およびバージョン管理ポリシーが含まれる。
●コンポーネント、ポート、ワイヤ、および物理配置（インスタンス空間におけるホスト関係）のインスタンスを見つけ出し、反映する。インスタンス空間では、各インスタンスは、ＧＵＩＤ、安定パス（ｓｔａｂｌｅ  ｐａｔｈ）、または配列ベースのパスによって識別することができる。パスはストリングであり、相対的であることができる。相対パスを含むこれらの識別子により、インスタンス要求ドキュメントのようにドキュメントにおいてインスタンスを見つけ出し、参照することが可能になる。
●作成、トポロジ変更、アップグレード、設定変更、および削除を含むインスタンスの操作。インスタンス変更は、インスタンス要求の境界内で行われる。これにより、更新のアトミック単位が提供され、エラーまたは制約違反が、要求全体の失敗となるようになる。また、インスタンス要求により、インスタンスがホストへのバインド化なしで一時的に存在することが可能になる。というのは、インスタンスは、要求がコミットされるときにホストを有していなければならないからである。また、インスタンス要求により、単一のコンポーネントの行われるべきインストールまたは設定に影響を与え、コンポーネントに関して単一の更新が行われるようにコミットするまでインストールまたは設定の更新を据え置く多くの操作も可能にする。
【０３４７】
●インスタンス要求を作成するときにインスタンス要求内で順序付けを作成する。順序付けにより、インスタンス要求からもたらされるコンポーネントに関するインストールの順序の制御が可能になる。
●インスタンス要求を見つけ出し、反映する。これには、すべてのエラー情報を含む状態の獲得およびその要求によって影響を受けるコンポーネントのインストール／更新の再試行が含まれる。
●インスタンス要求をロードする。インスタンス要求は、１組のインスタンス空間操作を表すＸＭＬファイルである。このドキュメントは、相対パスを活用して、アプリケーションインスタンスを作成または削除するための再使用可能な「スクリプト」とすることができる。
●データベースのインスタンス要求からインスタンス要求ドキュメントを生成する。そのようなドキュメントは、ある意味ポータブルである。
●ＳＤＭサービスに対するセキュリティ許可を管理する。これには、ターゲットマシンを操作するために使用されるクレデンシャル、および特定のホストインスタンス上でホストされるインスタンスを誰が作成することができるかなどのインスタンス操作に関する許可を設定することが含まれる。
●インスタンス要求インストール完了を含め前述の機能に関するイベントにサブスクライブする（ｓｕｂｓｃｒｉｂｅ）。このイベントのサブスクリプションの存続期間は、クライアントライブラリをロードしたプロセスの存続期間によって制限される（すなわち、これらは通常のＣＬＲイベントである）。
【０３４８】
ＳＤＭランタイムエンジン
ＳＤＭランタイムエンジンは、ＳＤＭモデルに関する推論、およびオブジェクトモデルによって表出した機能を実行する。
【０３４９】
分散型アプローチでは、ライブラリは、ＳＤＭのロード、コンポーネントインスタンスの作成、およびＳＤＭ全体の獲得（ＳＤＭエンティティ上に反映するため）などのかなりコースな（ｃｏｕｒｓｅ）コールを使用してＷｅｂサービスとしてランタイムエンジンと通信する。これによりサーバへの往復が低減される。このＷｅｂサービスに関するパラメータの多くのフォーマットは、ＳＤＭファイルについて同じスキーマを有するＸＭＬである。
【０３５０】
ある意味で、ＷｅｂサービスはＳＤＭサービスのすべての機能を提供し、クライアントライブラリがＷｅｂサービスを単にもっと使いやすくしているだけである。分散型アプローチでは、エンジンは、許可に関する検査を実行する（詳細についてはセキュリティ仕様を参照されたい）。
【０３５１】
インストーラプラグイン
インストーラプラグインは、クラスホスト関係に関連付けられる。インストーラプラグインは、Ｖｉｓｕａｌ  Ｓｄｕｄｉｏにおいて、使用中のプラグインと密接に関連しており、これによりクラスに関する設計体験が提供され、ＳＤＵの関連バイナリ、および展開値が生成される。インストーラプラグインは、ＳＤＭサーバの機能に以下のものを提供する。
●ホスト上のインストール、アンインストール、および再インストールコンポーネント。インスタンス要求が新たなコンポーネントインスタンス、コンポーネントインスタンスの削除、または再インストールを必要とするコンポーネントの変更をもたらす場合、インスタンス、ホストインスタンス、コンポーネントに関連するタイプ、およびＳＤＵのタイプに関連するバイナリに関する設定を取り込み、インスタンスのインストール、またはアンインストールを行うのはインストーラである。ＳＤＭのアプリケーションレイヤにおいて、タイプの提供された基本．ｍｓｉをホスト上にインストールし（特定のパラメータを使用して）、第２のタスクを適切な設定およびポートビューを設定するホスト上で実行するのを要求することは、インストーラにっとて最も一般的である。
●設定が変更されたとき、またはポートの１つのビューが変更されたとき（トポロジの変更、または設定変更を有する可視のポートに起因して）、コンポーネントインスタンスを更新すること。ＳＤＭのアプリケーションレイヤにおいて、このことがインストールの第２の部分の再実行であることは最も一般的である。
●ポート上の可視のポートをインストールされたコンポーネントインスタンス上の設定にマップする。ＳＤＭにおいて、コンポーネントインスタンスは、何らかのワイヤトポロジの結果として、ポートインスタンスが他のポートインスタンスの詳細を見ることを可能にし、通常、それによって他のポートインスタンスにバインドすることができるようにするポートインスタンスを有する。例えば、ＡＳＰ．ＮＥＴ  Ｗｅｂサイトは、データベースに配線することができるようにデータベースクライアントポートインスタンスを有してもよい。正しく配線された場合、そのデータベースクライアントポートは、単一のデータベースサーバポートインスタンス、およびそのサーバポート上の設定を見ることができる。この情報は、ＡＳＰ．ＮＥＴインストーラにより使用されて、クライアントポートの名前の下でｗｅｂ．ｃｏｎｆｉｇファイルにサーバに関する接続ストリングを入れる。
●インストーラはまた、ホストとそのゲストの間の制約検査を行うコードを提供する。この検査は、ＳＤＭエンジンによって実行され、これは前述の分散型アプローチでは示されていない。ほとんどのインストーラは、ＸＭＬ、ＸＰａｔｈ、およびＸＱｕｅｒｙに基づく共通の制約言語を使用することが予想される。
●設定を監査する（ａｕｄｉｔ）
●存在を監査する
●フル（Ｆｕｌｌ）を監査する
●ホストされたインスタンスを監査する
【０３５２】
コンポーネントに対するマッピング設定
インターフェース
ホスト上のローカルシステムとしての実行コマンドのような１組の基本メカニズムをインストーラに提供すること。将来、誰かがネットアドレスおよびアカウントだけを必要とするさらなるメカニズムを提供するであろう。
インターフェースは、管理されたコードである。
【０３５３】
設計
以下のセクションでは、データセンタ、およびそのようなデータセンタとしてホストされる分散アプリケーションがどのように設計されるかを扱っている。設計者は、ＳＤＭを使用して、データセンタ（例えば、ハードウェア、ネットワーク、ホストサーバ）、およびアプリケーションにおいて使用される物理リソースをアーキテクチャ設計する際に使用される様々なビルディングブロックをモデル化する。
【０３５４】
データセンタ記述
このセクションでは、数多くのマシンなどの特定のリソースを表すことなくデータセンタコンポーネントをどのようにモデル化するかについて説明する。このセクションでは、サービス定義モデル（ＳＤＭ）意味構造を使用して物理データセンタ環境のスケール不変モデルを提供する。
【０３５５】
仮想データセンタ（ＶＤＣ）は、データセンタの開発者のビューを簡単化する物理データセンタ環境の論理表現である。理想的には、ＩＴ専門技術者またはＩＴアーキテクチャ設計者は、開発者が分散アプリケーション／サービスを記述することができるのと同じスケール不変の形でデータセンタを記述できなければならない。ＶＤＣは、データセンタ内のサーバリソース、ネットワークリソース、およびストレージリソース、ならびにそれらのトポロジ上の関係の抽象化である。
【０３５６】
通常のデータセンタ図は、複数の互いに接続されたサーバ、ネットワーク機器、ＩＰアドレス、ＶＬＡＮ、オペレーティングシステム、ストレージ等がすべて、Ｖｉｓｉｏまたは同様のツールを使用して描かれた単一の図の上に表現されており、極めて複雑である。図に加えて、通常、どのようにデータセンタが区画化され、構成され、管理されるかを正確に規定する長大なドキュメントが存在する。
【０３５７】
この複雑さの例は、マイクロソフトシステムアーキテクチャ（ＭＳＡ）エンタープライズデータセンタ（ＥＤＣ）である。更新およびアップグレードが適用される際の時間の経過にわたってデータセンタの状態に対して手書きの図およびドキュメントを最新に保つことが、不可能でないにしても、コストのかかる作業になることが明白であろう。同様に、ドキュメントの規定に照らして環境を検証できることは、困難であり、人間による誤りが生じやすい。
【０３５８】
スケール不変の形でＭＳＡ  ＥＤＣのような複雑なデータセンタを表現できることは、開発者およびＩＴ専門技術者の両方にとって極めて強力であろう。コンポーネント、ポート、およびワイヤを使用してデータセンタを記述できることにより、今日の設計および展開のプロセスに欠落している展開要件をモデル化し、検証する強力なフレームワークが提供される。
【０３５９】
データセンタ記述の一態様は、ハードウェアを仮想化し、集約されたコンピューティング環境についてのメカニズムを構成できることである。従来のデータセンタ環境において、運用者は、通常、特定のアプリケーションに特有のハードウェア環境を構築している。例えば、新しい電子メールシステムをデータセンタに展開するとき、運用者は、１組のサーバを購入し、バックアップゾーンやデータゾーンのような異なるネットワークについてネットワークアダプタを追加し、スイッチや負荷分散装置のようなネットワークハードウェアを追加する。アプリケーションのためのハードウェアの展開は、広範な物理的努力を必要とする。
【０３６０】
それらの手作業で構築し、アプリケーション特有のハードウェア構成を作成するのに高いコストがかかるだけでなく、変更することが容易でない。つまり、構成の静的な性質により、作業負荷が変化するのに応じてリソースが新たなアプリケーションに容易に移動することができるので、低いリソース利用率という結果になる。
【０３６１】
本開示は、運用者が、サーバ、ストレージデバイス、およびネットワークデバイスを含む物理リソースの単一のプールを稼動することができるデータセンタ仮想化環境を作成する方法について説明する。その単一のプールから、アプリケーションのニーズを満たすように、オンデマンドでリソースが割り振られ、構成される。１組のリソースプロバイダが、リソースの所有権を追跡し、アプリケーションのニーズを満たすためにどのようにリソースを構成するかを知っている。
【０３６２】
新しいアプリケーションをデータセンタ環境に展開するとき、運用者は、アプリケーションによって必要とされるリソースの抽象記述を作成する。１つの要求は、サービスプラットフォームに対して抽象記述が現実のリソースに解決されることを求めることである。サービスプラットフォームは、リソースマネージャと協働して要求を満たすことができるリソースを見つけ出し、要求を最も経済的に満たすリソースを選択し、そのリソースに使用中とマークし、要求要件に適合するようにリソースを構成し、割り振られたリソースの具体的な記述を抽象記述に入れる。アプリケーションのニーズが変化するにつれ、運用者は、リソース記述を更新し、更新アプリケーション記述を解決するようにサービスプラットフォームに求める。個々のリソースプロバイダは、アプリケーションのニーズを満たすように物理リソースを構成するハードウェア、またはＯＳ特有のソフトウェアドライバを使用することができる。
【０３６３】
データセンタ記述に関連する概念には、（１）所望のリソース、リソース要求、および許可されたリソースを記述するためのグラフ言語、（２）ある所与のタイプの利用可能なリソースの知識、およびアプリケーション要件を満たすためにそのリソースを構成する能力を備えた１組のドメイン特有のリソースプロバイダ、および（３）リソース要求を処理し、リソースプロバイダと通信して適切な利用可能なリソースを見つけ出し、オプションとして特定のリソースの選択を最適化し、選択されたリソースを構成するようにリソースプロバイダに求め、選択されたリソースを反映するようにリソース要求を更新するリソースマネージャが含まれる。
【０３６４】
アプリケーション記述
アプリケーションも同様に、ＳＤＭ意味構造を使用して定義することができる。これは、段落０で開始しているＳＤＭセクションに関連して上記により詳細に説明されている。図２０は、アーキテクチャ設計者がＳＤＭ意味構造に関して大規模な分散アプリケーションを記述することを可能にするグラフィカルユーザインターフェース（ＵＩ）を示している。
【０３６５】
アプリケーションの物理システム上への論理配置
アプリケーションおよび仮想データセンタがＳＤＭ意味構造を使用してアーキテクチャ設計されると、アーキテクチャ設計者は、アプリケーション要素の仮想ハードウェア要素上への異なる論理配置を論理的に試みることができる。異なる展開環境（開発、試験、実動等）に対して異なる論理配置がありえる。論理配置は、設計時に行うことができ、要件および制約が検査され、エラーまたは警告があれば、開発者にアラートされる。論理配置の結果は、別個のファイルに取り込まれ、制約検査は、各コンポーネントクラス、ポートクラス、およびワイヤクラス上で指定されたＸＰａｔｈおよびＸＳＤを使用して実装される。これを図２１に示している。設計者は、異なるアプリケーション要素を物理要素上に配置するときに直感的な意思表示のためにＵＩ（ユーザインターフェース）を利用することができる。
【０３６６】
設計時検証
以下のセクションは、アプリケーションの物理リソース上への論理配置を設計時に検証するアプローチを扱う。ＳＤＭのコンポーネント、ポート、およびワイヤに対する拡張により、レイヤおよびレイヤ間のマッピングが追加されて、分散アプリケーションの設計および展開要件の設計時検証が達せられる。
【０３６７】
コンポーネント、ポート、およびワイヤは、ホスト、ファクトリ、リソースマネージャ、およびＳＤＭランタイムと組み合わせられたとき、強力な抽象化であるが、分散アプリケーション／サービスを展開し、管理するには十分ではない。これら論理抽象化の物理インスタンスを作成し、管理するために、いくつかの追加の構成が関係する。その追加の構成が、レイヤおよびマッピングである。
【０３６８】
レイヤ
図１１は、ＳＤＭによって定義されるレイヤ抽象化を示している。
【０３６９】
アプリケーションレイヤは、分散可能なコンポーネント、それらの展開要件および制約、ならびにアプリケーション／サービスのコンテキストにおけるそれらの通信関係を記述する。
【０３７０】
展開レイヤは、特にＩＩＳ、ＣＬＲ、およびＳＱＬなどのホストに関する構成、およびポリシー設定、ならびに制約を記述する。
【０３７１】
仮想データセンタ（ＶＤＣ）レイヤは、オペレーティングシステムからネットワークトポロジを経由してサーバ、ネットワークデバイス、およびストレージデバイスまでのデータセンタ環境の設定および制約を記述する。
【０３７２】
ハードウェアレイヤは、物理データセンタ環境を記述し、発見されるか、例えば、ＸＭＬを使用して宣言的な形で指定される。このレイヤは、スケール不変ではなく、それゆえ、ＳＤＭでモデル化されないが、完全性のために含められている。
【０３７３】
マッピング
ＳＤＭはレイヤ化されているので、様々なレイヤ間をバインドする方法が必要である。マッピングは、基本的に、１つのレイヤにおけるコンポーネントまたはポートを次の下位レイヤにおけるコンポーネントまたはポートにバインド化することである。マッピングは、以下のとおり記述することができる。
ＭＴ＝［Ｔｎ→Ｔｎ−１］＋［Ｔｎ−１→Ｔｎ−２］＋［Ｔｎ−２→Ｔｎ−３］［．．．］
【０３７４】
ここで、Ｍはマッピングを表わし、Ｔはコンポーネント、ポート、またはワイヤを表わし、ｎはレイヤを表わしている。矢印はマッピングの方向を表わし、常に上位のレイヤから下位のレイヤに向かっている。
【０３７５】
例えば、図１２で、ＭｙＦｒｏｎｔＥｎｄという名前のアプリケーションレイヤにおけるコンポーネントが、ＩＩＳと呼ばれる展開レイヤにおけるコンポーネントにマッピングされている。同様に、ＭｙＢａｃｋＥｎｄという名前のコンポーネントが、展開レイヤにおけるＳＱＬコンポーネントにマッピングされている。
【０３７６】
設計時の検証
コンポーネントと下位のレイヤにあるそのホストコンポーネントの間のバインドにより、アプリケーション／サービスが活動状態のデータセンタにおいて実際に展開される前に、開発者に対して問題を表面化させることができる。その問題は、互換性がないタイプ、構成上の競合、合致しない動作、トポロジ上の関係の欠落などに起因することがある。例えば、図１３に描かれたマッピングの試みでは、展開レイヤにおいてＩＩＳとＳＱＬコンポーネント間に潜在的な通信関係が存在しないので、エラーという結果になっている。
【０３７７】
ＭｙＢａｃｋＥｎｄコンポーネントからＳＱＬホストコンポーネントに対するマッピングは、コンポーネントとホストのタイプの適合性、および構成上の競合がないことに基づいて有効なバインドになる可能性があったが、ＭｙＳｅｒｖｉｃｅ  ＳＤＭが、指定された展開レイヤにおいて存在していないＭｙＦｒｏｎｔＥｎｄとＭｙＢａｃｋＥｎｄ間のトポロジ上の関係を定義したため、無効である。
【０３７８】
レイヤ化されたアーキテクチャ
図４８は、分散コンピューティングシステム上の分散アプリケーションの設計、展開、および管理を自動化するためのプラットフォームアーキテクチャを示している。アーキテクチャは、分散コンピューティングシステムの物理コンピュータリソースを表わす基本レイヤ３０２上の複数のレイヤを示している。自動化された展開サービスレイヤ３０４は、マシンを分散コンピューティングシステム内で使用されるサーバに変換するツールを提供する。そのようなツールにより、ＯＳ（オペレーティングシステム）イメージの作成、編集、および展開が可能になる。マシンの遠隔プログラミングは、システムデバイスおよびネットワークデバイスを構成し、管理することを可能にするマイクロソフトのＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムのプログラミングインターフェース（ＡＰＩ）であるＷＭＩ（Ｗｉｎｄｏｗｓ（登録商標）Ｍａｎａｇｅｍｅｎｔ  Ｉｎｓｔｒｕｍｅｎｔａｔｉｏｎ）などの完全にプログラマティックなインターフェースを使用して達せられる。
【０３７９】
ネットワーク管理レイヤ３０６は、自動化された展開サービスレイヤ３０４の上にある。ネットワーク管理レイヤ３０６により、ネットワーク管理および仮想トポロジ生成が可能になる。部分的に、ネットワーク管理レイヤは、ネットワークスイッチの関連するポートに接続された単一の物理ネットワークインターフェースを介して個々のコンピュータを１つまたは複数のＶＬＡＮに接続することを容易にするネットワークコンピュータのためのドライバモデルをサポートする。ドライバモデルによれば、ＶＬＡＮドライバが、サーバにおいてインストールされ、単一の物理ネットワークインターフェースの上に仮想ネットワークインターフェース（ＶＮＩＣ）を作成するために使用される。ＶＬＡＮドライバは各ＶＬＡＮのための１つの仮想ネットワークインターフェース（ＶＮＩＣ）を生成する。ＶＮＩＣは、サーバにおいてＩＰスタック中のネットワークインターフェース（ＮＩＣ）のすぐ上に存在し、そのため、サーバはすべてのパケットが同じ物理ＮＩＣを通して物理的に伝送されるとしても、１つ以上のＶＬＡＮを介して受け渡されるパケットを処理することができる。
【０３８０】
ドライバモデルは、ＶＬＡＮタグ付けをサポートして、分散コンピューティングシステムを介して受け渡されているデータパケットに、それが属するＶＬＡＮのＩＤでタグを付けすることを可能にする。ネットワークスイッチが、タグ付けを施行し、スイッチが属するＶＬＡＮを特定するタグを有するパケットだけを受け入れる。１つの実施例では、ネットワークスイッチは、タグ付きポートとタグなしポートの両方を有する。スイッチのタグ付きポートには、ＶＬＡＮ識別子でタグが付けされ、他のスイッチのタグ付きポートへの接続のために使用される。これにより、スイッチのネットワークを通じてパケットの迅速な転送が可能になる。スイッチのタグなしポートは、サーバまたはコンピュータへの接続のために使用される。パケットがそのデスティネーションサーバに達したとき、パケットをアップストリームのサーバまで通信するのに先立ってパケットからＶＬＡＮタグが取り除かれ、そのため、サーバは、タグ付けについて何も知る必要がない。
【０３８１】
物理リソース管理レイヤ３０８は、ネットワーク管理レイヤ３０６の上に存在する。物理リソース管理レイヤ３０８は、分散コンピューティングシステムの物理モデルを維持管理し、すべての物理コンピューティングリソースの所有権を追跡し、割り振りを調整する。物理管理レイヤ３０８は、一括によるリソースの割り振りをさらにサポートし、それによって物理コンピューティングリソースの動的な構成および管理を可能にしている。
【０３８２】
論理リソース管理レイヤ３１０は、物理リソース管理レイヤ３０８の上に存在する。論理リソース管理レイヤ３１０は、分散アプリケーションによって要求された論理リソースの割り振りを円滑にする。例えば、アプリケーションは、データベース、負荷分散サービス、ファイアウォール、Ｗｅｂサービスなどのリソースを必要とする可能性がある。論理リソース管理レイヤ３１０は、そのような論理リソースを公開する。
【０３８３】
次のレイヤはサービス定義モデルおよびランタイムレイヤ３１２であり、これは分散アプリケーションの記述、およびアプリケーションの操作の追跡を可能にする。サービス定義モデル（ＳＤＭ）は、オペレーションプロセスを記述するための名前空間およびコンテキスト、ならびにアプリケーションイントロスペクション（ｉｎｔｒｏｓｐｅｃｔｉｏｎ）およびアプリケーションリソースの制御のためのＡＰＩを提供する。このレイヤは、運用者および開発者が共通のアプリケーションの見通しを共有することをさらに可能にする。
【０３８４】
コンピューティングリソースレイヤ上の第６のレイヤは、コンポーネントレイヤ３１４である。このレイヤは、分散アプリケーションの再使用可能なビルディングブロックの定義を可能にし、コンテキスト、名前付け、およびバインド化のためのＳＤＭ  ＡＰＩを使用する。
【０３８５】
最上位レイヤはオペレーション論理層３１６であり、分散アプリケーションのオペレーション上の態様を提供する。オペレーションロジックは、サービスを開始し、サービスを成長および縮小し、アップグレードおよびダウングレードし、障害の検出および回復、ならびに状態区画化を行う責を担う。オペレーションロジックにより、展開およびアプリケーションにわたる実証済みのオペレーション上の実践を再使用することが可能になる。ＳＤＭレイヤの使用を通じて、オペレーションロジックは、生じる可能性がある問題をよりよく理解するためのコンテキストを有する。例えば、障害が生じたとき、オペレーションロジックは、部屋の真中の何からのサーバにおいてというだけでなく、電子メールサービスのフロントエンドで障害が生じたことを判定することができる。
【０３８６】
展開
以下のセクションは、データセンタおよび分散アプリケーションの展開を扱う。展開は、論理モデルのインスタンス化、アプリケーションの物理配置、アプリケーションおよびデータセンタの展開を伴う。図２３は、展開段階を一般的に示している。
【０３８７】
インスタンス化
ＳＤＭタイプは、スケール不変であり、どのスケールに対しても作成することができるので、展開の一態様は、ある所与の論理コンポーネントについて作成されるべきインスタンスの数、およびハードウェア／アプリケーションを物理的に実装する配線トポロジを定義することである。インスタンス要求ドキュメントが作成されて、作成する必要のあるインスタンスの宣言定義を提供する。
【０３８８】
アプリケーションの物理配置
物理配置は、展開のターゲットである特定のホストインスタンスを選択する動作である。物理配置は、論理配置によって制限され、制約は物理配置中に再検証される。物理配置は、物理配置ファイルに保存される。
【０３８９】
データセンタおよびアプリケーションの展開
ＳＤＵ、論理配置ファイル、インスタンス要求、および物理配置ファイルがＳＤＭランタイムに送り込まれる。ＳＤＭランタイムは、ホスト上で新たなインスタンスを作成し、そのタイプ上の設定値に合致するようにそのインスタンスを構成する責を担う適切なインストーラを（クラスとホストの関係に基づいて）呼び出す。ＳＤＭランタイムは、すべてのインスタンス、それらの最終設定値、および配置のデータベースを維持管理することになる。ランタイムＡＰＩは、インスタンス空間の照会をサポートする。
【０３９０】
（ＢＩＧ展開ツール）
シナリオ記述
特徴の概要
ＢＩＧ展開ツールは、データセンタ運用者、および自らのアプリケーションを試験する開発者のために分散ＳＤＭアプリケーション展開を行う。ＢＩＧ展開ツールは、サービス定義モデル（ＳＤＭ）アプリケーションを利用し、これにはアプリケーション（ＳＤＵ）のビット、マッピングファイル、および１組の展開制約が含まれる。ユーザが、自身のサーバ上へのアプリケーションの配置を指定し、展開時間設定を提供する。ツールは、遠隔マシンに対してインスタンスのインストールまたはアンインストールを行い、ステータスを運用者に提供する。運用者は、後に、新たなインスタンスを追加したり、インスタンスを撤去したり、アプリケーションのトポロジを再構成したりすることができる。
【０３９１】
シナリオ
大企業は、別個のデータセンタおよび開発者組織を有する。データセンタは、従業員と顧客の両方にサービスを提供するエンドユーザのためのアプリケーションを展開し、維持管理し、ホストする。データセンタのトポロジは、稀にしか変化せず、ＢＩＧコンピュータではないＭＳＡ  ＥＤＣ１．５によく合致する。
【０３９２】
データセンタ組織は、開発者に、論理情報モデル（ＬＩＭ）と呼ばれるホストポリシーのスケール不変の抽象化を提供する。ポリシーは、アプリケーション上の制約、許容可能な設定、および基本トポロジを含むホストの構成を指定する。
【０３９３】
開発者組織は、エンドユーザのニーズを満たし、データセンタのポリシーの範囲内に留まるようにこうしたアプリケーションをコーディングし、ホット修正を行う（ｈｏｔ−ｆｉｘ）。開発者は、アプリケーション要件および見込まれるホストを指定することによって展開指針を提供する。
【０３９４】
アプリケーション運用者は、ＢＩＧ展開ツールを使用してデータセンタにアプリケーションを展開する。展開ツールは、開発者指針およびデータセンタポリシーを使用して適切な展開を確実なものにする。アプリケーション運用者は、後に、ツールを使用してスケール拡張（ｓｃａｌｅ−ｏｕｔ）、アプリケーショントポロジの再構成、またはアンインストールを行う。
【０３９５】
特徴の説明
振る舞いの仕様
ツールがＷｈｉｄｂｅｙおよびその他の製品とどのように適合するかの概要を以下に示す。ＳＤＭランタイム、ＬＩＭ、ＳＤＭ／ＳＤＵ、およびＷｈｉｄｂｅｙについては、他の仕様において詳述されていることに留意されたい。図４９は、アプリケーション展開に関する例示的な使用フローを示している。
【０３９６】
図４９で伝えるべき重要な点は、以下のとおりである（左から右へ）。
開発者が、ＳＤＭ、バイナリ、およびＳＤＵのマッピングを含むアプリケーションＳＤＵを納入する。（バイナリは、アプリケーションのビットおよびコンテンツを意味するものとして使用する。）
開発およびデータセンタの組織は、別個であるが、同じＬＩＭを共用する。
展開ツールを実行するマシン上には、ストアおよびＡＰＩを有するＳＤＭランタイムがある。
アプリケーション運用者が、データセンタ記述、つまり、展開記述子を担い、ＬＩＭ、ＳＤＵ、およびＳＤＵのマッピングを使用する。
エージェント、および「ミニファクトリ」が、ターゲットサーバ上に存在し、展開のための入力としてＳＤＵ、展開記述子、およびデータセンタ記述子を受け取る。
エージェントは、共通のミニファクトリＡＰＩを使用してミニファクトリと対話する。
この例におけるミニファクトリは、ＳＱＬおよびＩＩＳであるが、他の製品に拡張してもよい。以上が、インストール、構成、およびアンインストールの作業を行う。
【０３９７】
設定および制約の概要
ＢＩＧ展開ツールは、ＳＤＭアプリケーションを利用する。ツールがどのように設定および制約を使用することになるかを理解するために、このセクションは、ＳＤＭに対する設定および制約の基本的な概要を提供する。設定、制約、およびスキーマに関する十分な説明については、関連する仕様を参照されたい。この説明では、設定／制約がＳＤＭのメタタイプに関するか、タイプに関するか、またはメンバに関するかについて区別しない。
【０３９８】
ＳＤＭモデルでは、開発者、ネットワークアーキテクチャ、およびアプリケーション運用者は、設定／制約（ネットワークアーキテクチャ設計者および開発者）、ＳＤＵマッピング（開発者）、および展開時間設定（アプリケーション運用者）を提供する能力を有することになる。これらの制約および設定は、独自のスキーマ、規則、および値をそれぞれ有するホスト（すなわち、ＩＩＳ、ＳＱＬ、ＢｉｚＴａｌｋ）ごとに範囲が決められることになる。
【０３９９】
各ホストの公開された一群の設定は、アプリケーションによって設定可能な設定と、ホストによって予約された設定に分けられることになる。前者をアプリケーション設定と呼び、後者をホスト設定と呼ぶ。さらに、ホストは、「ホスト制約」を指定することによってアプリケーション設定を制限し、アプリケーションは、「アプリケーション制約」を通してホスト設定に関する前提条件を与える。制限は、設定の値の範囲、特定の値、または依存関係に関する場合がある。
【０４００】
以下のテーブルは、ホスト対アプリケーションに関する設定および制約をまとめている。
【０４０１】
【表１】
2004272912.tif 000003
【０４０２】
論理情報モデル（ＬＩＭ）の目標は、データセンタのポリシーおよび展開ブロッカ（ｂｌｏｃｋｅｒ）の抽象化された見通しを提供することである。ＬＩＭは、ホスト対アプリケーション制約／設定の間の、つまり、ホスト設定、およびアプリケーション制約の間の分割を宣言する。ＬＩＭが取り込むポリシーは、ネットワークアーキテクチャ設計者によって作成される。このポリシーは、ネットワークアーキテクチャ設計者、開発者によってＬＩＭファイルに成文化されるか、またはＮｏｔｅｐａｄで編集される正規マイクロソフトのＬＩＭの使用によって実施されることができる。
【０４０３】
ＬＩＭは、次に、アプリケーションを書き、データセンタのＬＩＭの表現に照らして試験するために開発者によって使用される。アプリケーションの一部として、開発者は、ＬＩＭが許容するアプリケーション設定の値、アプリケーションが実行されることになるホストの制約、ホスト上へのコンポーネントの配置に関するメタデータを供給する。開発者は、マッピングファイルを通してホスト上へのアプリケーションの配置に関する指針を提供する。未指定の設定は、アプリケーション運用者が提供することになる展開時設定（すなわち、ＩＰアドレスまたはＡｐｐ＿ｐｏｏｌ＿ＩＤ）として渡される。
【０４０４】
基本的な例は、ネットワークアーキテクチャ設計者が、高性能ホスト対ベストエフォート型ホスト上でサービスを購入する顧客に対して異なるホスト制約を指定することであろう。ホスト制約は、ＩＯまたはＷｏｒｋｅｒＴｈｒｅａｄｓの数を異なる形で限定することが可能である。この例における高性能ホスト設定とベストエフォート型ホスト設定は同一であり、ＩＩＳ＿６の新しいモードを使用している。開発者は、異なる予算および要件で２つのアプリケーションを書く。第１のショッピングアプリケーションは、より多くのＷｏｒｋｅｒＴｈｒｅａｄを要する。４０１Ｋアプリケーションは、それほど差異化していない。両方のアプリケーションとも、ＷｏｒｋｅｒＰｒｏｃｅｓｓＩｓｏｌａｔｉｏｎＭｏｄｅで実行されることを制約する（要する）。図５０は、アプリケーション対ホストの「設定および制約」を示している。
【０４０５】
展開の段階
ＢＩＧ展開ツールを使用して、以下に示すＳＤＭアプリケーション展開について４つの段階が存在する。図５１は、展開ツールに関する例示的な段階を示している。
【０４０６】
初期段階は、ＬＩＭが生成されてスケール不変な形でデータセンタを表し、次に、ハードウェア分類ファイル（データセンタ記述子）を作成するために使用される段階である。
【０４０７】
アプリケーション展開段階は、開発者がＬＩＭに照らしてコーディングを行い、展開ツールＡＰＩを使用して自身のＳＤＭアプリケーションの試験およびデバッグする段階である。
【０４０８】
インストール段階は、アプリケーション運用者が既に構成済みのマシン上にアプリケーションをインストールする段階である。
【０４０９】
稼動段階は、アプリケーション運用者がスケール拡張し、トポロジを再構成し、または既に稼動中のアプリケーションをアンインストールする段階である。
【０４１０】
本明細書を通して、特に流れ図において、「展開」という用語は、すべての必要なホスト設定／制約検査、ホスト対アプリケーションの不適合のフラグ設定、アプリケーション設定の書き込み、およびミニファクトリ動作のコールを含むものとして使用していることに留意されたい。ミニファクトリ動作は、インストール、アンインストール、構成、およびＦｕｓｉｏｎ、ＭＳＩ、または将来のマイクロソフトのインストーラへのフックを行うすべての動作である。
【０４１１】
初期段階
初期段階は、ＬＩＭおよびデータセンタ記述子が作成されるときである。
データセンタのネットワークアーキテクチャ設計者は、Ｍｉｃｒｏｓｏｆｔ．ｃｏｍから最もよく合致するデジタル署名されたＬＩＭを選択し、ダウンロードする。次に、ネットワークアーキテクチャ設計者は、ネットワークトポロジ、許容されるアプリケーション設定、およびホスト制約を含む所望のデータセンタポリシーを反映するようにファイルを編集する。
【０４１２】
さらに、ＬＩＭは、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏ  Ｗｈｉｄｂｅｙの設計表面において作成することができる。プロセスフローは、次に、ネットワークアーキテクチャ設計者が、開発者組織にすべての関連するポリシーおよびトポロジの情報を与えることであり、これは、今日、ＷｏｒｄドキュメントおよびＶｉｓｉｏ図に取り込まれる。開発者は、次に、データセンタを記述する適切なＬＩＭを作成し、ネットワークアーキテクチャ設計者とともに繰り返して正しさを確実にする。
【０４１３】
ＬＩＭが作成されると、データセンタ組織は、データセンタ記述子ファイルを作成することによってＬＩＭに従って自らのハードウェアを分類する。データセンタ記述子は、ＬＩＭコンポーネントを稼動中のハードウェアに対してマップし、これを分類の動作と呼ぶ。それゆえ、データセンタ記述は、スケール不変ではなく、ＩＰアドレスのようなマシン特有の詳細を含む。以下の図は、データセンタ記述子を視覚化しているが、ＵＩを示唆するものではない。ＬＩＭは、「ＩＩＳゴールド」および「ＩＩＳシルバー」論理ホストの概念を有するであろうことに留意されたい。データセンタ記述子において、これらの論理ホストは物理マシンにマップされ、それによってＩＰアドレス、１９２．１６８．１１．２上にあるＩＩＳ［１］ゴールド、ＩＰアドレス１９２．１６８．１１．３上にあるＩＩＳ［２］ゴールドを有するといった具合である。図５２は、データセンタ記述の例示的な視覚化を示している。
【０４１４】
データセンタ運用者がサーバ、ネットワーク、リソース、およびアプリケーションより下のすべてをインストール／構成する際、動作はＬＩＭの範囲内に留まる必要があることに留意されたい。（データセンタ運用者が、アプリケーションより下のすべての物の責を担うことを想起されたい。）ネットワークアーキテクチャ設計者とデータセンタ運用者はともに、展開ツールの外部で自らのタスクを行う。
【０４１５】
アプリケーション開発段階
この段階では、開発者は、ＬＩＭに照らしてコーディングを行い、試験／デバッグ展開のためにＢＩＧ展開ツールＡＰＩを使用する。このＬＩＭは、データセンタによって提供されるか、またはデータセンタに代行して開発者組織によって成文化される（前述したとおり）。
【０４１６】
展開ツールＡＰＩにより、Ｖｉｓｕａｌ  Ｓｔｕｄｉｏ  Ｗｈｉｄｂｅｙが自らの「Ｆ５」展開および「試験／デバッグ」展開を実行する２つのシナリオが可能になる。Ｆ５展開および試験／デバッグ展開は、それぞれ単一の開発者ボックス、および複数のマシンに対するものである。Ｆ５のシナリオでは、必要なビットは、既にターゲットの単一の開発者ボックス上にある。試験／デバッグのケースでは、展開ツールが、通常の展開の場合と同様に、ターゲットマシンにビットを転送することが必要とされる。しかし、Ｆ５のシナリオも、試験／デバッグのシナリオもともに、開発者が、競合している設定の警告を受け、アプリケーションおよびホスト設定をともに上書きすることを可能にする。（通常、アプリケーション設定だけが、展開ツールによって書くことができる。）これらのＶＳシナリオは、ＳＤＭランタイムを使用していないことに留意されたい。図５３は、これらのＶＳシナリオを描いている。
【０４１７】
Ｖｉｓｕａｌ  Ｓｔｕｄｉｏの「Ｆ５」のシナリオと「試験／デバッグ」のシナリオに関する重要な注意（ｃａｖｅａｔｓ）は、以下のとおりである。
ＢＩＧ展開ツールＡＰＩは、ウィザードを通してＶＳからコールされることになる。
ＶＳウィザードは、展開の対象となるマシンを選択し、展開時間設定（すなわち、ＩＰ＿ａｄｄｒｅｓｓまたはＡｐｐ＿ｐｏｏｌ＿ＩＤ＝１７）を受け取ることになる。
ＶＳは、ユーザインターフェースを実装することになる。
Ｆ５のシナリオにおいて、ＳＤＭ、ＳＤＵ、バイナリ、およびすべてのビットは、既にターゲットの単一の展開ボックス上にある。それゆえ、必要とされるのは設定を書き込むことだけである。
試験／デバッグループにおいて、「展開」は、必要な設定を書き込むことを含む。
両方のシナリオとも、設定が競合するとき、フラグを設定し、ホストおよびアプリケーションを含むターゲットマシンの設定を上書きすることを可能にする。
【０４１８】
図５３に示していないのは、開発者がＬＩＭに照らしてアプリケーションをコーディングしていることと、ＬＩＭに対するＳＤＵマッピングの概念である。（ＬＩＭに関するさらなる詳細は、ＬＩＭ／ＬＩＤ仕様を参照されたい。）開発者は、ＳＤＭファイル、バイナリファイル、およびＳＤＵマッピングファイルが入っているＳＤＵをアプリケーション運用者に引き渡す。
【０４１９】
インストール段階
インストール段階に関して、運用者はアプリケーション（マッピングを有するＳＤＵ）およびデータセンタ記述子（ＬＩＭを拡張する）を提供される。
【０４２０】
アプリケーションのインストールを説明する図５４について、以下の注意が重要である。
アプリケーション運用者がツール（ＧＵＩ／ＣＬＩ）を立ち上げる。
すべてのファイルおよびデータセンタ記述とともにアプリケーションをコピーし、ロードする。
アプリケーションが、ＳＤＭランタイムに登録される。
アプリケーション運用者が、アプリケーション＿コンポーネントのホスト／マシンを選択する。（例を次のセクションで提供する。）
この選択（マッピングと呼ばれる）期間中、制約がランタイムの世界観（ｖｉｅｗ  ｏｆ  ｔｈｅ  ｗｏｒｌｄ）に照らして検査される。このツールの外部で設定を変更し、排反ビュー（ｄｉｓｊｏｉｎｔ  ｖｉｅｗ）が生じた場合、保証されない。
【０４２１】
展開は、ホスト対アプリケーションの制約／設定検査およびインストールを行う。（実装は、ネットワークがばらばらになる（ｆｌａｋｉｎｅｓｓ）のを回避するため、キャッシュ上にファイルをキャッシュし、ＡＣＬ設定することではるかに複雑になる可能性があることに留意されたい。）
ツールは、ＵＩまたはドキュメントを通じて、ステートフル（ｓｔａｔｅｆｕｌ）データ（ＳＱＬデータベースをポピュレート（ｐｏｐｕｌａｔｅ）することなどの）を扱わないことを明確にする。
【０４２２】
以上のステップにより、特定の展開に再使用することができ、または変更することができる展開記述が生成される。（例を次のセクションで提供する。）
「プレビュー」機能により、アプリケーション運用者は、ツールが行うことになる変更のリストを獲得することが可能になる。ユーザは、プレビューによって生成された展開記述子を使用してツールを再実行することができる。
【０４２３】
既に生成された展開記述子は、ＳＤＭランタイムがアプリケーションについて知っており、アプリケーションビットが依然として利用可能であり、同じデータセンタ記述子が有効であるものと想定すると、ロードし、実行することができる。図５４は、例示的なインストールシナリオを示している。
【０４２４】
展開を指定する例
展開を指定するために必要とされるデータの流れを明確にするため、ＬＩＭを通してデータセンタを制約しているＭＳＮの例を使用する。
【０４２５】
ＬＩＭは、デジタル署名され、タイムスタンプされ、バージョン管理されることができる。開発組織は、ＬＩＭを使用して、ＭＳＮデータセンタのホスト（ＩＩＳおよびＳＱＬサーバ）上でホストされる２層のアプリケーションをコーディングする。開発者は、コンポーネントがホストされるべきホストを指定し、ＳＤＵマッピングファイルを生成する。このＭＳＮ例を図５５に示す。
【０４２６】
以下は、図５５、およびアプリケーション展開におけるデータフローにおいて重要である。
ＳＤＵは、ＳＤＭを含む。
開発者は、ＳＤＵコンポーネントをＬＩＭ（ＭＳＮｄａｔａｃｅｎｔｅｒ．ＬＩＭ）にマップし、ＳＤＵマッピングファイルを作成する。マッピングは、許容可能な配置である。
データセンタ記述は、ＬＩＭコンポーネントに従って実際の／物理サーバを分類し、スケール不変ではない。
ＳＤＵ、ＳＤＵマッピング、データセンタ記述、およびユーザ入力が展開ツールに送り込まれて展開記述子が作成される。
展開記述子は、（ＳＤＵからの）コンポーネントを（データセンタ記述からの）どのマシン上にインストールするかを指定する。
展開記述子は、ＵＲＬなどの展開時設定を受け取る。
【０４２７】
図５５は、展開記述子ファイルを生成する例を示している。
前述の例では、ＳＤＵマッピングファイルは、開発者がＳＤＭコンポーネント２ＴｉｅｒＡｐｐ．ＭｙＷｅｂをＭＳＮで制約されたホストコンポーネントＭＳＮ９．ＩＩＳ＿ＭＳＮにバインドすることを規定し、２ＴｉｅｒＡｐｐ．ＭｙＤＢ→ＭＳＮ９．ＳＱＬ＿ＭＳＮに関しても同様である。（複数のＭｙＷｅｂが存在する場合、曖昧さをなくすために複合コンポーネントを指定する。）
【０４２８】
ネットワークアーキテクチャ設計者は、ＩＩＳおよびＳＱＬの制約と設定がどのように構成されるかを記述するＭＳＮｄａｔａｃｅｎｔｅｒ．ＬＩＭを編集する。このＬＩＭは、ＩＩＳまたはＳＱＬが稼動している特定のマシンではなく、ＩＩＳホストおよびＳＱＬホストを記述しているので、スケール不変である。データセンタは、ＬＩＭにて構成したようにどのマシンがＩＩＳおよびＳＱＬを実行しているかを規定するデータセンタ記述子を導出する。ＩＩＳ＿ＭＳＮ［１］およびＩＩＳ＿ＭＳＮ［２］の表記を使用して、ＩＩＳ＿ＭＳＮコンポーネントを実行している２つのマシンがあること示す。
【０４２９】
ＢＩＧ展開ツールは、入力として、ＳＤＵ、ＳＤＵマッピング、データセンタ記述子、（ユーザによって提供された）展開設定を受け取り、展開記述子を生成する。この例では、展開記述子は展開を指定する。これは、展開記述子を実行することにより、ソフトウェアがターゲットサーバ上にインストール／スケール拡張／再構成／アンインストールされるようになることを意味する。
【０４３０】
展開記述子のテキストにおいて詳述するように、ＭｙＷｅｂ（ＭｙＷｅｂ［１］）のインスタンスがサーバＩＩＳ＿ＭＳＮ［１］上にインストールされ、ＭｙＷｅｂ［２］がサーバＩＩＳ＿ＭＳＮ［２］上にインストールされ、ＭｙＤＢ［１］がサーバＳＱＬ＿ＭＳＮ［１］上にインストールされることになる。ＩＰアドレスまたはＡｐｐ＿Ｐｏｏｌ＿ＩＤなどの展開時設定が、アプリケーション運用者によって提供される。この展開記述子は、それが依存するファイルが存在するという条件付きで、再使用することができることに留意されたい。
【０４３１】
稼動段階
スケール拡張［縮小］シナリオ
既に稼動中のアプリケーションについて、スケール拡張［縮小］シナリオにより、アプリケーション運用者が、コンポーネント、ポート、またはワイヤを追加［削除］することが可能になる。この特徴の有用性の例は、Ｊｏｅ＿ＭｉｌｌｉｏｎａｉｒｅのＷｅｂサイトがトラフィックの劇的な増加を経験し、通常のＴＶシーズンの間だけスケール拡張し、その後（または毎晩）スケール縮小することを望むことであろう。
【０４３２】
アプリケーションスケール拡張［縮小］に関する流れ図では、以下が重要な点である。
スケール拡張［縮小］は、インストールのサブセットである。
アプリケーション運用者は、稼動中のＳＤＭアプリケーションを選択し、以下を行うことができる。すなわち、
コンポーネント、ポート、ワイヤを追加し、展開設定を入力する。
コンポーネント、ポート、およびワイヤを削除する。
【０４３３】
シナリオは、以前に生成されたか、または変更された展開記述子から実行することができる。（同じデータセンタ記述子／ＬＩＭを有する前述の注意事項と、アプリケーションに対するアクセスを、ＳＤＭランタイムが依然としてアプリケーションを登録しているという条件付きで。）図５６は、例示的なスケール拡張シナリオを示している。
【０４３４】
トポロジ再構成シナリオ
トポロジ再構成により、アプリケーション運用者が、アンインストール、再インストールを行うことなく、実行中のアプリケーションを再配線する（ｒｅｗｉｒｅ）ことが可能になる。再配線の例は、フロントエンドデータベースをこれから新たなバックエンドデータベースにポイントするように変更することであろう。
【０４３５】
トポロジ再構成における重要な点は、以下のとおりである。
このシナリオは、アンインストール、再インストールなしに既存のポートおよびワイヤの編集を可能にすることで、スケール拡張とは異なる。
このシナリオは、可能性としてユーザが、２つの異なるＳＤＭアプリケーションの「橋渡しをする（ｂｒｉｄｇｅ）」することができるようにする。
【０４３６】
図５７は、例示的なトポロジ再構成シナリオを示している。
トポロジ再構成は、アプリケーション全体を再展開することを望まない障害のケースにおいて有用である。例として、Ｐａｓｓｐｏｒｔが、バックエンド上にすべてのクレジットカード番号を格納しており、ＩＩＳフロントエンドを通して利用可能になされる。フロントエンドに障害が生じ、データを再展開／移動することを望まない。代わりに、新たなフロントエンド（通常のインストールの一環として）を展開し、Ｐａｓｓｐｏｒｔデータベースに新たなフロントエンドを再配線する。
【０４３７】
トポロジ再構成を使用して橋渡しを行う例は、ｂｅｔａ＿ＭＳＮ１０アプリケーションがＭＳＮ９アプリケーションのデータベースを共用したいと望む場合であろう。アプリケーション運用者は、ｂｅｔａ＿ＭＳＮ１０を通常どおり展開する。すると、ｂｅｔａ＿ＭＳＮ１０のフロントエンドは、ＭＳＮ９のデータベースと対話する必要があり、ＭＳＮ９のデータベースについて再構成（および新たなワイヤ）を要求する。
【０４３８】
アンインストールのシナリオ
アンインストールのシナリオでは、アプリケーション運用者がアプリケーションを選択し、すべての実行中のインスタンスが削除され、ランタイムが更新される。ユーザは、アンインストールするインスタンスそのものを選択しない。というのは、スケール縮小シナリオを通じてそれを行うことが可能だからである。
【０４３９】
以下の点が、アンインストールのシナリオに関して重要である。
アンインストールは、既存の（可能性として編集されている）展開記述子を通して行うことができる。
ユーザがアンインストールするべきアプリケーションを選択し、すべてのインスタンスが削除される。
ステートフルコンテンツは、既存の手段を通じてこのツールの外部で破棄されなければならない。
図５８は、例示的なアンインストールのシナリオを示している。
【０４４０】
管理
以下のセクションは、データセンタおよび分散アプリケーションが展開された後のこれらの管理を対象としている。モデルベースの管理ツールをまず、説明し、次に、イントロスペクション／追跡メカニズムおよびオペレーションロジックの説明を行う。
【０４４１】
モデルベースの管理
モデルベースの管理（またはオペレーションロジック）は、アプリケーションのＳＤＭベースのモデルにおける運用者の定義、ならびにアプリケーション開発者の意図およびポリシーに基づいて物理環境からのイベントトリガを受け入れ、モデルのコンテキストにおいて一連のタスクまたは処理をアクティブ化し、統合する処理であり、変化を生じさせ、モデルと物理世界の間の整合性を提供する。
【０４４２】
トリガ、要求、または他のしきい値は、ＳＤＭにおける特定のインスタンスを対象とするイベントである。コンポーネントインスタンスが、トリガを受け取り、ＳＤＭにて表現される全体的なアプリケーションおよびハードウェアの環境のコンテキストにおいて自らに関する他の詳細に基づき、トリガによって特定された問題に対処する一続きのステップを開始することになる。これはアプリケーションのコンテキストであり、ＳＤＭからのリソースであり、サービスのオペレーションスタッフにより一層の管理能力を提供するその豊かさおよび能力をこの自動化に与えている。
【０４４３】
図５９は、オペレーションロジックまたはモデルベースの管理と呼ばれるモデル（ＢＩＧ）および管理要素に関する全体的なアーキテクチャである。全体的なアーキテクチャにおける処理の提案される流れを要約すると、以下のとおりである。
●アプリケーション開発者が、新しいアプリケーションの集約モデル（ＳＤＭ）、またはエンドユーザアプリケーションまたはサービスを構成することになるコンポーネントタイプのクラスを定義することができることになる。
●開発者、またはオペレーション開発者がオペレーションに関するポリシーおよびガイドラインと共にモデルの中のコンポーネントタイプに注釈を付けることにより、実行されなければならないサーバの最低数の設定などの「運用者の意図」をモデルに追加することもできる。
●アプリケーションの特定の実装に関して実装されたインスタンスのＳＤＭランタイムまたはユニットモデルが、ユニットモデル内に保持されることになる。各マシンの所望の状態を保持するインスタンスと物理マシンの間に１対１の対応関係がある。
●ＢＩＧのリソースマネージャは、ユニットモデルと協働して、サーバの物理世界の変化を実装する。
●各サーバは、部分的にＢＩＧによって管理され、部分的に、運用者によってモデルの外部で管理されることが可能になる。
●集約モデルとユニットモデルの間には、モデルを通して物理マシンに対する変化を統合し、運用者の意図を実装する１つのタイプのモデルベースの処理がある。
●別のタイプのモデルベースの処理は、反対方向に流れ、物理空間とモデルの間の整合性を提供する。
●管理エリアにおいて、監視システムが、イベントを収集し、イベントを警報にグループ化する。
●イベントおよび警報にサブスクライブしているコンポーネントに、重要なイベントの通知が行われる。イベント情報は、関係するランタイムＳＤＭユニットまたはインスタンスについての情報とともにサブスクライブしているコンポーネントに送られ、モデルに対するマッピングが提供される。
●イベントがオペレーション上のトリガである場合、イベントは、一続きの統合されたオペレーションタスクを通して物理マシンに変化を生じさせることができるモデルベースの処理をトリガすることになる。
【０４４４】
図６０は、代表的な管理レイヤを示している。これは、集約モデルがＳＤＭに対応し、ユニットモデルがＳＤＭインスタンス空間に対応するように水平方向に回転された前述の全体的アーキテクチャ図のモデルセクションの拡大図である。全体リソースマネージャが、個々のリソースマネージャ（ファクトリとも呼ばれる）に対する要求を管理している。
【０４４５】
イントロスペクション／追跡メカニズム
ユーザ要求、ハードウェアトリガ、またはハードウェアしきい値に達したことなどのトリガが与えられると、適切なオペレーション上のプロセスがアクティブ化される。オペレーション上のプロセスは、実行されることになる１組のオペレーションタスクである。オペレーション上のタスクの実行は、統合による処理を必要とする。というのは、各タスクが、存続期間が長い（ｌｏｎｇ−ｌｉｖｅ）トランザクションである可能性があり、次のタスクの前に開始および完了を必要とするトランザクションだからである。この一続きの活動を監督してオペレーション上のプロセスを実行するエンジンが、オペレーションロジックのための統合エンジンである。
【０４４６】
分散されている可能性があるサーバまたはハードウェアリソース上の一続きのオペレーション上のタスクに統合を適用することは、ユニークなアプローチである。オペレーションロジックのこれらのプロパティにより、トランザクション処理に対してより高度なアプローチがなされる。
●長い存続期間−オペレーション上のプロセスは、数日または数ヶ月などの長期間にわたって実行されることがある。
●非同期−トリガ、またはイベントが、トランザクションまたはプロセスを開始することがあるが、他のイベントを処理するのにトリガされたタスクが完了するまで待つことができない。
●トランザクション式（ｔｒａｎｓａｃｔｅｄ）−オペレーション上のプロセスにおけるステップは、プロセスを開始するか、または送るエージェント、処理を受け取り、処理するエージェント、ならびにタスクが失敗した場合に変更をバックアウト（ｂａｃｋ−ｏｕｔ）する補正プロセスを有する動作である。
●永続的−オペレーションプロセスは、ダメージを受けたり、または不安定になったりすることなく長期間、続くことができる必要がある。
●高い可用性−可用性の高いＢＩＧコンピュータおよびサービスのオペレーション上のプロセスのために可能な限り可用性の高い信頼性が要件である。
【０４４７】
オペレーションロジックは、オペレーション開発者およびアプリケーション開発者に、ＢＩＧ環境におけるトリガに基づいて一続きのオペレーション動作を成文化し、標準化する機会を提供することになる。トリガが生じると、関連する一続きのタスクがアクティブ化される。特定の状況に関するステップには、個別のマシンに対するコマンド、アプリケーションコンポーネントインスタンスの変更、あるいはモデルのステップもしくは人間によるステップの変更が含まれることがある。各ステップは、開始と終了を有するトランザクションであり、成功したり、または失敗したりすることがある。統合エンジンを使用して、これらのタスクをステップスルー（ｓｔｅｐ  ｔｈｒｏｕｇｈ）することにより、プロセスが管理され、追跡され、プロセスについての報告が行われることになる。統合エンジンは、タスクを開始し、タスクの進行を監視し、タスクの完了または失敗を認識する。また、統合により、オペレーションプロセスがどのように定義されているかに応じて、部分的障害、または完全な障害の場合に代替の動作を行うことも可能になる。図６１を参照されたい。
【０４４８】
リソースマネージャ
リソースマネージャは、分散コンピューティングシステム内で論理リソースおよび物理リソースを割り振る責を担う。リソースマネージャは、利用可能なハードウェアを検出し、リソース割り振り要求を処理し、論理リソースおよび物理リソースの所有権を追跡する。リソースの動的プールに対するインターフェースを提供することにより、リソースマネージャは、サーバ内の可用性およびスケーラビリティのための基盤を提供する。
【０４４９】
リソースマネージャは、コンピュータおよびスイッチなどのネットワークデバイスを両方ともに含む分散コンピューティングシステム内のすべてのハードウェアを所有し、制御する。システムにおけるハードウェアリソースに対するアクセスは、リソースマネージャを通して制御される。さらに、リソースマネージャは、負荷分散グループなどの論理リソースを制御するための基本メカニズムを提供する。
【０４５０】
リソースマネージャは、システム内のすべてのリソース管理のための共通ＡＰＩを提供する。サービスおよびランタイムが、リソースマネージャＡＰＩを通じて対話して、リソース照会を行い、リソースを割り振り、リソース要件を変更し、リソースを解放する。
【０４５１】
ＢＩＧリソースマネージャ
序論
特徴の概要
ＢＩＧは、分散サービスランタイム、共通ハードウェアリファレンスプラットフォーム、およびリソースマネージャを定義する。分散サービスランタイムは、スケルトンがサービスコンポーネント、それらの相互関係、ならびにスケーラビリティおよび可用性ポリシーのための実行環境をオペレーションロジックの形態で定義するサービスを提供する。ハードウェアリファレンスプラットフォームは、１つから数千のコンピュータの範囲のシステム上でサービスを稼動することを可能にする共通ハードウェア構造を定義する。
【０４５２】
ＢＩＧリソースマネージャは、ＢＩＧコンピュータ内で論理リソースおよび物理リソースを割り振る責を担う。リソースマネージャは、利用可能なハードウェアを発見し、リソース割り振り要求を処理し、論理リソースおよび物理リソースの所有権を追跡する。リソースの動的プールに対するインターフェースを提供することにより、リソースマネージャは、ＢＩＧマシン内の可用性およびスケーラビリティのための基盤を提供する。
【０４５３】
本明細書は、ＢＩＧリソースマネージャの目標、アーキテクチャ、および実装について記述している。第１章は、目標、および駆動（ｄｒｉｖｉｎｇ）シナリオを説明している。第２章は、リソースマネージャ、およびその関連するリソースプロバイダのアーキテクチャについて記述している。第３章は、実装の詳細、およびＡＰＩについて記述している。
【０４５４】
説明
ＢＩＧリソースマネージャは、ＢＩＧコンピュータ内のリソースの割り振り、および使用の管理を担う。ＢＩＧリソースマネージャは、コンピュータおよびスイッチなどのネットワークデバイスを両方とも含むＢＩＧコンピュータ内のすべてのハードウェアを所有し、制御する。ＢＩＧコンピュータ内のハードウェアリソースに対するアクセスは、リソースマネージャを通じて制御される。さらに、リソースマネージャは、負荷分散グループなどの論理リソースを制御するための基本メカニズムを提供する。
【０４５５】
ＢＩＧリソースマネージャは、ＢＩＧコンピュータ内部のすべてのリソース管理のための共通ＡＰＩを提供する。サービスおよびＢＩＧランタイムは、リソースマネージャＡＰＩを通じて対話して、リソース照会を行い、リソースを割り振り、リソース要件を変更し、リソースを解放する。
【０４５６】
リソースプロバイダ
リソースマネージャは、リソース管理に対する共通インターフェースを提供するが、実際のリソースの知識は、１組のリソースプロバイダに由来する。リソースプロバイダは、特定のクラスのリソースの存在および管理について特定の知識を有する。例えば、ネットワークリソースプロバイダは、ＶＬＡＮの存在、およびＶＬＡＮを管理することの詳細について知っている。ＢＩＧにおける他のリソースプロバイダには、物理デバイスプロバイダ、ＩＩＳ  ＶＲｏｏｔプロバイダ、ＳＱＬデータベースプロバイダ、ＣＬＲ  ＡｐｐＤｏｍａｉｎプロバイダ、およびＷｉｎ３２サーフェイスリソースプロバイダが含まれる。
【０４５７】
リソースプロバイダは、リソース特有の知識によりリソースマネージャを拡張する。リソースプロバイダは、リソース特有の要求を共通の照会フォーマットに変換することを管理する。リソースプロバイダは、プロバイダヘルパＤＬＬを通してリソース特有の構成ＡＰＩによりリソースマネージャＡＰＩを拡張する。最後に、リソースプロバイダは、リソースマネージャデータストアに適切な状態を追加して、リソース特有の情報の追跡を可能にする。より高いレベルのリソースプロバイダが、より低いレベルのリソースプロバイダの上に築かれている。例えば、ＩＩＳ  ＶＲｏｏｔリソースプロバイダは、物理デバイスリソースプロバイダを通してマシンを割り振る。リソースプロバイダの階層化により、冗長性が最小限に抑えられ、リソース管理の均一性が高まる。
【０４５８】
Ｗｉｎｄｏｗｓ（登録商標）のＩ／Ｏ管理システムとＢＩＧのリソース管理システムの間の強い類似性を示すことができる。Ｗｉｎｄｏｗｓ（登録商標）Ｉ／Ｏマネージャと同様に、ＢＩＧリソースマネージャは、共通ＡＰＩ、リソースアクセス制御のための共通ロジック、共通リソース追跡、および様々な１組のプロバイダに要求を通す（ｗａｌｋ  ｔｈｒｏｕｇｈ）ための共通メカニズムを提供する。Ｗｉｎｄｏｗｓ（登録商標）デバイスドライバと同様に、ＢＩＧリソースプロバイダは、別個のクラスのリソースを制御するための特定の知識を使用して管理システムを拡張する。ＢＩＧリソースマネージャは、Ｗｉｎｄｏｗｓ（登録商標）Ｉ／Ｏマネージャと同様に、共通の傘（ｕｍｂｒｅｌｌａ）の下で多様なリソースを統一するためのモデルを提供する。
【０４５９】
自動リソース管理および最適化
ＢＩＧリソースマネージャは、リソースに関するコンポーネントの割り振り、および配置に直接関与することからデータセンタ運用者を解放する。例えば、ＢＩＧコンピュータに新たなサービスをインストールするとき、運用者は、どのコンピュータにサービスを配置するかを決める必要がない。運用者は、サービスにリソース割当量（ｒｅｓｏｕｒｃｅ  ｑｕｏｔａ）を与えるだけでよい。つまり、リソースマネージャが、コアネットワーク帯域幅などの限られた共用リソースを節約するためにＢＩＧコンピュータ内でサービスをどのように最適に配置するかを決める。
【０４６０】
信頼されるリソースプロバイダの基本セットは、リソースマネージャとともにコンポーネント配置の最適化に参加する。リソースプロバイダは、リソースマネージャに配置選択、およびプロバイダ特有の相対コスト選好を提供することにより、配置最適化に参加する。リソースマネージャは、グローバルな関心事と各リソースプロバイダのローカルな関心事のバランスをとって効率を最大化し、リソース使用率を最小限に抑える。
【０４６１】
最適なコンポーネント配置は、継続する関心事である。時間の経過とともに、個々のサービスのリソースニーズは、縮減し、増大する。利用可能な物理リソースは、新たな機器がＢＩＧコンピュータに追加され、より古い機器が撤去されるにつれて変化する。リソースマネージャは、配置決定を定期的に再検討し、コンポーネントを移動することの利点を評価する。リソースプロバイダは、コンポーネントを移動することのコストをリソースマネージャに提供することによって配置の再評価に参加する。移動コストは、移動できないストアに関する無限大から、状態のないＩＩＳコンポーネントに関する極めて小さいコストまでの幅を持たせることができる。
【０４６２】
ＢＩＧリソースマネージャは、リソースの割り振りおよびコンポーネントの配置に関して気を配ることから運用者を解放する。また、リソースマネージャは、複雑な割り振りロジックを書く必要性から開発者を解放する。つまり、開発者は、代わりに単にリソース要件のグラフをリソースマネージャに提供する。リソースマネージャは、ローカルなリソース要件とグローバルなリソース要件をともに考慮に入れて、ＢＩＧコンピュータ内でコンポーネントを最適に配置する。
【０４６３】
特徴の説明
実行環境
ＢＩＧリソースマネージャは、可用性の高いＳＱＬによって支えられたＣＬＲ管理サービスとして実行される。各ＢＩＧマシンは、ＨＡ  ＳＱＬクラスタにおけるＳＱＬサーバのペアにわたって複製された単一のリソースマネージャだけを有することが見込まれている。
【０４６４】
ＢＩＧリソースプロバイダは、ＢＩＧリソースマネージャプロセス内で実行される。リソースマネージャは、リソースプロバイダに動作すべき非同期の実行環境、およびリソースプロバイダが自らの状態を格納する共用データベースを与える。すべてのリソースプロバイダは、ＢＩＧオペレーションロジックモデルを使用するＣＬＲ管理コードであることが見込まれている。
【０４６５】
すべてのリソースプロバイダは、自らの状態をリソースマネージャデータベースに保持する。リソースプロバイダは、自らの管理要件を満たすために必要に応じて自身のテーブルを作成することができる。
【０４６６】
リソースマネージャデータベース内のリソースプロバイダの状態には、権限がある。そのため、例えば、ＩＩＳメタベースは、リソースマネージャデータベースにおいてデータのキャッシュである。リソースマネージャデータベース内に対応するエントリのない状態でＩＩＳ  ＶＲｏｏｔエントリがＩＩＳメタベースで見つかった場合、メタベースのＶＲｏｏｔは削除される。
【０４６７】
すべてのリソース割り振り要求およびリソース割り振り解除要求が、トランザクション内で統一される。リソースプロバイダはリソースマネージャデータベースだけを使用するリソースマネージャプロセス内で排他的に実行される。プロバイダに跨るリソース要求は、集約されていても、決定論的に分散されていない形で実行される。これにより、リソースプロバイダの設計および実装が大幅に単純化され、リソースが障害のシナリオにおいて決してサーバ間で失われることがないことを確実にする。
【０４６８】
ＢＩＧリソースマネージャは、リソース割り振りとリソース初期化を２つの異なる別個の動作に分ける。リソース割り振りは、リソースマネージャプロセス内で排他的に実行される分散されていない決定論的な操作である。他方、リソース初期化は、本来的に分散型の非決定論的なプロセスである。
【０４６９】
リソース割り振りには、通常、コンポーネントがインスタンス化され、ワイヤに接続され、必要に応じてリソース要件により属性付けされる深さ優先（ｄｅｐｔｈ−ｆｉｒｓｔ）オペレーションロジック段階によって前置きされる。
【０４７０】
リソース初期化からコンポーネントインスタンス化およびリソース割り振りを分離することにより、ＢＩＧランタイムおよびＢＩＧサービスは、リソースが初期化を完了していないために利用できないか、またはリソースが存在していたデバイスが消えたために利用できないかにかかわらず、共通のエラー処理メカニズムを使用することができる。リソース初期化は、通常、リソースマネージャデータベースまたはＳＤＭデータベースのようなＨＡ  ＳＱＬストアに状態を保存する状態マシンによって駆動されることになる。
【０４７１】
リソースプロバイダ
ＢＩＧリソースマネージャは、ＢＩＧコンピュータにおけるすべてのリソースを所有する。リソース特有のリソースプロバイダを通して、リソースマネージャは、個別のクラスのリソースに特有の知識により拡張される。リソースマネージャは、集約リソースオペレーションのストレージ、管理を提供し、リソースプロバイダのホストとして働く。
【０４７２】
ＢＩＧリソースマネージャは、限られた数のリソースプロバイダを通じて小さい特定の１組のリソースを提供する。数は少ないが、リソースプロバイダの基本セットは、ターゲットとなる顧客のすべてではないにしても、ほとんどの要件をカバーすることになること
が見込まれる。以下のリソースプロバイダが、最初の製品リリースにおいて見込まれている。
◆物理リソースプロバイダ（そのままのデバイス）
◆ネットワークリソースプロバイダ（ＶＬＡＮ）
◆外部リソースプロバイダ（ＤＮＳ名、外部ＩＰアドレス）
◆ＩＰ負荷分散グループリソースプロバイダ
◆ＩＩＳ  ＶＲｏｏｔリソースプロバイダ
◆ＳＱＬ  ＤＢリソースプロバイダ
◆ＣＬＲ  ＡｐｐＤｏｍａｉｎリソースプロバイダ
◆Ｗｉｎ３２サーフェイスリソースプロバイダ（Ｗｉｎ３２プログラム）
【０４７３】
作成パターン
通常リソース管理は、ＣＬＲ管理コード実行としてパッケージ化されたオペレーションロジックによって駆動されることになる。オペレーションロジックは、ＣＬＲ管理オブジェクトがターゲットコンポーネントを表わす「実体のないオブジェクト（ｄｉｓｅｍｂｏｄｉｅｄ  ｏｂｊｅｃｔ）」パターンに対して書き込まれる。この実体のないオブジェクトは、コンポーネントによって必要とされるあらゆる論理リソースまたは物理リソースの割り振り、そのリソースの初期化、ならびに、そのコンポーネントがもはや必要とされなくなったときに、最終的にそのリソースを解体し、解放する責を担う。
【０４７４】
以下のようなコール、により、実体のないオブジェクト、ランタイムデータベースにおけるコンポーネントインスタンスレコードを有するＣＬＲクラスの作成がもたらされるが、それ以上は何も作成されない。
FrontEnd f ＝ new FrontEnd()；   // 実体のないオブジェクトをインスタンス化
オペレーションロジックは、ＦｒｏｎｔＥｎｄ  ｆとやりとりして、スケーリング要件のようなパラメータを設定する。
【０４７５】
実体のないオブジェクト、このケースではＦｒｏｎｔＥｎｄ  ｆは、所望のリソースのグラフの要求に応答することによってあらゆるリソース割り振りに関与し、リソースの後の設定にも関与する。
r ＝ f.GetResourceGraph()；            // 論理リソース要求グラフの作成を依頼（複合であれば、再帰的に）
rgo ＝ BigAllocateResources(rgi)；      // リソースマネージャにグローバル割り当て要求を依頼
f.SetResources(rgo)；                 // 実際に割り当てられたリソースを通知（複合であれば、再帰的に）
実体のないオブジェクトは、例えば、ディスクをフォーマットすることやイメージをおくことのような、すべてのオブジェクト初期化を指示する。
f.BeginConstruct()；    // ステートマシンの構築／初期化を開始
f.EndConstruct()；      // 構築が終了したときに結果を取得（これは、正に.NET非同期パターン）
さらに、実体のないオブジェクトの存続期間は、実体のないオブジェクトが破棄を指示している代表されたオブジェクトの存続期間を超える。前の説明は、オブジェクト休止（ｑｕｉｅｓｃｅｎｃｅ）を禁止しない。
f.BeginDestruct()；     // ステートマシンの消滅を開始
f.EndDesctruct()；      // 消滅が終了したとき結果を取得
また、実体のないオブジェクトは、リソースを解放する。
f.ReleaseResources()；
その後、実体のないオブジェクトは、破棄することができる。
f ＝ null；
留意すべきいくつかの事項がある。ｆは、実体のないオブジェクトであり、リソース割り振りは、リソース初期化／構築とは異なるため、以下の行はすべて、単一の決定論的なトランザクションに入れることができる。ＲＭ  ＤＢがＳＤＭ  ＤＢと同じＳＱＬにあるという条件付きで、非分散型のトランザクションとさえすることができる。
BeginTransaction()；
FrontEnd f ＝ new FrontEnd；
r ＝ f.GetResourceGraph()；          // 論理リソース要求グラフの作成を依頼
rgo ＝ BigAllocateResources(rgi)；    // リソースマネージャにグローバル割り当て要求を依頼
f.SetResources(rgo)；               // 実際に割り当てられたリソースを通知
EndTransaction()；
すべてのリソースプロバイダは、何らかの時点で、分散オペレーションを呼び出すことになるが、ＢｉｇＡｌｌｏｃａｔｅＲｅｓｏｕｒｃｅｓ（）コール期間中には行われない。ある所与のリソースプロバイダの実装により、それ自体のＳＤＭモデル化サービスを通じて分散コードを活用することができる。
【０４７６】
配置最適化
先ず、この説明の関連において、配置最適化に関して以下の用語を定義したい。
Ｉ．ローカル最適化：単一のコンポーネントファクトリに孤立した最適化。含みとして、他のコンポーネントファクトリ内の配置に関する効果を無視する。
ＩＩ．集約された最適化：複数のコンポーネントファクトリを考慮に入れた最適化。例えば、ＩＩＳアプリケーションとＳＱＬデータベースの両方の配置を考慮する最適化。
ＩＩＩ．グローバル最適化：システム全体、すなわち、ＢＩＧコンピュータのアプリケーションのすべての最適化（既存のコンポーネントの移動を含む）。グローバル最適化は、主に既存のコンポーネントを移動するオプションを有しているので、集約最適化とは異なる。
【０４７７】
立場の誤解がなければ、以下のことに同意されるものと思われる。
Ｉ．ＢＩＧ  Ｖ１は、集約された割り振りＡＰＩを提供すべきである。集約された割り振りＡＰＩは、ＳＡＭにおけるコンポーネントインスタンスおよびワイヤインスタンス上の構成パラメータを有するコンポーネントインスタンスおよびワイヤインスタンスの集合を引数として受け取る。単一のトランザクションにおいて、集約された割り振りＡＰＩは、コンポーネントファクトリをコールして必要なリソースを予約する。（注：割り振りは、異なるコンポーネントファクトリを含む可能性があることを強調するために、一括ではなく、集約という用語を特に使用した。この点について、「集約され最適化された割り振りＡＰＩ」とは言っていないことに留意されたい。）
ＩＩ．長期的には、ＢＩＧは、グローバル配置最適化すべきである。グローバル配置最適化の目標は、あるプロパティを最適化するようにＢＩＧマシン内のコンポーネントインスタンスの配置を再構成することであり、主要なプロパティは、ＢＩＧマシンの共用リソースの使用法である。
ＩＩＩ．集約された配置最適化は、初期割り振りにて行われるか、または制御されたアプリケーション同意により、後にグローバル最適化の形態をとることができる。配置を実行する最も簡単な時は、コンポーネントインスタンスが最初に割り振られるときである。
ＩＶ．初期配置の後のコンポーネントの移動は、非常に高いコストがかかるか、または法外に高価になることさえある。大型のＳＱＬバックエンドを移動することは、極めて高いコストがかかり、アプリケーションの可用性を深刻に損なう可能性がある。コンポーネントの移動については、アプリケーションの望みを検討すべきである。
Ｖ．長期稼動中のアプリケーションでは、コンポーネントの移動は、グローバル配置最適化を使用しなくても、不可避となる。ハードウェアが予期せずに障害を生じる可能性がある。ハードウェアは、通常の減価償却およびライフサイクル制約により、確実に撤去されることになる。これは、どの長期稼動中のアプリケーションも、究極的には、コンポーネントを移動するための何らかのメカニズムを必要とすることを含意している。それらのメカニズムがグローバル配置最適化によって活用されるかどうかは、その存在に対して直交関係にある（ｏｒｔｈｏｇｏｎａｌ  ｔｏ  ｔｈｅ  ｅｘｉｓｔｅｎｃｅ）。
ＶＩ．長期稼動中のアプリケーションは、アップグレードのために何らかの形態の移行をサポートすることになる。例えば、ローリングアップグレードのためのメカニズムが、グローバル配置最適化によって活用される可能性がある。例えば、アプリケーションのローリングアップグレードポリシーが、新たなフロントエンドをオンラインにし、古いフロントエンドを撤去することである場合、新たなフロントエンドのその割り振りが、そのフロントエンドの配置を最適化するための理想的な時である。アップグレードは、グローバル配置最適化のためのよい機会を提供する。
【０４７８】
チームの他の者からのフィードバックに基づき、ＢＩＧ  Ｖ１について以下のことを提案する。
１）ＢＩＧ  Ｖ１は、一括割り振りＡＰＩを提供する。一括ＡＰＩは、ＳＡＭにおけるコンポーネントインスタンスおよびワイヤインスタンス上の構成パラメータを有するコンポーネントインスタンスおよびワイヤインスタンスの集合を引数として受け取る。単一のトランザクションにおいて、一括ＡＰＩは、コンポーネントファクトリをコールして必要なリソースを予約する。
２）ＢＩＧ  Ｖ１は、コンポーネントの移動を定式化する。最低限、定式化は、コンポーネントをオフラインにし、別の場所に戻すための標準のコンポーネントインターフェースを含むべきである。ＩＳｅｒｉａｌｉｚｅのコンポーネント等価物と考えられたい。この定式化は、オペレーションロジックによって、ローリングアップグレードを行うこと、およびフロントエンド全体のクローンを作成することに使用される。また、この定式化は、ＳＱＬバックエンドを区画化するために使用される可能もある。ハードウェアを撤去する際などに使用されるであろう。移動可能なコンポーネントという概念、異なるタイプのコンポーネントを移動することの意味、コストをどのように計算するか等がなければならない。
３）ＢＩＧ  Ｖ１は、集約された配置オプティマイザ（ｏｐｔｉｍｉｚｅｒ）を提供する。オプティマイザの複雑さは、開発サイクルのニーズを満たすように調整される。これは、単純にそのままのクラスタ化オプティマイザとすることもできるし、はるかに高度なものとすることができる。
４）初期配置期間中に、集約された配置オプティマイザが、一括割り振りＡＰＩによって使用される。コンポーネントファクトリは、配置オプティマイザと協働して、その決定を支援する。
５）アプリケーションの存続期間を通じて、集約された配置オプティマイザが定期的に呼び出されて、グローバル配置最適化を実行するためにコンポーネントインスタンスを移動することができる。オプティマイザは、アプリケーションによって必然的に提示される機会を活用することができる。また、オプティマイザは、アプリケーションに別の時点でのコンポーネントの移動を考慮するように求めることもできる。基本的に、グローバル最適化は、集約された配置オプティマイザ、および移動可能なコンポーネントの予め存在するサポートを活用することである。
６）ＢＩＧ  Ｖ１  ＩＩＳアプリケーションコンポーネントファクトリが、アプリケーションの許可を条件に移動可能なコンポーネントを実装する。グローバル配置最適化の利点の多くは、ＳＱＬデータベースなどの重いコンポーネントを無視し、ＶＲｏｏｔを移動することによって実現できる可能性が高い。また、ＩＩＳは、ＶＲｏｏｔの移動を容易にする排出（ｄｒａｉｎ）などの操作を必然的にサポートする。実質的に、ＩＩＳ  ＶＲｏｏｔコンポーネントファクタは、コンポーネント移動およびグローバル配置最適化に関するＶ１ポスターチャイルド（ｐｏｓｔｅｒ  ｃｈｉｌｄ）になる。
【０４７９】
物理リソースのモデル化
基礎となるリソース管理システム全体は、ハードウェアリソースグラフである。ハードウェアリソースグラフは、ハードウェアリソースの全体性、およびＢＩＧリソースマネージャが利用できるハードウェアリソースの接続を記述する。ハードウェアリソースグラフは、サーバ、ネットワークデバイス、およびネットワークトポロジを含む。さらに、ハードウェアリソースグラフは、電力グリッドおよび物理包含関係（ｐｈｙｓｉｃａｌ  ｃｏｎｔａｉｎｍｅｎｔ  ｒｅｌａｔｉｏｎｓｈｉｐｓ）に関する情報を収容することができる。
【０４８０】
ハードウェアリソースグラフは、次の３つの基本要素から成る。すなわち、エンティティ、コネクタ、および接続である。
【０４８１】
エンティティは、ソフトウェアによってアクセス可能なハードウェアの基本単位である。エンティティの例には、サーバ、ディスクドライブ、ネットワークデバイス等が含まれる。
【０４８２】
コネクタは、エンティティに対する物理インターフェースである。コネクタは、常に正確に１つのエンティティに関連している。コネクタの例には、ネットワークインターフェース、ＩＤＥインターフェース、ＡＣ電源コネクタ、および物理コンテナシップ（ｃｏｎｔａｉｎｅｒｓｈｉｐ）等が含まれる。
【０４８３】
接続は、正確に２つのコネクタの間の物理関係である。接続の例には、ネットワークケーブル、ＩＤＥケーブル、ＡＣケーブル等が含まれる。
【０４８４】
３つすべての要素タイプ、エンティティ、コネクタ、および接続が、関連するプロパティを有する。これらのプロパティは、プロパティ名、最大値、および利用可能値から成るタプルである。
【０４８５】
すべての３つの要素タイプは、デュアル（ｄｕａｌ）を有することができる。デュアルは、フェイルオーバ（ｆａｉｌ  ｏｖｅｒ）のために使用されるピアである。要素およびそのデュアルは、常に一緒に割り振られて高い可用性に必要な冗長性を提供する。デュアルの代用的な例には、冗長ネットワーク上のフェイルオーバスイッチ、冗長ＮＩＣ、および冗長ＮＩＣを冗長スイッチに接続するケーブルが含まれる。
【０４８６】
すべてのコネクタは、コネクタごとに許される接続の最大数を指定する基数を有する。例えば、ＩＤＥコネクタは、１つのマスタデバイスと１つのスレーブデバイスという２の基数を有する。図６２を参照されたい。
【０４８７】
基本タイプを定義するための原理は以下のとおりである。
◆基本的なハードウェアプロトコルが何か？  
◆ハードウェアレベルで、デバイスはどの言語を話すか？  
◆基本的なエンティティは、正確に１つの所有者を有する。  
◆コネクタおよび接続カテゴリは、合致しなければならない。  
◆デュアルは、１つとして割り振られなければならないフェイルオーバペアである。  
◆エンティティ、コネクタ、または接続は、デュアルとすることができる。  
【０４８８】
モデル化要素は何か？  
◆エンティティ
◆コネクタ  Ｓｒｃ＝エンティティ
◆接続  Ｓｒｃ＝コネクタ、Ｄｓｔ＝コネクタ
【０４８９】
基本的なカテゴリは何か？  
◆エンティティカテゴリ：
◆Ｘ８６ＰＣ：ソフトウェア／ＣＰＵ／ＲＡＭのやりとりを記述する。ＣＰＵおよびＲＡＭは値である。  
◆ＥＦＩ  ＰＣ：ソフトウェア／ＣＰＵ／ＲＡＭのやりとりを記述する。ＣＰＵおよびＲＡＭは値である。  
◆ネットワークデバイス。ＩＰ＋ＳＮＭＰを話す。製品識別子は値である。  
◆ディスク。セクタの送信および受信を行う。  
◆物理コンテナ
◆コネクタ／接続カテゴリ
◆イーサネット（登録商標）。帯域幅は値である。  
◆ＡＴＡ。帯域幅およびフォーマットは値である。  
◆ＳＣＳＩ。帯域幅およびフォーマットは値である。  
◆電力
◆物理（包含）
◆その他：ＦｉｂｒｅＣｈａｎｎｅｌ、シリアル、パラレル、ＵＳＢ、ＦｉｒｅＷｉｒｅ、８０２．１１、Ｉｎｆｉｎｉｂａｎｄ
【０４９０】
初期物理構成−図６３を参照されたい。
詳細例−図６４および６５を参照されたい。
【０４９１】
場所ベースのデバイス識別子
あらゆるネットワーク化されたデバイスは、ネットワークにおいてその場所の固有識別子を有する。
各レベルにおいて、値＝親スイッチ上のポート番号である。
終了（ｔｅｒｍｉｎａｔｅｄ）レベルは、終了値「＃」を有する。
終了値「＃」は、すべてのポート番号より大きい。
例えば、図６６を参照されたい。
【０４９２】
２つのデバイス間のパスの計算
２つのデバイス（２，０，１）および（２，１，＃）について検討する。
【０４９３】
各デバイスについて、終了プレフィックスを計算する。
(2,0,1) → (#,#,#), (2,#,#), (2,0,#)
(2,1,#) → (#,#,#), (2,#,#)
最も特定的な共通終了プレフィックスは、共通の親である。
(2,#,#)
残りの終了プレフィックスは、名前中間スイッチである。
(2,0,1) → (2,0,#)
(2,1,#) → なし
最終パス：
(2,0,1) から (2,1,#) → (2,0,#), (2,#,#) ＝ ２スイッチホップ ＝ ３スイッチホップ
また、デバイスに最も近いピアを見つけるともトリビアルである。
(2,0,1) → (2,0,？)
(2,1,#) → (2,？,#)
図６７を参照されたい。
【０４９４】
リソース要求のモデル化
ＢＩＧリソースマネージャは、ノード（リソース）およびエッジ（関係）のグラフとしてＢＩＧマシンをモデル化する。ノードとエッジはともに、属性（名前−値のペア）で注釈を付けることができる。
【０４９５】
リソースグラフに対する最も一般的なタイプのクエリの１つは、サブグラフ同型（ｉｓｏｍｏｒｐｈｉｓｍ）である。クライアントは、要求グラフを作成し、ハードウェアリソースグラフ内で同じ形状および同じプロパティを有するサブグラフを見つけ出すようにリソースマネージャに求める。リソースマネージャは、合致するものを見つけ出し、完全に注釈が付けられた応答グラフを戻す。
【０４９６】
サブグラフ同型の一部として、リソースマネージャは、グラフノードを折りたたんだり、または結合したりしては絶対にならない。つまり、要求グラフが２つのＰＣノードを収容する場合、応答グラフは、２つのＰＣ固有ノードを収容していなければならない。
【０４９７】
要求グラフは、ＰＣノードを見つけ出す、または少なくとも２５６ＭＢのＲＡＭを有するＰＣノードを見つけ出すなどの検索パラメータを含むことができる。応答グラフは、合致する要素（ノードとエッジの両方）のそれぞれの特定のＩＤを収容する。
【０４９８】
基本ケースでは、要求グラフは、読み取り専用クエリである。しかし、一般的な最適化は、リソース割り振りの形で読み取り−書き込み操作を可能にする。紙の上に描かれる場合、書き込み動作は、ブラケットでラベル付けされる。
【０４９９】
図６８は、ＰＣ、およびＩＤＥまたはＳＣＳＩなどのストレージトランスポートを通して接続された取り付けディスクを割り振る要求グラフである。ノードは、角のとれた四角形として表わされ、エッジは、属性が明記された四角形が被せられた太線として表わされていることに留意されたい。割り振りの成功により、図６９の応答グラフがもたらされることがある。
【０５００】
駆動シナリオ
ジョーの花屋が、図７０に示されるリソース要求を行う。ＭＳＮは、ジョーが少なくとも５００ＭＨｚのＰＣを得ることを約束する。というのは、ジョーは、「ゴールド」ＳＬＡを有し、ジョーのＰＣは、場所を維持するためにスイッチ５に接続されているからである。図７１に示される追加で、Ｅｘｏｄｕｓは、ＭＳＮが常にラック１７にあるマシンを獲得し、小型ディスクも獲得することを保証する。というのは、ＭＳＮは、「第２」クラスのストレージＳＬＡを有するからである。図７２を参照されたい。
【０５０１】
実装案
class Graph；
class Client
｛
private IResourceMediator mediators[]；
private Object mediatorStates[]；
｝
interface IResourceMediator
｛
public void MediateRequest(ref Graph graph, ref Object state)；
public void MediateReply(ref Graph graph, ref Object state)；
｝
class ResourceManager
｛
public Graph Allocate(Graph request, Client client)
｛
for (int n ＝ 0； n ＜ client.mediators.Length； n++)
｛
client.mediators[n].MediateRequest(ref request,
ref client.mediatorStates[n])；
｝
Graph reply ＝ PrimitveAllocate(request)；
for (int n ＝ client.mediators.Length - 1； n ＞＝ 0； n--)
｛
client.mediators[n].MediateReply(ref reply,
ref client.mediatorStates[n])；
｝
return reply；
｝
private Graph PrimitiveAllocate(Graph request)；
｝
【０５０２】
基本リソース割り振りのシナリオ
このセクションは、いくつかのシナリオをリストする。各シナリオには、対応する要求グラフが含まれている。クエリトランザクションの結果として割り振られることになるノードには、「［Ａｌｌｏｃａｔｅ］」でラベル付けされる。割り振られず、検索をマッチさせるために割り振り解除されなければならないノードには、「［Ｆｒｅｅ］」でラベル付けされる。ブラケットのラベルのないノードは、割り振られておらず、代わりに、残りの要求グラフに関するコンテキストを提供している。
【０５０３】
ＰＣ
Ａｋａｍａｉは、少なくとも１ＧＨｚのＣＰＵ、５１２ＭＢのＲＡＭ、そして１００ＧＢのローカルディスクストレージを有するサーバをＤｉｇｉｘデータセンタにて割り振る必要がある。図７３を参照されたい。
【０５０４】
ＶＬＡＮ
ＭＳＮインスタンスメッセージングは、そのフロントエンドが入っているＤＭＺを実装することを決定した。これを行うため、それには、そのフロントエンドの範囲（ｃｏｖｅｒａｇｅ）を有する２つのＶＬＡＮを必要とする。図７４を参照されたい。
【０５０５】
公開ＩＰアドレスまたはＤＮＳ名
ジョーのＷｅｂサービスは、自身を外の世界に見えるようにする必要がある。ジョーは、ＤＮＳエントリおよびルーティング可能なＩＰアドレスを割り振る必要がある。図７５を参照されたい。
【０５０６】
負荷分散グループ
ジョーのＷｅｂサービスは、単一のＰＣには余りにも大きく成長しすぎた。ジョーは、負荷分散グループおよび別のＰＣを割り振る必要がある。ジョーは、両方のＰＣを負荷分散されたグループの仮想ＩＰアドレスの背後に置く必要がある。図７６を参照されたい。
【０５０７】
パス
Ｈｏｔｍａｉｌは、１つのＵＳｔｏｒｅから別の所へ電子メールアカウントを転送するために８０Ｍｂｐｓのパスを割り振る。Ｈｏｔｍａｉｌは、パスに関して待ち時間およびＱＯＳ要件を指定することもできる。図７７を参照されたい。
【０５０８】
特定のストレージ
Ｈｏｔｍａｉｌは、新たなＵＳｔｏｒｅを作成したいと望む。それには、１０，０００ＲＰＭ以上で回転する少なくとも４セットの共用されないヘッドに跨る１００ＧＢを有するＲａｉｄ１ボックスを要望する。図７８を参照されたい。
【０５０９】
クラスタ（クォーラム（Ｑｕｏｒｕｍ））ストレージ
Ｈｏｔｍａｉｌは、フェイルオーバクラスタとして共用ディスクを有する１対のマシンを割り振ることを望む。それには、１０，０００ＲＰＭ以上で回転する少なくとも４セットの共用されないヘッドに跨る１００ＧＢを有するＲａｉｄ１ボックスを要望する。図７９を参照されたい。
【０５１０】
共用ストレージ
ジョーのＷｅｂサービスは、サービス特有の構成のロールバックイメージを保持するために複数のマシンによって使用可能な５０ＧＢの共通ストレージを必要とする。ストレージは、０ないしＮ個のマシンに利用可能である。図８０を参照されたい。
【０５１１】
割振り配置シナリオ
近接マシン割り振り
Ｈｏｔｍａｉｌは、新たなフロントエンドを割り振る必要がある。それには、バックエンドクラスタに対する十分な帯域幅を有する、その他方のフロントエンドと同じスイッチ上のマシンを見つけ出すことを望む。図８１を参照されたい。
【０５１２】
遠隔マシン割り振り
Ｅｘｐｅｄｉａ顧客プロファイルデータベースは、ＳＱＬレプリケーションのために別のマシンを必要とする。それには、異なるバッテリバックアップユニットによってカバーされたデータセンタの部分に配置されたマシンを望む。図８２を参照されたい。あるいは、場合により、図８３の例を参照されたい。
【０５１３】
待ち時間主導の（ｌａｔｅｎｃｙ  ｄｒｉｖｅｎ）割り振り
Ｈｏｔｍａｉｌバックエンドは、クラスタ調整のためにマシンを割り振る必要がある。マシンは、既にクラスタ内にあるマシンの５ミリ秒の待ち時間の範囲内になければならないが、帯域幅は低い。あるいは、これは、マシンが１ネットワークホップの範囲内にあることを必要とすることによって表わすことも可能である。図８４を参照されたい。
【０５１４】
複合コンポーネントのシーディング（ｓｅｅｄｉｎｇ）
Ｈｏｔｍａｉｌは、間もなく新たな電子メールユニットを作成する。ユニットは、少なくとも５００ＰＣに成長する余裕を持つ単一ホップクラスタ内に割り振られるべきであるが、Ｈｏｔｍａｉｌは、最初、数十のマシンだけしか割り振らない可能性がある。図８５を参照されたい。
【０５１５】
一括割り振り
ＭＳＮ  Ｓｅａｒｃｈは、少量の音楽サンプルに基づいてＭＰ３を検索する能力を追加することを決める。それには、４００ＰＣのブロック、３つの負荷分散装置、および２０ＴＢのストレージを割り振ることを望む。ＭＳＮ  Ｓｅａｒｃｈは、すべてかなしか（ａｌｌ−ｏｒ−ｎｏｔｈｉｎｇ）の割り振りを要望する。図８６を参照されたい。
【０５１６】
取り消しシナリオ
回復
ジョーのＷｅｂサービスが、ＩＤＣに支払いを停止した。ＩＤＣは、ジョーのＷｅｂサービスに割り振られたリソースのすべてを回収し、そのリソースを利用可能なリソースのプールに戻す必要がある。
【０５１７】
ハードウェア存続期間取り消し
Ｅｘｐｅｄｉａのフロントエンドの１つは、そのライフサイクルの終りに達したＰＣである。ＩＤＣのオペレーションロジックによってトリガされて、リソースマネージャは、マシンがＩＤＣに戻されるまでに７２時間あることを、Ｅｘｐｅｄｉａに通知する。
【０５１８】
制御された取り消し
Ｈｏｔｍａｉｌは、そのＵＳｔｏｒｅの大規模な再編のために２０の短期マシンを割り振った。そのＳＬＡに従って、ＩＤＣは、ここで１つのマシンを戻すことを要求している。Ｈｏｔｍａｉｌは、２０のマシンの１つを戻すか、または別の等価のマシンを戻すことができる。
【０５１９】
ＢＩＧ  Ｖｉｓｉｏｎ−以下のことを可能にする：
◆Ｖｉｓｕａｌ  Ｓｔｕｄｉｏ、およびＳＱＬ、ＩＩＳのような再使用可能なビルディングブロックを使用して分散型のスケーラブルな可用性の高いサービスの開発
◆自動的に割り振られ、目的化され、構成される１組の抽象化されたハードウェアリソースおよびソフトウェアリソースにわたる展開
◆オペレーション上の最良の実践を成文化してサービスの可用性および成長を制御することにより自動化を通じて所有コストを低減
◆商品経済を活用する標準化されたデータセンタハードウェアの調達
ＢＩＧサービスプラットフォームアーキテクチャ−図８７を参照
ＢＩＧコンピュータ−ハードウェアリファレンスプラットフォーム
【０５２０】
以下のように設計、試験、およびオペレーションのコストを低減する。
●サポートするハードウェアデバイスの数を限定する。  
●ネットワークトポロジを制約する。  
●ネットワーク構成の自動化を可能にする。  
ＢＩＧ技術展開要件に関する顧客の懸念をなくす。  
●ＰＸＥ、ＤＨＣＰ、ＤＮＳ、ＶＬＡＮ
ＩＰゲートウェイ
◆外部ネットワークと内部ネットワークの間のＩＰトラフィックを仲介する。  
◆ネットワークアドレス変換（ＮＡＴ）、ファイアウォール、負荷分散
インターネットネットワーク
◆ＩＰアドレスおよびＶＬＡＮが、ＢＩＧによって排他的に管理される。  
◆ＶＬＡＮが自動的に構成される。  
ハードウェアビルディングブロック
◆商品サーバ、ネットワークスイッチ、およびディスクの組合せ
【０５２１】
図８８を参照されたい。
【０５２２】
図８９は、ＢＩＧコンピュータ内部に存在することが可能な現行の製品の例である。
【０５２３】
リソース管理の特徴
●サーバ、ストレージ、またはネットワークハードウェアリソースの動的な発見
●（物理および論理）リソースが入っている可用性の高いデータベース
●リソースの列挙、照会、および更新をサポートするランタイムＡＰＩ
●リソースドライバを物理ハードウェアデバイスにバインド化するための論理リソースドライバモデルおよびＡＰＩ
●サーバリソースのプログラマティックな（ｐｒｏｇｒａｍｍａｔｉｃ）割り振り、および割り振り解除
●ＶＬＡＮや負荷分散グループなどのネットワークリソースの自動的な構成および管理
●ブロックベースおよびファイルベースのストレージリソースの動的な構成および管理
●障害検出の監視および通知
リソース管理コンポーネント
●リソースマネージャが、ＢＩＧコンピュータ内部のハードウェアおよびソフトウェアリソースの割り振りを担う。  
◆リソースマネージャが、ＢＩＧランタイムに登録される
◆リソースマネージャは、基本的に、ある所与のリソースタイプに関するファクトリである。  
●ハードウェアリソースマネージャ
◆ハードウェアインスタンスを割り振る責を担う基本レベルファクトリ
●ネットワークリソースマネージャ
◆ＶＡＬＮ、負荷分散グループ、ＩＰアドレス等を割り振る責を担う。  
●ストレージリソースマネージャ
◆ディスクやファイルなどのストレージリソースを管理する。  
●ＰＣリソースマネージャ
◆ターゲットサーバを割り振り、ｉＢＩＧサービスを使用してＯＳを展開する。  
●ソフトウェアリソースマネージャ
◆ＩＩＳ  Ｖｒｏｏｔ、ＳＱＬデータベース、ＡＳＰ．ＮＥＴ等を割り振り、構成する。
【０５２４】
図９０は、様々なリソース管理コンポーネントを示している。
【０５２５】
ハードウェアリソースの発見および管理
プロパティ：電力、ネットワーク、ストレージ、プロセッサ、メモリ、場所
ＢＩＧコンピュータ内部のハードウェアは、自動的に発見される。リソースドライバが、ハードウェアデバイスにバインドされ、ハードウェアリソースマネージャ（ＨＲＭ）に論理リソースを公開する。ＨＲＭは、論理リソース割り振り要求を物理リソースバインド化に変換する。図６３、６４、および６５を参照されたい。
【０５２６】
ＢＩＧコンピュータ内のネットワークリソース管理
ＢＩＧコンピュータは、ネットワークリソースに関する抽象化レイヤを定義する。
【０５２７】
ネットワークリソースマネージャは、ネットワークリソースを割り振り、ＢＩＧコンピュータ内部のネットワークスイッチおよび負荷分散装置をプログラムし、ネットワークリソースドライバとインターフェースをとる。
【０５２８】
ＶＬＡＮは、ＢＩＧコンピュータ内部のネットワークの分離および区画化を提供する。ネットワークリソース例は、ＶＬＡＮ、負荷分散グループ、ネットワークフィルタ、ＩＰアドレス、ＤＮＳ名である。
【０５２９】
ＢＩＧストレージリソース管理要件
●ファイルベースおよびブロックベースのストレージリソースを包含するＢＩＧコンピュータに接続されたストレージのグローバルビュー
●ストレージ相互接続ファブリック（ｆａｂｒｉｃ）の仮想化
●ＬＵＮ、ボリューム、アレイなどのより高いレベルのストレージ抽象化を作成し、管理するためのフレームワーク
●既存および新たなストレージデバイスがＢＩＧコンピュータにプラグインできるようにするドライバ／プロバイダモデル
●ＳＡＮシステムとの相互運用性
インフラストラクチャサービス（自動化された展開サービス（ＡＤＳ））−特徴
●基本展開サービス
◆基本ネットワークブートサービス（ＰＸＥ）およびイメージビルダサービス
◆プレブート（ｐｒｅ−ｂｏｏｔ）ＯＳ環境（ＢＭｏｎｉｔｏｒ）
◆レガシツールサポートのためにネットワークを介してデリバリされる仮想フロッピー（登録商標）
●イメージの展開および管理
◆イメージの作成、編集、および削除を行うためのツール
◆プレＯＳを実行しているシステムに対するイメージの展開
●複数デバイス管理（ＭＤＭ）
◆共通タスクのためのスクリプト
◆展開のための複数のステップおよびプロセスを調整するタスク順序付け
◆完全なプログラマティックインターフェース（ＷＭＩ）
●．ＮＥＴサーバＲＴＭから６０日間で出荷
◆Ｗｉｎｄｏｗｓ（登録商標）２０００および．ＮＥＴサーバターゲットをサポートする。
【０５３０】
図９２は、例示的なＡＤＳアーキテクチャを示している。
【０５３１】
図９３は、例示的なＡＤＳ遠隔ブートおよびイメージングシステムを示している。
【０５３２】
サービス定義モデル（ＳＤＭ）
●サービス全体のプログラマティック記述
◆サービスの宣言的定義
◆サービスの全体的なサービス構造をスケール不変な形で定義する。  
◆展開、管理、およびオペレーションのためのフレームワークを提供する。  
◆コンポーネントベースのモデルが、サービスの要素をモジュラー式に取り込む。  
●ＳＤＭＬは、サービス定義モデルを定義するための宣言的言語である。  
◆コンポーネント、ポート、およびワイヤ
◆タイプ空間、メンバ空間、およびインスタンス空間
◆コンポジションおよびカプセル化をサポートする。  
ＳＤＭ：コンポーネント、ポート、およびワイヤ
●コンポーネントは、実装、展開、およびオペレーションの単位である。  
◆例えば、．ＮＥＴサーバ、ＩＩＳ仮想Ｗｅｂサイト、ＳＱＬデータベースを実行している専用サーバ
◆ポートを通して機能を公開し、ワイヤを通して通信する。  
◆コンポジションによって作成された複合コンポーネント
●ポートは、関連タイプ（プロトコル）を有する名前（サービスアクセスポイント）である。  
◆ＢＩＧは、通信のためにどのようなプロトコルを使用すべきかを指令しない。  
◆プロトコルが、通信を確立するために必要とされる情報を取り込む。  
●ワイヤは、ポート間の許容されるバインド化である。  
◆ワイヤは、ポート間のトポロジ上の関係を宣言する。
【０５３３】
図９４を参照されたい。
【０５３４】
図９５は、ＳＤＭＬ例であるＭｙＳｅｒｖｉｃｅ．ｓｄｍｌを示している。図２８も、このＳＤＭＬ例に関連している。
【０５３５】
サービス展開ユニット（ＳＤＵ）は、アプリケーション／サービスに関するＳＤＭモデル、コンポーネント実装のためのＣＬＲアセンブリ、およびＭＳＩ、ＡＳＰ．ＮＥＴ、ＳＱＬスクリプト、静的コンテンツ等を含め、サービスを構成するすべての部分をカプセル化する。図９６を参照されたい。
【０５３６】
ＳＤＭランタイム
●ＳＤＭランタイムは、ＳＤＭのモデルおよびインスタンスを追跡する責を担う。  
◆ＩＩＳによってホストされるＷｅｂサービスとして実装される。  
◆スケーラビリティのために区画化することができる。  
●ランタイムＡＰＩがＳＯＡＰエンドポイントを公開する。  
◆ランタイムとの通信は、ランタイムライブラリを通じて行われる。  
●可用性の高いＳＤＭストア（Ｙｕｋｏｎの冗長データベース技術を使用）
◆２つのＳＱＬサーバおよび監視（ｗｉｔｎｅｓｓ）サーバ
【０５３７】
図２７を参照されたい
例：コンポーネントインスタンス化
using Microsoft.SDM；
public class MyService:
SDMComponent 
｛
public OnCreate(・・・)      ｛
fe1 ＝ CreateInstance(“fe”, “”)；
be1 ＝ CreateInstance(“be”, “”)；
w1 ＝ CreateWireInstance(“tds”)；
w1.Members.Add(fe1.Ports[“catalog”])；
w1.Members.Add(be1.Ports[“sql”])；
｝
｝
ｍｙｓｅｒｖｉｃｅ．ｃｓは、ＳＤＭ  ＡＰＩを使用するＣ＃コードである。
componenttype MyService 
｛
component MyFrontEnd fe；
component MyBackEnd be；
port http ＝ fe.http；
wire TDS tds ｛
fe.catalog；
be.sql；
｝
implementation “MyService, MyCLRApp”
｝
図３５を参照されたい。
【０５３８】
ＳＤＭランタイムＡＰＩを使用する動的バインド化の例（図９７参照）
１．ｂｅ［１］は、ｓｑｌ［１］ポートの準備ができ、ＤｅｃｌａｒｅＰｏｒｔ（）を使用して、そのポート接続情報をＳＤＭランタイムに登録することを宣言する。
２．ｆｅ［１］が初期化し、カタログ［１］ポートに関するピア情報をＳＤＭランタイムに求め、ＧｅｔＰｅｅｒＰｏｒｔ（）を使用してｓｑｌ［１］に関する情報を受け取る。
３．次に、ｆｅ［１］が、ＳＤＭランタイムによって動的に提供されたポート接続情報を使用してｂｅ［１］に接続する。
【０５３９】
サービス定義モデル（ＳＤＭ）ワークグループ
●ＳＤＭワークグループは、５つのチームから成る。  
◆インディゴ（Ｉｎｄｉｇｏ）
◆ホワイトホース（Ｗｈｉｔｅｈｏｒｓｅ）
◆フュージョン（Ｆｕｓｉｏｎ）
◆マネージメント（Ｍａｎａｇｅｍｅｎｔ）
◆ＢＩＧ
●チャーター（ｃｈａｒｔｅｒ）は、分散型および／または異機種混合のアプリケーションに関するクラスレベルのアプリケーションスキーマを定義するためのものであった。  
◆コンポーネント、ポート、およびワイヤを使用してアプリケーションを記述する。  
◆展開情報、構成情報、および管理情報を含む。  
●ＳＤＭは、フュージョンスキーマおよびマネージメントスキーマ（可能性として、その他のスキーマも）参照する外部スケルトン（ｅｘｏｓｋｅｌｔｏｎ）である。  
◆フュージョンアセンブリが、展開のために参照される（該当する場合）。  
◆ＭＢＵ設定および計測スキーマが、構成および監視のために参照され、指定される。
【０５４０】
ＳＤＭスキーマ（単純化された）
＜sdm＞
＜identity /＞              // 定義のグループを識別
＜porttypes /＞             // ポートの記述
＜wiretypes /＞            // トポロジの記述
＜componenttypes＞        // このライブラリで定義されるコンポーネントのセット
＜componenttype＞   
＜ports /＞          // 通信機能
＜settings /＞        // コンポーネントの構成設定
＜instrumentation /＞  // スキーマのモニタリング
＜deployment /＞     // インストーラタイプ、インストーラ情報、（例、Fusion）
＜components /＞     // コンポジションのサブコンポーネント
＜wires /＞          // ポート間の関係を定義
＜/componentType＞
＜/componenttypes＞
＜/sdm＞
【０５４１】
ＳＤＭおよびフュージョン−図９８を参照
●デフォルトの値を有するローカル設定が、フュージョンマニフェスト（または他のローカルインストール技術）にて指定される。
●ＳＤＭにおける設定が、オペレーションロジックおよびＢＩＧランタイムによって処理される。
◆例：「ユーザ数」を使用してアプリケーションの初期スケール拡張条件が決定されるであろう。
【０５４２】
ＳＤＭおよび展開−図９９参照
スケール不変な形でアプリケーションの構造を記述することは、展開の要件および制約の設計時検証を可能にするために、アプリケーションホスト環境（すなわち、データセンタ）の同様なスケール不変の記述を必要とする。  
◆マイクロソフトおよび顧客は、自身のデータセンタ環境の綿密な記述を描き、その図面を説明するために非常に大量のドキュメントを書くことに多大な労力を費やしている。  
◆それらの図面およびドキュメントは、物理マシン名からＩＰアドレス、ＶＬＡＮ、サーバの役割に至る情報の多くのレイヤをマージして、混乱を招くことの多い１つの包括的な図にする。
【０５４３】
図１００は、例示的なシステムアーキテクチャを示している。
【０５４４】
図１０１は、様々な展開レイヤの例を示している。
【０５４５】
オペレーションロジックは、オペレーションの「ビジネスロジック」である。
【０５４６】
オペレーションロジックは、再使用可能な最良の実践としてエンコードされた反復可能なパターンを取り込むＣＬＲコードである。
◆サービス環境または動作環境に特有ではない。  
◆開発し、試験し、荷することができる。  
◆人々によって実行されることを必要とするマニュアルによる手続きの必要性を減らす。  
オペレーションロジック（ＯｐｓＬｏｇｉｃ）は、サービスの全体的なオペレーションを担う。  
◆サービスを開始すること
◆サービスの成長および縮小
◆アップグレードおよび更新
◆障害の検出および回復
◆データベースの区画化
ＯｐｓＬｏｇｉｃは、ＭＳ中間層技術を使用して実装されることになる。  
◆ＩＩＳ上でホストされるＡＳＰ．ＮＥＴＷｅｂサービス
◆トランザクション調整のためのＤＴＣ
◆ストレージのためのＳＱＬサーバ
◆監視および管理のためのＷＭＩ
◆メッセージングのためのＭＳＭＱ
反復可能なアップグレードパターン→オペレーションロジック
●アップグレードは、ＢＩＧとともに出荷することが望まれる再使用可能なオペレーションロジックテンプレートのタイプの例である。
●インプレース（ｉｎ−ｐｌａｃｅ）アップグレードパターン
◆データを移動するコストは高いか、コードインスタンス化コストが低いか、または予備のリソースがない。  
◆コンポーネントのサービスを停止し、更新を実行し、再びサービスに戻す。  
●横並び（ｓｉｄｅ−ｂｙ−ｓｉｄｅ）アップグレードパターン
◆データを移動するコストが低く、コードインスタンス化のコストが高く、予備のリソースがある。  
◆新たなコンポーネントを作成し、古いコンポーネントのサービスを停止し、データを新たなコンポーネントに移行し、新たなコンポーネントをサービスに入れる。  
●置き換えアップグレードパターン
◆データの移行なし
◆新たなコンポーネントを追加し、古いコンポーネントを除去し、サービスの可用性を維持するよう調整を行う。  
●ローリングアップグレードは、成文化されたアップグレードパターンを再使用することができるより高いレベルのオペレーションロジックの例である。  
◆オペレーションロジックが試験でき、フレームワークがロールバックをサポートする。  
◆ソフトウェアにステップを実行させることにより、実行から人間によるエラーを取り除く。
【０５４７】
オペレーションロジック、ＢＩＧ、およびマイクロソフトプログラミングモデル−図１０２参照
インターネットが、企業アプリケーションを変化させる−より広く公開することにより、コストの増加がもたらされた。図１０３を参照されたい。新たなアーキテクチャは、ハードウェア、人々、および複雑性に起因する敏捷性の低下によって駆動されたコストの増加をもたらした。図１０４を参照されたい。ムーアの法則がディスク密度、ネットワークスループット、および処理能力の劇的な増加など、データセンタ全体に広がっている。
【０５４８】
サービスデリバリ（ｓｅｒｖｉｃｅ  ｄｅｌｉｖｅｒｙ）は、人間集約型（ｐｅｏｐｌｅ−ｉｎｔｅｎｎｓｉｖｅ）であり、人間の関与が、セキュリティ、信頼性、柔軟性、およびコストに影響を与える。図１０５を参照されたい。
【０５４９】
これは、ライフサイクル問題である−顧客の苦痛が、開発段階、展開段階、およびオペレーション段階にわたっている。図１０６を参照されたい。アプリケーションは、ハードウェア構成に結び付いたスケールのことを考えて、管理しやすさのことを考えて、オペレーションのことを考えて、つまり、データセンタにおける要件はどのようなものかを考えに入れて開発されていない。試験は、「塀越しに投げ入れる（ｔｈｒｏｗｎ  ｏｖｅｒ  ｔｈｅ  ｗａｌｌ）」式である。開発者のデスクトップ→試験構成？これは、自身の実動環境にどのようにマップされるか？展開の課題：どのサーバを使用するか？正しいトポロジはどのようなものか？サーバチーム、ストレージチーム、およびネットワーキングチームに問い合わせたか？どれだけの将来の需要を見込む必要があるか？オペレーション上の課題：これらアラートすべてに関してどうするのか？障害の生じたＮＩＣは、アプリケーションにどのように影響を与えるか？サービスのパフォーマンスはどうして低下しているのか？電子メール管理のクローンを作成できればいいのだが。
【０５５０】
サービスデリバリの課題に対処することは、顧客のための実行可能なソリューションの中核の教義（ｃｏｒｅ  ｔｅｎａｎｔ）である。
【０５５１】
ライフサイクルの各ステップにおける独立値
開発、展開、オペレーション
ライフサイクル全体のアーキテクチャを統一すること
ステップ間のより一層の調整およびフィードバック
変化するビジネスニーズに対するマッピングを可能にする
マッピングは、機動性があるときのみ行うことができる
最も安いＴＣＯプラットフォーム上に構築される
スケール拡張を通じて業界標準ハードウェアを有効に活用する
プロジェクトサミット（Ｐｒｏｊｅｃｔ  Ｓｕｍｍｉｔ）−革命的なサービスデイバリアーキテクチャ。図１０６を参照されたい。装備され、扱いやすく、展開要件を含み、オペレーションの知識をカプセル化し、標準のビルディングブロックを活用するサービスを開発する。迅速な準備、データセンタリソースの仮想化、自己完結型、ワンクリックによる展開、試験から実動までの一貫性、スケール独立のサービスを容易に展開する。集約管理、監視および変更管理、アプリケーションではなくサービスの管理、コンテキストを介していの真の自動化、豊かなサービス中心の管理コンソールによる簡単化されたオペレーション。
【０５５２】
ビジネスニーズをＩＴシステムにマップする。ＩＴオペレーション上の知識をツールに取り込む。
【０５５３】
プロジェクトサミット−包括的な新しいアーキテクチャ、および業界全体のイニシアチブ。図１０７を参照されたい。
【０５５４】
概念→アーキテクチャ→製造
長期の顧客およびパートナー主導の作業
１９９９年に開始した大規模な投資
大型ＭＳインターネットプロパティのオペレーション上へのニーズの深い研究から始まった
広範な顧客ベースにわたっての最初の所見を検証した
２０００年末期に製品グループからプロトタイプ
強力な１団の共同開発パートナー
製品定義に関与した大企業およびサービスプロバイダ顧客
ＡＰＩを介して公開された機能を定義するのを助けるために相談にあずかったＩＨＶおよびＩＳＶパートナー
Ｗｉｎｄｏｗｓ（登録商標）サーバ２００３と共に最初の製品出荷
顧客が、複雑なシステムを単純な図に変換する。図１０８を参照されたい。
【０５５５】
誰がＩＴサービスのデリバリに関与しているか？−人間は、システムの不可欠な部分である。
【０５５６】
アプリケーションアーキテクチャ設計者−サービスを設計する。  
ネットワークアーキテクチャ設計者−ネットワークを構成する。  
ストレージアーキテクチャ設計者−遠隔ストレージを構成する。  
アプリケーション運用者−サービスを維持管理する。  
ネットワーク運用者−ネットワークを維持管理する。  
ストレージ運用者−遠隔ストレージを維持管理する。  
サーバ運用者−サーバを維持管理する。
【０５５７】
このモデルの問題：人間のやりとりが多く、共通の言語が存在せず、ドメイン知識が不明瞭になる。
【０５５８】
ソリューションの詳細
サービス定義モデル
リソース仮想化
オペレーション上の自動化
管理ＡＰＩおよびソリューション
業界全体のイニシアチブを主導
サービス定義モデル（ＳＤＭ）−完全なサービスを取り込む。  
サービスの包括的な記述
アプリケーションコンポーネントおよび計測
サービストポロジ
基礎となるリソース（サーバ、ストレージ、ネットワーク）
開発者および運用者に関連がある。
【０５５９】
責任をレイヤ化し、分離する。  
リファレンスの一貫性のある枠組みを提供する。  
開発者のためにＶｉｓｕａｌ  Ｓｔｕｄｉｏで公開される。  
運用者のために実行時の活動（ｌｉｖｉｎｇ）モデル
割り振られたリソースの論理的に整合性のあるｉｎｄ．
リアルタイムでリソースを追跡する。  
サービスコンポジションに関する単一の権限
真の自動化のためのコンテキストを提供する。
【０５６０】
ＳＤＭ専門用語
コンポーネント−サービスのビルディングブロック
論理構成
スケール不変
１つのコンポーネントが、複数のインスタンスを有することがある。  
単純または複合
単一の論理エンティティ（データベース、Ｗｅｂサービス、ファイル区画化）
結合された論理エンティティ（ＨＡデータベース、電子メールなど）
コンポーネントに特有の展開マニフェストを含む。  
ＤＢコンポーネントは、データベーススキーマを含む。  
Ｗｅｂサービスコンポーネントは、ＵＲＬディレクトリ、コンテンツ、コードを含む。  
ポートおよびワイヤと相互接続されている。  
ポート−サービスアクセスポイント
ワイヤ−ポート間の通信関係
ＳＤＭは、抽象化およびカプセル化のための手段を提供する。図１１０を参照されたい。
【０５６１】
再使用を可能にする。  
複雑さを構造化する。  
人々をＳＤＭにマップすること−リファレンスの一貫性のある枠組みを提供する。図１１１を参照されたい。
【０５６２】
ＳＤＭアプリケーションを開発すること−新しいＶｉｓｕａｌ  Ｓｔｕｄｉｏ設計表面。図１１２を参照されたい。レガシアプリケーション、新たなアプリケーション。
【０５６３】
データセンタにおけるＳＤＭサービス−リソースを追跡する活動中のモデルを有する包括的な記述。図１１３を参照されたい。
【０５６４】
サミットコンピュータとは何か？
仮想化されたハードウェアリソースの機動性のあるプール
サーバ、ストレージ、ネットワークデバイス、管理されたファブリック
数十から数千のサーバ
既存のハードウェアからアセンブルされるか、またはＯＥＭから１つのＳＫＵとして注文される
単一の管理されたエンティティ
サミットは、サミットコンピュータとともに／内ですべてのハードウェアリソースを提供し、管理する。
サミットは、内部ネットワークファブリックの完全な構成を所有する。
【０５６５】
制御の有界ドメイン
標準化されたトポロジにより、構築、試験、およびオペレーションの複雑性に境界をつける。
サミットコンピュータの外部でリソースに関する所有権は変更されない。
【０５６６】
ソフトウェア革新の触媒
問い：自分のサーバアプリケーションに関して、どのようなデータセンタ環境をターゲットとすべきか？
答え：サミットコンピュータです。
Ｗｉｎ３により、ＩＳＶにプリンタおよびグラフィックスカードの詳細について忘れさせているのと同様に。
【０５６７】
ハードウェア革新のための触媒
マイクロソフトは、リファレンスプラットフォームを定義するために主なハードウェアベンダと手を結んだ。
最初の仕様および革新が、ＷｉｎＨＥＣ（２００３年５月）に現れる。
サミットは、集約革新のためのソフトウェア環境を提供する。
高密度ブレード、スマートラック等。
サミットは、ハードウェアの単純化を可能にし、例えば、以下のことを可能にする。
サーバからＫＶＭをドロップし、ネットワークデバイスから人間とのインターフェースをドロップする。
【０５６８】
図１１４は、例示的なリソースマネージャを示している。
リソース仮想化−ＳＤＭとコンポーネントインスタンスの間のブリッジ。
共用、割り振り、および回復を担う。図１１５を参照されたい。
【０５６９】
サーバリソース仮想化−Ｗｉｎｄｏｗｓ（登録商標）サーバ２００３における自動展開サービス（ＡＤＳ）
Ｗｉｎｄｏｗｓ（登録商標）サーバを迅速に目的化し、再目的化するための完全なインフラストラクチャ
Ｗｉｎｄｏｗｓ（登録商標）２０００およびＷｉｎｄｏｗｓ（登録商標）サーバ２００３のイメージをともに取り込み、編集するイメージングツール
ベアメタル（ｂａｒｅ  ｍｅｔａｌ）からゼロタッチ（ｚｅｒｏ  ｔｏｕｃｈ）のサーバ構築を可能にするセキュアな遠隔展開フレームワーク
大量サーバ管理のためのフレームワーク
セキュアで信頼でき、スクリプト実行のインフラストラクチャ
Ｗｉｎｄｏｗｓ（登録商標）データセンタのプログラマティックなモデル
すべての管理活動の永続的ログ
グラフィカルでプログラマティックなインターフェース
ＧＵＩベースの操作のための単純なＭＭＣユーザインターフェース
コマンドラインツールおよび／またはＷＭＩレイヤを通して公開される完全な機能性
ＡＤＳの主要な利点
１．ベアメタルサーバ構築およびスクリプトベースの管理に関連するＴＣＯの低減
ベアメタルからゼロタッチのサーバ構築を可能にする。  
１つのサーバと同じぐらい容易な１０００のサーバのセキュアなスクリプトベースの管理
２．Ｗｉｎｄｏｗｓ（登録商標）サーバデータセンタの一貫性、セキュリティ、およびスケーラビリティを改善
オペレーション上の最良の実践をエンコードし、人間によるエラーをなくす。  
すべての管理活動の永続的ストアを維持する。  
Ｗｉｎｄｏｗｓ（登録商標）データセンタ全体のセキュアなスクリプトベースの管理を集中式に行う。  
作業負荷要件の変化に応答してサーバの役割を迅速に変化させる。  
３．既存のサーバ管理投資を活用する。  
既存のスクリプトベースの自動化方法論を拡張し、強化する。
【０５７０】
オペレーション上の自動化−自動化の中核の教義
オペレーション上の最良の実践を取り込み、再使用することを可能にする柔軟性のあるフレームワーク
オペレーションロジック
自動化を行うための豊かなコンテキスト
イベントがＳＤＭによってコンテキスト化されてシステム管理の真の自動化を可能にする。  
「ラック２２の第５番のＤＬ３８０上で停止するＮＩＣによってどのアプリケーションが影響を受けるか？」
トランザクション可能（Ｔｒａｎｓａｃｔ−ａｂｌｅ）
補正ベースのモデルにより、ロールバックおよび元に戻すこと（ｕｎｄｏ）を可能にする。  
オペレーションロジック−開発者および運用者の自動化のためのフレームワーク
オペレーションロジックとは何か？
存続期間が長く、可用性が高く、持続性のあるエンコードされたオペレーションプロセス
サミットコンピュータリソースのコンテキストおよび制御のためにＳＤＭを活用する。  
運用者が、システムにおける自動化のレベルを変更することを可能にする。
【０５７１】
開発者にとっての利点
開発者がアプリケーションイベントおよびメッセージ（リターンコードなどの）に対してシステムがどのように応答し、解決すべきかを取り込めるようにする。
【０５７２】
マイクロソフトおよびＩＳＶコミュニティが、開発者が使用したり、または拡張したりすることができる標準の事前定義されたオペレーション上のプロセスを提供できるようにする。
【０５７３】
リソースの展開、アップグレード、スケール拡張、および削除を行う。
【０５７４】
ＩＴ専門技術者または運用者に対する利点
データセンタに関する実証済みのオペレーション上の最良の実践を容易に再使用できるようにする。
【０５７５】
オペレーション上の自動化−プログラミングオペレーションロジック。図１１６を参照されたい。
【０５７６】
ＳＤＭがオペレーションロジックとどのようにやりとりするか？：
インスタンス情報およびコンポーネント情報を示すようにイベントに注釈が付けられる。  
監視を行うサブシステムが、時間ベースのイベント相関を行う。  
警報は、イベントのロールアップ（ｒｏｌｌ−ｕｐ）である。  
より大きい意味構造上の意味
コマンドレット（ｃｏｍｍａｎｄｌｅｔ）は、
コンポーネントによって公開された管理コマンドのセットである。  
自己記述性（ｓｅｌｆ−ｄｅｓｃｒｉｂｉｎｇ）である。  
シェル内で直接に使用することができる。  
ＧＵＩ形態の表現を有することができる。  
運用者による使用のために「マニュアルページ（ｍａｎ−ｐａｇｅ）」を提供することができる。
【０５７７】
図１１７を参照されたい。
【０５７８】
オペレーション上の自動化−トランザクション可能
トランザクションは、耐障害性（ｆａｕｌｔ−ｔｏｌｅｒａｎｔ）の操作をサポートするのに不可欠である。  
例：Ｗｅｂサービスを追加すること
アドホック（ａｄ−ｈｏｃ）シェルスクリプトに対する強力な拡張
トランザクションモデルの後援による（ｕｎｄｅｒ  ｔｈｅ  ａｕｓｐｉｃｅｓ  ｏｆ）すべての形態のオペレーションロジック機能
補正ベース
持続性がある
統合（ｏｒｃｈｅｓｔｒａｔｉｏｎ）を使用して、トランザクションが複数のマシンにまたがることができる。
【０５７９】
管理ＡＰＩおよびソリューション−ＳＤＭの豊かさを活用
視覚化は、ＳＤＭを通して行われる。  
第三者のコンソールが、ＳＤＭから直接に情報を引き出すか、またはマイクロソフト管理ソリューションのプラットフォームノウハウを活用することができる。  
マイクロソフトは、データセンタ向けにＳＤＭベースの管理コンソールを構築する。  
顧客が、ＳＤＭを介してカスタムコンソールを作成することも可能である。
【０５８０】
図１１８を参照されたい。
【０５８１】
業界全体のイニシアチブ−ＩＨＶ革新、ＩＳＶ革新、ＳＩ革新を引き起こすこと
ＩＨＶ  ハードウェアリファレンスプラットフォーム仕様
主要なＯＥＭおよびスイッチ製造業者と緊密に協力すること
ＷｉｎＨＥＣ（’０３年５月）におけるリリースを目標とすること
新たな説得力のある徴を将来のハードウェア提供に導入する。
【０５８２】
主要な第三者のＩＳＶと手を結ぶ
Ｖｉｓｕａｌ  Ｓｔｕｄｉｏのためのアプリケーションコンポーネントを作成する。  
ＳＤＭ内のアプリケーションのためのリソースマネージャ
管理者がＳＤＭベースの管理コンソールを作成する。
【０５８３】
顧客およびパートナーとしてＳＩと協力する。  
顧客
顧客のオペレーション上のコストを劇的に低下させる。  
パートナー
革新的な新しいサービス提供をこのプラットフォーム上で作成する。  
オペレーション専門知識を資本化する→オペレーションロジックを開発する。
【０５８４】
主要な顧客の利点：選択肢を提供し、データセンタのための最も経済的で管理しやすいプラットフォームを提供する。
【０５８５】
業界全体のイニシアチブ−ＳＤＭの豊かさを異機種混合の環境に拡張する。Ｖｉｓｕａｌ  Ｓｔｕｄｉｏ（Ｗｉｎｄｏｗｓ（登録商標）向けのＳＤＭアプリケーションの開発を可能にする）、または第三者のツール（他のプラットフォーム向けのＳＤＭアプリケーションの開発を可能にする）を使用して、異機種混合のＳＤＭアプリケーションを開発する。
【０５８６】
結論
本発明を構造上の特徴および／または方法論上の動作に特有の言葉で説明したが、例示的な添付の特許請求の範囲において定義された本発明は、記載した特定の特徴または動作に限定されないことを理解されたい。むしろ、特定の特徴および動作は、特許請求の範囲の本発明を実施する例示的な形態として開示されている。さらに、これら請求項は、範囲および主題において例示的である。本明細書に記載した特徴の多くの他の組合せおよび部分的な組合せを、後に、本願の優先権を主張する特許出願明細書において請求する可能性がある。
【０５８７】
以上の説明は、構造上の特徴および／または方法論上の動作に特有の言葉を使用しているが、添付の特許請求の範囲において定義する本発明は、記載した特定の特徴または動作に限定されないことを理解されたい。むしろ、特定の特徴および動作は、本発明を実施する例示的な形態として開示されている。
【図面の簡単な説明】
【０５８８】
【図１】インターネットデータセンタの例を示す図である。
【図２】サービスの例を示す図である。
【図３】例示的なレイヤ抽象化を示す図である。
【図４】例示的なレイヤ抽象化を示す図である。
【図５】例示的なレイヤ抽象化を示す図である。
【図６】例示的なレイヤ抽象化を示す図である。
【図７】例示的なレイヤ抽象化を示す図である。
【図８】例示的なレイヤ抽象化を示す図である。
【図９】例示的なＳＤＭタイプ空間を示す図である。
【図１０】例示的なＳＤＭタイプ空間を示す図である。
【図１１】例示的なレイヤ抽象化を示す図である。
【図１２】例示的なレイヤ抽象化を示す図である。
【図１３】例示的なレイヤ抽象化を示す図である。
【図１４】例示的なレイヤ抽象化を示す図である。
【図１５】例示的なレイヤ抽象化を示す図である。
【図１６】例示的なプロセスを示す図である。
【図１７】本明細書で説明する例示的なコンポーネントを示す図である。
【図１８】本明細書で説明する例示的なコンポーネントを示す図である。
【図１９】本明細書で説明する例示的なコンポーネントを示す図である。
【図２０】例示的なグラフィカルユーザインターフェースを示す図である。
【図２１】例示的なグラフィカルユーザインターフェースを示す図である。
【図２２】例示的なＳＤＭモデルを示す図である。
【図２３】例示的な展開を示す図である。
【図２４】例示的なタイプを示す図である。
【図２５】例示的なインスタンス要求を示す図である。
【図２６】制約の例示的な再検証を示す図である。
【図２７】ＳＤＭランタイムの例示的な論理アーキテクチャを示す図である。
【図２８】サービスの例示的な表現図である。
【図２９】例示的なインスタンス空間を示す図である。
【図３０】データをＳＤＵにパッケージ化する例を示す図である。
【図３１】例示的なタイプ空間、メンバ空間、およびインスタンス空間を示す図である。
【図３２】例示的なメンバツリーを示す図である。
【図３３】例示的なインスタンスツリーを示す図である。
【図３４】本明細書で説明するシステムの例示的な実装を示す図である。
【図３５】コンポーネントインスタンスの追跡作成（ｔｒａｃｋｉｎｇ  ｃｒｅａｔｉｏｎ）の例を示す図である。
【図３６】例示的なコンポーネントインスタンスイベントを示す図である。
【図３７】例示的なコンポーネントインスタンスイベントを示す図である。
【図３８】例示的なコンポーネントインスタンスイベントを示す図である。
【図３９】例示的なコンポーネントインスタンスイベントを示す図である。
【図４０】区画化されたランタイムの例を示す図である。
【図４１】例示的なメンバ空間を示す図である。
【図４２】例示的なインスタンス階層を示す図である。
【図４３】インスタンス空間を区画化する例を示す図である。
【図４４】様々なコンポーネント間の例示的な関係を示す図である。
【図４５】例示的な固定ＩＤ信頼関係を示す図である。
【図４６】コンポーネントの例示的な配置構成を示す図である。
【図４７】コンポーネントの例示的な配置構成を示す図である。
【図４８】例示的なプラットフォームアーキテクチャを示す図である。
【図４９】アプリケーション展開に関する例示的な使用フローを示す図である。
【図５０】例示的なアプリケーション設定およびホスト設定を示す図である。
【図５１】展開ツールの例示的な段階を示す図である。
【図５２】データセンタ記述の例示的な視覚化を示す図である。
【図５３】例示的な流れ図である。
【図５４】例示的な流れ図である。
【図５５】ＳＤＵを扱う例を示す図である。
【図５６】例示的な流れ図である。
【図５７】例示的な流れ図である。
【図５８】例示的な流れ図である。
【図５９】例示的なモデルアーキテクチャを示す図である。
【図６０】管理の例示的なレイヤを示す図である。
【図６１】システムの例示的な動作を示す図である。
【図６２】例示的なコネクタ配置構成を示す図である。
【図６３】デバイスの例示的な物理構成を示す図である。
【図６４】デバイスの例示的な物理構成を示す図である。
【図６５】デバイスの例示的な物理構成を示す図である。
【図６６】デバイスの例示的な物理構成を示す図である。
【図６７】デバイスの例示的な物理構成を示す図である。
【図６８】例示的な要求グラフを示す図である。
【図６９】例示的な応答グラフを示す図である。
【図７０】本発明を使用することができる例示的なシナリオを示す図である。
【図７１】本発明を使用することができる例示的なシナリオを示す図である。
【図７２】本発明を使用することができる例示的なシナリオを示す図である。
【図７３】本発明を使用することができる例示的なシナリオを示す図である。
【図７４】本発明を使用することができる例示的なシナリオを示す図である。
【図７５】本発明を使用することができる例示的なシナリオを示す図である。
【図７６】本発明を使用することができる例示的なシナリオを示す図である。
【図７７】本発明を使用することができる例示的なシナリオを示す図である。
【図７８】本発明を使用することができる例示的なシナリオを示す図である。
【図７９】本発明を使用することができる例示的なシナリオを示す図である。
【図８０】本発明を使用することができる例示的なシナリオを示す図である。
【図８１】本発明を使用することができる例示的なシナリオを示す図である。
【図８２】本発明を使用することができる例示的なシナリオを示す図である。
【図８３】本発明を使用することができる例示的なシナリオを示す図である。
【図８４】本発明を使用することができる例示的なシナリオを示す図である。
【図８５】本発明を使用することができる例示的なシナリオを示す図である。
【図８６】本発明を使用することができる例示的なシナリオを示す図である。
【図８７】例示的なサービスプラットフォームアーキテクチャを示す図である。
【図８８】システム内の例示的なコンポーネントを示す図である。
【図８９】本明細書で説明するシステムに含めることができる例示的な製品を示す図である。
【図９０】様々なリソース管理コンポーネントを示す図である。
【図９１】複数のＬＡＮの例示的な配置構成を示す図である。
【図９２】例示的なＡＤＳアーキテクチャを示す図である。
【図９３】例示的なＡＤＳ遠隔ブートおよびイメージングシステムを示す図である。
【図９４】例示的なトポロジ配置構成を示す図である。
【図９５】ＳＤＭＬ例を示す図である。
【図９６】ＳＤＵにおけるデータの例示的な収集を示す図である。
【図９７】ＳＤＵランタイムＡＰＩを使用する動的バインド化の例を示す図である。
【図９８】例示的なＳＤＭ配置構成を示す図である。
【図９９】例示的な展開を示す図である。
【図１００】例示的なシステムアーキテクチャを示す図である。
【図１０１】様々な展開レイヤの例を示す図である。
【図１０２】例示的なオペレーションロジックを示す図である。
【図１０３】インターネットによる例示的な変化を示す図である。
【図１０４】インターネットによる例示的な変化を示す図である。
【図１０５】インターネットによる例示的な変化を示す図である。
【図１０６】例示的なアプリケーションライフサイクルを示す図である。
【図１０７】新しいアーキテクチャの例示的な利点を示す図である。
【図１０８】複雑なシステムを単純な図に変換する例を示す図である。
【図１０９】例示的なサービスを示す図である。
【図１１０】例示的なＳＱＬクラスタを示す図である。
【図１１１】例示的なＳＤＭデータセンタモデルを示す図である。
【図１１２】例示的な設計アプリケーション表面を示す図である。
【図１１３】データセンタにおける例示的なＳＤＭサービスを示す図である。
【図１１４】例示的なリソースマネージャを示す図である。
【図１１５】リソース仮想化の例を示す図である。
【図１１６】例示的なプログラミングオペレーションロジックを示す図である。
【図１１７】オペレーションロジックとの例示的な対話を示す図である。
【図１１８】異種環境を管理する例を示す図である。
【図１１９】異種環境を管理する例を示す図である。
【符号の説明】
【０５８９】
１００  インターネットデータセンタ
１０２  コンピュータ
１０４  コンピュータのプール
【図１】
2004272912.tif 000004
【図２】
2004272912.tif 000005
【図３】
2004272912.tif 000006
【図４】
2004272912.tif 000007
【図５】
2004272912.tif 000008
【図６】
2004272912.tif 000009
【図７】
2004272912.tif 000010
【図８】
2004272912.tif 000011
【図９】
2004272912.tif 000012
【図１０】
2004272912.tif 000013
【図１１】
2004272912.tif 000014
【図１２】
2004272912.tif 000015
【図１３】
2004272912.tif 000016
【図１４】
2004272912.tif 000017
【図１５】
2004272912.tif 000018
【図１６】
2004272912.tif 000019
【図１７】
2004272912.tif 000020
【図１８】
2004272912.tif 000021
【図１９】
2004272912.tif 000022
【図２０】
2004272912.tif 000023
【図２１】
2004272912.tif 000024
【図２２】
2004272912.tif 000025
【図２３】
2004272912.tif 000026
【図２４】
2004272912.tif 000027
【図２５】
2004272912.tif 000028
【図２６】
2004272912.tif 000029
【図２７】
2004272912.tif 000030
【図２８】
2004272912.tif 000031
【図２９】
2004272912.tif 000032
【図３０】
2004272912.tif 000033
【図３１】
2004272912.tif 000034
【図３２】
2004272912.tif 000035
【図３３】
2004272912.tif 000036
【図３４】
2004272912.tif 000037
【図３５】
2004272912.tif 000038
【図３６】
2004272912.tif 000039
【図３７】
2004272912.tif 000040
【図３８】
2004272912.tif 000041
【図３９】
2004272912.tif 000042
【図４０】
2004272912.tif 000043
【図４１】
2004272912.tif 000044
【図４２】
2004272912.tif 000045
【図４３】
2004272912.tif 000046
【図４４】
2004272912.tif 000047
【図４５】
2004272912.tif 000048
【図４６】
2004272912.tif 000049
【図４７】
2004272912.tif 000050
【図４８】
2004272912.tif 000051
【図４９】
2004272912.tif 000052
【図５０】
2004272912.tif 000053
【図５１】
2004272912.tif 000054
【図５２】
2004272912.tif 000055
【図５３】
2004272912.tif 000056
【図５４】
2004272912.tif 000057
【図５５】
2004272912.tif 000058
【図５６】
2004272912.tif 000059
【図５７】
2004272912.tif 000060
【図５８】
2004272912.tif 000061
【図５９】
2004272912.tif 000062
【図６０】
2004272912.tif 000063
【図６１】
2004272912.tif 000064
【図６２】
2004272912.tif 000065
【図６３】
2004272912.tif 000066
【図６４】
2004272912.tif 000067
【図６５】
2004272912.tif 000068
【図６６】
2004272912.tif 000069
【図６７】
2004272912.tif 000070
【図６８】
2004272912.tif 000071
【図６９】
2004272912.tif 000072
【図７０】
2004272912.tif 000073
【図７１】
2004272912.tif 000074
【図７２】
2004272912.tif 000075
【図７３】
2004272912.tif 000076
【図７４】
2004272912.tif 000077
【図７５】
2004272912.tif 000078
【図７６】
2004272912.tif 000079
【図７７】
2004272912.tif 000080
【図７８】
2004272912.tif 000081
【図７９】
2004272912.tif 000082
【図８０】
2004272912.tif 000083
【図８１】
2004272912.tif 000084
【図８２】
2004272912.tif 000085
【図８３】
2004272912.tif 000086
【図８４】
2004272912.tif 000087
【図８５】
2004272912.tif 000088
【図８６】
2004272912.tif 000089
【図８７】
2004272912.tif 000090
【図８８】
2004272912.tif 000091
【図８９】
2004272912.tif 000092
【図９０】
2004272912.tif 000093
【図９１】
2004272912.tif 000094
【図９２】
2004272912.tif 000095
【図９３】
2004272912.tif 000096
【図９４】
2004272912.tif 000097
【図９５】
2004272912.tif 000098
【図９６】
2004272912.tif 000099
【図９７】
2004272912.tif 000100
【図９８】
2004272912.tif 000101
【図９９】
2004272912.tif 000102
【図１００】
2004272912.tif 000103
【図１０１】
2004272912.tif 000104
【図１０２】
2004272912.tif 000105
【図１０３】
2004272912.tif 000106
【図１０４】
2004272912.tif 000107
【図１０５】
2004272912.tif 000108
【図１０６】
2004272912.tif 000109
【図１０７】
2004272912.tif 000110
【図１０８】
2004272912.tif 000111
【図１０９】
2004272912.tif 000112
【図１１０】
2004272912.tif 000113
【図１１１】
2004272912.tif 000114
【図１１２】
2004272912.tif 000115
【図１１３】
2004272912.tif 000116
【図１１４】
2004272912.tif 000117
【図１１５】
2004272912.tif 000118
【図１１６】
2004272912.tif 000119
【図１１７】
2004272912.tif 000120
【図１１８】
2004272912.tif 000121
【図１１９】
2004272912.tif 000122
【外国語明細書】
2004272912000001.pdf