The Java EE platform is a distributed multitiered application model that has three widely used common tiers. These tiers are the presentation tier (or web tier), the business tier, and the integration tier (or EIS tier).

The presentation tier, also known as the web tier, contains the components that create a web application. This tier has many components that use the HTTP protocol, construct views and interfaces for users, and provide a web service. These components are called web components. There are two types of presentation tier:

• Presentation-oriented tier: This type of presentation tier contains the components to construct an interactive web page and dynamic content using HTML and XHTML. These components are JavaServer Faces technology, Java Servlet technology, and JavaServer Page technology, which allow us to construct an interactive web...

When a client sends a request to the server, the server sometimes processes this request/response to perform the following tasks:

• Validating authentication
• Generating log
• Validating constraints
• Verifying the browser of the client
• Checking the duration between the request and response; calculating the response time
• Setting a cookie

However, we don't want to put these tasks within the logic of processing the main request. Consequently, creating a pre-process and/or post-process to do these tasks is a good method for decoupling the main logic from the complementary logic.

The intercepting filter pattern is the pattern that solves problems when we want to insert a logic that is not part of the main logic but we want to keep the two logics separated and decoupled. Merging the new logic with the main logic is a bad...

To implement this pattern with the best practices of Java EE 8, we will use the servlet filter from the Java Servlet specification. With the servlet filter, we can create an ordered request interceptor to treat the requests and responses. These interceptors are mapped by the URL pattern or servlet name. The servlet filter can be configured with XML (on web.xml) or annotation. In our case, we will imagine that we want to create a log of all the requests that are sent to the server. We will also have two filters—one to log the access time and another to log the information about the browser that the client is using. To log the access time, we will create a filter called LogAccessFilter, and to log the browser information we will create a filter called LogBrowserFilter.

In the Java EE world, we commonly work with complex projects that have similar functionalities and processes. Sometimes, using various controllers to handle a request is a bad practice because it needs to be configured at multiple endpoints and incurs a large cost of creation and maintenance. Consequently, creating a central point to treat a request is a very good solution, as it creates one point to manage all or a group of requests and then sends this request to the correct process. We can then treat all points that are common to all functionalities and send the request to a process to treat the questions that are not common to all but are specific to one functionality. Some configurations, such as session configuration, the maximum size limit of a request, cookie, and header, are common to all requests and can be configured from...

Some web applications have a complex logic for defining the correct view, content, or action to invoke. The MVC controller can be used to make this decision and get the correct view, content, or action. However, sometimes the logic to define a decision is very hard, and using the MVC controller to do this can cause duplication of a lot of code. To solve this, we need to centralize the logic at one point to permit an easy maintenance and a central logic point.

The application controller pattern is the pattern that permits the centralization of all view logic and promotes a unique process to define the flow of pages. This pattern is used together with FrontController, discussed earlier, and is an intermediary between FrontController and Command. Using this pattern, we will promote the decoupling between view treatment and request...

In this chapter, we learned about the presentation tier and looked at the intercepting filter pattern, front controller patterns, and application controller pattern as well as how to implement them. In the real world, we rarely need to implement these patterns because some frameworks, APIs, and specifications already implement them for us. However, it is very important to know about these patterns in order to improve our understanding of the frameworks, APIs, and specifications that implement them. As well as this, we sometimes need to implement some components outside of the framework. Consequently, it is a good idea to use this pattern.

The next chapter will address the business tier and its patterns. Here, we will cover the patterns that act on the business tier. Knowing about these patterns will complement our knowledge of the concepts and implementations...