Front Controller - Core J2EE design patterns

Front Controller pattern tells that, “There should be a Single entry and exit point for each and every request made by the user on a single application expecting for a single type of result and the same single controller may interact with different systems or programs to build the response for the request”.


For a better manageability of an application use a Front Controller as the initial point of contact for handling all related requests. The Front Controller centralizes control logic that might otherwise be duplicated, and manages the key request handling activities.


The Front Controller pattern suggests centralizing the handling of all requests but, it does not limit the number of handlers in the system, as does a Singleton. An application may use multiple controllers in a system, each mapping to a set of distinct services

Most of the current MVC based frameworks are using the Front Controller design pattern internally to handle the request from the multiple users.

• Action Servlet is the Front controller in the Struts Framework (1.x)
• Faces Servlet is the Front Controller in the JSF Framework.

Advantages:

Centralizes The Control: It works like a central place to handle system services and business logic across multiple requests and manages business logic processing and request handling. Centralized access to an application means that requests are easily tracked and logged.

Improves Manageability: Front Controller centralizes control, providing a choke point for illicit access attempts into the Web application. In addition, auditing a single entrance into the application requires fewer resources than distributing security checks across all pages.

Improves Reusability: Front Controller promotes cleaner application partitioning and encourages reuse, as code that is common among components moves into a controller or is managed by a controller.

Separates the System Processing Logic: Front Servlet seperates the System Processing logic from view and provides the better manageability from the same.

Intercepting Filter – Core J2EE design patterns

What Intercepting Filter does?

The Intercepting Filter pattern wraps existing application resources with a filter that intercepts the reception of a request and the transmission of a response.

What is the need of Intercepting Filter?

Consider a scenario, I your web application you want to check session from the every users request and if it is valid then only you want to let the user access the page. You can achieve this by checking sessions on all the servlet pages (or JSP pages) which users queries or you can do this by using Filter. In a filter you can write the logic to not enter the user without a valid session.

ie: An intercepting filter can pre-process or redirect application requests, and can post-process or replace the content of application responses. Intercepting filters can also be stacked one on top of the other to add a chain of separate, declaratively-deployable services to existing Web resources with no changes to source code.

Example for Intercepting Filter:


import java.io.IOException;
import java.util.Date;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;

public class LogFilter implements Filter {

    public void doFilter(ServletRequest req, ServletResponse res,
            FilterChain chain) throws IOException, ServletException {

        HttpServletRequest request = (HttpServletRequest) req;

        //Get the IP address of client machine.
        String ipAddress = request.getRemoteAddr();

        //Log the IP address and current timestamp.
        System.out.println("IP "+ipAddress + ", Time "
                            + new Date().toString());

        chain.doFilter(req, res);
    }
    public void init(FilterConfig config) throws ServletException {

        //Get init parameter
        String testParam = config.getInitParameter("test-param");

        //Print the init parameter
        System.out.println("Test Param: " + testParam);
    }
    public void destroy() {
        //add code to release any resource
    }
}

Advantages:

Centralizes Control with Loosely Coupled Handlers: Filters provide a central place for handling processing across multiple requests, as does a controller. Filters are better suited to massaging requests and responses for ultimate handling by a target resource, such as a controller. Additionally, a controller often ties together the management of numerous unrelated common services, such as authentication, logging, encryption, and so forth, while filtering allows for much more loosely coupled handlers, which can be combined in various combinations.

Improves Re-usability: Filters promote cleaner application partitioning and encourages reuse. These pluggable interceptors are transparently added or removed from existing code, and due to their standard interface, they work in any combination and are reusable for varying presentations.

Declarative and Flexible Configuration: Numerous services are combined in varying permutations without a single recompile of the core code base.

Disadvantages:

Information Sharing is Inefficient: Sharing information between filters can be inefficient, since by definition each filter is loosely coupled. If large amounts of information must be shared between filters, then this approach may prove to be costly.