A Session Bean is an Enterprise Bean that is generated for each session from the client and expires when the client exits. The lifecycle of the Session Bean does not exceed the range from the beginning until the end of the usage of the system by the user. Session Beans are classified into Stateless Session Beans, Stateful Session Beans, and Singleton Session Beans.

(a) Stateless Session Bean

This is a model in which the state of the session is not managed. Each session from the client needs to be concluded in one invocation of the Bean business method.

(b) Stateful Session Bean

This is a model in which the state of the session is managed. The EJB container manages the state of the session. Even when one session from the client invokes multiple EJB business methods, the state of each session is saved in between the invocation of the business methods.

(c) Singleton Session Bean

This is a model in which the state of the session is shared among multiple clients. One instance which is shared among all the sessions is created for an application. You must determine the Bean lifecycle according to the application.

For details on Singleton Session Beans that you can use with Application Server, see 2.19 Using Singleton Session Beans.

An Entity Bean expresses the entity, and as a prerequisite, must be stored (persisted) in the database. As a result, even when the client exits, the state of the Entity Bean continues to exist in the database. The lifecycle of this Enterprise Bean is longer as compared to that of a Session Bean. The following two management models are defined in the EJB specifications:

(a) BMP (Bean Managed Persistence)

This is a model for managing the data persistence of Enterprise Bean business methods. The developer of the Enterprise Bean must implement processes such as connecting to the database, assembling and executing SQL statements.

(b) CMP (Container-Managed Persistence)

This is a model in which the EJB container manages the data persistence. The EJB container executes processes, such as connecting to the database and storing data, therefore, these processes need not be executed by the business methods of the Enterprise Bean. Use the method provided by the EJB container to define the mapping of the Enterprise Bean data and the tables and columns of the database in which the data is to be stored. At the same time, define the connection information, such as the host name and port number of the database to which you will connect, in a resource adapter or a data source. The EJB container references this definition information, assembles the SQL statements, and references and stores the data in the tables of the database to which you will connect.

Note that since EJB QL has been implemented in CMP 2.0 added in EJB 2.0, the process of searching the database can be coded in the DD with syntax such as SQL, independent of the database to be used. In addition, CMR (Container-Managed Relationship) has been implemented to establish a relationship between the Entity Beans, therefore, the relationship between the Entity Beans can be specified in the DD and managed by the EJB container.

For details on the Java data type of the Entity Bean of the CMP functionality in the EJB container provided by Application Server and the SQL data type of the database, see 2.4.2 Mapping the CMP field and database.

A Message-driven Bean is a bean that integrates with JMS. The EJB container invokes a Bean, when a JMS message is received from the JMS Destination. Unlike a Session Bean or an Entity Bean, since the Message-driven Bean does not have a home interface and a component interface, it cannot be invoked directly from the client.

For a Message-driven Bean, the interfaces used for implementation in the EJB version 2.0 are different from the interfaces used for implementation in the EJB version 2.1 or later versions.

• In EJB 2.0, the following interfaces are implemented:
  
  • javax.ejb.MessageDrivenBean interface
  • javax.jms.MessageListener interface
• In EJB 2.1 or later versions, the following interfaces are implemented:
  
  • javax.ejb.MessageDrivenBean interface
  • Interface of any message listener provided by EIS

The versions of the corresponding connector are different in EJB 2.0 and in EJB 2.1 or later versions. The following table describes the correspondence between the versions of EJB and the connector:

Table 2-4 Correspondence between the EJB and connector versions

EJB version	Connector version
	Connector 1.0	Connector 1.5
EJB 2.0	Y	N
EJB 2.1 or later	Y	--

Legend:

Y: Messages sent from Cosminexus Reliable Messaging or TP1/Message Queue - Access can be received.

--: Messages sent by using the listener interfaces of any format can be received.

N: Messages sent from the corresponding resource adapter cannot be received.

Furthermore, the following table describes the functionality that is different in EJB 2.0 and EJB 2.1 or later versions:

Table 2-5 Functionality that is different in EJB 2.0 and EJB 2.1 or later versions

Functionality	EJB 2.0	EJB 2.1 or later
		When using the functionality of Connector 1.0	When using the functionality of Connector 1.5
Connectable resource adapters	Resource adapter in compliance with the Connector 1.0 specifications.	Resource adapter in compliance with the Connector 1.0 specifications.	Resource adapter that is compliant with the Connector 1.5 specifications, and in which Inbound has been defined.
Usable EIS	Cosminexus Reliable Messaging TP1/Message Queue - Access	Cosminexus Reliable Messaging#2 TP1/Message Queue - Access#2	Any EIS (including JMS) that supports Connector 1.5.#1
Defining a queue	Define in queue definition file.	Define in queue definition file.	Define in the objects to be managed within the DD of resource adapters (ra.xml).
JMS version	JMS1.0.2b	JMS1.0.2b	JMS1.1
Managing a connection in a message listener	Specify in the application attribute (pooled-instance). Same as the method-ready pool of the Message-driven Bean.	Specify in the application attribute (pooled-instance). Same as the method-ready pool of the Message-driven Bean.	Differ depending on the used resource adapters.

#1

Cosminexus Reliable Messaging or TP1/Message Queue - Access does not support the Connector 1.5 specifications. Therefore, you cannot use the functionality of Connector 1.5.

#2

You cannot specify a message-selector tag in the Deployment Descriptor of EJB2.1. When using the message selector, make changes to receive messages from the Cosminexus JMS provider.