Struts1に代わるWebフレームワークの選択

先日書いたいつまでStruts1を使い続けるの? - 達人プログラマーを目指してが想像以上の反響の大きさで驚いています。こんなにたくさんブクマいただいたのはブログ開設以来初めてです。政治的理由でフレームワークが最初から天下り的に与えられてしまい、結果的に要件に合わないフレームワークの使用を強いられて苦労させられた経験のある開発者の方も多いと思います。また、逆にフレームワークを提供したり選択したりする側の立場で、時代遅れのフレームワークを今後どうにかしなくてはならないという問題意識を持たれている方も多いのではないかと思います。(これは、ちょうど多くの会社のパソコンでWindows XPやIE6ではさすがに時代遅れだと認識はしていても、コストなどからなかなか思うようにバージョンアップが進まないというのと似たところもあると思います。*1)Struts1が既に時代遅れなのは知っているけれど、抱えている既存フレームワークの改修や開発者の再教育などのコストを考えると新しいフレームワークへの移行は簡単ではないのですよという声が聞こえてきそうです。
Javaを使ったWebアプリケーション開発ということ自体が、既に時代遅れという意見の方もおられるかもしれませんが、直ちにすべての開発をRubyやRIA技術に移行すればよいかというと、もちろん現実はそんなに簡単ではありません。開発ツールの完成度や既存のライブラリーの流用、開発者のスキルということを考えると、今後も、しばらくはJavaが主流の言語の一つとして利用され続けるというのは間違いないでしょう。(もちろん、Java言語自体も進化していくので、以前のバージョンと比較すると別言語のようになっていく可能性もあると思いますが。)
そこで、ここではJava EE環境で業務アプリケーションを作成するという前提で、Struts1に代わるWebアプリケーションフレームワークとして今後何を選択したらよいのかという点について、現時点で自分なりに考えてみた結果を整理しておきたいと思います。

2種類のMVCフレームワークの分類

一言でMVCフレームワークと言っても、大きく分けると

の2種類に分類できることをご存知でしょうか?前者のアクションベースのカテゴリーに属するフレームワークは、HTTPのリクエスト→レスポンスという基本的なプロトコルを完全に抽象化することなく、リクエストごとに処理をアクションとして記述していく方式になります。Struts1はこの方式の代表的な例ですが、他に似たようなアーキテクチャーのフレームワークとしてStruts2、Spring MVC、Stripesなどがこのカテゴリーに分類できます。一方、後者はちょうどVisual BasicDelphi、SwingなどのRADツールを使って、画面を作るのと似たような感覚で画面部品を配置することで、簡単に画面を開発できるようにするというタイプのフレームワークです。代表的なものを挙げるとJSFWicketTapestry、Echo、Clickなど、こちらのカテゴリーにもたくさんのフレームワークが存在します。*2

アクションベースフレームワークの長所

アクションベースフレームワークとしては以下のような長所が考えられます。

  • サーブレットのModel2パターン(PetStore)やStrutsなど伝統的な開発手法で経験者が豊富
  • しくみが単純な傾向があるため、オーバーヘッドが小さく性能が高い
  • Webのアーキテクチャーを隠蔽しないためRESTfulなサイトを構築しやすい
  • 画面レイアウトやデザインに対する柔軟性が高い

一般的には、コンシューマー系のサイトなど、リクエスト数やユーザー数に対するスケーラビリティの確保が最重要で画面デザインも独立させたいようなケースに適合すると考えられます。ただ、このような場合は、そもそもPHPRubyなどJava以外の言語での開発や、CMSパッケージの適用、SaaSなどの利用も競合することが考えられるので、本当にJavaベースのスクラッチ開発が最適なのかよくよく検討が必要でしょう。

コンポーネントベースフレームワークの長所

一方、コンポーネントベースフレームワークには以下のような長所があります。

したがって、社内のVBアプリケーションを単純にWebアプリケーションとして作り変えるような場合は適合することが多いと思います。特に社内システムだと、何百という入力項目に何十というコマンドボタンが付いているようなきわめて複雑な画面を作らなくてはならないことが多くあります。これを直接HTMLのフォームで作成すると非常に大変ですが、コンポーネントベースのフレームワークを使えば画面部品の流用で比較的簡単に作成できると思います。しくみが複雑なため、どうしても性能面では不利になると思うので対外サイトの構築には通常は向かないと思います。なお、このカテゴリーが適するアプリケーションであれば、FlexなどのRIA技術やJavaScript中心のAjaxフレームワークGWTなど)も有効なことが多いため、競合するところがあります。

今後注目したいJavaのWebアプリケーションフレームワーク

それで、Struts1に代わる次世代のJavaフレームワークですが、残念ながら今のところこれといった決め手がないというか、非常に選択が悩ましいです。
一応、アクションベースが適合するケースでDIコンテナーとしてSpringを利用する前提なら、まずはSpring MVCを第一選択肢として検討することをお勧めします。Springの一部として現在もアクティブに開発が行われているため、将来性も期待できますし、やはりSpringと相性が抜群によいのは大変に魅力的です。特に、Spring2.5以降で利用できる@MVCではCoCで設定ファイルの記述量も以前と比べて激減していますし、アクションクラスに相当するコントローラーのコード記述量はStruts比で半分から3割程度にも少なくできます。さらに、複雑な会話処理が必要ならWebFlowを組み合わせることができます。現状日本語の情報がほとんどないのと、設計の柔軟性が高い分ある程度(侵略的になり過ぎない範囲で)パターンごとに規約を決めてあげないと初心者のプログラマーには敷居が高いというところが欠点かもしれません。
一方、コンポーネントベースを選択するケースでは、やはりJava EE標準で部品やツールも豊富なため、まずはJSFを中心に検討すべきでしょう。特にJSF2.0では、Seamの特徴を取り入れることで前バージョンの欠点を克服して、かなり実用的なフレームワークになっています。あくまでも現時点における私の主観ですが、まとめると大体以下のような感じになると思います。もちろん、業務要件や開発者の経験によって良し悪しの判断は大きく変わってくるので、あまり鵜呑みにされないように注意してください。

基本
カテゴリー
実績 開発者数 将来性 HTML
非侵略性*3
会話状態*4 学習
コスト
開発
生産性
性能 単体試験
容易性
CoC*5活用
Struts1 アクション × × × × ×
SAStruts アクション ×*6 ×
Struts2 アクション × ×
Spring MVC アクション *7
JSF コンポーネント *8 *9
Wicket コンポーネント × *10 ×*11 ×
Tapestry コンポーネント ×*12 ×

フルスタックのフレームワークについて

Spring RooやGrailsなどのフレームワークが利用できるのであれば、最初からビルドやテストの仕組みが提供されているので
ビルドシステム構築スキルの重要性 - 達人プログラマーを目指して
で書いたような問題も軽減されて、工数を削減できるかもしれません。今のところ、こうしたフレームワークでどこまでのことが可能か未調査なのですが、基本的にはCRUD処理を中心とした単純なアプリケーション向けな印象があります。ただし、RooはRealオブジェクト指向ということですし、実は高度なロジックを実現できたりするかもしれません。
Webフレームワークの比較については以下の記事も参考になると思います。
Raible Designs | My Comparing JVM Web Frameworks Presentation from Devoxx 2010

*1:ただし、Windows7WindowsXPと比べて本当に便利かどうかは疑問の余地もありますが。私が新機能を使いこなしていないだけかもしれませんが。ただし、MSから強制されるバージョンアップとは違い、フレームワークの進歩はOSSなどプログラマーの必要性からボトムアップで起こります。この点はちょっと趣が違うかもしれません。

*2:Seamは純粋なWebフレームワークではありませんが、JSFWicketと組合せられるということで、このカテゴリーに属すると考えることもできます。

*3:画面を普通のhtmlに近い形で作成できるかどうか。html編集ツールでそのまま編集できたりjspへの変換が楽。独自のタグを多用するとポイントが下がる。non obtrusive htmlの適当な訳。

*4:ウィザードなど一連の処理範囲で状態をサーバー側に保持する機能を持つかどうか。特にブラウザーのタブやウィンドウごとに独立した状態を管理できるかどうか。普通のサーブレットAPIではセッションというログインユーザーごとに1つのグローバルな領域でしか状態が保持できないため、会話状態の管理は困難。

*5:Convention over Configuration。設定より規約ということで規約どおりなら無駄な設定ファイルを省略できるようにすることで無駄な設定を少なくすること。

*6:Struts1依存であることと現時点におけるSeasar2自体の将来性を考慮

*7:WebFlowを併用した場合

*8:faceletsを利用する前提

*9:SeamCDIを併用した場合

*10:Seamを併用した場合

*11:OOPのスキルが平凡なチームを想定

*12:前バージョンでの実績は別カウントとする