Servlet的出現
Servlet技術和JSP技術是利用Java語言開發Web應用程序的兩個主要技術，1996年Sun公司首次推出Servlet技術來解決Web程序當中的性能問題。Servlet在首次被用戶請求的時候加載到內存當中，之後將一直駐留在內存裡，對同一個servlet的後續請求將不用再對這個servlet的類進行實例化，這種機制大大提高了Web應用程序的相應速度。
可是Servlet並不是那麼完美，當人們在編寫Servlet的時候發現所有HTML輸出代碼都封裝在String對象裡，然後再用out對象的print方法向用戶展示出來，這不免增加了編碼的難度，而且維護起來也十分麻煩，即使稍微一點點的改動也需要重新編譯Servlet才行。
JSP以及相關技術的出現
Sun公司意識到了這個問題，並提出了JSP技術。JSP允許Java代碼和HTML標簽混雜在一起以簡化頁面的開發，修改頁面無需重新編譯，當第一次被請求的時候如果原先的JSP有變化則重新自動編譯，如果沒有變化則直接加載已經存在的實例。
但是問題又接踵而至：
l Java代碼和HTML代碼（邏輯和顯示）混雜在一起使得程序變得難以閱讀和維護
l 把代碼放在JSP當中很難重用，這與面向對象的思想是相悖的
l JSP當中編寫代碼IDE對此支持的並不是那麼十分的出色
l 測試變得困難
邏輯和顯示混雜是不被人們所提倡的，早在JSP1.0規范中就鼓勵程序員使用JavaBean將業務邏輯代碼封裝，從而把顯示和業務分開。但是事情並不像想象的那麼美好，在JSP當中對JavaBean中的方法命名必須遵守其命名約定，所以偶爾會出現某個方法的名字非常冗長難記。為了實現代碼和HTML更容易的分離JSP1.1定義了幾個自定義標簽庫，他們比JavaBean更加靈活易用。
但是舊的問題解決了，新的問題出現：自定義標簽庫很難編寫，並且JSP1.1中的自定義標簽有著非常復雜的生命周期。
後來人們開始給有關的標簽添加一些特定的常用功能。這些標簽庫編譯為幾個庫文件，統稱為JSTL（JavaServer Pages Standard Tag Libraries，JSP標准標簽庫）。
盡管有了JavaBean，JSTL等技術可以把業務邏輯和顯示代碼分開，但是還是有很多開發者貪圖方便或者說目光短淺，仍將邏輯與顯示的代碼混雜在一起。
Model1設計模型
至此出現了Java語言開發Web應用的第一種設計模型我們稱之為Model1，簡而言之就是只用JSP不使用Servlet，將頁面代碼和邏輯代碼混雜在一起。從一個JSP頁面到另外一個JSP頁面是通過頁面裡的鏈接完成的。
這種模式的問題就向上面所說的，對於小項目而言開發可能方便了一些。但是對於大型項目，開發是苦不堪言的，因為這種架構不利於網頁設計師和Web開發人員之間的勞動分工：開發人員既要參與頁面的開發，又要參與業務邏輯的編碼。維護起來就更加痛苦了，邏輯與顯示代碼混雜、頁面之間的聯系是通過鏈接（這意味著一旦頁面名字改變那麼任何使用這個頁面的其他頁面都要更改，嚴重的違背了面向對象的思想）這對開發人員來說俨然就是一場噩夢。
Model2設計模型
於是第二種設計模型出現了，我們稱之為Model2，這個模型是MVC（Model-View-Controller，模型-視圖-控制器）設計模式的另一個名字。按照Model2模型開發的應用程序由三種主要部分組成：模型、視圖、和控制器。
在Model2模型裡，所有的頁面都有一個共同的入口點，通常是用一個Servlet或者過濾器（其中Struts1用的是Servlet，而Struts2用的是過濾器）來充當控制器。控制器部分負責接收來自用戶輸入並控制模型和視圖部分做出相應的變化；視圖部分負責實現應用程序的信息顯示功能；模型部分封裝著應用程序的數據和業務邏輯。而在這樣的應用程序裡，每一個HTTP請求都必須定向到控制器，而潛在各個請求中的URI裡的信息將告訴這個控制需要調用哪些動作。控制器檢查每個URI以決定應該調用哪些動作。它還將動作對象保存在一個可以從視圖訪問的地方，這樣服務器端的值就可以顯示在浏覽器上了。最後控制器使用RequestDispatcher對象把請求傳遞給視圖（即相應的JSP頁面），再由JSP頁面裡的定義標簽把動作對象的內容顯示出來。
整個的發展流程
原來：技術的發展是由問題堆砌起來的。
後面將分別演示用Servlet和過濾器作為控制器實現Model2設計模型，其實可以看作是Struts1和Struts2的demo。
