BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース JSR-299 と Weld 1.0 の Java EE と JBoss への影響についての Gavin King との Q&A

JSR-299 と Weld 1.0 の Java EE と JBoss への影響についての Gavin King との Q&A

ブックマーク

原文(投稿日:2009/11/18)へのリンク

Red Hat の JBoss 部門は、JSR-299: Contexts and Dependency Injection for Java EE(以降では CDI とする) のための Java EE 6 参照実装である、Weld 1.0.0 を出荷した。Weld は、Sun の GlassFish Application Server バージョン 3 および、来たる JBoss AS 5.2.0 で使われている実装である。しかしながら、完全なアプリケーションサーバを必要としない。Weld は、Jetty 6.1 や Tomcat 6 のようなサーブレットコンテナにおいて動作させることができるし、Java SE 5.0 以上とですらも動作する。後者を示すために、Weld 配布には、コンソールアプリケーションの例と Swing アプリケーションの例が付属する。

JSR-299 のドラフトが最初に提出されたあとに、"注入可能なクラスをフレームワーク間でポータブルにする、実績があり、議論の余地の無いアノテーションの集まり" を標準化する目的で、Google と SpringSource は JSR-330 を提出した。だから CDI 仕様リードの Gavin King と情報交換したとき、私は JSR-330 が CDI にどのような影響を与えたかを最初に質問した。

CDI は今や JSR-330 で定義されている注入ポイント(injection point)を宣言するためのアノテーションを使用しています。330 で使われているモデルは、299 で既に定義していたものと本質的にはほとんど同一だったので、これはとても小さな影響でした。話を要約すると、おおよそ、アノテーション名の変更ということになります。

330 は完全な依存性注入のソリューションを定義していないことを記憶にとどめていてください。修飾子とともに、注入ポイントを宣言できるようにすることを定義していますが、残りは定義されていないままです。

InfoQ: CDI と EJB はどのようにして EE 6 で導入された管理 Bean モデルと動作するのでしょうか?

新しい管理 Bean の仕様は、私たちが JSR-299 (以前の仕様のドラフトで "Simple Web Beans" と呼んでいたもの) において行った作業の結果です。Simple Web Beans は依存性の注入、EL 名、インタセプタをサポートしていました。しかしプログラミング制限や EJB の完全な機能を持っていませんでした。

この結果として、普通の(plain) Java クラスの注入をサポートできることが絶対に必要だと論じている Red Hat と、新しい種類の EE "コンポーネント" を定義している 299 に満足していないことがはっきりしている他の EE ステークホルダとの間で、多くの論争がありました。

多くの議論の後、この"単純な"コンポーネントのアイデアは自身の仕様から取り除かれるであろう、EJB その他を含む、すべての他の EE コンポーネントプログラミングモデルの基礎を形成している、ソリューションに私たちは辿り着きました。それは偉大なビジョンでした。私たち全員がとても幸せになります。まだ EE 6 において完全に実現されていませんが。

最終的な結果は以下のようになります。CDI は、今や "管理 Bean" と呼ばれる、普通の Java クラスや EJB と一緒に動作できます。EJB は、今や単に、いくつかの追加のプログラミング制限や、いくつかの追加の機能を備えた特別な種類の管理 Bean と見なされます。それは、新しいユーザが EE を習得することを極めて容易にする、進歩したプログラミングモデルです。

InfoQ: まだ EJB は、自身のコンポーネントモデルを必要としますか?

私は、EE プラットフォームの方向性は、現在 EJB のみに定義されている機能を徐々に一般化することであると思います。そしてすべての管理 Bean にそれらを適用しています。例えば、@TransactionAttribute と @RolesAllowed が、すべての管理 Bean でサポートされるべきでない理由はありません。

けれども、まだ EJB は、メッセージ配送のエンドポイントを定義する場所、リモートや非同期メソッド呼出、タイマー、その他を持っています。それらの場合においては、EJB ライフサイクルモデルは多くの意味があります。

InfoQ: Seam は、CDI と同じように JSF 2 に対してもインスピレーションを提供してきました。JSF それ自身の問題を解決することは、Seam でそれらに取り組む上でどんな利点がありますか?

そうですね、精一杯、私たちは、ユーザエクスペリエンスを完全に透過的にするように取り組んできました。私たちは全く満足してませんでした。私たちのユーザは、彼らが JSF の機能を使っていたとき、いつも認識していました。そして彼らが Seam の機能を使っていたとき、それは JSF にあるべきでした。


CDI は、Red Hat のオープンソース Seam フレームワークとしての経験から生まれた。大雑把に言えば Seam のプログラミングモデルを Java EE 6 のためのプログラミングモデルとして標準化している。CDI は Java EE 6 において 3 つの主な目的を果たしている。最初に、スコープ、状態、コンテキストに結び付けられたコンポーネントのライフサイクルを管理する宣言的な方法を提供する。次に、標準化された、アノテーション駆動の、型安全な依存性注入フレームワークを Google の Guice に似たやり方でプラットフォームに提供する。3 番目に、Java EE プラットフォームのポータブルな拡張機能を開発するための Service Provider Interface (SPI) を提供する。

CDI の Service Provider Interface は Java EE の拡張性の主要な部分、Java EE 6 の目標の中心になっている。JSR-316 仕様は述べる。

...私たちは、それらの技術をよりきれいに階層化する、あるいはJava EE アプリケーションサーバにプラグインすることを可能にすることに価値があると信じている。より多くの拡張可能なポイントやより多くの Service Provider Interface を追加することによって、これらの他の技術がプラットフォーム実装にきれいに実用的にプラグインできる。そして同時に開発者にとってプラットフォームに組み込まれている設備として使いやすいものとなる。

活動中のこの例は、Seam の次のリリース、バージョン 3 で見つけられる。CDI をそのコアエンジンとして使っており、CDI には存在しない BPM 統合、Drools 統合、PDF と電子メールテンプレートのサポート、Excel 生成、などのような多くの追加機能を提供するために CDI Service Provider Interface を使っている。これらの拡張(そしてサードパーティベンダによって構築される潜在的なその他)は、すべての Java EE 6 環境を含む JSR-299 をサポートするあらゆる環境において動作させることができる。CDI 仕様によると、

ポータブルな拡張機能は、以下のようにしてコンテナと統合することができる。
• それ自身の Bean、インタセプタ、コンテナへのデコレータを提供すること
• 依存性注入サービスを使用してそれ自身のオブジェクトへ依存性を注入すること
• カスタムスコープのためのコンテキスト実装を提供すること
• いくつかの他のソースからのメタデータでアノテーションベースのメタデータを増加または上書きすること

Gavin King は InfoQ に語った。

CDI と JSF2 の出現は Seam にとって新しい方向性を表しています。

Seam2 では、私たちは JSF の欠陥を取り繕うことに多大なるエネルギーを消耗しました。その結果、私たちに興味を引かせるフルレンジのプレゼンテーション技術との統合を作業する時間が無くなってしまいました。JSF2 は、私たちに他の領域にエネルギーを集中させます。

最も重要なのは、今や CDI は、すべての EE 6 アプリケーションサーバでポータブルなコア"エンジン"を提供していることです。それは Tomcat、Jetty、Resin でさえも利用可能です。このコアは、どんな特別なプレゼンテーション技術にも依存しません。代わりに良く定義されたポータブルな拡張機能開発者用 SPI があります。この SPI は生態系の基盤として役立ちます。もしあなたがフレームワーク開発者なら、あなたのフレームワークと CDI を統合するために、ひいては、EE 環境と統合するために何をする必要があるか、今や正確に分かります。これがおそらく CDI のもっともエキサイティングな機能です。

したがって、Seam3 は CDI のポータブルな拡張機能の集まりとなるでしょう。それらはあらゆるアプリケーションサーバで動作し、CDI のプログラミングモデルへの拡張と私たちの興味を引く他の技術との統合を提供するでしょう。

JBoss の CTO である Mark Little は、CDI と Seam は、全ての彼らのプロジェクトとプラットフォームのための未来であると述べている

ESB と SOA-P のようなチームは、Seam の新しいバージョンが彼らのユニークな要求に配慮することを保証するために、既にそれらのプロジェクトやプラットフォームと密接に取り組んでいます。重要なことにもかかわらず、いくつかのそれらのプロジェクトは、Seam は変更無しでも適切だったと、既に決定しました。だから可能と思っていたよりも、より緊密で素早い統合を見ることでしょう。

そして King はさらに念を押した。

Seam は既に Red Hat のかなりの数のプロジェクトで成功裏に使われています。CDI は、Seam のコアな機能性をより強固な基盤に置きます。そして私たちの CDI 実装、Weld は、より多く集中されて、インフラストラクチャの構成要素はより良くテストされてきました。このことは、Seam2 において単純には適切でなかった全ての種類の物事に Weld を使い始めることができることを意味します。ウェブサイトを構築するときにすることは何もありません。

Red Hat の外部や多数の他の CDI 実装もまた反騰しているのは、同様に真実である 。 Resin メーカの Caucho Technology は、実装 (CanDI) を持っており、Resin コンテナ自身は内部で CDI を広範囲に及んで使用している。 Apache も OpenWebBeans と呼ばれる実装について作業しているし、Granite DS は Flex アプリケーションで CDI を使用することを可能にする実装を持っている。ブログによると

私たちの気持ちは、JCDI はイベント駆動のアーキテクチャにおいて Flex RIA と完全に合うということです。JCDI アプリケーションは非常にきれいに見えます。JBoss Seam は、より多くの機能を提供しています。[けれども]彼らは必ずしも RIA フロントエンドでは意味をなしません。

この記事に星をつける

おすすめ度
スタイル

BT