Put JSF to work 2

Ii. High-level architecture design (overall architecture design)
The next step in designing a web application system is the overall architecture design. It includes dividing applications into functional components and dividing these components into several layers. The overall architecture design is neutral for specific technical use.
Multitiered architecture (multi-layer architecture)
The multi-layer architecture divides the entire system into obvious functional units: client, presentation layer, business logic, integration, and EIS. This architecture ensures a clear division of responsibilities, making the system easier to maintain and expand. A three-or multi-tier system is proven to be more flexible and scalable than a C/S system without a business logic layer.
The customer layer is where the data model is consumed and expressed. For a web application, the customer layer is usually a web browser. The browser-based thin client does not contain the representation logic. It depends on the presentation layer.
The presentation layer exposes services at the business logic layer to users. It knows how to process a client request, how to interact with the business logic layer, and how to select the next view for display.
The business logic layer contains the Business Objects and services of an application. It receives a request from the presentation layer and processes the response based on the business logic of the request. The business logic layer components greatly benefit from system-level services (such as security management, transaction management, and resource management ).
The integration layer is a bridge between the business logic layer and the EIS (Enterprise Information System) layer. It encapsulates the logic of interaction with the EIS layer. Sometimes the integration layer and the business logic layer are called the intermediate layer.
Application Data is persistent at the EIS layer. It includes relational databases, object databases, and legacy systems.
Jcatalog Architecture Design
Shows the overall architecture design of jcatalog and how it implements a multi-layer architecture.

Applications use a multi-layer non-distributed framework that shows how application layers are divided and the specific technologies used by each layer. This figure also serves as the deployment diagram of the sample application. For a configuration architecture, the presentation layer, business logic layer, and integration layer are all located in the same Web container. Well-defined interfaces isolate responsibilities of each layer. The configured architecture makes the application simple and scalable.
For the presentation layer, experience tells us that the best way is to select an existing and tested web application framework, rather than designing and building a framework by yourself. We have some Web Application Frameworks to choose from, such as struts, webwork, and JSF. We chose JSF as the presentation layer framework for jcatalog.
Both EJB and pojo can be used to build the business logic layer. If the application is distributed, EJB with remote interfaces is a good choice. Our jcatalog is a typical web application without remote access requirements. Therefore, pojo in the Spring framework is used to implement the business logic layer.
The integration layer processes data persistence in relational databases. There are different solutions for implementing the integration layer:
L pure JDBC: This is the most flexible solution. However, the underlying JDBC is very heavy, and the performance of poor JDBC code is not good.
L entity beans: CMP is an expensive solution for isolating data access code and processing o/R ing data persistence. It is an app server-centric solution. An entity bean does not make the application dependent on a database, but makes the application dependent on an EJB container.
L o/R Mapping Framework: the O/R Mapping Framework is an object-centric solution for data persistence. Object-oriented applications are easy to develop and lightweight. There are many ready-made frameworks in this field: JDO, hibernate, toplink, cocobase, and so on. We use hibernate in this application.

Now let's take a look at each layer to discuss specific design issues. Because JSF is a relatively new technology, we will focus on it.
Presentation layer and JSF
The presentation layer collects user input, indicating data, controls page navigation, and delegates user input to the business logic layer. The presentation layer can also verify the user input and maintain the application session status. Below we will discuss the design considerations and patterns of the presentation layer, and why we chose JSF to implement the presentation layer of jcatalog.
Model-View-Controller
MVC is a schema design pattern strongly recommended by the Java Blue Book for structured applications. MVC split design focus, which can reduce code overlap, centralized control, and make applications more scalable. MVC also helps developers with different skills concentrate on the skills they are good at and work together through clearly defined interfaces. MVC is the structure design mode of the presentation layer.
Assumerver faces
JSF is a server-side UI component framework developed for Java-based Web applications. JSF includes a set of APIs used to express and maintain the UI components, process events, server-side verification, and data conversion, define page navigation, and support for internationalization and accessibility; and provides scalability for these features. It also includes two jsp m tag libraryies to indicate the UI group and associated components and server objects on the JSP page. (In fact, JSF is now a standard and a set of interfaces as well as the Reference implementations provided by it. You can also implement your own JSF implementation by yourself. Of course, it is relatively difficult, if not mentioned later, "Implementation" refers to the built-in reference implementation)
JSF and MVC
JSF is very suitable for the presentation layer framework based on MVC. It clearly divides behavior and representation. It supports the concepts of the UI components and web layer that we are familiar with, but does not limit you to some scripting or Markup languages.
The backing beans of JSF are model layers (for more information about backing beans, see the following section ). They can also contain actions, which are an extension of the controller layer and proxy of user requests to the business logic layer. Note that the business logic layer is often referred to as the model layer from the perspective of the entire application framework. (Note: This is different from the model layer here.) The JSP page containing the JSF tag serves as the view layer. While faces servlet provides the controller function.
Why JSF?
JSF is not just another Web framework. below is how it differs from a general web framework:
L Object-Oriented web application development like swing: Ui component models with Event Listeners and handlers declared on the server (just like swing components ), promotes Object-Oriented web application development.
L backing-bean management: backing bean is the JavaBeans associated with the UI component on the page. Backing bean management distinguishes the definition of the UI component object from the object that maintains Data Execution application-related processing. The specific implementation of JSF stores and manages the backing-bean instances in an appropriate range.
L extensible UI Component Model: The jsf ui component that makes up a JSF application is a configurable and reusable element. You can inherit these standard UI components to develop more complex components, such as menu bar and tree components.
L flexible Presentation Model: Renderer separates the functions of the UI component from its view. Different Renderer can be created to define the different appearances of the same component of the same client or different clients. (For a brief introduction, you can define htmlrenderer and wmlrenderer to generate HTML and WML appearances for the same component .)
L scalable conversion and verification model: You can develop your converter and validator based on the standard converter and validator to provide more powerful functions.

Although JSF is powerful, it is not yet mature. The component, converter, and validator provided by JSF are very simple. In addition, each component's validation model cannot process multiple-to-Multiple Validation between components and validator. JSF labels cannot be seamlessly connected with jstl.

In the following chapter, we will discuss the key parts and design decisions for implementing jcatalog using JSF. First, let's discuss the definition and use of managed bean and backing bean in JSF. Next, we will introduce how to handle security, paging, caching, file upload, verification, and custom error information in JSF.

Managed bean, backing bean, view object, and domain object model
JSF introduces two new concepts: managed bean and backing bean. JSF provides a powerful bean management mechanism. A JavaBean object managed by JSF is called a managed bean. A managed bean describes how to create and manage a bean, which has nothing to do with bean functions.

Backing bean defines the attributes and processing logic of UI components on the page. Each backing bean attribute corresponds to the value of a component or component. Backing bean also defines a set of methods for executing component functions, such as verifying component data, processing component-triggered events, and processing navigation-related operations when the component is activate.

Every page in a typical JSF application has a backing bean. However, it is not a good practice to force the one-to-one relationship between the page and the backing bean. It causes similar code repetition issues. In reality, some pages may share the same backing bean. For example, in jcatalog, The createproduct and editproduct pages share the same productbean definition.

A view object is a model object used only in the presentation layer. It contains data that must be displayed at the view layer, including the logic for verifying user input, processing events, and interacting with the business logic layer. In JSF-based applications, backing Bean is a view object. In this article, backing beans and view objects are interchangeable concepts.
Compared with the actionform and action concepts in struts, using backing bean development in JSF is more in line with OO design habits. A backing bean contains not only the display data, but also the behaviors related to the data. In struts, actionform and Action contain data and logic.

We have heard of domain object model (domain object model ). So what is the difference between domain object model and view object? In a simple web application, a domain object model is often used across all layers. However, in a slightly complex web application, an independent view object is required. Domain object model is about the business object (BO) and should belong to the business logic layer. It contains business data and business logic associated with specific business objects. A view object contains the relevant data and behaviors. The productlistbean of jcatalog is a good example of view object. It contains the data and logic of the presentation layer, such as paging-related data and logic. One disadvantage of separating view object and domain object model is that data mapping must be performed between two object models. In jcatalog, productbeanbuidler and userbeanbuilder use the commons-beanutils package based on reflection to implement data mapping.

Security
Currently, JSF does not have built-in security features. The security requirements of the example application are very simple: only when a user wants to log on to the Administration Intranet, authentication based on the user name and password is required, and authorization is not required.
For user authentication in JSF, the following solutions are available:
L use a backing bean base class: This solution is simple, but it will make backing beans dependent on this inheritance structure. (That is, backing bean inherits this base class)
L using a JSF viewhandler packaging class: This solution will tightly limit the security logic to the special web layer technology of JSF.
L servlet filter: a jsf application is no different from other Java-based Web applications. Therefore, a filter is the best place to handle authentication checks. The security logic of this solution is not bound to a specific web application.
In the example application, the securityfilter class processes user authentication. Currently, protected resources only include three pages. Therefore, they are hardcoded into the filter class for simplicity, as an improvement, you can write specific security rules and protected resources into the configuration file.

Paging
In the application, the catalog page needs to be paged. The presentation layer can process pages, which means that all data must be obtained and stored in the presentation layer. Paging can also be processed at the business logic layer, integration layer, or even EIS layer. One assumption of jcatalog is that no more than 500 products are in the directory. All product information can be stored in the user's session. The paging logic is implemented in productlistbean. The pagination-related parameter product per page can be configured through the JSF managed-bean mechanism.

Caching
Caching is one of the most important technologies to improve the performance of Web applications. In the application framework, caching can be implemented in many layers. If a layer in the structure can avoid calling the layer below it, it is the most ideal situation (??). The JSF managed-bean mechanism makes caching in the presentation layer very easy. By changing the scope of a managed bean, data in the managed bean can be cached in different scopes.

The sample application uses two levels of caching. The caching of the first layer is in the business logic layer. The cachedcatalogserviceimpl class maintains the read/write cache for all products and directories. Spring manages this class as a singleton service bean. Therefore, the first layer of cache is an application-scopse read/write cache.

To simplify the paging logic and speed up the application, the product is also cached in the presentation layer, and the range is session scope. Each user maintains his/her own productlistbean in the session. The cost is system memory and outdated data. During the user's session, if the administrator updates the directory, the user may see outdated data. However, based on our previous assumptions, there will be no more than 500 of items in the directory, and the directory will not be updated frequently, so we can bear these costs.

File Upload
Currently, sun's JSF reference implementation does not support file upload. Struts has a good file upload function, but to use this function, the Struts-faces package is required. In jcatalog, each product has a corresponding photo. After you create a new product, you must upload the corresponding image. Images are stored in the file system of the application server, and productid is used as the image name.
The example program uses the <input type = "file">, Servlet, and Jakarta commons file-upload package to implement a simple file upload function. This solution requires two parameters: the product image directory and the Image Upload result screen. They can be configured in applicationbean. View the fileuploadservlet class for details.

Validation
The standard validator provided by JSF is very basic and cannot meet many actual requirements. Developing your own JSF validater is simple. In this example, selecteditemsrange validater is developed with custom tags. It is used to verify the number of items selected by the uiselectworkflow component:
<H: selectmanylistbox value = "#"
Id = "selectedcategoryids">
<Catalog: validateselecteditemsrange minnum = "1"/>
<F: selectitems value = "#"
Id = "categories"/>
</H: selectmanylistbox>
For more information, see the example.

Error-message customization
In JSF, you can create resource boudles for converter and validator to customize error messages. A resource bundle is created in the faces-config.xml:
<Message-bundle> catalog. View. Bundle. Messages </message-bundle>
The key-value of the error message is added to the message. propertyes file:
# Conversion error messages
Javax. Faces. component. uiinput. Conversion = input data is not in the correct type.
# Validation error messages
Javax. Faces. component. uiinput. Required = required value is missing.

Business logic layer and Spring framework
The Business Object and service are located at the business logic layer. A business object not only contains data, but also the logic related to this object. In this example, there are three business objects: product, category, and user.

Business services and business objects, and provide high-level business logic. A formal business interface should be defined. It contains a service interface that can be directly called by the client. Pojo in the Spring framework implements the business logic layer of jcatalog. Here there are two business services: catalogservice contains the business logic related to directory management; userservice contains the user management logic.

Spring is based on the concept of Reverse Control (IOC. The spring features used in the example program include:
L use application context to manage beans: spring can effectively organize and manage objects in our intermediate layer and process plumbing for us. Spring can eliminate the flood of Singleton mode and promote good OO programming habits, such as interface-oriented programming.
L declarative Transaction Management: Spring uses AOP (Aspect-Oriented Programming) to achieve declarative transaction management without using EJB containers. In this way, transaction management can be applied to any pojo. Spring's transaction management does not depend on JTA. It uses other transaction policies to work. In this example, we will use declarative Transaction Management in hibernate transactions.
L inheritance system of data access exceptions: Spring provides a meaningful exception system to replace sqlexception. To use the exception system of spring, you must define the exception translator for spring data access in the spring configuration file:
<Bean id = "jdbcexceptiontranslator" class =
"Org. springframework. JDBC. Support. sqlerrorcodesqlexceptiontranslator">
<Property name = "datasource">
<Ref bean = "datasource"/>
</Property>
</Bean>
In the example program, if a product with duplicate IDS is inserted, dataintegrityviolationexception is thrown. This exception will be caught and thrown again as duplicateproductidexception. In this way, duplicateproductidexception can be distinguished from other data access exceptions for processing.
L integrate hibernate: Spring and force us to use its powerful JDBC abstract features. It can be well integrated with the O/R maping framework, especially hibernate. Spring provides effective and secure hibernate session operations. Spring processes the configuration of hibernate sessionfactory in application contexts and JDBC data sources. Spring also makes the application easy to test.

Integration layer and Hibernate
Hibernate is an open-source o/R Mapping Framework. O/R Mapping can reduce the use of JDBC APIs. Hibernate supports all mainstream SQL database management systems. Hiernatede Query Language hql is the smallest oo extension of SQL, which provides an elegant bridge between objects and the relational world. Hibernate provides functions such as data acquisition and update, transaction management, database connection pool, programmatic or declarative query, and declarative object link management.

Hibernate is less aggressive than other O/R Mapping frameworks. Reflection, binary code generation is used during the runtime.
SQL generation occurs when the system starts. It allows us to develop persistent objects (PO) According to Java's habits, including using associations, inheritance, polymorphism, combinations, and Java collections frameworks. The Business Object (BO) in the example application is pojo and does not need to implement any hibernate-related interfaces.
Data Access Object (DAO)
The DAO mode is used in jcatalog. This mode abstracts and encapsulates all access to the data source. The application has two Dao interfaces: catalogdao and userdao. Their implementation classes hibernatecatalogdaoimpl and hibernateuserdaoimpl contain hibernate-specific management and persistence data logic.