Visual Studio 2005 Team System : デプロイメントと運用を意識した分散システムの設計
Visual Studio Team System
Microsoft Corporation
May 2004
日本語版最終更新日 2004 年 6 月 1 日
適用対象:
Microsoft Visual Studio 2005 Team System
概要 : ここでは、分散アプリケーションを構築するために Visual Studio 2005 Team System で利用可能なソフトウェア デザイン ツールについて説明します。
メモ このドキュメントは製品のリリースに先立って制作されているため、実際に出荷される製品にこのドキュメントの内容が正確に反映されるとは限りません。このドキュメントの情報は、このドキュメントの公開時点の製品について書かれたものであり、計画以外の目的で利用できるものではありません。また、このドキュメントの情報は、予告なしに変更される可能性があります。
目次
はじめに
分散システムの設計課題
分散システムの設計と配置 (デプロイメント) の改善
Distributed System Designers の概要
拡張性
Visual Studio 2005 Team System との統合
まとめ
はじめに
Distributed System Designers (コードネーム : Whitehorse) は、分散システムを GUI ベースでデザイン可能とし、またその検証をサポートするツールです。このツールセットには、アプリケーション アーキテクト、デザイナ、開発者、およびオペレーション アーキテクト用のツールが含まれています。
Distributed System Designers は Dynamic Systems Initiative (DSI) における初の成果として登場するもので、大規模な分散システムの開発、配置 (デプロイメント) 、および管理の改善を目的としています。DSI は、Microsoft Windows プラットフォームを強化し、企業が分散システム利用する際の作業を簡素化および自動化するためのソリューションを提供するマイクロソフトと業界の取り組みです。詳しくはこちらのサイトのホワイトペーパー、あるいは「Microsoft Dynamic Systems Initiative」の Web ページ (英語) を参照してください。
また、サービス指向アーキテクチャ (SOA) は、次世代の分散アプリケーションの基盤となるテクノロジです。Microsoft の "Indigo" プラットフォームには、業界をリードするサービス指向システムが実際に利用可能なテクノロジとして提供されます。"Indigo" は、現在の Windows プラットフォームで提供される SOAP および Web サービスのサポートをベースにしており、トランスポートおよびアプリケーション トポロジの包括的な範囲にサポートを追加し、安全で信頼性が高く、耐久性があるメッセージベースの通信をサービス間で実現します。また、Indigo プラットフォームによる継続的な進歩を待ちつつも、一方で今すぐにでも SOAP、XML メッセージング、および ASP.NET Web サービスを利用して、サービス指向システムの開発を始めることができます。詳細については、「Indigo」(英語) を参照してください。
分散システムの設計課題
分散システムの設計と配置 (デプロイメント) はかなり複雑なプロセスです。このセクションでは、実際に起こり得るいくつかの課題を説明します。
分散システムの設計の視覚化
サービス指向アーキテクチャではシステムがサービス毎に断片化されるため、システム構造全体をまとめて視覚化することが、より一層難しくなってきます。さらに、企業では、これまで各部門が個別にさまざまなアプリケーションを購入、開発してきたため、さまざまな異種システムを使用しています。これらの個々のシステムは、個別のプログラミング テクノロジを利用していることがほとんどで、そのため、これらの既存のシステム間では機能やデータを共有するのが難しいことがほとんどです。相互運用性を可能にするために、開発者とアーキテクトはこれまで以上にメッセージベースのインターフェイスの設計を行うよう求められています。つまり、新規のメッセージを設計する一方で、既存メッセージ スキーマへも適合させる必要があるのです。メッセージによる相互運用は、サービス指向アーキテクチャの中心課題です。
設計とコードの同期
システム デザイン ドキュメントを最新の状態に保つには、チームメンバー間の密接なコミュニケーション、特にアーキテクトと開発者のコミュニケーションが必須です。しかし多くの場合、どれほど努力したとしても、システム デザイン ドキュメントは、コーディングが開始された途端に古くなったり、的確なものでなくなったりしてしまいます。デザイン ドキュメントを頻繁に変化するコードと同期化させるのは、開発が進むにつれ困難な作業となり、多くの場合は途中で断念する結果となります。
Design for Deployment：配置 (デプロイメント) を考慮した設計
ソフトウェアおよびハードウェア ベンダは多くの場合、開発者がプラットフォーム構成 (SQL、IIS、BizTalk など) の微妙な違いを認識しており、一方で運用管理者がアプリケーション開発者の使用するフレームワークやメッセージ プロトコルを十分に理解していると考えています。運用はソフトウェア開発ライフサイクル全体の一部であるべきですが、運用管理を担当するチームは組織的にも機能的にも分離されていることがしばしばで、多くの場合は積極的に開発チームと協力体制をとることはまれであり、ソフトウェア開発サイクルの終盤になって受動的な協力が開始され、その結果、ソフトウェア開発の初期に防ぐことのできた問題がようやくその段階で顕在化します。
Web サービスの開発と配置 (デプロイメント) をシンプルなケースで考えてみましょう。開発者の主な関心はサービスの実装にありますが、セキュリティと認証モデル、実運用を行う環境で要求される他のサポート サービス、および要求どおりに Web サービスを機能させるのに必要な構成設定にも関心を持つ必要があります。運用担当者は、新しいサービスにはどのようなプロトコルやサービスが必要なのか、そしてそれらが自社のIT ポリシーに従っているかどうかを理解する必要があります。開発と運用の分離は、配置 (デプロイメント) において不適切な構成を引き起こし、さらには、データセンターと互換性のない設計につながり、結果として、配置 (デプロイメント) 上の問題を修正するのに多額の追加予算を費やすことになります。
多くの組織においては、ドキュメントやデザインレビューを増やし、またダイアグラムをより緻密にすることでこういったコミュニケーションの問題に取り組もうとしています。しかし残念なことに、そのポリシーを効率的に実施し、伝達するツールや共通言語は現時点で十分に用意されていません。さらにこれらのプロセスは、開発者や運用担当者が毎日使用する実際のツールと統合されていないことがほとんどで、こういったプロセス自体がメンバーの負荷を増やす等、新たな問題の一因になっています。
セキュリティを考慮したアプリケーション構成
分散アプリケーションにおけるセキュリティ対策は、多くの時間が必要であり、また複雑なプロセスです。なぜなら、分散アプリケーションにおいては、その設計に影響する可能性のある多数のテクノロジや設定が関係しているためです。現在のところ、アプリケーションを設計する際に、アプリケーションのセキュリティ構成やデータセンターのセキュリティ要件を示す統合的な方法はありません。そのため、セキュリティが正しく実装されていることを確認するのは困難です。
分散システムの設計と配置 (デプロイメント) の改善
Distributed System Designers は、分散システムのビジュアル デザインと検証を可能にすることを目的とし、統合されたデザイン エクスペリエンスを提供します。Designers では、基礎をなすメタモデルとして System Definition Model (SDM) を使用し、アプリケーション サービスだけではなくランタイム環境の接続、構成、および関係を記述します。SDM は多層的なモデルをベースにしており、アプリケーション、アプリケーション ホスティング環境、ネットワーク トポロジ、オペレーティング システム、および物理デバイス、という階層が含まれています。このモデルにより、Distributed System Designers は各レイヤのデザインを記述できるだけでなく、分散システムの全レイヤに影響を及ぼす制約とポリシーを各レイヤで示すこともできます。
Distributed System Designers では、開発と運用という 2 つの異なる分野を統合したモデルをサポートしています。Distributed System Designers は以下の機能を提供します。
-
分散システムの設計や構成を記述する共通言語(SDM をベースにした言語)。
-
開発者が、アプリケーションがランタイム環境に要求する制約 (つまり、運用担当者に伝えるべき内容) を記述できるようにします。
-
運用担当者が、実運用を行う環境における配置 (デプロイメント) のポリシーであるアプリケーション ランタイム、セキュリティ、および接続要件 (つまり、開発者に伝えるべき内容) を記述できるようにします。
-
開発者と運用担当者の共通のコミュニケーション基盤となる抽象概念。
-
既存の Visual Studio プロジェクト システムおよび .NET テクノロジとの統合。
-
ビジュアル デザインによる成果物と実装コードの完全な同期化。
-
新しい種類のアプリケーションやホスティング システムをモデルにできる拡張フレームワーク。
以下のセクションでは、Distributed System Designers ツールセットに含まれる各デザイナやエディタの機能について説明します。
Distributed System Designers の概要
Distributed System Designers には、以下のデザイナが含まれています。
-
Application Connection Designer
-
Logical Datacenter Designer
-
System Designer
-
Deployment Designer
Application Connection Designer
Application Connection Designer (ACD) は、開発者やアーキテクトが配置 (デプロイメント) を考慮しつつ、システムを構成するアプリケーションを定義および設定するのに役立ちます。ツールボックスには、アプリケーション プロトタイプのセットが用意されており、「Web サービス」、「Web アプリケーション」、「Windows アプリケーション」、「外部データベース」、「外部 Web サービス」、「外部 BizTalk サービス」、が含まれています。その他のアプリケーション タイプを文書化するために、汎用のアプリケーション プロトタイプも含まれています。
アプリケーション コネクション ダイアグラムには、ある一つのVisual Studio ソリューションで定義したアプリケーションが表示されます。このダイアグラムは、ツールボックスから各アプリケーションを追加してゼロから作成することもできますし、既存のソリューションや既存のプロジェクトからリバース (解析) を行い作成することもできます。
以下の図に、サンプル アプリケーションの接続ダイアグラムを示します。
.gif)
図 1 Application Connection Designer
ACD には、"内部" および "外部" のアプリケーションが表示されます。"内部アプリケーション" は個別に配置 (デプロイメント) 可能なアプリケーションで、1 つ以上の配置 (デプロイメント) 可能なシステムを構成するソリューション内で定義されます。各内部アプリケーションは一般的に、ホスト可能な実行ファイル (「Web アプリケーション」や 「Windows アプリケーション」など) を定義する単一プロジェクトになります。リソースはこのプロジェクトに含めることもできますし、他の参照、またはクラス ライブラリ プロジェクトなどの共有プロジェクトとして配置 (デプロイメント) することもできます。また、"外部アプリケーション" により、開発者は、配置 (デプロイメント) 時に解決する必要のある他のシステムへの参照を視覚化できます。
各アプリケーションはボックスとして表示され、アプリケーションの接続ポイント (他のアプリケーションへ接続するためのポイント、あるいは他のアプリケーションから接続されるためのポイントのどちらか) を示す小さなシェイプが付いています。これらはエンドポイントと呼ばれています。アプリケーションの提供するサービスはプロバイダのエンドポイント (ソリッド シェイプ。色のついたシェイプ) で表され、他のアプリケーションが提供するサービスへの接続ポイントはコンシューマのエンドポイント (クリア シェイプ。透明なシェイプ) で表されます。アプリケーションは、そのエンドポイントを介して互いに接続されます。
SDM モデルではエンドポイントのタイプ、構成、および接続に関しての記述が中心になります。個々のアプリケーションではこのモデルを拡張して、サービスが提供する動作 (ビヘイビア) の定義を表すことができます。たとえば Web サービスのエンドポイントは、次のいずれかの方法で定義できます。一つ目の方法は[Endpoint Details] ウィンドウを使用する方法です。Web サービス プロバイダのエンドポイントをクリックすると、[Endpoint Details] ウィンドウでその Web サービスのオペレーションを定義できます。2つ目の方法は、動作の定義を既存の Web サービス記述言語 (.wsdl) ファイルからインポートする方法です。ACD では完全なデザイン エクスペリエンスをサポートしており、このような方法でモデルを拡張することにより、たとえば、Web サービス アプリケーションの動作や構成を完全に指定することが可能になります。
ACD に表示される接続は、開発環境における現在のアプリケーション構成を示しています。アプリケーションをデバッグすると、接続経路が表示されます。
ACD では実装を行う前に、デザインを作成し検証を行うことができます。アプリケーション定義をツールボックスから ACD に追加しても、対応するプロジェクト、コード、および構成ファイルはすぐには作成されません。コードが初めて生成されたときが "実装" と見なされます。アプリケーション定義はインクリメントに行うことも、一度に行うこともできます。実装したアプリケーションは、ダイアグラム において影が付くようになり、未実装のアプリケーションと区別されます。個々のアプリケーションを実装すると、ダイアグラムおよびコード ファイルを開いている限り、生成されたコード ファイル、構成ファイル、およびダイアグラム サーフェス上に表示されたアプリケーション デザインは引き続き同期化され続けます。何らかの理由でダイアグラムを閉じている場合は、それを再び開くとコードと同期が行われ、ダイアグラムを閉じている間にコードに加えられた変更が更新されます。このように、ACD のデザイン モデルは、他のツールで問題になりがちな同期の問題を解消し、コードに加えられた変更に合わせてダイアグラムも最新の状態に保たれるようになります。また、リバース エンジニアリングでアプリケーションを作成すると、そのアプリケーションは既に実装されたものと見なされ、それ以降は自動的に同期化されます。
実装を行う前にデザインの作成と検証を行えるため、アーキテクトやアプリケーション デザイナは、システムの機能設計と検証に専念することができ、開発チームが後で行った方がよいと思われる実装決定の一部を後回しにすることができます。このような決定の中には、プログラミング言語の選択やテンプレートの準備、あるいはWeb プロジェクトに使用するサーバーの場所の選択、といったものも含まれるでしょう。
ダイアグラムはファイル (.dsdgm ファイル) として格納されるため、ソース コード コントロールに含めることができます。またダイアグラム作成作業をチームにおけるプロセス (ワークフロー) の標準的な作業として組み込むのも良いでしょう。実装したアプリケーションに関する情報は、各プロジェクト内の .sdm ファイルに格納されます。これにより、プロジェクトを複数のソリューションで再利用でき、作業をチームの開発者で分担できます。
ACD では、"アプリケーション構成設定のモデル" と "ホスティングに対する制約" を定義する機能を提供しています。ホスティングに対する制約により、アプリケーション設計者はホスティング環境に関して、必要となる条件を指定することができます。Settings and Constraints Editor におけるアプリケーション定義のホスティング制約を定義することにより、アプリケーション開発者は対象とする配置 (デプロイメント) 環境で利用可能な必須の機能セットを要求できるため、運用管理者に重要なアプリケーション要件を伝えることができます。その場合、運用管理者は論理データセンター (データセンター、つまりシステムを実際に運用するサーバー構成を論理的に表現したもの) を変更して、それらのアプリケーション開発者からの要求を受け入れるかどうかを決定することができます。アプリケーション設定とホスティング制約は、配置 (デプロイメント) に関する検証の一部として、論理データセンターの設定と制約に対して検証されます (Deployment Designer を参照)。
Logical Datacenter Designer
Logical Datacenter Designer (LDD) は、相互接続した論理サーバーのダイアグラムを作成するのに使用します。つまり、このダイアグラムはデータセンターの論理的な構造を表します。
これらの論理データセンター ダイアグラムは、対象とする配置 (デプロイメント) 環境に関する重要な情報を開発者に伝えます。この Designer を使用すると、オペレーション アーキテクト (運用管理者側のアーキテクト) はデータセンターのサーバーの種類、許可される通信の種類、特定の通信経路、および使用可能なサービスの種類を指定したり、設定することができます。
論理データセンター ダイアグラムは通常、オペレーション アナリスト (運用管理者側の分析担当者) が作成し、開発者が使用します。オペレーション アナリストは、論理データセンターのダイアグラムを作成した後もアプリケーション開発のライフサイクルを通じて、ダイアグラムをデータセンターの設計変更に合わせて最新の状態を保持することができます。他の Distributed System Designersと同様に、Logical Datacenter Designer は Visual Studio と完全に統合されています。しかし、論理データセンター ダイアグラムは、アプリケーション開発プロセスから切り離して作成されます。論理データセンター ダイアグラムは .lsad ファイルとして格納され、同じターゲット環境に配置 (デプロイメント) される他の分散システムにおいても再利用することができます。
以下の図に、構築中の論理データセンター ダイアグラムの簡単な例を示します。
.gif)
図 2 Logical Datacenter Designer
LDD では、ダイアグラム サーフェスに追加できる定義済み論理サーバーのプロトタイプが、ツールボックスに含まれています。論理サーバーは、データセンターのアプリケーション ホストを表しています。この中には「Windows クライアント サーバー」、「Web サーバー (IIS サーバー)」、「SQL サーバー」、および「汎用サーバー」が含まれます。汎用サーバーを除く各プロトタイプは、サーバーの設定に使用する設定と適用可能な制約のグループをあらかじめ定義しています。汎用サーバーはドキュメント専用で、データセンター内に存在する他の種類のサーバーをモデル化できます。各論理サーバーには、特定の通信プロトコルを指定するエンドポイントが 2 つあります。エンドポイントを論理サーバーに追加すると、そのエンドポイントを通じて他の論理サーバーと通信することができます。
与えられた設定を編集することにより、データセンター内の論理サーバーの構成をモデル化できます。論理サーバーの設定を編集する代わりに、本物のサーバーからその設定をインポートすることもできます。一度データセンターの記述を行うと、データセンターに関して管理可能なアプリケーションの種類や構成に関するポリシー制約は、Settings and Constraints Editor を使用して指定することができるようになります。これらの制約は、サーバーで管理できるアプリケーションの種類を設定したり、アプリケーションに必要な構成を指定するために使用するので、アプリケーション層の設定に照らして作成します。たとえば、Web サーバーで管理するアプリケーションについては ASP.NET のセキュリティ設定を指定できたり、Windows クライアント サーバーで管理するアプリケーションについて .NET フレームワーク のバージョンを指定できたりします。設定に関しては固定のものとしてマークすることにより、それらの設定を開発でオーバーライドできないようになります。
以下の図に、Settings and Constraints Editor を示します。
.gif)
図 3 Settings and Constraints Editor
ツールボックスには、ゾーンとエンドポイントも含まれています。ゾーンはデータセンターの通信境界を表しています。また、ゾーンのエンドポイントはゾーンとサーバーの接続ポイントを表しています。ゾーンとサーバー間の通信経路は、ゾーンのエンドポイントを通じて制御され、ゾーンに出入りできる通信プロトコルを設定することができます。サーバーのエンドポイントは、サーバー間で許可する通信経路とプロトコル、およびゾーンでトラフィックの送受信に使用する通信経路とプロトコルを指定するために使用します。
論理データセンター ダイアグラムで定義した構成設定とアプリケーション制約は、配置 (デプロイメント) 検証の一部としてアプリケーションで定義した設定および制約に照らして検証されます (Deployment Designer を参照)。この機能を用いることで、運用管理者はデータセンター ポリシーと配置 (デプロイメント) 要件を開発チームに伝えることができます。
System Designer
System Designer は、ACD で定義したアプリケーションからシステムを作成、設定するのに使用します。Distributed System Designers では、「システム」は開発の単位となり、1 つ以上のアプリケーションと他のサブシステムで構成されます。また、システムは他のシステムを組み合わせ構成できるため、大規模な分散システムのシナリオを定義できます。つまり、アプリケーション アーキテクトは、複雑な多層システムを "入れ子になった" システムの階層として設計することができます。
System Designerによるシステム定義は、ACD で設定した開発構成から切り離して定義を行うことができます。ACD のアプリケーション定義で決めたアプリケーション設定は、許可があれば、System Designer でオーバーライドすることができます。ACDで定義したアプリケーションは、System Designerにより、それぞれ別個の構成で複数のシステム定義に落とすことができます。つまり、これによりさまざまな計画された配置 (デプロイメント) 、データセンター構成、地理的な配置 (デプロイメント) 、または顧客ごとに異なる構成を定義することができるのです。
以下の図に、入れ子になったシステムを含むサンプル システムのダイアグラムを示します。
.gif)
図 4 System Designer
Deployment Designer
Deployment Designer は、ある論理データセンターに特定のシステム配置 (デプロイメント) を定義するのに使用します。Deployment Designer により、システム内の各アプリケーションを論理データセンター上で論理的に表現されているサーバーに連結することができます。Deployment Designer は一般的に、運用管理者ではなく、開発者やアーキテクトが使用します。このDeployment Designer においては、Distributed System Designers の基礎にあるSDM モデルによりもたらされるメリットのうち、コミュニケーション面の メリットが最も強く提供されています。配置 (デプロイメント) を定義すると、必要に応じて配置の妥当性を検証することができます。検証では、システム内のアプリケーションが連結されていることを確認し、アプリケーションが論理データセンター ダイアグラムで指定したアプリケーション制約を満たしていること、そして論理サーバーが ACD とシステム ダイアグラムで指定したホスティング制約を満たしていることをチェックします。
検証ではまた、必要な通信経路が存在することを確認し、正しい通信プロトコルが存在し、アプリケーションとホスト サーバー間で互換性があるかどうかも判断します。
以下の図に、サンプル配置 (デプロイメント) ダイアグラムを示します。
.gif)
図 5 Deployment Designer
すべての検証エラーは Visual Studio エラー リストに表示されます。このリストには、エラーを修正、調整するためのナビゲーション機構があります。エラー リストでエラーをダブルクリックすると、Deployment Designer で適切なダイアグラムが開かれ、適切なアプリケーションまたは論理サーバーが選択され、修正すべき設定に移動するため、簡単にその設定を修正することができます。これにより、配置 (デプロイメント) 前に、システムを完全に実装していなくても、構成上のエラーを修正できます。また、Deployment Designer から、アプリケーションおよびデータセンターの構成において必要となる全ての設定に関するレポートを生成し、カスタム配置 (デプロイメント) ツール用のスクリプトを作成するのに使用することができます。
拡張性
Distributed System Designers には、パートナーがプラットフォームを拡張したり、他のプロトコルのサポートや特別な種類のアプリケーションと論理サーバーを追加できる拡張モデルが含まれます。
Visual Studio 2005 Team System との統合
Distributed System Designers では、分散アプリケーションの設計と配置 (デプロイメント) をサポートします。この Designers は、いくつかの点で他の Visual Studio 2005 Team System ツールと統合されています。
-
Distributed System Designers を使用して配置 (デプロイメント) を設計、開発、およびテストした分散システム開発プロジェクトは、Visual Studio 2005 Portfolio Management Tools を使用して管理します。
-
アプリケーションは、Visual Studio 2005 Team Test を使用し単体テストが行われます。
-
Visual Studio 2005 Team Foundation Server と Visual Studio 2005 Team Foundation Client により、ソース コード 管理とワーク アイテムトラッキングが提供されます。
まとめ
Distributed System Designers は 4 つのデザイナから構成されており、サービス指向アーキテクチャに基づいて分散システムの設計および検証を行う際のプロセスを簡略化します。
-
サービス指向アーキテクチャ - サービス指向アーキテクチャは、次世代の分散アプリケーションの基盤になると期待されていますが、サービス毎に断片化されているため、全体の構造を視覚化したり、設計するのは困難です。Application Connection Designer と System Designer は、アプリケーション アーキテクト、デザイナ、および開発者がサービス指向システム全体を視覚化し、適切な設計を行うのに役立ちます。
-
運用を考慮した設計 - Distributed System Designers では、システムのアプリケーション層およびアプリケーション ホスト層を表すダイアグラムを作成します。これらのダイアグラムは、アプリケーションの設計および配置 (デプロイメント) を行う担当者が、アプリケーションが最初に配置 (デプロイメント) されてからその後の運用を行っている間、そのアプリケーションを変更する際に、運用上の要件に対しその構成が妥当かどうかを検証するのに役立ちます。
-
実行可能な設計 - Distributed System Designers の統合モデルにより、アプリケーションおよびインフラストラクチャ アーキテクトはデザイン プロセスでさまざまなメタデータを取り込むことが可能です。このメタデータは、コードを生成したり、アプリケーション デザインをデータセンターの定義に照らして検証するのに使用できます。このモデルにより、アプリケーション アーキテクトは正しく厳密な設計を行うことができます。デザインはコードと同期化され、アプリケーションが存続している間、その関連を維持します。これにより、アプリケーション アーキテクトは、必要に応じてアプリケーションを保守および拡張できます。
Distributed System Designers を使用すると、企業は Web サービスベースのサービス指向アプリケーションを正常に構築して、データセンターに配置 (デプロイメント) するためにアプリケーションを効率的に準備できます。
Visual Studio Team System の詳細については、以下のトピックを参照してください。
