J2EE 1.4 has a very rigid component structure. In the EJB 2.1 specification, the beans have to inherit from certain framework classes and implement multiple framework interfaces. Those abstract base classes and interfaces act as the "hook" between the bean and the container. For instance, the container would register classes that implement the javax.ejb.EJBObject interface as EJBs; EJB classes that also implement the java.rmi.Remote interface would be made accessible over the network; when instantiating the EJB, the container would also call the ejbCreate() method in the bean class, which is declared in the bean's abstract base class javax.ejb.SessionBean. You have to implement the life cycle methods (e.g., the ejbCreate() method) in the abstract base class even if they are empty.

The rigid component structure makes it difficult to inherit from EJB 2.1 beans. It essentially forces developers back to use pre-Java procedural programming techniques in J2EE applications. In addition, you cannot directly pass EJB 2.1 beans across J2EE tiers. You have to write special serializable "data transfer objects" (DTOs, also known as value objects) to clone the data content inside the bean. That is a lot of duplicated code.

A much better solution is to use plain old Java objects (POJOs) as service components. However, without the underlying framework interfaces and abstract classes acting as "hooks", how does the framework know which POJO is a managed EJB component?

The container manages the POJOs according to configuration metadata associated with the Java objects. For instance, the metadata could specify which bean methods are the life cycle methods and eliminate the need for the abstract base class. The POJO approach is a cornerstone of lightweight frameworks. In some POJO frameworks, the metadata is completely specified in separate XML files. But in EJB3, we use easy-to-use Java annotations to specify POJO metadata and glue the components with containers. For instance, a stateless session bean in EJB3 could be as follows. The @PostConstruct annotated method is a POJO lifecycle method and it is invoked right after the bean is created.

@Stateless
public class MyBean implements MyInterface {

  public void myBusinessMethod () {
    // ... ...
  }

  @PostConstruct
  public void myInitMethod () {
    // Invoked right after the bean is created
    // ... ...
  }
}
        

Another important scenario is to use managed POJOs for data models. For instance, in the following example, the EJB3 container maps the Product class to a relational database table of the same name. The container figures out the structure of the table based on the class's JavaBean properties (i.e., the getter and setter methods). So, the table has an ProductId column and a ProductName column. All operations on Product instances are automatically translated to SQL statements by the container and persisted to the relational database. You can read more about EJB3 POJO entity beans in Chapter 4, Develop a Data Model and Chapter 10, Complex ORM.

@Entity
public class Product 
    implements Serializable 
{
  private long productId;
  private String productName;

  @Id
  @GeneratedValue
  public int getProductId () {
    return productId;
  }
  public void setProductId (int id) {
    this.productId = id;
  }

  public String getProductName () {
    return productName;
  }
  public void setProductName (String name) {
    this.productName = name;
  }
}
        

In EJB3, annotations are used not only to define EJB components but also to deliver container services to POJOs. In fact, the wide use annotation is a main characteristic that differentiates EJB3 from EJB 2.1 and even some other earlier lightweight frameworks.

As we discussed earlier in this chapter, declarative services are a key concept in Java enterprise middleware, freeing developers from coding tedious cross-cutting concerns (e.g., logging, transaction and security) that are not essential to the business logic. In J2EE 1.4 and some other enterprise Java frameworks (e.g., the Spring framework), XML configuration files are used extensively to deliver services to Java objects. For instance, you can declare transactional and security properties of methods in a separate XML file. The container reads in the XML file at runtime and applies those services to the methods. However, as the container grows bigger and more complex, the complexity of the XML configuration files quickly grows out of control. In a typical J2EE 1.4 application (or Spring application), you can easily have as much "XML code" as Java code.

The biggest problem with XML configuration files is they are very repetitive. The repetition comes from the separation between the Java code and code configuration. You have to repeat the same information in both the Java code and the XML configuration file in order to connect the two. In the XML file, you have to verbosely "describe" which class and methods each setting applies to. If you make one typo, well, the application breaks with hard-to-debug errors.

To compound this problem, older frameworks do not provide sensible default configuration settings. You have to spell out everything explicitly in XML code. It makes the XML files very hard to read and extremely tedious to write by hand. Just take a look at the security configuration in J2EE 1.4 or transaction configuration in Spring, and you will immediately understand what we mean here.

The problems with external XML metadata have been refereed to as "XML hell", and it is one of the major complaints developers have against J2EE 1.4. As developers become frustrated with XML files, they invent new solutions. The open source XDoclet project allows you to define metadata in specially formatted JavaDoc comments. The XDoclet pre-processor analyzes the code and automatically generates all the correct J2EE XML files. This approach makes developer's life easier by putting code and code-related configuration metadata close together in the same file. The developer can quickly associate the two pieces of information without switching between editor windows. XDoclet has become a wildly popular project among J2EE developers.

Learning from the success of XDoclet, Sun added a new language feature known as annotations in the Java language in Java SE 5.0. Annotations embed metadata inside Java source code. There is no need to duplicate Java class and method names in an external file. Compilers can more easily check structure of annotations, and IDEs can offer and even higher level of validation. Hence, misspellings and other usage mistakes can be easily caught. Embedding metadata in Java source code is no longer the "hack" XDoclet used to be. The following listing shows a transactional method example in EJB3 annotations.

@Stateless
public class MyBean implements MyInterface {

  @TransactionAttribute(
    TransactionAttributeType.REQUIRED)
  public void myBusinessMethod () {
    // ... database operations...
  }

  // ... ...
}
        

Java EE 5.0 and EJB3 specifications define standard Java annotations you can use in any Java EE application servers. That essentially makes annotations a part of the standard Java API, just like API classes and methods. In this book, we will focus heavily on the annotation API of EJB3.

As we mentioned, a core architectural design pattern in J2EE is Inversion of Control (IoC), which allows developers to write loosely coupled components. However, in J2EE 1.4, the implementation of IoC is based on "dependency lookup". For instance, if a session bean needs to obtain an instance of a database resource, the session bean needs to explicitly lookup the database by its name via a JNDI call. The following code snippet shows how to look up a container managed DataSource object under the JNDI name "defaultDS". You can then use this object to access the server's default database.

DataSource ds;

// Boilerplate code follows ...
try {
  InitialContext ctx = new InitialContext();
  ds = (DataSource) ctx.lookup("DefaultDS");
} catch (Exception e) {
  // Handle the exception
}

// ... use ds ...
        

The dependency lookup code is boilerplate code since it is not part of your business logic and it clutters your Java business classes. In addition, the dependency lookup code assumes that JNDI is running in the container. If you decide to use another service management framework (e.g., the JBoss MicroContainer and Spring Framework), you would have to change all occurrences of the lookup code. A better solution is to use the "dependency injection" pattern to "wire" container-managed objects into each other. You simply need to declare the dependencies among objects using metadata. Again, some frameworks use verbose XML files to express dependency metadata. In Java EE 5.0 and EJB3, we use the simpler Java annotations to inject dependency objects. For instance, the following code snippet shows how to obtain a database resource object and an entity bean persistence manager object (see Chapter 4, Develop a Data Model) in an EJB3 session bean.

@Stateless
public class MyBean implements MyInterface {

  @Resource
  DataSource defaultDS;
  
  // ... use defaultDS ...
}
        

The @Resource annotation tells the container to inject a value to the defaultDS variable in the EJB 3.0 session bean. The injection happens before the variable is first used. The container decides which DataSource object to inject based on the target's variable name. In this case, the DataSource under JNDI name "defaultDS" is automatically assigned to the defaultDS variable. Notice that the container can even inject values to private field variables.

Dependency injection allows for the development of simple application components that aren't tied to their environment. It eliminates the need for cumbersome JNDI lookups or homegrown service locators to interact with other parts of the application. Not only does this greatly simplify the code in normal use, but it also allows for easy testability of the application.

Even the most powerful enterprise Java containers cannot provide all the services all applications need. In a lightweight enterprise Java framework, POJOs should not only consume container services but also offer services to other POJOs in the system. This way, we can extend container services using POJOs.

In EJB3, you can use interceptors to deliver custom services to EJB3 components. The custom services can be as rich as the regular container service. They can be delivered to the components via annotations as well. In Chapter 11, Extend Container Services, we will show how to develop your own service annotations using EJB3 interceptors.

As we discussed, EJB3 is the central piece of lightweight technology in Java EE standards. In a JBoss lightweight web application, the business logic, including transactional data persistence, are implemented in EJB3 components. An EJB3 application primarily consists of annotated POJOs and very little XML. The business logic is fully encapsulated in reusable POJO components. EJB3 applications are easy to write and maintain. The EJB3 container provides a whole slew of proven useful services for the POJO components, and it manages the lifecycle of components to enable dependency injection.

EJB3 POJO components handle the business logic but they do not interact with the web browsers. A complete web application requires a web framework to generate HTML pages, receive user input, and manage the navigation flow. The consensus among most web developers is that a Model-View-Controller (MVC) architecture is the best for web frameworks. In an MVC framework, the controller takes user input and decides which view to show next; The view renders the HTML page for the browser; The model encapsulates data captured from the web form and to be displayed on the web page.

There are many web frameworks available. We've chosen JavaServer Faces (JSF), the standard Java EE web framework . While JSF does have a leg up on the competition by being a standards-based technology, the decision to embrace JSF over the alternatives goes much deeper.

JSF is a well-designed and easy-to-use component-based web framework. This component-based development model aligns perfectly with the lightweight POJO approach we are promoting. The development model is clean and simple.

A JSF application primarily contains two types of components -- both are easy to use and conforming to the POJO philosophy.

The componentized UI and POJO data model make it easy to support JSF in IDE tools. In fact, many Java IDEs now support drag-and-drop UI designers for JSF. The JSF component model also allows third party vendors to develop and sell reusable UI component libraries. Those component libraries make it easy for server-side developers to take advantage of the latest browser technology without the need to mess with JavaScripts and such. For instance, in Chapter 13, Rich UI and AJAX, we will discuss how to use rich UI and AJAX component libraries in JSF.

The JSF request model is powerful and easy to extend. Technologies like Facelets and Seam have been developed on top of JSF, providing even richer development environments. While competing frameworks all have nice features, JSF seems to be the easiest to extend. We expect even more innovative extensions in the near future, clearly making JSF the framework of choice for most EE projects.

Of course, JSF isn't without its drawbacks. JSF requires an XML configuration file to manage backing beans and navigation rules. As we will also soon see, the integration between JSF backing beans and EJB3 beans is not entirely smooth. In addition, JSF usage from JSPs can get tricky at times. However, these problems are not entirely unique to JSF. Other frameworks exhibit similar problems. The good news is that the JSF model is advanced enough that solutions to all of the issues have been developed. We will look at those solutions in Chapter 13, Rich UI and AJAX and Chapter 14, Integrate JSF with EJB3.

In JBoss AS, the JSF implementation is provided by the Apache MyFaces project. The MyFaces project not only provides a standard-compliant JSF implementation, but also add-on UI components and data validators (see Chapter 13, Rich UI and AJAX). In addition, the Oracle ADF Faces, recently donated to Apache as an Open Source project, provides a large set of high performance rich UI components for free.

As we mentioned in the previous section, one JSF shortcoming is that its integration with EJB3 is not entirely smooth. On the programming model level, JSF components are configured over XML while EJB3 components are configured with annotation. On the integration level, the JSF backing beans and EJB3 components must have different Java classes, and that could force unnecessary tiers in the application.

The JBoss Seam framework aims to resolve those inconsistencies and support the EJB3-style programming model in the entire application. Under Seam, EJB3 beans can be JSF backing beans themselves. All components in JSF and EJB3 can now cross-reference each other under a unified set of annotations and Expression Language (EL). XML files are only used for defining processes, such as page flows or long running business processes.

Seam is beyond a simple bridge between JSF and EJB3. It makes innovative use of EJB3 stateful components and is inherently a stateful framework. It manages application states from short conversations (lasting several minutes) to long running business processes (lasting months) across several users. Because state management is built into the most basic Seam components, Seam applications can support isolated application states in each browser window (or tab). The browser "back" button also works robustly in Seam.

While Seam enables JSF and EJB3 standards to work better together, Seam itself is not yet a Java standard. At the time of this writing, the JCP is considering adopting a Seam-like contextual component model for a future Java EE specification,. In this book, we develop most of our example applications in plain JSF and EJB3 without Seam. In Chapter 14, Integrate JSF with EJB3 and Chapter 15, Integrate Business Processes, we will introduce Seam and show you how Seam further simplifies web application development.