As most Java developers will know, there are many web frameworks available to the Java developer. But why Seam? Before we discuss what exactly is Seam and what makes Seam a different framework, let's take a very brief look at the history of the earlier web frameworks.

With the increased popularity of the Model-View-Controller (MVC) pattern and frameworks such as Struts, Java web development suddenly got a whole lot easier. With de facto standard frameworks, developers were able to concentrate on their application logic rather than think about the plumbing of how to develop scalable database-driven web applications. However, with these frameworks, developers still had to think about HTTP requests and responses, and developing effective web-based user interfaces implied writing HTML code.

The next evolutionary stage in web development came in 2004 when the Java Server Faces (JSF) technology was created. JSF uses a component-based approach to web development, unlike previous frameworks such as Struts. This component-based approach opened up the market for drag-and-drop style development environments. If a developer wanted to have a table of results shown on a web page backed by database queries, this could be achieved using drag-and-drop and minimal coding effort. If, for example, the developer wanted to change the user interface to allow the table of results to have clickable column headings, this could typically be achieved by setting a few properties within the IDE rather than having to write lots of Java code and HTML. Oracle's JDeveloper and Sun's Java Studio Creator, amongst others, offered GUI builders for web applications—the type of technology previously found only in GUI designers for desktop applications. All of the modern IDEs (Eclipse, NetBeans, and IntelliJ IDEA) now support this type of drag-and-drop support for JSF development. Examples of such a type of support in Eclipse (using JBoss Tools) and NetBeans 6.1 are shown in the following screenshots.

We've now seen how JSF came to be, and how web development used to be tricky and cumbersome, but how does Seam fit into this web development landscape? What is Seam, and why is it different? In simple terms, Seam is a web framework that makes developing web applications simpler. Because they have become standard with Java EE 5, Seam makes extensive use of annotations to help us achieve this goal. All of the annotations used within Seam applications take common-sense defaults with the aim of cutting down on the amount of configuration required by annotations. This use of default values is called configuration by exception. In most cases, the default values for annotations are correct and applicable to the task at hand, meaning that less configuration data has to be entered into the application code. Of course, it is still possible (and necessary) to change configuration values and add parameters into annotations. But in most cases, configuration by exception helps cut down on the amount of configuration required.

The use of annotations in Seam does not completely remove the need for XML configuration. However, it is greatly reduced when compared to other frameworks such as Spring, Struts, or JSF. With the exception of defining page flows in XML files, Seam rarely uses XML configuration. The XML configuration in these cases is generally very similar among applications, and is not considered a large part of application development.

With the Java EE 5 framework, Dependency Injection has become a standard feature of enterprise application development. Within Java EE 5, Dependency Injection allows components to be automatically set within classes without the need for the developer to call any setter methods. For example, Session Beans can automatically be looked up using the @EJB annotation, or the Entity Manager Factory can be set using the @PersistenceUnit annotation. Seam extends the Dependency Injection capabilities provided by Java EE 5 and allows Seam components to be both injected into and outjected from other components. This facility to perform both Dependency Injection and Dependency Outjection is more commonly called Dependency Bijection, and will be discussed fully in Chapter 2.

The Seam Framework is a stateful framework. Seam components can be declared to have different contextual scopes. These scopes range from stateless (having no state) through to long running scope or application lifetime scope. Frameworks such as Spring and Struts are stateless frameworks in the sense that they do not offer facilities to define scope for components. All of these frameworks allow components to be cached using various caching strategies, but Seam component scope further allows different components to be declared with different levels of scope. This is discussed in depth later in this book.

Seam components are used to define entities and classes that manage entities within an application. Seam does not impose any design patterns on components. We do not need to extend Seam classes or implement Seam interfaces to define Seam components. A Seam component can be any POJO (Plain Old Java Object). In this book, however, we will use Session Beans (both stateless and stateful) as Seam components. This will be useful because of the benefits (security, transactions, pooling, and so on) that Session Beans provide us. With Seam we don't have to use Session Beans as Seam components. A Seam component can be just as easily declared a POJO as can it be declared a Session Bean.

Seam is supplied with, and fully integrates with, the RichFaces component library. RichFaces provides many user interface components, and is described fully in Chapter 6.

JSF didn't really take off as a development model until it became the standard web framework used within Java EE 5 applications. The first versions of Seam used JSF with JSP as the view technology, but this is no longer the view technology recommended by JBoss, and has been superseded by Facelets. Seam also allows other view technologies, such as Flex, GWT, and Wicket, to be used. However, these technologies are not covered in this book. JSF or JSP can still be successfully used as the view technology for Seam applications, and we will be using them in the next few chapters of this book, to learn the basics of Seam. We will discuss Facelets in Chapter 4, when we have a good understanding of Seam, and will see what it offers that JSF does not.

Over the past few years, agile techniques have turned favorable, including Test Driven Development and Unit Testing. Traditionally, testing web applications has been a fairly complex task. However, Seam provides a simple yet effective mechanism for unit testing that includes not only testing our application logic, but also testing the user interface logic. In Chapter 5, we will detail how we can successfully test our Seam applications and provide good test coverage by using the TestNG test tool.

So far, we have discussed Seam as though it were only a web framework. Seam promises to be much more than that. At the beginning of this chapter, we learned that Seam helps bridge the gap between server-side programming and web programming. Well, what exactly does this mean?

In traditional J2EE, Java EE 5 web applications, database tables are typically modeled as either Entity Beans or Entities with Persistence. The typical flow of events in a database-driven web application would be:

This technique of detaching objects and displaying "dumb" data works quite well for small domain models that don't have many relationships between objects. However, when there are complex relationships, the web client cannot always access the entire domain model, as only certain aspects of the model have been serialized to the client. This can lead to lazy initialization errors, where clients try to access parts of our data model that have yet to be initialized from the database. Seam alleviates this problem by allowing Java EE 5 Persistent Entities to be used within the web tier. In Java EE 5, Persistent Entities are simple POJOs. Hence, full access to an applications domain model is available on the web tier within Seam applications.

Seam provides the Hibernate Validator classes as a part of the framework, and these provide an additional level of entity validation over what the Java EE framework provides as standard. We can therefore validate our entity properties easily in the user interface, to ensure that invalid values are not entered into our domain model.

We will discuss database persistence in depth in Chapter 7.

More often than not, web applications require users to traverse through several pages before completing a given action. Consider, for example, applying for motor insurance. As users of motor insurance web sites, we have to enter our name, address, the use of our motor vehicle, the type of insurance required, and so on, before we can finally get a quote for insurance. Typically, this type of procedure is mapped out as a series of web pages with the Previous and the Next buttons. How many times have you accidentally closed the browser in the middle of applying for or buying something on the Internet? How many times have you pressed the Back button and lost all of the submitted data that you had just entered? Seam provides the solution to these problems in terms of conversations, which we'll discuss in Chapter 8. These conversations can be anything from a simple one-page request/response conversation through to a multipage conversation that lasts several hours or longer!

A conversation is an example of how Seam works as a stateful framework, with a conversation being one of the different levels of component scope.

With the advent of modern web applications and AJAX, users expect a higher level of interactivity within their web applications. The distinction between desktop applications and web applications is becoming increasingly blurry. Manually crafting JavaScript code can be time-consuming and prone to error, and isn't always the best way to add AJAX functionality to an application. The Seam Framework provides AJAX support via tight integration, with the AJAX4JSF library helping to alleviate the issues with writing the JavaScript code manually. We will discuss AJAX4JSF support in Chapter 9.

Most applications need some sort of security access to restrict application functionality between users. Sometimes, a simple level of security access is required, whereby, only logged-on users can access certain pages—for example, so that only registered and logged-on users can post comments on a blog. Sometimes, this level of security isn't sufficient and a role-based security model is required. For example, again in a blog application, only users with the editor role would be able to edit and delete comments. You'll be pleased to know that Seam provides both user-based and role-based security mechanisms. We'll discuss these in detail in Chapter 10.

On top of all of these features that the framework provides, Seam is also supplied with a tool for rapidly generating application skeletons. The SeamGen tool allows application skeletons to be built via a series of interactive questions that are asked to the developer. Throughout the course of this book, we'll first learn how to write Seam applications without using the SeamGen tool, so that we can get a good understanding of the different parts of a Seam application and how they all fit together. Only when we have a solid understanding of what constitutes a Seam application, we'll introduce the SeamGen tool and show the benefits and performance gains that it provides.