Strutsの新バージョンである Struts1.3 がリリース間近となってきた。Struts1.3.0は開発者向けとして既にリリースされている。現在J2EE Webアプリケーションを構築する際の事実上のデファクト Webアプリケーションフレームワークとなっている Struts の新バージョンだけに，その動向が注目されている。
今回は，この新しいStrutsの新機能を中心に紹介をする。
開発が進む「2つのStruts」
Strutsの今後については様々な情報が飛び交っているが，ここでStrutsの現在とロードマップについて整理しておこう。
執筆時現在，正式にリリースされているのはバージョン1.2系のStruts。多くの読者が利用しているだろう。
Strutsを開発しているApache Software Foundation のStruts プロジェクトでは，現在２つのフレームワークを開発している。１つは，前述したSturts，もう１つは以前ご紹介したShale（関連記事「Strutsの後継Shaleによるアプリケーション作成」）だ。それぞれの正式な名称は，Apache Struts Action Framework と Apache Shale Frameworkである。
現在 Apache Sturts Action Framework(以降，新Struts)は，バージョン1.3の開発が急ピッチで進められている。そして，現在の正式リリースされているバージョン 1.2系のStrutsは Strutsクラッシックと呼ばれるようになる。なぜなら，新Sturtsでは内部のアーキテクチャを大幅に刷新し，新しい思想の元に開発がすすめられているからだ。
一方，Strutsバージョン２とも呼ばれることがあったShaleは，独立したプロダクトとして開発が進められる事となり，事実上２つのWebアプリケーションフレームワークが１つのプロジェクト内で開発されることとなった。
新Sturtsで変わるのは内部アーキテクチャ
新Sturtsでは何が変わるのだろうか。今回はこの点にフォーカスしていきたいと思う。
まず今回のマイナーバージョンアップの目的は，「今後のStrutsの進化に耐えうるコードベースの用意」だ。よってStruts1.0->Struts1.1→1.2といった従来のマイナーバージョンアップ時のような大幅な機能追加は予定されていない。アプリケーションへのインタフェースである「アクション」や「アクション・フォームBean」といった概念は従来通り存在し，基本的なクラスもそのまま利用可能となっている。すなわち，Struts1.2のアプリケーションをSturts1.3ベースへバージョンアップすることは，そう難しくはないので安心いただきたい。
それよりも，新Strutsでは内部のアーキテクチャが大幅に変更されている。これは，アプリケーション開発者へのインパクトよりも，Strutsをベースとした拡張フレームワークの製造者にインパクトがあるだろう。StrutsはMVCモデル２アーキテクチャをWebアプリケーションに提供するだけのシンプルなフレームワークである。そのため，実案件での利用時には，機能不足を補うためになんらかの拡張を行っていることが多い。その拡張方式によっては大きなインパクトがあることになる。
開発単位が細分化され，配布も機能別に
では，どのような変化があったのかを紹介してゆく。まず大きな変更点としてStrutsの開発単位が細分化されたことが挙げられるだろう。
Strutsクラッシックでは，Strutsは１つの塊として提供され，「コントローラ」「Sturtsカスタムタグライブラリ」「Struts-Validaotr」「Struts-Tiles」などの様々な機能が１つのJARファイルの中に同梱されていた。
新Strutsでは，機能別に開発単位を細分化しそれぞれを別のJARファイルとして配布するようになる。開発のリリースサイクルも個別に行われるようになるが，Struts Action Framework としてのリリース形態は複数のJARファイルをまとめて配布するようにし，各JARファイル間のバージョンの整合性が保たれるようにするようだ。
この形式の配布物は "Struts Action Library" と呼ばれるようになる。執筆時時点では開発者向けのリリース版である バージョン 1.3.00 の Struts Action Library が http://svn.apache.org/dist/struts/action-lib/action-library_1.3_00.zip より入手可能となっている。この配布形式には開発単位毎のJARファイルと，Strutsの動作および開発に必要なその他のJARファイルおよび各種DTDファイルが同梱されている。Struts関連のJARファイルおよび開発単位は，以下のようになっている。
これらの他にも，サンプルアプリケーションや以前ご紹介したStruts-Faces（関連記事「JSFでStrutsは不要になる？答えを握るStruts-Facesとは」），Sandboxで開発されていた Struts Flow やStruts Scriptingなどが同レベルの開発単位として管理されるようになった。すなわち，利用者は必要な機能のJARを選択して利用するようになる。
様々な機能拡張や変化に耐えられるよう部品化
この開発・配布単位の変化は，先に述べた「今後のStrutsの進化に耐えうるコードベースの用意」と無関係ではない。Struts開発チームは，様々な機能拡張や変化にStrutsが耐えられるようにStrutsを部品化し，様々な他の部品や拡張パッケージ，独自実装機能と組み合わせやすくしたのだ。
その代表的な変更点が，HTTPリクエストの処理に 「Chain of Responsibility」パターンを導入したことだ。「Chain of Responsibility」パターンは GoF(the Gang of Four)が提唱したデザインパターンの１つで，オブジェクトを鎖状に繋ぎ，それを順次渡り歩くことで処理をおこなってゆくパターンだ。新Strutsでは，この方式をStrutsクラッシックのリクエストプロセッサが行っていた「HTTPリクエストの処理」に採用し，リクエストプロセッサを全面的に書き換えた。この新しいリクエストプロセッサは，ComposableRequestProcessor クラスとして新Strutsの標準リクエストプロセッサとなっている（従来のリクエストプロセッサ「RequestProcessor」もStrut1.3.0 には同梱されており，変更することも可能）。
このComposableRequestProcessorは，「Chain of Responsibility」パターン を実現するために，XMLファイルに定義されたチェーン情報を読み込み，順に処理を行っていくように設計されている。すなわち，このXMLファイルを変更することで，HTTPリクエストの処理順序や，独自の処理を自由なタイミングで挿入することができるようになっているのだ。Strutsクラッシックで同様のことを行うためには，RequestProcessorクラスを継承したクラスを用意し，拡張ポイントであるメソッドをオーバーライドするか，独自の制御フローを用意する必要があった。しかし，新しいリクエストプロセッサ ComposableRequestProcessorでは，XMLファイルを変更するのみで様々な拡張が行えるようになっており，まさに「進化に耐えうるコードベース」となっている。
