Struts1.3によるWebアプリケーションの作り方 (概要編)

2011年1月10日Apache Struts

No Struts

本連載の内容は記事執筆当時のまま再公開しており、現在では古い、あるいは適切ではない内容を含んでいます。

ソリューション開発部の黒住です。

本稿ではStrutsバージョン1.3によるWebアプリケーションの作り方を解説します。Strutsは2000年の登場以来、急速に広まりいまやJ2EE開発におけるデファクトのWebアプリケーションフレームワークとなりました。しかし、登場以来5年以上が経過し、アーキテクチャや思想の古さが目立つようになってきました。そこで、Struts開発チームはStrutsの内部構造を大幅にリファクタリングし、新しいStrutsをリリースしようとしています。本稿ではこの新しいStrutsを取り上げ、「概要編」としてStrutsの簡単な紹介を行います。その後、続編である「構築編」において、Webアプリケーションの作り方を解説します。対象としてはStrutsを初めて学ぶ方を想定しています。

J2EEとWebアプリケーション

JavaでWebアプリケーションを構築する場合、J2EEを無視して構築することは不可能です。J2EEでWebアプリケーションを構築する場合、アプリケーションを論理的な4階層に分けて設計・製造するのが一般的です。階層化を行うことで、層ごとの役割分担が明確となると同時に、各層ごとに異なるマシン上での実行をも可能となり、スケーラビリティやアベイラビリティの向上にも貢献できるようになります。その階層イメージは次の図のようになります。

説明図:J2EEアプリケーションの論理的階層イメージ
図:J2EEアプリケーションの論理的階層イメージ

J2EE (Java 2 Enterprise Edition) アプリケーションを作成するための知識は多岐に渡り、APIから設計ガイド、デザインパターンやサンプルアプリケーションまでさまざまです。特にSun Microsystemsが提供するJ2EE設計ガイドである、「Designing Enterprise Applications with the J2EE (TM) Platform, Second Edition (通称 J2EE BluePrints)」では、アプリケーションのアーキテクチャにまで言及されていますが、さまざまな規模のアプリケーション (基幹システムからToyシステムまで) に対応できるよう記載されているので、そのまま適用すると、いたずらに複雑かつファットなアプリケーションになり、コストやパフォーマンスに深刻な影響を与えかねないので注意が必要です。

Webアプリケーションを設計する場合には、図のような各層を意識しつつアーキテクチャを設計する必要があります。プレゼンテーション層とビジネスロジック層の分離には、MVCモデル2アーキテクチャパターン (以降、MVCモデル2) を用いるのが一般的です。MVCモデル2の概要は後述しますが、Webアプリケーションの構成要素を、プレゼンテーション (ビュー)、ビジネスロジック (モデル)、制御 (コントローラー) の3つのコンポーネントに分類し、それぞれの機能を明確に分離する方法です。これによって開発分担が明確になるばかりでなく、機能の追加/変更が局所化されメンテナンス性が向上します。

同モデルを実装する際にすべてを開発する方法もありますが、近年ではMVCモデル2を採用したWebアプリケーションフレームワークを利用する方法が一般的です。とくに本稿で取りあげるStrutsはJ2EE Webアプリケーションフレームワークのデファクトであり、他のフレームワークの追従を許さないほど多く採用されています。

フレームワークとは

英和辞典によるとフレームワーク (=framework) とは、「骨組み、枠組み、構造、体制など」と解説されていますが、コンピュータの分野では、「ある特定のソフトウェアを対象にした、再利用可能な設計プロダクトを構成するモジュールの集合」と定義されます。アプリケーションを構築する場合、システムのアーキテクチャ、クラス、クラス間の協調動作の方法など、さまざまな事柄を設計してから製造を行います。通常であれば、この作業を構築ごとに繰り返すことになりますが、共通の目的を持つアプリケーションには共通の機能が存在し、場合によっては似かよったアーキテクチャによって構築される場合もあります。フレームワークは、これら共通の機能やアーキテクチャを抽象化し、アプリケーションの雛形を提供することで、コードの再利用性を向上させ、案件ごとの構築の負担を軽減するものです。

コードの再利用という考え方は古くはライブラリやコンポーネントという方法で行われてきました。これらの方法はAPI仕様を理解すれば使えるため利用しやすいのですが、アプリケーション全体からみるとほんの一部の機能しか再利用できず、大幅な生産性向上は期待できませんでした。

説明図:ライブラリによるコード再利用
図:ライブラリによるコード再利用

一方、フレームワークを用いてアプリケーションを構築する場合、フレームワークが提供する規約やしくみに沿った形で設計、製造しなくてはならないなどの制限や、事前知識を習得する必要があります。しかし製造は、下図のように、提供される抽象クラスの継承クラスを作成し、アプリケーション固有の機能のみを実装することになりますので、構築時に開発する部分は格段に少なくなります。

説明図:フレームワークによるコード再利用
図:フレームワークによるコード再利用

フレームワークを利用した場合でもライブラリを利用してさらに再利用化を促進することは可能なので、ライブラリの利用と、フレームワークの利用は相反するものではありません。

フレームワークを用いたアプリケーションの製造では、メインプログラムは記述せず、呼び出される部分を記述します。メインプログラム部分とアーキテクチャが決められているため、アプリケーション依存の部分の作成には、設計や実装においてさまざまな規約に基づく必要がありますが、以下のようなすばらしい効果が得られます。

  • 基本的なアーキテクチャを繰り返し設計する必要がなくなり、構築までの負担、時間が軽減される。
  • 拡張部分が、一定の規約に基づいて設計作成されるため、拡張部の再利用性の向上も期待できる。
  • 基本機能の部分は、フレームワーク側で充分にテストされている場合、個々のアプリケーションではテストの必要がなく、拡張したコードの正当性の確保にのみに注力できる。
  • コード量が軽減することにより、保守コストが削減される。

このようにアプリケーション構築にフレームワークを導入することで、生産性、品質、コスト面の向上がはかれるのです。

Strutsの概要

Strutsは Tomcat を生み出した Apache Software Foundation で開発されている、 Java、servlet、JSPテクノロジを用いたオープンソースのWebアプリケーションフレームワークです。 Webアプリケーションフレームワークは、Webアプリケーションの定型的な処理 (リクエストの受け取り、フォームデータの操作、レスポンスページの生成処理など) を抽象化したもので、このフレームワークを目的アプリケーションの機能にあわせて拡張することで、さまざまなWebアプリケーションが作成できるようになります。すなわち、定型的な処理は作成する必要がないということです。数多くのWebアプリケーションフレームワークが存在するなか、Strutsがデファクトとなった理由/特徴は以下のとおりです。

  • 必要な機能のみをシンプルに提供
    非常にシンプルかつ機能的で、洗練されたアーキテクチャをもつWebアプリケーションフレームワークであり、Webアプリケーション構築の上で必要な、最低限の機能を提供しています。
  • オープンソースによる開発
    Strutsを開発しているApacheプロジェクトは、整備された運用ルールにもとづき、より良いものを作り出す志をもった、多くの優れた開発者が参加しており、作ったものをただ公開しているようなオープンソースプロダクトとは一線を画しています。
  • Apacheライセンスにもとづき商利用も可能
    Strutsの配布は The Apache Software License (ASL) にもとづいて配布されています。ASLは商利用や再配布に特別な制限のない、比較的自由なライセンスです。
  • モデルの実装には非関与
    Strutsのサービススコープはプレゼンテーション層に特化しており、モデルの実装方法を規定していません。これは、ビジネスロジックの実装方法をEJBでもJavaクラスでも実装可能なことを示しており、非常に自由度の高いアプリケーションの構築を可能としています。
  • ポータビリティの確保
    ピュアJavaで作成されたStrutsはポータビリティにも気が配られており、ほとんどすべてのアプリケーションサーバー (Webコンテナ) での動作が報告されています。
  • API互換性の維持
    バージョンアップ時のAPIの互換性を保証するというポリシを持って開発されており、利用したアプリケーションの寿命をいたずらに短くしないよう考慮されています。
  • 洗練されたアーキテクチャ
    Struts自身は、オープンソースゆえに、世界中の多くの優秀な開発者、レビュアーによってよく検討されたアーキテクチャとなっており、世のフレームワーク論なども視野に入れた洗練された設計がなされています。このため、多くの開発者にとって理解しやすく、非常に導入しやすいものとなっています。
  • MVCモデル2
    Strutsが採用しているMVCモデル2アーキテクチャパターンの実装では、モデル、ビュー、コントローラーのそれぞれの結びつきは非常に弱く、1つの変更が及ぼす影響が最小限に抑えられるように設計されています。これは、それぞれの開発を分業でき、また平行して開発が可能なことを示しており、たとえばページデザイナとビジネスロジック開発者の分業が可能となります。
  • J2EE仕様との親和性
    プレゼンテーション部の作成にはJSPテクノロジを用いており、Java、servlet、JSP以外の特別な技術知識を必要としないため、導入に関して開発要員の確保や学習のオーバヘッドが軽微ですむという利点があります。また、リソースバンドルを利用したマルチリンガル対応を考慮した機能を持ち、ブラウザの言語によって返却するコンテンツを変更する機能が簡単に実現できます。

MVCモデル2

Strutsが導入しているMVCモデル2は、Strutsを理解する上で非常に重要ですので、ここで簡単に説明しておきましょう。MVCモデルの歴史は古く、Smalltalk-80 (世界で最初に広まったオブジェクト指向言語) における、ユーザーインタフェース構築のためのアーキテクチャとして提唱されました。MVCは、モデル (Model) -ビュー (View) -コントローラー (Controller) の3種類のオブジェクトがそれぞれ、

  • Model:ビジネスロジック
  • View:プレゼンテーション
  • Controller:制御

と役割を分担し協調しあってアプリケーションを動作させる方法です。

Strutsは、ModelをJavaBeansで、ViewをJSPで、ControllerをServletで実装した MVCモデル2と呼ばれるアーキテクチャを採用しています。また、その機能を極力シンプルにするというポリシで設計されており、MVCモデル2におけるStrutsの適用範囲は図に示すとおり、Modelには及んでいません。これにより、ビジネスロジックなどを実装するModelはフレームワークにとらわれることなく自由に、Javaのクラスでも、EJBでも実装できるようになっています。利用する側としては非常に自由度の高いフレームワークと言えるでしょう。

説明図:MVCモデル2
図:MVCモデル2

Strutsの動作

Strutsで作成したWebアプリケーションの動作を図に示しました。リクエストが処理されてからレスポンスを生成するまでを順に追いながら、コンポーネントと動作を見ていきましょう。

説明図:Strutsの動作
図:Strutsの動作
  1. ブラウザからHTTPリクエストが送られます。
  2. Strutsが提供するコントローラーは、リクエストを実際に処理するリクエストプロセッサ (Struts提供) に処理を委譲します。
  3. リクエストプロセッサは、リクエストのURLと呼び出す処理のマッピングをActionConfigから入手し、リクエストに対応したアクションクラス (Actionクラスの継承クラスで、開発者が作成します) を呼び出します。ActionConfigは、リクエストURLに対応した処理が記述されているstruts-config.xml (開発者が記述) の情報を起動時に読込、保持しているクラスです。
  4. HTTPリクエスト中にフォーム情報がある場合、その情報を対応するアクションフォームBean (開発者が作成) にセットします。リクエストとアクションフォームBeanの対応はstruts-config.xmlに記述します。
  5. アクションフォームBeanの検証機能にて、リクエストデータの正当性をチェックした後、3. で決定したアクションを呼び出し、データのセットされたアクションフォームBeanを引数として渡します。
  6. 呼び出されたアクションではビジネスロジックを呼び出します。ビジネスロジックは、JavaクラスやEJBなどでアクションとは別に実装し、それを呼び出すための処理のみをアクションで実装します。このポリシにより、プレゼンテーション層とビジネスロジック層の明確な分離をもたらし、ビジネスロジックの再利用性とメンテナンス性が向上します。
  7. リクエスト処理の結果表示のための情報をJavaBeansやアクションフォームBeanクラスにセットし、コンテキストと呼ばれるオブジェクトの保管場所に保存します。
  8. ビジネスロジックの処理結果を判断し、遷移すべきページを示す情報 (アクションフォワードクラス) を、呼び出し元であるリクエストプロセッサに返却します。
  9. アクションから返却されたアクションフォワードクラスが示すJSPページ (開発者が作成) を呼び出します。
  10. 呼び出されたJSP内では、表示のために必要な情報をJSPタグのuseBeanやカスタムタグライブラリなどで、コンテキストから取り出します。
  11. JSPによって生成されたページをHTTPレスポンスとして返却します。

上記手順によって、リクエスト処理が完了します。図中の太枠のアイテムが開発者が用意するものです。

次回の記事はこちら。

※本稿は月刊JavaWorld (株式会社IDGジャパン発行) 2003年9月号および2003年11月号に掲載した連載「Jakarta活用指南」記事の元原稿に加筆修正したものです。

  • 株式会社アークシステムの来訪管理・会議室予約システム BRoomHubs
  • 低コスト・短納期で提供するまるごとおまかせZabbix