Model 1 Architecture

Model 1 architecture is the easiest way of developing JSP based web applications. It cannot get any easier. In Model 1, the browser directly accesses JSP pages. In other words, user requests are handled directly by the JSP.

Let us illustrate the operation of Model 1 architecture with an example. Consider a HTML page with a hyperlink to a JSP. When user clicks on the hyperlink, the JSP is directly invoked. This is shown in Figure 1.1. The servlet container parses the JSP and executes the resulting Java servlet. The JSP contains embedded code and tags to access the Model JavaBeans. The Model JavaBeans contains attributes for holding the HTTP request parameters from the query string. In addition it contains logic to connect to the middle tier or directly to the database using JDBC to get the additional data needed to display the page. The JSP is then rendered as HTML using the data in the Model JavaBeans and other Helper classes and tags.

Figure 1.1: Model 1 Architecture.

Problems with Model 1 Architecture

Model 1 architecture is easy. There is some separation between content (Model JavaBeans) and presentation (JSP). This separation is good enough for smaller applications. Larger applications have a lot of presentation logic. In Model 1 architecture, the presentation logic usually leads to a significant amount of Java code embedded in the JSP in the form of scriptlets. This is ugly and maintenance nightmare even for experienced Java developers. In large applications, JSPs are developed and maintained by page authors. The intermingled scriptlets and markup results in unclear definition of roles and is very problematic .

Application control is decentralized in Model 1 architecture since the next page to be displayed is determined by the logic embedded in the current page. Decentralized navigation control can cause headaches when requirements keep changing.