JSP Model 1, Model 2 Architectures and MVC Pattern

JSP Model 1, Model 2 Architectures and MVC Pattern

The early JSP specifications presented two approaches for building web applications using JSP technology. These two approaches were the JSP Model 1 and Model 2 architectures. The two JSP architectures differ in several key areas.
The major difference is in how and by which component the processing of a request is handled. With the Model 1 architecture, the JSP page handles all of the processing of the request and is responsible for displaying the output to the client. There is no extra servlet involved in the process. The client request is sent directly to a JSP page, which may communicate with JavaBeans or other services, but ultimately the JSP page selects the next page for the client. The next view is determined based on either the JSP selected or parameters within the client's request. In contrast, in the Model 2 architecture, the client request is first intercepted by a servlet, referred to as a controller servlet. This servlet handles the initial processing of the request and determines which JSP page to display next.A client never sends a request directly to a JSP page in the Model 2 architecture. This allows the servlet to perform front-end processing, including authentication and authorization, centralized logging, and help with internationalization. Once request processing has completed, the servlet directs the request to the appropriate JSP page. How the next page is determined varies widely across different applications. The main difference between the two approaches is that the Model 2 architecture introduces a controller servlet that provides a single point of entry and encourages more reuse and extensibility than the Model 1 approach. With the Model 2 architecture, there is a clear separation of the business logic, presentation output, and request processing. This separation often is referred to as a Model-View-Controller (MVC) pattern.

While the Model 2 architecture might seem overly complicated, it actually can simplify an application greatly. Web applications built using the Model 2 approach generally are easier to maintain and can be more extensible than comparable applicationsbuilt around the Model 1 architecture.

Importance of Model-View-Controller

The MVC architectural pattern is not directly related to web applications. In fact, it's quite common in Smalltalk applications, which generally have nothing to do with the Web.
The Model 2 approach is concerned with separating responsibilities in web applications. Allowing a JSP page to handle the responsibilities of receiving the request, executing some business logic, and then determining the next view to display can make for an unattractive JSP page, not to mention the maintenance and extensibility problems this entanglement causes. Application development and maintenance are much easier if the different components of a web application have clear and distinct responsibilities.

The MVC Model
Depending on the type of architecture your application uses, the model portion of the MVC pattern can take many different forms. In a two-tier application, where the web tier interacts directly with a data store such as a database, the model classes may be a set of regular Java objects. These objects may be populated manually from a ResultSet returned by a database query, or they may be instantiated and populated automatically by an object-to-relational mapping (ORM) framework such as TopLink or CocoBase.

The MVC View
The views within the web tier MVC pattern typically consist of HTML and JSP pages. HTML pages are used to serve static content, while JSP pages can be used to serve both static and dynamic content.
Most dynamic content is generated in the web tier. However, some applications may require clientside JavaScript. This does not interfere with or infringe upon the MVC concept.
HTML and JSP are not the only choice for the view. You easily can support WML, for example,
instead of HTML. Because the view is decoupled from the model, you can support multiple views, each for a different client type, using the same model components.

The MVC Controller
The controller portion of the web tier MVC design generally is a Java servlet. The controller in a web tier application performs the following duties:

Intercepts HTTP requests from a client

Translates each request into a specific business operation to perform

Either invokes the business operation itself or delegates it to a handler

Helps to select the next view to display to the client

Returns the view to the client

The Front Controller pattern describes how a web tier controller should be implemented. Because all client requests and responses go through the controller, there is a centralized point of control for the web application. This helps when adding new functionality. Code that would normally need to be put in every JSP page can be put in the controller servlet, which processes all the requests. The controller also helps to decouple the presentation components (views) from the business operations, further aiding development.

Useful Links : Sun's Patterns Catalog Front Controller Pattern

Here is a graphical repersentation of a typical struts based application.