ジャカルタエンタープライズBean

Jakarta Enterprise Beans ( EJB、旧称Enterprise JavaBeans )は、エンタープライズソフトウェアのモジュール構築用のJava APIの1つです。EJBは、アプリケーションのビジネスロジックをカプセル化するサーバー側ソフトウェアコンポーネントです。EJB Webコンテナは、コンピュータセキュリティ、Javaサーブレットライフサイクル管理、トランザクション処理、その他のWebサービスなど、Web関連のソフトウェアコンポーネントのランタイム環境を提供します。EJB仕様は、 Java EE仕様のサブセットです。^[1]

EJB仕様は、もともと1997年にIBMによって開発され、その後1999年にサンマイクロシステムズ（EJB 1.0および1.1）によって採用され^[2]、Javaコミュニティプロセスの下でJSR 19（EJB 2.0）、JSR 153（EJB 2.1）、JSR 220（EJB 3.0）、JSR 318（EJB 3.1）、JSR 345（EJB 3.2）として拡張されました。

EJB 仕様は、エンタープライズ アプリケーション (「フロントエンド」ユーザーインターフェイス ソフトウェアとは対照的) に通常含まれるサーバー側 (「バックエンド」とも呼ばれる)「ビジネス」ソフトウェアを実装するための標準的な方法を提供します。このようなソフトウェアは同じ種類の問題に対処しており、これらの問題に対するソリューションはプログラマーによって繰り返し再実装されることがよくあります。Jakarta Enterprise Beans は、永続性、トランザクションの整合性、セキュリティなどの一般的な懸念事項を標準的な方法で処理し、プログラマーがエンタープライズ ソフトウェアの特定の部分に集中できるようにすることを目指しています。

EJB 仕様では、アプリケーション サーバーが次の責任をどのように提供するかが詳細に規定されています。

• トランザクション処理
• Jakarta Persistence (JPA)が提供する永続性サービスとの統合
• 同時実行制御
• Jakarta Messaging (JMS) とJakarta Connectors (JCA)を使用したイベント駆動型プログラミング
• 非同期メソッド呼び出し
• ジョブスケジューリング
• Java Naming and Directory Interface (JNDI)による命名およびディレクトリ サービス
• RMI-IIOPとWeb サービスを使用したプロセス間通信
• セキュリティ( JCEおよびJAAS )
• アプリケーションサーバーへのソフトウェアコンポーネントの展開

さらに、Jakarta Enterprise Beans 仕様では、EJB コンテナと EJB が果たす役割、およびコンテナ内での EJB のデプロイ方法が定義されています。EJB 仕様では、アプリケーション サーバーが永続性を提供する方法 (JPA 仕様に委任されたタスク) は詳細に説明されていませんが、代わりに、ビジネス ロジックをアプリケーション サーバーが提供する永続性サービスと簡単に統合する方法が詳細に説明されていることに注意してください。

企業は、ビジネス ロジックをカプセル化するために EJB を使用するとパフォーマンスが低下することを発見しました。これは、ほとんどのビジネス アプリケーションが実際にはこの分散コンピューティング機能を必要としないにもかかわらず、元の仕様ではCORBA (およびオプションで他のプロトコル) を介したリモートメソッド呼び出しのみが許可されていたためです。EJB 2.0 仕様では、複数のサーバーに分散されていないアプリケーションからパフォーマンスの低下なしで直接呼び出すことができるローカル インターフェイスの概念を追加することで、この問題に対処しました。^[3]

EJB 3.0 仕様 ( JSR 220) は、新しい軽量パラダイムに従って、以前の仕様から脱却しました。EJB 3.0 は、プレーン Java オブジェクトの使用と、異種システムの構成と統合を簡素化するための依存性注入のサポートにおいて、 Springの影響を示しています。EJB 3.0 は、他のバージョンの EJB とともに、 MuleSoft 認定の PlektonLabs EJB コネクタを使用してMuleSoft -v4 と統合できます。Hibernate の作成者である Gavin King は、EJB 3.0 プロセスに参加し、このテクノロジの積極的な支持者です。元々 Hibernateにあった多くの機能は、EJB 3.0 のエンティティ Beanの代替であるJava Persistence APIに組み込まれました。EJB 3.0 仕様は、はるかに簡潔なコーディング スタイルを可能にするために、アノテーション(Java 言語の 5.0 リリースで追加された機能) と構成より規約の使用に大きく依存しています。したがって、実際上、EJB 3.0 ははるかに軽量で、以前の EJB 仕様とほとんど類似点のないほぼ完全に新しい API です。^{[引用が必要]}

以下に、EJB がコード内でどのように見えるかの基本的な例を示します。

@StatelessパブリッククラスCustomerService { 
    
  

  プライベートEntityManager entityManager ;パブリックvoid addCustomer ( Customer customer ) { entityManager . persist ( customer ); } }   
   
       
     
   

上記は、Customer オブジェクトを永続化するためのサービス クラスを定義します ( O/R マッピング経由)。EJB は永続コンテキストの管理を担当し、addCustomer() メソッドはデフォルトでトランザクションおよびスレッド セーフです。示されているように、EJB はビジネス ロジックと永続化のみに焦点を当てており、特定のプレゼンテーションについては何も認識しません。

このような EJB は、次のように、たとえば Web 層のクラスで使用できます。

@Named @RequestScopedパブリッククラスCustomerBacking { @EJBプライベートCustomerService customerService ;	

   
    
     

   public String addCustomer ( Customer customer ) { customerService . addCustomer ( customer ); context . addMessage (...); // 簡潔にするために省略されていますreturn "customer_overview" ; } }    
      
       
       
   

上記は、アノテーションによって EJB が挿入されるJavaServer Faces@EJB (JSF) バッキング Bean を定義します。その addCustomer メソッドは、通常、ボタンなどの UI コンポーネントにバインドされます。EJB とは異なり、バッキング Bean にはビジネス ロジックや永続性コードは含まれませんが、そのような問題は EJB に委任されます。バッキング Bean は、EJB が認識していなかった特定のプレゼンテーションを認識します。

EJB コンテナには、2 つの主要なタイプの Bean が保持されます。

• セッションBean ^[4]は、「ステートフル」、「ステートレス」、または「シングルトン」のいずれかであり、ローカル（同じJVM）またはリモート（異なるJVM）インターフェースを介して、またはインターフェースなしで直接アクセスできます。^[5]この場合、ローカルセマンティクスが適用されます。すべてのセッションBeanは、すべてのビュー（ローカル/リモート/インターフェースなし）に対して非同期実行^{[6]をサポートします。}
• メッセージ駆動型 Bean (MDB、メッセージ Bean とも呼ばれます)。MDB も非同期実行をサポートしますが、メッセージング パラダイムを介して実行されます。

ステートフルセッションBean ^[7]は、状態を持つビジネスオブジェクトです。つまり、セッション全体を通じてどの呼び出しクライアントを扱っているか、およびそのリクエストの履歴を追跡します。そのため、Beanインスタンスへのアクセスは、その存続期間中、厳密に1つのクライアントのみに制限されます。^[8]単一のBeanへの同時アクセスが試行された場合、コンテナはそれらのリクエストをシリアル化しますが、@AccessTimeoutアノテーションを介してコンテナは例外をスローすることができます。^[9]ステートフルセッションBeanの状態は、クライアントが一定時間Beanにアクセスしなかった後にメモリを解放するために、コンテナによって自動的に永続化（パッシブ化）される場合があります。 JPA拡張永続コンテキストは、ステートフルセッションBeanによって明示的にサポートされています。^[10]

例

• Web ストアでのチェックアウトは、ステートフル セッション Bean によって処理される可能性があります。ステートフル セッション Bean は、その状態を使用して、顧客がチェックアウト プロセスのどこにいるかを追跡し、顧客が購入するアイテムのロックを保持する可能性があります (システム アーキテクチャの観点からは、クライアントがそれらのロックを管理することはあまり理想的ではありません)。

ステートレスセッションBean ^[11]は、状態が関連付けられていないビジネスオブジェクトです。ただし、単一のBeanインスタンスへのアクセスは、一度に1つのクライアントのみに制限されており、Beanへの同時アクセスは禁止されています。 ^[8]単一のBeanへの同時アクセスが試行された場合、コンテナは各リクエストを別のインスタンスにルーティングするだけです。^[12]これにより、ステートレスセッションBeanは自動的にスレッドセーフになります。インスタンス変数は、クライアントからBeanへの単一のメソッド呼び出し中に使用できますが、それらのインスタンス変数の内容は、異なるクライアントメソッド呼び出し間で保持される保証はありません。ステートレスセッションBeanのインスタンスは通常、プールされます。最初のクライアントによるメソッド呼び出しが終了した直後に、2番目のクライアントが特定のBeanにアクセスすると、同じインスタンスを取得する可能性があります。呼び出し元のクライアントとの会話を維持するためのオーバーヘッドがないため、ステートフルBeanよりもリソースを消費しません。

例

• 顧客サポートへの電子メールの送信は、1 回限りの操作であり、複数ステップのプロセスの一部ではないため、ステートレス Bean によって処理される可能性があります。
• ウェブサイトのユーザーが「今後の更新について通知を受け取る」ボックスをクリックすると、セッション Bean の非同期メソッドの呼び出しがトリガーされ、そのユーザーが会社のデータベースのリストに追加されることがあります (この呼び出しは、ユーザーが成功または失敗の通知を待つ必要がないため、非同期です)。
• 製品リストや現在のユーザーの履歴など、Web サイトの複数の独立したデータを取得することも、セッション Bean の非同期メソッドで処理できます (これらの呼び出しは、そのように並行して実行できるため非同期であり、パフォーマンスが向上する可能性があります)。この場合、非同期メソッドは Future インスタンスを返します。

シングルトンセッションBean ^{[13] [14]}は、JVM内でグローバルに共有された状態を持つビジネスオブジェクトです。唯一のBeanインスタンスへの同時アクセスは、コンテナ（コンテナ管理による同時実行性、CMC）またはBean自体（Bean管理による同時実行性、BMC）によって制御できます。CMCは、@Lockメソッド呼び出しに読み取りロックまたは書き込みロックのどちらを使用するかを指定するアノテーションを使用して調整できます。さらに、シングルトンセッションBeanは、アノテーションを使用して、EJBコンテナの起動時にインスタンス化するように明示的に要求できます@Startup。

例

• すべてのユーザーに対して同じグローバルな日次価格リストをロードする場合は、シングルトン セッション Bean を使用すると、アプリケーションがデータベースに対して同じクエリを何度も実行する必要がなくなります...

メッセージ駆動型Bean ^[15]は、メソッド呼び出しではなくメッセージによって実行がトリガーされるビジネスオブジェクトです。メッセージ駆動型Beanは、特に、下位レベルのJMS ( Java Message Service )仕様に高レベルの使いやすい抽象化を提供するために使用されます。メッセージ駆動型Beanは、JMSメッセージキューまたはメッセージトピックをサブスクライブする場合があります。これは通常、アノテーションの activationConfig 属性を介して行われます@MessageDriven。これらは、イベント駆動型処理を可能にするためにEJBに追加されました。セッションBeanとは異なり、MDBにはクライアントビュー(ローカル/リモート/インターフェイスなし)がありません。つまり、クライアントはMDBインスタンスを検索できません。MDBは、たとえばJMSキューまたはトピック上の着信メッセージをリッスンし、自動的に処理します。Java EE仕様ではJMSサポートのみが必須ですが、^[16]メッセージ駆動型Beanは他のメッセージングプロトコルをサポートできます。^{[17] [18]}このようなプロトコルは非同期の場合もあれば、同期の場合もあります。セッション Bean は同期または非同期にすることもできるため、セッション Bean とメッセージ駆動型 Bean の主な違いは同期性ではなく、(オブジェクト指向の)メソッド 呼び出しとメッセージングの違いです。

例

• 複数のノードに構成更新を送信するには、JMS メッセージを「メッセージ トピック」に送信し、このトピックをリッスンしているメッセージ駆動型 Bean で処理します (送信者はコンシューマーの数、場所、正確なタイプを知る必要がないため、ここではメッセージ パラダイムが使用されます)。
• ジョブを作業クラスターに送信するには、JMS メッセージを「メッセージ キュー」に送信します。また、メッセージ駆動型 Bean で処理することもできますが、この場合はキューをリッスンします (送信者はどのワーカーがジョブを実行するかを気にする必要がないため、メッセージ パラダイムとキューが使用されますが、ジョブが 1 回だけ実行されることを保証する必要があります)。
• Quartzスケジューラからのタイミングイベントの処理は、メッセージ駆動型Beanによって処理できます。Quartzトリガーが発動すると、MDBが自動的に呼び出されます。Java EEはデフォルトではQuartzを認識しないため、JCAリソースアダプタが必要になり、MDBにはこれへの参照が注釈付けされます。^[19]

EJB は、通常、アプリケーション サーバー内の EJB コンテナーにデプロイされます。仕様では、EJB がコンテナーと対話する方法と、クライアント コードがコンテナー/EJB の組み合わせと対話する方法が規定されていますjavax.ejb。アプリケーションで使用される EJB クラスは、パッケージに含まれています。(パッケージは、 EJB コンテナー実装でのみ使用される サービス プロバイダー インターフェイスjavax.ejb.spiです。)

EJB のクライアントは、Java の new 演算子を介してこれらの Bean を直接インスタンス化するのではなく、EJB コンテナを介して参照を取得する必要があります。この参照は通常、実装 Bean 自体への参照ではなく、クライアントが要求したローカルまたはリモートのビジネス インターフェース、または実際の Bean のサブタイプのいずれかを動的に実装するプロキシへの参照です。プロキシは、それぞれインターフェースまたは Bean に直接キャストできます。クライアントは EJB に「ビュー」を持っていると言われ、ローカル インターフェース、リモート インターフェース、および Bean サブタイプ自体は、それぞれローカル ビュー、リモート ビュー、およびインターフェースなしのビューに対応します。

このプロキシは、トランザクション、セキュリティ、インターセプション、インジェクション、リモート処理などの横断的 ( AOPのような) サービスを Bean に透過的に提供する機会を EJB コンテナに与えるために必要です。たとえば、クライアントがプロキシのメソッドを呼び出すと、最初に EJB コンテナの助けを借りてトランザクションが開始され、次に実際の Bean メソッドが呼び出されます。Bean メソッドが戻ると、プロキシはトランザクションを終了し (つまり、コミットまたはロールバックを実行して)、制御をクライアントに戻します。

EJBコンテナは、クライアントコードがEJBへの十分なアクセス権を持っていることを確認する責任があります。^[20]セキュリティの側面は、アノテーションを介してEJBに宣言的に適用できます。^[21]

EJBコンテナはコンテナ管理のACIDトランザクションとBean管理のトランザクションの両方をサポートする必要があります。^[22]

コンテナ管理トランザクション (CMT) は、セッション Bean の呼び出しに対してデフォルトでアクティブです。つまり、明示的な設定は必要ありません。この動作は、Bean によってアノテーションを介して宣言的に調整することができ、必要に応じて、後でデプロイメント記述子でその設定をオーバーライドできます。調整には、Bean 全体または特定のメソッドのトランザクションをオフにすること、またはトランザクションの伝播とトランザクションの開始または参加に関する代替戦略を要求することが含まれます。このような戦略は主に、Bean が呼び出された時点でトランザクションが進行中の場合、または進行中でない場合の対処方法を扱います。次のバリエーションがサポートされています: ^{[23] [24]}

あるいは、BeanはJTA APIを介してプログラム的にトランザクションを処理することをアノテーションで宣言することもできます。この動作モードは、コンテナではなくBean自体がトランザクションを処理するため、Bean管理トランザクション（BMT）と呼ばれます。^[25]

JMS ( Java Message Service ) は、Bean からクライアントにメッセージを送信し、クライアントがこれらの Bean から非同期メッセージを受信できるようにするために使用されます。MDB は、 JMS キューまたはトピック のいずれかを使用して、クライアントから非同期にメッセージを受信するために使用できます。

インジェクションの代替として、EJB のクライアントは、Java Naming and Directory Interface (JNDI)を使用して、セッション Bean のプロキシ オブジェクト (EJB スタブ) への参照を取得できます。この代替手段は、非管理コードやスタンドアロンのリモート Java SE クライアントなど、インジェクションが利用できない場合や、取得する Bean をプログラムで決定する必要がある場合に使用できます。

EJBセッションBeanのJNDI名は、EJBコンテナによって次の方式で割り当てられる: ^{[26] [27] [28]}

（角括弧内の項目はオプション部分を示します）

単一の Bean は、クライアントの「場所」に応じて、上記のパターンに一致する任意の名前で取得できます。必要な Bean と同じモジュール内のクライアントは、モジュール スコープおよびそれより広いスコープを使用できます。必要な Bean と同じアプリケーション内のクライアントは、アプリ スコープおよびそれより広いスコープを使用できます。

たとえば、CustomerService Bean と同じモジュールで実行されるコード(この記事の前半で示した例のように) は、次のコードを使用して、その (ローカル) 参照を取得できます。

CustomerServiceLocal customerService = ( CustomerServiceLocal )新しいInitialContext (). lookup ( "java:module/CustomerService" );  
      

Javaプログラミング言語で書かれたクライアントとの通信のために、セッションBeanは、でアノテーションされたインターフェースを介してリモートビューを公開することができます@Remote。^{[29]これにより、他のシステムで実行されている可能性のある他の}JVMのクライアントからそれらのBeanを呼び出すことができます（EJBコンテナの観点からは、別のJVMのコードはすべてリモートです）。

ステートレスおよびシングルトンセッションBeanは、 WSDLおよびSOAPまたはプレーンXMLを介してリモート通信するための「Webサービスクライアントビュー」を公開することもできます。 ^{[30] [31] [32]}これは、JAX-RPCおよびJAX-WS仕様に準拠しています。ただし、JAX-RPCのサポートは将来的に削除される予定です。^[33] JAX-WSをサポートするために、セッションBeanには@WebService、および でリモートに公開されるメソッドが注釈付けされます@WebMethod。

EJB仕様ではRESTful Webサービスとしての公開については一切触れられておらず、この形式の通信に対する明示的なサポートもありませんが、JAX-RS仕様ではEJBを明示的にサポートしています。^[34] JAX-RS仕様に従って、ステートレスおよびシングルトンセッションBeanは、アノテーションを介してルートリソースとして宣言でき、EJBビジネスメソッドは、、、およびアノテーションを@Path介してリソースメソッドにマップできます。ただし、これは「Webサービスクライアントビュー」とはみなされません。これはJAX-WSおよびJAX- RPC専用です。 @GET@PUT@POST@DELETE

Web サービスによる通信は、Java プログラミング言語で書かれていないクライアントでは一般的ですが、ファイアウォール経由で EJB サーバーにアクセスできない Java クライアントにも便利です。さらに、Web サービス ベースの通信は、Java クライアントがいわゆる「クライアント ライブラリ」の難解で定義の曖昧な要件を回避するために使用できます。クライアント ライブラリとは、リモート EJB サーバーと通信するために Java クライアントがクラス パス上に持つ必要がある一連の jar ファイルです。これらのクライアント ライブラリは、クライアントが既に持っているライブラリと競合する可能性があります (たとえば、クライアント自体が完全な Java EE サーバーである場合)。このような競合は解決が非常に困難または不可能であると見なされます。^[35]

EJB 2.1 以前では、各 EJB は Java 実装クラスと 2 つの Java インターフェイスを提供する必要がありました。EJB コンテナは、EJB 実装を提供するために Java 実装クラスのインスタンスを作成しました。Java インターフェイスは、EJB のクライアント コードによって使用されました。

EJB 2.1 以前では、EJB 仕様にはデプロイメント記述子が必要でした。これは、選択された特定の EJB プラットフォームに関係なく、EJB を一貫した方法でデプロイできるメカニズムを実装するために必要でした。Bean をデプロイする方法に関する情報 (ホーム インターフェイスまたはリモート インターフェイスの名前、Bean をデータベースに保存するかどうか、および保存する場合はその方法など) をデプロイメント記述子で指定する必要がありました。

デプロイメント記述子は、デプロイされる各 EJB のエントリを持つXMLドキュメントです。この XML ドキュメントは、各 EJB について次の情報を指定します。

• ホームインターフェースの名前
• Bean (ビジネス オブジェクト) の Java クラス
• ホームインターフェースのJavaインターフェース
• ビジネスオブジェクトのJavaインターフェース
• 永続ストア（エンティティ Bean のみ）
• セキュリティロールと権限
• ステートフルまたはステートレス（セッション Bean の場合）

多くのベンダーの古い EJB コンテナでは、EJB 仕様で定義されているよりも多くのデプロイメント情報が必要でした。これらのコンテナでは、追加情報を個別の XML ファイルまたはその他の構成ファイル形式で必要としていました。EJB プラットフォーム ベンダーは、通常、このデプロイメント記述子を読み取る独自のツールを提供し、現在は非推奨となっている Home インターフェイスと Remote インターフェイスを実装するクラスのセットを生成することがありました。

EJB 3.0 (JSR 220) 以降、XML 記述子はEnterprise Bean 実装 (ソース レベル) で設定されたJava アノテーションに置き換えられましたが、アノテーションの代わりに (またはアノテーションに加えて) XML 記述子を使用することは依然として可能です。XML 記述子とアノテーションの両方が Enterprise Bean 内の同じ属性に適用されている場合、XML 定義は対応するソース レベルのアノテーションをオーバーライドしますが、一部の XML 要素は追加することもできます (たとえば、@ActivationConfigPropertyアノテーションによって既に定義されている名前とは異なる名前の XML の activation-config-property は、既存のすべてのプロパティを置き換えるのではなく追加されます)。

EJB 3.1 以降、EJB 仕様では EJB コンテナの 2 つのバリエーション (完全バージョンと限定バージョン) が定義されています。限定バージョンは、 EJB 3.1 Lite ^{[36] [37]}と呼ばれる仕様の適切なサブセットに準拠しており、 Java EE 6 の Web プロファイル(それ自体が完全な Java EE 6 仕様のサブセット) の一部です。

EJB 3.1 Liteでは以下の機能はサポートされません。^[38]

• リモートインターフェース
• RMI-IIOP 相互運用性
• JAX-WS Web サービス エンドポイント
• EJB タイマー サービス ( @Schedule、@Timeout)
• 非同期セッションBeanの呼び出し（@Asynchronous）
• メッセージ駆動型Bean

@AsynchronousEJB 3.2 Lite では、除外される機能が少なくなっています。特に、と@Schedule/ は除外されなくなりました@Timeoutが、@Schedule完全な EJB 3.2 ではサポートされる「persistent」属性はサポートされません。EJB 3.2 Lite の除外される完全なリストは次のとおりです。

• リモートインターフェース
• RMI-IIOP 相互運用性
• JAX-WS Web サービス エンドポイント
• 永続タイマー（「persistent」属性@Schedule）
• メッセージ駆動型Bean

EJB 4.0、最終リリース (2020-05-22)

Jakarta Enterprise Beans 4.0は、Jakarta EE 9の一部であり、主にAPIパッケージ名をトップレベルjavax.ejbパッケージからトップレベルjakarta.ejbパッケージに移動したツールリリースでした。^[39]

その他の変更には、新しいトップレベル パッケージに移行する意味のない非推奨の API の削除や、Java または Jakarta EE 9 の他の場所から削除された機能に依存する機能の削除が含まれます。次の API が削除されました。

• に依存するメソッドはjava.security.IdentityJava 14 から削除されました。
• Jakarta EE 9 プラットフォームから XML RPC が削除されたことを反映するために、Jakarta XML RPCに依存するメソッド。
• 非推奨のEJBContext.getEnvironment()メソッド。
• Java 11 および Jakarta EE 9 プラットフォームから CORBA が削除されたことを反映した「分散相互運用性のサポート」。

その他の小さな変更には、Enterprise Beans 2.x API グループを「オプション」としてマークし、Schedule注釈を繰り返し可能にすることが含まれます。

EJB 3.2.6、最終リリース (2019-08-23)

Jakarta Enterprise Beans 3.2 は、Jakarta EE 8 の一部であり、依然として「EJB」という略語が使用されていますが、この API セットは、 Oracle の「Java」商標を侵害しないように、Eclipse Foundationによって正式に「Jakarta Enterprise Beans」に名前が変更されました。

EJB 3.2、最終リリース (2013-05-28)

JSR 345。Enterprise JavaBeans 3.2 は比較的マイナーなリリースで、主に仕様の明確化と、仕様によって課せられたが時間の経過とともに実質的な目的を果たさなくなったいくつかの制限の解除が含まれていました。既存の完全な EJB 機能のいくつかも EJB 3 Lite に組み込むよう要求され、EJB 3.1 で削除が提案されていた機能は実際に削除されました (オプションになりました)。^{[40] [41]}

以下の機能が追加されました:

• ステートフル セッション Bean のパッシベーションは、@Statefulアノテーションの属性 (passivationCapable = false)によって非アクティブ化できます。
• TimerService は、同じ EJB モジュール内のすべてのアクティブなタイマーを取得できます (以前は、TimerService が呼び出された Bean のタイマーのみを取得できました)
• ライフサイクルメソッド（例）は、既存のアノテーション@PostConstructを使用してステートフルセッションBeanに対してトランザクション化できます。@TransactionAttribute
• 埋め込みコンテナによって実装された自動クローズ可能なインターフェース

EJB 3.1、最終リリース (2009-12-10)

JSR 318。Enterprise JavaBeans 3.1 仕様の目的は、開発者の観点から複雑さを軽減して EJB アーキテクチャをさらに簡素化し、コミュニティのニーズに応じて新しい機能を追加することです。

• インターフェースなしのローカルビュー（インターフェースなしビュー）
• EJB コンポーネントの.warパッケージ
• EJB Lite: EJBのサブセットの定義
• ポータブル EJB グローバルJNDI名
• シングルトン(シングルトン セッション Bean)
• アプリケーションの初期化とシャットダウンイベント
• EJB タイマー サービスの強化
• シンプルな非同期（@Asynchronousセッション Bean 用）

EJB 3.0、最終リリース (2006-05-11)

JSR 220 -主な変更点: このリリースでは、バージョン 2.x で使用されていた複雑な「デプロイメント記述子」ではなく「アノテーション」を使用することで、EJB の記述がはるかに簡単になりました。また、このリリースでは、ホーム インターフェイスとリモート インターフェイス、および ejb-jar.xml ファイルの使用は不要になり、ビジネス インターフェイスと、インターフェイスを実装する Bean に置き換えられました。

EJB 2.1、最終リリース (2003-11-24)

JSR 153 -主な変更点:

• Web サービスサポート (新機能): ステートレス セッション Bean をSOAP / HTTP経由で呼び出すことができます。また、EJB は新しいサービス参照を使用して Web サービスに簡単にアクセスできます。
• EJB タイマー サービス (新機能): 特定の時間に EJB を呼び出すためのイベント ベースのメカニズム。
• メッセージ駆動型 Bean は、JMS以外のソースからのメッセージを受け入れます。
• メッセージの宛先 (EJB 参照、リソース参照などと同じ考え方) が追加されました。
• EJB クエリ言語 (EJB-QL) の追加: ORDER BY、AVG、MIN、MAX、SUM、COUNT、および MOD。
• XMLスキーマはデプロイメント記述子を指定するために使用され、DTDに代わるものである。

EJB 2.0、最終リリース (2001-08-22)

JSR 19 -主な変更点: 全体的な目標:

• Javaで分散オブジェクト指向ビジネス アプリケーションを構築するための標準コンポーネント アーキテクチャ。
• 異なるベンダーのツールを使用して開発されたコンポーネントを組み合わせることで、分散アプリケーションの構築が可能になります。
• (エンタープライズ) アプリケーションの作成を容易にします。アプリケーション開発者は、低レベルのトランザクションと状態管理の詳細、マルチスレッド、接続プール、その他の複雑な低レベル API を理解する必要がありません。
• Javaの「一度書けばどこでも実行できる」という哲学に従います。エンタープライズ Bean は一度開発すれば、再コンパイルやソース コードの変更なしに複数のプラットフォームに展開できます。
• エンタープライズ アプリケーションのライフ サイクルの開発、展開、および実行時の側面に対処します。
• 複数のベンダーのツールが実行時に相互運用できるコンポーネントを開発および展開できるようにする契約を定義します。
• 既存のサーバー プラットフォームと互換性があります。ベンダーは既存の製品を拡張して EJB をサポートできるようになります。
• 他のJava APIと互換性があります。
• エンタープライズ Bean と Java EE コンポーネント、および非 Java プログラミング言語アプリケーション間の相互運用性を提供します。
• CORBA プロトコル (RMI-IIOP) と互換性があること。

EJB 1.1、最終リリース (1999-12-17)

主な変更点:

• XML デプロイメント記述子
• デフォルトの JNDI コンテキスト
• IIOP 経由の RMI
• セキュリティ - メソッド主導ではなく、ロール主導
• エンティティ Bean のサポート - オプションではなく必須

リリース 1.1 の 目標:

• アプリケーションのアセンブリとデプロイメントをより適切にサポートします。
• 個々の EJB ロールの責任をより詳細に指定します。

EJB 1.0 (1998-03-24)

JavaOne 1998、^[42] Sunの第3回Java開発者会議（3月24日から27日） で発表されたリリース1.0の 目標：

• コンポーネント アーキテクチャによって想定される個別の「EJB ロール」を定義しました。
• エンタープライズ Bean のクライアント ビューを定義しました。
• エンタープライズ Bean 開発者のビューを定義しました。
• EJB コンテナ プロバイダーとサーバー プロバイダーの役割を定義しました。これらを組み合わせることで、エンタープライズ Bean のデプロイメントと実行をサポートするシステムが構成されます。

• 公式サイト
• Java EE 8 API Javadocs
• EJB 3.0 API Javadocs
• EJB 3.0 仕様
• Sun の EJB 3.0 チュートリアル
• EJB (3.0) 用語集
• EJB に関するよくある質問
• JSR 345 (EJB 3.2)
• JSR 318 (EJB 3.1)
• JSR 220 (EJB 3.0)
• JSR 153 (EJB 2.1)
• JSR 19 (EJB 2.0)
• EJB3 in Action、第 2 版の「メッセージ駆動型 Bean の操作」
• クライアントがEJBを呼び出す