1年ちょっと前にJSF2.0の記事を書いたのですが、JavaEE6のWebフレームワーク標準であるものの、やはりまだJSF2.0についての日本語情報は少ないですね。私がJSF2.0を導入したシステムも、ようやく第１弾のカットオーバーを数ヶ月前に迎えて、幸い安定稼働しています。

さて、今回はJSF2.0、特にFaceletsによるカスタムタグを、Webプロジェクト（war)に含めない場合の実装について記述したいと思います。前回の記事において、XHTMLによるコンポーネントが作れるようになったと書いたのですが、画面共通で利用する汎用的なコンポーネントを開発者向けに提供したいと考えた場合、Webプロジェクトではなく、別途jarを分けて提供したいというケースは多いのではないかと思います。

これまで大規模プロジェクトでアーキテクトとして携わってきた経験上、開発者が勝手に共通コンポーネントを改修してしまったり、誤って削除するなど、開発者が触れる場所にあるのは、全体最適化および標準化の観点からも好ましくありません。またバージョニングの観点からも、例えばMavenにてフレームワーク系のjarはバージョニングにしているケースも多いでしょうから、やはりシステム共通レベルの実装はおいそれと開発者が触れないようにしておくほうがベターです。

とはいえ、別のjarのresourcesフォルダにXHTMLを置くだけでは、warの中に含めた場合と違い、カスタムタグとして認識されないので、一工夫必要になるのですが、Webで調べてもほとんど言及されてないところなので、今回取り上げることにしました。

今年の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のメリットを紹介しようと思います。

現在私は、数ヶ月前にカットオーバーしたシステムの品質保証というやっかいな仕事に取り組んでいます。。。

まぁよくある話なのですが、納期最優先で気合いと根性によりなんとかカットオーバーして、クリティカルな障害は出ていないものの、ポツポツとしょぼい障害が発生するという状況が続いており、顧客から品質について見直せというクレームが出ているわけです。

ちなみに、アーキテクチャ視点から見たこのシステムは、Java製で、WebフレームワークはStrutsを使用しており、ORマッパーやDI・AOPなどの比較的新しい技術は利用していないため、ゴリゴリの実装になっていました。PLに聞いたところ、新技術を利用することによる技術的問題を抱える余裕がないため、枯れた技術で構成したとのことです。まぁ個人的には、枯れた技術を利用してももっとやりようがあったとは思いますが、後の祭りですね。

とりあえず、MavenやHudsonを導入して、JUnitで単体テストクラスを作って（今はありません）などというタスクになるといいうことで、引き受けたわけですが、提案資料を作っている最中に大きな障害が発生し、ソースレビューだとか機能テストのやり直しだとか、もうちょっと根本的なところから手を付けることになりそうです。

よくよく考えてみると、上記に挙げた単体テストの自動化＆レポート作成などの仕組みは、開発フェーズにおけるプロセス改善として、品質を作り込むための事前予防的なアプローチです。対して、今回の私のミッションは、すでにカットオーバーしているシステムの品質をチェックして、問題があれば直すということで、最初から後手のアプローチになっているわけですね。

とはいえ、顧客に対して、「品質が上がってよかった」もしくは「品質に問題がないことがわかってよかった」のいずれかの納得感を持ってもらわねばなりません。これらを定量的に実感してもらうためには、何らかの品質指標を使うという手もあるのですが、これを可視化するとこちらとしても困るとか、今後もその指標に縛られるから嫌だとか、PM・PLからいちゃもんをつけられたため、工学的な手法も微妙だったりします。

そんなこんなで、内部的な事情も考慮しつつ、障害分析の深掘りから見えてくる傾向と対策により品質チェックをするという方向で提案しようとしています。これで顧客からどんな反応が返ってくるかドキドキですが。。。

■参考リンク

Wikipedia：ISO 9126

■参考にした文献