今年の4月より、大規模プロジェクトのアーキテクトとして忙しい日々を送っています。
今回、現時点（2010/08）では日本では書籍どころか、Webでもさほど情報がないJavaServerFaces2.0(JSF2.0)をWebのフレームワークとして採用することにしました。元々、今の会社ではJSF1.1,1.2の実績はそれなりにあるのですが、2.0は初の採用になります。
JSF1.x時代といえば、ライブラリはApache MyFacesを利用し、その拡張ライブラリであるMyFaces Tomahawkを利用するという形態が一般的だったかと思います。今の会社でも多かったのはそのパターンで、Tomahawkに含まれる各種コンポーネントをさらに拡張してプロジェクト用のタグライブラリを作成して、それを開発者に使用させるという形でした。
JSF2.0となると、すでにRIではなくなったMyFacesではなく、新たにRIとなったMojarraを利用するというのが品質・パフォーマンス面でベターと判断し、今回のプロジェクトではMojarraの各種コンポーネントを拡張することにしました。別プロジェクトで開発したコンポーネントは当然Tomahawk依存ですから、ConverterやValidatorを除けば、ほとんど流用できるものはないので、フルスクラッチで開発しています。
さて、ここ数ヶ月、私自身がJSF2.0と格闘してきて、自分なりに色々と見えてきた部分があるので、これからJSF2.0を採用しようとしている方々向けに、何回かに分けて情報を提供できればと思います。今回はまずJSF2.0のメリットを紹介しようと思います。
JSF2.0の採用理由となりうるメリットを挙げてみます。
1.Faceletsによるテンプレート化
JSF2.0より、JSF用のOSSライブラリであったFaceletsが標準仕様として取り込まれました。元々はJSF1.1でも組み合わせて利用することはできましたが、標準となったことにより、これまでのJSPファイルにJSFタグを記述していくスタイルから、 XHTMLでJSFタグもしくはHTMLタグを記述するというスタイルに大きく変わります。
そもそもJSPはコンパイルすればServletのclassファイルになるわけですが、FaceletsではJSPは登場してこないので、XHTMLすなわちXMLを動的に解析＆コンパイルするというアーキテクチャになります。ですので、これまでJSPのプリコンパイルは？というと、もはや必要ないわけで、さらにプリコンパイルがないから遅いのでは？というと、これまたパフォーマンスも申し分ありません。
このFaceletsが利用できるようになったため、テンプレート化が進むというのが大きなメリットです。例えば、これまでJSPでは、各画面で共通のヘッダ・フッタなどのタグも、共通化したJSPを作成してそれをincludeするという形で、常に主体となるのは個別のJSPでした。
Faceletsの登場により、JSF2.0では、ひとつまたは複数のテンプレートとなるXHTMLを作成して、その差分のみを個別のXHTMLとして記述することが可能になります。
例えば下記のように、JSF2.0では、ヘッダのincludeだとか、CSS読み込みのためのstyleタグなども全てtemplate.xhtmlに記述してしまえば、個別のJSPはすっきりとした形に記述することが可能です。
1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
アーキテクトとしては、上記のようなtemplate.xhtmlだとかsearch_condition.xhtmlのようなファイルを、いかに準備できるかというのがポイントになってきますね。
例えば上記のように、ui:paramタグを使って、ManagedBeanのエイリアスを記述してしまえば、テンプレート側でもこのエイリアスでインスタンスに関わらずManagedBeanにアクセスできるので、テンプレート化をさらに進めることができますが、このようなテクニックも駆使できるというのは、個別にコーディングさせる部分を減らすことに大いに貢献できます。
2.Ajaxサポートによる部分サブミット＆部分レンダリング
JSF2.0からは、Ajaxがタグとして提供されるようになり、JavaScriptを個別にコーディングしなくてもよくなりました。これまでも、JBoss RichFacesやIceFaces、PrimeFacesといったOSSライブラリを使えば同じようなことが実現できたのですが、やはり標準仕様となったことは非常に大きいと思います。
最近のブラウザであればまだよいのですが、IE6などのJavaScriptが遅く、レンダリング自体が遅いブラウザのサポートをしなければならない現状では、Ajaxタグにより、部分サブミット＆部分レンダリングが可能になるので、これをガンガン使っていけば、例えばホストマイグレーションなど、パフォーマンス要件が厳しい場合には有効な手段となると思います。
なお、アーキテクトとして、Ajaxを基本にしていくという決断をした場合は、これまでServletFilterで行っていたようなエラー発生時に、エラーページにForwardするような実装はできませんので、一旦エラー用のXMLを返して、JavaScript側でエラーページに飛ばすなどの工夫は必要になります。やはりエラーハンドリングについてはある程度苦戦すると覚悟したほうがよいです。
※f:ajaxタグの実装は下記ページが参考になります。
http://d.hatena.ne.jp/shin/20090726/p1
3.XHTMLベースでのコンポーネント開発
これまでは独自のタグを作成するという場合は、JavaでUIコンポーネントやレンダラといったクラスをベースコンポーネントを継承しつつも作成していくというプロセスを取らざるを得ませんでした。JSF2.0より、XHTMLでもコンポーネントを作成することができるようになり、これを独自タグとして、個別のXHTMLから利用するということが可能になりました。
ただし、あくまでXHTMLで作成できるのは、複合コンポーネント（Composite Component）であり、既存のタグを組み合わせるというレベル感ではありますので、完全にJavaで書かなくてよいのかどうかは、そのプロジェクトで求められている要件により異なります。ですので、複合コンポーネントで多少トリッキーなタグ実装になってもやり切るという判断もありですし、Javaで複雑なコンポーネントはこれまでと同じように作成しておき、開発者向けにはこれをラップしたようなXHTMLで提供するというバランス型もありです。
ちなみに、私が現在担当しているプロジェクトでは、コンポーネント側でかなりがんばらなければならないので、Javaでコアコンポーネントを開発し、XHTMLによる複合コンポーネントも利用するというバランス型にしています。
なお、業務チームでもXHTMLであれば開発できるので、サブシステム内でしか使わないニッチなコンポーネントであれば、アーキテクチャチームではなく業務チームに作らせるという権限委譲も可能ですので、検討するとよいでしょう。
さて、今回は主なメリット３つに絞って書いてみましたが、faces-configが不要だったり、ナビゲーションが楽になっているなど、他にもメリットはたくさんあったりします。
逆に、現時点における最大のデメリットは「情報がとにかく少ない」ということに尽きると思います。私の場合は、洋書を購入して、あとはひたすらデバッグと、Mojarraのソースを読み続けて、ひと通り理解しましたが、逆に言えば、それだけの覚悟＆スキルに自信がなければ、少々現時点での採用は難しいかもしれません。
とはいえ、ようやく他のLLのWebフレームワークやASP.NETと比べても、それなりに使う気になるレベルになったとは言えると思いますので、アーキテクトの皆さんには是非とも利用を検討してみて頂きたいと思います。