[轉] tomcat和web伺服器,應用伺服器的關系

Tomcat伺服器是一個免費的開放源代碼的Web應用伺服器。因為Tomcat技術先進、性能穩定且免費，是以深受Java愛好者的喜愛并得到了部分軟體開發商的認可，成為目前比較流行的Web應用伺服器。

一、Tomcat與應用伺服器

到目前為止，Tomcat一直被認為是Servlet/JSP API的執行器，也就所謂的Servlet容器。然而，Tomcat并不僅僅如此，它還提供了JNDI和JMX API的實作機制。盡管如此，Tomcat仍然還不能算是應用伺服器，因為它不提供大多數J2EE API的支援。

很有意思的是，目前許多的應用伺服器通常把Tomcat作為它們Servlet和JSP API的容器。由于Tomcat允許開發者隻需通過加入一行緻謝，就可以把Tomcat嵌入到它們的應用中。遺憾的是，許多商業應用伺服器并沒有遵守此規則。

對于開發者來說，如果是為了尋找利用Servlet、JSP、JNDI和JMX技術來生成Java Web應用的話，選擇Tomcat是一個優秀的解決方案；但是為了尋找支援其他的J2EE API，那麼尋找一個應用伺服器或者把Tomcat作為應用伺服器的輔助，将是一個不錯的解決方案；第三種方式是找到獨立的J2EE API實作，然後把它們跟Tomcat結合起來使用。雖然整合會帶來相關的問題，但是這種方式是最為有效的。。

二、Tomcat與Web伺服器

Tomcat是提供一個支援Servlet和JSP運作的容器。Servlet和JSP能根據實時需要，産生動态網頁内容。而對于Web伺服器來說， Apache僅僅支援靜态網頁，對于支援動态網頁就會顯得無能為力；Tomcat則既能為動态網頁服務，同時也能為靜态網頁提供支援。盡管它沒有通常的Web伺服器快、功能也不如Web伺服器豐富，但是Tomcat逐漸為支援靜态内容不斷擴充。大多數的Web伺服器都是用底層語言編寫如C，利用了相應平台的特征，是以用純Java編寫的Tomcat執行速度不可能與它們相提并論。

一般來說，大的站點都是将Tomcat與Apache的結合，Apache負責接受所有來自用戶端的HTTP請求，然後将Servlets和JSP的請求轉發給Tomcat來處理。Tomcat完成處理後，将響應傳回給Apache，最後Apache将響應傳回給用戶端。

最近在javaword上發現的一篇文章，大拿寫的，鬥膽把它翻譯出來。為了不贻害大家我把英文連接配接貼出來：http://www.javaworld.com/javaworld/jw-01-2008/jw-01-tomcat6.html

文中as表示企業應用級伺服器，ws表示web伺服器

當java開發者談論企業級應用伺服器(application server)的時候，tomcat常常被看作既是application server也是web server。畢竟，tomcat在輕量級的開發方面是目前最流行的選擇之一，在很多方面它也能滿足一個application server的需求--盡管tomcat被設計成一個web server. 本文中，大拿Jeff Hanson 來給我們說說tomcat是as還是ws，不過首先他給我們解釋了as，ws以及java ee容器之間的差別，然後他給我們評估了tomcat在java企業級開發的各個方面的适用度。

java 開發者都在激烈的讨論tomcat是否是個as。不過大家是公說公有理，婆說婆有理。有的人說tomcat絕對是as，有人說肯定不是。事實是，tomcat常常被當成as使用，而且有時它在某些方面還真是和這個角色。對開發者來說，用tomcat做as，隻要它能勝任就ok了，管它是as還是ws呢？

我在本文像大家解釋tomcat是as還是ws。首先我來解釋as,ws以及j2ee容器之間的差別，然後來看看tomcat作為ws在那些地方可以當作as來用。在這裡我向大家展示了一個可擴充的架構，它從一個輕量級的tomcat開始，還包括了一個複雜的面向服務的架構soa，它可以讓你的j2ee 應用服務更加的成熟。

j2ee作為一個參考點

j2ee是開我們開發服務端java應用的實際标準。它是其它服務端java技術的基礎，當然也包括as。當我們談論ws和as時，j2ee的compliance就是一個非常重要的考證因素。

j2ee擴充了j2se，以便支援ws，企業級元件模型，可管理的apis，通信協定等。這樣就可以設計和實作面向服務的架構了。

一個規範的j2ee應用伺服器必須支援如下的特性：EJB server 和容器，jndi，jms架構，jta，jca。j2ee server常常支援一個分層類加載器，以便它能加載或者再加載ejb，war，manifest-specified等等。

j2ee也為用戶端應用定義了一個容器，servlet，和ejb元件。有了它們提供的架構和功能，我們部署，持久化，執行各種元件就友善多了。

j2ee也定義了一種用來連接配接j2ee應用，as和企業資訊系統的架構，比如erp系統，大型機系統，資料庫系統，以及非java的應用。jca為j2ee 應用同eis之間提供了統一的接口，相當于一個資源擴充卡。

所謂的j2ee as ，它需要支援j2ee一些特性，但不是全部的特性（如figure1）。使用as能夠給你在預測試的環境(能夠提供所有的java企業級開發服務)下host一個系統帶來很大的友善。在有些時候，當我們的服務隻是需要j2ee server的一兩個特性的執行環境下時，as還會帶來不必要的重載。

比如說，好多基于java的web應用隻是需要一個as/容器，像servlet，jsp，jdbc，它們在ws就是很好的選擇。在這種情況下你可能選擇各種架構來建構一個piecemeal系統。有的開發者就會選擇用tomcat來代替as。

通常，是否用as或ws取決于應用元件之間的通信類型。

EARs, WARs, JARs, and Java EE

一個j2ee應用肯呢個包含一個或更多j2ee元件，像ejb，web models，資源擴充卡，j2ee應用的用戶端models。每個j2ee元件都有相應的配置描述--一個用來描述這個元件的xml檔案。java元件用jar 檔案格式來組織。

jar檔案格式是基于zip檔案格式的，它能夠綁定多個j2ee元件在一個檔案裡。一個jar檔案包含了java類檔案，xml檔案，輔助資源，靜态html檔案，以及一些别的j2ee元件。一個标準的java web應用被放在war裡面，它隻是jar的擴充。一個标準的j2ee應用被放在ear裡面，它也是jar的一個擴充而已。

一個war檔案就是一個特殊的jar檔案，它包含了web應用元件，像servlet，jsp檔案，html檔案，配置描述，共用jar檔案等等。war檔案可以部署到ws上，比如說tomcat。

一個ear檔案也是一個ieteshu的jar檔案，它包含了j2ee應用元件，像war檔案，ejbs，資源擴充卡等等。ear檔案能夠被部署在jboss，websphere，weblogic等一些企業級伺服器裡面。j2ee as在運作時加載ear檔案，然後部署裡面的元件，部署是依據裡面的配置描述來的。

ear檔案裡面也會包含很多個web應用還附帶着别的資源和輔助元件。把一個ear部署到j2ee as環境的話，as能夠分别通過類加載器和資源加載器來隔離每個web應用到不同的context裡面。web應用在as環境裡還可以共享公共的資源，比如說utility類檔案。

jar檔案格式是基于zip檔案格式的，它能夠把各種j2ee元件綁定成一個檔案。一個jar檔案包括了java class檔案，xml描述檔案，輔助資源，靜态html檔案，以及别的相關的j2ee.一個标準的java web 應用部署在war裡面，它也是一個個jar檔案，隻不過多了一個war的字尾。一個标準的j2ee應用部署在一個ear裡面，它也是一個jar檔案，和war一樣，就是多了個ear的字尾而已。

war檔案裡面包含了web應用的元件像servlets，jsp檔案，html檔案，配置描述，共用jar檔案等等。war能夠部署在ws上，比如說tomcat上。

ear檔案裡面包含了j2ee應用元件像war檔案，ejbs，資源擴充卡等。ear部署在js裡面像jboss，weblogic，websphere等等。js在運作時加載ear檔案，然後部署它裡面的元件，像web 應用，資源擴充卡，ejbs，等等，這些都是根據配置描述裡的介紹進行的。

ear檔案能包含多個web應用，還有别的資源，以及輔助元件。我們開發的ear檔案必須在js的結構内，才能根據指定的class加載和資源加載上下文來分開每個web應用。web應用在js環境裡能共享公共類等檔案。

在一個j2ee環境裡，我們設計了專門的容器來處理元件分離和資源共享。這些容器被js管理。容器能夠在j2ee元件部署和執行的地方提供分離上下文。容器也在元件之間提供了抽象層，這樣他們就很少能夠直接影響對方了。相反，元件可以通過協定和容器的api來給彼此或外部server提供接口。抽象層讓容器能夠提供元件所需的輔助服務，比如說連接配接池，事物管理，狀态管理等。

web應用 vs 企業級應用

對有些人來說，把很多人搞糊塗還有一點，那就是我們如何區分企業級應用和web應用。一般來說，一個java企業級應用定義了如下的元件和技術：

EAR files

Java Servlets

JavaServer Pages or JavaServer Faces

Enterprise JavaBeans (EJB)

Java Authentication and Authorization Service (JAAS)

J2EE Connector Architecture

JavaBeans Activation Framework (JAF)

JavaMail

Java Message Service (JMS)

Java Persistence API (JPA)

Java Transaction API (JTA)

The Java Management Extensions (JMX) API

Java API for XML Processing (JAXP)

The Java API for XML-based RPC (JAX-RPC)

The Java Architecture for XML Binding (JAXB)

The SOAP with Attachments API for Java (SAAJ)

Java Database Connectivity (JDBC) framework

java web應用是java企業級應用的一個子集，它包括

WAR files

Java Servlets

JavaServer Faces or JavaServer Pages

Java Database Connectivity (JDBC) framework

流行的架構像,Apache Struts, Spring, Hibernate,還有别的很多元件,它們已經讓java企業級應用和javaweb應用的界限便的很模糊了,每個架構都提供了稍微不同的觀點，但它們都是在解決同一個問題。每個架構都在解決某個具體問題上很有效，可能它們都是用了不同的技術。

也許，當我們仔細觀察這些元件在企業級和web應用這兩個方面的不同行為時，它們之間的模糊界限可能會變的清晰些。

Java EE application scenarios

在一個典型的j2ee web應用裡，一個html用戶端對一個server發出了一個請求，這個請求被web容器處理後，調用了配置在它裡面的用來處理指定請求的servlet。

一旦servlet接收到了最初的請求，它把一些請求轉發到别的地方去，這樣做是為了實作必須的業務邏輯來完成我們的請求。

絕大多數業務服務或者元件都需要請求通路資料庫，或者資訊系統。有的時候在業務服務和資料庫之間出現了一個抽象層，它用來保護資料庫。daos做這種抽象層.當dao調用完成後，我們就是用一個或多個java beans，來把相應資料傳送回去。ok，這樣我們就把相應資料給傳回去了。

在圖六裡面隻需要有限的j2ee技術就可以實作，包括JDBC, JSP，或者别的顯示技術，tomcat或者别的web server都提供了servlet和jsp引擎，它們可以用圖六的請況下。

複雜的應用

現在，我們來假設下我們給這個應用添加一些需求，不同的業務元件之間的異步通信。在一個基于java的系統裡，我們可以使用jms來實作。如圖7

很多web servers都不能提供jms規範，但是我們可以很容易的給一個ws環境添加一個jms實作。是以在圖7的情況下，我們可以很容易的用ws做伺服器。

下一步，假設我們在業務服務和不同的企業資訊系統之間添加了一個連接配接實作。j2ee給我們提供了jca 标準來實作這個需求。圖8顯示了jca

到現在，這個架構已經有點複雜了吧，仔細看看，它也更像一個js了吧。ws像tomcat很有可能需要和别的架構結合才能來滿足這個需求，但是這樣的話

系統的管理和監控就顯得有點不切實際了。

最終我們來看看圖9給我們的解決方案，它相對複雜，基于java，面向服務的架構使用所有值錢講過的技術。它還包括war配置，ejb，web services等等。

圖9的架構就已經需要一個可測試的，可擴充的，可維護的js了。一個有正規技術水準的開發團隊能夠使用tomcat做web層，也可以用tomcat整合各種技術和架構來

支援這些業務層和資料層。但是無論你怎麼做，這樣都不是很可靠，特别你要給别人一個可選擇的成熟的應用服務。

在本文的示例中我們可以知道java 企業級應用的可擴充性，還有不斷增長的複雜性在平時是很常見的現象。tomcat可能在開始的時候能滿足你的需求，

但是當系統望後走的時候我們就會發現tomcat有點不那麼靠譜了，因為系統的需求變得複雜了，變得難以配置，管理維護和監控了。js在這方面比ws要

強很多，它在容器和部署上下文之間提供了很好的附加技術來整合這下東東，在很多情況下，選擇一個js遠比ws要效率高，當然這隻是對那些要跑很成時間的系統。

我們從前面所見的應用演化能看出來，apache的tomcat可以用來做應用服務，特别是不是很複雜的web 應用。從前面的圖中我們知道，tomcat是應用的最

廣泛的web server環境。tomcat的流行是因為它易于使用，支援很多java web開發的标準特性，包括war部署，jndi資源，jdbc資料源，jsp支援，會話管理

，支援虛拟主機，支援叢集，還支援jmx管理和監控。tomcat也是java企業級開發的最愛，因為他在運作時的效率無人能比的。

在第6版的tomcat裡面，一些新特性已近加入進來，包括同comet處理異步http請求，線程池共享，無阻塞連接配接，加強了jmx的管理和監控，servlet2.5，jsp2.1扽高等

即使有了這些新特性，tomcat仍然不能搞定整個j2ee。因為tomcat和别的web server不足的地方還有很多。像分布式事務，ejbs，jms。

當我們的應用需要這些特性的時候，我們常常使用as比如jboss，Geronimo, WebLogic, WebSphere, or Glassfish等等。很多as實際上用tomcat做它們的web容器。

總結：

as和ws正式的差別很清楚，但是現實世界的區分并不是很明顯。但是tomcat嚴格的來說并不是一個應用服器，本文已經對此做出了解釋。

當我們決定為我們自己應用或者系統選擇server的時候，最好是把系統的需求拆分開來，再看看我們需要哪些j2ee元件。

對那些簡單的，不需要擴充的web應用我們可以用tomcat，它是個快速，可靠，輕量的解決方案。

對那些更加複雜的企業級應用，soas，或者更高擴充web 應用，我就需要成熟的as來為我們提供更加有效的選擇。

About the author

作者

Jeff Hanson has more than 20 years experience as a software engineer, including working as senior engineer for the

Windows OpenDoc project and as chief architect for the Zareus SOA platform. The author of numerous articles and books,

he is the chief architect for Max Software Inc., where he leads design and implementation teams building desktop and server

applications for the content-control industry using C++, PHP, and JEE