一、概述

1.前言

在前面幾篇博客中，我們和大家說了負載均衡器服務器、Web服務器、反向代理服務器、緩存服務器，從這篇博客開始我們和大家說說應用程序服務器，對于上述內容不了解的博友可以去參考一下我們前幾篇的博客。在應用程序中最出名的有兩種一種是PHP，另一種是JSP。他們都是用來進行Web開發的，特別是進行電子商務網站的開發，應用的特別多。對于我們運維來說肯定是不需要開發的。但我們得進行應用程序服務器維護的工作。前面我們和大家多次聊了PHP的應用服務器維護如，LAMP環境的搭建、LNMP環境搭建等。在這篇博客中我們主要和大家聊一聊JSP服器的應用。在說JSP的相關知識之前，我們先來回憶一下PHP相關知識點。

2.PHP相關知識

(1).PHP簡介

PHP是通用服務器端腳本編程語言，其主要用于web開發以實現動態web頁面，它也是最早實現將腳本嵌入HTML源碼文檔中的服務器端腳本語言之一。同時，php還提供了一個命令行接口，因此，其也可以在大多數系統上作為一個獨立的shell來使用。

Rasmus Lerdorf于1994年開始開發PHP，它是初是一組被Rasmus Lerdorf稱作“Personal Home Page Tool” 的Perl腳本， 這些腳本可以用于顯示作者的簡歷并記錄用戶對其網站的訪問。后來，Rasmus Lerdorf使用C語言將這些Perl腳本重寫為CGI程序，還為其增加了運行Web forms的能力以及與數據庫交互的特性，并將其重命名為“Personal Home Page/Forms Interpreter”或“PHP/FI”。此時，PHP/FI已經可以用于開發簡單的動態web程序了，這即是PHP 1.0。1995年6月，Rasmus Lerdorf把它的PHP發布于comp.infosystems.www.authoring.cgi Usenet討論組，從此PHP開始走進人們的視野。1997年，其2.0版本發布。

1997年，兩名以色列程序員Zeev Suraski和Andi Gutmans重寫的PHP的分析器(parser)成為PHP發展到3.0的基礎，而且從此將PHP重命名為PHP: Hypertext Preprocessor。此后，這兩名程序員開始重寫整個PHP核心，并于1999年發布了Zend Engine 1.0，這也意味著PHP 4.0的誕生。2004年7月，Zend Engine 2.0發布，由此也將PHP帶入了PHP5時代。PHP5包含了許多重要的新特性，如增強的面向對象編程的支持、支持PDO(PHP Data Objects)擴展機制以及一系列對PHP性能的改進。

(2).PHP Zend Engine

Zend Engine是開源的、PHP腳本語言的解釋器，它最早是由以色列理工學院(Technion)的學生Andi Gutmans和Zeev Suraski所開發，Zend也正是此二人名字的合稱。后來兩人聯合創立了Zend Technologies公司。

Zend Engine 1.0于1999年隨PHP 4發布，由C語言開發且經過高度優化，并能夠做為PHP的后端模塊使用。Zend Engine為PHP提供了內存和資源管理的功能以及其它的一些標準服務，其高性能、可靠性和可擴展性在促進PHP成為一種流行的語言方面發揮了重要作用。

Zend Engine的出現將PHP代碼的處理過程分成了兩個階段：首先是分析PHP代碼并將其轉換為稱作Zend opcode的二進制格式(類似Java的字節碼)，并將其存儲于內存中；第二階段是使用Zend Engine去執行這些轉換后的Opcode。

(3).PHP的Opcode

Opcode是一種PHP腳本編譯后的中間語言，就像Java的ByteCode,或者.NET的MSL。PHP執行PHP腳本代碼一般會經過如下4個步驟(確切的來說，應該是PHP的語言引擎Zend)：

• Scanning(Lexing) —— 將PHP代碼轉換為語言片段(Tokens)

• Parsing —— 將Tokens轉換成簡單而有意義的表達式

• Compilation —— 將表達式編譯成Opocdes

• Execution —— 順次執行Opcodes，每次一條，從而實現PHP腳本的功能

(4).PHP的加速器

基于PHP的特殊擴展機制如opcode緩存擴展也可以將opcode緩存于php的共享內存中，從而可以讓同一段代碼的后續重復執行時跳過編譯階段以提高性能。由此也可以看出，這些加速器并非真正提高了opcode的運行速度，而僅是通過分析opcode后并將它們重新排列以達到快速執行的目的。

常見的php加速器有：

• APC (Alternative PHP Cache) 遵循PHP License的開源框架，PHP opcode緩存加速器，目前的版本不適用于PHP 5.4。項目地址，http://pecl.php.net/package/APC。

• eAccelerator 源于Turck MMCache，早期的版本包含了一個PHP encoder和PHP loader，目前encoder已經不在支持。項目地址，?http://eaccelerator.net/。

• XCache 快速而且穩定的PHP opcode緩存，經過嚴格測試且被大量用于生產環境。項目地址，http://xcache.lighttpd.net/

• Zend Optimizer和Zend Guard Loader Zend Optimizer并非一個opcode加速器，它是由Zend Technologies為PHP5.2及以前的版本提供的一個免費、閉源的PHP擴展，其能夠運行由Zend Guard生成的加密的PHP代碼或模糊代碼。 而Zend Guard Loader則是專為PHP5.3提供的類似于Zend Optimizer功能的擴展。項目地址，http://www.zend.com/en/products/guard/runtime-decoders

• NuSphere PhpExpress NuSphere的一款開源PHP加速器，它支持裝載通過NuSphere PHP Encoder編碼的PHP程序文件，并能夠實現對常規PHP文件的執行加速。項目地址，http://www.nusphere.com/products/phpexpress.htm

(5).PHP源碼目錄結構

PHP的源碼在結構上非常清晰。其代碼根目錄中主要包含了一些說明文件以及設計方案，并提供了如下子目錄：

• build —— 顧名思義，這里主要放置一些跟源碼編譯相關的文件，比如開始構建之前的buildconf腳本及一些檢查環境的腳本等。

• ext —— 官方的擴展目錄，包括了絕大多數PHP的函數的定義和實現，如array系列，pdo系列，spl系列等函數的實現。 個人開發的擴展在測試時也可以放到這個目錄，以方便測試等。

• main —— 這里存放的就是PHP最為核心的文件了，是實現PHP的基礎設施，這里和Zend引擎不一樣，Zend引擎主要實現語言最核心的語言運行環境。

• Zend —— Zend引擎的實現目錄，比如腳本的詞法語法解析，opcode的執行以及擴展機制的實現等等。

• pear —— PHP 擴展與應用倉庫，包含PEAR的核心文件。

• sapi —— 包含了各種服務器抽象層的代碼，例如apache的mod_php，cgi，fastcgi以及fpm等等接口。

• TSRM —— PHP的線程安全是構建在TSRM庫之上的，PHP實現中常見的*G宏通常是對TSRM的封裝，TSRM(Thread Safe Resource Manager)線程安全資源管理器。

• tests —— PHP的測試腳本集合，包含PHP各項功能的測試文件。

• win32 —— 這個目錄主要包括Windows平臺相關的一些實現，比如sokcet的實現在Windows下和*Nix平臺就不太一樣，同時也包括了Windows下編譯PHP相關的腳本。

好了，說了這么多PHP的相關知識我們就說到這吧。下面我們來說一說程序之間的跨平臺。

3.C/C++與Java

在說Java之間我們來得說一說，C與跨平臺的相關知識。我們都知道C語言是面向對象的語言，C++是面向對象的語言。相對于PHP語言來說C語言或者C++語言，更接近底層的語言或者說更接近于硬件。執行效率要比PHP這種解釋型語言高的多。那大家想啊，我們經常用PHP來編寫Web應用，那我們能不能用C語言來編寫網站呢。答案是否定的，因為沒有一家公司要C語言來開發網站的，大家都知道我們編寫C語言都先編寫后進行編譯，然后再運行。那大家想啊，我們網站變動很快，幾乎每天都的大量的更新，每次更新都要進行編譯，然后再運行。維護成本太高了，就算是有公司出的起成本，也沒有公司會用，C語言還有個致命的弱點那就是不能跨平臺，比如我們的網站是在32位平臺上開發的，那我們只能在32位平臺上運行，而不能在64位平臺上運行。所以用C語言編寫的網站移植會很困難。剛才我們說到了跨平臺，下面我們就說一下與平臺相關的問題。

大家都知道，用C語言我們一般用來開發操作系統，而不是來用編寫網站的。現在主流的操作系統有兩種，一種是Windows系統，另一種是Linux系統。我們大家又知道，用C語言的操作系統都是有API接口(Application Programming Interface)的，簡單來說API就是系統調用。幫助我們的開發人員更好的開發應用軟件，由于操作系統的不同API又分為Windows API和Linux API。我們在Windows平臺開發出來的軟件在Linux上無法運行，在Linux上開發的軟件在Windows上又無法運行，這就導致了軟件移植困難，我們開發軟要開發兩份，甚至更多版本很是煩鎖。后大家就規定一個統一的API接口即POSIX(Protabl Operation System 可移植操作系統規范)。

但是我們知道一個應用程序的運行，需要諸多相關的庫文件來支撐的。在Windows當中的庫文件是*.dll（動態鏈接庫）而Linux當中的庫文件是*.so（共享對象）。這樣編寫的程序，也是不能跨平臺的。后來為了解決這個問題就提出是ABI接口（Application Binary Interface 應用程序二進制接口）。好了，我們說了這么多，其實就想表達兩個意思。一是C語言是不能用來編寫網站的，二是C語言移植困難、維護成本高。下面我們就來說一說Java。

二、Java

1.Java 簡介

Java是由Sun Microsystems公司于 1995年5月推出的Java面向對象程序設計語言（以下簡稱Java語言）和Java平臺的總稱。由James Gosling和同事們共同研發，并在1995年正式推出。用Java實現的HotJava瀏覽器（支持Java applet）顯示了Java的魅力：跨平臺、動態的Web、Internet計算。從此，Java被廣泛接受并推動了Web的迅速發展，常用的瀏覽器均支持Javaapplet。另一方面，Java技術也不斷更新。(2010年Oracle公司收購了SUN)

2.Java 組成

Java由四方面組成：

• Java編程語言

• Java類文件格式

• Java虛擬機

• Java應用程序接口(Java API)

下面我們來說一下這四個方面的關系，我們通過Java編程語言+Java應用程序接口（Java API）編寫出*.java的文件（如，test.java），通過Java編譯器javac（Java Complier）進行編譯生成*.class的類文件(如，test.class)，再通過Java類文件+Java虛擬機（JVM）運行Java程序。簡單過程如下，

• Java 程序語言+Java API ---> test.java （java程序）

• javac(Java Complier) ---> test.class （字節碼文件）

• Java類文件+Java虛擬機 ---> 運行test.class

好了，下面我們來說一說，Java虛擬機（JVM）的組成。

JVM 組成：

• JRE（JVM+Java SE API），是用于實現Java程序運行的最小環境。

• JDK （Java+API+JVM），是用于實現Java程序開發的最小環境。

3.Java 平臺

Java平臺由Java虛擬機（Java Virtual Machine，簡稱JVM）和Java 應用編程接口（Application Programming Interface，簡稱API）構成。Java應用編程接口為此提供了一個獨立于操作系統的標準接口，可分為基本部分和擴展部分。在硬件或操作系統平臺上安裝一個Java平臺之后，Java應用程序就可運行。Java平臺已經嵌入了幾乎所有的操作系統。這樣Java程序可以只編譯一次，就可以在各種系統中運行。Java應用編程接口已經從1.1x版發展到1.2版。常用的Java平臺基于Java1.5，最近版本為Java7.0。

4.Java 體系

Java分為三個體系，

• J2SE（Java2 Platform Standard Edition，java平臺標準版）

• J2EE(Java 2 Platform,Enterprise Edition，java平臺企業版)

• J2ME(Java 2 Platform Micro Edition，java平臺微型版)。

其中，Java SE則只包含了Java二進制程序(如JVM和Java字節碼編譯器)和Java的核心代碼庫，而Jave EE標準則包含了一組適用于創建企業級Web應用程序的API。Jave EE建立在Java SE的基礎上，并依賴于Java SE才能正常工作。當然，任何級別的應用程序均能從Java EE中獲益，但Jave EE卻更適合解決大型軟件系統設計中的問題。JAVA EE包含多個獨立的API，Servlet和JSP就是其中的兩個，而JAVA EE中著名的API中還包含如下的幾個，

JAVA EE APIs：

• EJB(Enterprise JavaBeans)：JAVA相關的諸多高級功能的實現，如RMI（Remote Method Invocation), 對象/關系映射，跨越多個數據源的分布式事務等；

• JMS(Java Message Service)：高性能異步消息服務，實現JAVA EE應用程序與非JAVA程序的“透明”通信；

• JMX（Java Management Extensions）：在程序運行時對其進行交互式監控和管理的機制；

• JTA（Java Transaction API）：允許應用程序在自身的一個或多個組件中平滑地處理錯誤的機制；

• JavaMail：通過工業標準的POP/SMTP/IMAP協議發送和接收郵件的機制；

Java SE APIs：

• JNDI（Java Naming and Directory Interface）:用于與LDAP服務交互的API；

• JAXP（Java API for XML Processing）:用于分析及轉換XML（基于XSLT實現）；

5.Java 優勢

與傳統程序不同，Sun 公司在推出 Java 之際就將其作為一種開放的技術。全球數以萬計的 Java 開發公司被要求所設計的 Java軟件必須相互兼容。“Java 語言靠群體的力量而非公司的力量”是Sun公司的口號之一，并獲得了廣大軟件開發商的認同。這與微軟公司所倡導的注重精英和封閉式的模式完全不同。

Sun 公司對 Java 編程語言的解釋是：Java 編程語言是個簡單、面向對象、分布式、解釋性、健壯、安全與系統無關、可移植、高性能、多線程和動態的語言。

Java 平臺是基于 Java 語言的平臺。這樣的平臺非常流行。因此微軟公司推出了與之競爭的.NET平臺以及模仿Java的C#語言。

6.Java 執行過程

用Java語言來編寫源代碼，把它編譯成Java Class文件，然后在Java VM中運行class文件；當編寫程序時，通過調用類(Java API)中的方法來訪問系統資源，而當程序運行時，它通過調用class文件中實現了Java API的方法也滿足程序的Java API調用。Java VM和Java API一起組成了一個“平臺“，所有Java程序都在其上編譯和運行，因此，它們有時也被稱作Java運行時環境。Java VM的主要任務是裝載class文件并且執行其中的字節碼。Java VM包含一個類裝載器(class loader)，它可以從程序和API裝載class文件；而Java API的類只在程序執行中需要時才會被裝載。（如上圖）

Java字節碼由執行引擎來執行。而不同的Java VM中，其執行引擎的實現可能各不相同。最簡單的執行引擎不是一次性解釋字節碼，而另一種稱為“即時編譯器(just-in-time compiler)”的執行引擎執行速度更快，但要消耗更多的內存資源。即時編譯模式下，第一次被執行的字節碼會被編譯成本地機器代碼并緩存下來以實現“復用”。第三種執行引擎是所謂的自適應優化器，此種方法中，虛擬機始的時候解釋字節碼，介是會監視運行中程序的活動，并且記錄下使用最頻繁的代碼。程序運行時，虛擬機只把那些活動最頻繁的代碼編譯成本地代碼，而不頻繁的代碼則仍然保留為字節碼由虛擬機解釋執行。自適應優化器可以使得Java VM在80%-90%的時間里執行被優化過的本地代碼，而只需要編譯10%- 20%對性能有影響的代碼。最后一種虛擬機由硬件芯片構成，它用本地方法執行Java字節碼，其執行引擎內嵌于芯片中。

三、Servlet與JSP

1. Servlet是什么?

在Client/Server應用的發展過程中，Java提供了一整套Client/Server解決方案，在這個方案中，程序可以自動地下載到客戶端并執行，這就是applet。但是它僅僅是問題的一半，問題的另一半就是Servlet。Servlet可以被認為是服務器端的applet。Servlet被Web服務器加載和執行，就如同applet被瀏覽器加載和執行一樣。Servlet從客戶端(通過Web服務器)接收請求，執行某種作業，然后返回結果。使用servlet的基本流程如下：

• 客戶端通過HTTP提出請求。

• Web服務器接收該請求并將其發給Servlet。如果這個Servlet尚未被加載，Web服務器將把它加載到Java虛擬機并且執行它。

• Servlet將接收該HTTP請求并執行某種處理。

• Servlet將向Web服務器返回應答。

• Web服務器將從Servlet收到的應答發送給客戶端。

由于servlet是在服務器上執行，通常與applet相關的安全性的問題并不需實現。要注意的是Web瀏覽器并不直接和Servlet通信，Servlet是由Web服務器加載和執行的。而Servlet是用Java編寫的，所以它們一開始就是平臺無關的。這樣，Java編寫一次就可以在任何平臺運行(write once，run anywhere)的承諾就同樣可以在服務器上實現了。Servlet還有一些CGI腳本所不具備的獨特優點：

• Servlet是持久的。Servlet只需Web服務器加載一次，而且可以在不同請求之間保持服務(例如一次數據庫連接)。與之相反，CGI腳本是短暫的、瞬態的。每一次對CGI腳本的請求，都會使Web服務器加載并執行該腳本。一旦這個CGI腳本運行結束，它就會被從內存中清除，然后將結果返回到客戶端。CGI腳本的每一次使用，都會造成程序初始化過程(例如連接數據庫)的重復執行。

• Servlet是與平臺無關的。如前所述，servlet是用Java編寫的，它自然也繼承了Java的平臺無關性。

• Servlet是可擴展的。由于servlet是用Java編寫的，它就具備了Java所能帶來的所有優點。Java是健壯的、面向對象的編程語言，它很容易擴展以適應你的需求。servlet自然也具備了這些特征。

• Servlet是安全的。從外界調用一個servlet的惟一方法就是通過Web服務器。這提供了高水平的安全性保障，尤其是在你的Web服務器有防火墻保護的時候。

Setvlet可以在多種多樣的客戶機上使用。由于Servlet是用Java編寫的，所以你可以很方便地在HTML中使用它們，就像你使用applet一樣。那么，Servlet是怎樣執行的？怎樣來寫一個Servlet，它的基本架構是怎么樣的？這些問題，將在后面部分給予介紹。

2.JSP與Servlet

現在已經對Servlet有了大概的了解，現在我們就來說說JSP和Servlet的關系。

JSP是一種腳本語言，包裝了Java Servlet系統的界面，簡化了Java和Servlet的使用難度，同時通過擴展JSP標簽(TAG)提供了網頁動態執行的能力。盡管如此，JSP仍沒有超出Java和Servlet的范圍，不僅JSP頁面上可以直接寫Java代碼，而且JSP是先被譯成Servlet之后才實際運行的。JSP在服務器上執行，并將執行結果輸出到客戶端瀏覽器，我們可以說基本上與瀏覽器無關。它是與JavaScript不同的，JavaScript是在客戶端的腳本語言，在客戶端執行，與服務器無關。那么JSP是什么？就是Servlet。

JSP與Servlet之間的主要差異在于，JSP提供了一套簡單的標簽，和HTML融合的比較好，可以使不了解Servlet的人可以做出動態網頁來。對于Java語言不熟悉的人(比如像我)，會覺得JSP開發比較方便。JSP修改后可以立即看到結果，不需要手工編譯，JSP引擎會來做這些工作；而Servelt還需要編譯，重新啟動Servlet引擎等一系列動作。但是在JSP中，HTML與程序代碼混雜在一起，而Servlet卻不是這樣。也許大家比較混亂了，那么Servlet又是什么？下面我們對JSP的運行來做一個簡單的介紹，告訴大家怎樣來執行一個JSP文件：

當Web服務器(或Servlet引擎,應用服務器)支持JSP引擎時，JSP引擎會照著JSP的語法，將JSP文件轉換成Servlet代碼源文件，接著Servlet會被編譯成Java可執行字節碼(bytecode)，并以一般的Servlet方式載入執行。簡單來說就是，*.jsp文件 -jasper引擎-> *.java文件 -javac編譯器-> .class (JVM運行)。

JSP語法簡單，可以方便的嵌入HTML之中，很容易加入動態的部分，方便的輸出HTML。在Servlet中輸出HTML則需要調用特定的方法，對于引號之類的字符也要做特殊的處理，加在復雜的HTML頁面中作為動態部分，比起JSP來說是比較困難的。除去了轉換和編譯階段，JSP和Servlet之間的區別實在是不大。

JSP引擎通常架構在Servlet引擎之上，本身就是一個Servlet，把JSP文件轉譯成Servlet源代碼，再調用Java編譯器，編譯成Servlet。這也是JSP在第一次調用時速度比較慢的原因，在第一次編譯之后，JSP與Servlet速度相同。下面我們來看看為什么他們在第一次編譯后再編譯的速度相同。

在整個運行過程中，JSP引擎會檢查編譯好的JSP(以Servlet形式存在)是否比原始的JSP文件還新。如果是，JSP引擎不會編譯；如果不是，表示JSP文件比較新，就會重新執行轉譯與編譯的過程。為了有個深刻的了解，我們看一下JSP的運行和開發環境：

• 瀏覽器：常見的瀏覽器有IE和火狐等。

• 據庫：常用的數據庫有Oracle,SQL Server,Informix,DB2,Sybase,Access,MySQL等。

• 操作系統：常見的有Windows,Linux,以及各種Unix系統。

• Web服務器：常見的有IIS,Apache,Netscape Enterprise Server等。

• JSP引擎：一般JSP引擎都以Servlet引擎為基礎，并以Servlet的形式出現。同時，在各種免費和商業引擎的實現中，Servlet引擎和JSP引擎通常也是一起出現，我們成為Servlet/JSP引擎，或從某種成為JSP引擎。JSP引擎是可以提供JSP和Servlet運行支持并對其生存周期進行管理的系統級實體。

在JSP頁面第一次被請求時，JSP引擎會將JSP原始文件轉換成Servlet源代碼，然后調用Java編譯器，編譯成Servlet并在Servlet引擎中執行。當再次有請求的時候，JSP引擎會見差異編譯好的JSP是否比原來的JSP原始文件要新。如果是，則運行Servlet；如果不是，表示文件已經更新的了，就會從新執行轉換和編譯的過程。

說到這里，也基本把JSP和Servlet的關系說清楚了，從我的感覺上看用JSP就可以了，簡單又方便，又可以和Bean很好的兼容使用，功能又很強大，為什么又出現了Servlet，它又有什么用？何況它的編寫又相對復雜。為了把問題說得更清楚一點，我想在這里說一下歷史，順便再講一下為什么還要用Servlet，Servlet的好處是什么？

簡單的說，SUN首先發展出Servlet，其功能比較強勁，體系設計也很先進。只是，它輸出HTML語句還是采用了老的CGI方式，是一句一句輸出。所以，編寫和修改HTML非常不方便。后來SUN推出了類似于ASP的嵌入式的JSP（是Servlet發展的產物），把JSP TAG嵌入到HTML語句中，這樣，就大大簡化和方便了網頁的設計和修改。新型的網絡語言如ASP，PHP，JSP都是嵌入型的SCRIPT語言。

從Web三層結構的角度看，一個Web項目最少分三層：data layer(數據層),business layer(業務層), presentation layer(展示層)。當然也可以更復雜。S用來寫business layer是很強大的，但是對于寫presentation layer就很不方便。JSP則主要是為了方便寫presentation layer而設計的。當然也可以寫business layer。寫慣了ASP，PHP，CGI的朋友，經常會不自覺的把presentation layer和business layer混在一起。把數據庫處理信息放到JSP中，其實，它應該放在business layer中。

根據SUN自己的推薦，JSP中應該僅僅存放與presentation layer有關的內容，也就是說，只放輸出HTML網頁的部份。而所有的數據計算，數據分析，數據庫聯結處理，統統是屬于business layer，應該放在JAVA BEANS中。通過JSP調用JAVA BEANS，實現兩層的整合。

實際上，微軟推出的DNA技術，簡單說，就是ASP+COM/DCOM技術。與JSP+BEANS完全類似，所有的presentation layer由ASP完成，所有的business layer由COM/DCOM完成。通過調用，實現整合。現在微軟推出的.NET也是通過這個理念，所有的presentation layer由ASP.NET完成，business layer由C#或VB.NET或VC.NET來完成。

為什么要采用這些組件技術呢？因為單純的ASP/JSP語言是非常低效率執行的，如果出現大量用戶點擊，純SCRIPT語言很快就到達了他的功能上限，而組件技術就能大幅度提高功能上限，加快執行速度。另外一方面，純SCRIPT語言將presentation layer和business layer混在一起，造成修改不方便，并且代碼不能重復利用。如果想修改一個地方，經常會牽涉到十幾頁code，采用組件技術就只改組件就可以了。

綜上所述，Servlet是一個早期的不完善的產品，寫business layer很好，寫presentation layer就很不好，并且兩層混雜，顯得十分混亂。所以，推出JSP+BAEN，用JSP寫presentation layer，用BAEN寫business layer。SUN自己的意思也是將來用JSP替代Servlet。

看了上面的敘述，大家可能對JSP與Servlet共存有了比較好的認識。可以看到JSP和Bean結合后的的實用性，強大的表現功能，易用性都是Servlet所不能及的。那么是不是Servlet就被取代了？不是！在以后的發展中，它還是有著巨大的作用的。上面只不過是將了問題的一方面，下面我們來看看Servlet本身的特點。由于它是由java來寫的，所以相關的特點我們就不說了，上文已經有了詳細的介紹，我們來看看其他的特點，Servlet是用于開發服務器端應用程序的一種編程模型，如果只是一個普通的java應用，可以不使用Servlet來編寫，但是如果想要提供基于web的服務能力，那么就必須按照這種模型來編寫，而且Servlet也必須允許在符合Servlet規范的java web server or app server之上，否則無法運行。除非你自己實現一個Web server，但是其復雜度是比較高的，特別是在企業級應用中，對系統的穩定性和健壯性都要求比較高，所以Servlet的模型實際上是簡化了編寫穩健的服務器端的應用開發過程。Servlet 可以作為提供web服務能力的一個接入方式，現在也許可以理解了什么是Servlet什么是JSP，它們之間的關系是怎樣的。好了，知識鋪墊我們就說到這了。我已經盡最大的努力來說明Servlet與JSP了，畢竟我不是開發啊。想深入了解JSP與Servlet的朋友可以可以看看Java Web開發的相關書箱。下面我們來說一說JSP運行過程。

3.JSP 運程過程

一個JSP頁面有多個客戶訪問，下面是第一個客戶訪問JSP頁面時候，JSP頁面的執行流程：

• 客戶通過瀏覽器向服務器端的JSP頁面發送請求

• JSP引擎檢查JSP文件對應的Servlet源代碼是否存在，若不存在轉向第4步，否則執行下一步

• JSP引擎檢查JSP頁面是否需要修改，若沒修改，轉向第5步，否則執行下一步

• JSP引擎將JSP頁面文件轉譯為Servlet源代碼（相應的 .java 代碼）

• JSP引擎將Servlet源代碼編譯為相應字節碼（ .class代碼 ）

• JSP引擎加載字節碼到內存

• 字節碼處理客戶請求，并將結果返回給客戶

在不修改JSP頁面的情況下，除了第一個客戶訪問JSP頁面需要經過以上幾個步驟外，以后訪問該JSP頁面的客戶請求，直接發送給JSP對應的字節碼程序處理，并將處理結果返回給客戶，這種情況下，JSP頁面既不需要啟動服務器，以便重新加載修改后的JSP頁面。

四、Tomcat

1.概述

通過上面的講解大家對JSP與Servlet已經有所理解，最起碼知道它們是做什么的，說到底它們都是程序設計語言，是幫助我們更好的編寫程序。大家都知道，不管是Servlet也好，還是JSP也好它們編寫出來的應用程序都是要運行的。在Web服務器的支持下可以執行解析并且運行，最終能被用戶所看到并操作，這是才我們的最終目的。那能實現對JSP與Servlet解析并運行的Web服務器有哪些呢？（注，我們一般說能解析并運行JSP與Servlet的程序為Web服務器，可在JSP與Servlet這里我們稱為Web容器。在下面的內容中我們就說Web容器，也就是Web服務器）

2.常見的web容器

商業版：

• Sun GlassFish Enterprise Server

• Sun Java System Web Server

• JBoss Enterprise Application Platform

• WebLogic Application Server

• Caucho's Resin Server

• WebSphere Application Server

• NetWeaver

非商業版：

• Apache Tomcat

• Apache Geronimo

• GlassFish

• JBoss Application Server

• Jetty

• Tiny Java Web Server

• Eclipse Virgo

注，用的最多的不是Tomcat，我們這里主要講解tomcat。

3.Tomcat 簡介

Sun推出的JSP（Java Server Pages）是一種運行于服務器端的動態網頁開發技術，它基于Java技術。執行JSP時需要在Web服務器上架設一個編譯JSP網頁的引擎。Tomcat服務器是Apache組織開發的一種JSP引擎同時支持Servlet，本身具有Web服務器的功能，可以作為獨立的Web服務器來使用。但是，在作為Web服務器方面，Tomcat處理靜態HTML頁面時不如Apache迅速，也沒有Apache健壯，所以我們一般將Tomcat與Apache配合使用，讓Apache對網站的靜態頁面請求提供服務，而Tomcat作為專用的JSP引擎，提供JSP解析，以得到更好的性能。并且Tomcat本身就是Apache的一個子項目，所以Tomcat對Apache提供了強有力的支持。對于大多數網站來說，Tomcat是一個很不錯的選擇。

Tomcat 在嚴格意義上并不是一個真正的應用服務器，它只是一個可以支持運行Serlvet/JSP的Web容器，不過Tomcat也擴展了一些應用服務器的功能，如JNDI，數據庫連接池，用戶事務處理等等。Tomcat 是一種具有JSP環境的Servlet容器。Servlet容器是代替用戶管理和調用 Servlet的運行時外殼。那么什么是Servlet容器呢？

Servlet容器，負責處理客戶請求。當客戶請求來到時，Servlet容器獲取請求，然后調用某個Servlet，并把Servlet的執行結果返回給客戶。當客戶請求某個資源時，Servlet容器使SERVLETREQUEST對象把客戶的請求信息封裝起來，然后調用JAVA Servlet API中定義的Servlet的一些生命周期方法，完成Servlet的執行，接著把Servlet執行的要返回給客戶的結果封裝到SERVLETRESPONSE對象中，最后SERVLET容器把客戶的請求發送給客戶，完成為客戶的一次服務過程。

4.Tomcat 體系結構

Tomcat 支持Servlet 2.5和JSP 2.1的規范，它由一組嵌套的層次和組件組成，一般可分為以下四類：

• 頂級組件：位于配置層次的頂級，并且彼此間有著嚴格的對應關系（如，Server、Service）；

• 連接器：連接客戶端（可以是瀏覽器或Web服務器）請求至Servlet容器，

• 容器：包含一組其它組件，如Engine、Host、Content；

• 被嵌套的組件：位于一個容器當中，但不能包含其它組件（如，Realm（用戶賬戶數據庫）、valve（基于用戶的認證）、logger（記錄日志））；

頂級組件：

(1).服務器(server)：Tomcat的一個實例，通常一個JVM只能包含一個Tomcat實例；因此，一臺物理服務器上可以在啟動多個JVM的情況下在每一個JVM中啟動一個Tomcat實例，每個實例分屬于一個獨立的管理端口。這是一個頂級組件。

(2).服務(service)：一個服務組件通常包含一個引擎和與此引擎相關聯的一個或多個連接器。給服務命名可以方便管理員在日志文件中識別不同服務產生的日志。一個server可以包含多個service組件，但通常情下只為一個service指派一個server。

連接器類組件：

連接器(connectors)：負責連接客戶端（可以是瀏覽器或Web服務器）請求至Servlet容器內的Web應用程序，通常指的是接收客戶發來請求的位置及服務器端分配的端口。默認端口通常是HTTP協議的8080，管理員也可以根據自己的需要改變此端口。一個引擎可以配置多個連接器，但這些連接器必須使用不同的端口。默認的連接器是基于HTTP/1.1的Coyote。同時，Tomcat也支持AJP、JServ和JK2連接器。

容器類組件：

(1).引擎(Engine)：引擎通是指處理請求的Servlet引擎組件，即Catalina Servlet引擎，它檢查每一個請求的HTTP首部信息以辨別此請求應該發往哪個host或context，并將請求處理后的結果返回的相應的客戶端。嚴格意義上來說，容器不必非得通過引擎來實現，它也可以是只是一個容器。如果Tomcat被配置成為獨立服務器，默認引擎就是已經定義好的引擎。而如果Tomcat被配置為Apache Web服務器的提供Servlet功能的后端，默認引擎將被忽略，因為Web服務器自身就能確定將用戶請求發往何處。一個引擎可以包含多個host組件。

(2).主機(Host)：主機組件類似于Apache中的虛擬主機，但在Tomcat中只支持基于FQDN的“虛擬主機”。一個引擎至少要包含一個主機組件。

(3).上下文(Context)：Context組件是最內層次的組件，它表示Web應用程序本身。配置一個Context最主要的是指定Web應用程序的根目錄，以便Servlet容器能夠將用戶請求發往正確的位置。Context組件也可包含自定義的錯誤頁，以實現在用戶訪問發生錯誤時提供友好的提示信息。

被嵌套類(nested)組件：

這類組件通常包含于容器類組件中以提供具有管理功能的服務，它們不能包含其它組件，但有些卻可以由不同層次的容器各自配置。
(1).閥門(Valve)：用來攔截請求并在將其轉至目標之前進行某種處理操作，類似于Servlet規范中定義的過濾器。Valve可以定義在任何容器類的組件中。Valve常被用來記錄客戶端請求、客戶端IP地址和服務器等信息，這種處理技術通常被稱作請求轉儲(request dumping)。請求轉儲valve記錄請求客戶端請求數據包中的HTTP首部信息和cookie信息文件中，響應轉儲valve則記錄響應數據包首部信息和cookie信息至文件中。
(2).日志記錄器(Logger)：用于記錄組件內部的狀態信息，可被用于除Context之外的任何容器中。日志記錄的功能可被繼承，因此，一個引擎級別的Logger將會記錄引擎內部所有組件相關的信息，除非某內部組件定義了自己的Logger組件。
(3).領域(Realm)：用于用戶的認證和授權；在配置一個應用程序時，管理員可以為每個資源或資源組定義角色及權限，而這些訪問控制功能的生效需要通過Realm來實現。Realm的認證可以基于文本文件、數據庫表、LDAP服務等來實現。Realm的效用會遍及整個引擎或頂級容器，因此，一個容器內的所有應用程序將共享用戶資源。同時，Realm可以被其所在組件的子組件繼承，也可以被子組件中定義的Realm所覆蓋。

引擎(Engine)：引擎是指處理請求的Servlet引擎組件，即Catalina Servlet引擎，它從HTTPconnector接收請求并響應請求。它檢查每一個請求的HTTP首部信息以辨別此請求應該發往哪個host或context，并將請求處理后的結果返回的相應的客戶端。嚴格意義上來說，容器不必非得通過引擎來實現，它也可以是只是一個容器。如果Tomcat被配置成為獨立服務器，默認引擎就是已經定義好的引擎。而如果Tomcat被配置為Apache Web服務器的提供Servlet功能的后端，默認引擎將被忽略，因為Web服務器自身就能確定將用戶請求發往何處。一個引擎可以包含多個host組件。

Tomcat連接器架構：基于Apache做為Tomcat前端的架構來講，Apache通過mod_jk、mod_jk2或mod_proxy模塊與后端的Tomcat進行數據交換。而對Tomcat來說，每個Web容器實例都有一個Java語言開發的連接器模塊組件，在Tomcat中，這個連接器是org.apache.catalina.Connector類。這個類的構造器可以構造兩種類別的連接器：HTTP/1.1負責響應基于HTTP/HTTPS協議的請求，AJP/1.3負責響應基于AJP的請求。但可以簡單地通過在server.xml配置文件中實現連接器的創建，但創建時所使用的類根據系統是支持APR(Apache Portable Runtime)而有所不同。APR是附加在提供了通用和標準API的操作系統之上一個通訊層的本地庫的集合，它能夠為使用了APR的應用程序在與Apache通信時提供較好伸縮能力時帶去平衡效用。同時，需要說明的是，mod_jk2模塊目前已經不再被支持了，mod_jk模塊目前還apache被支持，但其項目活躍度已經大大降低。因此，目前更常用 的方式是使用mod_proxy模塊。

如果支持APR：

• HTTP/1.1：org.apache.cotote.http11.Http11AprProtocol

• AJP/1.3：org.apache.coyote.ajp.AjpAprProtocol

如果不支持APR：

• HTTP/1.1: org.apache.coyote.http11.Http11Protocol

• AJP/1.3: org.apache.jk.server.JkCoyoteHandler

連接器協議：

Tomcat的Web服務器連接器支持兩種協議：AJP和HTTP，它們均定義了以二進制格式在Web服務器和Tomcat之間進行數據傳輸，并提供相應的控制命令。

AJP(Apache JServ Protocol)協議：目前正在使用的AJP協議的版本是通過JK和JK2連接器提供支持的AJP13，它基于二進制的格式在Web服務器和Tomcat之間傳輸數據，而此前的版本AJP10和AJP11則使用文本格式傳輸數據。

HTTP協議：誠如其名稱所表示，其是使用HTTP或HTTPS協議在Web服務器和Tomcat之間建立通信，此時，Tomcat就是一個完全功能的HTTP服務器，它需要監聽在某端口上以接收來自于商前服務器的請求。

5.Tomcat 工作模式

(1).獨立的Servlet容器

Tomcat 的默認工作模式，作為獨立的Servlet容器，是內置在Web服務器中的一部分，是指使用基于JAVA的Web服務器的情形。其他兩種方式是TOMCAT與其他服務器集成的方式。

(2).進程內的Servlet容器

Servlet容器作為Web服務器的插件和JAVA容器的實現。Web服務器的插件在內部地址空間打開一個JVM（JAVA VIRTUAL MACHINE）使JAVA容器得以在內部運行。如有某個需要調用Servlet的請求，插件將取得對此請求的控制并將它傳遞（使用JNI）給JAVA容器。進程內的容器對于多線程、單進程的服務器非常適合，并且提供了很好的運行速度，只是伸縮性有所不足。

注，JNI是JAVA NATIVE INTERFACE的縮寫，是JAVA本地調用接口，通過JNI，JAVA程序可以和其他語言編寫的本地程序進行通信。

(3).進程外的Servlet容器

Servlet容器運行于Web服務器之外的地址空間，并且作為Web服務器的插件和JVM使用IPC（如TCP/IP）進行通信。進程外容器的反應時間不如進程內的容器，但有較好的伸縮性、穩定性等性能。

IPC INTERPROCESS COMMUNICATION（進程間通信）的簡寫，它是實現進程間通信的一種技術。

6.Tomcat 的組織結構

Tomcat是一個基于組件的服務器，它的構成組件都是可配置的，其中最外層的給件是CATALINA SERVLET容器，其他的組件按照一定的格式要求配置在這個頂層容器中。Tomcat的各個組件是server.xml文件中配置的，Tomcat服務器默認情況下對各種組件都有默認的實現，下面通過分析server.xml文件來理解Tomcat的各個組件是如何組織的。

?

01.<Server>????? 頂層元素，代表一個服務器 02.<Service>? 頂層元素，是Connector的集合，只有一個Engine 03.<Connectior/>??????? 連接器類元素，代表通信接口 04.<Engine>?? 容器類元素，為特定的Service組件處理所有客戶請求，可包含多個Host 05.<Host>??? 為特定的虛擬主機處理所有客戶請求 06.<Context>???? 為特定的WEB應用處理所有客戶請求 07.</Context> 08.</Host> 09.</Engine> 10.</Service> 11.</Server>

Tomcat中真正處理客戶請求與生成響應的三個組件是Engine 、Host、 Context。為了幫助大家更好的理解Tomcat的組織結構，請看下圖：

好了，說到這里有關Tomcat的相關理論知識我們就講的差不多了，在下面的一篇博客中我們將講解Tomcat的安裝與配置。希望大家有所收^_^……

?

?

from:?http://www.it165.net/admin/html/201309/1852.html

總結

以上是生活随笔為你收集整理的Tomcat系列之Java技术详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。