[解決済み] EJBとは何ですか、何をするものですか？

質問

を知りたいのですが？ EJB ビーンとは何か、そのインスタンスがプールで管理されるとはどういうことか、などなど。本当にうまく理解できないんだ。

Javaプログラマーにとって、それらが実際どのようなものなのか説明してもらえますか？彼らは何をするのでしょうか？その目的は何ですか？ なぜそれを使うのですか？(なぜ POJO ?) アプリケーションの例を挙げてみましょう。

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

EJB学習初心者の方へご注意ください。

EJBは 分散型オブジェクト でリンクされた複数のマシン（仮想または物理）上で動作するソフトウェアのことを指します。 ネットワーク .

解決方法は？

なぜそれを使うのか？(なぜPOJOにこだわらないのか？)

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

1. Loose Couplingにより、複数のアプリケーション/クライアントでロジックを再利用/共有する。
   
   EJBは独自のジャーにパッケージ化され、デプロイされ、多くの場所から呼び出すことができます。 これらは共通のコンポーネントです。 確かに、POJOは（慎重に！）ライブラリとして設計され jarとしてパッケージ化されています。 しかし、EJBはローカルとリモートの両方のネットワークアクセスをサポートしています。 ローカルJavaインタフェース、透過的RMI、JMS非同期メッセージ、SOAP/REST Webサービス経由。 複数の（一貫性のない）デプロイメントで、jarの依存関係をカット＆ペーストすることから解放されます。
   
   SOAサービスを作成する際に非常に便利です。ローカルアクセスに使用する場合、それらは POJO（無料のコンテナサービスが付加されている）。EJBレイヤーを分離して設計する行為は カプセル化、疎結合、凝集を最大化するための特別な配慮を促進し クリーンなインターフェース（Facade）を推進し、複雑な処理とデータから呼び出し側を保護します。 モデルです。

2. スケーラビリティと信頼性 様々な呼び出しメッセージ/プロセスから膨大な数のリクエストを適用した場合 /プール内の利用可能なEJBインスタンスに分散されます。 を作成し、その後キューに入れる。 これは、1秒間に受信するリクエストの数が サーバーが処理できる量より多くても、優雅に劣化していきます。 を効率的に処理し、余分なリクエストは待機させる。 私たちは すべてのリクエストがひどい応答時間を経験するような、サーバーのメルトダウン（quot;meltdown" ）には至りません。 さらに、サーバーはハードウェアやOSの能力を超えるリソースにアクセスしようとします。 を処理できず、クラッシュしてしまう。 EJBを別の層にデプロイすることができます。 クラスター化することで、1つのサーバーから別のサーバーへのフェイルオーバーによる信頼性が得られ、さらに ハードウェアを追加して、リニアに拡張することができます。

3. 並行性の管理。 コンテナは、EJBインスタンスが自動的に安全に（シリアルに）アクセスされることを保証する。 複数のクライアントから コンテナは、EJBプール、スレッドプール、および 呼び出しキュー、メソッドレベルの書き込みロック(デフォルト)または read locking (@Lock(READ)による)。 これにより、以下のようなデータ破損からデータを保護します。 また、書き込みと書き込みの衝突を防ぐことで、データの安定した読み取りを支援します。 読み書きの衝突が発生します。
   
   これは主に@SingletonセッションBeanに有効で、Beanが操作している場合です。 は、クライアントの呼び出し元で共通の状態を共有します。 これは、手動で簡単にオーバーライドすることができます。 同時コード実行のための高度なシナリオを設定したり、プログラムによって制御することができます。 とデータアクセスを行うことができます。

4. トランザクション処理の自動化。
   
   何もしなければ、すべてのEJBメソッドが実行されます。 をJTAトランザクションで実行します。 JPAやJDBCを使ってデータベースにアクセスすると、それは自動的に トランザクションに参加させる。 JMSやJCAの呼び出しも同様です。 指定方法 メソッドの前に @TransactionAttribute(someTransactionMode) を付けることで、そのメソッドがどのように動作するかを指定することができます。 特定のメソッドがJTAトランザクションに参加し、デフォルトのモードである "Required"をオーバーライドします。

5. インジェクションによる非常にシンプルなリソース/依存性アクセス。
   
   コンテナは、リソースを検索し、リソース参照をインスタンスフィールドとして EJBは、JNDIに保存されたJDBC接続、JMS接続/トピック/キュー、他の EJB、JTAトランザクション、JPAエンティティ・マネージャ永続化コンテキスト、JPAエンティティ・マネージャ ファクトリー永続化ユニット、および JCA アダプタリソース。 例：他のEJB & JTA Transaction & JPA entity Manager & への参照を設定する場合。 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
       }
   }
   
   

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

   @EJB MyAccountsBean accountsBean;    
   
   

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

6. JPAとのスマートなインタラクション。 デフォルトでは、上記のように注入されたEntityManagerは、トランザクション・スコープを持つ永続性を使用します。 コンテキストを使用します。 これはステートレスセッションビーンに最適です。 ステートレス）EJB メソッド が呼び出されると、新しいトランザクション内で新しい永続性コンテキストが作成され、すべての DBに取得/書き込まれたエンティティオブジェクトインスタンスは、そのDB内でしか見ることができません。 メソッド呼び出しから分離されます。 しかし、もし他のステートレスEJBが コンテナから呼び出されたメソッドには、同じPCが伝搬され共有されます。 エンティティは、同じPCを通じて自動的に一貫した方法で共有されます。 トランザクションを実行します。
   
   ステートフルセッションBeanを宣言した場合、JPAと同等のスマートな親和性を得るには、次のようにします。 entityManagerを拡張スコープのものにすることを宣言します。 PersistentContent(unitName="AccountsPU, type=EXTENDED)と宣言します。 これは、以下の期間にわたって存在します。 ビーンセッションは、複数のビーン呼び出しとトランザクションにまたがって、インメモリコピーをキャッシュします。 以前取得/書き込まれたDBエンティティを再取得する必要がないようにします。

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

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

9. 標準化・移植性。 EJBの実装は、Java EE標準とコーディング規約に準拠しており、品質と移植性を高めています。 と理解しやすく、メンテナンスも容易です。 また、新しいコードへのポータビリティも向上します。 ベンダーのアプリサーバーは、すべて同じ標準的な機能をサポートしています。 を誤って採用することを防ぐことができます。
   
   ポータブルでないベンダーの機能

10. 真のキッカーは、シンプルさです。 上記はすべて EJB のデフォルト設定を使用することで、非常に合理化されたコードになります。 の中で、Java EE 6の中で、またはいくつかのアノテーションを追加してください。 コーディング 独自のPOJOでエンタープライズ/インダストリアル強度の機能を提供します。 である 道 より大量で、複雑で、間違えやすい。 しかし、一旦 EJBを使ったコーディングはとても簡単で、さまざまな利点があります。

10年前のオリジナルのEJB仕様では、EJBは生産性を大きく低下させるものでした。 EJBは肥大化し、多くのコードと設定資料を必要とし、上記の利点の2/3程度を提供するものでした。 ほとんどのWebプロジェクトでは、実際にEJBを使用することはありませんでした。 しかし、10年にわたる調整、オーバーホール、機能強化、開発の合理化によって、この状況は大きく変わりました。 Java EE 6では、最大レベルの工業的強度と使いやすさを提供します。

何が気に入らないのでしょうか？） :-)