Enterprise JavaBeans (EJB)

EJBs are J2EE components that implement the complex business logic for a J2EE application. An EJB component consists of the following parts :

• Deployment descriptors describe and declare the resources needed by EJBs and are stored as XML files. The vendor-independent deployment descriptor file is named ejb-jar.xml . In addition, there may be vendor-specific deployment descriptors.

• Component and/or Local interfaces, except in the case of message-driven beans. These interfaces describe the business methods available to the client. The EJB container, using these interfaces, creates classes that enable clients to use the EJBs. These stub classes enable clients to transparently use EJBs over the network. The skeleton classes enable the container to intercept calls and provide services to EJBs. All component interfaces extend the javax.ejb.EJBObject interface. Local interfaces extend the javax.ejb.EJBLocalObject interface.

  Note

  The remote interface has been renamed to component interface in the final EJB2.0 spec.

  
  

• Home and/or LocalHome interfaces, except in the case of message-driven beans. These interfaces describe the factory methods for creating, destroying, and obtaining references to EJBs. The container creates factory classes from these interfaces. The stub classes allow the client to acquire and release EJB instances. The skeleton classes allow the container to intercept the client requests to provide services. Home interfaces extend the javax.ejb.EJBHome interface. LocalHome interfaces extend the javax.ejb.EJBLocalHome interface.

• An EJB class. The EJB class contains the business logic and data specific to the application. This class is provided by the application developer. All EJB implementation classes indirectly implement the javax.ejb.EnterpriseBean interface.

• Helper classes. These classes are used by the EJB for application-specific purposes.

• JAR file. The EJB is packaged in a JAR file containing the elements listed above.

There are three types of EJBs:

• Session beans: These beans are accessed by clients (Servlet, application client, or another EJB). They represent single or groups of related operations for accessing persistent or legacy data. They contain procedural business logic.

• Entity beans: These beans represent persistent data. They generally are accessed by session beans.

• Message-driven beans: These EJBs process JMS messages, providing an asynchronous entry point to EJBs.

The following sections describe each of the above EJB types in more depth.

Session Beans

Session beans are EJB components used for managing client interactions. Generally, they are not used for updating data stores and usually work best as a transactional facade to entity beans. That is, session bean methods conceal the client application from the complexities of business workflow logic. The interfaces provided by session beans should be simple where the client only needs to call a single method or a group of simple methods to achieve a result that has business value.

There are two kinds of session beans: stateless and stateful .

• Stateless session beans are allocated by the container from a free pool of identical objects. The bean is then used for a single method invocation, and then it is released back into the free pool. Stateless session beans provide good performance because they can be multiplexed between clients.

• Stateful session beans are dedicated to clients for the lifetime of the bean. These beans retain EJB-specific information (such as its state) across method calls.

The rule of thumb for determining when to use a stateful or a stateless session bean is as follows : If a transaction can be completed with a single method call use a stateless session bean; otherwise , use stateful session beans. Although session beans do not represent the state of a data attribute in the data store, they can use JMS and JDBC to read and write persistent state information.

Session beans are declared in the ejb-jar.xml file using the <session> and <session-type> tags. The <session> tag identifies the bean as a session bean. The session type tag with a value of Stateless causes the EJB container to create a stateless session bean. Alternatively, a value of Stateful causes the container to create a stateful session bean.

The Home interface for session beans must have a create method because session beans are not persistent. This create method maps to the ejbcreate() method implemented by the EJB bean class. The EJB container takes care of creating new beans according to the EJB pool deployment descriptor.

The Session Bean Class

Session beans implement the SessionBean interface. The SessionBean interface has the following methods:

• ejbActivate : This method is used for stateful beans when the container decides to allocate it to a client or remote it from a passivated state.

• ejbPassivate : The container calls this method before the bean is placed into a dormant state. A stateful bean is passivated to conserve memory resources. This usually means writing the bean to disk. The passive state for a stateless bean is usually in a memory-free pool.

• ejbRemove : The container invokes this method before permanently removing a session bean from its pool.

• setSessionContext : This method is called by the container after the session bean is created. The session context is used to access container information about the current session bean.

• ejbCreate : This method is called when a bean is created or re- initialized . The method signature depends on the create method in the Home interface.

For technical information on developing Session Beans in the context of the WebLogic Server 7.0, see "Developing Business Logic ”Session Beans," p. 609 .

Entity Beans

Entity beans represent persistent data maintained in a database. Entity bean data is usually mapped to a row in a database table. Like stateless session beans, a particular instance is allocated to a client for the duration of a method call. Entity beans are allocated from a free pool by the container when they are needed.

Because entity beans represent data, they need a unique primary key and must support relationships with other entity beans. This mirrors the functionality supported by relational databases with primary and foreign keys.

Note

Each entity EJB needs a primary key class. It can be a native Java object, such as a string or a user -defined Java object.

The Home interface for an entity bean must define create and finder methods matching those in the entity bean.

Note

Finder methods are discussed further in the CMP section of this chapter.

Entity beans use two persistence mechanisms. Data can be saved and read by either making explicit JDBC calls from the EJB class or declaratively using the entity bean's deployment descriptors, where the container issues the JDBC calls. Explicit persistence is referred to as bean-managed persistence (BMP) and declarative persistence is called container-manager persistence (CMP).

Bean-Managed Persistence (BMP)

With BMP the bean developer writes the code to retrieve and save persistent data using JDBC. Bean data is stored in instance fields and mapped to a database. Relationships with other entity beans are also stored in instance fields. The database mapping can be done either explicitly by the developer or by using an object-to-relational database mapping tool.

Container-Managed Persistence (CMP)

For entity beans using container-managed persistence, the EJB container loads and saves data from/to the data store. There is no JDBC code in the CMP bean.

Because the container performs all data updates and reads, it must have access to the data fields of the entity bean. In fact, the entity bean developer does not define any data field objects in their source code. Instead, the developer defines public abstract get and set methods whose names correspond to entries in the EJB deployment descriptor ( ejb-jar.xml ). The EJB container creates an entity bean that subclasses the developer's abstract entity bean, defining non-abstract get and set methods with objects to store the bean's data.

Entity beans participate in relationships with other entity beans, just as tables maintaining foreign keys from other tables in a relational database. A CMP bean contains two types of fields: data fields and relationship fields. A relationship field does not represent the bean's state, as the data field does, but instead is a foreign key to another EJB. The EJB deployment descriptor allows 1-1, 1-n, and n-n relationships between EJBs. These relationships are called container-managed relationships (CMR) and are declared between EJBs and relationship fields using the EJB deployment descriptor.

The mapping between fields in a CMP entity bean and a column in a database table is accomplished by using the EJB deployment descriptor file ( ejb-jar.xml ) and a vendor-specific CMP deployment descriptor file for the EJB container. For example, in the case of the WebLogic Server the CMP deployment descriptor file is named weblogic-cmp-rdbms-jar.xml.

The ejb-jar.xml provides the following tags for CMP beans:

• <persistence-type> , which must have a value of "Container" to indicate the bean is using container-managed persistence.

• <abstract-schema- name > , which provides an identifying name for the memory-schema of the EJB.

• <field-name> , which, within the context of the <cmp-field> tag, provides persistent fields for the bean. Each persisted field corresponds to the public abstract get/pub methods of the entity bean.

• <primary-field> , which identifies which one of the field entries under the <cmp-field> tag is the bean's primary key.

Note

For CMP beans, the <primary-field> tag is not valid for use with compound primary keys.

The objective of the vendor-specific deployment descriptor is to provide CMP bean information to the EJB container. For example:

• Which JDBC data source to use for the CMP bean.

• Which tables in the relational database to use.

• The mapping information between the fields declared in the ejb-jar.xml file and the database columns .

Another key element of the ejb-jar.xml file for CMP beans is the <query> tag. Because the entity bean developer does not write JDBC code, the container must create finder methods to look up beans. Using EJB-QL statements, the container can generate finder methods defined in the EJBHome or EJBLocalHome interfaces.

Note

EJB-QL or EJB query language is an SQL-92 style language for defining entity bean lookups and is part of the EJB 2.0 specification. Instead of querying relational data, EJB-QL queries objects.

The Entity Bean Class

Entity beans implement the EntityBean interface. The business methods of the entity bean do not access the database directly, because database access is managed by the ejbCreate , ejbFindByPrimaryKey , ejbFind< Method >, ejbLoad , ejbRemove , and ejbStore methods.

The EntityBean interface has the following methods:

• ejbActivate : This method is used when the container decides to allocate the entity bean instance to a client or load a bean from the passivated state. This method must set the primary key of the entity bean.

• ejbPassivate : The container calls this method before the bean is placed into a dormant state. An entity bean is passivated to conserve memory resources and this usually means writing it to disk.

• ejbRemove : The container invokes this method before permanently removing an entity bean and its corresponding entry in the data store.

• ejbLoad : The container calls this method at the start of a transaction or when the bean is first loaded into memory. This method loads the current value of the data store entry for this bean into memory.

• ejbStore : The container calls this method at the end of a transaction just before the entity bean's data is written to disk.

• ejbFindByPrimaryKey : This method is called by the container and it returns the primary key object for the bean. This method matches the findByPrimaryKey method of the Home interface.

• setEntityContext : This method is called by the container after the entity bean is created. The entity context is used to access container information specific to the current entity bean, such as who is using the bean.

• ejbPostCreate : This method is called after the bean and data store elements for the bean have been written to the persistent storage. It sets the container-managed relationships with other beans.

• ejbCreate : This method is called when a bean is created or re-initialized. The method signature depends on the create method in the Home interface. This method sets the primary key and other container-managed fields. This method also returns an instance of the primary key to the entity bean.

• ejbFind < Method > : This method corresponds to finder methods in the Home interface. It returns either a collection of primary keys or a single primary key for an entity bean.

Note

Entity beans must define one or more ejbCreate methods to define how an entity bean can be initialized. They also can have optional finder methods.

For technical information on developing Entity Beans in the context of the WebLogic Server 7.0, see "Managing Persistence ”Entity Beans," p. 655 .

Message-Driven Beans (MDB)

Message-driven beans (MDB) are asynchronous JMS message consumers. They provide a loosely coupled mechanism to access services and business logic contained in a J2EE server. MDBs can use entity beans, EIS components, and other J2EE components during their processing. Also, MDBs are ideal for B2B and logging applications where requests are delivered without expecting an immediate response.

MDBs are very similar to stateless session beans. They contain no state, are allocated from a free pool when needed, and are placed back in the free pool after a message is processed . They also support container-managed transactions for the lifetime of the onMessage JMS method call. However, unlike session beans, MDBs have no identity information in their messages; all messages are anonymous. In addition, MDBs do not require a Home or Remote/Local interfaces because they can only receive messages via JMS.

The EJB container performs most of the steps necessary to connect to JMS. At startup, the EJB container creates a pool of free MDBs and connects itself to JMS to receive messages on their behalf . When a MDB is created, the container calls the setMessageContext method. The receipt of a message causes the container to remove an MDB from the free pool and call the onMessage method. When the method call completes, the MDB is placed back in the free pool.

MDBs are declared in the ejb-jar.xml deployment description. The <message-driven> tag identifies the EJB as an MDB. The queue or topic receiving messages is specified in the <message-driven-destination> tag.

The Message-Driven Bean Class

MDBs implement the MessageDrivenBean and MessageListener interfaces.

The MessageDrivenBean interface defines the following methods:

• ejbRemove : This method is invoked by the container just before the message bean is permanently removed.

• SetMessageDrivenContext : This method is called just after a message bean is created. The container passes a MessageDrivenContext object to the message bean. The MessageDrivenContext contains methods into the container for information about the current message bean instance.

The MessageListener interface defines only one method, onMessage , which receives messages from JMS via the container. The bean's business logic is contained in this method.

For technical information on developing Message-Driven Beans in the context of the WebLogic Server 7.0, see "Asynchronous Message Processing ”Message-Driven Beans," p. 725 .