Sun  的關于 JavaBean 規范見：http://java.sun.com/javase/technologies/desktop/javabeans/docs/spec.html，其中可下載到 JavaBean 規范的  PDF 文檔。


實際中的問題

首 先，當然還是要說它的屬性及 setter/getter 方法。屬性以小寫字母開頭，駝峰命名格式，相應的 getter/setter 方法是 get/set 接上首字母大寫的屬性名。多數情況是對的，且當前流行的 IDE(Eclipse、JBuilder) 也都認這個死理，這里 NetBean 值得表揚一下。但要是碰到些遺留的代碼中屬性名不規范，或者有些人就是頑固，或真是對屬性命名猶豫不決時的寫下的代碼時，那還是有得你研究一下。

這里來看看 Eclipse 為幾個屬性生成的 getter/setter 方法吧：

sName(從 C 轉過來的，受匈牙利的影響，認為 Name 是個字符串，所以加個前綴 s)           getSName()/setSName(String name)
URL (平時認為是縮略語/專有名詞，理當全部大寫，這在我們對待 ID 時經常發生的)           getURL()/setURL(String url)

上 面第一個由 Eclipse 為我們生成的 getSName()/setSName(String name) 方法，參照 JavaBean  規范來說，其實是錯誤的。如果出現這樣的方法，放到我們的標簽(像 Struts 標簽，如 <s:textfield name="sName"/>)，或是進行 Hibernate/iBatis 那種映射時，你就能收到報 找不到 sName 屬性相應的 getter/setter 方法 那樣的錯誤。不是明明有 getSName() 和 setSName(String name)，可是方法名錯了，正確的版本應該是 getsName() 和 setsName(String name)。

前面首先解釋了屬性命名不規范產生問題的原因，現在就來更仔細的了解關于 JavaBean 屬性及其 getter/setter 方法的約定，有些是硬性的。


屬性與存取訪問的規定

為 JavaBean 創建屬性時，必須牢記：縮略語通常被視為一個獨立的單詞，而不是單個字母。例如，URL 對應的屬性名應該用 url，相應的 getUrl()/setUrl()，所以 ID 還是用 id 作為屬性吧，相應的 getId()/setId()。

規 范中另一個特別的地方就是，第二個字母為大寫的屬性名要區別對待。如果屬性名的第二個字母是大寫的，那么該屬性名直接用作 getter/setter 方法中 get/set 的后部分，就是說大小寫不變。這就是為什么 sName 對應的存取方法是 getsName()/setsName() 的原因，不能不說這條規則很令人費解。那就更有必要看看下面表格的規范：

    來自J道Banq http://www.jdon.com/artichect/dbdead.htm

隨著用戶的爆發量增長，在某個凌晨醒來時，你發現：數據庫已死。

傳統軟件系統實則應該叫數據庫軟件系統，是一個數據庫系統，開發這樣的系統非常簡單，成本 也非常低廉，只要根據需求先設計好數據表結構，然后，就找一些大學畢業生寫大量SQL語句，雖然還使用 JAVA/PHP/.NET等語言，但實際上這些語言只是將SQL送往數據庫執行的運輸工，沒有什么價值和地位。

所以，這樣的系統運行在互聯網環境下以后，主要負載就集中在數據庫的SQL運行上，也就是說：整個軟件系統性能關鍵點就集中在數據庫上了，數據庫是性能 主角，是王者；雖然你購置了昂貴的Websphere/weblogic等應用服務器，但是由于Java只是運輸工，根本起不到性能上負載分擔的作用。

著名的社區網站MySpace就是因為一個好的idea，用戶瘋狂增長，但是系統卻不能平滑承受增長的用戶訪問，這些用戶訪問網站緩慢、無法訪問甚至丟失數據，他們經過幾次傷筋動骨的架構升級，在微軟SQLServer直接技術支持下， 好容易才勉強應付過去。看看他們痛苦經歷，你是否也愿意再來一次呢？詳細情況： http://www.jdon.com/jivejdon/thread/34601.html

從中可以看出，數據庫性能微調和挖潛總是有限度的，對數據庫性能優化提高性能的步伐永遠趕不上用戶增長量， 有人也提出數據庫集群的概念，其實數據庫集群是一個騙人概念，一般只是備份，在集群數量和failover上有制約， 否則，數據庫巨頭Oracle不會跑到JavaEE陣營搖旗吶喊，還最早推出EJB3服務器，并揚言要收購JavaEE過去老大 Bea Weblogic。

很顯然，數據庫成已經為軟件系統的主要性能瓶頸了，單純依靠數據庫自救的方式已經行不通，是宣布數據庫退出主角時候了，那么由誰來宣布：教皇數據庫已死？無疑是Java。

Java社區早在本世紀初就提出中間件概念，用以取代數據庫地位，實則就是將軟件系統主要負載從數據庫上轉移到中間件服務器上，分擔負載。 也就是說：Java社區提出：既然數據庫已經成為瓶頸，修修補補也無濟于事，不如放棄它，不再依賴它。

也就是說：Java不再做SQL的運輸工，不再是跑龍套的了，而是主角，那么如何讓Java成為主角呢？那必須依賴對象這個概念，對象是生活在中間件服務器內存中，它又是數據庫數據的業務封裝，它和數據庫有著 千絲萬縷的關系，但是它又和關系數據庫存在天然矛盾，兩者水火不容。

過去，我們是將業務邏輯寫成SQL送往數據庫執行，導致數據庫成為業務邏輯主要運行瓶頸，那么，如果我們將 業務邏輯用對象概念表達，而不是SQL，那么我們的業務邏輯就圍繞內存中的對象反復計算，這樣，負載不是集中在 對象運行的中間件服務器上（也就是應用服務器Weblogic/websphere/JBoss/Tomcat）？而對象/中間件都是用Java 語言表達的，無疑，這樣的架構，Java才成為主角。

再進一步想想：如果我們從軟件系統開始之初，就使用對象分析設計，不與數據庫沾邊，整個流程就完全OO，分析設計直至代碼都擺脫了數據庫影響，這個流程如下：

分析建模 細化設計(通過Evans DDD) 架構設計 代碼實現 調試測試 部署運行。

那么數據庫在什么時候建立呢？數據庫表結構的創建可以延緩到部署運行時，由Hibernate/EJB CMP/JPA等ORM技術自動實現。這樣， 整個上游環節就不涉及數據庫技術，而是使用更符合自然的表達OO方式，軟件質量就更高了。我在J道網站已經大量闡述了如何從OO分析 到OO實現的過程，包括我的Jdon框架也直接支持這樣一個自然方式。

現在，很多人已經理解，分析設計要用OO，但是數據庫是運行階段缺少不了的，確實，這是正確觀點，我們奪取數據庫的王位，不是將它打倒，只是理性和平移交權力重心而已，數據庫退出主角地位，讓位于Java中間件，也預示著過去數據庫為王的時代的結束， 但是數據庫會和操作系統一樣，成為我們現代軟件系統一個不可缺少重要的基礎環節。

正是基于這樣事實，雖然我早在2005年喊出“數據庫時代的終結一文，回帖長達幾百貼， 大部分是懷疑論，不信論，其實2003年國外TSS就有一篇“給數據庫休息吧” （休息不代表退休，而是退居幕后，就象操作系統作用一樣），由此可見，由于傳統觀點影響和不及時與國際新思想同步，國內數據庫保皇派還是有相當人數的。我 BanQ人微言輕，拋出這些觀點被保皇派譏諷為所瘋話，那么看看，著名ORM框架Hibernate和SEAM框架創始人Gavin King的一段觀點：

In almost all enterprise applications, the database is the primary bottleneck, and the least scalable tier of the runtime environment. 數據庫成為了大多數企業應用的主要瓶頸，也成為了運行環境中最不具伸縮性的層。... PHP/Ruby的用戶會說什么都不共享（share nothing）的架構照樣具有很好的伸縮性，.... 這些傻瓜真正想的是“除了數據庫以外什么都不共享(Share nothing except for the database)”的架構。更多參看這里

所謂伸縮性，就是彈性，整個軟件架構既支持小負載運行，也支持大負載支持，只要增加服務器即可； 由于軟件系統負載已經從SQL轉移到內存中的對象上，那么我們就可以通過增加這些應用服務器數量，通過分布式計算甚至云計算，達到業務對象在多臺應用服務 器之間傳遞共享，而不必通過數據庫這個環節，既減輕數據庫負載，又能輕松擴充性能，不必走 集中試大型主機之路，只要添置低廉PC服務器即可。經過權威測試：websphere/weblogic的20臺PC服務器集群性能不亞于一臺SUN/IBM的中型機，性價比已經一目了然了。

JavaEE的服務器的集群相對于Linux等操作系統集群的好處在于：JavaEE集群能夠針對某個繁忙負載大的具體業務功能進行集群，換句話說： 就是做到精確制導，精確解決問題，而顯然，Linux操作系統的集群則無法直至業務核心的。

從另外一個方面看：雖然現在PHP號稱走上對象路線，Ruby的鐵軌開始鋪進企業，但是他們的運行環境實則依賴數據庫的， 特別是Ruby On Rails還是最適合Evans DDD對象建模路線，但是目前來講還是"披著羊皮的狼"，批著DDD，實則是以數據庫中心。當然相信 ROR等將來會提供分布式計算環境，但是JavaEE在2002年時就通過EJB以及分布式緩存成熟穩定地提供分布式計算的中間件，并且已經大量成熟應用。

本文結束以前，我相信大家明白，在眾多語言平臺競爭中，為什么Java能夠擊敗過去拳王數據庫，奪得新的拳王冠軍，以及他的特點所在。有人可能會說：你忘記談.NET了，這個不用我回答你，用微軟中國董事長張亞勤的話回答：8年前.NET戰略很天真， 你會將你的重要業務企業計算依賴一個很天真不成熟的技術嗎？除非你自己也很天真:)。

  J2EE，Java2平臺企業版（Java2PlatformEnterpriseEdition），是Sun公司為企業級應用推出的標準(Platform)。Java平臺共分為三個主要版本JavaEE、JavaSE和JavaME。

  Sun公司在1998年發表1.2版本的時候，使用了新名稱Java2Platform，即Java2平臺，修改后的JDK稱為 Java2PlatformSoftwareDevelpingKit，并分為標準版(StandardEdition，J2SE),企業版 (EnterpriseEdition，J2EE)，微型版(MicroEdition，J2ME)。J2EE便由此誕生。

  Java2平臺包括標準版（J2SE）、企業版（J2EE）和微縮版（J2ME）三個版本。他們的范圍是：J2SE包含于J2EE中，J2ME包含了J2SE的核心類，但新添加了一些專有類。

  隨著Java技術的發展，J2EE平臺得到了迅速的發展，成為Java語言中最活躍的體系之一。現如今，J2EE不僅僅是指一種標準平臺，她更多的表達著一種軟件架構和設計思想。

  2005年6月，JavaOne大會召開，SUN公司公開JavaSE6。此時，Java的各種版本已經更名以取消其中的數字2：J2EE更名為JavaEE，J2SE更名為JavaSE，J2ME更名為Java ME。

一、配置系統管理（Admin Web Application）

大多數商業化的J2EE服務器都提供一個功能強大的管理界面，且大都采用易于理解的Web應用界面。Tomcat按照自己的方式，同樣提供一個成熟 的管理工具，并且絲毫不遜于那些商業化的競爭對手。Tomcat的Admin Web Application最初在4.1版本時出現，當時的功能包括管理context、data source、user和group等。當然也可以管理像初始化參數，user、group、role的多種數據庫管理等。在后續的版本中，這些功能將得 到很大的擴展，但現有的功能已經非常實用了。Admin Web Application被定義在自動部署文件：CATALINA_BASE/webapps/admin.xml 。（譯者注：CATALINA_BASE即tomcat安裝目錄下的server目錄）

你必須編輯這個文件，以確定Context中的docBase參數是絕對路徑。也就是說CATALINA_BASE/webapps /admin.xml的路徑是絕對路徑。作為另外一種選擇，你也可以刪除這個自動部署文件，而在server.xml文件中建立一個Admin Web Application的context，效果是一樣的。你不能管理Admin Web Application這個應用，換而言之，除了刪除CATALINA_BASE/webapps/admin.xml ，你可能什么都做不了。

如果你使用UserDatabaseRealm（默認），你將需要添加一個user以及一個role到CATALINA_BASE/conf/tomcat-users.xml文件中。你編輯這個文件，添加一個名叫“admin”的role 到該文件中，如下：

＜role name="admin"/＞

你同樣需要有一個用戶，并且這個用戶的角色是“admin”。象存在的用戶那樣，添加一個用戶（改變密碼使其更加安全）：

＜user name="admin"

            

            

            

            password="deep_dark_secret"

            

            

            

            roles="admin"/＞

            

            

當你完成這些步驟后，請重新啟動Tomcat，訪問http://localhost:8080/admin，你將看到一個登錄界面。Admin Web Application采用基于容器管理的安全機制，并采用了Jakarta Struts框架。一旦你作為“admin”角色的用戶登錄管理界面，你將能夠使用這個管理界面配置Tomcat。

二、配置應用管理（Manager Web Application）

Manager Web Application讓你通過一個比Admin Web Application更為簡單的用戶界面，執行一些簡單的Web應用任務。Manager Web Application被被定義在一個自動部署文件中：

CATALINA_BASE/webapps/manager.xml

你必須編輯這個文件，以確保context的docBase參數是絕對路徑，也就是說CATALINA_HOME/server/webapps/manager的絕對路徑。（譯者注：CATALINA_HOME即tomcat安裝目錄）

如果你使用的是UserDatabaseRealm，那么你需要添加一個角色和一個用戶到CATALINA_BASE/conf/tomcat-users.xml文件中。接下來，編輯這個文件，添加一個名為“manager”的角色到該文件中：

＜role name=”manager”＞

你同樣需要有一個角色為“manager”的用戶。像已經存在的用戶那樣，添加一個新用戶（改變密碼使其更加安全）：

＜user name="manager"

            

            

            

            password="deep_dark_secret"

            

            

            

            roles="manager"/＞

            

            

然后重新啟動Tomcat，訪問http://localhost/manager/list，將看到一個很樸素的文本型管理界面，或者訪問 http: //localhost/manager/html/list，將看到一個HMTL的管理界面。不管是哪種方式都說明你的Manager Web Application現在已經啟動了。

Manager application讓你可以在沒有系統管理特權的基礎上，安裝新的Web應用，以用于測試。如果我們有一個新的web應用位于/home/user /hello下在，并且想把它安裝到/hello下，為了測試這個應用，我們可以這么做，在第一個文件框中輸入“/hello”（作為訪問時的 path），在第二個文本框中輸入“file:/home/user/hello”（作為Config URL）。

Manager application還允許你停止、重新啟動、移除以及重新部署一個web應用。停止一個應用使其無法被訪問，當有用戶嘗試訪問這個被停止的應用時，將 看到一個503的錯誤??“503 - This application is not currently available”。

移除一個web應用，只是指從Tomcat的運行拷貝中刪除了該應用，如果你重新啟動Tomcat，被刪除的應用將再次出現（也就是說，移除并不是指從硬盤上刪除）。

三、部署一個web應用

有兩個辦法可以在系統中部署web服務。

1.拷貝你的WAR文件或者你的web應用文件夾（包括該web的所有內容）到$CATALINA_BASE/webapps目錄下。

2.為你的web服務建立一個只包括context內容的XML片斷文件，并把該文件放到$CATALINA_BASE/webapps目錄下。這個web應用本身可以存儲在硬盤上的任何地方。

如果你有一個WAR文件，你若想部署它，則只需要把該文件簡單的拷貝到CATALINA_BASE/webapps目錄下即可，文件必須以 “.war” 作為擴展名。一旦Tomcat監聽到這個文件，它將（缺省的）解開該文件包作為一個子目錄，并以WAR文件的文件名作為子目錄的名字。

接下來，Tomcat將在內存中建立一個context，就好象你在server.xml文件里建立一樣。當然，其他必需的內容，將從server.xml中的DefaultContext獲得。

部署web應用的另一種方式是寫一個Context XML片斷文件，然后把該文件拷貝到CATALINA_BASE/webapps目錄下。一個Context片斷并非一個完整的XML文件，而只是一個context元素，以及對該應用的相應描述。

這種片斷文件就像是從server.xml中切取出來的context元素一樣，所以這種片斷被命名為“context片斷”。

舉個例子，如果我們想部署一個名叫MyWebApp.war的應用，該應用使用realm作為訪問控制方式，我們可以使用下面這個片斷：

＜!--

            

            

            

            Context fragment for deploying MyWebApp.war

            

            

            

            --＞

            

            

            

            ＜Context path="/demo"

            

            

            

            docBase="webapps/MyWebApp.war"

            

            

            

            debug="0" privileged="true"＞

            

            

            

            ＜Realm className=

            

            

            

            "org.apache.catalina.realm.UserDatabaseRealm”

            

            

            

            resourceName="UserDatabase"/＞

            

            

            

            ＜/Context＞

            

            

四、配置虛擬主機（Virtual Hosts）

關于server.xml中“Host”這個元素，只有在你設置虛擬主機的才需要修改。虛擬主機是一種在一個web服務器上服務多個域名的機制，對 每個域名而言，都好象獨享了整個主機。實際上，大多數的小型商務網站都是采用虛擬主機實現的，這主要是因為虛擬主機能直接連接到Internet并提供相 應的帶寬，以保障合理的訪問響應速度，另外虛擬主機還能提供一個穩定的固定IP。

基于名字的虛擬主機可以被建立在任何web服務器上，建立的方法就是通過在域名服務器（DNS）上建立IP地址的別名，并且告訴web服務器把去往 不同域名的請求分發到相應的網頁目錄。因為這篇文章主要是講Tomcat，我們不準備介紹在各種操作系統上設置DNS的方法，如果你在這方面需要幫助，請 參考《DNS and Bind》一書，作者是Paul Albitz and Cricket Liu (O'Reilly)。為了示范方便，我將使用一個靜態的主機文件，因為這是測試別名最簡單的方法。

在Tomcat中使用虛擬主機，你需要設置DNS或主機數據。為了測試，為本地IP設置一個IP別名就足夠了，接下來，你需要在server.xml中添加幾行內容，如下：

　＜Server port="8005"







shutdown="SHUTDOWN" debug="0"＞







＜Service name="Tomcat-Standalone"＞







＜Connector className=







"org.apache.coyote.tomcat4.CoyoteConnector"







port="8080"







minProcessors="5" maxProcessors="75"







enableLookups="true"







redirectPort="8443"/＞







＜Connector className=







"org.apache.coyote.tomcat4.CoyoteConnector"







port="8443" minProcessors="5"







maxProcessors="75"







acceptCount="10" debug="0"







scheme="https" secure="true"/＞







＜Factory className="org.apache.coyote.







tomcat4.CoyoteServerSocketFactory"







clientAuth="false" protocol="TLS" /＞







＜/Connector＞







＜Engine name="Standalone"







defaultHost="localhost" debug="0"＞







＜!-- This Host is the default Host --＞







＜Host name="localhost"







debug="0" appBase="webapps"







unpackWARs="true" autoDeploy="true"＞







＜Context path="" docBase="ROOT" debug="0"/＞







＜Context path="/orders"







docBase="/home/ian/orders" debug="0"







reloadable="true" crossContext="true"＞







＜/Context＞







＜/Host＞







＜!-- This Host is the first







"Virtual Host": http://www.example.com/ --＞







＜Host name="www.example.com"







appBase="/home/example/webapp"＞







＜Context path="" docBase="."/＞







＜/Host＞







＜/Engine＞







＜/Service＞







＜/Server＞

Tomcat的server.xml文件，在初始狀態下，只包括一個虛擬主機，但是它容易被擴充到支持多個虛擬主機。在前面的例子中展示的是一個簡 單的 server.xml版本，其中粗體部分就是用于添加一個虛擬主機。每一個Host元素必須包括一個或多個context元素，所包含的context元 素中必須有一個是默認的context，這個默認的context的顯示路徑應該為空（例如，path=””）。

五、配置基礎驗證（Basic Authentication）

容器管理驗證方法控制著當用戶訪問受保護的web應用資源時，如何進行用戶的身份鑒別。當一個web應用使用了Basic Authentication（BASIC參數在web.xml文件中auto-method元素中設置），而有用戶訪問受保護的web應用 時，Tomcat將通過HTTP Basic Authentication方式，彈出一個對話框，要求用戶輸入用戶名和密碼。在這種驗證方法中，所有密碼將被以64位的編碼方式在網絡上傳輸。

注意：使用Basic Authentication通過被認為是不安全的，因為它沒有強健的加密方法，除非在客戶端和服務器端都使用HTTPS或者其他密碼加密碼方式（比如，在一個虛擬私人網絡中）。若沒有額外的加密方法，網絡管理員將能夠截獲（或濫用）用戶的密碼。

但是，如果你是剛開始使用 Tomcat，或者你想在你的web應用中測試一下基于容器的安全管理，Basic Authentication還是非常易于設置和使用的。只需要添加＜security-constraint＞和＜login-config＞兩個元素 到你的web應用的web.xml文件中，并且在CATALINA_BASE/conf/tomcat-users.xml文件中添加適當的＜role＞ 和＜user＞即可，然后重新啟動Tomcat。

下面例子中的web.xml摘自一個俱樂部會員網站系統，該系統中只有member目錄被保護起來，并使用Basic Authentication進行身份驗證。請注意，這種方式將有效的代替Apache web服務器中的.htaccess文件。

＜!--







Define the







Members-only area,







by defining







a "Security Constraint"







on this Application, and







mapping it to the







subdirectory (URL) that we want







to restrict.







--＞







＜security-constraint＞







＜web-resource-collection＞







＜web-resource-name＞







Entire Application







＜/web-resource-name＞







＜url-pattern＞/members/*＜/url-pattern＞







＜/web-resource-collection＞







＜auth-constraint＞







＜role-name＞member＜/role-name＞







＜/auth-constraint＞







＜/security-constraint＞







＜!-- Define the Login







Configuration for







this Application --＞







＜login-config＞







＜auth-method＞BASIC＜/auth-method＞







＜realm-name＞My Club







Members-only Area＜/realm-name＞







＜/login-config＞

六、配置單點登錄（Single Sign-On）

一旦你設置了realm和驗證的方法，你就需要進行實際的用戶登錄處理。一般說來，對用戶而言登錄系統是一件很麻煩的事情，你必須盡量減少用戶登錄驗證的次數。作為缺省的情況，當用戶第一次請求受保護的資源時，每一個web應用都會要求用戶登錄。

如果你運行了多個web應用，并且每個應用都需要進行單獨的用戶驗證，那這看起來就有點像你在與你的用戶搏斗。用戶們不知道怎樣才能把多個分離的應用整合成一個單獨的系統，所有他們也就不知道他們需要訪問多少個不同的應用，只是很迷惑，為什么總要不停的登錄。

Tomcat 4的“single sign-on”特性允許用戶在訪問同一虛擬主機下所有web應用時，只需登錄一次。為了使用這個功能，你只需要在Host上添加一個SingleSignOn Valve元素即可，如下所示：

＜Valve className=

            

            

            

            "org.apache.catalina.

            

            

            

            authenticator.SingleSignOn"

            

            

            

            debug="0"/＞

            

            

在Tomcat初始安裝后，server.xml的注釋里面包括SingleSignOn Valve配置的例子，你只需要去掉注釋，即可使用。那么，任何用戶只要登錄過一個應用，則對于同一虛擬主機下的所有應用同樣有效。使用single sign-on valve有一些重要的限制：

1.value必須被配置和嵌套在相同的Host元素里，并且所有需要進行單點驗證的web應用（必須通過context元素定義）都位于該Host下。

2.包括共享用戶信息的realm必須被設置在同一級Host中或者嵌套之外。

3.不能被context中的realm覆蓋。

4.使用單點登錄的web應用最好使用一個Tomcat的內置的驗證方式（被定義在web.xml中的＜auth-method＞中），這比自定義的驗證方式強，Tomcat內置的的驗證方式包括basic、digest、form和client-cert。

5.如果你使用單點登錄，還希望集成一個第三方的web應用到你的網站中來，并且這個新的web應用使用它自己的驗證方式，而不使用容器管理安全，那你基本上就沒招了。你的用戶每次登錄原來所有應用時需要登錄一次，并且在請求新的第三方應用時還得再登錄一次。

當然，如果你擁有這個第三方web應用的源碼，而你又是一個程序員，你可以修改它，但那恐怕也不容易做。

6.單點登錄需要使用cookies。

七、配置用戶定制目錄（Customized User Directores）

一些站點允許個別用戶在服務器上發布網頁。例如，一所大學的學院可能想給每一位學生一個公共區域，或者是一個ISP希望給一些web空間給他的客戶，但這又不是虛擬主機。在這種情況下，一個典型的方法就是在用戶名前面加一個特殊字符（~），作為每位用戶的網站，比如：

http://www.cs.myuniversity.edu/~username

http://members.mybigisp.com/~username

Tomcat提供兩種方法在主機上映射這些個人網站，主要使用一對特殊的Listener元素。Listener的className屬性應該是 org.apache.catalina.startup.UserConfig，userClass屬性應該是幾個映射類之一。

如果你的系統是Unix，它將有一個標準的/etc/passwd文件，該文件中的帳號能夠被運行中的Tomcat很容易的讀取，該文件指定了用戶的主目錄，使用PasswdUserDatabase 映射類。

＜Listener className=

            

            

            

            "org.apache.catalina.startup.UserConfig"

            

            

            

            directoryName="public_html"

            

            

            

            userClass="org.apache.catalina.

            

            

            

            startup.PasswdUserDatabase"/＞

            

            

web文件需要放置在像/home/users/ian/public_html或者/users/jbrittain/public_html一樣的目錄下面。當然你也可以改變public_html 到其他任何子目錄下。

實際上，這個用戶目錄根本不一定需要位于用戶主目錄下里面。如果你沒有一個密碼文件，但你又想把一個用戶名映射到公共的像/home一樣目錄的子目錄里面，則可以使用HomesUserDatabase類。

　＜Listener className=

            

            

            

            "org.apache.catalina.startup.UserConfig"

            

            

            

            directoryName="public_html"

            

            

            

            homeBase="/home"

            

            

            

            userClass="org.apache.catalina.

            

            

            

            startup.HomesUserDatabase"/＞

            

            

這樣一來，web文件就可以位于像/home/ian/public_html或者/home/jasonb/public_html一樣的目錄下。這種形式對Windows而言更加有利，你可以使用一個像c:home這樣的目錄。

這些Listener元素，如果出現，則必須在Host元素里面，而不能在context元素里面，因為它們都用應用于Host本身。

八、在Tomcat中使用CGI腳本

Tomcat主要是作為Servlet/JSP容器，但它也有許多傳統web服務器的性能。支持通用網關接口（Common Gateway Interface，即CGI）就是其中之一，CGI提供一組方法在響應瀏覽器請求時運行一些擴展程序。

CGI之所以被稱為通用，是因為它能在大多數程序或腳本中被調用，包括：Perl，Python，awk，Unix shell scrīpting等，甚至包括Java。

當然，你大概不會把一個Java應用程序當作CGI來運行，畢竟這樣太過原始。一般而言，開發Servlet總要比CGI具有更好的效率，因為當用戶點擊一個鏈接或一個按鈕時，你不需要從操作系統層開始進行處理。

Tomcat包括一個可選的CGI Servlet，允許你運行遺留下來的CGI腳本。

為了使Tomcat能夠運行CGI，你必須做如下幾件事：

1.把servlets-cgi.renametojar （在CATALINA_HOME/server/lib/目錄下）改名為servlets-cgi.jar。處理CGI的servlet應該位于Tomcat的CLASSPATH下。

2.在Tomcat的CATALINA_BASE/conf/web.xml 文件中，把關于＜servlet-name＞ CGI的那段的注釋去掉（默認情況下，該段位于第241行）。

3.同樣，在Tomcat的CATALINA_BASE/conf/web.xml文件中，把關于對CGI進行映射的那段的注釋去掉（默認情況下，該段位于第299行）。注意，這段內容指定了HTML鏈接到CGI腳本的訪問方式。

4.你可以把CGI腳本放置在WEB-INF/cgi 目錄下（注意，WEB-INF是一個安全的地方，你可以把一些不想被用戶看見或基于安全考慮不想暴露的文件放在此處），或者你也可以把CGI腳本放置在 context下的其他目錄下，并為CGI Servlet調整cgiPathPrefix初始化參數。這就指定的CGI Servlet的實際位置，且不能與上一步指定的URL重名。

5.重新啟動Tomcat，你的CGI就可以運行了。

在Tomcat中，CGI程序缺省放置在WEB-INF/cgi目錄下，正如前面所提示的那樣，WEB-INF目錄受保護的，通過客戶端的瀏覽器無法窺探到其中內容，所以對于放置含有密碼或其他敏感信息的CGI腳本而言，這是一個非常好的地方。

為了兼容其他服務器，盡管你也可以把CGI腳本保存在傳統的/cgi-bin目錄，但要知道，在這些目錄中的文件有可能被網上好奇的沖浪者看到。另外，在Unix中，請確定運行Tomcat的用戶有執行CGI腳本的權限。

九、改變Tomcat中的JSP編譯器（JSP Compiler）

在Tomcat 4.1（或更高版本，大概），JSP的編譯由包含在Tomcat里面的Ant程序控制器直接執行。這聽起來有一點點奇怪，但這正是Ant有意為之的一部分，有一個API文檔指導開發者在沒有啟動一個新的JVM的情況下，使用Ant。

這是使用Ant進行Java開發的一大優勢。另外，這也意味著你現在能夠在Ant中使用任何javac支持的編譯方式，這里有一個關于Apache Ant使用手冊的javac page列表。

使用起來是容易的，因為你只需要在＜init-param＞ 元素中定義一個名字叫“compiler”，并且在value中有一個支持編譯的編譯器名字，示例如下：

＜servlet＞

            

            ＜servlet-name＞jsp＜/servlet-name＞

            

            ＜servlet-class＞

            

            org.apache.jasper.servlet.JspServlet

            

            ＜/servlet-class＞

            

            ＜init-param＞

            

            ＜param-name＞logVerbosityLevel＜/param-name＞

            

            ＜param-value＞WARNING＜/param-value＞

            

            ＜/init-param＞

            

            ＜init-param＞

            

            ＜param-name＞compiler＜/param-name＞

            

            ＜param-value＞jikes＜/param-value＞

            

            ＜/init-param＞

            

            ＜load-on-startup＞3＜/load-on-startup＞

            

            ＜/servlet＞

            

            

當然，給出的編譯器必須已經安裝在你的系統中，并且CLASSPATH可能需要設置，那處決于你選擇的是何種編譯器。

十、限制特定主機訪問（Restricting Access to Specific Hosts）

有時，你可能想限制對Tomcat web應用的訪問，比如，你希望只有你指定的主機或IP地址可以訪問你的應用。這樣一來，就只有那些指定的的客戶端可以訪問服務的內容了。為了實現這種效 果，Tomcat提供了兩個參數供你配置：RemoteHostValve 和RemoteAddrValve。

通過配置這兩個參數，可以讓你過濾來自請求的主機或IP地址，并允許或拒絕哪些主機/IP。與之類似的，在Apache的httpd文件里有對每個目錄的允許/拒絕指定。例如你可以把Admin Web application設置成只允許本地訪問，設置如下：

＜Context path=

            

            

            

            "/path/to/secret_files" ...＞

            

            

            

            ＜Valve className="org.apache.

            

            

            

            catalina.valves.RemoteAddrValve"

            

            

            

            allow="127.0.0.1" deny=""/＞

            

            

            

            ＜/Context＞

            

            

如果沒有給出允許主機的指定，那么與拒絕主機匹配的主機就會被拒絕，除此之外的都是允許的。與之類似，如果沒有給出拒絕主機的指定，那么與允許主機匹配的主機就會被允許，除此之外的都是拒絕的。

  web服務器可以解析(handles)http協 議。當web服務器接收到一個http請求(request)，會返回一個http響應 (response)，例如送回一個html頁面。為了處理一個請求(request)，web服務器可以響應(response)一個靜態頁面或圖片， 進行頁面跳轉(redirect)，或者把動態響應(dynamic response)的產生委托(delegate)給一些其它的程序例如cgi腳本，jsp(javaserver pages)腳本，servlets，asp(active server pages)腳本，服務器端(server-side)javascript，或者一些其它的服務器端(server-side)技術。無論它們(譯者 注:腳本)的目的如何，這些服務器端(server-side)的程序通常產生一個html的響應(response)來讓瀏覽器可以瀏覽。

  要知道，web服務器的代理模型(delegation model)非常簡單。當一個請求(request)被送到web服務器里來時，它只單純的把請求(request)傳遞給可以很好的處理請求 (request)的程序(譯者注:服務器端腳本)。web服務器僅僅提供一個可以執行服務器端(server-side)程序和返回(程序所產生的)響 應(response)的環境，而不會超出職能范圍。服務器端(server-side)程序通常具有事務處理(transaction processing)，數據庫連接(database connectivity)和消息(messaging)等功能。

  雖然web服務器不支持事務處理或數據庫連接池，但它可以配置(employ)各種策略(strategies)來實現容錯性(fault tolerance)和可擴展性(scalability)，例如負載平衡(load balancing)，緩沖(caching)。集群特征(clustering—features)經常被誤認為僅僅是應用程序服務器專有的特征。

應用程序服務器(the application server)

  根據我們的定義，作為應用程序服務器，它通過各種協議，可以包括http，把商業邏輯暴露給(expose)客戶端應用程序。web服務器主要是處 理向瀏覽器發送html以供瀏覽，而應用程序服務器提供訪問商業邏輯的途徑以供客戶端應用程序使用。應用程序使用此商業邏輯就象你調用對象的一個方法 (或過程語言中的一個函數)一樣。

  應用程序服務器的客戶端(包含有圖形用戶界面(gui)的)可能會運行在一臺pc、一個web服務器或者甚至是其它的應用程序服務器上。在應用程序 服務器與其客戶端之間來回穿梭(traveling)的信息不僅僅局限于簡單的顯示標記。相反，這種信息就是程序邏輯(program logic)。正是由于這種邏輯取得了(takes)數據和方法調用(calls)的形式而不是靜態html，所以客戶端才可以隨心所欲的使用這種被暴露 的商業邏輯。

  在大多數情形下，應用程序服務器是通過組件(component)的應用程序接口(api)把商業邏輯暴露(expose)(給客戶端應用程序) 的，例如基于j2ee(java 2 platform, enterprise edition)應用程序服務器的ejb(enterprise javabean)組件模型。此外，應用程序服務器可以管理自己的資源，例如看大門的工作(gate-keeping duties)包括安全(security)，事務處理(transaction processing)，資源池(resource pooling)，和消息(messaging)。就象web服務器一樣，應用程序服務器配置了多種可擴展(scalability)和容錯(fault tolerance)技術。

一個例子

  例如，設想一個在線商店(網站)提供實時定價(real-time pricing)和有效性(availability)信息。這個站點(site)很可能會提供一個表單(form)讓你來選擇產品。當你提交查詢 (query)后，網站會進行查找(lookup)并把結果內嵌在html頁面中返回。網站可以有很多種方式來實現這種功能。我要介紹一個不使用應用程序 服務器的情景和一個使用應用程序服務器的情景。觀察一下這兩中情景的不同會有助于你了解應用程序服務器的功能。

情景1:不帶應用程序服務器的web服務器

  在此種情景下，一個web服務器獨立提供在線商店的功能。web服務器獲得你的請求(request)，然后發送給服務器端(server- side)可以處理請求(request)的程序。此程序從數據庫或文本文件(flat file，譯者注:flat file是指沒有特殊格式的非二進制的文件，如properties和xml文件等)中查找定價信息。一旦找到，服務器端(server-side)程序 把結果信息表示成(formulate)html形式，最后web服務器把會它發送到你的web瀏覽器。

  簡而言之，web服務器只是簡單的通過響應(response)html頁面來處理http請求(request)。

情景2:帶應用程序服務器的web服務器

  情景2和情景1相同的是web服務器還是把響應(response)的產生委托(delegates)給腳本(譯者注:服務器端(server -side)程序)。然而，你可以把查找定價的商業邏輯(business logic)放到應用程序服務器上。由于這種變化，此腳本只是簡單的調用應用程序服務器的查找服務(lookup service)，而不是已經知道如何查找數據然后表示為(formulate)一個響應(response)。這時當該腳本程序產生html響應 (response)時就可以使用該服務的返回結果了。

  在此情景中，應用程序服務器提供(serves)了用于查詢產品的定價信息的商業邏輯。(服務器的)這種功能(functionality)沒有指 出有關顯示和客戶端如何使用此信息的細節，相反客戶端和應用程序服務器只是來回傳送數據。當有客戶端調用應用程序服務器的查找服務(lookup service)時，此服務只是簡單的查找并返回結果給客戶端。

  通過從響應產生(response-generating)html的代碼中分離出來，在應用程序之中該定價(查找)邏輯的可重用性更強了。其他的 客戶端，例如收款機，也可以調用同樣的服務(service)來作為一個店員給客戶結帳。相反，在情景1中的定價查找服務是不可重用的因為信息內嵌在 html頁中了。

  總而言之，在情景2的模型中，在web服務器通過回應html頁面來處理http請求(request)，而應用程序服務器則是通過處理定價和有效性(availability)請求(request)來提供應用程序邏輯的。

警告(caveats)

  現在，xml web services已經使應用程序服務器和web服務器的界線混淆了。通過傳送一個xml有效載荷(payload)給服務器，web服務器現在可以處理數據和響應(response)的能力與以前的應用程序服務器同樣多了。

  另外，現在大多數應用程序服務器也包含了web服務器，這就意味著可以把web服務器當作是應用程序服務器的一個子集(subset)。雖然應用程 序服務器包含了web服務器的功能，但是開發者很少把應用程序服務器部署(deploy)成這種功能(capacity)(譯者注:這種功能是指既有應用 程序服務器的功能又有web服務器的功能)。相反，如果需要，他們通常會把web服務器獨立配置，和應用程序服務器一前一后。這種功能的分離有助于提高性 能(簡單的web請求(request)就不會影響應用程序服務器了)，分開配置(專門的web服務器，集群(clustering)等等)，而且給最佳 產品的選取留有余地。