Remember that the intention of the EJB environment is that you will spend most of your time writing business logic rather than network and database "plumbing." Beyond writing the business logic, the only additional thing the bean writer needs to do is to provide lifecycle "hooks" that allow the container to manage the bean.

Each of the different types of EJBs discussed earlier (Session, Entity, and MDB) has a slightly different lifecycle, but the common parts are as follows:

• Bean creation and initialization

• Bean destruction and removal

• The saving and restoring of the bean's internal state (if applicable)

The details associated with each type of bean lifecycle will be discussed as they are covered. For now, all you need to know is that

• An EJB will implement one or more lifecycle interfaces depending on its type. The interfaces are defined in the javax.ejb package.

• Standard lifecycle methods must be provided.

• The lifecycle methods will generally begin with ejb so that they can be easily distinguished from the business methods around them, for example, ejbCreate().

Listing 4.4 contains the lifecycle methods in the example AgencyBean with most of the implementation code removed for clarity

Listing 4.4 Lifecycle Methods on the AgencyBean

package agency;

import java.rmi.*;
import java.util.*;
import javax.ejb.*;
// Remaining imports removed for clarity

public class AgencyBean implements SessionBean
{
  private DataSource dataSource;
  private String name = "";

  public void ejbCreate () throws CreateException { 
    try {
      InitialContext ic = new InitialContext();
      dataSource = (DataSource)ic.lookup("java:comp/env/jdbc/Agency");
      name = (String)ic.lookup("java:comp/env/AgencyName");
    }
    catch (NamingException ex) {
      error("Error connecting to java:comp/env/Agency:",ex);
    }
  }

  public void ejbActivate() { ... }

  public void ejbPassivate() { ... }

  public void ejbRemove() { ... }

  private SessionContext ctx;
 
  public void setSessionContext(SessionContext ctx) {
    this.ctx = ctx;
  }
}

As you can see, the example AgencyBean implements the SessionBean interface. This means that it must implement the ejbRemove(), ejbActivate(), ejbPassivate(), and setSessionContext() methods. The context passed in setSessionContext() provides a way for the bean to communicate with the container. It is usual to save the session context object in an instance variable for use by the other bean methods.

In an Entity bean the ejbCreate() method takes on the role of constructor in that most of the bean initialization will take place in this method, and corresponds to the create() method defined in the home interface. The ejbCreate() method is not defined in the SessionBean interface, because its signature will vary from one EJB to another (as described tomorrow when Session EJBs are discussed in detail).

The Deployment Descriptor

The final piece of the EJB jigsaw lies in the provision of configuration information, or meta data, for the EJB. This provides a way of communicating the EJB's requirements and structure to the container. If an EJB is to be successfully deployed, the container will have to be provided with extra information, including

• An identifier or name for the EJB that can be used for JNDI lookup to locate the bean.

• The bean type Session, Entity, or Message-Driven.

• The EJB's remote interface class. This interface will typically just be named according to the EJB's functionality, for example, Agency or BankTeller.

• The EJB's home interface class. The name for an EJB's home interface will typically be derived from its remote interface name.

• The bean class itself. Again, the name for the bean will typically be derived from the associated remote interface name.

• Any name/value pairs to be provided as part of the bean's environment. Effectively, these are variables that can be given values by the assembler or deployer as well as the developer.

• Information about any external resources required by the EJB, such as database connections or other EJBs.

All of this essential information is bundled into a deployment descriptor that accompanies the EJB classes. The deployment descriptor is defined as an XML document, and is discussed in more detail later when examining the packaging of an EJB.

In addition to the essential information, the deployment descriptor can also carry other metadata such as:

• Declarative attributes for security and transactions

• Structural information about bean relationships and dependencies

• Persistence mapping (if applicable)

You will see examples of all of these as you progress through this book.

This chapter is from Teach Yourself J2EE in 21 Days, second edition, by Martin Bond et. al. (Sams, 2004, ISBN: 0-672-32558-6). Check it out at your favorite bookstore today. Buy this book now.