[转] 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