今回と次回はWebシステム基盤ではなく，その上で動作させるアプリケーションの設計について取り上げます。一般にWebシステム基盤の設計者（Webアーキテクト）とアプリケーションの設計者（アプリケーションSE）は別な担当者であることが多いのですが，アプリケーションはWebシステム基盤と整合性を取っていなければ正しく動きません。整合性を取るために，WebアーキテクトはアプリケーションSEの設計作業を支援することが不可欠で，設計支援するにはアプリケーション設計の知識が必要になります。

　アプリケーション設計のポイントは，「アプリケーション・アーキテクチャ」と「アプリケーションの標準化」です。この2点に重点を置いて説明します。

アプリケーション・アーキテクチャ

　システム全体を見て描いたアプリケーションの青写真を「アプリケーション・アーキテクチャ」と呼びます。アプリケーションを設計する際には，システム基盤と整合性を保つ形でアプリケーション・アーキテクチャを決定しなければなりません（図1）。

図1●システム基盤上にアプリケーションを構築する
図1●システム基盤上にアプリケーションを構築する
可用性，パフォーマンス，セキュリティ，運用の各設計に基づき，要素技術の組み合わせと配置を決定し，システム基盤を固める。システムとして完成させるには，このシステム基盤と整合性を保ってアプリケーションを設計・開発することが欠かせない

　アプリケーション・アーキテクチャを描く際に重要なのは，Webシステム基盤だけでは解決できない要件に対する解決策をきちんと盛り込むことです。ここでは仮に，「バグ修正や機能追加などが容易な，保守性の高いシステムにしたい」という要件であるという前提で話を進めます。この場合，いくらシステム基盤でモジュール化や構造化を意識し，機能単位で修正や追加をできるような設計にしていたとしても，アプリケーションで保守性を無視して設計・実装してしまうと台無しです。アプリケーション・アーキテクチャにおいて，保守性を上げる工夫が必要になります。

　実際のアプリケーション・アーキテクチャは多面的な側面を持ち非常に複雑なのですが，ここではアプリケーションの構成要素を役割別に分類し，その役割がどう連動するかを表した設計図のことだと考えてください。構成要素を役割別に分類したものを「静的な構造」，役割ごとの連動を表したものを「動的な構造」と呼びます。

　また，Webシステムにおけるアプリケーションとしては，アプリケーション（AP）サーバー上で動作するプログラムやデータベース（DB）サーバー上で動作するプログラム（例えばストアド・プロシージャ）がありますが，以下ではAPサーバー上で動作するプログラムを中心に考えます。

アプリケーションは5層をベースに考える

　Webアーキテクチャの静的な構造はレイヤー（層）で表現します。MVC（Model-View-Controller）モデルに基づくWebシステムのアプリケーション・アーキテクチャは，図2左のようなレイヤー構成をベースに考えると分かりやすくなります。

図2●アプリケーション・アーキテクチャをレイヤーに分けて記述した例
図2●アプリケーション・アーキテクチャをレイヤーに分けて記述した例
アプリケーションは，役割別にレイヤー分けすると分かりやすい（左）。各レイヤーの実装に使うフレームワークやライブラリなどの要素とアプリケーション要素を図示する（右）
[画像のクリックで拡大表示]

　このレイヤー構成は，画面表示をつかさどる「View」，Viewの制御や入力されたデータの受け渡しを担当する「Controller」，業務処理など実質的な処理をする「Logic」，DBアクセスを一元化する「DAO」，DBMS上のデータ処理を担う「DB」――という5層で成り立っています。

　この構成の特徴は，保守性を高めるために，「DTO（Data Transfer Object）」に当たるオブジェクトを定義していることです。このオブジェクトに，レイヤー間でやり取りするデータを格納し，各レイヤーはこのオブジェクトを参照して処理などを実行するように設計します。こうすることで，各レイヤー間ではDTOのやり取りしか発生しなくなりますので，それぞれのレイヤーの独立性が高まります。この構成を採った場合，MVCモデルにおける「Model」はLogicにDTOを加えたものとなります。

　レイヤー構成を固めたら，各レイヤーの実装方針を決定します。実装方針としては，フレームワークやライブラリを採用するかどうか，採用する場合はどのようなものを選べばシステム基盤と整合性を保てるかを検討します。検討結果を書き加えたものが図2右です。

　このケースでは，APサーバーとしてJavaベースの「Apache Tomcat」を，可用性向上のために「スケールアウト構成」をそれぞれ採用し，システム基盤を設計していました。そこで，ViewとControllerの実装には「Struts」，DAOの実装にはO-Rマッピング・ツール「iBATIS」という，一般的なJavaベースのアプリケーション・フレームワークを組み合わせて使うことにしました。一般的なフレームワークを使うことで，開発要員の確保が容易になり，保守性はさらに高まります。

　また，Viewの実装フレームワークにStrutsを採用したのに伴い，Strutsの提供するJSP（JavaServer Pages）タグを使って利用者向けのユーザー・インタフェースを提供することにしました。また，ViewからDAOの4層を貫く形でアプリケーション部品の依存性を下げるDI（Dependency Injection）フレームワーク「Spring」を導入することで，開発生産性と柔軟性の向上を狙っています。DIを採り入れることで，新たな機能をアプリケーションのロジック中に組み入れたり，逆に取り外したりする作業が容易になって，保守性が上がります。