EJBs are J2EE components that implement the complex business logic for a J2EE application. An EJB component consists of the following parts :
There are three types of EJBs:
The following sections describe each of the above EJB types in more depth. Session BeansSession 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 .
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 ClassSession beans implement the SessionBean interface. The SessionBean interface has the following methods:
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 BeansEntity 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:
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:
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 ClassEntity 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:
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 ClassMDBs implement the MessageDrivenBean and MessageListener interfaces. The MessageDrivenBean interface defines the following methods:
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 . |