連載 アプリケーション・アーキテクチャ設計入門 第4回　セキュリティ、運用管理、および通信のポリシーとその設計 日本ユニシス　猪股 健太郎 2003/12/20
Page1 Page2 Page3 Page4

運用管理ポリシー

　運用管理は、（1）例外管理、（2）モニタリング、（3）構成情報、（4）メタデータ、そして（5）サービスの位置を対象にする。

（1）例外管理

　アプリケーションは実行時の例外をキャッチし、もし可能なら解決し、解決不可能であれば意味のあるメッセージをユーザーに表示してデバッグのための情報をログに残す。.NETベースのアプリケーションにおける例外管理の詳細は、MSDNの「.NETにおける例外管理」を参照のこと。

　例外管理の設計・実装においては以下のガイドラインに従うべきである。

• 例外に何らかの情報を追加できるか、もしくは例外の種類に応じて処理を分岐させる必要がある場合は例外をキャッチすべきである。少なくとも論理層（レイヤ）の境界においては例外をキャッチすることを勧める

• アプリケーション例外を設計する際は、ApplicationExceptionクラス（System名前空間）から派生させる。ビジネス上の例外と技術的な例外の2つを区別することが多い

• 物理層（ティア）を越えて例外情報を伝播させる場合は、例外クラスはシリアライズ可能にしておく。ただしサービス・インターフェイスやユーザー・インターフェイス・コンポーネントでは例外情報を再構成することで、詳細な内部情報を伝播させないようにする

• 例外が起こったときに運用管理者や技術サポートなどに情報を伝える場合は、動作していたビジネス・プロセスの詳細情報や、例外が発生したマシンの情報などを追加する

●各コンポーネントにおける例外管理の設計と実装

−プレゼンテーション層−

　ユーザー・プロセス・コンポーネントでは、例外をキャッチして、操作を再実行するのか、問題をユーザーに知らせるのか、ユーザー・インターフェイスの遷移をコントロールするのかを決定する。

　ユーザー・インターフェイス・コンポーネントでは、問題を特定するのを助けるために例外情報を渡す。渡す先は中央のサーバや、ローカルのファイルや、イベント・ログなどが考えられる。

−ビジネス層−

　ビジネス・コンポーネントは、データ層のコンポーネントからビジネス上の例外か技術的な例外を受け取る。受け取った例外はそのまま呼び出し元に返すことを勧める。

　ビジネス・コンポーネントで新たに例外を起こす場合は、呼び出し元から受け取ったデータが不適切な場合と、制約違反が起こった場合である。新たに起こした例外も、そのまま呼び出し元に返すことを勧める。

−データ層−

　データ・アクセス・ロジック・コンポーネントでの例外は、ストアド・プロシージャから受け取ったビジネス例外か、データ･ストアで発生した技術例外である。データ・ストアから受け取った例外は、ビジネス例外または技術例外でラップするなど、アプリケーションで扱いやすい形に変換しなければならない。ここで発生した例外は必ずほかの場所に渡すべきである。その際、ビジネス例外と技術例外は別の機構が使われる場合もある。

（2）モニタリング

　モニタリングは、アプリケーションが正常に機能し、最適に動作していることを確認するために利用される。モニタリングの詳細なガイドラインは、MSDNの「.NET 分散型アプリケーション デザインにおける監視」を参照のこと。

　モニタリングには、以下の種類がある。

ヘルス管理	致命的なエラーや、問題の始まりを示唆する警告がないかを識別する。
SLAの順守	サービスは期待どおりに動作しているか、レスポンスタイムやスループットが範囲内かどうかを識別する。
スケール管理	ハードウェア・リソースは十分かを識別する。
ビジネス・モニタリング	ビジネス・プロセスが効率的に動作しているかを識別する。

　これらの適切な答えを得るために、アプリケーションやサービスの適切な個所でモニタリングを行う。

（3）構成情報

　システムは構成データの内容に基づいてセキュリティ、運用管理、通信の振る舞いを変更する。例えば、コンポーネントの位置、リソースの位置、外部サービスのURL、データベースの接続文字列などである。

　構成情報はさまざまな場所に配置できる。XML構成ファイル、SQL Serverなどのデータ・ストア、Active Directory、COM+サービスを利用するServicedComponentクラス（System.EnterpriseServices名前空間）のCOM+コンストラクション文字列、サード・パーティ製の構成管理ソリューションなどである。.NETの構成ファイルに書かれた構成データはアプリケーションから簡単にアクセスできる。

　構成データの置き場所を決定する際は、オフラインで利用できる必要があるか、そしてセキュリティに気を付けなければいけないかなどを考慮する。例えば、データベースへのクレデンシャルを含む接続文字列をXML構成ファイルなどに平文で保持すべきではない。

（4）メタデータ

　アプリケーションの自由度を高めるために、アプリケーションが自分自身に関する情報（メタデータ）を提供できるようにするとよい。設計時であれば、メタデータに基づいてコードを自動生成させるという利用法が考えられる。これはチーム間のコミュニケーションを助け、設計における各種規約を強制させるのに役立つ。しかし、開発の初期コストが高くなるし、自動生成の仕組みについての理解が必要とされる。一方、実行時であればメタデータに基づいて処理を実行するという利用法が考えられる。これはハード・コーディングを減らし、コンポーネント間の結合を疎にすることができる。ただし、実行時にメタデータを利用することは一般にパフォーマンスに悪影響を与えるので、開発の初期によくテストしておくべきだろう。

（5）サービスの位置

　オブジェクトやサービスを呼び出す際は、要求を受け付けるオブジェクトやサービスがどこに配備されているのかが分からないといけない。

　ローカルのアセンブリであれば、実行時にリンクすることができる。詳細は、MSDNの「ランタイムがアセンブリを検索する方法」を参照のこと。

　.NETリモート処理であれば、配備情報はアプリケーションにハード・コーディングすることもできるし、構成ファイルから読み取ることもできる。詳細は、MSDNの「構成ファイルを使用したリモート オブジェクトの登録」を参照のこと。

　非同期メッセージングのためにメッセージ・キューを利用する場合で、クライアントとサーバが同じドメインに位置するのであれば、キューの名前やIDなどで位置を特定できる。

　XML Webサービスであれば、URIはアプリケーション構成ファイルから動的に得ることもできるし、Windows Server 2003のプライベートUDDIリポジトリなどを使って検索することもできる。

INDEX
	[連載] アプリケーション・アーキテクチャ設計入門
	第4回　セキュリティ、運用管理、および通信のポリシーとその設計
	1．セキュリティ・ポリシーに関する設計：認証
	2．セキュリティ・ポリシーに関する設計：承認、安全な通信、プロファイル管理、監査
	3．運用管理ポリシーに関する設計
	4．通信ポリシーにおける非同期通信と同期通信

　

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

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