Web sites were originally static. Later dynamic content came about through CGI scripts paving the way for the first true Web applications. Since HTTP was entirely stateless, it became necessary to invent ways for requests to be linked together in a sequence. At first state was added to the URLs, but later the cookie concept came into being. By giving each user a special token, the server could maintain a context for each user, the HTTP session where the application can store state. As simple as it is, the HTTP session defines the entire concept of what a Web application is today.

The benefits of the HTTP session are clear, but we don't often stop to think about the drawbacks. When we use the HTTP session in a Web application, we store the sum total of the state of the user's interaction with the application in one place. This means that unless we jump through some seriously complex hoops, the user can only interact with an application in one way at a time.

Consider an application that manages a set of paged search results stored in the HTTP session. If the user were to start a new search in a new window, the new search would overwrite any previous session-scoped results. That's painful enough, but multitasking users aren't the only way session-scoped data causes Web applications to explode.

Consider our friend the back button, the mortal enemy of nearly every Web developer. When a user goes backwards in time to a previous page and presses a button, that application invocation expects to be associated with an HTTP session state that may have subsequently changed. When your application only has one context to store state, there's little hope of creating anything but the fragile Web applications that we all struggle with.

Most applications deal with this by adding state to the URLs, either going back to manually putting state information in the URLs or by adding a cookie-like token in the URL to point to a finer-grained context than the HTTP session. This can force the developer to pay a lot of attention to state management, often spending more time on it than on writing the actual application.

JBoss Seam
This article introduces JBoss Seam, a framework for managing contextual components. You'll see how Seam can manage state information in a Web application, overcoming the fundamental limitations of the HTTP session and enabling entirely new contexts that dramatically extend the capabilities of Web applications. It does all of this while simplifying your Web application development and reducing the amount of code (and XML) you have to write.

Seam is a framework for managing contextual components. What does that mean? Let's first look at a component. They go by many names: JavaBeans, POJOs, Enterprise JavaBeans. They're Java classes that provide some type of function to your application. A Java EE application might have many kinds of components: JSF backing beans creating the Web tier, entity beans providing persistence, and session beans providing business logic. To Seam, they're all components. Seam unifies these diverse component models, letting you think of them all as simply application components.

A Quick Example
The best way to see what Seam can do is to look at some examples. These examples are derived from the Seam DVD Store application. You can see the complete application in the examples directory of the Seam distribution. We'll start with a simple EJB3 entity bean for a product.

@Entity
@Name("product")
public class Product
    implements Serializable
{
     long id;
     String title;
     String description;
     float price;

     @Id @GeneratedValue(strategy=AUTO)
     public long getId() {
       return id;
     }
     public void setId(long id) {
       this.id = id;
     }

     public String getTitle() {
       return title;
     }
     public void setTitle(String title) {
       this.title = title;
     }

     // more getters and setters.
}

This is an EJB3 entity bean, a POJO with a couple of annotations. The only thing that stands out here is the @Name annotation, which marks it as a Seam component named product. We'll see later how this affects things. For now let's move on to an application component that displays a list of all the products in the system.

@Stateful
@Name("search")
@Interceptors(SeamInterceptor.class)
public class SearchAction
     implements Search
{
     @PersistenceContext(type=EXTENDED)
     private EntityManager em;

     @Out
     private List<Product> products;

     @Factory("products")
     public void loadProducts()
     {
       products = em.createQuery("from Product p")
       .getResultList();
     }
}

This is a stateful EJB3 session bean. We've marked it as a Seam component using the @Name annotation and brought in Seam functionality with the SeamInterceptor. Ignoring the remaining Seam annotations for a moment, what we have here is a simple component that keeps track of a list of Product objects.

The loadProducts() method uses the EJB3 persistence API to load that list of products. It makes use of EJB3 dependency injection to receive an EntityManager instance from the container so that it can load the the products into the product list.

The goal of this component is to provide this list of products to the UI. The @Out annotation on the product list does this. @Out marks the list as data to be shared out to the UI.

Let's jump forward to the view. This is part of the Facelets XHTML template, but for our purposes you can think of it as a JSP file that uses the JavaServer Faces tag libraries. The dataTable tag renders the list of items in table form using the three column definitions: title, description, and price.

<h:dataTable value="#{products}" var="prod">
   <h:column>
     <f:facet name="header">title</f:facet>
     #{prod.title}
   </h:column>
   <h:column>
     <f:facet name="header">description</f:facet>
     #{prod.description}
   </h:column>
   <h:column>
     <f:facet name="header">price</f:facet>
     #{prod.price}
   </h:column>
</h:dataTable>

The search component provides the products value for the table to the view, but how does the value get populated in the view? The @Factory annotation on the loadProducts() method tells Seam that if a view needs a products value, the loadProducts() method can be used as a factory method to load the products from the database.

There's something else happening here. SearchAction is a stateful session bean, and the product's value is just part of its state. Stateful components have a lifecycle. They have to be created, kept around, and eventually destroyed. In Seam, stateful components have the lifecycle of their surrounding context. If a stateful component were session-scoped, for example, it would be stored in the HTTP session and destroyed when the HTTP session is destroyed, unless it reaches its natural end of life sooner.

We mentioned earlier that Seam has several more interesting contexts than just simple session-scoped data. Stateful components, by default, have conversational scope. A conversation is a sequence of clicks within a Web application. You can think of it as an actual conversation with part of the application. You interact with one part of the application for a few clicks and say good-bye, maybe moving on to some other part of the application.