tomcat是企业应用级服务器还是web服务器?

coutoperator 2010-04-21

最近在javaword上发现的一篇文章,大拿写的,斗胆把它翻译出来。为了不贻害大家我把英文连接贴出来:http://www.javaworld.com/javaworld/jw-01-2008/jw-01-tomcat6.html

文中as表示企业应用级服务器,ws表示web服务器

当java开发者谈论企业级应用服务器(applicationserver)的时候,tomcat常常被看作既是applicationserver也是webserver。毕竟,tomcat在轻量级的开发方面是目前最流行的选择之一,在很多方面它也能满足一个applicationserver的需求--尽管tomcat被设计成一个webserver.本文中,大拿JeffHanson来给我们说说tomcat是as还是ws,不过首先他给我们解释了as,ws以及javaee容器之间的区别,然后他给我们评估了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应用服务器必须支持如下的特性:EJBserver和容器,jndi,jms框架,jta,jca。j2eeserver常常支持一个分层类加载器,以便它能加载或者再加载ejb,war,manifest-specified等等。

j2ee也为客户端应用定义了一个容器,servlet,和ejb组件。有了它们提供的框架和功能,我们部署,持久化,执行各种组件就方便多了。

j2ee也定义了一种用来连接j2ee应用,as和企业信息系统的架构,比如erp系统,大型机系统,数据库系统,以及非java的应用。jca为j2ee应用同eis之间提供了统一的接口,相当于一个资源适配器。

所谓的j2eeas,它需要支持j2ee一些特性,但不是全部的特性(如figure1)。使用as能够给你在预测试的环境(能够提供所有的java企业级开发服务)下host一个系统带来很大的方便。在有些时候,当我们的服务只是需要j2eeserver的一两个特性的执行环境下时,as还会带来不必要的重载。

比如说,好多基于java的web应用只是需要一个as/容器,像servlet,jsp,jdbc,它们在ws就是很好的选择。在这种情况下你可能选择各种框架来构建一个piecemeal系统。有的开发者就会选择用tomcat来代替as。

通常,是否用as或ws取决于应用组件之间的通信类型。

EARs,WARs,JARs,andJavaEE

一个j2ee应用肯呢个包含一个或更多j2ee组件,像ejb,webmodels,资源适配器,j2ee应用的客户端models。每个j2ee组件都有相应的配置描述--一个用来描述这个组件的xml文件。java组件用jar文件格式来组织。

jar文件格式是基于zip文件格式的,它能够绑定多个j2ee组件在一个文件里。一个jar文件包含了java类文件,xml文件,辅助资源,静态html文件,以及一些别的j2ee组件。一个标准的javaweb应用被放在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等一些企业级服务器里面。j2eeas在运行时加载ear文件,然后部署里面的组件,部署是依据里面的配置描述来的。

ear文件里面也会包含很多个web应用还附带着别的资源和辅助组件。把一个ear部署到j2eeas环境的话,as能够分别通过类加载器和资源加载器来隔离每个web应用到不同的context里面。web应用在as环境里还可以共享公共的资源,比如说utility类文件。

jar文件格式是基于zip文件格式的,它能够把各种j2ee组件绑定成一个文件。一个jar文件包括了javaclass文件,xml描述文件,辅助资源,静态html文件,以及别的相关的j2ee.一个标准的javaweb应用部署在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企业级应用定义了如下的组件和技术:

EARfiles

JavaServlets

JavaServerPagesorJavaServerFaces

EnterpriseJavaBeans(EJB)

JavaAuthenticationandAuthorizationService(JAAS)

J2EEConnectorArchitecture

JavaBeansActivationFramework(JAF)

JavaMail

JavaMessageService(JMS)

JavaPersistenceAPI(JPA)

JavaTransactionAPI(JTA)

TheJavaManagementExtensions(JMX)API

JavaAPIforXMLProcessing(JAXP)

TheJavaAPIforXML-basedRPC(JAX-RPC)

TheJavaArchitectureforXMLBinding(JAXB)

TheSOAPwithAttachmentsAPIforJava(SAAJ)

JavaDatabaseConnectivity(JDBC)framework

javaweb应用是java企业级应用的一个子集,它包括

WARfiles

JavaServlets

JavaServerFacesorJavaServerPages

JavaDatabaseConnectivity(JDBC)framework

流行的框架像,ApacheStruts,Spring,Hibernate,还有别的很多组件,它们已经让java企业级应用和javaweb应用的界限便的很模糊了,每个框架都提供了稍微不同的观点,但它们都是在解决同一个问题。每个框架都在解决某个具体问题上很有效,可能它们都是用了不同的技术。

也许,当我们仔细观察这些组件在企业级和web应用这两个方面的不同行为时,它们之间的模糊界限可能会变的清晰些。

JavaEEapplicationscenarios

在一个典型的j2eeweb应用里,一个html客户端对一个server发出了一个请求,这个请求被web容器处理后,调用了配置在它里面的用来处理指定请求的servlet。

一旦servlet接收到了最初的请求,它把一些请求转发到别的地方去,这样做是为了实现必须的业务逻辑来完成我们的请求。

绝大多数业务服务或者组件都需要请求访问数据库,或者信息系统。有的时候在业务服务和数据库之间出现了一个抽象层,它用来保护数据库。daos做这种抽象层.当dao调用完成后,我们就是用一个或多个javabeans,来把相应数据传送回去。ok,这样我们就把相应数据给传回去了。

在图六里面只需要有限的j2ee技术就可以实现,包括JDBC,JSP,或者别的显示技术,tomcat或者别的webserver都提供了servlet和jsp引擎,它们可以用图六的请况下。

复杂的应用

现在,我们来假设下我们给这个应用添加一些需求,不同的业务组件之间的异步通信。在一个基于java的系统里,我们可以使用jms来实现。如图7

很多webservers都不能提供jms规范,但是我们可以很容易的给一个ws环境添加一个jms实现。所以在图7的情况下,我们可以很容易的用ws做服务器。

下一步,假设我们在业务服务和不同的企业信息系统之间添加了一个连接实现。j2ee给我们提供了jca标准来实现这个需求。图8显示了jca

到现在,这个架构已经有点复杂了吧,仔细看看,它也更像一个js了吧。ws像tomcat很有可能需要和别的框架结合才能来满足这个需求,但是这样的话

系统的管理和监控就显得有点不切实际了。

最终我们来看看图9给我们的解决方案,它相对复杂,基于java,面向服务的架构使用所有值钱讲过的技术。它还包括war配置,ejb,webservices等等。

图9的架构就已经需要一个可测试的,可扩展的,可维护的js了。一个有正规技术水平的开发团队能够使用tomcat做web层,也可以用tomcat整合各种技术和框架来

支持这些业务层和数据层。但是无论你怎么做,这样都不是很可靠,特别你要给别人一个可选择的成熟的应用服务。

在本文的示例中我们可以知道java企业级应用的可扩展性,还有不断增长的复杂性在平时是很常见的现象。tomcat可能在开始的时候能满足你的需求,

但是当系统望后走的时候我们就会发现tomcat有点不那么靠谱了,因为系统的需求变得复杂了,变得难以配置,管理维护和监控了。js在这方面比ws要

强很多,它在容器和部署上下文之间提供了很好的附加技术来整合这下东东,在很多情况下,选择一个js远比ws要效率高,当然这只是对那些要跑很成时间的系统。

我们从前面所见的应用演化能看出来,apache的tomcat可以用来做应用服务,特别是不是很复杂的web应用。从前面的图中我们知道,tomcat是应用的最

广泛的webserver环境。tomcat的流行是因为它易于使用,支持很多javaweb开发的标准特性,包括war部署,jndi资源,jdbc数据源,jsp支持,会话管理

,支持虚拟主机,支持集群,还支持jmx管理和监控。tomcat也是java企业级开发的最爱,因为他在运行时的效率无人能比的。

在第6版的tomcat里面,一些新特性已近加入进来,包括同comet处理异步http请求,线程池共享,无阻塞连接,加强了jmx的管理和监控,servlet2.5,jsp2.1扽高等

即使有了这些新特性,tomcat仍然不能搞定整个j2ee。因为tomcat和别的webserver不足的地方还有很多。像分布式事务,ejbs,jms。

当我们的应用需要这些特性的时候,我们常常使用as比如jboss,Geronimo,WebLogic,WebSphere,orGlassfish等等。很多as实际上用tomcat做它们的web容器。

总结:

as和ws正式的区别很清楚,但是现实世界的区分并不是很明显。但是tomcat严格的来说并不是一个应用服器,本文已经对此做出了解释。

当我们决定为我们自己应用或者系统选择server的时候,最好是把系统的需求拆分开来,再看看我们需要哪些j2ee组件。

对那些简单的,不需要扩展的web应用我们可以用tomcat,它是个快速,可靠,轻量的解决方案。

对那些更加复杂的企业级应用,soas,或者更高扩展web应用,我就需要成熟的as来为我们提供更加有效的选择。

Abouttheauthor

作者

JeffHansonhasmorethan20yearsexperienceasasoftwareengineer,includingworkingasseniorengineerforthe

WindowsOpenDocprojectandaschiefarchitectfortheZareusSOAplatform.Theauthorofnumerousarticlesandbooks,

heisthechiefarchitectforMaxSoftwareInc.,whereheleadsdesignandimplementationteamsbuildingdesktopandserver

applicationsforthecontent-controlindustryusingC++,PHP,andJEE

相关推荐