第2回　三層アーキテクチャとは

三層アーキテクチャモデル

今回は従来から一般的に言われている三層アーキテクチャモデルについて説明します。

三層アーキテクチャはメインフレーム上でのレガシーシステム時代から提唱され、さまざまな形になってきています。まず、プレゼンテーションレイヤ、ビジネスレイヤ、データレイヤの三層に分ける代表的な例を説明いたします。

① プレゼンテーションレイヤ層

この階層はシステム操作するユーザに対してのユーザへのインターフェイスを提供します。

この階層にはユーザインターフェイスコンポーネントおよびユーザインターフェイスプロセスコンポーネントが含まれます。

② ビジネスレイヤ層

この階層にはプレゼンテーションレイヤからデータなどが渡され、業務処理を実行します。

プレゼンテーションからのデータ授受をシンプルにかつ柔軟にするためにサービスインターフェイスを設計します。

ビジネスレイヤでは業務処理を実行するためビジネスワークフローやビジネスコンポーネント、ビジネスエンティティが配置されます。

サービスインターフェイスを経由してビジネスワークフローやビジネスコンポーネント、ビジネスエンティティへと処理は渡されます。

ビジネスエンティティはサービスインターフェイスから渡されたデータや後述するデータレイヤから来たデータをビジネスレイヤで扱えるデータ、つまりエンティティとして表現するために使用されます。

ビジネスコンポーネントは、業務に依存した業務ロジックを作り込むコンポーネントです。

ビジネスワークフローはビジネスエンティティをどのビジネスコンポーネントへ渡すか、ビジネスコンポーネントの処理の順番など、調整、実行を行います。

③ データレイヤ層

この階層にはデータソースやサービスとのデータやり取りや接続の手順、管理、制御を行います。

この階層にはデータアクセスロジックコンポーネントやサービスエージェントが含まれます。

データアクセスロジックコンポーネントはデータソースとの接続の手順、データのやり取り、接続資源の管理などを行います。この際、接続するデータソースはDBであったり、ファイルであったりします。接続先によって接続手順は異なるため、これらの煩わしさをビジネスレイヤに意識させないようにデータレイヤに隠ぺいします。サービスエージェントもデータアクセスロジックコンポーネントと同様ですが、COM+サービスやWebサービスを経由して他システムに接続するために使われます。そのため、それぞれのサービスのインターフェイスにあった方法で接続する必要があります。

各コンポーネントについて

各レイヤは様々なコンポーネントで構成されています。前項ではそれぞれのレイヤの中に含まれるコンポーネントの種類について大まかな説明を行いました。ここではそれぞれのコンポーネントについて解説していきます。

プレゼンテーションレイヤ

① ユーザインターフェイスコンポーネント

ユーザインターフェイスコンポーネントはユーザがアプリケーションを直接操作し、表示を見る部分です。ここでの入力データのチェックは、アプリケーションの入力として相応しいデータであるかなどをチェックします。

ユーザに表示を見せる、操作させるという部分では、今日では様々な表現方法や入力インターフェイスが登場しています。ディスクトップ上で動作するWindows アプリケーションと同等の表現方法がWebアプリケーションのユーザインターフェイスであるブラウザ上で表現できるようになってきています。しかし、それはWebサーバおよびネットワークなどのインフラストラクチャの負荷が多くなる傾向が強く、どこまでを追及していくかが問題となってきています。

一画面内に多くの項目やデータを表示させることで、ユーザにより多くの情報を提供したり、リストボックスコントロールやダイアログボックスなどを使用してユーザの入力を制限、補助したりすることも可能です。しかし、これらを多用するとクライアント画面内のデータ量が多くなり、ネットワークのトラフィック量を増加させることになります。

また、Webアプリケーションでは特にネットワークのトラフィックを意識する必要があります。拠点間などの回線速度の遅いWANを使用した環境で使用されるアプリケーションではトラフィックをできるだけ少なくする必要があります。.NETを用いたWebアプリケーションではASP.NETを使用してWeb画面を構築する場合がほとんどです。その際、ViewStateプロパティを有効にしていると画面コントロールと画面内のデータのすべてをクライアントとWebサーバ（IIS）間で通信することとなり、トラフィック量が大幅に増加します。

② ユーザインターフェイスプロセスコンポーネント

ユーザインターフェイスプロセスコンポーネントはユーザインターフェイスコンポーネントでのデータの入力を補助したり、入力データの整合性を保つためのデータ入力を促したり、入力の順序に従い操作を行わせるようにしたりします。また、このコンポーネントでは表示される画面の移動や補助画面の表示なども行います。

その際の画面間のデータの受け渡しや一時的なデータ保持方法についてもこのコンポーネントで実現する必要があります。

また、このコンポーネントでは入力されたデータをビジネスレイヤのサービスインターフェイスに渡すようにデータの整形等も行います。

WebアプリケーションではセッションデータをWebサーバ内やステートサーバ等に保持する手法がよく使用されますが、多くのセッションデータを保持しているとそれだけ、サーバの資源を多く使用することとなります。ほかの画面やシステムとの連携のためにデータを保持するのであれば、一時データベーステーブルへの格納などを検討する必要があります。

昨今話題になっているWindows Presentation Foundation（以降WPFと略します）などもこのコンポーネントの一つです。

WPFを用いると、Microsoft社のプレゼンテーションでよくみられるような、複数の画面を立体的に見せたり、複数の動画を同時に表示したりすることができますが、トラフィック量が大幅に増加します。

これらは非常に素晴らしい表現力で魅力的な画面を作成することができますが、ネットワーク環境やサーバマシンおよびクライアントマシンの性能を考慮して採用を検討する必要があります。

ビジネスレイヤ

③ サービスインターフェイス

サービスインターフェイスはビジネスロジックをサービスとして公開するために必要なインターフェイス（メッセージ形式、手順、データ形式、プロトコル、セキュリティ、例外のリターン、ログの出力など）を作成する必要があります。そのため、サービスインターフェイスは一般的にはファサードとして実装されます。

サービスとして公開されているビジネスロジックは様々なクライアントアプリケーションから様々な方法で呼び出される可能性があるため、それらの呼び出し方法にあったサービスインターフェイスを準備する必要があります。そのため、必要となる通信形式、データ構造、セキュリティ要件、プロセス方式はサービスにより発行されるコントラクトの一部として定義される必要があります。

サービスインターフェイスでは、サービスとして公開した先から来たデータをビジネスレイヤ内で使用できるデータの型へ変換し、データのエラーチェックなどを行います。

ここでのデータチェックは正規化や正当性チェックのみで論理チェックなどはビジネスコンポーネントなどで行われます。しかし、ここでのチェックを怠るとビジネスコンポーネントやデータレイヤでの想定外の処理やデータ破壊、外部からの攻撃などを受ける可能性があります。

そのため、サービスインターフェイスでは単にサービスを公開するためのインターフェイスとしてだけでなく、外部からの攻撃を防御する仕組みを持たせる必要があります。

Webアプリケーションでは通信プロトコルとしては、HTTPやHTTPSがよく使用されています。また、WebサービスではSOAPが使用されています。

しかし、.NET Framework 3.0までのWebサービスではJ2EEなどの.NET Framework以外の技術で公開されたWebサービスとの接続は難しく、相互接続は困難でした。Windowsアプリケーションでは従来からのTCP/IPやUDPを用いた通信や.NET Remotingなどをその都度選択して通信を行っていました。Windowsアプリケーションでも既存のVisual Basic 6.0などのレガシーアプリケーションとの通信にはCOM+オブジェクトを経由して接続する必要がありました。

最新の.NET Framework 3.5では、Windows Communication Foundation（以降WCFと略します）を用いてWindows アプリケーションでもWebアプリケーションでも同等に使用できる、型指定のないメッセージ非同期受け渡しの基本機能が提供されています。また、既存のメッセージキュー（MSMQ⁠）⁠、COM+、ASP.NET Webサービス、Webサービス拡張（WSE: Web Services Enhancements⁠）⁠、およびJ2EEなどと接続する機能を提供しています。

WCFは開発の工数と手間を大きく削減できる技術ではありますが、必ず事前検証を行い、採用を検討する必要があります。これを怠るとWCFを使用する以前はソケットやHTTP、HTTPSなどで直接通信できていましたが、.NETではこれらを直接操作することが難しく、難易度はかなり高くなります。

④ ビジネスワークフロー

ビジネスワークフローはビジネスレイヤ内のデータの流れやビジネスロジックの順序を制御するために使用されます。

プレゼンテーションレイヤからのユーザデータはサービスインターフェイスを経由してビジネスロジックを実行するために使用されます。その際、ユーザデータの流れやビジネスロジックを、定義されたとおりの流れで処理されるように制御する必要があります。また、ビジネスワークフローではプロセスの開始から終了までを制御する必要があります。そのため、長時間プロセスについても制御を行えるような仕組みを考慮する必要があります。

.NET Framework 3.5ではWindows Workflow Foundation（以降WFと略します）を用いてこれらのプロセスの流れを制御することができます。WFを使用することにより、長時間プロセスや非同期のプロセスも制御することができます。しかし、これらはWCFとの連携が必要となる場合があり、必ず事前検証を行い、採用を検討する必要があります。

また、複数のプロセス（ビジネスコンポーネント）間でトランザクションを渡す必要がある場合などはプロトタイプを構築し、さまざまなタイミングや障害への対応を検討し、採用を検討する必要があります。

⑤ ビジネスコンポーネント

ビジネスコンポーネントはビジネスロジックそのものといえます。ビジネスプロセスは単一もしくは複数の処理で構成されます。複数の処理で構成される場合は、それぞれの処理結果を基に別の処理が実行される場合などがあります。これらを一連のビジネスルールとして実装し、ビジネスタスクとして実行する必要があります。これがビジネスコンポーネントです。

ビジネスコンポーネントは従来通りの手法で構築される場合が多いです。しかし、CPUのマルチ化やマルチスレッド化が進み、これらを有効に利用しながら並行処理で実行する技術が必要になってきています。

⑥ ビジネスエンティティ

ビジネスエンティティはビジネスコンポーネント間でデータをやり取りする際に定義されるものです。

ビジネスエンティティにはビジネスコンポーネントが使用するデータ構造として定義される場合や、アプリケーション内部で使用されるデータ構造が定義される場合もあります。

.NET FrameworkではハッシュテーブルやDataSet、DataTable、ArrayListなどをそのまま用いることが多いと思います。しかし、ここではビジネスコンポーネントやサービスインターフェイスで扱いやすい状態でデータを定義することが必要になってきます。たとえば、WCF経由でJ2EEのWebサービスと接続するのにビジネスエンティティで型付きのDataSetで定義されていた場合、サービスインターフェイスで型変換を行う必要があります。逆にビジネスコンポーネント間でのデータ引き渡しにおいてビジネスエンティティで型なしのDataSetを定義していた場合、ビジネスコンポーネント内でDBに登録する前に型付きDataSetに変換する必要があります。このように、必要に応じたデータ構造で定義されている必要があります。

データレイヤ

⑦ データアクセスロジックコンポーネント

データアクセスロジックコンポーネントはデータストアへの接続、データのやり取り、接続状態の維持、データソースの例外情報の受け取り等を実装します。

これらのデータソースとのやり取りを一元管理することにより、データソースが変更になった場合でもビジネスレイヤへの影響を最小限にすることができます。また、接続状態を管理することで、データソースへの接続資源の有効利用、レスポンスの向上などを図ることができます。

データソースとのやり取りを本コンポーネント内に隠蔽することにより、データソースのセキュリティ確保も図ることができます。

データアクセスロジックコンポーネントについては以前から様々な議論がされています。「⁠DBのテーブルごとにコンポーネントを作成する手法」「⁠業務にあった形でコンポーネントを作成する手法」などです。これらは一長一短あり、どれが正解とは言い切れません。しかし、実際のアプリケーション構築では両方のよいところを採用しているのが実情のようです。

また、データアクセスについても常時接続型と非常時接続型の二つがあります。それぞれについても一長一短があり、たとえば参照系のみであれば常時接続型として、データを高速に表示させる方式を検討するとか、更新系の場合は非常時接続型を用いてデータの排他時間を短縮するなどを事前に検討する必要があります。

⑧ サービスエージェント

サービスエージェントはビジネスレイヤでアプリケーション外部のサービスを利用する際に、そのサービスと通信するための機能、ロジックを実装します。これらの機能やロジックには外部サービスのデータ形式の変換やデータ構造の変換なども含まれます。

サービスエージェントは接続する外部サービスごとに作成する必要があり、外部サービスの仕様変更やインターフェイス変更などの影響をビジネスレイヤに及ぼさないようにする必要があります。

サービスエージェントについてもWCFを使用することができる場合があります。これらについても接続先ごとのプロトタイプなどを構築して、検証、考慮して採用を検討する必要があります。

次回はプレゼンテーション層に含まれるコンポーネントの設計について説明します。