Team Edition for Software Architects アプリケーション デザイナの概要、パート 1
Tony Loton
LOTONtech Limited
February 2005
日本語版最終更新日 2005 年 6 月 6 日
概要: サービス指向システムのデザインを始めとした、アプリケーション デザイナの実用的な利用方法について概要を説明します。
ApplicationDesignerExample.exe ファイルのダウンロード
目次
はじめに
分散システム デザイナの 1 つとしてのアプリケーション デザイナ
分散システム ソリューションの作成
アプリケーションとプロトタイプ
サービス指向アプリケーションのデザイン
まとめ
関連情報：
はじめに
この記事では、Visual Studio 2005 Team Edition for Software Architects が提供する分散システム デザイナにふくまれる 4 つのデザイナのうちの 1 つであるアプリケーション デザイナについて概要を説明します。
まず、アプリケーション デザイナが、他のビジュアル デザイナと緊密に連携して機能するしくみについて説明します。 次に、筆者が考案したサービス指向に基づく通貨換算アプリケーションを例に、具体的なアプリケーション デザインの方法について解説します。 具体的、というのは、Visual Studio 2005 Team Edition for Software Architects を使用して実際に行った分散システムのデザイン方法についてこれから説明する、ということを意味しています。
この連載のパート 2 では、パート 1 でデザインした通貨換算アプリケーションの実装について説明する予定です。 最後に、外部 Web サービスや外部データベースなど、他のアプリケーション タイプを全体のデザインに組み込む方法について解説します。
分散システム デザイナの 1 つとしてのアプリケーション デザイナ
Visual Studio 2005 Team Edition for Software Architects には、分散システム デザイナと総称される 4 つのビジュアル デザイナが用意されています。 図 1 に示すように、これらのデザイナ（アプリケーションデザイナ、システムデザイナ、論理データセンターデザイナ、配置デザイナ）は連携して動作します。そのため、個々のデザイナについて掘り下げる前に、各デザイナ間の関係について確認することが重要となります。
図 1. 分散システム デザイナ
アプリケーション デザイナを使用すると、分散システムを構成するアプリケーションを定義できます。 次に、このアプリケーション定義をシステム デザイナで使用して、配置可能なシステムにアプリケーションを組み込むことができます。 さらに、配置デザイナを使用して、システムの配置を評価できます。
それとは別に、論理データセンター デザイナを使用すると、(システムに組み込まれた) アプリケーションを配置するターゲット データセンターの論理表現 (サーバーやネットワークの論理的な構成表現) を定義できます。最後に、システム デザイナによって作成されたシステム定義セットと、論理データセンター デザイナによる論理サーバー定義セットを入力にし、配置デザイナが描かれます。
この連載記事では、図に示す分散システム デザイナの構成ツールすべてについて説明します。 このパート 1 では、アプリケーション デザイナを中心に解説します。
分散システム ソリューションの作成
アプリケーション デザイナによる分散システムのデザインを始める前に、Visual Studio で分散システム ソリューションを作成するか、または既存のソリューションにアプリケーション ダイアグラムを追加する必要があります。 分散システム ソリューションは簡単に作成できます。 新規プロジェクトを作成する際に、「分散システム ソリューション」のプロジェクト タイプから「分散システム」と名前のついたテンプレートを選択するだけです。
作成直後の新しいソリューションには、.ad 拡張子が付いた、ソリューションと同じ名前のアプリケーション ダイアグラムが含まれています。 ソリューションに ApplicationDesign という名前を付けた場合、アプリケーション ダイアグラムの名前は ApplicationDesign.ad となります。 ソリューションに作成可能なアプリケーション ダイアグラムは 1 つだけです。これは、アプリケーション ダイアグラムが、相互接続型アプリケーションに関するソリューションの全体構造を記述するものだからです。 ただし、システム、配置、および論理データセンターのダイアグラムについては、同じソリューションの中に複数作成できます。
アプリケーションとプロトタイプ
アプリケーション デザイナでは、ASP.NET Web サービスに代表されるサービス指向アーキテクチャ (SOA) に沿ったアプリケーションのデザインに重点が置かれています。 アプリケーション デザイナのツールボックスにはアプリケーション プロトタイプが用意されており、ユーザーはこのプロトタイプを使用してアプリケーションのデザインを行うことができます。 各プロトタイプは、あらかじめ構成済みの基本アプリケーション タイプを表しています。 アプリケーション ダイアグラムにプロトタイプをドラッグすることで、そのプロトタイプの定義どおりに構成された、基本タイプのアプリケーションが作成されます。
ツールボックスには、ASP.NET をベースとしたプロトタイプが 2 種類用意されています。「ASP.NETWebService」とは、1 つ以上の Web サービス エンドポイントを持つ ASP.NET アプリケーションのことです。 そのため、「ASP.NETWebService」 プロトタイプを使用すると、Web サービスの既定のプロバイダ エンドポイントを持つ ASP.NET アプリケーションが作成されます。 「ASP.NETWebApplication」 プロトタイプは、Web コンテンツのエンドポイントを持つ ASP.NET アプリケーションの作成に使用されます。 このトピックでは、エンドポイントについて詳しく説明します。
以下のリストは、サポートされる他のアプリケーション タイプとその関連プロトタイプを示しています。
- Windows アプリケーション: 「WindowsApplication」 プロトタイプ
- Office アプリケーション: 「OfficeApplication」 プロトタイプ
- 外部またはサードパーティの Web サービス: 「ExternalWebService」 プロトタイプ
- 外部データベース: 「ExternalDatabase」 プロトタイプ
- BizTalk Web サービス: 「BizTalkWebService」 プロトタイプ
- ジェネリック アプリケーション (他のすべてのアプリケーション タイプ用): 「GenericApplication」 プロトタイプ
マイクロソフトまたはサードパーティが提供する追加的なアプリケーション タイプやプロトタイプを読み込むこともできます。さらに、アプリケーションに追加したアプリケーションまたはエンドポイントの既存の基本タイプを使用して、ユーザー定義のカスタム プロトタイプを作成することもできます。
マイクロソフトが提供するアプリケーション タイプには、ASP.NET アプリケーションや Windows アプリケーションなどのように、コードの完全な双方向性をサポートしているものがあります。 つまり、これらのアプリケーション タイプでは、コードに加えられた変更がデザイナに反映されるとともに、デザイナに加えられた変更がコードに反映されます。 さらに、外部 Web サービス、BizTalk Web サービス、外部データベースなど、アプリケーションから外部リソースへの接続を定義するのに役立つアプリケーション タイプもあります。 GenericApplication プロトタイプを使用すると、Unix アプリケーションや CICS トランザクション アプリケーションなど、サポートされていないアプリケーションを簡単に作成できます。 これは基本的な拡張機能です。 より高度な拡張機能として、SDK を使用して新しい基本タイプやプロトタイプの作成を行うこともできます。 アプリケーション デザイナのプロトタイプは多くの点で UML (Unified Modeling Language) に似ていますが、UML が提供する単純なラベリング メカニズムと比べてはるかに強力な機能を提供します。
サービス指向アプリケーションのデザイン
実例を使ってアプリケーション デザイナの使用方法を見ていきましょう。 この例では、単純化のため、「ASP.NETWebApplication」 プロトタイプと 「ASP.NETWebService」 プロトタイプのみを使用して、サービス指向のシステムをデザインします。 これら以外のアプリケーション タイプを組み込んだデザインについては後で説明します。
図 2 はここで考えているデザインの全体像を表しています。
図 2. サービス指向アーキテクチャのためのアプリケーション ダイアグラム
フロント エンドとなる 2 つの ASP.NET Web アプリケーションは、ある金額を特定の通貨に換算します。 DollarExchangeApp は、ある通貨で指定された金額を米ドルに換算するフォームを提供します。一方、EuroExchangeApp は、指定された金額をユーロに換算します。
このデザインで次のレイヤを構成する ASP.NET Web アプリケーションは、以下の 2 つの Web サービスを公開します。
- 米ドルへの換算をサポートする Web サービス (USDollarService)
- ユーロへの換算をサポートする Web サービス (EuroService)
このデザインでは専用のフロントエンド アプリケーションによって各 Web サービスが公開されていますが、すべての通貨を換算する単一の ExchangeApp フロントエンド アプリケーションを作成して、そのアプリケーションから両方の Web サービスに接続するのが完全なデザインです。
通貨の換算はすべて、現行の市場為替レートに依存しています。そのため、このデザインでは次のレイヤに ASP.NET Web アプリケーションを組み込み、為替レートを提供する Web サービスを公開します。 ExchangeRateService はサードパーティが提供する Web サービスで実装することも考えられますが、今回は BureauDeChange アプリケーションを使用して独自に実装します。
デザイン上の考慮事項
この例は、サービス指向アーキテクチャ (SOA) における 2 つの重要な原則を示しています。 1 つは、サービスがその他のサービスを利用するという原則です。 もう 1 つは、それらのサービスが、アプリケーションの固有性、ビジネスの一般性、およびテクノロジの依存性に従って階層化されるという原則です。
CurrencyConverter は、DollarExchangeApp および EuroExchangeApp プレゼンテーション アプリケーションに対して、アプリケーション固有のサービスを提供します。 その一方で CurrencyConverter は、BureauDeChange アプリケーションが提供する ExchangeRateService という、より一般的なサービスを利用します。
この例は、CurrencyConverter という単一のアプリケーションが、複数のプロバイダ エンドポイントを使用することで、複数のサービスをサポートできるということも示しています。これは、単一のコンポーネントによる複数のインターフェイスの公開という UML のコンセプトを反映しています。
アプリケーションのデザイン
前述のように、ツールボックスからダイアグラムにアプリケーション プロトタイプをドラッグすることによって、アプリケーション デザインが作成されます。 この例では、2 つの「ASP.NETWebApplication」 プロトタイプ (DollarExchangeApp および EuroExchangeApp 用) と 2 つの 「ASP.NETWebService」 プロトタイプ (CurrencyConverter および BureauDeChange 用) をドラッグしました。 それにもかかわらず、ダイアグラムに表示されるすべてのアプリケーションに "ASP.NETWebApplication" というラベルが付けられていることを不思議に思うかもしれません。
ここでの微妙な違いは、「ASP.NETWebApplication」 プロトタイプをデザイン画面にドラッグしたときには Web コンテンツの既定のエンドポイントが追加され、「ASP.NETWebService」 をドラッグしたときには Web サービスの既定のエンドポイントが追加されるということです。 したがって、「ASP.NETWebService」 プロトタイプは実質的には 「ASP.NETWebApplication」 プロトタイプであり、便宜上 Web コンテンツのエンドポイントを削除して Web サービスのエンドポイントを追加したものなのです。
メモ 既存のプロトタイプを基に独自のアプリケーション プロトタイプを作成して、ツールボックスに追加できます。 ただし、この記事の範囲を超えるため、詳細については割愛します。
次に、先ほど話題にしたエンドポイントの定義を行います。
エンドポイントと接続
アプリケーションはエンドポイントを介して通信します。相互接続された 2 つのアプリケーションの場合、接続の一方の端点にプロバイダ エンドポイントを、もう一方の端点にコンシューマ エンドポイントを置く必要があります。
BureauDeChange アプリケーションには Web サービスの既定のプロバイダ エンドポイントがあり、その名前を ExchangeRateService に変更しています。 このプロバイダ エンドポイントから CurrencyConverter アプリケーションへと、接続ラインを ALT キーを押しながらドラッグするという単純な操作で、CurrencyConverter アプリケーションへの接続を作成しました。 これにより CurrencyConverter のコンシューマ エンドポイントが自動的に作成されます。
CurrencyConverter アプリケーションには、Web サービスの既定のエンドポイントがあります。このエンドポイントの名前を USDollarService に変更し、上記と同じ方法で DollarExchangeApp に接続しました。 ツールボックスから CurrencyConverter にもう 1 つ Web サービスのエンドポイントを追加し、このエンドポイントの名前を EuroService に変更して、EuroExchangeApp に接続しています。
DollarExchangeApp と EuroExchangeApp にあった Web コンテンツの既定のプロバイダ エンドポイントは削除しています。この例では必要ないからです。
メモ ASP.NET Web アプリケーションには、Web サービスまたは Web コンテンツのエンドポイントをいくつでも作成できます。これは、ASP.NETWebApplication を基にしたアプリケーションでも、ASP.NETWebService を基にしたアプリケーションでも同じです。 結局のところ、どちらも Web アプリケーションには変わりないからです。
Web サービスの詳細
ASP.NET アプリケーションの Web サービス プロバイダ エンドポイントを右クリックして [コンテキスト] メニューをポイントし、[操作の定義] をクリックすると、[Webサービスの詳細情報] (Web Service Details) ウィンドウが表示され、その Web サービスに定義された操作の確認と変更を行うことができます。
図 3 に示すように、この Web サービスでは getExchangeRate 操作を定義しています。この操作は、String パラメータで指定された 2 つの通貨コードを基に倍精度浮動小数点型の値 (為替レートの換算要素) を返します。
図 3. ExchangeRateService に関する Web サービスの詳細
[<操作の追加>] (add operation) インジケータおよび [<パラメータの追加>] (add parameter) インジケータをクリックすると、必要に応じて操作やパラメータを追加できます。
たとえば、図 4 に示すように USDollarService Web サービスの 2 つの操作を指定しています。これらの操作では、ユーロまたは英ポンド建ての金額が米ドルに換算されます。
図 4. USDollarService に関する Web サービスの詳細
図では示しませんが、EuroService に関する Web サービスの詳細は、fromEuros 操作を fromDollars 操作で置き換えたことを除いて、USDollarService に関する Web サービスの詳細情報と同じです。
演習
この記事で提供した情報を参考にすれば、Microsoft Visual Studio 2005 December CTP (またはこれ移行にリリースされた Beta 2 日本語版などのバージョン) を使用して、このアプリケーションのデザインを読者自身で行えることと思います。 自身でのデザインが困難に感じられる場合は、この記事付属のサンプルをダウンロードして読み込むこともできます。 分散システム ソリューションを新規作成し、既定のアプリケーション ダイアグラム (.ad) ファイルを削除します。そして、[既存項目の追加] オプションを使用してサンプルの ApplicationDesign.ad ファイルを追加します。
設定と制約
Web サービス プロバイダ エンドポイントに関する Web サービスの詳細を確認および変更できたように、エンドポイントまたはアプリケーション全体に関する設定と制約の確認および変更も可能です。 設定では、アプリケーションの動作やランタイム環境の制御を行います。 アプリケーションにおける制約では、アプリケーションをホストする論理サーバーのタイプを指定します。 エンドポイントにおける制約では、アプリケーションのエンドポイントに連結する論理サーバーのエンドポイントのタイプを指定します。 CurrencyConverter アプリケーションの設定と制約を図 5 に示します。このアプリケーションのホストは、既定で IIS Web サーバーに指定されています。
図 5. CurrencyConverter の設定と制約
これは、論理データセンター ダイアグラム (以降の連載記事で説明します) 上の論理サーバーが表すサーバーにアプリケーションを配置する場合、サーバーに対して適切な IIS Web サーバーの設定を行う必要があるということを意味しています。 適切に設定されない場合は制約が満たされず、アプリケーションをサーバーに正しく配置できません。
図 5 では、オペレーティング システムの制約が選択されていません。IISWebServer の制約が満たされる限り、任意のオペレーティング システムを実行しているサーバーにこの Web アプリケーションを配置できるためです。
エンドポイントに対する代表的な制約として WebSiteEndpoint 制約があります。これは、Web サービスのエンドポイントを持つアプリケーション (CurrencyConverter) が Web サイトのエンドポイントを持つサーバーにホストされる場合に適用される制約です。
設定と制約エディタについては、システム デザイナに関する記事の中で再度取り上げます。このエディタを使用すると、アプリケーションに対する設定をオーバーライドできます。 また、後続の連載記事ではこれらの値の設定に関する事項を詳しく解説し、その際、配置デザイナを使用してターゲット データセンターでのアプリケーション システムの配置を評価する方法について説明します。
まとめ
この記事の図 1 に示すように、アプリケーション デザイナは Team Edition for Software Architects を構成するピースの 1 つです。アプリケーションのデザインを行う際に、このツールが非常に有用であることが理解できると思います。
Tony Loton は、LOTONtech Limited  のプリンシパル コンサルタント兼ディレクタ、Cogenture のプリンシパル コンサルタント兼マイクロソフト部門ヘッド、英国放送大学の準講師など、多くの肩書きを持つ MCP です。 現在は、2005 年夏に Wiley/Wrox より発刊予定の『Professional Visual Studio 2005 Team System』(ISBN 0764584367) を共同執筆中です。
|
