EJBとは何ですか？

EJB豆が何であるかを学ぶことを試みてきました、それは彼らのインスタンスが何とか何とかプールで管理されていることをどういう意味ですか？本当にそれらをうまくつかむことができません。

それらが実際に何であるかを説明できますか（実際にはJavaプログラマーにとって）。彼らは何をしますか？彼らの目的は何ですか？なぜ実際に使用するのですか？（なぜ固執しないのPOJOですか？）おそらくサンプルアプリケーションですか？

更新された情報、つまりのみを参照してくださいEJB 3.1。EJBに関する日付の情報は誤解を招く可能性があります。

EJB学習初心者の方は注意してください：

EJBは分散オブジェクトに基づいています。これは、ネットワークでリンクされた複数のマシン（仮想または物理）で実行されているソフトウェアを指します。

なぜ実際に使用するのですか？（なぜPOJOに固執しないのですか？）

データベースにアクセスするコンポーネント、または他の接続性/ディレクトリリソースにアクセスするコンポーネント、または複数のクライアントからアクセスされるコンポーネント、またはSOAサービスとして意図されたコンポーネントが必要な場合、EJBは通常「より大きく、より強く、より高速（または少なくともよりスケーラブル）」です。 POJOよりも単純です。これらは、Webまたは企業ネットワークを介して多数のユーザーにサービスを提供する場合に最も価値があり、部門内の小さなアプリにはあまり価値がありません。

1. 疎結合を使用した複数のアプリケーション/クライアント間でのロジックの再利用/共有。
   EJBは独自のjarにパッケージ化され、デプロイされ、さまざまな場所から呼び出されます。これらは共通のコンポーネントです。確かに、POJOは（注意深く！）ライブラリとして設計し、jarとしてパッケージ化できます。しかし、EJBはローカルとリモートの両方のネットワークアクセスをサポートします-ローカルJavaインターフェース、透過RMI、JMS非同期メッセージ、SOAP / REST Webサービスなどを含み、複数の（一貫性のない？）デプロイメントによるカットアンドペーストのjar依存関係からの節約になります。
   SOAサービスの作成に非常に役立ちます。ローカルアクセスに使用すると、POJOになります（無料のコンテナーサービスが追加されます）。別個のEJBレイヤーを設計することにより、カプセル化、疎結合、結合を最大化するための特別な注意が促され、クリーンなインターフェース（Facade）が促進され、呼び出し元が複雑な処理やデータモデルから保護されます。

2. スケーラビリティと信頼性さまざまな呼び出しメッセージ/プロセス/スレッドから大量のリクエストを適用すると、それらは最初にプール内の使用可能なEJBインスタンス全体に分散され、次にキューに入れられます。つまり、1秒あたりの受信リクエスト数がサーバーが処理できる数よりも多い場合は、正常に機能が低下します。常に一部のリクエストが効率的に処理され、超過したリクエストは待機状態になります。サーバーの「メルトダウン」に到達しません-すべての要求が同時にひどい応答時間を経験し、さらにサーバーはハードウェアとOSが処理できる以上のリソースにアクセスしようとするため、クラッシュします。EJBは、クラスター化できる別の層にデプロイできます。これにより、あるサーバーから別のサーバーへのフェイルオーバーによって信頼性が得られ、ハードウェアを追加して線形に拡張できます。

3. 同時実行管理。コンテナーは、EJBインスタンスが複数のクライアントによって安全に（連続して）自動的にアクセスされるようにします。コンテナーは、EJBプール、スレッドプール、呼び出しキューを管理し、メソッドレベルの書き込みロック（デフォルト）または読み取りロック（@Lock（READ）を介して）を自動的に実行します。これにより、書き込みと書き込みの同時衝突によるデータの破損を防ぎ、読み取りと書き込みの衝突を防ぐことで、データを一貫して読み取ることができます。
   これは、主に@SingletonセッションBeanに役立ちます。Beanは、クライアントの呼び出し元間で共通の状態を操作および共有します。これを簡単に上書きして、コードの同時実行とデータアクセスの高度なシナリオを手動で構成またはプログラムで制御できます。

4. 自動トランザクション処理。
   何もせず、すべてのEJBメソッドがJTAトランザクションで実行されます。JPAまたはJDBCを使用してデータベースにアクセスすると、自動的にトランザクションに参加します。JMSおよびJCAの呼び出しについても同じです。メソッドの前に@TransactionAttribute（someTransactionMode）を指定して、その特定のメソッドがJTAトランザクションに参加するかどうか、またはどのように参加するかを指定し、デフォルトモード「オーバーライド」をオーバーライドします。

5. インジェクションによる非常にシンプルなリソース/依存関係アクセス。
   コンテナはリソースを検索し、EJBのインスタンスフィールドとしてリソース参照を設定します。たとえば、JNDIに格納されたJDBC接続、JMS接続/トピック/キュー、他のEJB、JTAトランザクション、JPAエンティティマネージャーの永続コンテキスト、JPAエンティティマネージャーファクトリの永続ユニット、 JCAアダプターのリソース。たとえば、別のEJBとJTAトランザクションとJPAエンティティーマネージャーとJMS接続ファクトリとキューへの参照を設定するには、次のようにします。

   @Stateless
   public class MyAccountsBean {
   
       @EJB SomeOtherBeanClass someOtherBean;
       @Resource UserTransaction jtaTx;
       @PersistenceContext(unitName="AccountsPU") EntityManager em;
       @Resource QueueConnectionFactory accountsJMSfactory;
       @Resource Queue accountPaymentDestinationQueue;
   
       public List<Account> processAccounts(DepartmentId id) {
           // Use all of above instance variables with no additional setup.
           // They automatically partake in a (server coordinated) JTA transaction
       }
   }
   

   サーブレットは、インスタンス変数を宣言するだけで、このBeanをローカルで呼び出すことができます。

   @EJB MyAccountsBean accountsBean;    
   

   そして、必要に応じてそのメソッドを呼び出すだけです。

6. JPAとのスマートな相互作用。デフォルトでは、上記のように注入されたEntityManagerは、トランザクションスコープの永続コンテキストを使用します。これは、ステートレスセッションBeanに最適です。（ステートレス）EJBメソッドが呼び出されると、新しい永続コンテキストが新しいトランザクション内に作成され、DBに取得/書き込まれるすべてのエンティティオブジェクトインスタンスは、そのメソッド呼び出し内でのみ表示され、他のメソッドから分離されます。ただし、メソッドによって他のステートレスEJBが呼び出されると、コンテナはそれらに伝播して同じPCを共有するため、同じトランザクションで同じエンティティがPCを通じて一貫した方法で自動的に共有されます。
   @StatefulセッションBeanが宣言されている場合、JPAと同等のスマートアフィニティは、entityManagerを拡張スコープ1として宣言することによって実現されます：@PersistentContent（unitName = "AccountsPU、type = EXTENDED）。複数のBean呼び出しとトランザクション間で、以前に取得/書き込みされたDBエンティティのメモリ内コピーをキャッシュするため、再取得する必要がありません。

7. ライフサイクル管理。EJBのライフサイクルはコンテナ管理です。必要に応じて、EJBインスタンスを作成し、ステートフルセッションBeanの状態をクリアして初期化し、パッシベーションとアクティブ化を行い、ライフサイクルコールバックメソッドを呼び出します。これにより、EJBコードはライフサイクル操作に参加してリソースを取得および解放したり、その他の初期化およびシャットダウン動作を実行したりできます。また、すべての例外をキャプチャしてログに記録し、必要に応じてトランザクションをロールバックし、必要に応じて新しいEJB例外または@ApplicationExceptionをスローします。

8. セキュリティ管理。EJBへのロールベースのアクセス制御は、シンプルなアノテーションまたはXML設定を介して構成できます。サーバーは、認証されたユーザーの詳細と各呼び出しをセキュリティコンテキスト（呼び出し元のプリンシパルとロール）として自動的に渡します。これにより、すべてのRBACルールが自動的に適用され、メソッドが間違ったロールによって不正に呼び出されることがなくなります。これにより、EJBはユーザー/ロールの詳細に簡単にアクセスして、追加のプログラムによるチェックを行うことができます。これにより、標準的な方法で追加のセキュリティ処理（またはIAMツール）をコンテナーにプラグインできます。

9. 標準化と移植性。EJB実装はJava EE標準とコーディング規約に準拠しており、品質と理解と保守の容易さを促進します。また、コードがすべて同じ標準機能と動作をサポートすることを保証し、開発者がプロ​​プライエタリな
   移植性のないベンダー機能を誤って採用しないようにすることで、新しいベンダーアプリサーバーへのコードの移植性を促進します。

10. 本当のキッカー：シンプルさ。上記のすべては、Java EE 6内のEJBのデフォルト設定を使用するか、いくつかの注釈を追加することで、非常に合理化されたコードで実行できます。企業コーディング/あなた自身のPOJOの産業強度の特徴は次のようになり道より、volumous複雑でエラーが発生しやすいです。EJBを使ってコーディングを始めると、EJBの開発はかなり簡単になり、一連のすばらしい「フリーライド」のメリットが得られます。

10年前の元のEJB仕様では、EJBは生産性の大きな問題でした。それらは肥大化し、多くのコードと構成アーティファクトを必要とし、上記の利点の約2/3を提供しました。ほとんどのWebプロジェクトは実際にはそれらを使用しませんでした。しかし、これは10年間の微調整、オーバーホール、機能強化、開発の合理化によって大幅に変化しました。Java EE 6では、最高レベルの産業用強度と使いやすさを提供します。

嫌いなことは何ですか？:-) :-)

EJBは、ビジネスロジックを含むJavaコンポーネントであり、コンテナーにデプロイします。これは、アノテーションにより、通常は宣言的な方法でコンテナーによって提供される技術サービスからメリットを得ます。

• トランザクション管理：EJBのメソッドが呼び出される前にトランザクションを自動的に開始し、このメソッドが戻るとトランザクションをコミットまたはロールバックできます。このトランザクションコンテキストは、他のEJBへの呼び出しに伝播されます。
• セキュリティ管理：呼び出し元がメソッドを実行するために必要な役割を持っていることを確認できます。
• 依存性注入：他のEJB、またはJPAエンティティマネージャー、JDBCデータソースなどのリソースをEJBに注入できます。
• 並行性：コンテナーは、一度に1つのスレッドのみがEJBインスタンスのメソッドを呼び出すようにします。
• 配布：一部のEJBは、別のJVMからリモートで呼び出すことができます。
• フェイルオーバーとロードバランシング：EJBのリモートクライアントは、必要に応じて自動的に呼び出しを別のサーバーにリダイレクトできます。
• リソース管理：サーバーのメモリ消費を制限するために、ステートフルBeanを自動的にディスクにパッシベーションすることができます。
• ...おそらくいくつかのポイントを忘れました。

Oracleのドキュメントからこれが私のような誰かが簡単な方法でEJBのトピックを理解するのに役立つことを願っています

エンタープライズBeanとは Javaプログラミング言語で記述されたエンタープライズBeanは、アプリケーションのビジネスロジックをカプセル化するサーバー側コンポーネントです。ビジネスロジックは、アプリケーションの目的を満たすコードです。たとえば、在庫管理アプリケーションでは、エンタープライズBeanがcheckInventoryLevelおよびorderProductと呼ばれるメソッドでビジネスロジックを実装する場合があります。これらのメソッドを呼び出すことにより、クライアントはアプリケーションが提供する在庫サービスにアクセスできます。

エンタープライズBeanの利点いくつかの理由により、エンタープライズBeanは大規模な分散アプリケーションの開発を簡素化します。まず、EJBコンテナはエンタープライズBeanにシステムレベルのサービスを提供するため、Bean開発者はビジネスの問題の解決に集中できます。Bean開発者ではなくEJBコンテナは、トランザクション管理やセキュリティ認証などのシステムレベルのサービスを担当します。

第2に、クライアントではなくBeanにアプリケーションのビジネスロジックが含まれているため、クライアント開発者はクライアントのプレゼンテーションに集中できます。クライアント開発者は、ビジネスルールを実装したり、データベースにアクセスしたりするルーチンをコーディングする必要はありません。その結果、クライアントはより薄くなり、小さなデバイスで実行されるクライアントにとって特に重要な利点となります。

第3に、エンタープライズBeanはポータブルコンポーネントであるため、アプリケーションアセンブラは既存のBeanから新しいアプリケーションを構築できます。これらのアプリケーションは、標準APIを使用している限り、任意の準拠Java EEサーバーで実行できます。

エンタープライズBeanを使用する場合アプリケーションに以下の要件のいずれかがある場合は、エンタープライズBeanの使用を検討する必要があります。

アプリケーションはスケーラブルでなければなりません。増加するユーザーに対応するには、アプリケーションのコンポーネントを複数のマシンに分散する必要がある場合があります。アプリケーションのエンタープライズBeanをさまざまなマシンで実行できるだけでなく、それらの場所もクライアントに対して透過的になります。

トランザクションはデータの整合性を確保する必要があります。エンタープライズBeanはトランザクション、つまり共有オブジェクトの同時アクセスを管理するメカニズムをサポートしています。

アプリケーションにはさまざまなクライアントがあります。わずか数行のコードで、リモートクライアントはエンタープライズBeanを簡単に見つけることができます。これらのクライアントは、薄く、多様で、多数の場合があります。

私が最も興味を持つ質問は、それらをどこでどのように使用できるかです。これを理解するには、最初にどのタイプのEJBが存在するかを確認する必要があります。2つの大きなカテゴリがあります。

1. セッションBean
2. メッセージ駆動型Bean

セッションBeanについて考えてみましょう。彼らは3種類あります：

1. ステートフル -これらのコンポーネントは状態を維持し、複数の要求にわたってクライアントに固有です。セッションとして見てください。これらをすぐに使用できるのは、ショッピングカートまたは他のタイプのセッション（ログインセッションなど）です。
2. ステートレス -これらは、要求間で情報を保持しない自己完結型のコンポーネントですが、ユーザーに固有です。頭に浮かぶ即時の使用- サービス層のサービスクラス。想像してみてくださいOrderService。これらのもう1つの大きな用途は、Webサービスを公開することです。繰り返しますが、これはサービス層にあるか、完全に分離しています。
3. シングルトン -これらは、アプリケーションごとに存在し、1回作成され、再利用/アクセスが複数回できるBeanです。すぐにConfigurationコンポーネントが頭に浮かびます。アプリケーションレベルの構成を保存し、どこからでも必要なときにアクセスできます。

これで、残りの機能または機能は、次のような状況でレイヤー全体で使用できます。

• セキュリティ -呼び出されたメソッドの注釈を使用して、アクセス許可を確認できます。これは、必要に応じて、サービス層とコントローラーで発生する可能性があります。
• トランザクション管理 -これは、サービス層または永続層の明らかな候補です
• 依存性注入 -再びどこでも使用されます

現代の大きな用途の1つは、いわゆるマイクロサービスとサービス指向アーキテクチャーです。一部のビジネスロジックコンポーネントをEJBとしてパッケージ化し、それらを組織全体に配布して、複数のクライアントで使用できます（ここでのクライアントとは、他のバックエンドアプリケーションを意味します）。

等々。ここでの大きな欠点は、EJBコンテナーに大きく依存するようになり、2つのリファレンス実装を切り替えることはできても、Tomcatなどの軽量なものに切り替えることができなくなることです。しかし、なぜすべてのメリットを犠牲にしたいのでしょうか。