Session Beanは，クライアントからのセッション単位に生成され，クライアントが終了すると消滅するEnterprise Beanです。Session Beanのライフサイクルは，ユーザがシステムの利用を開始してから終了するまでの範囲を超えることはありません。Session Beanは状態管理をするかどうかによって，Stateless Session BeanとStateful Session Beanに分類されます。

(a)　Stateless Session Bean

セッションの状態を管理しないモデルです。クライアントからの1セッションはBeanのビジネスメソッドの1回の呼び出しで完結させる必要があります。

(b)　Stateful Session Bean

セッションの状態を管理するモデルです。EJBコンテナが状態管理をします。クライアントからの1セッションがEJBの複数のビジネスメソッドを呼び出す場合でも，ビジネスメソッドの呼び出し間で状態が保存されます。

Entity Beanは，エンティティを表現し，データベースに保存（永続化）されることを前提としています。そのため，クライアントが終了してもEntity Beanの状態はデータベースに存在し続けます。Session Beanと比較してライフサイクルが長いEnterprise Beanです。EJB仕様では，次の二つの管理モデルを規定しています。

(a)　BMP（Bean Managed Persistence）

Enterprise Beanのビジネスメソッド内でデータの永続化の管理をするモデルです。データベースへの接続，SQLの組み立てや実行などの処理は，Enterprise Beanの開発者が実装しなければなりません。

(b)　CMP（Container Managed Persistence）

EJBコンテナがデータの永続化の管理をするモデルです。データベースへの接続とデータの保存はEJBコンテナによって実行されるので，Enterprise Beanのビジネスメソッドで実行する必要はありません。Enterprise Bean内のデータと格納先データベースのテーブルおよびカラムの対応をEJBコンテナが提供する方法で定義します。一方，接続先データベースのホスト名やポート番号などの接続情報をリソースアダプタまたはデータソースに定義します。EJBコンテナは，これらの定義情報を参照してSQL文を組み立て，接続先データベースのテーブルにデータの参照および格納をします。

なお，EJB 2.0で追加されたCMP 2.0ではEJB QLが導入されたため，使用するデータベースに依存することなく，データベースの検索処理をSQLのような構文でDDに記述できるようになりました。また，Entity Bean同士に関連を持たせるCMR（Container-managed relationship）が導入されたため，Entity Bean間の関連をDDで設定し，EJBコンテナで管理できるようになりました。

Cosminexusで提供するEJBコンテナのCMP機能でのEntity BeanのJavaデータ型とデータベースのSQLデータ型の対応については，「5.2.9　CMPフィールドとデータ型のマッピング」を参照してください。

Message-driven Beanは，JMSと連携するメッセージ駆動タイプのBeanです。EJBコンテナはJMSのDestinationからのJMSメッセージ受信を契機にBeanを起動します。Session BeanまたはEntity Beanと異なり，ホームインタフェース，コンポーネントインタフェースを持たないため，クライアントから直接呼び出されません。

Message-driven Beanは，EJB 2.0の場合とEJB 2.1の場合で実装するインタフェースが異なります。

• EJB 2.0の場合は，次のインタフェースを実装します。
  
  • javax.ejb.MessageDrivenBeanインタフェース
  • javax.jms.MessageListenerインタフェース
• EJB 2.1の場合は，次のインタフェースを実装します。
  
  • javax.ejb.MessageDrivenBeanインタフェース
  • EISが提供する任意のメッセージリスナのインタフェース

EJB 2.0とEJB 2.1では，それぞれ対応するConnectorのバージョンが異なります。EJBとConnectorのバージョンの対応を次の表に示します。

表5-3　EJBとConnectorのバージョンの対応

EJBのバージョン	Connectorのバージョン
	Connector 1.0	Connector 1.5
EJB 2.0	○	×
EJB 2.1	○	◎

（凡例）

○：uCosminexus Reliable MessagingまたはTP1/Message Queue - Accessから送信されたメッセージを受信できます。

◎：任意の形式のリスナインタフェースを使用して送信されたメッセージを受信できます。

×：該当するリソースアダプタから送信されたメッセージを受信できません。

また，EJB 2.0とEJB 2.1では，次の表に示す機能差があります。

表5-4　EJB 2.0とEJB 2.1の機能差

機能	EJB 2.0	EJB 2.1
		Connector 1.0の機能を使用する場合	Connector 1.5の機能を使用する場合
接続できるリソースアダプタ	Connector1.0仕様に準拠したリソースアダプタ。	Connector1.0仕様に準拠したリソースアダプタ。	Connector 1.5仕様に準拠し，Inboundが定義されているリソースアダプタ。
使用できるEIS	uCosminexus Reliable Messaging TP1/Message Queue - Access	uCosminexus Reliable Messaging TP1/Message Queue - Access	Connector 1.5をサポートする任意のEIS（JMSを含みます）。※
キューの定義方法	キュー定義ファイルに定義します。	キュー定義ファイルに定義します。	リソースアダプタのDD（ra.xml）内の管理対象オブジェクトに定義します。
JMSのバージョン	JMS1.0.2b	JMS1.0.2b	JMS1.1
メッセージリスナでのコネクションの管理方法	アプリケーションの属性（pooled-instance）に指定します。Message-driven Beanのmethod-readyプールと同じになります。	アプリケーションの属性（pooled-instance）に指定します。Message-driven Beanのmethod-readyプールと同じになります。	使用するリソースアダプタによって異なります。

注※

uCosminexus Reliable MessagingまたはTP1/Message Queue - AccessはConnector 1.5仕様に対応していないため，Connector 1.5の機能は使用できません。