You might be wondering about why we need a layer of session beans at all. If the lightweight model is all about simplifying application development, wouldn't it be easier to implement the business logic directly in the in web component like a Servlet or a JSF backing bean (see later in this chapter for JSF backing beans)? In some cases, that might be true, especially for very simple applications. However, EJB3 session beans are lightweight enough to fit nicely in small web applications, high-end enterprise applications and everywhere in-between. As we discussed in Chapter 1, What is a Lightweight Web Application, session beans provide important features such as dependency injection and container managed transaction.

To implement a session bean, we first determine the interface it exposes. In the DVD catalog application, this is a simple Java interface declaring all business methods.

public interface DvdCatalog {
  public void addProduct (Product product);
  public Collection <Product> getAllProducts ();
}
        

The EJB3 container creates instances of the session bean based on the implementation classes. The application itself never creates session bean instances. It simply asks the container for an instance of the session bean to use, either through dependency injection or, for external components, through a JNDI lookup. The class is tagged with the @Stateless annotation, which tells the container that the bean object does not maintain any client state information between method invocations. The caller component gets a fresh and random DvdCatalogBean instance every time it makes a bean method call.

@Stateless
public class DvdCatalogBean implements DvdCatalog {

  // ... ...

}
        

So far we have learned how to setup a EJB3 session bean component. In the next section, we will learn how to implement the session bean to access the database via entity beans. We will see how other parts of the application (i.e., the JSF backing bean) make use of the session bean later in this chapter.

As we discussed, in an EJB3 application, the data model is implemented in EJB3 entity beans, which are persisted to the database. In order to use the entity beans in the session bean, you need a special utility class called the EntityManager. The EntityManager acts as a generic DAO (Data Access Object) for all entity beans in the JAR. It translates operations on entity beans to SQL statements to the database. The easiest way to obtain an EntityManager is to let the container create one and inject it into the session bean (see "dependency injection" in Chapter 1, What is a Lightweight Web Application). Since the DVD Catalog sample application contains a single persistence context, the code just has to ask for it. The following listing shows how to do just that.

@Stateless
public class DvdCatalogBean implements DvdCatalog {

  @PersistenceContext
  EntityManager em;
  
  // ... ...
}
        

Notice that the em variable is simply a data member in the DvdCatalogBean class. Its value is never explicitly initialized. The container assigns the right EntityManager to the em variable at runtime each time em is used.

The addProduct() and getAllProducts() methods in the DvdCatalogBean class show the EntityManager in action. The EntityManager.persist() method takes a new entity bean POJO and writes it to the database.

@Stateless
public class DvdCatalogBean implements DvdCatalog {

  public void addProduct (Product product) {
    em.persist (product);
  }

  // ... ...
}
        

The EntityManager.query() method takes a query string to search for entity bean objects in the database (to be more accurate, it retrieves data from the relational database and then assembles those data into entity objects). The syntax of the query string is very similar to SQL. We will cover EJB3 Query Language in more detail in Chapter 4, Develop a Data Model.

@Stateless
public class DvdCatalogBean implements DvdCatalog {

  // ... ...

  public Collection <Product> getAllProducts () {
    return (Collection <Product>)
        em.createQuery("from Product p").getResultList();
  }
}
        

In this simple example, we have so far ignored the transaction services for database operations in session beans. It's not that transactions aren't important. The EJB3 defaults are exactly what we want right now. We will cover database transactions in Chapter 6, Transactions.

The CatalogBean is the only JSF backing bean in the DVD catalog application. Again, its source code can be found in the src directory of the dvdcatalog project template. As discussed in the previous section, we want to refer to the CatalogBean backing bean by the name catalog in the JSP page. To do that, we add the following definition in the dd/war/faces-config.xml configuration file in the dvdcatalog project template.

<faces-config>

  <managed-bean>
    <description>catalog</description>
    <managed-bean-name>catalog</managed-bean-name>
    <managed-bean-class>
      dvdcatalog.web.CatalogBean
    </managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
  </managed-bean>

  ... ...

</faces-config>
        

In the catalog.jsp page, #{catalog} refers to the backing bean instance, and #{catalog.product} refers to the product property in the backing bean instance. Since the scope of the backing bean is request, a new backing bean will be created each time the user reloads the page. Please see Chapter 5, Make the Application Stateful for more on JSF backing bean scopes. Now, let's examine the CatalogBean in more detail.

The CatalogBean backing bean contains two properties: The product property is in fact a Product entity bean object. It maps to all the input fields in the new DVD entry form. The backing bean's constructor sets the initial value for the product property, which are displayed in the initial data entry page. When the addProduct.jsp form is submitted, JSF automatically sets the fields of the product property to contain the input values from the form. The productList property is a collection of Product objects, retrieved from the database to be displayed in the catalog.jsp page.

public class CatalogBean implements Serializable {

  protected Product product;
  protected Collection <Product> productList;

  ... Getter and Setter methods for the
      product and productList properties ...

  public CatalogBean () {
    // ... ...

    product = new Product ();
    // Initialize the form
    // product.setTitle("A Great Movie");
    // product.setActor("Oscar Winner");
    // product.setPrice(25.0);
  }
}
        

In the catalog.jsp page, we see that when the form is submitted, the server is supposed to perform action #{catalog.addProduct}. That means the server would invoke the addProduct() method on the CatalogBean backing bean. The CatalogBean.addProduct() method invokes the DvdCatalog session bean's addProduct() method and passes in the product entity bean, which is automatically constructed from the user input. It then uses the session bean to retrieve a complete list of products in the database. The following code listing shows the code for addProduct() method.

public class CatalogBean 
    implements Serializable {

  // ... ...

  public String addProduct() {
    DvdCatalog dvdCatalog = getCatalogBean();
    // Add the product to the database
    dvdCatalog.addProduct(product);
    // Refresh the products list
    setProductList(dvdCatalog.getAllProducts());
    
    return "afterAddProduct";
  }
  
  private DvdCatalog getCatalogBean() {
    try {
      InitialContext ctx = new InitialContext();
      return (DvdCatalog) 
  ctx.lookup("dvdcatalog/DvdCatalogBean/local");
    } catch (Exception e) {
      // Handle exception ...
    }
  }
}
        

Now, we use the dreaded JNDI lookup in the getCatalogBean() method to obtain an EJB3 session bean instance in the JSF backing bean. What's up with that? Aren't we supposed to use dependency injection here? Well, this is in fact an integration gap between the current JSF and EJB3. The JBoss Seam framework (see side bar) bridges this gap. But for a pure JSF + EJB3 application here, We have to resort to the old JNDI lookup as a workaround. By default, the JNDI lookup string is composed of the application's name (i.e., the EAR file's base name, see Chapter 3, Customization and Agile Deployment), the session bean class name, and whether the session bean is local or remote. A local session bean runs in the same JVM as the client.

The return value of the event handler method is used by the server to determine which page to display next after processing the event. Here, the addProduct() method returns the "afterAddProduct" string, the server would load and display to the /app/catalog.jsp page after addProduct() exits, according to the following navigation rule in the faces-config.xml file.

<faces-config>

  ... ...

  <navigation-rule>
    <navigation-case>
      <from-outcome>afterAddProduct</from-outcome>
      <to-view-id>/app/catalog.jsp</to-view-id>
    </navigation-case>
    ... ...
  </navigation-rule>
</faces-config>
        

These rules can be as specific or as general as needed. If the event handler method returns null, the server would refresh and display the current page.