Considerations When Choosing an MVC Framework

While Spring provides its own Web MVC framework, several reasons might force you to use a different web application framework. For example, your team might have an existing investment in another framework. We believe the learning curve for Spring Web MVC is less steep than some of the other frameworks, partly because it reuses Spring's Dependency Injection features. However, adopting a new framework will always have a cost. Alternatively, you might be working on an existing application, built with a particular MVC framework. Often when doing an overhaul of such an application, there's no time to refactor each and every layer. Bottlenecks and problems more often than not occur in the backend, and when you're choosing Spring to facilitate refactoring, it may be prudent to keep the MVC layer in place and integrate it with a newly created Spring-based backend. With respect to JSF: This relatively new technology uses an entirely different approach and resembles ASP.NET in many respects.

Comparing the Traditional Web MVC Frameworks

In Chapter 12, we discussed the requirements of a successful MVC framework. Key values we identified included non-intrusiveness, flexibility, testability, and being agnostic with respect to view technologies. It's important to consider how frameworks meet these requirements in the following areas:

Form submission is vital to most web applications. Data from a form on an HTML page, posted by the user, is accessible via the HttpServletRequest. Most MVC frameworks allow for transformation of the parameters in the request to a Java object (where, for example, postForm.html?name=Spring will result in a setName("Spring") calls on a preconfigured form object). The process of doing so is called data binding. To what extent data binding is supported and whether or not transformation of primitives to objects is implemented by the framework of your choice will significantly influence the way you will be working with it and how efficiently you can build pages containing forms.
Validation is done by every framework we discuss here. It's important to know how the framework you're choosing implements validation. Ideally, the validation mechanism shouldn't be tied to the Servlet API; validation of domain objects can just as well be part of the service layer. If the validation mechanism is tied to the Servlet API, you can't move it to a Servlet-independent service layer.
In many projects — especially for large projects — specialist HTML developers create the layout of the website and even individual pages. Some HTML developers will know JSP; some will know only Velocity or XSLT; many lack programming skills altogether, yet have valuable knowledge of HTML layout issues. In some projects, it might be necessary to create Excel files or PDF documents. Those documents are just as much views as HTML pages are. Thus it's important not only to design for a clean separation between Java code and presentation elements, but for a web application framework to support more than one view technology, ideally in a fully transparent fashion independent of how your controllers will be delivering the actual input for the view. In other words, typically a framework that best supports the Model-View-Controller patterns is preferred.
Controllers are the components handling the user's actions. Two things are important about the way a framework supports controllers:
- To what level the controllers can be tested in isolation. Controllers are excellent candidates for being unit-tested; some frameworks, however, don't allow this because it's not possible to use the controllers without the framework itself.
- Web applications often include some aspect-oriented behavior, which you don't want to embed in each and every controller. Using web interceptors, you can separate those things from your controllers. If your framework supports interceptors, you will see that it increases the efficiency of the development of your web application.

The following sections discuss four of the most popular MVC frameworks — WebWork, Struts, Spring MVC, and JSF — in the context of these criteria.

Struts is one of the older MVC frameworks. It has been available since late 2000 and has been the de facto standard for building Web MVC applications since 2002. Struts is hosted by Apache and can be found at http://struts.apache.org. As of January 2005, the current Struts 1.2.x series can be considered relatively stable and not likely to change significantly. Work on Struts 2.0, codenamed "Shale," has been announced. This line of the codebase is still very much in the preliminary planning stages, and not much is known about it other than the fact that it will probably not be backward compatible with Struts1.x, but rather will be primarily a layer meant to handle workflow around base UI handled by JSF.

WebWork is hosted by Open Symphony. Version 2 is based on XWork, a library implementing the command pattern. WebWork actions (controllers) are not tied to the Servlet API, greatly increasing testability. WebWork is a relative newcomer but widely considered to be one of the better alternatives to Struts. WebWork can be found at www.opensymphony.com/webwork.

Tapestry is an Apache Jakarta project. Like JSF, Tapestry uses a more component-oriented, event-driven approach than Spring MVC, Struts, or WebWork, and works at a higher level of abstraction in terms of mapping web UI elements to Java code. While Tapestry is not as well known as Struts or perhaps even Spring MVC, it can be considered mature, and is in use in a number of production applications. As of January 2005, Tapestry 3.0 is the current version, with work on the next major release, to be called 3.1 or4.0, at a relatively advanced stage. Tapestry can be found at http://jakarta.apache.org/tapestry.

JSF is an emerging technology based on specification by Sun. Compared to Spring MVC, Struts, and WebWork, it has a more component-oriented, event-driven approach and a much higher level of abstraction. While a promising technology, there are some drawbacks, including its immaturity, which we'll discuss later in this chapter. JSF is a specification, with potentially multiple implementations. The best known are the Reference Implementation created as part of the specification process, and MyFaces, available at www.myfaces.org.

Data Binding and Validation

Editing data is an often seen use case in web applications. All of the frameworks under discussion offer their own way of binding request parameters to objects created on the server. To what extent each framework facilitates data binding is covered in this section.

WebWork

WebWork has advanced features for working with request parameters and binding:

WebWork can bind form data to objects in one of two ways: in a completely command-oriented fashion, where the action (controller) represents both the data as well as the behavior (it implements the GoF command pattern). You also have the option to use a ModelDriven action, which binds data to a separate object (for example your domain model, implemented as Hibernate objects).
WebWork uses OGNL to convert primitives to objects (for example '2004-10-12' to a java.util.Date object). Predefined converters are available, and implementing your own converter for a custom type is not difficult. Although OGNL is not a standard of any sort, it's easy to learn and has the same characteristics as, for example, the Expression Language from JSP 2.0. However, compared to the latter, it's generally more advanced, with less limitations, and as such more usable in practice. Conversion errors are treated in a consistent manner. The XWork ActionContext contains a conversionErrors map, and using a ConversionErrorFieldValidator you can display errors to the user. Customization of the error messages is possible using i18n.
Validation can be done in one of two ways: either by implementing your own validate() method where you programmatically validate the input of a user, or by using XWork's more sophisticated validation framework. The latter allows for validation contexts with which you can validate a certain object in different ways, depending on the context you've specified. This is an advanced feature that will help in more complex applications. The XWork validation framework is partly configured in XML.

Struts

Struts uses ActionForms to implement data binding. It integrates tightly with the Commons Validator, which offers you advanced XML-based validation.

Data binding with Struts is done using ActionForms. For every form, you have to extend the concrete ActionForm class, which prevents you from reusing your domain model and working with it directly in your HTML forms. This requirement is widely considered to be one of the major design flaws in Struts. After the form data is transported to an ActionForm object, you have to extract it yourself and modify your domain model accordingly — an extra step that isn't required by WebWork and Spring. Dynamic forms (introduced in Struts 1.1) make the whole data binding process less painful, but you still have to extend a concrete class.
Struts ActionForms are supposed to be JavaBeans to convert expressions to setters and getters. They use almost the same expression language as Spring does: user.name, for example, will result in getUser().setName("value"). Indexed properties, however, are treated differently: user[2] will result in getUser(2), setUser(2, "value") respectively.
Transformation of user input to objects other than primitives or Strings is not supported by Struts. Even though Struts allows you to parse integers and such, when parsing fails, there is no standard mechanism for informing the user about parsing errors. Although Transformation of objects other than Strings or primitives can be done in the transformation code you have to implement anyway (because of the ActionForm), it's still a major shortcoming. Struts does have support for binding files to ActionForms (as FormFile objects), which means uploading files is easy.
Validation in Struts is done using Commons Validator (http://jakarta.apache.org/commons/validator), an XML-based declarative approach to validating ActionForms. Commons Validator is the most mature validation framework available in the open source community. This, however, tells us more about the state of validation in general than about the quality of the Commons Validator. We feel that configuring the Commons Validator with the XML format provided is awkward and unintuitive.

Spring MVC

Spring's data binding and validation is quite similar to WebWork's features. Furthermore, Spring has a pluggable validation mechanism, based on the Spring Validator interface.

Data binding in Spring is done in a similar fashion as WebWork. Spring has a wide variety of controllers and supports the WebWork command-oriented way of development as well. Indexed properties are supported (so you will be able to bind a list of objects to your domain model), as are nested properties. Just as with WebWork, with Spring it's possible to reuse your domain model in your entire application and seamlessly bind user input to it.
Transformation of user input to objects (note the previous example: transforming 2004-10-12 to an appropriate java.util.Date object) is supported via the use of the PropertyEditor infrastructure from the JavaBeans standard. There are a lot of property editors available with the Spring distribution, and building your own custom property editors is easy enough. As opposed to Struts, conversion errors are handled in a consistent, easy manner.
Conversion errors that occur during the transformation of properties are treated in a consistent manner. The DataBinder treats them as any other validation errors, adding error messages to the Errors class. Standard i18n keys are provided, which you can easily customize. Think of a NumberFormatException thrown after parsing a number or some other exception being thrown if the invocation of a setter failed or in case the setter simply didn't exist (the DataBinder JavaDocs explain all this in more detail).
Validation in Spring is done using the org.springframework.validation.Validator interface. Spring does not provide a concrete validation implementation. There are, however, utility classes available to do programmatic validation (org.springframework.validation.ValidationUtils). The community has already implemented validator classes that integrate with Commons Validator. A rule-based validation framework is also on its way.

Tapestry

Tapestry also provides sophisticated data binding support.

Tapestry data binding works at a relatively high level of abstraction, handled at the component level. In its simplest form, a component such as a TextField, in the page template, will specify an OGNL expression that is the binding path for the data. This may be a relatively simple, nested JavaBean access, but also include arbitrary method calls as also allowed by OGNL. The binding path is also the path used to obtain the data for display when the page is output.
Conversion of types is usually handled by the component itself. For example, the DatePicker component produces a drop-down calendar on the web page and will transparently handle binding the result of the user selection to a java.util.Date property as specified via a property path. There are components for most HTML elements, for example checkboxes (the latter component binding to a Boolean property). There is no built-in mechanism (such as Spring MVC's registration of PropertyEditors) to handle binding text fields to arbitrary user-specific types. Because OGNL allows arbitrary method calls, it is fairly simple for this use case to call custom setter methods that perform conversion, although at the disadvantage of being able to transparently use existing domain objects.
Validation is handled by using validator objects of type IValidator. For each page component that needs to be validated, another component of type ValidField is defined and essentially exists to associate the page component with a particular validator instance, and to handle rendering. A related object with page scope, called a Validation Delegate, coordinates all the validation for the entire page. Validator exists for common types, such as Strings, Numbers, Email addresses, and Dates. They can check for common validity aspects such as input not being empty or null, the minimum size, and so on, and also aspects specific to the type, as in the case of the email validator, which checks whether the input is a valid email address or not. Additionally, there is a regex validator which will validate based on a regular expression pattern. Client-side JavaScript validation code can be set to be automatically generated. If used, it will work in addition to the server-side code. Server-side validation errors get collected by the Validation Delegate, to be displayed in a consistent fashion.
There is no concept of a pluggable validation object such as Spring's Validator, meant to validate the content of the entire page or a domain object backing the page, although it's easy to add additional custom Java code to a page lifecycle method to do additional validation, which can combine any errors with those produced by field level validation.

JavaServer Faces

JSF takes a different approach to binding data. With JavaServer Faces, binding can be done to a JSF-managed bean (sometimes also called code-behind file — similar to the ASP.NET code-behind page). A slightly modified version of the JSTL Expression Language is used. Instead of writing${user.name} with the JSF Expression Language (JSF EL), you will have to write #{user.name} where user has to be a JSF-managed bean and name represents the name property.
Conversion of types in JSF can be done by using the Converter interface. JSF delivers converters for most standard types. The Converter interface much resembles the java.beans.PropertyEditor interface. The former, however, is tailored for use within JavaServer Faces. Conversion methods can also be directly implemented in your code-behind file (backing bean).
Validation of user input is done by built-in validation support that is easily extensible by adding custom Validator implementations. This resembles Spring's validation support except for one thing: JSF positions validation before the user input is converted and bound to the (domain) model whereas Spring first binds the data and then calls any validator available. This results in Spring validators being usable in the middle tier as well, whereas JSF validators are tied to the Faces API and can be used only in the front-end (more on the JSF lifecycle can be found later in this chapter).
Display of validation and conversion errors is standardized through the FacesMessage type and the ValidatorException and ConverterException, respectively. FacesMessages are typically associated with a specific component in the view. JavaServer Faces supports internationalization of FacesMessages through the Application.getMessageBundle(String) method.

Dealing with the Presentation Layer

Spring offers tag libraries, as we discussed in Chapter 13. WebWork and Struts both offer convenient tag libraries as well. We'll also compare the frameworks based on which view technologies they integrate with.

WebWork

Support is offered for Velocity, FreeMarker, and JavaServer Pages. Of course the latter is natively supported by Servlet containers. For Velocity and FreeMarker, you will have to add a custom WebWork servlet.
Just as binding of data from forms happens using the data binding features, you can retrieve data from objects in your view templates as well. In WebWork this is done using the OGNL expression language embedded in WebWork JSP tags, similar to JSTL <c:out value="${person.name}"/> tags.

Struts

Struts offers support for JavaServer Pages only. There are, however, external libraries available for Velocity as the view technology (hosted by the Velocity project, also part of Apache), and it's possible to use a "bridge servlet" to work with other view technologies.
Struts has a rich set of tag libraries that support the retrieval and displaying of data bound in the model in all kinds of HTML widgets (select boxes, text fields, and so on). The html:XXX tags are a convenient way to limit the amount of HTML you need to type. It is, however, not a standard and chances are that HTML developers don't know how to work with those.

Spring MVC

Spring seamlessly integrates with JSP, Velocity, FreeMarker, and XSLT and it's also possible to generate document-based output in Excel or PDF format. Spring completely decouples the view from the controller, aiming for an easy transition to a different view technology if needed.
Spring features a set of tag libraries that facilitate binding of values (transformation of object to displayable String values and vice-versa, using the before mentioned property editors). In release1.2, a set of JSP tag files is available that will make it easier for you to create HTML widgets such as text fields and select boxes. All tag files and custom tags reuse and support the JSTL Expression Language. Macros for FreeMarker and Velocity are also available, resembling the custom tags. The Spring tags are fundamentally different from Struts' tags, for instance. Spring's tags are focused entirely on integration with existing presentation tier technologies such as JSTL. They do not focus on providing easy ways to render checkboxes and other widgets. That's what HTML and other tag libraries will probably do better.

Tapestry

Tapestry page templates are simply HTML source files. A Tapestry-specific jwcid attribute added to an HTML element specifies the corresponding Tapestry component to use to render that section of the web page. The component is a high-level construct, which knows how to render itself, is backed by Java code, and deals as needed with the page or other components it is embedded in. Depending on the component itself, and how much configuration information it needs, the component reference and attributes specified in the HTML page may be enough, or additional configuration information may need to be specified in a separate .page file. Components exist that correspond to most lower-level HTML elements such as input boxes or checkboxes and radio buttons, as well as higher level constructs such as a date picker.
It is very easy to construct new components, generally more so than in JSF.
Because templates are essentially plain HTML files, they may be edited in close to WISIWYG fashion in any standard HTML editor, much more so than for other view technologies such as JSP or Velocity/FreeMarker, where the markup interferes in terms of getting an idea of the final output.
Tapestry is intrinsically tied to its templating format, based on components. It is essentially impossible to access Tapestry components or pages from another view technology such as JSP or Velocity/FreeMarker, although Tapestry does include code for handing off to JSP pages or allowing JSP pages to hand off to Tapestry pages.

JavaServer Faces

JavaServer Faces includes a set of core components and render kits that facilitate the rendering of standard widgets such as text boxes and radio buttons. The implementation of those components (usable in JSP as tags) is left to the vendor providing the JSF implementation. Where Spring and WebWork do not focus on providing tags generating HTML widgets (text fields, radio buttons, and such), JSF much more resembles Struts in this respect. This is also related to the higher abstraction level JSF tries to achieve. Communication between components and how input and validation tie together is part of the technology — you don't have to implement all this yourself, whereas with the other command-oriented frameworks (but not Tapestry) you might end up doing more coding.
JavaServer Faces defaults to JavaServer Pages, but depending on the implementation of the specification, other templating technologies might be supported as well.

Controller Infrastructure and Interception Handling

Of course any MVC framework requires controllers or a similar mechanism to sit between the view layer and the business services layer. Struts, WebWork, and Spring all offer a controller hierarchy, although there are significant differences. JSF and Tapestry both take a different, more event-driven approach.

WebWork

WebWork has the most advanced interception infrastructure of these frameworks. Interceptors are fully configurable to be executed against any given set of URLs (so it's possible to apply only interceptors to all URLs with the .html extension, for example). WebWork interceptors are heavily used in the framework itself: for example, to do data binding and validation.
WebWork actions are completely decoupled from the Servlet API, which greatly increases testability. Theoretically, you could reuse your actions in a fat client as well. However, we're a little skeptical about whether it really makes sense to use the same approach for a rich client application and the heavily constrained HTTP interaction model.
The controllers are modeled as command objects, holding both the data and the behavior related to a user's action. As the command objects hold data as well, a new command object needs to be created for every request.
WebWork does not include a wide variety of prebuilt controllers that model often-used processes in web applications (displaying a form, submitting it, returning to the form because of validation errors, and so on).

Struts

Controllers in Struts are called actions. Your actions always have to extend an abstract base class. This and the fact that actions need the framework to work correctly seriously limits the possibility to test your actions in isolation. A separate project is available on SourceForge (offering the StrutsTestCase). Using this, you can test Struts Actions without a Servlet container.
Struts actions are tied to the Servlet API, just as Spring's Controller interface is (unless you're using the Spring ThrowAwayController).
Struts actions are required to be threadsafe. For each type of action, only one instance is maintained. Although it's a good practice to create threadsafe components, there might be situations where you simply cannot do without an object per request because of resource management, for example.
Struts includes a small collection of actions that facilitate trivial tasks, such as forwarding to a different page. Struts has a large user base and a big community. Many extensions are built for Struts, so for a lot of usage scenarios, actions are probably available.
Struts does not feature an interceptor mechanism. Common behavior spread over multiple actions will have to be implemented in abstract action classes or delegates that you call in every action. This increases coupling between functionality and behavior in your web application and results in higher maintenance costs (code spread over more classes, difficult to remove a specific functionality, and so on).

Spring MVC

Spring features HandlerInterceptors, which you can configure just as you configure any other component in Spring. Spring supports so-called before and after advice: You can implement custom behavior before a controller is executed (or stop the execution if you like) and after the controller has finished executing.
The most often used Spring controllers all implement the Controller interface. Spring also provides a WebWork-style controller that is created on every request. This is the ThrowAway Controller. Because the top-level types are interfaces, with Spring it's possible to implement your own controller infrastructure if you like — you don't have to extend a concrete class as with Struts.
Although most of Spring's controllers are tied to the Servlet API (unless you're using the ThrowAwayController), you can test them in complete isolation. No container is needed if you want to execute your controllers. Spring’s test classes that mock the Servlet API are a convenient way to test.
By default, there's only one instance for each controller bean. If you want, you can define the controllers to be prototype, resulting in one controller for every request.
Spring's controller infrastructure suits many common scenario's encountered in web application development. For example, there are controllers to do ordinary form workflow (displaying the form, submitting it, and so on) and to implement a wizard-like flow.
Spring's controllers are fully configurable and allow for overriding specific parts of the request flow (data binding, validation, everything can be customized or overridden). Spring controllers are largely based on the Strategy and Template Method design patterns.

Tapestry

Tapestry does not have the notion of a strongly typed Controller. Rather, components and pages are coded to respond to lifecycle callbacks and events from user interactions. The pages and components are completely Tapestry-specific, extending special interfaces, and it is generally expected that page and component code deals, for the most part, with user interface concerns, and relies on a lower-level service layer for non–UI related aspects.
It is not easy to completely unit test Tapestry 3.0 pages and components because of the complex lifecycle that they embody. Proper delegation to a service layer for non-UI concerns, together with the small amount of code needed to produce UI because of this high-level nature of Tapestry, does mean that there is relatively little UI code to test compared to some frameworks such as Struts, for equivalent functionality. Tapestry versions 3.1and 4 aim to significantly reduce the difficulty of unit testing pages.
There is no easy method to transparently intercept event and lifecycle callbacks, short of bringing in an AOP framework, or subclassing pages and components.

JavaServer Faces

JavaServer Faces does not have the notion of a strongly typed controller. Instead, any ordinary object (preferably a JavaBean) can act as a handler and has to be defined in the configuration of the application as a managed bean. JSF managed beans can be scoped (per application, session, or request). Handlers can contain conversion and validation code as well as code to save the data a user submitted (or references to service objects doing this).

As opposed to the other frameworks under discussion, JavaServer Faces has a much higher level of abstraction. When developing an application with JavaServer Faces, you don't necessarily have to know about the difference between GET and POST and the way user input is communicated using HTTP query parameters. While this may sound like an advantage, the result is a less flexible technology that might limit you in some situations. Also, to fully understand why things work the way they work, you might end up getting into some of the lower-level details anyway.

Important

"All non-trivial abstractions, to some degree, are leaky."

Joel Spolsky – www.joelonsoftware.com

Other Characteristics

Let's quickly note a few other characteristics of these frameworks, good and bad. These include nontechnical reasons that you might consider when choosing a framework.

WebWork

WebWork is built on top of XWork, a implementation of the GoF Command pattern. It allows you to create configurable command objects and use them in its web framework.
WebWork doesn't seem to have generated a lot of press yet. It still remains to be seen whether it will become a popular framework used by the masses.
Documentation for the WebWork MVC framework is not extensive and largely conceptual. Pragmatic usage of the framework is not covered in the documentation. We feel that the weak documentation of WebWork is a major gap.
WebWork is supported by Open Symphony, a healthy open source community. WebWork is also used in a number of complex, public web applications (including the Confluence Wiki product from Atlassian, which also uses Spring), so it is proven to be able to meet challenging requirements.

Struts

Struts has been available since 2000 and has been adopted by many big corporations as their preferred web application framework. Whatever the technical arguments, Struts won't go away any time soon.
Struts has a large user base and a healthy community. The mailing list generates a huge amount of traffic — sometimes over 100 emails per day.
Struts development has traditionally progressed at a slow pace, especially when compared to the Spring project. Recently, Struts announced a separate, more JSF-oriented project. The Struts1.x branch continues and will focus on providing backward-compatible releases without any major redesigns.
Because of its popularity, there are many books and other resources on Struts.
Because of its popularity, Struts has better tool support than other web application frameworks.
Struts is hosted by Apache, a healthy open source community.

Spring Web MVC

Spring Web MVC integrates seamlessly with its Inversion of Control container so you do not have to learn a new way to configure your controllers. Furthermore, it's easy to link your presentation tier to your middle tier.
Although Spring is relatively new, its Web MVC framework is already widely used in both large and small projects. The flexibility the Web MVC framework gives you has already led to a wide variety of applications, ranging from applications with a custom-built controller infrastructure to facilitate extremely high loads to rich business applications with a complex interface.
Spring is a project with a release-early-release-often philosophy. Since the 1.0 release in March 2004, two major releases have been done, as well as almost ten minor releases — including bug fixes, maintenance work, and minor enhancements.
There is an Eclipse plug-in for Spring that manages and visualizes application context files. There is also a documentation tool called BeanDoc that generates HTML reports of your contexts.
As of mid 2005, there are a significant number of books on Spring (besides this one), and more books are on the way. Spring also features an extensive reference guide, in HTML format as well as PDF. While Struts is still ahead of all other web frameworks in this area, the gap is narrowing between Struts and both Spring MVC and JSF.
Spring, as an independent project, is hosted at SourceForge and has an active mailing list, forum, and user community.

Tapestry

For developers used to a traditional command-oriented Model 2 framework such as Struts, Tapestry, because of its component-oriented nature with fairly complex lifecycles, will have a relatively steep learning curve (which it shares with JSF) for new developers, compared to the learning curve to pick up another command-oriented framework. For smaller projects where there is already a team of developers experienced in a traditional framework, the time investment may not be worth it. For larger projects, or with the expectation of ongoing work, the time investment is generally worth it.
Tapestry 3.0 applications produce URLs that are generally considered ugly. While there is a patch available that reworks the URL strategy even for Tapestry 3.0, if this is a concern it may be best to wait for Tapestry 3.1 or 4.0, which offer additional URL generation options out of the box, including a much friendlier format.
There is no high-level concept of flow between pages in Tapestry, such as afforded by Spring MVC's SimpleFormController. However, any of the frameworks mentioned in this chapter are well served by adding some sort of more powerful, higher-level, web flow framework.
Although Tapestry is more mature than JSF right now, and generally considered more usable than JSF without special tools, the fact that JSF is backed by a JCP standard probably means that JSF will become more popular than Tapestry. However, there is no sign that either will disappear. There is a Tapestry book available and a vibrant user community.

JavaServer Faces

JavaServer Faces is a relatively new technology based on the assumption that multiple vendors will provide an implementation of it. There are a couple of open source implementations available, such as Smile (http://smile.sourceforge.net) and MyFaces (http://myfaces.sourceforge.net). The Apache initiative is also starting a JSF implementation, dubbed Struts Shale.
Although JSF is a promising technology, opinions are mixed. Combined with an appropriate implementation and tool support, it should be a powerful technology. Note, however, that because of the high level of abstraction JSF tries to achieve, you might end up with a less flexible application framework. An often-heard argument is that if your primary focus is performance, you shouldn't choose JSF to serve as your MVC framework.
There are already a significant number of books published on JSF and of course you can download the specification, which provides a wealth of information as well.
Many big vendors are enthusiastic about JSF. Thus it is likely that it will benefit from excellent tool support.