容器tomcat虚拟主机

ISSN1000-9825,CODENRUXUEWE-mail:jos@iscas.
ac.
cnJournalofSoftware,Vol.
17,No.
5,May2006,pp.
11951203http://www.
jos.
org.
cnDOI:10.
1360/jos171195Tel/Fax:+86-10-625625632006byJournalofSoftware.
Allrightsreserved.
一个J2EE应用服务器的Web容器集成框架林泊,周明辉+,刘天成,黄罡,梅宏(北京大学信息科学技术学院软件研究所,北京100871)AWebContainerIntegrationFrameworkinJ2EEApplicationServersLINBo,ZHOUMing-Hui+,LIUTian-Cheng,HUANGGang,MEIHong(InstituteofSoftware,SchoolofElectronicsEngineeringandComputerScience,PekingUniversity,Beijing100871,China)+Correspondingauthor:Phn:+86-10-62757670,Fax:+86-10-62751792,E-mail:zhmh@sei.
pku.
edu.
cn,http://www.
sei.
pku.
edu.
cnLinB,ZhouMH,LiuTC,HuangG,MeiH.
AWebcontainerintegrationframeworkinJ2EEapplicationservers.
JournalofSoftware,2006,17(5):11951203.
http://www.
jos.
org.
cn/1000-9825/17/1195.
htmAbstract:RegardingtheshortcomingsfoundwiththetraditionalmethodofintegratingaJ2EE(Java2platformenterpriseedition)WebContainer,atwo-layeredWebcontainerintegrationframeworkisproposed:theouterlayerisindependentoftheWebcontainerimplementationandistheinterfacebetweentheWebcontainerandmanagementtools,deploymenttoolsandothermodules;theinnerlayerisanextensiontotheWebcontainer.
TheframeworkhasbeenimplementedontheJ2EEapplicationserverPKUAS(PekingUniversityApplicationServer).
Testresultshaveshownthatthisframeworkcansatisfythedesigngoalsofapluggable,unifiedconfigurableWebcontainer,anditsperformanceissatisfactory.
Keywords:J2EEapplicationserver;Webcontainer;integrationframework摘要:针对J2EE(Java2platformenterpriseedition)应用服务器集成Web容器的传统实现方式存在的不足,提出一个两层结构的Web容器集成框架:外层独立于Web容器实现,满足管理工具、部署工具等其他模块与Web容器的交互;内层则是对特定Web容器的包装、扩展或改良.
该框架已在J2EE应用服务器PKUAS(PekingUniversityApplicationServer)上得以实现.
测试结果表明,该框架具有良好的可插拔性,实现了应用服务器配置和管理机制的统一,且性能良好.
关键词:J2EE应用服务器;Web容器;集成框架中图法分类号:TP393文献标识码:AJ2EE(Java2platformenterpriseedition)[1]是Sun公司于1999年推出的Java企业计算平台规范与技术.
它通过提供企业计算环境所必需的各种服务,使得部署在J2EE平台上的基于构件的分布式应用可以实现高可用性、安全性、可扩展性和可靠性,是目前应用最为广泛的面向Web的应用系统结构规范.
本文为2005年中国计算机大会推荐优秀论文.
SupportedbytheNationalNaturalScienceFoundationofChinaunderGrantNos.
60125206,60233010,90412011(国家自然科学基金);theNationalHigh-TechResearchandDevelopmentPlanofChinaunderGrantNos.
2005AA112030,2005AA113031(国家高技术研究发展计划(863));theNationalGrandFundamentalResearch973ProgramofChinaunderGrantNo.
2002CB312003(国家重点基础研究发展计划项目(973))Received2005-06-15;Accepted2006-01-181196JournalofSoftware软件学报Vol.
17,No.
5,May2006J2EE采用多层分布式应用模型(如图1所示),包括表示层、业务层和数据层.
其中业务层的Web容器、EJB容器和J2EE服务构成J2EE应用服务器,为部署在其上的J2EE应用构件提供运行支持,日渐成为构造Internet应用的主流平台.
一般地,Web容器在接收到客户的Web请求时,会由相应的Web构件进行简单的业务处理,之后再将请求转发给EJB容器,由相应的EJB构件处理复杂业务逻辑并与数据层进行交互.
Web容器实现了Servlet/JSP[2]标准,负责为部署在其中的Web构件(Servlet和JSP(JavaServerPages))提供运行支持.
由于Servlet/JSP规范本身是一个独立的规范,并且早于J2EE规范产生,因此,Web容器实现的发展历程也要久于J2EE应用服务器(独立的Web容器实现一般被称作Web服务器),其各方面技术已经相当成熟稳定.
常见的开源产品如Tomcat,Jetty等均经受过大规模应用的考验.
为了充分利用Web容器多年来积淀的技术、最大程度地节约开发成本,集成第三方开源Web服务器已成为现今开源J2EE应用服务器实现的惯例.
J2EEservicesEJBcontainerEJBWebcontainerJSPAppletcontainerAppletApplicationclientcontainerApplicationClientDatabaseLegacySystemJ2SEJ2SETransactionServletJ2SEJ2EEservicesPresentationtierBusinesstierDatatierDataAccessLegacyIntegrationSecurityConcurrencyPersistenceJ2EEservicesJ2SETransactionSecurityConcurrencyPersistenceInteroperabilityInteroperabilityFig.
1J2EEarchitecture图1J2EE体系结构然而,在代码级集成一个独立的第三方产品势必面临许多问题,包括:用户界面不一致、管理接口不一致、配置方式不一致以及内部结构不一致等.
传统紧耦合的集成方式无法解决这些问题,主要体现为:第一,对集成的Web容器只在高层进行操作,而对其内部模块的可控制性较差.
在这种方案下,应用服务器只负责设定相关的参数和环境变量,而后调用Web容器自身的启动代码进行启动.
对于Web容器的内部模块应用服务器很难进行控制.
第二,配置文件、管理方式与应用服务器本身的机制不统一.
由于集成没有深入到Web容器的内部模块,从而导致了对Web容器的配置以及管理都需通过Web容器提供的机制.
也就是说,用户无法通过应用服务器的配置文件和管理工具[3]对整个应用服务器进行统一的配置或管理.
第三,对集成的Web容器有过强的依赖性.
Servlet/JSP标准仍然在升级演变,第三方Web容器产品也有自己的版本更新周期,而且,一般来说要短于应用服务器的更新周期.
对Web容器的强依赖性,意味着升级更换Web容器的代价大为提高,往往需要改动应用服务器中许多其他模块的代码,这就使得应用服务器中的Web容器的实现很难跟上集成的第三方产品的更新速度,导致应用服务器的竞争力下降.

为了解决以上问题,本文提出一个J2EE应用服务器中Web容器的集成框架,并给出该框架在北京大学自主开发的应用服务器——PKUAS(Pekinguniversityapplicationserver)上的实现过程.
本文第1节分析Web服务器的基本结构和不同实现的共同点.
第2节详细阐述两层结构的Web容器集成框架.
第3节在J2EE应用服务器PKUAS上实现该框架,并对实现结果进行性能评测与分析.
第4节对目前的相关工作进行考察,并与本文提出的框架进行比较.
最后一节总结全文.
林泊等:一个J2EE应用服务器的Web容器集成框架11971Web服务器分析1.
1Web服务器通常,一个完整的Web服务器包含一个或多个"虚拟主机".
所谓虚拟主机,就是在一个物理的服务器上配置多个域名,每个域名对应相同或不同的应用.
这样,客户端看起来好像是有多个主机;Web容器在收到请求时,根据客户端给出的域名来确定处理该请求的虚拟主机.
在每个虚拟主机中又可以部署一个或多个Web应用.
每个部署在服务器上的Web应用要提供对本应用的生命周期管理等功能.
尽管不同的Web服务器的实现各不相同,但都按照服务器-虚拟主机-应用的层次结构进行设计和管理.
1.
2Tomcat结构分析ApacheTomcat[4]是Servlet/JSP标准的参考实现,作为一个成功的、有着广泛应用的Web容器,Tomcat有着整齐而清晰的内部结构,如图2所示.
这是一个较为典型和完整的Web容器结构,其他实现或多或少具有类似的结构.
其中关键的模块有:Server.
一个Server模块代表了整个Tomcat容器.
它的属性代表了Web容器作为一个整体的特征.
一个Server模块主要包括一个或多个Service模块以及顶层的命名资源.
在运行期间,Server模块应监听port属性所指定的端口,并对于该端口接受的每一个连接读入其所传入的第1行信息并与shutdown属性所指定的字串进行比较:如果两者相吻合,则执行关闭服务器的步骤;否则,不执行任何操作并断开连接.
这种机制为容器的远程管理提供了可能.
Service.
一个Service模块代表了共享同一个Container实例(通常是Engine实例)的一个或多个Connector实例所组成的逻辑整体.
该Container负责处理这个Service中所有Connector接受的请求.
Service模块最主要的职责在于:允许加密的Connector以及普通的Connector连接到同一组Web应用.
同一个Connector不能同时存在于两个不同的Service中.
在同一个Java虚拟机中可以同时存在多个Service实例,但这些实例除了共享最基本的Java运行时类库以外,相互之间是完全独立的.
ServerFig.
2InnerstructureofTomcat图2Tomcat内部结构Connector.
Connector模块负责接受来自网络客户端的请求,并将请求的处理结果反馈给客户端.
每个Connector实例实际上实现的是一种网络传输协议,它将通过这种协议传入的客户端请求进行分析,构造相应的Request和Response实例,找出适合相应该请求的Container实例,调用该Container的invoke方法,并将Request和Response实例作为参数传入,最终将处理结果或者错误信息反馈给客户端.
Engine.
Engine是Container的子接口,它代表了整个Servlet引擎.
在运行中,Engine永远是Container层次结构的最高级,所以,其setParent()方法若如被调用将总是抛出IllegalArgumentException异常.
一个Engine的子Container通常是一个或多个的Host实例.
Host.
Host代表的实际上就是常说的"虚拟主机"的概念.
在一个TomcatWeb服务器中可以同时运行多个Host,每个Host都与一个特定的主机名以及任意个"别名"相绑定.
每个客户端的请求都会根据主机名映射到相应的Host进行处理.
Host的下级Container通常是一些Context实例.
Context.
一个Context就是一个独立的Web应用.
它包括了Web应用的所有Servlet类、JSP文件、静态页面和图片、Jar包、环境变量、各种配置参数以及其他各种资源.
Context的下级Container通常是Wrapper的1198JournalofSoftware软件学报Vol.
17,No.
5,May2006实例.
1.
3Jetty结构分析Jetty是由MortBayConsulting领导的开源JavaWeb容器项目[5].
Jetty项目起源于MortBay创始人GregWilkin的Java编程竞赛参赛作品,发展至今已有近10年的历史.
如今,Jetty以其小巧、高效以及高度的可嵌入性和稳定性得到了广泛的应用和认同.
与Tomcat类似,Jetty也按照功能模块的结构组织,但不具有Tomcat中的父子结构层次,模块与模块之间是一种关联和使用的关系.
比较显著的不同是,Jetty中没有一个显示地代表"虚拟主机"的模块,而是把虚拟主机的功能分别在应用级和服务器级进行实现.
在Jetty中,类HttpServer定义一个Web服务器;类HttpListener定义一个监听端口,类似于Tomcat中的Connector;而类HttpContext对应于Web应用.
2两层结构的Web容器集成框架针对文章开始部分指出的问题,以第1节Web服务器的分析为基础,本文提出一个两层结构的Web容器集成框架,把各种不同Web容器实现的配置抽象并规范化成同一种表示和配置方式,由框架来做适配,实现Web容器的无缝集成,从而实现应用服务器配置和管理机制的统一;同时,给予用户选择具体Web容器的自由.
这个框架能够将Web容器的具体实现对Web容器以外的模块完全屏蔽,同时,在这个框架下,各种不同结构的Web容器实现都能够被集成到应用服务器中来.
2.
1体系结构为了有效隔离Web容器的具体实现,集成框架包括两个层次:面向应用服务器其他模块的外层和面向特定Web容器实现的内层,如图2所示(当作为应用服务器中的一个模块时,Web容器需要提供被应用服务器其他模块访问的接口).
框架的外层定义应用服务器其他模块与Web容器的交互,例如管理工具需要对Web容器实施启动、停止和配置等一系列管理操作,部署工具需要部署Web构件到Web容器上等.
所有交互全部通过外层进行,而不对Web容器的内部实现有任何依赖性;框架的内层主要是针对特定Web容器实现的适配,通过一系列的映射或模拟,将特定Web容器所提供的功能"反映"为外层所暴露出来的结构.
在这样一个框架层次下,实现者可以同时集成多种Web容器,而无须对应用服务器的其他模块作任何修改.
InnerlayerWebcontainerimplementationOuterlayerInnercontainermanagerOutercontainermanagerVirtualhostInnervirtualhostOutervirtualhostJ2EEapplicationserverOthermodulesOthermodulesOthermodulesAppli-cationOuterapplicationInnerapplicationContainermanagerFig.
3Webcontainerintegrationframeworkarchitecture图3Web容器集成框架体系结构根据前面对Web容器的关键功能的深入分析,我们为集成框架提炼出3类实体:容器管理器、虚拟主机和林泊等:一个J2EE应用服务器的Web容器集成框架1199应用.
框架的内外层皆围绕这3类实体建立,以实现封装和隔离,如图3所示.
这3类实体之间存在一对多的父子关系,构成一个3层的树状结构.
对外界来说,每一个实体都是一个可操作的对象,它们反映了Web容器对外提供的主要功能.
下面是这3类实体的具体描述:容器管理器.
该实体代表了一个Web容器,它主要为具体Web容器实现以及它所下属的子实体提供生命周期管理等.
该实体定义Web容器的标识、监听的端口号、使用的协议类型(HTTP,HTTPS,AJP等).
容器管理器没有父实体,可以包含一个或多个虚拟主机作为子实体.
虚拟主机.
该实体主要用于部署应用.
其存在的目的是划分同一Web容器中不同应用的集合,使得应用集合之间相互独立.
该实体为本虚拟主机和下属的子实体提供生命周期管理等.
该实体的属性包括:虚拟主机的标识、虚拟主机的别名.
该实体与一个父实体即容器管理器实体关联,同时可以包含任意多个应用作为子实体.