Red HatのJBoss部門は、この2,3ヶ月間に、幾つものアップデートをリリース予定で、その中には、webアプリケーション フレームワーク Seamの新しいメジャーリリースやJSFコンポーネント ライブラリ RichFacesが含まれている。InfoQは、RedHatの Principal Software Engineerである Pete Muir氏と、将来のリリースと彼のSeamチームからInfinispan データグリッド チームへの移動について聞いた。
InfoQ:Infinispanチームへの移動、おめでとうございます。なんで移動したのですか？
ありがとうございます。私が話した殆どの人達、特にソフトウェア エンジニアには、やっているプロジェクトを本当に楽しみ始める仕事の周期があり、時間と共にその喜びがだんだん薄れていきます。私は、 Seam and Weldプロジェクトで喜びの周期の終りに近づいているのを感じたので、新しい挑戦を求める決心をしました。Infinispanは、自然な選択のようでした。私は、以前マスターコースの修論の一部として、データグリッドに関わっていました。そして、RedHat,は、Infinispanへの投資を増やしていますので、それは、会社のゴールともよく合うわけです。
InfoQ: Infinispanでのあなたの計画は何ですか？
個人的には、仮想ノードに取り掛かる事から始めます。Infinispanは、一貫したハッシュ ウィールを使って、分散環境における、決定論的な、速い、そして小さなオーバーヘッドのデータ検索を実現しています。しかし、均等な分散を保証する、いくつかの技術を使っても（例えば MurmurHashやビット スプレッダー）、ユーザは、少数ノードのデータグリッドでは、データはうまく分散していない（あるノードだけが処理でもデータ格納でも高負荷になる）、と報告しています。しかし、多数ノードのグリッドでは、この問題がありません。１つの物理ノードで複数のノードを提供する仮想ノードがこれに役立つのです。Infinispan 5には、他に幾つもの改善点がありますが、少々話したいと思います。
Alpha 2で既に使えるMapReduceが一番目です。Infinispanは、本質的に、無制限に線形な、インメモリのデータ拡張を提供しますが、大規模な計算実行能力がないデータグリッドを持つのは、運転免許書無しに、Ferrariを持つようなものです。 Big Dataの領域に方向性を欠いていることや既存の分散実行フレームワークの複雑さに対する批判を耳にしてきました。我々の主な焦点は、パワーと豊富なフィーチャ セットを犠牲にせずに、単純化することです。Infinispanの MapReduceについてもっと知りたければ、Vladimirのブログを見てください。
我々は、またHibernate OGM (object-grid mapper)にも取り組んでいます。 Hibernate OGMは、 Hibernate コア エンジンを再利用していますが、エンティティをInfinispan（結局、いかなるキー／値の格納）に保存し、リレーショナル データベースにではありません。またクエリのサポートにも取り組んでいます。最初は、JP-QLのサブセットですが、徐々に成長していきます。このプロジェクトは、まだ初期段階ですが、長期の目標は、JPAの全機能ではないにしても、ほとんどをサポートすることです。もっと詳しくは、http://community.jboss.org/wiki/HibernateOGMGeneralInformationsで見れます。あなたがもし自分の手も汚したいのであれば、フォーラムで Emmanuel か Sanneに連絡することです。
InfoQ: あなたがCDI 1.1のEGリードになることは、知っているのですが、CDI 1.1の計画について教えてください。
CDI 1.1のEGリードになります。実際の話、JSR提案の最初のドラフトを終えたところで、公開前のフィードバックを求めています。 CDI 1.0は、コミュニティから非常に肯定的に受け入れられ、一般的に、現在の機能があれば、人々は、必要とすることを実現できる、と思っています。しかし、正しいソリューションを検討する時間が充分なく、後回しになっている所があります。もちろん若干の予期しなかった問題です。CDI 1.1では、このような未完成な部分に取組みます。同時にコミュニティが作った若干の最も人気のある拡張を標準化します。機能面で大きなものを追加する計画は、ありません。追加するものは、以下のものです。
- インターセプタとデコレータのグローバルな順番付けと代替のグローバルな使用可能性
- 組込みコンテキストを管理するためのAPI。JSFの外で使える対話コンテキストの組込み実装ができる
- Java EEコンテナの外から開始できる組込みモード
- コンストラクタ レベルでのBean宣言
- 静的なインジェクション
- Seam Solderから@Unwrapsの包含
- いくつものPortable Extensions SPI の小さな改善
- クライアント制御のコンテキスト
- Java EEプラットフォームで使われる際のライブラリでのCDIサポートの改善
- Servletイベント用のCDIイベントの送信
- アプリケーション ライフサイクル イベント
InfoQ: 昨年の終わりごろ、ツイッターやブログ（例えば ここ）に、JSR-299 (CDI)のリファレンス実装であるWeldのメモリ問題やパフォーマンス問題に関して、多くのコメントがありました。その時あなたは、改善を検討中だ、と言いましたが、どのぐらい進みましたか？
非常に改善できた、と言えるのがうれしいです。メモリ使用量、ブート時間、実行時のパフォーマンスが改善できました。我々の測定では、いくつかのbeansをデプロイすることで、ブート時間は2倍改善され、たくさんのbeansを使うと10倍改善できました。メモリ使用量は、デプロイのbeansの数に依らず、一貫して4倍改善しました。実行時のパフォーマンスは、40％改善しました。Weldは、他のCDI実装より優れていますし、DIの世界の他のどのソリューションよりも優っています。これらの改善は、 Weld 1.1.0（これは、 JBoss AS 6 と GlassFish 3.1に含まれている）にすべて含まれています。我々は、更に改善するつもりでいます。特にメモリ使用に関してです。Weld 1.2 （ JBoss AS 7に含まれる予定）に含まれます。最終的には、Weldが使うのは、1bean当たり1kぐらいが目標です。
InfoQ: 多くのチームが、JSF2に移行する前に Seam 3 と RichFaces 4を待っているのを知っています。RichFaces 4 は、3月に出るのですよね。Seam 3は、いつになるのか知ってますか？その間、Seam 2に JSF 2/Facelets 2のサポートを追加する計画はありますか？
3月までにSeam 3を完成させるつもりです。Beta 1は今入手できますし 、Seam 3に必要な全てのモジュールが入っています。例えば、
- Seam Security, Java EEの仕様で提供されるよりも強化された認証と認可を追加し、 OpenID や SAMLとシームレスに統合された連邦身元確認のフィーチャを追加している
- XML Configuration, XMLを介してCDIベースのアプリケーションを設定する方法を提供する
- Seam Faces, JSF2のフィーチャに追加され、重要な、他のSeamモジュールへのJSF統合ポイントを提供する
- Seam Catch, 開発者に統一された、堅牢な例外処理プロセスを提供する
- Seam Wicket, CDIコンポーネント モデルと他のSeamモジュールを Apache Wicketに統合する
- Seam International, CDIベースのアプリケーションにローカライズされたサービスを提供する
- Seam Remoting, CDI beansをwebページから直接起動するためのAjax ベースのフレームワーク
... そしてもっとです。我々は、Seam 2.2.1をリリースしたばかりで、これの主目標は、 JSF 1.2を走らせている JBoss AS 6上のSeam 2を充分サポートすることです。我々は、長い間工数を考えて、Seam 2にJSF2サポートを追加する（Seam 3の開発が遅くなります）か、JSF 1.2 のサポートに留まるべきかを議論してきました。我々は、現在 Seam 2.3のリリースを計画しており、JSF2を完全にサポートするつもりです。その間、様々なコミュニティ メンバーは、進んで物事に取り組んで、JSF2と動くSeam 2.2の派生を提供しています。例えば、 https://github.com/heyoulin/seam2jsf2 ですが、本当にうれしいです。
InfoQ: RichFaces 4 には、何が期待できますか？
RichFaces 4 は、JSF 2での新しいAjaxフィーチャをターゲットにした RichFacesリリースです。要約すると、
- 完全な JSF 2.0サポートと拡張
- Bean Validation (JSR-303)と標準のJSF バリデーターの両方と統合した、真のクライアントサイド バリデーション
- 多数の再設計され、最適化されたコンポーネント
- Atmosphereと統合したClient Push
- 統合されたデータ テーブルの設計により、柔軟で、使い易くなった
- Google App Engine のサポート
- Ajaxリクエストの高度なキューイング
- 動的なリソース サポート
InfoQ: JBoss AS 6は、Java EE 6 Web Profileのみに対して認定されたことに興味があります。なぜ Java EE 6の仕様を完全にサポートしないのですか？この動きが Java EE 6マーケットに影響しますか？
AS 6の目標は、Web Profile TCKにできるだけ早くパスすることだったので、CDIのような新しい、興奮するようないくつかの技術をできるだけ早く完全なJBoss ランタイムで使えたのです。AS6は、AS5のコードベース（完全なEE5の実装）の上に作られているので、AS 6は、追加のJSRも含んでいます。このことを変に深読みしないでください。我々は、EEに背を向けているわけではなく、我々は単に、できるだけ早く進めたかっただけです。 Java EE 6には、多くの魅力がありますから。 JBoss Web Profileサーバーを速く出すのは、重要なマイルストーンであり、その上に、完全なEE 6認定を得るように開発していきます。これは、AS 7のコミュニティ ロードマップにあり、その後で、今年の終わりごろにRedHat製品を完全にサポートする予定です。