概念: Web アプリケーション・フレームワーク

トピック

 

概論To top of page

アプリケーション・フレームワークを使用すると、ソフトウェア・アプリケーションの実装中に多くの利点があります。フレームワークはアプリケーション間で共通する多くの実装の詳細に対応する再使用可能インフラストラクチャーを提供し、共通してみられる実装上の問題に対する解決策を再発見したり再実装したりするのを防ぐのに役立ちます。 さらに、フレームワークは特定タイプのアプリケーションを作成するという問題に対して有効な解決策を与えるプログラミング・モデルに従っていることが多く見受けられます。 Java 2 Enterprise Edition (J2EE) Web アプリケーションの場合、モデル・ビュー・コントローラー (MVC) 設計パターンを基にしたフレームワークは最善のものとみなされ、特に、Struts は最も一般的に使用されてきています。つい最近、J2EE 規格委員会は付加的な利点のある MVC フレームワークを提供する JavaServer Faces (JSF) 仕様をリリースしました。

本書は MVC 設計パターンの利点を説明し、Struts および JSF フレームワークの概要を示します。本書はこれらのフレームワークの目的を説明し、その利点と欠点を挙げ、これらのフレームワークを選択する際のガイドラインを示します。最後に、補足テクノロジー、すなわちサービス・データ・オブジェクト (SDO) と Enterprise JavaBeans (EJB) を、これらのフレームワークを使用するアーキテクチャーに統合する方法についても説明します。

 

モデル・ビュー・コントローラー設計パターンTo top of page

モデル・ビュー・コントローラー (MVC) はアプリケーションのユーザー・インターフェースをビジネス・ロジックから分離する設計パターンです。このために、アプリケーションのアーキテクチャーをモデル、ビューおよびコントローラーという 3 つの部分に階層化します。図 1 は Web アプリケーションに適用される MVC アーキテクチャーを示します。

図 1: Web アプリケーションの MVC アーキテクチャー

モデル

モデルはアプリケーションの状態を表わし、それを変更するビジネス・アクションを定義します (永続データおよびビジネス・ロジック)。モデルに対しては状態を問い合わせることができ (通常、ビューが行う)、状態の変更を行うように要求することができます (通常、コントローラーが行う)。モデルはビューやコントローラーについては何も関知しません。

ビュー

ビューはモデルの表示を提供するもので、アプリケーションの外観、すなわちユーザー・インターフェースを表わします。ビューはユーザーとの間でデータを表示および収集することを担当します。ビューはモデルの状態を取得することはできますが、変更することはできません。

コントローラー

コントローラーはユーザー入力に応え、それに応じて状態を変更するためにモデルに通知します。具体的に言うと、コントローラーは入力ユーザー要求を該当のビジネス・ロジック関数 (モデル内) にディスパッチし、結果に基づいてユーザーへの応答を選択すること (ビュー) によりユーザー要求を処理します。

利点

MVC 設計パターンで表示からビジネス・ロジックを分離することにより次の利点が得られます。

  • 保守容易性の向上

    ビュー・レイヤーとモデル・レイヤーが分離されているので、ビジネス・ルールに影響を与えずにユーザー・インターフェースを変更することができ、またユーザー・インターフェースに影響を与えずにビジネス・ルールを変更できます。したがって、変更の影響を最小限に抑えられます。

  • モデルの再利用性

    同じモデルの複数のビューを作成できます。例えば、アプリケーションで異なるクライアントのデバイス・タイプ (例: 携帯電話、PDA) をサポートする必要がある場合は、各テクノロジーに固有の新しいビューを作成し、同じモデルを再利用することができます。

  • 責務の分離

    開発の役割を分離することができ、これにより開発チームの異なるメンバーはそれぞれの専門分野に注力できます。例えば、Web ページの設計者はビュー・レイヤーを担当し、Java 開発者から独立して設計に取り組むことができ、Java 開発者はコントローラー・レイヤーとモデル・レイヤーの実装に専念できます。

 

Struts To top of page

Struts は MVC 設計パターンを使用したダイナミック Web アプリケーションの構造を可能にするアプリケーション・フレームワークです。Struts は Sun の J2EE Model 2 アーキテクチャーを基にしたアプリケーションの MVC 実装を構築するための土台として使用できる、協調する Java クラス、サーブレット、および JavaServer Page (JSP) タグ・ライブラリーの集合です。

  • コントローラー・レイヤーはサーブレットを使用して実装される。
  • ビューは JSP を使用して実装される。
  • モデル・レイヤーは通常、JavaBeans または Enterprise JavaBeans を使用して実装される。

アーキテクチャーTo top of page

図 2 は Struts での MVC アーキテクチャーの実装とクライアント要求の処理フローを示します。

図 2: Struts MVC アーキテクチャーと要求処理フロー

コントローラー・コンポーネント

Struts の主なコントローラー・コンポーネントは、フロント・コントローラー・サーブレット、ActionServlet と、ActionForm クラスおよび Action クラスで構成されています。

  • ActionServlet

ActionServlet は HTTP リクエストを受け取り、モデルで要求されたアクションを呼び出し、表示する次のビューを選択します。ActionServlet はフレームワークのコアです。ActionServlet クラスの 1 つのインスタンスがすべての入力要求を受け取ります。ActionServlet は HTTP リクエストにより対応するフィールドを使用して ActionForm の状態を設定し、任意で ActionForm に妥当性の検証を要求し、マップされた Action に渡します。要求は構成ファイル (struts-config.xml) を使用して Action にマップされます。

  • ActionForm

ActionForm クラスはフォーム・データを表わします。ActionServlet インスタンスは入力フォームからの値をプロパティーに自動的に取り込み、要求された Action に渡します。また、ActionForm はビューで表示する、モデルからのダイナミック・データを保持するのにも使用します。

  • Action

Action クラスはモデル・レイヤーを呼び出すためのロジックを含みます。ActionServlet によって実行されると、Action クラスはビジネス・ロジックを実行するためにモデル・オブジェクトを呼び出した後、ActionServlet コントローラーに次の行き先を知らせます。

モデル

Struts はモデルに対し使用するテクノロジーを指定しません。しかし、たいていの場合、モデル・オブジェクトは簡単な JavaBeans、または Enterprise JavaBeans などのより強力なコンポーネントを使用して実装されます。

ビュー

通常、ビューの実装は、フレームワークに付属した JSP カスタム・タグ・ライブラリーを活用するために JavaServer Pages を使用して行われます。表示するダイナミック・データは JavaBeans から、またはコントローラー・レイヤーで作成される ActionForm クラスのインスタンスから取得されます。カスタム・タグはこのデータにアクセスするための基本手段です。

利点To top of page

Struts は強力な開発者コミュニティーでサポートされるオープン・ソース・フレームワークであり、その規格は Apache Software Foundation の Jakarta プロジェクトで管理されています。これはベンダー固有のものではなく、多くの開発ツールでサポートされるので、魅力的な選択肢です。MVC ベースのフレームワークであることに加え、Struts はほかにも次の利点があります。

  • Struts は HTTP が中心になっていて、低レベルの詳細 HTTP リクエスト処理を隠します。
  • モデルに依存しておらず、開発者はモデル・レイヤーに使用するテクノロジーを選択できます。
  • Struts は構成可能度が高いフレームワークです。アプリケーションのフロー、ユーザー入力の妥当性検査、およびエラー処理を制御するために XML 構成ファイルを使用します。
  • Struts は国際化/ローカリゼーションをサポートしており、そのために、標準 Java ResourceBundles を使用しています。
  • Struts は再使用可能性を大きく向上させる次の機能を提供します。
    • 一般 Bean 操作、条件付き/反復ロジック、HTML レンダリングなどの共通タスクを扱う JSP カスタム・タグ・ライブラリーの豊富なセット
    • レイアウトを制御し共通のルック・アンド・フィールをプロモートするため再使用可能ユーザー・インターフェース・テンプレートを作成できるタイルのサブフレームワーク
    • 追加のコード再使用のため Struts 式言語 (EL) を使用した JSP 標準タグ・ライブラリー (JSTL) へのアクセス

制限To top of page

Struts の制限には次のものがあります。

  • Struts のオープン・ソースの性質はそのサポートが開発者コミュニティーに依存することを意味します。
  • ビュー・レイヤーに対し異なるテクノロジーを使用することは難しいため、Struts は「JSP マインドセット」を備えています。
  • Struts は豊富な Web ユーザー・インターフェースの作成を可能にするユーザー・インターフェース・コンポーネントおよびイベント処理モデルは提供していません。

 

JavaServer Faces To top of page

JavaServer Faces (JSF) は ユーザー・インターフェース主導アプローチを使用して Java Web アプリケーションの作成を可能にするアプリケーション・フレームワークです。このテクノロジーは、サーバー上で動作する標準 ユーザー・インターフェース・コンポーネント・モデルを使用して Web アプリケーションを作成するための基盤を提供します。その目標は、プログラミング・モデルを単純化し、ユーザー・インターフェース指向のイベント・ドリブン Web 開発を促進することにより Web アプリケーション開発を容易にすることです。

アーキテクチャーTo top of page

JSF は MVC ベースのアプリケーション・フレームワークです。JSF はユーザー・インターフェース・コンポーネントの定義、サーバー上でのその状態の管理、クライアント生成イベントの処理を行うための豊富なアーキテクチャーを提供します。また、ユーザー入力の妥当性検査およびページ・ナビゲーションの制御に対するサポートも提供します。図 3 は JSF アーキテクチャーの主なコンポーネントを示し、クライアント要求の処理フローを図示しています。

図 3: JSFコンポーネント・アーキテクチャーとページ要求処理フロー

FacesServlet

FacesServlet は JavaServer Faces ページに対するすべての要求のエントリー・ポイントです。ページのライフサイクルを制御するためにフレームワークで要求されたリソースを初期化し、要求を処理するためにページを呼び出します。FacesServlet はアプリケーションに対するフロント・コントローラーとして働きます。

JavaServer Faces ページ

JavaServer Faces ページは、それに含まれるすべてのユーザー・インターフェース・コンポーネントを表現するための JavaServer Faces タグを含む JSP ページです。各コンポーネントは Backing Bean プロパティーとの値関連を宣言し、必要とするイベント・リスナー、バリデーター、およびコンバーターを指定します。フレームワークはコンポーネントのデータと、関連する Backing Bean のバインド済みプロパティーを自動的に同期化させます。

ユーザー・インターフェース・コンポーネントのツリー

JSF ページのユーザー・インターフェース・コンポーネントはコンポーネント・ツリー (「ビュー」とも呼んでいます)によりサーバー上に表示されます。フレームワークで要求が処理されると、このコンポーネント・ツリーが作成される (最初のページ要求の場合)か、または保存状態から復元されます (以降のページ要求の場合)。

バリデーター

バリデーターはユーザー入力の妥当性検査に使用します。JSF は多くの標準バリデーター・クラスを含み、カスタム・クラスの作成をサポートします。

Backing Bean

Backing Bean は JSF Page のユーザー・インターフェース・コンポーネント用のデータを保持し、その動作をサポートするメソッドを実装する JavaBean です。一般的に、これらのメソッドは イベント処理、妥当性検査、およびナビゲーション制御を実行するためのロジックを含みます。 通常、Backing Bean はビジネス・ロジックを実行するためのメソッドをモデル・オブジェクトから呼び出します。JSF により Faces 構成ファイル (face-config.xml) でページが使用するすべての Backing Bean を宣言することができ、これらはアプリケーション起動時に Web コンテナーにより自動的にインスタンス化されます (これらの Bean を Managed Bean と呼びます)。また、構成ファイルでは Backing Bean でナビゲーション制御ロジックと連動するページ・ナビゲーション・ルールも指定します。

イベント・リスナー

イベント・リスナーは、特定タイプのコンポーネント生成イベントを処理するように設計されたユーザー定義のクラスです。JSF では、値変更イベント (例: ユーザーがコンポーネントの値を変更した)、アクション・イベント (例: ユーザーがボタンをクリックした) およびデータ・モデル・イベント (ユーザーがデータ・セットで新しい行を選択する)という 3 種類のイベントをサポートします。

レンダラー・キット

レンダラー・キットは特定クライアント・タイプに対するレンダラーのグループです。レンダラーは特定クライアント・デバイス上にユーザー・インターフェース・コンポーネントを表示するために、該当の出力を生成するクラスです。JSF はコンポーネント表示用の HTML を生成し、そのほかのクライアント・タイプ用のレンダー・キットを作成できる標準 HTML レンダー・キットを提供します。

コンバーター

コンバーターは表示のためオブジェクトをストリングに変換し、処理のためストリングをオブジェクトに変換するのに使用します。また、フォーマット設定およびローカリゼーション選択を適用するのにも使用します。

利点To top of page

JSF は Java Community Process (JCP) を通じて開発された標準ベースのフレームワークで、Java 2 Enterprise Edition (J2EE) 仕様の今後のリリースに入る予定です。したがいまして、Java サーバー・サイド・ユーザー・インターフェース作成に関する公式標準として確立しています。その主な長所としては、まずプログラミング・モデルの単純化が挙げられます。これにより開発者は Web アプリケーションを作成する労力が軽減されます。次に、フレキシブルなアーキテクチャーが挙げられます。これは、プレゼンテーションからアプリケーション・ロジックをクリーンに分離する (MVC の性質による)ことが可能になります。これらの長所を踏まえ、次の利点が得られます。

  • 迅速なアプリケーション開発                                       

    JSF により、単純化されたプログラミング・モデルを通して、Web アプリケーションの迅速な開発が実現します。開発者は再使用可能ユーザー・インターフェース・コンポーネントをページで容易にアセンブル可能で、それをアプリケーション・データ・ソースに接続し、クライアント生成イベントをサーバー・サイド・イベント・ハンドラーに結びつけることができます。フレームワークはコンポーネント状態を自動的に同期化する処理を行い、ユーザー入力の妥当性検査、ビジネス・ロジックの実行、ページ・ナビゲーションの制御などの共通する Web プログラミング・タスクに対し包括的なサポートを提供します。また、ますます多くのベンダーが生産性をさらに向上させるためにビジュアルな方法で JSF を使用した Web ユーザー・インターフェース作成のツール・サポートを提供するようになっています。

  • 保守容易性

    JSF ではユーザー・インターフェースのコンポーネント・レベルで表示と動作をクリーンに分離する結果として、非常に細かいレベルで問題となる部分を切り分け、保守容易性の向上を図ることができます。

    o Java 開発者がコンポーネントの動作をインプリメントしている間に、ページ設計者はコンポーネントを表示するタグの使用に集中することができます。完成したら、JSF の簡単なプログラミング・モデルを使用して個々の部分を速やかにリンクできます。

    o コンポーネントの表示に対する変更は、コンポーネントの動作に影響を与えません。 例えば、「背後の」コードを変更する必要なく、コンポーネントを表示する新しいタグを選択できます。

  • 柔軟性

    JSF では、ユーザーを特定の表示テクノロジーやマークアップ言語に縛ることはありません。

    o JSF の柔軟なレンダリング・モデルにより、コンポーネントをクライアント・デバイスから独立したものにすることができます。異なるマークアップ言語を生成するレンダラーを使用することで、コンポーネントを HTML 以外の方法で表示できます。したがって、異なるレンダラーを使用すると、同じコンポーネント・ロジックを複数のクライアント・タイプに対し再使用できます。

    o JSF ではコンポーネントを JSP ページ上に表示する JSP カスタム・タグ・ライブラリーを提供しているだけでなく、ユーザーが JSP 以外の表示テクノロジーを使用することもできます。これができるのは、JSF テクノロジーがサーブレット API の上部に直接階層化されているからです。

  • 拡張性

    JSF のユーザー・インターフェース・コンポーネントのモデルはカスタム・コンポーネント作成のため拡張可能です。これによりツリーおよびメニューなどの高度なコンポーネントを作成することができ、Web アプリケーション用に、より豊富で使いやすいユーザー・インターフェースを作成できます。

 

制限To top of page

JSF の制限には次のものがあります。

  • JSF は時間と共に改良し続ける新しいテクノロジーです。
  • JSF は一貫したルック・アンド・フィールを促進し、ページを個別の処理セクションに分割できるレイアウト管理機能は備えていません。
  • JSF 開発はツール・サポートなしで手作業で行われる場合は難しい作業です。その RAD の利点は、ビジュアル設計ツールを持つ IDE を使用した場合に真に実現されます。

 

フレームワーク選択ガイドラインTo top of page

ベスト・プラクティスとして、MVC アーキテクチャーに準拠したアプリケーション・フレームワークを使用することをお勧めします。Struts および JSF は共にこのアーキテクチャーに準拠しているので、優れた選択肢になります。両者を比較すると、機能性が重複していることが明らかになります。例えば、両者は共に入力の妥当性検査、要求処理、およびページ・ナビゲーションに対するサポートを提供しています。2 つの中からどのようにして選択すればよいのでしょうか。 表 1 は重要なフレームワーク機能をリストし、Struts および JSF のサポートを比較しています。これをガイドとして利用すると、必要な機能や最善のサポートを提供するフレームワークはどちらか、といった内容に基づいて選択の決定を下す助けとなります。

 

  Struts JavaServer Faces
プログラミング・モデル
  • フォーム処理スタイル
  • イベント・ドリブン・スタイル
UI コンポーネントとサポート
  • Struts-HTML タグ・ライブラリーで提供される簡単な UI コンポーネント
  • 提供される ActionForm Bean へのデータ・バインディング
  • 豊富な UI コンポーネント
  • 追加のカスタム・コンポーネントを作成可能
  • Backing Bean またはサポートされる任意のモデル・オブジェクトへのデータ・バインディング
  • 提供されるイベント処理サポート
クライアント・デバイスの独立性
  • サポートされない
  • Render キットはデバイスの独立性を提供
エラー処理と妥当性検査
  • XML ファイル (validation.xml) で駆動される妥当性検査フレームワーク
  • 多くの事前定義バリデーターを備えた妥当性検査フレームワーク
  • カスタム・バリデーターを作成可能
スクリプト記述
  • Java Action クラスで書かれるスクリプト
  • スクリプトはフォーム・データのみにアクセスできる
  • Backing Bean、モデル・クラスまたはイベント・リスナー・クラスで書かれるスクリプト
  • スクリプトはイベントに付加可能
  • スクリプトは UI コンポーネントとそのデータにアクセス可能
ページ・フロー
  • 高度で、柔軟なフレームワーク
  • XML ファイル・ベース
  • 高度で、柔軟なフレームワーク
  • XML ファイル (faces-config.xml) で構成
セッションおよびオブジェクト状態管理
  • 手動
  • 自動

表 1: Struts と JSF の機能の比較

決定はどちらか一方/または選択になる必要はないということにも注意してください。Apache プロジェクトで開発される Struts と Faces の統合ライブラリーを使用して両方のテクノロジーを結合することもできます (#resources -- このハイパーリンクは、生成されたこの Web サイト内に存在しません『リソース』を参照)。このライブラリーにより、Struts コントローラー・コンポーネント、アクション、およびビジネス・ロジックとあわせてユーザーの Web ユーザー・インターフェースで JSF コンポーネントを使用できます。

長い目で見れば、新しいプロジェクトには JSF を使用し、既存の Struts プロジェクトは JSF に移行することをお勧めします。この根拠は次のように要約できます。

  • JSF はユーザーが長い間待ち望んでいて、Struts では提供されない豊かさを Web ユーザー・インターフェースにもたらす。
  • JSF の簡単なプログラミング・モデルにより、生産性を向上させる高レベルの抽象化を実現。Struts での基本的な「フォームおよびフィールド」処理とは対照的にユーザー・インターフェース・コンポーネントとクライアント・イベントの観点から考慮することができます。
  • JSF は Web アプリケーション作成の完全な解決策を提供し、サービス・データ・オブジェクトなどの新しいテクノロジーと容易に統合する (#complementary -- このハイパーリンクは、生成されたこの Web サイト内に存在しません『補足テクノロジー』を参照)。
  • RAD 6.0 などの強力な統合開発環境 (IDE) は、今日すでに JSF をサポートしている。
  • J2EE 仕様への JSF の将来の組み込みにより、多くのベンダーから幅広いツール・サポートが提供される。

 

補足テクノロジー To top of page

この節では、強力で完全なエンドツーエンドの実装ソリューションを作成するために サービス・データ・オブジェクト (SDO) および Enterprise JavaBeans (EJB) のテクノロジーをどのように Struts または JSF フレームワークに統合できるかについて考察します。

EJB テクノロジーの説明については、「ガイドライン: Enterprise JavaBeans (EJB)」を参照してください。

 

サービス・データ・オブジェクトTo top of page

サービス・データ・オブジェクトは一様な、データ・ソースから独立し切断された方法でバックエンド・データへのアクセスを可能にするプログラミング・モデルの仕様です。このプログラミング・モデルにより、あらゆるタイプのデータ・ソース (リレーショナル・データベース、EJB エンティティー Bean、Web サービス、XML データ・ソース、等)からデータを検索でき、それをデータの構造化グラフ (DataGraph) として一様に提示できます。SDO は DataGraph をバックエンドの接続やトランザクションから独立して検索できるようにすることで切断された操作に対応します。SDO は依然として Java Specification Request (JSR) 235 として JCP を通して提出されている提案仕様です。

アーキテクチャー

SDO アーキテクチャーは DataGraph を異種データ・ソースからクライアントに戻すために一様なデータ・アクセス・レイヤー (Data Mediator Service) を使用します。図 4 は SDO アーキテクチャーのコンポーネントを示します。

図 4: SDO アーキテクチャー

DataObject

DataObject は実データ (例: リレーショナル・データベースからのプリミティブ値やデータ行) およびその他の DataObject への可能な参照を保持します。DataObject はそのタイプ、関係、および制約の判別のためにイントロスペクトすることができます。

DataGraph

DataGraph は DataObject のセットを保持し、通常、アーキテクチャーでのコンポーネント間の転送単位を表わします。DataGraph は新規データ・オブジェクト、変更または削除されたデータ・オブジェクトを含めて、データへのすべての変更を記録します。

Data Mediator Service

Data Mediator Service はデータを表す DataGraph を作成するためにデータ・ソースとの相互作用を担当します。このプラグ可能サービスによりネイティブ・データ表現を SDO グラフィカル表現に変換します。また、Mediator は DataGraph 内の変更をデータ・ソースに戻して適用することも担当します。

 

フレームワーク適用度To top of page

SDO テクノロジーはツールとフレームワークの容易な統合を約束します。JSF およびその他の MVC フレームワークに関連して、次の 2 つの解決策を検討することができます。

UI コンポーネントと SDO 間のバインディング (JSF)

JSF フレームワークでは、データ検索を目的として Web ユーザー・インターフェース・コンポーネントの値を SDO に宣言してバインドできます。例えば、バックエンド・データ・ソースから値を検索するためにデータ・テーブル・コンポーネントを SDO にバインドすることができます。 この組み合わせにより、プログラミングの必要なく容易に UI コンポーネントからのデータ接続性が確立されます。図 5 は JSF UI コンポーネントを SDO にバインドして得られるアーキテクチャーを示します。

図 5: JSF との SDO の使用

SDO に対するモデル・オブジェクト (任意の MVC フレームワーク)

MVC フレームワークのモデル・レイヤーはバックエンド・データにアクセスするために SDO を使用することもできます。 図 6 は Entity EJB を使用して持続データにアクセスするために SDO を使用したモデル・クライアント例を示します。モデル・オブジェクトはステートレス・セッション EJB ファサードによって戻される DataGraph を使用します。その次に、このセッション Bean ファサードは Mediator から DataGraph を取得します。Mediator は Entity EJB ベースの永続性メカニズムのデータ・ファサードとして働きます。

図 6: モデル・オブジェクトおよび EJB との SDO の使用

 

リソースTo top of page

次のリンクから本書に記載するアプリケーション・フレームワークおよびコンポーネント・テクノロジーに関連した追加情報を入手できます。

Rational Unified Process   2003.06.15