連載 アプリケーション・アーキテクチャ・ガイド2.0解説 第5回 典型的なアプリケーションのパターン（前編） 日本ユニシス　猪股 健太郎 2009/10/16
Page1 Page2 Page3

■リッチ・クライアント・アプリケーション

　リッチ・クライアント・アプリケーションは、クライアント上で動作するアプリケーションであり、応答性や対話性が高い、リッチなユーザー体験を提供できる。また、アプリケーションの利用シナリオに適したネットワーク接続性もサポートできる。

　スタンドアロンで動作するため、ネットワーク接続が必要ない場合もあれば、クライアント・サーバ型アーキテクチャをとる場合もある。後者の場合は、常時通信するアプリケーションや、一時的に通信すればよいアプリケーションなどがある。

リッチ・クライアント・アプリケーションの典型的な構造

　リッチ・クライアント・アプリケーションのアーキテクチャ・フレームとして、AAGでは下記のものを取り上げている。ここでは、その中から「通信」「UI合成」「構成管理」「データ・アクセス層」「状態管理」「ワークフロー」の6つを説明しよう。

リッチ・クライアント・アプリケーションのアーキテクチャ・フレーム

通信

UI合成

構成管理

データ・アクセス層

例外管理

状態管理

ワークフロー

プレゼンテーション層

ビジネス層

保守性

セキュリティ

データ処理

ネットワーク接続性

●通信

　リッチ・クライアント・アプリケーションでは、アプリケーション内の論理階層（ティア）やアプリケーション外のサービスと多種多様な通信が可能である。ただし、ビジネス層が同じ物理階層（ティア）に配置される場合は、単なるオブジェクト呼び出しとすべきである。

注意点：

• 異なる物理階層（ティア）と通信する場合は、可能な限りメッセージ・ベースの通信を選択する。
• 異なる物理階層（ティア）と通信する場合は、粒度の大きいインターフェイスを設計し、ネットワーク通信のオーバーヘッドを小さくする。
• オフライン処理をサポートする。接続状態を検知し、オフラインの場合はデータをキャッシュしておき、再度オンラインになったときにサーバと同期を取る。
• 機密情報を送受信する場合は、IPSecやSSLといった安全な通信チャネルを使ったり、データを暗号化したり、データに署名したりする。
• 多量のデータを送受信するアプリケーションでは、パフォーマンスやネットワーク帯域幅を考慮し、最適なプロトコルを選択する。

関連するパターン：

• 非同期コールバック
• サービス・ゲートウェイ
• サービス・ロケーター
• サービス・インターフェイス

●UI合成

　さまざまな種類の作業に対応した業務アプリケーションでは、複雑なUIがよく用いられるが、拡張性と保守性を高めるために、モジュールや画面を動的に読み込んでUIを作り上げるアーキテクチャを検討する。

注意点：

• 機能要件に基づいてUIの実装技術を決める。
• 抽象化を用いて、コンポーネント同士の依存関係を最小にする。
• UI合成の機構を正しく選択する。
• 再利用可能な部品を合成してUIのビューを作る。
• プレゼンテーション層のコンポーネント間でやり取りする場合は、Publish-Subscribeパターン（オブザーバパターン）を用いて結合度を下げる。

関連するパターン：

• 複合ビュー
• テンプレート・ビュー
• ツーステップ・ビュー
• オブザーバ

●構成管理

　ほとんどの場合、リッチ・クライアント・アプリケーションは起動時に構成情報を読み取る。このため、構成情報をローカルに置くのかサーバ上に置くのか、そして、実行時に変更した構成情報をどこに保存するかを決定する必要がある。

注意点：

• 変更される可能性がある情報を特定する。
• ユーザーごとに異なるのか、アプリケーションで共通なのかによって格納場所を決める。
• 機密情報については、通信チャネル、ローカルの保存場所、そしてメモリ上においても保護する。
• ローカルの構成情報をセキュリティ・ポリシーで上書きする仕組みを検討する。

関連するパターン：

• Provider（英語）

●データ・アクセス層

　リッチ・クライアント・アプリケーションでは、リモートの物理階層（ティア）に置かれたデータにアクセスする場合もあれば、ローカル・マシン上のデータにアクセスする場合もある。データ・アクセスはパフォーマンスに大きな影響を与えるため、アーキテクチャ設計の時点から注意が必要である。

注意点：

• データ・ソースから得られるデータが、クライアント・アプリケーションで扱いにくい形式（例えばバイナリ・フォーマット）である場合は、アプリケーションで扱いやすい形式にデータを変換する。
• クライアントが非常に多量のデータを扱う場合は、データをひとまとめにして非同期でロードし、ローカルにキャッシュするようにする。
• 可能な限り、データは非同期でロードする。
• 一時的接続型のシナリオでは、接続状況を確認し、接続されたときにデータをバッチ更新する機構を採用する。
• 複数のユーザーがデータを操作する場合は同時実行制御を行う。

関連するパターン：

• ドメイン・モデル
• Entity Translator（英語）
• データ転送オブジェクト

●状態管理

　リッチ・クライアント・アプリケーションでは、ネットワークに常時接続しているシナリオでも非接続のシナリオでも、ユーザー設定や一時的な内部データなどを保存したり読み出したりできなければならない。

注意点：

• アプリケーションがキャッシュすべきデータを特定し、データのサイズや、再取得のコストなどを調べておく。
• データ・サイズが大きい場合は、ローカル・ファイルに保持する。
• データがアプリケーションの起動時に必要であれば、ローカル・ファイルや分離ストレージに永続化しておく。
• 機密情報を保存する場合は、暗号化や署名などで保護する。
• 全ユーザーで共通の状態なのか、それとも個々のユーザーごとに異なるのかといった粒度を特定する。

関連するパターン：

• Context Object（英語）

●ワークフロー

　多段階操作やウィザード形式のUIをサポートする、ワークフローやビューフローを使ったリッチ・クライアント・アプリケーションもある。そのような機能を実装するに当たってはさまざまなパターンが考えられる。

注意点：

• 多段階の業務プロセスや、長期にわたる業務プロセスに関係するビジネス・コンポーネントでは、ワークフローを使う。
• ワークフローやビューフローの要件が単純であれば、カスタム・コードで実装する。
• ワークフローやビューフローの要件が複雑であれば、プラットフォームで利用可能なワークフロー実行エンジンを使って実装する。
• ワークフローやビューフローのロジックは、ビジネス・ワークフロー・コンポーネントまたはUIプロセス・コンポーネントとして独立させる。
• ワークフローのエラーをどう扱い、どのように表示するかの方針を決定する。
• 途中で止まってしまったフローをどのように扱うかの方針を決定する。

■

　リッチ・クライアント・アプリケーションのまとめとして、リッチ・クライアント・アプリケーションの構築に利用できる実装テクノロジを表にまとめる。

テクノロジ	利用シナリオ
Windowフォーム	応答性の良いアプリケーションをVisual Studioでデザインする場合
WPF	リッチなメディアやグラフィックをサポートする場合
XBAP	アプリケーションをWebサーバからダウンロードして、インストールせずに実行する場合
OBA（Officeビジネス・アプリケーション）	主にドキュメント・ベースのアプリケーションや、レポーティングに使うアプリケーションの場合
Smart Client Software Factory（英語）	WindowsフォームでUI合成を実現する場合
Composite Application Guidance for WPF（英語）	WPFでUI合成を実現する場合
SNMPまたはWMI	リモート・モニタリングを実現する場合
リッチ・クライアント・アプリケーションの構築に利用できる実装テクノロジ

■

　次回は、典型的なアプリケーションの続きとして、「サービス」「モバイル・アプリケーション」「OBA（Officeビジネス・アプリケーション）」「SharePoint業務アプリケーション」を説明していく。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第5回 典型的なアプリケーションのパターン（前編）
	1．Webアプリケーション
	2．RIA（リッチ・インターネット・アプリケーション）
	3．リッチ・クライアント・アプリケーション

「アプリケーション・アーキテクチャ・ガイド2.0解説」

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