The early JSP specifications presented two approaches for building web applications using JSP technology. These two approaches were described in the specification as JSP Model 1 and Model 2 architectures.
The two JSP architectures differed in several key areas.

Figure 1-1. JSP Model 1 Architecture
Notice that in Figure 1-1 there is no 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 either determined based on the JSP selected or parameters within the client’s request.
In direct comparison to the Model 1 approach, in the Model 2 architecture, the client request is first intercepted by a servlet, most often referred to as a Controller servlet.
The servlet handles the initial processing of the request and also determines which JSP page to display next.
This approach is illustrated in Figure 1-2.
Figure 1-2. JSP Model 2 Architecture
As you can see from Figure 1-2, in the Model 2 architecture, a client never sends a request directly to a JSP page. The controller servlet acts as sort of a traffic cop. This allows the servlet to perform front-end processing like authentication and authorization, centralized logging, and possibly helps with Internationalization.
Once processing of the request has finished, the servlet directs the request to the appropriate JSP page. How exactly the next page is determined can vary widely across different applications, for example, in simpler applications, the next JSP page to display may be hard coded in the servlet based on the request, parameters, and current application state. In other more sophisticated web applications, a workflow/rules engine may be used.
As you can see, 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 also encourages more reuse and extensibility than Model 1. With the Model 2 architecture, there is also a clear separation of the business logic, presentation output, and request processing.
This separation is often referred to as a Model-View-Controller (MVC) pattern. While the Model 2 architecture might seem overly complicated, it can actually simplify an application greatly. Web applications built using the Model 2 approach are generally easier to maintain and can be more extensible than comparable applications built around the Model 1 architecture.
All of this doesn’t mean that applications built using the Model 1 approach are incorrectly designed. The Model 1 architecture might be the best decision for smaller applications that have simple page navigation, no need for centralized features, and are fairly static.
However, for larger enterprise-size web applications, it would be more advantageous to utilize the Model 2 approach.
No comments:
Post a Comment