...

JavaServer Facesの初の早期アクセスリリース(initial early access release)の一般公開に伴い、STRUTS-DEVとSTRUTS-USER両メーリングリストの会員の多くが、Strutsの未来について心配している。そこで、以下に、この問題に対する私の現在の考えを簡潔に述べたいと思う。
---Craig R. McClanahan

背景

  JavaServer Faces(JSF)は、Java Community Processの下でJSR 127として開発が進められている。その目的は、Webアプリケーションの中で使用するユーザインタフェイス部位（コンポーネント）のための標準的なフレームワークを作ることである。その主な特徴と機能は次のとおり：

・ユーザインタフェイスコンポーネントの基本形。

・イベント処理の基本形。

・検査（ヴァリデーション）の枠組み。

・レンダリングの柔軟性（HTMLの多様な規格、HTML以外のマークアップ言語、マークアップ技術などに対し、プラグインにより対応）。

・HTML 4.01に対応する標準クラスRenderKit（およびRenderer）の提供…このライブラリは、JSFの実装系間に互換性を持たせ、JSFをより簡単に使いやすくし、ユーザのアプリケーションに対し実装系間のポータビリティを保証することが目的である。ただし、このライブラリには、実装系間の競争によって多くの技術革新が今後導入されることが期待される。

  上記の機能のすべてが、ごくふつうのJava APIsの規格として提供されるため、JavaServer Page(JSP)にとくに依存するものではない。しかし実際には、JSFのユーザの多くがJSPのユーザでもあると思われるため、JSFの規格には次のような一連の要件が付加されている：

・RenderKitの特定の実装に依存しない標準タグライブラリによって、共通的な処理（たとえばヴァリデータをコンポーネントに付加する）を記述する。

・基本的なHTML RenderKitのための標準タグライブラリを用意し、そのタグによって、各コンポーネントのタイプと、そのコンポーネントタイプのレンダリング方法（描画～表示方法）を記述する。
  これについては、実例を挙げたほうが分かりやすいだろう。UISelectOneコンポーネントの場合を考えてみよう。このコンポーネントはオプション（選択項目）のリストを表示し、その中の一つだけをユーザに選択させる。このようなコンポーネントは、基本的なHTML RenderKitでは三つの方法でレンダリングできる（それぞれ、別のRendererを使用する）。それら三つの方法はそれぞれ、次のようなタグで記述される：

<h:selectone_listbox>    すべてのオプションのリストを表示し、したがって
                          スクロールバーが表示されない。

<h:selectone_menu>       コンボボックスとして表示する（HTMLの<select>要素
                          でsize="1"としたもの）。

<h:selectone_radio>      複数のラジオボタンと説明用ラベルを表示する。

  なお、この場合、アプリケーションのデベロッパは、このコンポーネントを表示するために上のどのタグが使われるかを知る必要がない。ページの作者が、自分の目的に応じて自由に選べばよい（Java APIのレベルでこの選択をするためには、コンポーネントのインスタンスの"rendererType"プロパティをセットする）。これは、Strutsのタグに比べてJSFが優れていると言える多くの点の一つである。Strutsのタグでは、各要素をレンダリングする方法はつねにたった一つしかない。
  このほか、グリッドやツリーなど、複雑なコンポーネントを作る機能も提供されている。それは“小さな物から複雑な物を組み立てる”という、周知の技法を利用している。JSPではタグをネスティングすることによってそれを達成する。従来のHTMLでは、<form>要素の中の<input>要素をネスティングすることによって、それを実現していた。
  JavaServer Facesと、その規格草案、および初期参照実装に関する詳しい情報は、次のURLより入手できる：

http://java.sun.com/j2ee/javaserverfaces/

  Java Developer Connection（要登録,無料）には、JavaServer Facesを対象とするフォーラムがある。JSFに関する質問は、ここに提出するとよい：

http://forums.java.sun.com/forum.jsp?forum=427

  なおJavaServer Facesは、Servelet 2.3およびJSP 1.2（すなわちJ2EE 1.3対応コンテナ）に依存する。

Strutsへの影響

  JSFの低レベルのコンポーネントは、Strutsユーザにはお馴染みのstruts-htmlタグライブラリと非常によく似ているように思える。実際に、JSFのタグとStrutsのhtmlタグは多くの点で重複している。では、何が問題なのか？。
  2002年3月のJavaOneにおけるStruts同好集会で私は、StrutsとJSFはきわめてクリーンに統合化できる、と述べた。つまり、コントローラ、Action(s)、ビジネスロジックの表現の面でStrutsを使い続け、同時に、ユーザインタフェイスの面ではJSFを利用できる。その席で私は、あなたのアプリケーションの中のStrutsのhtmlタグの部分を、JSFのタグに書き換えることが可能だ、と述べた。そしてその際に、ビジネスロジックの部分やActionクラスはまったく無変更であり、コンフィギュレーションファイルstruts-config.xmlの中の要素をごくわずか書き換えるだけでよいのである。
  私は、JavaServer Facesの開発と並行して（私はJSR-127の規格書担当者なのだ）、まさにこのような、Struts/JSFを統合化するためのライブラリの開発にも取り組んでいる（Struts 1.1のみを対象…1.0は未着手）。そのライブラリはまだ未完成だが、上のパラグラフで述べたような目標は明らかに、JSFの現在の設計の下で十分に達成可能である。
  JSFの設計が今後変わることもありえるが、しかしJSR-127エキスパートグループの多くのメンバが、Strutsとの良質な統合化を、JSFの普及が成功するための重要な要因と見なしている。したがってJSFは今後とも、Strutsとの統合化が困難または不可能になる方向には進化しないと思われる。
  デベロッパの立場としては、ページの中でJSFのコンポーネントを使うためには、次の指針に従うだけでよい：

・/WEB-INF/libディレクトリの中に、新たに、struts-faces.jarファイルと、JSFの実装系のJARファイルを加える。

・JSFのタグとJSTLのタグは、ひとつのページの中で問題なく混用できるから、必要に応じてJSTLのタグを使ってよい。

・展開記述子web.xmlの中に、JSFの規格書９章に定められている要件のための２つのタグを加える。

・各ページを順に、１ページずつ、JSFのタグを使うよう書き換えていく。またJSFの要件に従って、各ページのための要素を適切に書き換える。

  統合化ライブラリは、Struts 1.1と共に使える単独のパッケージとして提供される予定だ。その中には、Strutsを使ったWebアプリケーションの基本形と、その「JSF化バージョン」が含まれている。それらを見れば、StrutsとJSFを併用するために書き換えるべき箇所が具体的に分かる。
  このライブラリには、統合化クラス本体（主に、JSFのApplicationHandler APIの実装クラス）のほかに、従来のstruts-htmlタグとほぼ同等の機能を提供する「Sturts的なJSFコンポーネント」（＝JSFのタグには同等のものがないもの）と、関連のレンダラーが含まれる。たとえばその中の「Struts的UIFormコンポーネント」は、formに対応するaction属性を記述でき、必要に応じてformビーンを作る。それはまさに、現在のタグと同等である。
  この統合化ライブラリの開発は、現在、順調に進められている。
  ただし、まだ、そのベータ版等を公開することができない。その主な理由は、JSFの早期アクセスリリース以降、JSFの規格にいくつかの変更が加えられたためである。新規格への対応化が完成次第、このライブラリはStrutsの"contrib"フォルダに加えられ、通常のApacheライセンス条項に基づいてダウンロードと利用が可能になる。とくに、そのソースコードは、あなたが独自のJSFコンポーネントを自作する際の、最初の“たたき台”として役に立つだろう。

ユーザインタフェイスのテクノロジとして何を選ぶべきか？

  Webアプリケーションに求められる機能性と開発スケジュールは、さまざまである。しかし、将来的な指針としては、次のようなことがおすすめである：

・StrutsのHTMLタグライブラリを使っている既存のStrutsアプリケーションを抱えている方は、そのアプリケーションをそのまま使いつづけてかまわない。Struts 1.1は、Strutsの既存の機能性を完全にサポートしている。

・統合化ライブラリが使えるようになったら、既存のアプリケーションの「JSFコンポーネント使用バージョン」を作るための時間費用等を判定するために、いくつかの実験をやってみること（JSFによってアプリケーションの機能性が増強されるので、そのような実験はやってみる価値が十分にある）。上で述べたように、JSFへの移行は１ページずつ、少しずつやればよい。全体を一挙にやる必要は、まったくないのである。

・これから開発する新しい、比較的小規模で開発時間の短いアプリケーションに関しては、StrutsのHTMLタグライブラリをそのまま使いつづける。

・開発期間の長いアプリケーションに関しては、StrutsのHTMLタグライブラリではなくJSFコンポーネントを使う/使い方を勉強することを、真剣に検討しよう。JSFのHTMLコンポーネントを使うという当面のメリットに加えて、将来的には、サードパーティ製の多様なJSFコンポーネントのライブラリを使える楽しみもある。Strutsのデベロッパたちも、そのようなライブラリの開発を手がけるだろう。

  Strutsのタグライブラリは、ユーザインタフェイス用の標準Java APIの開発に対し、大きな刺激と影響を与えた。私はJSTLの規格書担当者に、次のような冗談を言ったことがある：「Strutsのユーザは、式言語がStrutsなみに強力にならないかぎり、JSTLを絶対に使わないよ」。私のこの発言は、意外と大きな意味を秘めていたのだ。つまり今日では(JSFの登場によって)、HTMLタグに関しても同じこと（Strutsのhtmlタグよりも強力なものを作る、という衝動の存在）が言えるのだ。われわれはJSFというスタンダードへ移行することによって、Strutsの未来を新たな方向へ拡張し、切り開いていけるのである。

             Craig McClanahan