JavaServer Faces (JSF) technology is a new user interface framework for J2EE applications. It is particularly suited, by design, for use with applications based on the MVC (Model-View-Controller) architecture. Numerous articles have introduced JSF. However, most take a highly theoretical approach that doesn't meet the challenges of real-world enterprise development. Many issues remain unsolved. For example, how does JSF fit into the overall MVC architecture? How does JSF integrate with other Java frameworks? Should business logic exist in the JSF backing beans? How do you handle security in JSF? And most importantly, how do you build a real-world Web application using JSF?
This article addresses all those issues. It shows you how to integrate JSF with other Java frameworks—specifically, the Spring Framework and Hibernate. It demonstrates how to create the JCatalog Web application, an online product catalog system. Using the JCatalog example, this article covers each phase of Web application design, including business-requirement gathering, analysis, technology selection, high-level architecture, and implementation-level design. The article discusses the advantages and disadvantages of the technologies used in JCatalog and demonstrates approaches for designing some of the application's key aspects.
This article is written for Java architects, developers already working with J2EE-based Web applications. It is not an introduction to JSF, the Spring Framework, and Hibernate. Please see Resources if you are unfamiliar with these areas.
Functional requirements of the sample application
This article's sample application, JCatalog, is a real-world Web application, realistic enough to provide the basis for a meaningful discussion of a Web application's architectural decisions. I begin by presenting JCatalog's requirements. I refer back to this section throughout the article to address the technical decisions and architecture design.
The first phase in designing a Web application is to gather the system's functional requirements. The sample application is a typical e-business application system. Users can browse a product catalog and view product details, and administrators can manage the product catalog. Enhancements—e.g., inventory management and order processing—can be added to make the application a full-blown e-business system.
Use-case analysis is used to access the sample application's functional requirements. Figure 1 is the application's use-case diagram.
A use-case diagram identifies the actors in a system and the operations they may perform. Seven use cases must be implemented in the sample application. Actor User can browse the product catalog and view product details. Once User logs in the system, she becomes actor Administrator, who can create new products, edit existing products, and delete old products.
JCatalog must meet the following business rules:
- Each product has a unique product ID
- Each product belongs to at least one category
- The product ID cannot change once created
We make the following assumptions for the application's design and implementation:
- English is the default language; no internationalization is required
- No more than 500 products exist in the catalog
- The catalog is not updated frequently
Figure 2 shows all of JCatalog's pages and the transitions among them.
The application has two groups of pages: public Internet and administration intranet. The intranet is accessible only to the users who log in the system successfully. ProductSummary is not presented to the users as a separate page. It displays in an HTML frame within the Catalog page. ProductList is a special catalog viewable only by the administrators. It contains links for creating, editing, and deleting products.
Figure 3 is a mock-up of the Catalog page. Ideally, for each page, a mock-up that details information for all the controls and the content required on the page should be included in the requirements documentation.
High-level architecture design
The next phase in designing a Web application is the high-level architecture design. It involves subdividing the application into functional components and partitioning these components into tiers. The high-level architecture design is neutral to the technologies used.
A multitiered architecture partitions the whole system into distinct functional units—client, presentation, business-logic, integration, and enterprise information system (EIS). This ensures a clean division of responsibility and makes the system more maintainable and extensible. Systems with three or more tiers prove more scalable and flexible than a client-server system, in which no business-logic middle tier exists.
The client tier is where the data model is consumed and presented. For a Web application, the client tier is normally the Web browser. The browser-based thin client does not contain presentation logic; it relies on the presentation tier.
The presentation tier exposes the business-logic tier services to the users. It knows how to process a client request, how to interact with the business-logic tier, and how to select the next view to display.
The business-logic tier contains an application's business objects and business services. It receives requests from the presentation tier, processes the business logic based on the requests, and mediates access to the EIS tier's resources. Business-logic tier components benefit most from system-level services such as security management, transaction management, and resource management.
The integration tier is the bridge between the business-logic tier and the EIS tier. It encapsulates the logic to interact with the EIS tier. Sometimes, the combination of the integration tier and the business-logic tier is referred to as the middle tier.
Application data persists in the EIS tier. It contains relational databases, object-oriented databases, and legacy systems.
JCatalog's architecture design
Figure 4 shows JCatalog's high-level architecture design and how it fits into the multitiered architecture.
The application uses a multitiered nondistributed architecture. Figure 4 shows us the partitioning of the application tiers and the technologies chosen for each tier. It also serves as the sample application's deployment diagram. For a collocated architecture, the presentation, business-logic, and integration tiers are physically located in the same Web container. Well-defined interfaces isolate each tier's responsibility. The collocated architecture makes the application simple and scalable.
For the presentation tier, experience shows that the best practice is to choose an existing, proven Web application framework rather than designing and building a custom framework. We have several Web application frameworks to choose from, e.g., Struts, WebWork, and JSF. We use JSF for JCatalog.
Either EJB (Enterprise JavaBeans) or POJO (plain old Java objects) can be used to build the business-logic tier. EJB with remote interfaces is a better choice if the application is distributed. Since JCatalog is a typical Web application with no remote access required, POJO, with the help of the Spring Framework, is used to implement the business-logic tier.
The integration tier handles the data persistence with the relational database. Different approaches can be used to implement the integration tier:
- Pure JDBC (Java Database Connectivity): This is the most flexible approach; however, low-level JDBC is cumbersome to work with, and bad JDBC code does not perform well.
- Entity beans: An entity bean with container-managed persistence (CMP) is an expensive way to isolate data-access code and handle O/R (object-relational) mapping data persistence. It is an application-server-centric approach. An entity bean does not tie the application to a particular type of database, but does tie the application to the EJB container.
- O/R mapping framework: An O/R mapping framework takes an object-centric approach to implementing data persistence. An object-centric application is easy to develop and highly portable. Several frameworks exist under this domain—JDO (Java Data Objects), Hibernate, TopLink, and CocoBase are a few examples. We use Hibernate in the sample application.
Now let's discuss the design issues associated with each application tier. Since JSF is a relatively new technology, I emphasize its use.
Presentation tier and JavaServer Faces
The presentation tier collects user input, presents data, controls page navigation, and delegates user input to the business-logic tier. The presentation tier can also validate user input and maintain the application's session state. In the following sections, I discuss the presentation tier's design considerations and patterns, and the reason I chose JSF to implement JCatalog's presentation tier.
MVC is the Java-BluePrints-recommended architectural design pattern for interactive applications. MVC separates design concerns, thereby decreasing code duplication, centralizing control, and making the application more extensible. MVC also helps developers with different skill sets focus on their core skills and collaborate through clearly defined interfaces. MVC is the architectural design pattern for the presentation tier.
JSF is a server-side user interface component framework for Java-based Web applications. JSF contains an API for representing UI components and managing their state; handling events, server-side validation, and data conversion; defining page navigation; supporting internationalization and accessibility; and providing extensibility for all these features. It also contains two JSP (JavaServer Pages) custom tag libraries for expressing UI components within a JSP page and for wiring components to server-side objects.
JSF and MVC
JSF fits well with the MVC-based presentation-tier architecture. It offers a clean separation between behavior and presentation. It leverages familiar UI-component and Web-tier concepts without limiting you to a particular scripting technology or markup language.
JSF backing beans are the model layer (more about backing beans in a later section). They also contain actions, which are an extension of the controller layer and delegate the user request to the business-logic tier. Please note, from the perspective of the overall application architecture, the business-logic tier can also be referred to as the model layer. JSP pages with JSF custom tags are the view layer. The Faces Servlet provides the controller's functionality.
JSF is not just another Web framework. The following features differentiate JSF from other Web frameworks:
- Swing-like object-oriented Web application development: The server-side stateful UI component model with event listeners and handlers initiates object-oriented Web application development.
- Backing-bean management: Backing beans are JavaBeans components associated with UI components used in a page. Backing-bean management separates the definition of UI component objects from objects that perform application-specific processing and hold data. JSF implementation stores and manages these backing-bean instances in the proper scope.
- Extensible UI component model: JSF UI components are configurable, reusable elements that compose the user interfaces of JSF applications. You can extend the standard UI component and develop a more complex component, e.g., menu bar and tree component.
- Flexible rendering model: A renderer separates a UI component's functionality and view. Multiple renderers can be created and used to define different appearances of the same component for the same client or for different clients.
- Extensible conversion and validation model: Based on the standard converters and validators, you can develop customized converters and validators, which provide better model protection.
Despite its strength, JSF is not mature at its current stage. The components, converters, and validators that ship with JSF are basic. And the per-component validation model cannot handle many-to-many validation between components and validators. In addition, JSF custom tags cannot integrate with JSTL (JSP Standard Tag Library) seamlessly.
In the following sections, I discuss several key aspects and design decisions I made when implementing JCatalog with JSF. I start with a discussion of the definition and use of managed beans and backing beans in JSF. Then, I present how to handle security, pagination, caching, file upload, validation, and error-message customization in JSF.
Managed bean, backing bean, view object, and domain object model
JSF introduces two new terms: managed bean and backing bean. JSF provides a strong managed-bean facility. JavaBean objects managed by a JSF implementation are called managed beans. A managed bean describes how a bean is created and managed. It has nothing to do with the bean's functionalities.