[解決済み] EJB3.1とCDIはどこで使うのか？

質問

Java EEベースの製品を作っているのですが、その中で GlassFish 3 と EJB 3.1 を使用しています。

私のアプリケーションは セッションビーンズ があり、スケジューラがあり、ウェブサービスを使用しています。最近、私は Apache TomEE をサポートする コンテクストと依存性注入 (CDI) . GlassFishコンテナもCDIをサポートしています。

CDIがまだ提供していない機能を必要としない場合、セッションビーンを置き換えることができますか？また、その場合、どのような利点があるのでしょうか？

どのように解決するのですか？

CDIとEJBは自由に組み合わせることができ、素晴らしい結果を得ることができます。 あなたが使用しているような @WebService と @Schedule といった、EJBを追加する良い理由となります。

多くの混乱があるので、ここではEJBとCDIについて、それぞれが一緒に関係するような一般的な情報を紹介します。

EJB >= CDI

なお、EJBは は CDI Beanであり、したがってCDIのすべての利点を有する。 その逆は（まだ）真実ではありません。 ですから、EJB対CDIと考える癖をつけないように注意してください。

Java EEの将来のバージョンでは、私たちはそれらを整列し続けるでしょう。 整合させるということは、すでにできることを、単に @Stateful , @Stateless または @Singleton のアノテーションを追加します。

実装用語でいうところのEJBとCDI

結局のところ、EJBとCDIはプロキシされたコンポーネントであるという同じ基本設計を共有しています。 EJBまたはCDIビーンへの参照を取得するとき、それは本物のビーンではありません。 むしろ、渡されたオブジェクトは偽物（プロキシ）です。 この偽オブジェクトのメソッドを呼び出すと、呼び出しはコンテナに送られます。コンテナはインターセプターやデコレーターなどを経由して呼び出しを行い、トランザクションやセキュリティチェックの処理も行います。 それがすべて終わると、最終的に呼び出しは本物のオブジェクトに送られ、結果はプロキシを通して呼び出し元に戻されます。

違いは、呼び出されるオブジェクトがどのように解決されるかという点だけです。 解決されるとは、コンテナが呼び出す実際のインスタンスをどこで、どのように探すかということです。

CDI では、コンテナは "scope" を探します。これは基本的に、特定の期間 (リクエストごと) に存在するハッシュマップとなります。 @RequestScoped や HTTP セッションごとに @SessionScoped アプリケーション単位 @ApplicationScoped , JSFの会話 @ConversationScoped またはカスタムスコープの実装に従います）。

EJB では、コンテナは、Bean が @Stateful . また @Stateful ビーンも上記のスコープアノテーションのいずれかを使用することができ、 スコープ内の他のすべてのビーンと共存させることができます。 EJBでは @Stateful は，本質的に，"any scoped"ビーンである。 その @Stateless は基本的にインスタンスプールで、1回の呼び出しの間、プールからインスタンスを取得します。 1回の呼び出しの間、プールからインスタンスを取得します。 @Singleton は基本的に @ApplicationScoped

つまり、基本的なレベルでは、"EJB" ビーンでできることは、"CDI" ビーンでできるはずなのです。 この2つを区別するのは非常に困難です。 すべての配管は、インスタンスがどのように解決されるかを除いて、同じです。

このプロキシ処理を行う際にコンテナが提供するサービスという点では、現在は同じではありませんが、私が言ったように、私たちはJava EE仕様のレベルでそれに取り組んでいます。

パフォーマンスに関するメモ

軽い」「重い」というイメージは捨ててください。 それはすべてマーケティングです。 これらの製品は、ほとんどの場合、同じ内部設計になっています。 CDIのインスタンス解決は、より動的で文脈的であるため、おそらく少し複雑です。 EJBインスタンス解決は、比較するとかなり静的で、ダムで、シンプルです。

TomEEの実装の観点から言うと、EJBを呼び出すのとCDI Beanを呼び出すのとでは、パフォーマンスの差はほぼゼロです。 jQueryを使用します。チェックボックスがチェックされていないかどうかをテストする