EJB 3.0 Entity Model
To create the session bean, a developer only needs to code a bean class and annotate it with appropriate metadata. A session bean need not home interface, remote interface, or deployment descriptor to code. All that is required in addition to the bean class is a business interface, and that can be generated by default. The bean class is coded as a plain old Java object (POJO) rather than a class that implements an interface such as javax.ejb.SessionBean. Because the bean class does not implement an interface such as javax.ejb.SessionBean, a developer no longer has to implement methods such as ejbRemove, ejbActivate, or ejbPassivate in the bean class. However a developer can implement any or all of these callbacks if they are needed. If the bean class implements one of these callbacks, the EJB container calls it just as it does for EJB 2.1 technology.
The new Java Persistence API in EJB 3.0 defines a new single model for implementing persistence in the Java platform. In EJB 3.0 technology, an entity bean class is a concrete class. It's no longer an abstract class.
The EJB 2.0 specification uses the CMP model. It expanded the existing CMP to allow multiple entity beans to have relationships among themselves. This is referred to as Container-Managed Relationships (CMR). The container manages the relationships and the referential integrity of the relationships.According to the EJB 2.0 specification, the implementation class for an entity bean that uses CMP is now defined as an abstract class.
The EJB 1.1 specification presented a more limited CMP model. The EJB 1.1 architecture limited CMP to data access that is independent of the database or resource manager type. It allowed you to expose only an entity bean’s instance state through its remote interface; there is no means to expose bean relationships. The EJB 1.1 version of CMP depends on mapping the instance variables of an entity bean class to the data items representing their state in the database or resource manager. The CMP instance fields are specified in the deployment descriptor, and when the bean is deployed, the deployer uses tools to generate code that implements the mapping of the instance fields to the data items.
The following topics are discussed in this section:
Defining Persistent Fields
In EJB 3.0, get and set methods are concrete, not abstract. In addition, these methods can include logic, something that was not possible previously. This is useful for actions such as validating fields. Another improvement is that access to the persistence fields is not limited to the get and set methods. The persistence fields are also accessible through a bean class's business methods. One restriction however is that in EJB 3.0 technology, only methods within the class can access persistence fields -- in other words, you cannot expose the instance variables outside of the class.
The EJB 2.0 specification lets you designate an entity bean’s instance variables as CMP fields or CMR fields. You define these fields in the deployment descriptor. CMP fields are marked with the element cmp-field, while container-managed relationship fields are marked with the element cmr-field.
Dependency Injection
Previous versions of the EJB architecture forced the developer into complying with the requirements of the EJB container in terms of providing classes and implementing interfaces. By comparison, In EJB 3.0, dependency injection reflects the fact that the bean tells the EJB container what it needs, and then container satisfies those needs.
Message-Driven Beans
EJB 3.0 enhances message-driven beans with support for interceptors.
Message-driven beans were a new feature introduced by the EJB 2.0 architecture. Message-driven beans are transaction-aware components that process asynchronous messages delivered through the Java Message Service (JMS).
- © 2010, Oracle Corporation and/or its affiliates