11 a) (II) To create an entity bean, you perform the following steps: 1. Create a remote interface for the bean.

The remote interface declares the methods that a client can invoke. It must extend javax.ejb.EJBObject. 2. Create a home interface for the bean. The home interface must extend javax.ejb.EJBHome. It defines the create and finder methods, including findByPrimaryKey, for your bean. 3. Define the primary key for the bean. The primary key identifies each entity bean instance. The primary key must either be a well-known class, such as java.lang.String, or be defined within its own class. 4. Implement the bean. This includes the following: a. The implementation for the methods declared in your remote interface. b. An empty constructor for the bean. c. The methods defined in the javax.ejb.EntityBean interface. d. The methods that match the methods declared in your home interface. This includes the following: The ejbCreate and ejbPostCreate methods with parameters matching those of the create method defined of the home interface. An ejbFindByPrimary key method which corresponds to the findByPrimaryKey method of the home interface. Any other finder methods that were defined in the home interface. 5. If the persistent data is saved to or restored from a database, you must ensure that the correct tables exist for the bean. 6. Create the bean deployment descriptor. The deployment descriptor specifies properties for the bean through XML properties. See "Deploying an EJB" for more details. 7. Create an ejb-jar file containing the bean, the remote and home interfaces, and the deployment descriptor. The ejb-jar file must define all

beans within your application. Refer to"Create a JAR File" for more details

Deployment:

8. In the same manner, you must create the XML deployment descriptors for the bean, create a JAR file containing all of the bean's files, and use deployejb tool to load and publish the bean in the database. 9. The XML deployment descriptors are explained fully in Appendix A, "XML Deployment Descriptors". See the appendix for a full description on defining persistence for entity beans. For completeness, the following is how the purchase order example deployment descriptors are organized. Since the purchase order does not define any logical names that must be mapped and do not use the <run-as> option, only the EJB deployment descriptor is required.

DEPLOYMENT: In the same manner, you must create the XML deployment descriptors for the bean, create a JAR file containing all of the bean's files, and use deployejb tool to load and publish the bean in the database. The XML deployment descriptors are explained fully in Appendix A, "XML Deployment Descriptors". See the appendix for a full description on defining persistence for entity beans. For completeness, the following is how the purchase order example deployment descriptors are organized. Since the purchase order does not define any logical names that must be mapped and do not use the <run-as> option, only the EJB deployment descriptor is required.

11 a (I) There are two types of persistence for entity beans: bean-managed and container-managed. With bean-managed persistence, the entity bean code that you write contains the calls that access the database. If your bean has containermanaged persistence, the EJB container automatically generates the necessary database access calls. The code that you write for the entity bean does not include these calls

Container-Managed Persistence The term container-managed persistence means that the EJB container handles all database access required by the entity bean. The bean's code contains no database access (SQL) calls. As a result, the bean's code is not tied to a specific persistent storage mechanism (database). Because of this flexibility, even if you redeploy the same entity bean on different J2EE servers that use different databases, you won't need to modify or recompile the bean's code. In short, your entity beans are more portable if you use container-managed persistence than if they use bean-managed persistence. To generate the data access calls, the container needs information that you provide in the entity bean's abstract schema. Abstract Schema Part of an entity bean's deployment descriptor, the abstract schema defines the bean's persistent fields and relationships. The term abstract distinguishes this schema from the physical schema of the underlying data store. In a relational database, for example, the physical schema is made up of structures such as tables and columns. You specify the name of an abstract schema in the deployment descriptor. This name is referenced by queries written in the Enterprise JavaBeans Query Language (EJB QL). For an entity bean with container-managed persistence, you must define an EJB QL query for every finder method

(except findByPrimaryKey). The EJB QL query determines the query that is executed by the EJB container when the finder method is invoked. To learn more about EJB QL, see Chapter 29. You'll probably find it helpful to sketch the abstract schema before writing any code. Figure 23-1 represents a simple abstract schema that describes the relationships between three entity beans. These relationships are discussed further in the sections that follow.

Figure 23-1 A High-Level View of an Abstract Schema Persistent Fields The persistent fields of an entity bean are stored in the underlying data store. Collectively, these fields constitute the state of the bean. At runtime, the EJB container automatically synchronizes this state with the database. During deployment, the container typically maps the entity bean to a database table and maps the persistent fields to the table's columns. A CustomerBean entity bean, for example, might have persistent fields such as firstName, lastName, phone, and emailAddress. In container-managed persistence, these fields are virtual. You declare them in the abstract schema, but you do not code them as instance variables in the entity bean class. Instead, the persistent fields are identified in the code by access methods (getters and setters).

Relationship Fields A relationship field is like a foreign key in a database table: it identifies a related bean. Like a persistent field, a relationship field is virtual and is defined in the enterprise bean class via access methods. But unlike a persistent field, a relationship field does not represent the bean's state. Relationship fields are discussed further in Direction in Container-Managed Relationships. Multiplicity in Container-Managed Relationships There are four types of multiplicities: one-to-one, one-to-many, many-to-one, and many-to-many. One-to-one: Each entity bean instance is related to a single instance of another entity bean. For example, to model a physical warehouse in which each storage bin contains a single widget,StorageBinBean and WidgetBean would have a one-to-one relationship. One-to-many: An entity bean instance can be related to multiple instances of the other entity bean. A sales order, for example, can have multiple line items. In the order application, OrderBeanwould have a one-to-many relationship with LineItemBean. Many-to-one: Multiple instances of an entity bean can be related to a single instance of the other entity bean. This multiplicity is the opposite of a one-tomany relationship. In the example just mentioned, from the perspective of LineItemBean the relationship to OrderBean is many-to-one. Many-to-many: The entity bean instances can be related to multiple instances of each other. For example, in college each course has many students, and every student may take several courses. Therefore, in an enrollment application, CourseBean and StudentBean would have a many-to-many relationship. Direction in Container-Managed Relationships The direction of a relationship can be either bidirectional or unidirectional. In a bidirectional relationship, each entity bean has a relationship field that refers to the other bean. Through the relationship field, an entity bean's code can access its related object. If an entity bean has a relative field, then we often say that it "knows" about its related object. For example, if OrderBeanknows

what LineItemBean instances it has and if LineItemBean knows what OrderBean it belongs to, then they have a bidirectional relationship. In a unidirectional relationship, only one entity bean has a relationship field that refers to the other. For example, LineItemBean would have a relationship field that identifies ProductBean, butProductBean would not have a relationship field for LineItemBean. In other words, LineItemBean knows about ProductBean, but ProductBean doesn't know which LineItemBeaninstances refer to it. EJB QL queries often navigate across relationships. The direction of a relationship determines whether a query can navigate from one bean to another. For example, a query can navigate fromLineItemBean to ProductBean but cannot navigate in the opposite direction. For OrderBean and LineItemBean, a query could navigate in both directions, because these two beans have a bidirectional relationship.