Entity beans deal with data. They typically represent nouns, such as a frequent flier account, customer, or payment. Plain old Java objects come into existence when they are created in a program. When the program terminates, the object is lost. But an entity bean stays around until it is deleted. A program can create an entity bean and then the program can be stopped and restarted--but the entity bean will continue to exist. After being restarted, the program can again find the entity bean it was working with and continue using it.

Plain old Java objects are used only by one program. An entity bean, on the other hand, can be used by any program on the network. Client programs just need to find the entity bean via JNDI in order to use it. Entity beans must have a unique primary key that is used to find the specific entity bean they want to manipulate. For example, an "employee" entity bean may use the employee's social security number as its primary key. Methods of an entity bean run on a "server" machine. When a client program calls an entity bean's method, the client program's thread stops executing and control passes over to the server. When the method returns from the server, the local thread resumes execution.

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.

In order to generate the data access calls, the container needs information that you provide in the entity bean's 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.  You'll probably find it helpful to sketch the abstract schema before writing any code. Figure represents a simple abstract schema that describes the relationships between three entity beans. These relationships are discussed further in the sections that follow.

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 CustomerEJB 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).

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 with access methods. But unlike a persistent field, a relationship field does not represent the bean's state.