Java による Web アプリケーション開発フレームワークについて
SI 事業部 東京センター 開発部

青江崇のフレームワークが注目されるようになってき

1. は じ め に
近年, インターネットの爆発的普及に伴い, Webた。

アプリケーションの構築が盛んに行われるよう

当社 SI 事業部では , これまでの Java によるになってきた。最近ではインターネットだけでな

Web アプリケーション開発によって蓄積された

く , 社内の基幹システムまでもが Web アプリケー

社内ライブラリをもとに独自のフレームワークションに置き換えられようとしている。Web アを開発し , 業務への適用を行った。本稿では簡単

プリケーションの構築がこれ程までに盛んになっながらこの Web アプリケーション開発フレームてきた理由としては , クライアントとして Webワークについて紹介を行い , Web アプリケーショ

ブラウザを使用するため , クライアントアプリンの開発に対してどのようなメリットがあるかにケーションを配布する必要がない , システムが多ついて述べていきたい。

層構造をとることにより , スケーラビリティを高めることができること , 等が挙げられる。

2. フレームワークについてこの Web アプリケーション開発において ,2.1 フレームワークとは何か

現在最もよく利用されている言語が Java であフレームワークとは , 共通の目的を持つアプリる。Java には J2EE（Java2 Platform Enterprise

ケーションに対し , 共通する構造や機能を提供すEdition）と呼ばれる , サーバーサイドアプリケーる半完成のアプリケーションのことである。こション開発を行うための仕様群があり , 他の言う説明するとライブラリと同じように思われる方語による開発と比較して , サーバーサイドアプリがいるかもしれない。しかしながら , ライブラリ

ケーションを構築するための強力な機能を提供しはあくまで部品の形で提供されており , メインプてくれることが最も大きな理由であろう。

ログラムは開発者が開発することになる。これ

しかしながら J2EE を用いた場合においても ,に対し , フレームワークはアプリケーションのメWeb アプリケーションの構築は決して容易ではインプログラムがフレームワークによって提供さない。しかも Web アプリケーション開発案件はれている。開発者は開発しようとするアプリケー

多くの場合 , 大変な短納期である。このため最近ション固有の処理を実装した部品を作り , フレーになって Web アプリケーションを開発するためムワークがその部品を呼び出すことになる。つま－1－

りライブラリを用いた開発とは視点が逆なのである仕組み。

る。図 1 にフレームワークを用いた開発のイメー

基本的に Web アプリケーションの開発においジを示す。ては , これらをすべて一から「手作り」しなければならない。この中で , クライアントからの要求とビジネスロジックのマッピング , DB アクセス処理やエラーハンドリングなどといったものはシステムレベルのサービスであり , アプリケーション開発の本質と関係がないのである。また , クラ
イアントから送信されるパラメータのチェックや画面遷移処理は毎回必ず発生する作業であるが ,図 1 フレームワークを用いた開発のイメージ意外に工数を取られる作業である。
よって , 上に挙げたような Web アプリケーショ

2.2 Web アプリケーション開発におけるフレーン開発における煩雑な作業を吸収し , ビジネスロムワークの重要性ジックの開発に集中できるようなフレームワーク

では , なぜ Web アプリケーションの開発におが求められているわけである。

いて , フレームワークを用いた開発が注目されているのであろうか。理由を簡単に述べてしまうと ,3. Java による Web アプリケーション開発

Web アプリケーションの開発は「非常に手間がフレームワークかかる」からである。以下に Web アプリケーショ

ここでは当社にて開発した Java による Web アンの開発において , 開発者が作成しなければならプリケーション開発フレームワークについて解説ないものを列挙してみよう。

する。まず , フレームワークを開発するにあたっ・ユーザに対するフロントエンドとしての画面。て , 以下に示す事柄を満たすことを目標とした。

・ビジネスロジック（トランザクション処理）。

・DB 接続処理やトランザクション管理 , エラーハ

・クライアント（画面）からの要求とビジネスロンドリング等のシステムレベルのサービスをフジックのマッピング。

レームワーク側で実装しておき , アプリ開発者・クライアントからの入力パラメータのチェック。にこれらを意識させないようにする。
・画面遷移やクライアントからの要求のビジネ・ビジネスロジックの処理結果に応じた画面遷移スロジックコンポーネントへの転送といった ,の制御。

Web アプリケーションでは手続きが複雑になる

・DB アクセス処理（コネクションの確立 , トラン処理を出来るだけ隠蔽し , ロジック開発に集中ザクション管理）。
・アプリケーション内のエラーをハンドリングすできるようにする。
・ビジネスロジック開発についても , テンプレー－2－

トを用意して , 開発者間でのコード設計のばらつきを減らすようにする。

ネスロジックへ渡す。
・遷移先の画面を決定 , ディスパッチする。
（データアクセス層）

3.1 基本となる考え方

・データベースアクセス処理を一元管理する。

MVC モデルを基本として設計を行った。MVC

・ビジネスロジックがデータアクセスする際に必モデルとは , アプリケーション構成を , ビジネ

要なコネクションの取得 , トランザクション管スロジック実行モジュールである Model, プレ理を行う。

ゼンテーションロジック実行モジュールである

・容易にデータアクセスオブジェクトを作成できView, 処理の流れを制御するモジュールであるるようなフレームワークを提供する。

Controller に分割して組み立てて行く設計手法で以下 , それぞれの層について解説していく。

ある。図 2 に MVC モデルでアプリケーションを構築した際の処理の流れについて説明している。

3.3 Web 層
Web 層フレームワークの処理の流れは図 3 のようになっている。網掛けのないクラスはフレー
ムワークで提供されているクラス , 網掛けされているクラスはフレームワークが提供するクラスを継承して , 実装者が実装するクラス , 黒塗りのクラスは実装者が開発するクラスである。

図 2 MVC モデル
理想は Controller, Model, View の結びつきをなるべく疎にして , それぞれに開発者を分担させることができるようにすることである。

3.2 全体の構成
今回作成したフレームワークは大きく分けてWeb 層とデータアクセス層に分けることができる。それぞれの役割は以下のようになる。
（Web 層）・クライアントから送信されてくる HTTP リクエストの処理を担当する。
・クライアントからのサービス要求を適切なビジ

図 3 Web 層フレームワークの処理の流れ－3－以下 , それぞれのモジュールについて解説してするクラスである。このクラスの役割は , 相当すいく。

る「処理」に必要とされるビジネスロジックの（Main Servlet）

呼び出しと , その結果に応じた遷移先画面の決定

クライアントからの HTTP リクエストを集中である。Main Servlet がアプリケーション全体のして受け付けるクラスで , アプリケーション全体

Controller ならば , この Request Handler はビジのコントローラの役割を持ち , Web 層フレーム

ネスロジック単位の Controller と言える。

ワークの中心となっている。リクエストパラメー

アプリケーション開発者は実装したい「処理」

タの処理 , 認証 , クライアントから要求された「処ごと（通常はボタン押下処理と 1 対 1 になるで理」に応じた Request Handler（後述）実装クラあろう）に , この Request Handler を継承したクスの検索と処理呼び出し及びその処理結果に応じラスを作成して , ビジネスロジックを呼び出す処

た JSP へのディスパッチを行う。

理を実装することになる。なお , クライアントのこのように 1 つのクラスでリクエストを集中

ボタン押下処理と Request Handler の結びつけ的に受け付ける設計（J2EE パターンでは Flontには URL のサーブレットマッピングを利用する。

Controller パターンと呼ばれている）にしているマッピング情報は設定ファイルに定義しておく。

ため , 認証やパラメータの処理 , 画面遷移処理の（Business Logic Bean）

ようなリクエストのたびに毎回行われる処理をア

ビジネスロジックをカプセル化した JavaBeans

プリケーション開発者が実装しなくても済むようである。MVC モデルの中の Model に相当する。にしている。

基本的にアプリケーション仕様に応じて設計する（Certifier）ものであるので , フレームワークの提供するもの認証処理を実装するスケルトンクラス。認証処ではない。ただし , 後述する JSP が利用するので理の内容はアプリケーション要件によって異なる

Java Beans の仕様を満たす必要はある。

ので , アプリケーション開発者が処理を実装する。

（JSP）（Arguments）

いわゆる JSP である。Business Logic Bean をHttp Servlet Request にセットされたフォーム

参照し , 処理結果をクライアントに表示する。どパラメータを Hashtable 形式で格納するクラス。の JSP に遷移させるのかを決定するのは Request

Http Servlet Request よりも使いやすくしている。

Handler で , 実際のディスパッチ処理を行うのはパラメータのセットは Main Servlet が行うため ,Main Servlet である。

アプリケーション開発者がセット処理を実装する（Abstract Query）必要はない。

検 索 系 の デ ー タ ア ク セ ス オ ブ ジ ェ ク ト。

（Request Handler）

Business Logic Bean はこのオブジェクトを通しクライアントから呼び出される「処理（ログて , データベースの検索処理を行う。詳細はデー

イン処理 , 検索処理 , 会員登録処理など）」に相当

タアクセス層の節で解説する。
－4－

（Abstract Trans Query）
更新処理系のデータアクセスオブジェクト。
Business Logic Bean はこのオブジェクトを通して , データベースの更新処理を行う。詳細はデー

図 4 コネクションプール取得処理の流れ

タアクセス層の節で解説する。

さらに , 現在開発中の段階であるが , 次のようなモジュールを提供する予定である。
（Arguments Validator）
入力パラメータのチェック処理を一括して行うクラスである。入力されたパラメータを格納する
図 5 データアクセス処理（検索）の流れ

Arguments クラスを解析し , 入力値の型 , 文字列長についてチェックを行う。チェック内容については CSV 形式の設定ファイルに定義する（フォーム名に対して定義する）。こうすることによって入力チェック処理をアプリケーション開発者がコーディングしなくて済むようにすることを目指している。

図 6 データアクセス処理（更新）の流れ

3.4 データアクセス層
データアクセス層のフレームワークはデータ（Connection Pool Factory）ベースのコネクションプール管理機能を提供すデータアクセス層のフレームワークの中心とるフレームワークとデータベースへのアクセス機なるクラスである。後述する Connection Pool ク

能を提供するフレームワークに分けることができラスを管理し , データアクセス処理時にはコントる。図 4 にコネクションプール管理機能を提供すローラの役割を果たす。

るフレームワークの , コネクションプール取得ま（Connection Pool）

での処理の流れを , 図 5, 6 にデータベースへのア

JNDI ルックアップによって取得されたデータクセス機能を提供するフレームワークの , データソース（javax. sql. Data Source クラス）を保持し ,アクセス処理の流れを検索処理と更新処理に分けDB とのコネクションを管理するクラスである。て示す。

データソースは Hashtable に格納しており , 複数

以下 , 図の中に登場したそれぞれのモジュール

DB にアクセスする必要があるケースにも対応しについて解説していく。ている。
－5－

（Connection Filter）

4. フレームワークの実装例

java. sql. Connection クラスをラップし , 使い

この章では簡単な Web アプリケーションの構やすくしたクラスである。DB に対する 1 接続を築を例に , フレームワークの実際の適用方法につ確保し , DB に対して検索 , 更新処理を行うためのいて解説したいと思う。

インターフェースを提供する。
（Query Result）

4.1 作成するアプリケーション

DB の検索結果を格納するクラスである。項目

今回実装例として作成するアプリケーション

名付きテーブルの構造をしており , Result Set とは , 簡単なクイズアプリケーションである。まず違って行番号を直接指定して値を取り出すことが画面遷移を図 7 に示す。最初に問い合わせ画面ができる。

あり , 4 つの選択肢から 1 つを選んで「回答」ボ

（Abstract Query）

タンを押す。選択肢が正解であれば次の画面へ検索処理をカプセル化したデータアクセスオブと進むことができ , 間違っていた場合は問い合わ

ジェクトで ,“Abstract ～”の名称が示すようにせ画面に戻る。このとき選択した答えが間違いで抽象クラスである。コネクションを取得して検索あったことを知らせるメッセージを表示する。

処理を実行する処理を実装しており , SQL 文の取次節よりこのアプリケーションを実装していく

得についてのみサブクラスの定義に任せるよう手順を示していく。にしている。よってアプリケーション開発者はAbstract Query のサブクラスを作成し , SQL 文

4.2 ビジネスロジックの実装を実装するだけで検索処理を実行するデータアク

まずはビジネスロジックの実装から始める。実セスオブジェクトを作ることができる。

装コードをリスト 1 に示す。クラス名は“Apptec（Abstract Trans Query）Quiz”とした。選択された答えが正解であるかを更新処理をカプセル化したデータアクセスオブ判定するメソッド mark() を実装する。また , プ

ジェクト。コネクションを取得して , トランザクロパティとして正解 , 不正解を表す“correct”プションを開始 , コミット（例外発生時はロールバッロパティを実装する。

ク）する処理を実装しており , 更新処理の内容はここで , このビジネスロジック実装クラスがクサブクラスの定義に任せるようにしている。アプ

ライアント非依存であることに注目してもらいた

リケーション開発者は Abstract Trans Query のい。クライアントが Web ブラウザであることをサブクラスを作成し , 1 トランザクションで行い意識せずに実装を行っている。

たい更新処理の内容を実装する。トランザクショ
ン管理やコネクションの解放といった処理は実装

4.3 Request Handler の実装する必要がない。

続いて , コントローラの役割を果たす RequestHandler を実装する。実装コードをリスト 2 に示
－6－図 7 サンプルアプリケーションの画面遷移

リスト 1 Apptec Quiz. Javaす。Request Handler を継承し , handle() メソッ

Apptec Quizの状態（ここではcorrectプロパティ）

ドの中に処理を実装する。まずクライアントかを判定して , 遷移先を決定 , return している。

ら送られてきたパラメータを Arguments から

ここで , 遷移先は JSP の実 URL ではなく , 論取り出し , 先ほど実装した Apptec Quiz に渡し理名を返していることに注目してほしい。この論て , ビジネスロジック処理を実行させる。その後

理名と実 URL のマップはリスト 3 のように設定－7－リスト 2 Quiz Handler. java

リスト 3

JSP の論理名と実 URL のマッピングファイルに定義する。こうすることでプログラムHandler を指定できるようにし , ボタン押下処理

中に JSP ファイルの実 URL をハードコーディンとビジネスロジックのマッピングを直観的で分かグすることを防ぎ , アプリケーション構成の変更り易いようにしている。
実際の Handler と URL のマッピングはリスに対しても柔軟に対処できるようにしている。

ト 6 のように設定ファイルに定義している。こうすることで , もしボタンに対する処理（Request

4.4 JSP の実装Handler）が変わったとしても設定ファイルの変最後に JSP を実装する。問い合わせ画面の JSP更だけで済むようにしている。

（quiz. jsp）のソースはリスト 4 のようになってまた , リスト 4 の 13 行目では Apptec Quiz のいる。
ボタン押下に応じた Request Handler の呼びステータスを参照して , 不正解を知らせる文字列出しは , form タグの action 属性で行っている。

を表示するかどうかを判定していることが分かる。

action に 記 述 さ れ て い る URL の 最 後 の パ ス
4.5 実装例についてのまとめ“/quiz”が Handler の指定である。実は Web アプ
リケーションの配備ディスクリプタ“web. xml”

今回は非常に簡単なアプリケーションであったにてリスト 5 のようなサーブレットマッピング

ため , フレームワークを用いて実装したメリットを行っており , 最後のパスを自由に指定できるはあまり感じられなかったかもしれない。しかしようにしている。これを利用して , URL で起動ながら , ここまでの流れを見てきて , アプリケー－8－

リスト 4 quiz.jsp

リスト 5 web.xml でのサーブレットマッピング設定

リスト 6

サーブレットパスと RequestHandler のマッピング

ションの開発の内容が以下のように「型ハメ」さ作成し , 1) で作成したビジネスロジックを呼れていることに気づかれたと思う。

び出す処理を実装する。

1）ビジネスロジックを実装した JavaBeans を作

3）JSP を 作 成 し , １) で 作 成 し た Java Beans成する。

から値を参照して画面を表示するロジック2）ボタン押下処理に対する RequestHandler をを実装する。また , form に対する Request－9－

Handler の呼び出しを実装する。

イブラリといった「財産」があったからこそ開発

開発の順番はこうでなくても構わない。また ,をすることが出来たこと強調しておきたい。特に

1), 2), 3) の開発を別の人に分担することも可能でデータアクセス層のフレームワークはほぼ完成状ある。

態であり , 筆者はそれに僅かな変更を行っただけ

開発の規模が大きくなってくると , このようにであった。ここに , このような貴重な財産を積み作業内容が「型ハメ」されていることは作業効率上げて頂いた応用技術の諸先輩方に感謝の意を示の向上につながってくるはずである。

したい。

5. ま参 考 文 献とめ

本稿では当社 SI 事業部にて開発した Web アプ[1] ディーパック・アラー , ジョン・クルーピ , ダリケーションフレームワークについて簡単ながらン・マークス著 , ウルシステムズ株式会社監訳：解説を行ってきた。以下に本フレームワークによJ2EE パターン , p.166-178, ピアソン・エデュる開発上のメリットについてまとめる。

ケーション (2002)

・システムレベルのサービスを開発者が実装しな[2] 月刊ジャバワールド 2002 年 5 月号 , p.52-86,くて済む。

IDG ジャパン (2002)

・Web アプリケーション開発おいて最も実装の[3] 月刊 DB マガジン 2001 年 12 月号 , p.75-88,

手続きが複雑になる部分を隠蔽し , ビジネスロジックの実装に注力することができる。

翔泳社 (2001)[4] 深澤 良彰：Vol.10 オブジェクト指向再利用

・開発手順を一定の型にはめることによって , 作の真髄（オブジェクト工房 Web サイト内）,業効率を高めることができ , 開発者間でのコー

http://www.itc.co.jp/kobo/manabu_fo10.

ドの品質のばらつきを抑えることができる。

html

本フレームワークを実際の業務開発に適用して[5] Inderjeet Singh, Beth Stearns, Mark

みたところ , 上記のメリットは概ね得られること

Johnson, エ ン タ ー プ ラ イ ズ チ ー ム 共 著：ができ , 開発時の目標はおおよそ達成することがJava2 Platform Enterprise Edition アプリ

できた。
しかしながら, 今回開発したフレームワー

ケーション設計ガイド 第 2 版（J2EE1.3 対応）,

クはまだまだ発展途上の段階である。より良い

http://sdc.sun.co.jp/NASApp/

フレームワークとするために今後も更なる改善をsdcpersonal/private/jdc/download/行っていきたいと思っている。

j2ee_blueprints/j2eebp_2e-ja.pdf

最後に , 今回開発したフレームワークは決して筆者が 1 人で開発したものではなく , これまでの応用技術の Web アプリケーション開発業務を通して積み重ねられてきた開発ノウハウや豊富なラ－10 －