With resource initialization and access control out of the way, delegated to appropriate component types, we can focus on the implementation of the main application logic.
We have already decided to use a servlet as a Controller. With a servlet as the common entry point for all application requests, you gain control over the page flow of the application. The servlet can decide which type of response to generate depending on the outcome of the requested action, such as returning a common error page for all requests that fail, or different responses depending on the type of client making the request. With the help from some utility classes, it can also provide services such as input validation, I18N preparations, and in general, encourage a more streamlined approach to request handling.
When you use a servlet as a Controller, you must deal with the following basic requirements:
All requests for processing must be passed to the single Controller servlet.
The servlet must be able to distinguish requests for different types of processing.
Here are other features you will want support for, even though they may not be requirements for all applications:
A strategy for extending the application to support new types of processing requests in a flexible manner
A mechanism for changing the page flow of the application without modifying code
You can, of course, develop a servlet that fulfills these requirements yourself, but there are servlets ...