1、<p>　　Servlet和JSP技術簡述</p><p>　　Nagle ，Wiegley</p><p>　　摘要：Servlet程序在服務器端運行，動態(tài)地生成Web頁面與傳統(tǒng)的CGI和許多其他類似CGI的技術相比，Java Servlet具有更高的效率，更容易使用，功能更強大，具有更好的可移植性，更節(jié)省投資。</p><p>　　關鍵字：JSP技術；

2、Servlet；HTTP服務</p><p>　　1　Servlet的功能</p><p>　　Servlet是運行在Web或應用服務器上的Java程序，它是一個中間層，負責連接來自Web瀏覽器或其他HTTP客戶程序的請求和HTTP服務器上的數據庫或應用程序。Servlet的工作是執(zhí)行西門的任務，如圖1.1所示 。</p><p>　　圖1.1　Web中間件的作用&

3、lt;/p><p>　　1.1　讀取客戶發(fā)送的顯式數據</p><p>　　最終用戶一般在頁面的HTML表單中輸入這些數據。然而，數據還有可能來自applet或定制的HTTP客戶程序。</p><p>　　1.2　讀取由瀏覽器發(fā)送的隱式請求數據</p><p>　　圖1.1中顯示了一條從客戶端到Web服務器的單箭頭，但實際上從客戶端傳送到Web服

4、務器的數據有兩種，它們分別為用戶在表單中輸入的顯式數據，以及后臺的HTTP信息。兩種數據都很重要。HTTP信息包括cookie、瀏覽器所能識別的媒體類型和壓縮模式等。</p><p><b>　　1.3　生成結果</b></p><p>　　這個過程可能需要訪問數據庫、執(zhí)行RMI或EJB調用、調用Web服務，或者直接計算得出對應的響應。實際的數據可能存儲在關系型數據庫

5、中。該數據庫可能不理解HTTP，或者不能返回HTML形式的結果，所有Web瀏覽器不能直接與數據庫進行會話。即使它能夠做到這一點，為了安全上的考慮，我們也不希望讓它這么做。對應大多數其他應用程序，也存在類似的問題。因此，我們需要Web中間層從HTTP流中提取輸入數據，與應用程序會話，并將結果嵌入到文檔中。</p><p>　　1.4　向客戶發(fā)送顯式數據（即文檔）</p><p>　　這個文檔

6、可以用各種格式發(fā)送，包括文本（HTML或XML），二進制（GIF圖），甚至可以式建立在其他底層格式之上的壓縮格式，如gzip。但是，到目前為止，HTML式最常用的格式，故而servelt和JSP的重要任務之一就式將結果包裝到HTML中。</p><p>　　1.5　發(fā)送隱式的HTTP響應數據</p><p>　　圖1.1中顯示了一條從Web中間層到客戶端的單箭頭。但是，實際發(fā)送的數據有兩種

7、：文檔本身，以及后臺的HTTP信息。同樣，兩種數據對開發(fā)來說都式至關重要的。HTTP響應數據的發(fā)送過程涉及告知瀏覽器或其他客戶程序所返回文檔的類型（如HTML），設置cookie和緩存參數，以及其他類似的任務。</p><p>　　2　動態(tài)構建網頁的原因</p><p>　　預先建立的文檔可以滿足客戶的許多請求，服務器無需調用servlet就可以處理這些請求。然而，許多情況下靜態(tài)的結果不能

8、滿足要求，我們需要針對每個請求生成一個頁面。實時構建頁面的理由有很多種：</p><p>　　2.1　網頁基于客戶發(fā)送的數據</p><p>　　例如，搜索引擎生成的頁面，以及在線商店的訂單確認頁面，都要針對特定的用戶請求而產生。在沒有讀取到用戶提交的數據之前，我們不知道應該顯示什么。要記住，用戶提交兩種類型的數據：顯示（即HTML表單的數據）和隱式（即HTTP請求的報頭）。兩種輸入都可用

9、來構建輸出頁面?；赾ookie值針對具體用戶構建頁面的情況尤其普遍。</p><p>　　2.2　頁面由頻繁改變的數據導出</p><p>　　如果頁面需要根據每個具體的請求做出相應的改變，當然需要在請求發(fā)生時構建響應。但是，如果頁面周期性地改變，我們可以用兩種方式來處理它：周期性地在服務器上構建新的頁面（和客戶請求無關），或者僅僅在用戶請求該頁面時再構建。具體應該采用哪種方式要根據具體

10、情況而定，但后一種方式常常更為方便，因為它只需簡單地等待用戶的請求。例如，天氣預報或新聞網站可能會動態(tài)地構建頁面，也有可能會返回之前構建的頁面（如果它還是最新的話）。</p><p>　　2.3　頁面中使用了來自公司數據庫或其他數據庫斷數據源的信息</p><p>　　如果數據存儲在數據庫中，那么，即使客戶端使用動態(tài)Web內容，比如applet，我們依舊需要執(zhí)行服務器端處理。想象以下，如果

11、一個搜索引擎網站完全使用applet，那么用戶將會看到：“正在下載50TB的applet，請等待！”。顯然，這樣很愚蠢；這種情況下，我們需要與數據庫進行會話。從客戶端到Web層再到數據庫（三層結構），要比從applet直接到數據庫（二層結構）更靈活，也更安全，而性能上的損失很少甚至沒有。畢竟數據庫調用通常是對速度影響最大的步驟，因而，經過中間層可以執(zhí)行高速緩存和連接共享。</p><p>　　理論上講，serve

12、lt并非只用于處理HTTP請求的Web服務器或應用服務器，它同樣可以用于其他類型的服務器。例如，servlet能夠嵌入到FTP或郵件服務器中，擴展他們的功能。而且，用于會話啟動協(xié)議服務器的servlet API最近已經被標準化（參見http://jcp.org/en/jsr/detail?id=116）。但在實踐中，servelt的這種用法尚不流行，在此，我們只論述HTTP Servlet。</p><p>　　

13、3　Servlet相對于“傳統(tǒng)”CGI的優(yōu)點</p><p>　　和傳統(tǒng)CGI及許多類CGI技術相比，Java servelt效率更高、更易用、更強大、更容易移植、更安全、也更廉價。</p><p><b>　　3.1　效率</b></p><p>　　應用傳統(tǒng)的CGI，針對每個HTTP請求都用啟動一個新的進程。如果CGI程序自身相對比較簡短，

14、那么啟動進程的開銷會占用大部分執(zhí)行時間。而使用servelt，Java虛擬機會一直運行，并用輕量級的Java線程處理每個請求，而非重量級的操作系統(tǒng)進程。類似地，應用傳統(tǒng)的CGI技術，如果存在對同一CGI程序的N個請求，那么CGI程序的代碼會載入內存N次。同樣的情況，如果使用servlet則啟動N個線程，單僅僅載入servlet類的單一副本。這種方式減少了服務器的內存需求，通過實例化更少的對象從而節(jié)省了時間。最后，當CGI程序結束對請求的

15、處理之后，程序結束。這種方式難以緩存計算結果，保持數據庫連接打開，或是執(zhí)行依靠持續(xù)性數據的其他優(yōu)化。然而，servelt會一直停留在內存中（即使請求處理完畢），因而可以直接存儲客戶請求之間的任意復雜數據。</p><p><b>　　3.2　便利</b></p><p>　　Servelt提供大量的基礎構造，可以自動分析和解碼HTML的表單數據，讀取和設置HTTP報頭

16、，處理cookie，跟蹤會話，以及其他次類高級功能。而在CGI中，大部分工作都需要我們資金完成。另外，如果您已經了解了Java編程語言，為什么還有學校Perl呢？您已經承認應用Java技術編寫的代碼要比Visual Basic，VBScript或C＋＋編寫的代碼更可靠，且更易重用，為什么還有倒退回去選擇那些語言來開發(fā)服務器端的程序呢？</p><p><b>　　3.3　強大</b><

17、/p><p>　　Servlet支持常規(guī)CGI難以實現(xiàn)或根本不能實現(xiàn)的幾項功能。Servlet能夠直接于Web服務器對話，而常規(guī)的CGI程序做不到這一點，至少在不使用服務器專有API的情況下是這樣。例如，與Web服務器的通信使得講相對URL轉換成具體的路徑名變得更為容易。多個servelt還可以共享數據，從而易于實現(xiàn)數據庫連接共享和類似的資源共享優(yōu)化。Servelt還能維護請求之間的信息，使得諸如會話跟蹤和計算結果緩

18、存等技術變得更為簡單。</p><p><b>　　3.4　可移植性</b></p><p>　　Servelt使用Java編程語言，并且遵循標準的API。所有主要的Web服務器。實際上都直接或通過插件支持servlet。因此。為Macromedia JRun編寫的servlet，可以不經過任何修改地在Apache Tomcat，Microsoft Internet

19、Information Server，IBM WebSphere 。iPlanet Enterprise Server。Oracle9i AS 或者StrNine WebStar上運行。他們是java2平臺企業(yè)版的一部分，所以對servlet的支持越來越普遍。</p><p><b>　　3.5　廉價</b></p><p>　　對于開發(fā)用的網站、低容量或中等容量網站

20、的部署，有大量免費或極為廉價的Web服務器可供選擇。因此，通過使用servelt和jsp，我們可以從免費或廉價的服務器開始，在項目獲得初步成功后，在移植到更高性能或高級管理工具的昂貴的服務器上。這與其他CGI方案形成鮮明的對比，這些CGI方案在初期都需要為購買專利軟件包投入大量的資金。</p><p>　　價格和可移植性在某種程度上是相互關聯(lián)的。例如，Marty記錄了所有通過電子郵件向他發(fā)送問題的讀者的所在國。印

21、度接近列表的頂端，可能僅次于美國。Marty曾在馬尼拉講授過jsp和servlet培訓課程，那兒對servelt和jsp技術抱很大的興趣。</p><p>　　那么，為什么印度和菲律賓都對這項技術著呢感興趣呢？我們推測答案可能分兩部分。首先，這兩個國家都擁有大量訓練有素的軟件開發(fā)人員。其次，這兩個國家的貨幣對美元的匯率都極為不利。因此，從美國公司那里購買專用Web服務器會消耗掉項目的大部分前期資金。</p&

22、gt;<p>　　但是，使用servlet 和JSP，他們能夠從免費的服務器開始：Apache Tomcat。項目取得成功之后，他們可以轉移到性能更高、管理更容易，但需要付費的服務器。他們的servelt和jsp不需要重寫編寫。如果他們的項目變得更龐大，他們或許希望轉移到分布式環(huán)境。沒有問題：他們可以轉而使用Macromedia JRun Professional，該服務器支持分布式應用。同樣，他們的servelt和jsp

23、沒有任何部分需要重寫。如果項目變得極為龐大，錯綜復雜，他們或許希望使用Enterprise JavaBeans來封裝他們的商業(yè)邏輯。因此，他們可以切換到BEA WebLogic或Oracle9i AS。同樣，不需要對servlet和jsp做出更改。最后，如果他們的項目變得更龐大，他們或許將他從Linux轉移到運行IBM WebSphere的IBM大型機上。他們還是不需要做出任何更改。</p><p><b&

24、gt;　　3.6　安全</b></p><p>　　傳統(tǒng)CGI程序中主要的漏洞來源之一就是，CGI程序常常由通過的操作系統(tǒng)外殼來執(zhí)行。因此,CGI程序必須仔細地過濾掉那些可能被外殼特殊處理的字符，如反引導和分號。實現(xiàn)這項預防措施的難度可能超出我們的想象，在廣泛應用的CGI庫中，不斷發(fā)現(xiàn)由這類問題引發(fā)的弱點。</p><p>　　問題的第二個來源是，一些CGI程序用不自動檢查數組

25、和字符串邊界的語言編寫而成。例如，在C和C＋＋中，可以分配一個100個元素的數組，然后向第999個“元素“寫入數據——實際上是程序內存的隨機部分，這完全合法。因而，如果程序員忘記執(zhí)行這項檢查，就會將系統(tǒng)暴露在蓄意或偶然的緩沖區(qū)溢出攻擊之下。</p><p>　　Servelt不存在這些問題。即使servelt執(zhí)行系統(tǒng)調用激活本地操作系統(tǒng)上的程序，它也不會用到外殼來完成這項任務。當然，數組邊界的檢查以及其他內存包含

26、特性是java編程語言的核心部分。</p><p><b>　　3.7　主流</b></p><p>　　雖然存在許多很好的技術，但是，如果提供商助支持他們，或開發(fā)人員不知道如何使用這些技術，那么它們的優(yōu)點又如何體現(xiàn)呢？servelt和jsp技術得到服務器提供商的廣泛支持，包括Apache，Oracle，IBM，Sybase，BEA，Maromedia，Causho，

27、Sun/iPlanet，New Atlanta，ATG，F(xiàn)ujitsu，Lutris，Silverstream，World Wide Web Consortinrm ，以及其他服務器。存在幾種低廉的插件，通過應用這些插件，Microsoft IIS和Zeus也同樣支持servlet和jsp技術，它們運行在Windows，Unix/Linus,MacOS,VMS，和IBM大型機操作系統(tǒng)之上。它們用在航空業(yè)、電子商務、在線銀行、web搜索引

28、擎、門戶、大型金融網站、以及成百上千您日常光顧的其他網站。</p><p>　　當然，僅僅是流行并不能證明技術的優(yōu)越性。很多泛美的例子。但我們的立場是：服務器端Java本非一項新的、未經證實的技術。</p><p><b>　　參考文獻：</b></p><p>　　[1]　Clifton G.M. Branham, Arthur Jonath

29、an .Servlets and JSP in an undergraduate database course[J].Proceedings of the International Conference on Parallel and Distributed Processing Techniques and Applications,2003(3):1490-1496.</p><p>　　[2]　Kirk

30、egaard, Christian.Static analysis for Java servlets and JSP[J].Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics),2006(4):336-352.</p&g

31、t;<p>　　[3]　Nakaike,Takuya.JSP Splitting for improving execution performance[J].Proceedings - International Symposium on Applications and the Internet,2004[8]:117-126.</p><p>　　[4]　Hassan, Doaa .Devel