1.3 Where Does JSF Fit in the Big Picture?

JSF may not be a good fit for all web applications. If you develop a web site where the dynamic aspects are limited to things like pulling content from a database, generating dynamic navigation menus, adding dynamic "cookie trails" to the pages, and other features that just make it easier to maintain the site content and simplify access to different parts of the site, JSF may be overkill. The best fit for JSF is a true web application—a web site with a lot of user interaction—rather than a web site with some dynamic content. A simple dynamic web site is probably easier to implement and maintain using only servlets and JSP, or even just JSP and the JSP Standard Tag Library (JSTL).

JSF does not necessarily replace current technologies. It's a complement that brings structure and maintainability to the application user interface. The following sections describe how JSF fits with some established Java web application technologies.

1.3.1 Using JSF with JSP

As you have already seen, JSF plays nicely with JSP. In fact, all JSF implementations must support JSP and provide tag libraries with custom actions for representing the standard JSF UI components in JSP pages. If you're familiar with JSP, adding JSF to the mix is fairly simple. While you can use JSP to develop complete, simple applications without writing a single line of Java code, be aware that most JSF applications require event handlers and backend logic implemented as Java classes; hence, you must have a Java programmer handy when you use JSF.

1.3.2 Using JSF with Struts and Other Application Frameworks

You may have noticed that I refer to Struts and similar frameworks as application frameworks, and to JSF as a user interface framework. I do this to emphasize that they have different objectives. An application framework's objective is to support the development of complete applications; it's concerned with the Big Picture. This type of framework acts as a traffic cop, routing HTTP requests to request handling code and internal view requests to response rendering code based on mappings between symbolic names and the different types of application components. An application framework doesn't care about details, such as how the user interface is rendered, or make any distinction between user actions that only affect the user interface (e.g., asking for the next set of rows to be displayed in a table) and actions that need to be processed by backend code (e.g., processing an order on an e-commerce site). Struts, for instance, can use JSP, Velocity, XSLT, or any other presentation layer technology to render a response. The Struts servlet just routes requests to application classes that process them and then tell Struts which page to display next.

A user interface framework, on the other hand, focuses on the user interface details and isn't concerned with how the rest of the application is implemented. It defines a detailed API for user interface components, for how user actions result in user interface events and how these events are handled, how the components are tied to the business data they visualize, and so on.

With these differences in mind, it should come as no surprise that it's possible to use JSF with an application framework like Struts. Basically, all requests are processed by JSF until it's clear that backend code needs to be invoked. The control is then passed on to Struts, and eventually comes back to JSF for rendering of the response.

There's some overlap between Struts and JSF, though. Both define mechanisms for page navigation and validation, for instance, but they are so flexible that you can pick and choose which should be in charge of these tasks. The JSF custom tag libraries also make some of the Struts counterparts obsolete, but the Struts Action and model classes can be used without any modification in most cases.

Another class of application frameworks includes component-based presentation layers that are very similar to JSF. Examples include the Barracuda/XMLC and Tapestry open source products, as well as a number of commercial products. These frameworks can be modified to support JSF components in such a way that it would be almost transparent to the applications built on top of them. This will likely happen for most commercial products and possibly for the open source products if there's enough interest.

1.3.3 Using JSF with Enterprise JavaBeans

Enterprise JavaBeans and other J2EE technologies are often employed in complex web applications to support different types or clients (e.g., HTML browsers, WML browsers, and standalone GUI applications) with tight security and transaction handling requirements. These technologies are used to implement the backend code and are not directly tied to the user interface code. As a result, you can use JSF safely with these technologies.