AW==Adam Winer -- Oracle representative to the JavaServer Faces Expert Group and architect of ADF Faces.
TF==Ted Farrell -- chief architect for Application Development Tools at Oracle corpoation
−JavaServer Facesは今後どうなりますか？。
AW: 非常に近い将来、JSF の規格はJSP やJSTLと並んでJ2EEに統合化され、JSP やJSTLとの共用性が改善される。早くもJSF 1.2 は、J2EE 5.0の中核的な部位のひとつになる。われわれJ2EEエキスパートグループは、JSF とJSP の式言語API を一本化した。それは、JSF とJSP の双方にとって大きな利益をもたらす。
JSF の将来像に関して最も重要なのは、それがエキスパートグループが作る規格によってでなく、JSF のコンポーネントとJSF テクノロジの大規模で健全なエコシステムを作りあげる、JSF コミュニティの努力によって形成されることだ。われわれOracleのADF Faces （Oracleが作ったカスタムJSF コンポーネント集）は、そのようなエコシステムの重要な一部だ。
−OracleはJSF をどのように使っていますか？。
TF: Oracleは業界のスタンダードを完全にサポートしており、JSF もその例外ではない。OracleはAdamを中心にJSF のエキスパートグループに最初から尽力しており、規格の策定に重要な貢献を果たした。OracleはJSF コンポーネントの豊富な集合と、JSF のためのビジュアルな開発ツールを作っている。JSF のコンポーネント集を商用製品として発売したのは、大手ベンダとしてはOracleが最初だ。
AW:Oracle のADF Faces は、JSF の規格の上に構築された大規模なコンポーネントライブラリだ。それは、クライアントサイドヴァリデーション、ダイアログフレームワークなど、ほかにはないUIフレームワークを数多く提供している。ADF Faces はSun の参考実装を使用しているので、JSF の規格に正しく準拠した実装の上なら、どの実装の上でも使える。JSF のOracle独自の実装、というものはない。
−JSF はIDE がなくても使えますか？。
AW: もちろんだ。HTMLページをDreamweaver がなくても作れる、StrutsのコードをEmacs で書ける、それと同じく、IDE がなくてもJSF は使える。JSF の中に、IDE を必要とする部分はない。
JSF にはツールの開発をしやすくするための大量の努力が盛り込まれているので、JSP をIDE で開発することに比べれば、JSF をIDE で開発するメリットは大きい。しかしそれは、IDE がなければJSF アプリケーションを開発できない、という意味ではない。ユーザのfaces-config.xmlとコンポーネントライブラリのfaces-config.xmlには、IDE のための豊富な情報を盛りこむことができる。それによって、IDE などのツールの機能性が向上する。したがって、JSF はIDE を使わないと開発が難しい、のではなくて、IDE を使うと開発がより一層しやすくなる、とは言える。
−JSF のタグはHTMLのタグとかけ離れすぎているので、Web デザイナーにとって使いづらいという説がありますね。
AW:JSFの規格が定めているJSF のタグに関しては、その不平は理解できないね。<input type="text"> と書く代わりに<h:inputText> と書く。両者の間には１対１の対応関係がある。
しかしADF Faces コンポーネントライブラリには、高度なコンポーネントが多いから、HTMLとかけ離れた部分もある。今後は、通常のHTMLを書く部分が今と同じく残ると同時に、それと並行して、ユーザとの豊富な対話能力を提供する高度なコンポーネントに移行していく部分が増えるだろう。今現在、ほとんどのWeb ページが５年前と同じで、大手の優秀なスタッフを抱えたところだけが本当に新しいユーザインタフェイスを提供している。その原因は、毎回、車輪を再発明するように、最小公分母から開発を始めなければならないからだ。ADF Faces によるリッチなクライアントは、JSF がそういう状況からの脱却であることの好例だ。
−JSP やStrutsではなくJSF を採るべき最大の動機は何でしょうか？。
AW:Struts は本質的にコントローラのフレームワークだ。そのHTMLタグやTiles のライブラリはビューの部分だが、それらはあくまでも周辺的なものであり、本格的で高機能なビュー部位ではない。
それに対してJSF は、本質的にビューのフレームワークだ。JSF はStrutsがカバーしていない多くの問題を解決する。中でもいちばん重要なのは、そのUIコンポーネントのモデルが、非常にリッチなコンポーネント集合と、リッチなユーザ対話性を可能にしていることだ。
JavaがC++ を駆逐しないのと同じく、JSF がStrutsを駆逐することはない。しかし今後の数年間では、StrutsのイノベーションよりもJSF 周辺のイノベーションのほうがずっと大きいだろう。Strutsのイノベーションの方向性は、JSF が扱わないコントローラ機能の部分だ。
−JSF 1.1 以降のJSF に関するOracleのビジョンは？。
TF: OracleはJSF をベースとする開発を、今後も続ける。今後は、DHTML やモバイルデバイス用、telnetアプリケーション向け等のレンダーキットも加える。それによってユーザは、単一のプログラミングインタフェイス(J2EE/Faces)によって多様なデバイスをサポートできるようになる。他社のUIソリューションでは、デベロッパはDHTML 、JavaScript、モバイル機の上のグラフィクスなど、個々の要素について詳しい知識を取得しなければならない。
−ADF Faces はOracle以外のプラットホームもサポートするのですか？。
AW: イエス。ADF Faces と全体としてのADF は、Oracle以外のアプリケーションサーバやデータベースの上でも使える。
TF:JBoss, WebLogic, WebSphere, SQLServer, DB2, MySqlなどの上で利用を実証した。
−OracleのADF Faces のコンポーネントがMyFaces などと違う点は、主にどこにありますか？。
TF: JSF の規格では、さまざまなベンダのツールやランタイムの上で、規格に準拠したコンポーネントが使える。そこでベンダによる大きな違いはコンポーネントに現れる。OracleのADF Faces は、きわめてデータ指向の、多様なエンタプライズ向けコンポーネントの集大成だ。そのほかの既製コンポーネントは、外見的には良くても、アプリケーションからデータを取得してページの上に表示し、そのデータをユーザが自由に操作する能力に関しては、コンポーネントの実装に大差がある。コンポーネントの対話性を充実させるためにプログラマが大量のコードを書いたり、コンポーネントを拡張したりする代わりに、ADF Faces は数ダースもの、すぐにそのまま使える、データ指向のコンポーネントを提供している。そのルック＆フィールは、内蔵の“スキニング(skinning)”技術によって、自由にカスタマイズできる。
AW: そのほかの既製のコンポーネント集に比べてADF Faces は、カバー範囲が広く、コンポーネント数が多くて、より堅牢（ロバスト）だ。ADF Faces はOracleの社内ですでに広く使われており、アクセシビリティや国際化の機能を最初から持っている。あとからそれらを実装する必要がない。しかしJSF の偉大なところは、ADF Faces を使ったからといって、ユーザはそれに閉じ込められることがない。ほかのベンダのコンポーネントを併用することも、当然できる。
−リッチなWeb クライアント技術として、JSF を、MacromediaのFlexとか、DHTML 、SVG などと比べるといかがですか？。
TF: アプリケーションをクライアント上に表示する技術としては、さまざまなものが市場に出回っている。しかし、それらのテクノロジのコストはどうか？。うちの顧客たちは、よくこんな質問をする：
「新しいプログラミング言語を勉強しなければならないのか？」
「それは多様な種類のデバイスをサポートしているか？」
「コンポーネントを別の環境でも使えるか？」
そのほかのテクノロジとJSF の大きな違いは、これらの質問への答えがJSF では、「ノー」、「いくらでも多様」、「イエス」であることだ。
JSF では、単一の統一的なプログラミングインタフェイスを使ってプログラミングをする。多様性はコンポーネントが面倒見る。たとえばADF Faces のコンポーネントの一部はHTMLにレンダリングされ、あるいはWeb デバイスにレンダリングされ、DHTML/JavaScriptにレンダリングされ、Telnetにレンダリングされる場合もある。プログラマは、これらの環境や言語に合わせて別々のプログラミングを学ぶ必要がない。クライアントのタイプがどれだけ変わっても、API は一つ、開発ツールも一つですむ。
−JSF のエキスパートグループに対するOracleの貢献について聞かせてください。
TF: OracleはJavaServer Facesに、その発表の時点から参加している。そして第一回のエキスパートグループの集まりから一貫して大きな貢献をしている。Oracleは、ADF UIX のようなWeb フレームワークや、J2EE向けの開発ツールの豊富な経験を踏まえて、エキスパートグループに参加している。OracleチームのリーダーであるAdam Winerは、最初の旗揚げ会合から今日のJSF 1.2 の設計に至るまで、最も活発なメンバーである。
−現在のJSF の規格に欠けているもの、Oracleから貢献・提案したいものは何ですか？。AW: まっ先に、二つのものが思い浮かぶね。ひとつは、J2EEのデベロッパたちに愛されているJSTLの<c:forEach> タグを併用できないことだ。JSF と併用するための方法が、よく分からないのだ。ADF Faces は、その方法を見つけた。そしてその方法を、J2EEの規格の一部として提供したいと思っている。もうひとつは、JSF の標準コンポーネントにはクライアントサイドの入力ヴァリデーションの機能がないことだ。ADF Faces は、それをサポートしており、そのコンポーネントをJSF の今後の規格の一部として提供することも可能だ。
−JSF がJ2EEの世界で、ASP のように普及することを妨げているものがあるとすれば、それは何でしょうか？。
TF: 普及は、ソフトウェアベンダの採用如何にかかっている。JSF の場合は、大手のソフトウェアベンダのほとんどが、このテクノロジのためのソリューションの提供に取り組んでいる。多くのベンダがこの取り組みにリソースをつぎ込み、顧客の実務ニーズにこのテクノロジをマッチさせるべく、顧客たちと共に努力している。JSF の将来性は強力であり確実である。
【読者感想】
(1) 現状ではStrutsはコントローラ中心のフレームワークであり、JSF はビュー中心のフレームワークで、JSF-Struts統合化ライブラリにより両者を使える。しかしJSF の規格の今後の進化により、Strutsフレームワークのコントローラ部分を導入し、その結果、Strutsの開発は停止する。ベンダやデベロッパの開発努力は、JSF のフリーでオープンソースな実装系や、ADF, MyFaces, などなどのようなコンポーネントライブラリの開発に向けられることになる。
(2)Struts の作者Craig McClanahanは、J2EEアプリケーションにおけるJSF とStrutsの統合化について語っている。彼は、Struts 2.0（コードネーム：Shale ）はJavaServer Facesを軸として構築される、と述べている。
(3) コンポーネント指向でイベント駆動型のフレームワークは、Tapestry, Echo, WebOnSwingなどいろいろある。その中でJSF は、どの部分で差をつけるのか？。
(4) JSF が多様なデバイスとコンポーネントの再利用をサポートするなら、その特徴は、FlexやXAMLに比べてむしろニッチ市場ではないか？。
(5)(3)へのコメント
JSF はJ2EEの一員になり、メジャーな存在になり、サポートするベンダも増える。Tapestryその他は、バスに乗り遅れて道端にしゃがみこむ人びとになる。
(6)(5)への反論
Entity Bean は、J2EEの一員で、メジャーで、多くのベンダがサポートしているが、５年経った今もあまり人気がないね。
(7)(6)への反論
しかし、企業ユーザなどでは、政治的な力が働くからね。マイナーなものは、採用しにくいだろうね。
(8)(7)への反論
JSF は半煮えのソリューション（結核を治すためのバンドエイド）のように感じる。Strutsよりも便利で効率的なものは欲しい。しかし、それがまさにJSF なのか、今のところは確信を持てない。
(9) Microsoft は、ビューとモデルの分離についてVBデベロッパたちに教える代わりに、WebFormsを提供した。そのページ指向のパラダイムによって、デスクトップからWeb 開発に移行する痛みを和らげようとした。そこで今のVBの連中は、かつてデスクトップでやったのと同じ混乱を、Web アプリケーションに嬉々として持ち込んでいる。最近のMicrosoft はページ指向のWebFormsの限界に気づいて、流行遅れのStrutsが最初から持っていたコントローラフレームワーク…ASP.NET 2.0 のFront Controller…を導入した。Microsoft は、Avalon/XAML の導入後はWebFormsを非推奨にするつもりだ。この技術的飛躍が起きているとき、Javaのソフトウェアエンジニアたちが採用するものはJSF だ…それはリクエスト/ リスポンスのサイクルの中でリダイレクトを実行できないテクノロジだ。
--end of text--