• Simplified design : The front controller now abides by SRP because it is involved
only in intercepting requests and delegating to specialized classes.
• Promotes reusability : The introduction of the front controller removes the module
controllers and immensely improves reusability.
• Single point of failure : The front controller is also a single point of failure for any
The JSP controller presented while discussing the Front Controller pattern was intended
to perform the following tasks related to request processing:
1. Intercept incoming requests.
2. Invoke business components.
3. Identify and redirect to the next view.
The Front Controller design pattern solved the first problem. As with the JSP con-
troller, it is entirely possible to build the two other functions in the front controller. But
that would result in a highly inflexible, fat, magic front controller that handles too many
responsibilities. As the application grows, it becomes an uphill task to maintain and use
such complex and specific front controllers. This was exactly the problem with the JSP-
based controller used in the eInsure application.
A new customer wanted to integrate their existing re-insurance product, built on the
WebWork 2.0 framework, with eInsure. The integration soon ran into heavy weather
because the controller was never designed to cater to this kind of requirement. Another
existing client of eInsure demanded a new feature called policy quotation . This feature
would enable the potential customers of this insurance company to get an approximate
value of the premium they needed to pay for a new policy. For this they would use their
mobile devices to connect to the system and supply the minimal information required to
generate the quote—or tentative premium value.