EJBBeanとは何か、インスタンスがプールで管理されているとはどういう意味かを学ぼうとしています。本当にそれらをうまく把握することはできません。
それらが実際に何であるかを説明してもらえますか（実際にはJavaプログラマーの場合）。彼らは何をしますか？彼らの目的はどれですか？なぜ本当にそれらを使用するのですか？（なぜただ固執しないのPOJOですか？）おそらくサンプルアプリケーション？
更新された情報、つまりを参照してくださいEJB 3.1。EJBに関する日付情報は、誤解を招く可能性があります。
EJB学習の初心者の場合は、次の点に注意してください。
EJBは分散オブジェクトに基づいています。これは、ネットワークによってリンクされた複数のマシン（仮想または物理）で実行されているソフトウェアを指します。
なぜ本当にそれらを使用するのですか？（POJOに固執しないのはなぜですか？）
データベースにアクセスする、他の接続/ディレクトリリソースにアクセスする、複数のクライアントからアクセスする、またはSOAサービスとして使用するコンポーネントが必要な場合、今日のEJBは通常、「より大きく、より強力で、より高速（または少なくともよりスケーラブル）」です。 POJOよりもシンプルです。これらは、Webまたは企業ネットワークを介して多数のユーザーにサービスを提供する場合に最も価値があり、部門内の小さなアプリにはあまり価値がありません。
ルーズカップリングを使用して、複数のアプリケーション/クライアント間でロジックを再利用/共有します。
EJBは、独自のjarにパッケージ化され、デプロイされ、多くの場所から呼び出されます。それらは一般的なコンポーネントです。確かに、POJOは（慎重に！）ライブラリとして設計し、jarとしてパッケージ化することができます。ただし、EJBはローカルとリモートの両方のネットワークアクセスをサポートします。これには、ローカルJavaインターフェイス、透過RMI、JMS非同期メッセージ、SOAP / REST Webサービスなどが含まれ、複数の（一貫性のない？）デプロイメントでのカットアンドペーストjar依存関係からの節約になります。
これらは、SOAサービスの作成に非常に役立ちます。ローカルアクセスに使用される場合、それらはPOJOです（無料のコンテナーサービスが追加されます）。個別のEJBレイヤーを設計するという行為は、カプセル化、緩い結合、および凝集を最大化するための特別な注意を促進し、クリーンなインターフェース（Facade）を促進し、複雑な処理およびデータモデルから呼び出し元を保護します。
スケーラビリティと信頼性さまざまな呼び出しメッセージ/プロセス/スレッドからの大量の要求を適用する場合、それらは最初にプール内の使用可能なEJBインスタンスに分散され、次にキューに入れられます。これは、1秒あたりの着信リクエストの数がサーバーが処理できる数よりも多い場合、正常に機能が低下することを意味します。常に効率的に処理されているリクエストがいくつかあり、超過したリクエストは待機します。サーバーの「メルトダウン」には到達しません。すべてのリクエストで同時にひどい応答時間が発生し、さらにサーバーはハードウェアとOSが処理できるよりも多くのリソースにアクセスしようとするため、クラッシュします。EJBは、クラスター化できる別の層にデプロイできます。これにより、あるサーバーから別のサーバーへのフェイルオーバーによる信頼性が得られ、さらにハードウェアを追加して線形に拡張できます。
同時実行管理。コンテナは、EJBインスタンスが複数のクライアントによって安全に（シリアルに）自動的にアクセスされることを保証します。コンテナは、EJBプール、スレッドプール、呼び出しキューを管理し、メソッドレベルの書き込みロック（デフォルト）または読み取りロック（@Lock（READ）を介して）を自動的に実行します。これにより、書き込みと書き込みの同時衝突によるデータの破損が防止され、読み取りと書き込みの衝突が防止されるため、データを一貫して読み取ることができます。
これは主に、@ SingletonセッションBeanで役立ちます。この場合、Beanは、クライアントの呼び出し元間で共通の状態を操作および共有します。これを簡単にオーバーライドして、コードの同時実行とデータアクセスの高度なシナリオを手動で構成またはプログラムで制御できます。
自動化されたトランザクション処理。
何もしないでください。すべてのEJBメソッドはJTAトランザクションで実行されます。JPAまたはJDBCを使用してデータベースにアクセスすると、データベースは自動的にトランザクションに参加します。JMSとJCAの呼び出しについても同じです。メソッドの前に@TransactionAttribute（someTransactionMode）を指定して、その特定のメソッドがJTAトランザクションに参加するかどうか/どのように参加するかを指定し、デフォルトモード「必須」をオーバーライドします。
インジェクションによる非常にシンプルなリソース/依存関係へのアクセス。
コンテナは、リソースをルックアップし、リソース参照を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;
そして、必要に応じてそのメソッドを呼び出すだけです。
JPAとのスマートな相互作用。デフォルトでは、上記のように挿入されたEntityManagerは、トランザクションスコープの永続コンテキストを使用します。これは、ステートレスセッションBeanに最適です。（ステートレス）EJBメソッドが呼び出されると、新しい永続コンテキストが新しいトランザクション内に作成され、DBに取得/書き込まれるすべてのエンティティオブジェクトインスタンスは、そのメソッド呼び出し内でのみ表示され、他のメソッドから分離されます。ただし、他のステートレスEJBがメソッドによって呼び出された場合、コンテナは同じPCを伝播して共有するため、同じエンティティが同じトランザクションでPCを介して一貫した方法で自動的に共有されます。
@StatefulセッションBeanが宣言されている場合、entityManagerを拡張スコープのものとして宣言することでJPAと同等のスマートアフィニティが実現されます：@PersistentContent（unitName = "AccountsPU、type = EXTENDED）。これはBeanセッションの存続期間中存在します。複数のBean呼び出しおよびトランザクションにわたって、以前に取得/書き込みされたDBエンティティのメモリ内コピーをキャッシュするため、再取得する必要はありません。
ライフサイクル管理。EJBのライフサイクルはコンテナ管理です。必要に応じて、EJBインスタンスを作成し、ステートフルセッションBeanの状態をクリアして初期化し、ライフサイクルコールバックメソッドを非アクティブ化してアクティブ化し、ライフサイクルコールバックメソッドを呼び出します。これにより、EJBコードはライフサイクル操作に参加してリソースを取得および解放したり、その他の初期化およびシャットダウン動作を実行したりできます。また、すべての例外をキャプチャしてログに記録し、必要に応じてトランザクションをロールバックし、必要に応じて新しいEJB例外または@ApplicationExceptionsをスローします。
セキュリティ管理。EJBへのロールベースのアクセス制御は、単純な注釈またはXML設定を介して構成できます。サーバーは、認証されたユーザーの詳細を各呼び出しとともにセキュリティコンテキスト（呼び出し元のプリンシパルとロール）として自動的に渡します。これにより、すべてのRBACルールが自動的に適用され、間違ったロールによってメソッドが不正に呼び出されることがなくなります。これにより、EJBは、追加のプログラムチェックのためにユーザー/ロールの詳細に簡単にアクセスできます。これにより、標準的な方法で追加のセキュリティ処理（またはIAMツール）をコンテナにプラグインできます。
標準化と移植性。EJBの実装は、Java EE標準とコーディング規則に準拠しており、品質と理解と保守の容易さを促進します。また、すべてが同じ標準機能と動作をサポートすることを保証し、開発者が独自の
非移植性ベンダー機能を誤って採用することを思いとどまらせることにより、新しいベンダーアプリサーバーへのコードの移植性を促進します。
本当のキッカー：シンプルさ。上記のすべては、非常に合理化されたコードで実行できます。JavaEE 6内のEJBのデフォルト設定を使用するか、いくつかの注釈を追加します。独自のPOJOでエンタープライズ/インダストリアルストレングス機能をコーディングすると、はるかにボリュームがあり、複雑で、エラーが発生しやすくなります。EJBを使用してコーディングを開始すると、EJBの開発はかなり簡単になり、「フリーライド」の優れたメリットが得られます。
10年前の元のEJB仕様では、EJBは生産性の大きな問題でした。それらは肥大化し、多くのコードと構成アーティファクトを必要とし、上記の利点の約2/3を提供しました。ほとんどのWebプロジェクトは実際にはそれらを使用していませんでした。しかし、これは10年間の調整、オーバーホール、機能強化、開発の合理化によって大きく変化しました。Java EE 6では、最高レベルの産業用強度と使いやすさを提供します。
嫌いなものは何ですか？:-) :-)
EJBは、コンテナにデプロイするビジネスロジックを含むJavaコンポーネントであり、アノテーションのおかげで、通常は宣言的な方法でコンテナによって提供される技術サービスの恩恵を受けます。
Oracle docからのこれが、私のような誰かがEJBのトピックを簡単な方法で理解するのに役立つことを願っています。
エンタープライズBeanとは何ですか？Javaプログラミング言語で記述されたエンタープライズBeanは、アプリケーションのビジネスロジックをカプセル化するサーバー側のコンポーネントです。ビジネスロジックは、アプリケーションの目的を満たすコードです。たとえば、在庫管理アプリケーションでは、エンタープライズBeanはcheckInventoryLevelおよびorderProductと呼ばれるメソッドでビジネスロジックを実装する場合があります。これらのメソッドを呼び出すことにより、クライアントはアプリケーションによって提供されるインベントリサービスにアクセスできます。
エンタープライズBeanの利点いくつかの理由から、エンタープライズBeanは大規模な分散アプリケーションの開発を簡素化します。まず、EJBコンテナはエンタープライズBeanにシステムレベルのサービスを提供するため、Bean開発者はビジネス上の問題の解決に集中できます。Bean開発者ではなく、EJBコンテナが、トランザクション管理やセキュリティ認証などのシステムレベルのサービスを担当します。
次に、クライアントではなくBeanにアプリケーションのビジネスロジックが含まれているため、クライアント開発者はクライアントのプレゼンテーションに集中できます。クライアント開発者は、ビジネスルールを実装したりデータベースにアクセスしたりするルーチンをコーディングする必要はありません。その結果、クライアントはより薄くなります。これは、小さなデバイスで実行されるクライアントにとって特に重要な利点です。
第3に、エンタープライズBeanは移植可能なコンポーネントであるため、アプリケーションアセンブラーは既存のBeanから新しいアプリケーションを構築できます。これらのアプリケーションは、標準APIを使用していれば、準拠しているJavaEEサーバーで実行できます。
エンタープライズBeanを使用する場合アプリケーションに次の要件のいずれかがある場合は、エンタープライズBeanの使用を検討する必要があります。
アプリケーションはスケーラブルである必要があります。増え続けるユーザーに対応するには、アプリケーションのコンポーネントを複数のマシンに分散させる必要がある場合があります。アプリケーションのエンタープライズBeanをさまざまなマシンで実行できるだけでなく、それらの場所もクライアントに対して透過的になります。
トランザクションは、データの整合性を確保する必要があります。エンタープライズBeanは、共有オブジェクトの同時アクセスを管理するメカニズムであるトランザクションをサポートします。
アプリケーションにはさまざまなクライアントがあります。わずか数行のコードで、リモートクライアントはエンタープライズBeanを簡単に見つけることができます。これらのクライアントは、薄く、さまざまで、多数ある可能性があります。
私が最も興味を持っているのは、それらをどこでどのように使用できるかということです。これを理解するには、最初にどのタイプのEJBが存在するかを確認する必要があります。2つの大きなカテゴリがあります：
セッションBeanについて考えてみましょう。それらは3種類あります：
OrderService。これらのもう1つの大きな用途は、Webサービスを公開することです。繰り返しますが、これはサービスレイヤーにあるか、完全に分離されています。Configurationに思い浮かびます。アプリケーションレベルの構成を保存し、必要なときにどこからでもアクセスできます。これで、残りの機能または機能を次のような状況でレイヤー間で使用できます。
現代における大きな用途の1つは、いわゆるマイクロサービスとサービス指向アーキテクチャです。一部のビジネスロジックコンポーネントをEJBとしてパッケージ化し、組織全体に分散して、複数のクライアントで使用できます（ここでのクライアントとは、他のバックエンドアプリケーションを意味します）。
等々。ここでの大きな欠点は、EJBコンテナに大きく依存するようになり、2つのリファレンス実装を切り替えることはできても、より軽いもの（たとえば、Tomcat）に切り替えることができないことです。しかし、なぜあなたはすべての利益を犠牲にしたいのですか？
EJBは、ビジネスロジックが階層型アプリケーションに組み込まれる場所です。そのモデルに続いて、層（層とは異なる）はユーザーおよび他のインターフェースから独立してアクセス可能であるため、複数のプロトコルを使用する複数のコンポーネントによって展開およびアクセスできます。
正規化されたシステムモデルでは、EJBは「アクション」と「ワークフロー」であり、サーブレットは「インターフェイス」、JCAは「コネクタ」、タイマーとJMSは「イベント」です。