連載 アプリケーション・アーキテクチャ設計入門 第5回（最終回）　物理配置および運用上の要求 日本ユニシス　猪股 健太郎 2004/02/14
Page1 Page2 Page3 Page4

コンポーネントの配置パターン

　ここでは、いくつかの配置パターンと、そのメリット／デメリット、実現に要求される事柄を解説する。もちろん、配置パターンにはさまざまなバリエーションが考えられるが、それらすべてを取り上げることはしない。

　なお、ここで例示する図にはいくつかのコンポーネントが描かれているが、1つのコンポーネントが1つのアセンブリに対応しているわけではないことに注意してほしい。

■Webベースのユーザー・インターフェイス

− ビジネス・ロジックがWebファームにある場合 −

　すべてのアプリケーション・コンポーネントがWebファーム上に置かれている。データアクセス・ロジック・コンポーネントがWebファームに置かれているため、DataReaderオブジェクトを利用することもできる。リモート呼び出しが少ないのでパフォーマンスは最高である。

Webペースのユーザー・インターフェイス

− ビジネス・ロジックがWebファームにある場合 −

• クライアントはファイアウォールを通してWebファームにアクセスする。

• WebファームはASP.NETのページを所持し、ビジネス・コンポーネントをサービス・コンポーネント（ServicedComponentオブジェクト）としてホストする。

• Webファームからデータベースへのアクセスはファイアウォールを通す。Webファームはデータベースのクライアント・ライブラリを所持し、データベース接続文字列を管理する。

• ServicedComponentオブジェクトでCOM+のトランザクション機能を使っている場合は、データソースに接続するためにでリモート・プロシージャ・コール（RPC）のポートを開いておく。

− ビジネス・ロジックがアプリケーション・ファームにある場合 −

　ビジネス・コンポーネントとデータアクセス・ロジック・コンポーネントがWebファームとは別のアプリケーション・ファームに置かれている。Webファームとアプリケーション・ファームとでそれぞれリソースに関する処理が多く発生する場合は、スケーラビリティが向上する可能性もある。

Webペースのユーザー・インターフェイス

− ビジネス・ロジックがアプリケーション・ファームにある場合 −

　実現に要求される事柄は、以下を除いて前述のパターンと共通する。

• WebファームはASP.NETのページとユーザー・プロセス・コンポーネントを所持する。この場合DataReaderオブジェクトを使うメリットはない。

• すべてのビジネス・コンポーネントはアプリケーション・ファームに置かれ、ファイアウォールを通してアクセスされる。ファイアウォールで何番のポートを開ける必要があるかは、通信チャネルの選択に依存する。

• アプリケーション・ファームはデータベースのクライアント・ライブラリを所持し、データベース接続文字列を管理する。

■リッチ・クライアントのユーザー・インターフェイス

− リモート・コンポーネントを呼び出す場合 −

　このような構成は、主にイントラネット内部で利用される。

リッチ・クライアントのユーザー・インターフェイス

− リモート・コンポーネントを呼び出す場合 −

• リッチ・クライアントにはユーザー・インターフェイス・コンポーネントとユーザー・プロセス・コンポーネントが配置されている。

• ファイアウォールとは、大規模データセンター以外ではどちらか一方だけ使われることが多い。

• ファイアウォールで何番のポートを開ける必要があるかは、通信チャネルの選択に依存する。

• アプリケーション・ファームはほかのクライアントと共有される場合もある。

− XML Webサービスを呼び出す場合 −

　前述のパターンと違い、このような構成はインターネット上でも用いられる。ただし、認証、承認、安全な通信などのセキュリティ面については特に気を使う必要がある。

リッチ・クライアントのユーザー・インターフェイス

− XML Webサービスを呼び出す場合 −

• アプリケーション・ファームにはXML Webサービス用のサービス・インターフェイスが置かれている。サービス・インターフェイスはアプリケーション・ファーム内のコンポーネントや、別のマシンに配置されているリモート・コンポーネントを呼び出すことができる。

• リッチ・クライアントは標準的なプロトコルとフォーマットでサーバにアクセスする。

■複数のサービスを統合して1つのサービスにする

− ビジネス・ロジックがWebファームにある場合 −

　サービス・インターフェイスやサービス・エージェントが、ビジネス・コンポーネントと同じ場所に配置されている。

サービス統合

− ビジネス・ロジックがWebファームにある場合 −

• アプリケーションの呼び出し元はファイアウォールを通してWebファームにアクセスする。

• Webファームのサービス・インターフェイスはWebファーム内のコンポーネントを呼び出すことができる。

• サービス・エージェントがメッセージ・キューを使う場合は、Webファームの負荷分散によりクラスタ構成が効果的に働かない。

• データソースの呼び出しと内部サービスの呼び出しはファーム内のどこからでも開始される。ファイアウォールは外向きの呼び出しを通過させる必要がある。インターネット・データセンターでは、外向きの呼び出しは、独立したファイアウォールを通る。

• Webファームからデータベースへのアクセスはファイアウォールを通す。Webファームはデータベースのクライアント・ライブラリを所持し、データベース接続文字列を管理する。

• ServicedComponentオブジェクトでCOM+のトランザクション機能を使っている場合は、データソースに接続するためにファイアウォールでリモート・プロシージャ・コール（RPC）のポートを開いておく。メッセージ・キューイングを使っている場合も同様に必要なポートを開けておく。

− ビジネス・ロジックがアプリケーション・ファームにある場合 −

　サービス・インターフェイスやサービス・エージェントが、ビジネス・コンポーネントと異なる場所に配置されている。サービス・エージェントでメッセージ・キューを使う場合、クラスタリング構成をとりながら負荷分散が可能になる。

サービス統合

− ビジネス・ロジックがアプリケーション・ファームにある場合 −

• Webファームにデータアクセス・ロジック・コンポーネントを置くことで、DataReaderオブジェクトを利用することもできる。その際は、ファイアウォールを通してデータベースにアクセスができるようにポートを開ける。セキュリティ上問題がある場合は、アプリケーション・ファーム上のコンポーネントをリモート起動する。

• インターネットを通して外部のサービスを呼び出すサービス・エージェントはWebファームに配置する。Webファームは要求受信時のファイアウォールと要求発信時のファイアウォールに分けられている。

■ビジネス・ワークフローをEAIクラスタに配置する

　ビジネス・ワークフローを保持するEAIクラスタを、アプリケーション用のインフラから独立させる。

EAIクラスタ

• ユーザー・インターフェイスがWebファームを呼び出す。Webファームはアプリケーション・ファーム上のビジネス・コンポーネントを呼び出す。ビジネス・コンポーネントはデータソースを呼び出したり、EAIクラスタを呼び出したりする。

• ビジネス・ワークフローが呼び出すビジネス・コンポーネントはEAIクラスタに配置することもできる。

• ビジネス・ワークフローは、Webファームやアプリケーション･ファームに配置されたコンポーネントをリモート呼び出しで利用することもできる。

• ビジネス・コンポーネントはEAIクラスタとアプリケーション・ファームとで同じものを配置することもできるが、管理コストはほかの場合と比べて大きくなる。

INDEX
	[連載] アプリケーション・アーキテクチャ設計入門
	第5回（最終回）　物理配置および運用上の要求
	1．物理階層（ティア）の構成要素
	2．コンポーネントの物理配置計画とコンポーネント分散境界
	3．コンポーネントの配置パターン
	4．運用上の要求に対する設計方針

　

「アプリケーション・アーキテクチャ設計入門」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）