SeamのWebサイトのWeb Beansのページ(リンク)では、Web Beansを次のように説明している。
・・・アプリケーションの開発を格段に容易にするJava EE環境の各種サービスです。Web Beansによって、JavaBeansやEnterprise Java Beansといった従来のJavaコンポーネントタイプの上に、高度なライフサイクル・相互作用モデルが階層化されます。従来のJava EEプログラミングモデルを補完するものとして、Web Beansの各種サービスによって以下の項目が実現します。
- 明確なコンテキストに拘束された、処理状態を把握するコンポーネントのライフサイクルの向上
- 依存性注入（Dependency Injection）のタイプセーフな方法
- イベント通知機能による対話
- デコレータと呼ばれる、業務上の問題を解決する場合に使用することに適した新しい種類のインターセプタをコンポーネントにバインドするためのより優れた方法
現在、公開草案の見直しが行われているが、Web Beansの広い範囲に及ぶ潜在的な影響について、JEEコミュニティの一部のメンバーはずっと関心を持っており、スペックリードであるGavin King氏は見直し期間を2009年2月まで延長して、このような不安事項の一部に対応することを決定したと発表した。InfoQがKing氏と面談を行った結果、以下のようなさまざまな事実が判明した。
InfoQ: 私が知りたいと思っていたことは、SpringとWeb Beansの両方がJava EEの依存性注入フレームワークを提供できるのであれば、Web BeansがSpringよりも優れている点として最も重要なポイントは何なのかということです。SpringSourceの中には、専門家グループとかかわっている人はいますか？
Web BeansのモデルはSpring、Guice、Seamの影響を受けています。しかし、もっとも直接的な影響を受けているのは、Seamの文脈状態管理モデルとGuiceのタイプセーフな依存性注入モデルです。SeamもGuiceもSpringの進化に影響を与えてきており、最近Springには文脈beansやGuiceスタイルを強制するタイプを限定的にサポートする機能が付加されました。しかし、Web Beansには、クリーンな状態から開始するというメリットがあったため、最終結果は全体的にクリーンさ、簡潔さ、タイプセーフ性が高くなります。Web Beansには、デコレータ、ステレオタイプ、展開タイプ、タイプセーフなイベント・オブザーバ結合、インターセプタ拘束注釈など、ほかのソリューションにはないさまざまな革新的な新しい概念も取り入れられています。最終的には、XML色が断然に少なくなり、タイプセーフ性が大幅に増します。
SpringSourceは現在、JSR-299 EGでは表現されていません。
InfoQ: デコレータとインターセプタの違いは何ですか？
デコレータで解決できるすべての問題はおそらくインターセプタで解決できると思いますが、インターセプタはビジネスロジックを処理する方法としては、タイプセーフの度合いが非常に低く、不自然な方法です。呼び出し中で、特定のJavaタイプに適用できるメソッドの意味論を認識した割り込みを行う方法がデコレータによって実現します。つまり、インターセプタは、トランザクション管理やセキュリティといった技術的な問題をビジネスロジックから切り離すことができるのに対し、デコレータはビジネス上の問題に対して同様の区分化を実現するということです。
InfoQ: Web Beansでイベントモデルが必要な理由を教えてください。
それは、疎結合の、強く型付けされたコード化アプローチを推進したいと考えているからです。この考え方は、仕様のすべての根底をなすものです。しかし、それ以上に、処理状態を把握できるような疎結合なコンポーネントを記述しようとしているのも事実です。処理状態を把握できるコンポーネントは、キャッシュした状態を管理するなどの理由で、Webコンテキストでは問題になる可能性があります。ロールバックが発生すると中断されるアプリケーションが数多くありますが、それは状態がトランザクションと結合していないからです。このような問題は、一般的にアプリケーションが高負荷下に置かれているときにしか発生しないため、テストするのが困難です。そのような理由で、イベントモデルによって、この種の問題を処理する方法を実現しているのです。
InfoQ: Web Beansのイベントモデルは、オブザーバ、オブサーバブルのパターンとどう違うのですか？
私たちは、今でもこれのいくつかの側面に取り組んでいます。たとえば、IBMが提示した問題として、現在の草案ではクラスタを処理する意味論が一切提供されることがないので、次の草案では、おそらくイベントがJMSトピックまたはキューに送信できるようになり、Javaオブジェクトをキューに送信するすばらしい方法が提供されるでしょう。詳細については、ブログのこの記事を参照してください(リンク)。
InfoQ: Web BeansがJFSとEJBの統合と密接に関係していることは明らかですが、統合に関して、ほかにどのような用途を考えましたか？
Web Beansは、依存性注入のフレームワークです。しかし、ある意味では、依存性注入は技術的には特に興味深いものではありません。実際に、依存性注入フレームワークの役割は、オブジェクト間のやり取りのバックボーンを提供することです。依存性注入フレームワークは、アプリケーションのコンポーネント間のやり取りだけでなく、アプリケーションのコンポーネントとインフラとのやり取りのバックボーンでもあります。Java EEには、サードパーティのフレームワークを環境に統合するAPIがないため、現時点ではSpringやSeamといった何らかのバックボーンを階層化することによって、サードパーティのフレームワークを環境に統合する必要があります。したがって、Web Beansによって、Java EEの一部であるこれを実行する標準的な方法を提供しています。
私たちが重視している用途として本当に重要なものは4つあり、この4つの用途でほかの用途の大部分をカバーできていると思っています。1つ目はWebフレームワークです、Web Beansと別のWebフレームワークの統合は容易にできる必要がありますが、これは容易にできると考えています。2つ目は、JBPMやOracleのBPMといったビジネスプロセスマネジメントエンジンです。これによって、階層管理モデルが使用されるようになりました。3つ目は、Springであろうと、Seamであろうと、Guiceであろうと、それ以外の依存性注入メカニズムであろうと、既存の依存性注入フレームワークを使っている人たちが、既存のコードとWeb Beansを統合できる必要があるということです。4つ目はJAX-RSです。
InfoQ: そうすると、Web BeansはSeam 3にどのような影響を与えるのでしょうか？
Seam 3の中核となるエンジンはWeb Beansです。そして、JSF、JBPM、Hibernate、Drools、Groovy、Wicket、GWTといった私たちが気に入っているテクノロジーや、セキュリティ、PDF、Eメール、Excel、RSSなどのレンダリングといった一般的な問題を解決するテクノロジーを統合する各種のモジュールを移植したり、これらをWeb Beansのバックボーンに移植したりすることを考えています。私は今でも、Seam独自の依存性注入方法を利用した既存のコードをサポートする方法について考えていますが、Seam 2での統合層によって、またはこのAPIをWeb Beans上に再実装することによって実現できると考えています。
InfoQ: リモートEJBを処理する方法がわかりません。処理できないのでしょうか。そうであれば、これが貴社が対応しようとしていることですか？
そうです。公開草案の改訂版において取り組むべき問題点の1つとして、これまで何度もあった機能要求であるEJBへのリモート参照など、既存のJava EEリソースタイプすべてにWeb Beansスタイルの注入を提供することがあります。
InfoQ: JCPに関する意見として、専門家グループ間でのやり取りが困難であるということがよく聞かれます。Web Beansが、JSFやEJBといったさまざまな仕様やサーブレットや一般的な注釈に関係しているとすれば、このことがどの程度の問題となり、どのように対処してきたかについて知りたいと思っていました。
これは、ずっと私たちを悩ませてきた問題であり、現在でもこの問題と格闘しています。言いたくはないのですが、複数の専門家グループにかかわる問題を解決するということにおいては、JCPはほとんど機能していません。
InfoQ: Web Beansの仕様が最初に発表されたとき、多くの議論が交わされました。議論の対象となった項目は、Web Beansの汎用性、そしてJEE仕様やJSE 7仕様の一部にすることによって、SwingやJavaFXなど、依存性注入フレームワークが役に立つかもしれない場所でWeb Beansを使用できるようにするべきか否かという点でした。しかし、仕様にはEJB（または、少なくともEJB Lite）への依存性が組み込まれているため、Web Beansの幅広い適応性が制限されているように思われます。この点についての考えを少し聞かせてください。また、APIが元来の権限を越えて拡張されなかった理由についても教えてください。
もしWeb BeansがEJBに代わるものを提供できると思われていたら、政治的に存立可能であったかどうかはわかりませんが、これは本当の制限ではないと考えます。SE環境で使用できるものとして求められていたものは、EJB LiteとWeb Beansの機能を兼ね備えた統合型パッケージ製品です。EJB Liteを使わずにWeb Beansを実現することは、私には大した意味を持ちません。このような不自由な製品を使うと、独自の非標準的なトランザクション管理や持続性の統合などを構築する必要があるからです。統合型製品の設置スペースは、実際にはSpringなどよりも小さく（ただし、Guiceよりは大きい）、使用する構成もずっと小さくなります。
当然、コミュニティには、E、J、Bの文字を有するすべてのものに対して無意味な不安を抱いている人たちもいます。しかし、実のところ、Web Beansを利用したいのであれば、このような人たちは精神的な問題に打ち勝つ必要があるだけなのです！
InfoQ: JSRのことがはじめて話題になったとき、IBMはJCPの仕様について、以下のような懸念を公的に表明しました。
「私たちは、JSFとEJBのコンポーネントの統合という既定の方針を超えてJSR 299が進もうとしている方向性を懸念しており、この方向性を念頭に置いて継続的な取り組みを行うと、Java EE 6から分離される可能性もあります。さらに別のコンポーネントモデルの定義を付加するJava EE 6プラットフォームを採用することが簡単であることに、私たちのお客様は気づかないと思います。」
IBMの懸念は、仕様の方向性にどのような影響を与えたのでしょうか？
IBMをはじめとする多くのJCPメンバーが、新しい「コンポーネントモデル」であると特徴付けているWeb Beansの初期草案に対して批判的な意見を示しました。そこで、公開草案では、特定の既存のEEコンポーネントタイプに提供された各種サービスとして機能の再特徴付けを行いました。これは、部分的には、このような批判への対応になりましたが、十分な対応とはならなかったため、299の公開レビュー期間を延長して、仕様に変更を付け加えました。
先ごろ、IBMをはじめとするEEベンダーとともに、多くの時間を使って彼らの懸念事項に対応しました。IBMは、299の専門家グループに加わったばかりですが、現在公開草案の改訂版の策定に取り組んでいます。現在、主要なEEベンダーの意見は一致しています。それは、1月の終わりに公表される公開草案の改訂版で特定の懸念事項が対処されれば、299をEE 6のプラットフォームに組み込むべきであるという意見です。最終的に、EEプラットフォームは最先端の依存性ソリューションを標準装備することになります。
Web Beansの詳細はリファレンスガイド(リンク)に記載されている。最初のα版もSeamのWebサイト(リンク)からダウンロードできる。