资源web应用服务器

Vol.
15,No.
122004JournalofSoftware软件学报1000-9825/2004/15(12)1787OnceAS/Q:一个面向QoS的Web应用服务器黄涛1,2+,陈宁江1,2,3,魏峻1,张文博1,2,3,张勇1,2,31(中国科学院软件研究所软件工程技术研发中心,北京100080)2(中国科学院软件研究所计算机科学重点实验室,北京100080)3(中国科学院研究生院,北京100039)OnceAS/Q:AQoS-EnabledWebApplicationServerHUANGTao1,2+,CHENNing-Jiang1,2,3,WEIJun1,ZHANGWen-Bo1,2,3,ZHANGYong1,2,31(TechnologyCenterofSoftwareEngineering,InstituteofSoftware,TheChineseAcademyofSciences,Beijing100080,China)2(KeyLaboratoryofComputerScience,InstituteofSoftware,TheChineseAcademyofSciences,Beijing100080,China)3(GraduateSchool,TheChineseAcademyofSciences,Beijing100039,China)+Correspondingauthor:Phn:+86-10-62553570,E-mail:tao@otcaix.
iscas.
ac.
cn,http://www.
iscas.
ac.
cnReceived2004-07-06;Accepted2004-09-06HuangT,ChenNJ,WeiJ,ZhangWB,ZhangY.
OnceAS/Q:AQoS-enabledWebapplicationserver.
JournalofSoftware,2004,15(12):1787~1799.
http://www.
jos.
org.
cn/1000-9825/15/1787.
htmAbstract:Withtheincreasingdiversityandcomplexityofdistributedsystemsinnetworkenvironment,webapplicationserver(WAS)isrequiredtotransformitsservicemodelfrom"BestEffort"to"QoS(qualityofservice)Guarantee".
However,mostexistingWASsarerelativelyweakintermsofQoSprovision.
Inthispaper,OnceAS/QispresentedtoshowhowaQoS-enabledWAScanofferdifferentQoSprovisionsforapplications.
OnceAS/QprovidesasetofQoSrelatedservicesandaframeworktosupportQoSguarantee,inordertorealizeaQoSenabledWAS.
ThispaperfirstdescribesthearchitectureandmaincomponentsofOnceAS/Q.
Thentwokeyissues,relatedtoQoSenablingandthecorrespondingsolutions,areexploredindetail:oneisthedefinitionandmappingofQoSspecifications,andtheotheristhedynamicreconfigurationofQoS-awareservicecomponentsandresources.
Ecperfbenchmark,awell-knownperformancebenchmarkforJ2EEApplicationServer,isusedtoevaluatetheeffectofQoSenablingofOnceAS/Q.
ExperimentalresultsshowthatOnceAS/QcansupportbetterQoSforapplicationsatareasonablecost.
Keywords:Webapplicationserver;QoS;middleware摘要:网络分布计算环境下应用系统的需求多样化和复杂性的增长,要求位于中间件层次的Web应用服务器SupportedbytheNationalHigh-TechResearchandDevelopmentPlanofChinaunderGrantNos.
2004AA112010,2003AA414310(国家高技术研究发展计划(863));theNationalGrandFundamentalResearch973ProgramofChinaunderGrantNo.
2002CB312005(国家重点基础研究发展规划(973))作者简介:黄涛(1965-),男,江苏淮阴人,博士,研究员,博士生导师,主要研究领域为软件工程,网络分布式计算;陈宁江(1975-),男,讲师,主要研究领域为软件工程,网络分布式计算;魏峻(1970-),男,博士,副研究员,主要研究领域为软件工程,网络分布式计算;张文博(1976-),男,博士生,主要研究领域为网络分布式计算;张勇(1975-),男,博士生,主要研究领域为网络分布式计算.

1788JournalofSoftware软件学报2004,15(12)(webapplicationserver,简称WAS)从原来的"尽力而为"服务模型转变为服务质量(qualityofservice,简称QoS)保障模型,为具有不同需求的应用分别提供适宜的服务质量保障.
目前的WAS系统在此方面仍然比较薄弱.
OnceAS/Q是一个面向QoS的WAS系统,它以QoS规约为基础,为不同应用提供不同的QoS保障能力.
OnceAS/Q实现了一个应用QoS保障框架,提供了一组QoS服务组件支持具有QoS需求的应用开发和运行.
介绍了OnceAS/Q的体系结构和主要组件,详细阐述了两个关键问题,一是QoS规约的定义及其映射,另一个是面向QoS的服务组件和资源的动态重配.
OnceAS/Q原型在Ecperf测试基准下,对其QoS保障能力进行了实验.
实验数据表明,在较大规模的应用环境下,OnceAS/Q能够提供更好的服务质量,并且开销是可接受的.
关键词:Web应用服务器;QoS;中间件中图法分类号:TP311文献标识码:AWeb应用服务器(Webapplicationserver,简称WAS)已经成为网络分布计算环境下的主流中间件[1,2].
目前的WAS系统大多是遵循J2EE(Java2platformenterpriseedition)[3]规范实现,它们从功能性方面为应用提供了基础运行支撑服务,但是对应用非功能性方面的支持比较薄弱,特别是在服务质量(qualityofservice,简称QoS)保障方面.
与应用服务器相关的QoS概念是从网络、多媒体等领域引申出来的.
如同早期的网络/多媒体系统一样,目前的WAS基本采用"尽力而为(besteffort)"服务策略为应用提供服务,即对所有应用请求一视同仁,尽最大努力地分配任务和资源.
然而,Internet环境的高度开放、动态演变的本质特征,以及应用需求的复杂多样和快速增长,使得WAS的"尽力而为"服务模型很难满足应用的高可靠、实时、安全等需求.
因此,WAS需要转换服务策略,随需而变,为有不同需求的应用提供合适的服务质量,如业务吞吐量、响应时间、可靠度等.

例如,在一个复杂的电子商务系统中,会包含不同规模的子系统,也可能并存多种类型的资源,视频/音频文件显然具有与文本文件不同的资源需求.
当发生大规模的用户并发访问时,如果WAS采用尽力而为、先来先处理的策略,那么具有高负载性质的请求(如多媒体资源请求)可能会先被WAS尽力处理,造成系统在一段时间内过于繁忙而导致阻塞甚至崩溃;或者某些低级别的用户请求可能会占用过多的资源,从而会影响WAS对其他更重要的应用请求的响应.
因此,WAS如果具有对QoS特性的处理和优化能力,使应用系统的用户具有良好的使用感受,这对体现应用的价值有着重要意义.
面向QoS的Web应用服务器是指WAS能够根据应用对QoS的需求,以及运行环境情况,遵照QoS规约为不同应用提供不同的QoS保障,并且在运行时动态调整WAS的QoS保障行为.
我们在自主研发的J2EE应用服务器——OnceAS[4]的基础上,研究了提供随"需(QoS)"而变能力的应用服务器体系结构、QoS规约描述和不同层次的映射,以及根据QoS需求和运行时状态,动态重配WAS的服务组件和资源的机制.
本文第1节介绍OnceAS/Q的体系结构及主要组成部分.
第2节阐述OnceAS/Q的QoS规约的定义和描述方法.
第3节介绍OnceAS/Q的动态调整过程,包括服务组件和资源的动态适应机制.
第4节给出了对OnceAS/Q的实验及其结果.
第5节对相关的研究工作进行讨论.
最后是对本文工作的总结.

1面向QoS的Web应用服务器框架1.
1OnceAS应用服务器对服务质量保障的不足应用服务器OnceAS遵循J2EE1.
4规范,体系结构如图1所示,其中主要部件包括:EJB容器和Web容器,它们为应用组件(EJB,Servlet等)提供生命期管理和运行时服务;系列基础服务组件,包括命名、安全、事务等,为WAS和应用组件的运行提供支持;管理内核(managementkernel)为基础服务组件提供了统一的管理和配置框架,进行服务组件的生命期管理和运行时控制;容器入口(invocationentry)响应客户的请求;拦截器(interceptor)[5](若干个拦截器组成拦截器链)在请求处理路径上拦截调用上下文(InvocationContext),OnceAS根据上下文信息触发相应的服务组件处理特定的任务.
OnceAS体系结构具有一定的可扩展性和可重配性[4,6]:(1)通过Interceptor机制,WAS在不改变内核的情况下能够灵活地增加、改变和撤销各种运行时服务;(2)管理内核对各个服务组件实施了灵活的生命期管理,提供黄涛等:OnceAS/Q:一个面向QoS的Web应用服务器1789了一个可扩展的服务管理和控制框架,能够动态地配置和替换服务组件.

Fig.
1ArchitectureofOnceAS图1OnceAS的体系结构但是,面对灵活的QoS保障需求,OnceAS存在的不足主要表现在:(1)应用开发方面缺乏QoS需求描述方法,OnceAS也没有提供相应的QoS映射设施;(2)由于Java虚拟机和J2EE的局限,OnceAS还缺乏描述和管理系统资源的良好方法和设施;(3)虽然Interceptor模式运用和Java简单反射机制[7]为实现组件运行时重配提供了一定的支持,但对于面向QoS的系统重配来说依然不够,需要有更高层次的动态适应机制.
因此,面向WAS的随"需(QoS)"而变的需求,围绕以上问题,我们对OnceAS进行了扩展,研究和设计了一个面向QoS的应用服务器——OnceAS/Q(QoS-EnabledOnceAS).
1.
2OnceAS/Q系统结构1.
2.
1随需而变的服务模型面向QoS的WAS是指在可用资源的约束下,能够提供满足应用特定需求的服务能力,即具有随需而变的服务模型,如图2所示.
这可视作一个控制-反馈模型.
Fig.
2TheQoS-enabledondemandservicemodel图2随需而变的服务模型在这样的服务提供模型中,首先应用对服务质量的要求以WAS可理解和处理的方式表示出来,即QoS规约(表示应用与服务器之间的服务保障契约),WAS的服务组件和资源的配置及调整都遵照该规约进行.
这要求有完善的QoS规约描述方法,以适合WAS的特点和便于实现QoS管理.
QoS映射(QoSmapping)使应用与WAS之间建立起QoS关联,包括面向需求的服务和资源的配置和绑定.
WAS根据QoS映射驱动服务组件和服务器资源的重配.
其次,QoS管理(QoSmanangement)是在运行时进行QoS管理和控制.
它监测环境(environment)的状态,向WAS组件(包括容器、基础服务组件、管理内核等)发出服务和资源重配置的命令.
环境包含了WAS所使用的InvocationcontextClientrequestNamingserviceSecurityserviceTransactionserviceOtherservices…ManagementkernelInterceptorServiceinvocationApplicationcomponentsContainerInvocationentryQoSpluginQoSmappingEnvironmentQoS-enablesystemSpecificationResourcebindingMonitorFeedbackServicebindingReconfigurationControlObservationQoSmanagementWAScomponentsApplication1790JournalofSoftware软件学报2004,15(12)底层资源.
环境的变化会反馈给QoS管理过程,WAS组件在运行时通过QoS管理按需改变配置和行为.
QoS管理是随需而变服务模型的核心,其主要任务有:QoS协商控制——运行时动态修改QoS规约,驱动服务组件和资源的动态重配;QoS准入控制——根据QoS请求和当前系统状态,决定是否允许当前应用进入执行状态;QoS维持控制——确保应用组件所需的服务组件和资源,维持应用的QoS级别.
同时处理用户违反QoS规定的行为,给出服务中止或者降级等反馈.
WAS的QoS调整会对应用产生一定影响,可能要求应用也相应地调整.
为了透明地在应用客户端动态加入QoS控制,使应用业务逻辑与QoS服务逻辑有效分离,在应用端引入QoS插件是一个好的方法,插件中包含需要在客户端处理的QoS相关逻辑.
我们在OnceAS体系结构的基础之上,以扩展的方式增加随需而变的服务模型的机制,同时也考虑充分利用OnceAS原有的可扩展机制等特点,保证了原有组件的复用性和应用的兼容性.
1.
2.
2OnceAS/Q的主要结构按照上述QoS随需而变的服务模型,OnceAS/Q提供了一组QoS服务组件(简称为QoS组件),支持具有QoS需求的应用开发和运行,这些QoS组件一方面接受管理内核的生命期管理和配置,另一方面通过相互协作和管理内核来配置其他基础服务组件的行为,为应用与WAS服务组件和资源之间建立有效的QoS映射,在运行时基于QoS需求适应性地调配服务组件和资源.
OnceAS/Q的系统结构如图3所示,按照功能不同,QoS组件分为QoS映射、QoS管理和客户端QoS支持等3类.
Fig.
3ThearchitectureofOnceAS/Q图3OnceAS/Q系统结构(1)QoS映射组件QoS映射组件在应用部署时或运行时进行QoS规约的解析和映射.
拦截器(QoSinterceptor)拦截获得的QoS规约,生成QoS元数据(QoSMetadata),其中包含QoS请求级别、服务组件和资源配置等初始信息.
QoS映射器(QoSmapper)负责解析QoS规约.
服务规划代理(serviceplanningagent)与管理内核的服务配置器(serviceconfigurator)进行协调,根据QoS元数据来确定满足QoS请求的服务组件集合.
资源代理(resourceagent)对资源的状态进行监控,并根据QoS元数据形成满足当前QoS请求的资源配置,进行资源分配.
(2)QoS管理组件QoS映射结果封装为QoS上下文(QoSContext),QoS管理组件的操作将以QoSContext为依据.
QoS部署器QoSContextOnceAS/QQoSmapperResourceagentServiceplanningagentQoSdeployerQoSspecificationQoSMetaDataServicespecificationApplicationclientQoS-enableclientcontainerQoSproxyQoSinterceptorsRequestContainerQoSlogicgeneratorManagementkernelQoSinterceptorsQoScontrollerQoSmonitorServiceconfiguratorQoSContextQoSProxyQoSStatus黄涛等:OnceAS/Q:一个面向QoS的Web应用服务器1791Fig.
4MultipleviewsofQoSspecification图4多视图的QoS规约SpecificationmappingQoSrequirementspecificationApplicationNetworkNodeWASContainerQoSservicespecificationQoSresourcespecification(QoSdeployer)负责部署有QoS需求的应用组件,它根据QoS上下文,生成与应用相关联的服务组件和资源实例的集合.
QoS控制器(QoScontroller)是实施QoS管理的核心部件,主要处理QoS协商控制、QoS准入控制和QoS维持控制等任务.
QoS监视器(QoSmonitor)监视和感知WAS的状态,将整个系统的资源使用情况、运行状态等形成QoS报告(QoSStatus),定期反馈给QoS控制器.
QoS逻辑生成器(QoSlogicgenerator)动态生成QoS相关的处理逻辑,将它和相关配置信息封装进QoS代理(QoSproxy)中;在容器返回应用请求处理结果时,QoS代理对象被反馈到客户端,与QoS客户端容器动态组装起来,负责处理需在客户端进行的QoS服务逻辑.
(3)QoS客户端容器(QoS-enableclientcontainer)OnceAS/Q在客户端部署QoS客户端容器.
它作为应用与WAS的中介,充当QoS插件的角色.
客户请求先经过QoS客户容器进行QoS相关处理,然后再传给服务器.
QoS客户容器主要包含两类QoS功能组件:QoS代理(QoSproxy)和客户端QoS拦截器.
2OnceAS/Q的QoS规约2.
1Web应用服务器的QoS规约由于QoS规约所描述的对象和内容的多样性,关于WAS的QoS规约可从多个视图来描述,如图4所示.
从物理层次视角看,包括应用层、容器层、WAS层、节点层和网络层.
各个层次都可以定义面向该层次实体的QoS规约,不仅定义的内容有不同要求,而且每层次之间存在一定的映射关系.
从内容视角看,QoS规约包括3个部分:(1)QoS需求规约(QoSrequirementspecification,简称QRSpec),从应用视角描述期望的服务质量性质,如期望的服务质量级别,可靠性、可伸缩性、性能等可度量的QoS参数及其值域等;(2)QoS服务规约(QoSservicespecification,简称QSSpec),规定WAS为满足应用QoS需求所需的服务组件集合及其可配置属性、服务行为和服务依赖关系等;(3)QoS资源规约(QoSreSourcespecification,简称QRSSpec),它描述满足QoS需求和服务规约所需的资源类型、资源配置参数及其值域、资源分配策略、协商策略等.
QoS规约可以在应用设计阶段被定义,也可以在运行时动态生成或者修改,但是不同QoS规约在应用生命周期的重要性及其对QoS保障能力的影响是不一样的.
例如,在应用设计阶段主要定义QoS需求规约,而服务规约和资源规约主要面向运行阶段.
虽然也可以在设计时定义资源规约,但资源规约的准确性和完整性对用户不做较高的要求,而且WAS在进行QoS协商时,运行时生成的资源规约比设计时的处理优先级要高.
2.
2OnceAS/Q的QoS规约描述WAS关注的QoS性质有很多,可扩展的QoS规约描述方法是非常重要的.
J2EE平台以使用部署描述符文件的方式来定义应用和WAS之间的安全、应用环境变量、组件关系等信息.
为了与J2EE平台兼容,以及提供简洁而可扩展的描述手段,OnceAS/Q基于XML语言描述QoS规约,定义了QoS描述符(QoSdescriptor,简称QD).
QD将QRSpec,QSSpec,QRSSpec等部分集成起来,为各个层次的QoS规约提供了统一表示,图5给出了QD的xml模式结构.
在QD.
xml中,Tier标签定义规约的层次,即应用层、WAS层、容器层等.
RequirementSpec标签定义需求规约部分,它的结构遵循以下QoS性质描述框架:类别(category)给出高层次的服务质量的类型描述;每个类别由若干属性(property)来描述该类别的各个方面;每个属性由若干量度(metric)给出定性或定量的指标;每个度量又由1792JournalofSoftware软件学报2004,15(12)若干参数(parameter)及其取值来表示.
ServiceSpec标签定义服务规约部分,包括服务名称、服务依赖关系定义(dependency)、实现类、参数配置集等.
ResourceSpec标签定义资源规约部分,包括资源类型、该类QoS监控器实现、资源配置参数等.
为了使各个部分建立有机的联系,OnceAS/Q定义了QoS角色(QoSRole)的概念.
QoSRole是一个逻辑概念,它标识了一组具有相同QoS需求的用户或者应用.
QoS需求规约、服务规约和资源规约以QoSRole为线索组织和关联起来.
QD描述符作为标准J2EE部署描述符的补充,其在应用部署过程中先后由QoS映射器和QoS部署器解析和处理,生成QoS元数据.
Fig.
5ThestructureofQoSdescriptor图5QoS描述符文件的结构3OnceAS/Q运行时的QoS管理与控制OnceAS/Q根据运行环境和应用的QoS需求动态地调整服务质量,这包括两个方面的问题:一是服务组件的动态配置,二是资源的动态分配.
3.
1服务组件的动态配置OnceAS/Q使用管理内核作为QoS服务组件的管理框架.
QoS服务组件与WAS的基础服务组件一样,都通过统一接口向管理内核注册.
管理内核中的服务配置器(serviceconfigurator)负责生成和维护服务组件之间的依赖关系.
各个服务组件之间的交互通过管理内核传递和响应"通知(notification)"来进行.

面向QoS服务重配的关键是如何区分不同应用的QoS重配请求,使不同应用所使用的服务集互相不干扰,即保证服务重配的一致性.
在OnceAS/Q中,采取了应用服务空间区分的方法.
定义1.
应用QoS环境(applicationQoSenvironment,简称AQE).
AQE是与特定QoS角色(QoSRole)绑定的服务和资源配置.
AQE=(QoSRoleID,Qservices,Qresources,S2R,SDT),其中,QoSRoleID标识与具体应用绑定的QoSRole;Qservices是与QoS角色绑定的服务集合,QoS映射器在解析QoS规约时生成;黄涛等:OnceAS/Q:一个面向QoS的Web应用服务器1793Qresources是与QoS角色绑定的资源集合,QoS映射器在解析QoS规约时生成;S2R:Qservices*Qresources,定义了服务与资源的映射关系;SDT:Qservices*Qservices,定义了服务依赖关系,是非自反的.
SDT实际给出了与QoS角色绑定的服务依赖树.
WAS管理内核依据AQE为不同的QoSRole创建服务组件实例.
不同QoSRole的AQE是相互分离的,因此,不同QoSRole拥有不同的服务组件实例.
在WAS中,存在着全局唯一的服务组件,即在运行时只能有一个服务组件实例存在,因此,nceAS/Q设置一个单独的全局QoS环境(globalQoSenvironment,简称GQE)对全局服务组件进行管理.
定义2.
全局QoS环境.
GQE=(Gservices,ServiceLinks),其中,Gservices是全局唯一的服务组件集合;ServiceLinks:AQE.
Qservices*Gservices,是应用QoS环境中的服务与全局服务关联的关系,用以标识全局服务组件的不同配置实例.
AQE与GQE将具有不同QoS需求的应用所使用的服务组件和资源实例区分开来,保证了为不同应用提供不同的QoS配置,从而避免了可能的服务配置冲突.
AQE被封装在QoSContext中,在服务重配过程中由管理内核、QoS控制器等操纵.
图6是一个AQE与GQE的示例.
OnceAS/Q的服务重配或者由QoS拦截器拦截应用请求而触发,或者由QoS控制器根据运行时状态触发,服务重配过程如下:(1)QoS拦截器拦截应用请求中的QoS需求(或者QoS控制器根据QoS监控器的报告生成新的QoS需求),将其封装到当前QoSContext;(2)QoS控制器向管理内核发出"QoS服务重配"通知,并将当前QoSContext传递给管理内核;(3)服务配置器从QoSContext中获得新的服务组件配置和调整策略;(4)对服务组件配置中的每个服务组件逐个处理:如果服务存在服务依赖关系,则构造出其服务依赖树,从树根依次对各个服务进行处理;(5)根据服务调整策略的不同类型,对服务分别做如下处理:(5.
1)"重置(reset)"策略:首先阻塞服务组件的执行;通过序列化、持久化或者日志(logging)等机制暂存当前服务的状态;重新设置服务组件的参数;将服务组件从暂存状态恢复到执行状态;(5.
2)"停止(stop)"策略:将服务状态写入日志;通知管理内核,停止该服务组件的运行;释放本组件占用的资源;依据服务依赖关系,管理内核通知其相关的服务组件除去与该服务的关联;(5.
3)"新增(append)"策略:通知管理内核装载所需服务组件,并生成组件实例;从QoSContext中获取QoSRole和应用QoS环境(AQE),装载新生成的服务组件实例;根据QoS规约配置新服务组件的参数;(5.
4)"替换(replace)"策略:首先执行(5.
2)停止该服务组件;然后执行(5.
3)增加新服务组件;Fig.
6AQEandGQE图6AQE与GQE示例图ApplicationQoSenvironmentQoSRoleServicea1Servicea2Servicea3Servicea21Servicea22Resourcea12Resourcea11Resourcea21Resourcea211Resourcea22GlobalQoSenvironmentGlobalServiceResourceg1Resourceg2BindingServicelinkServicedependency1794JournalofSoftware软件学报2004,15(12)(6)服务配置器生成新的服务依赖树;(7)QoS控制器发出调整系统资源的通知;(8)生成新的应用QoS环境(AQE),返回新的QoSContext.
3.
2资源的动态分配运行时的服务组件重配与系统资源的动态重分配紧密相关.
一个运行时系统所使用的资源归根到底是内存、CPU、网络带宽、磁盘等类型.
但是,一般用户和应用系统对于这些底层资源的配置以及需求是不敏感的,难以进行资源的按需管理.
为此,WAS应该为应用提供一定的资源管理透明性.
OnceAS/Q增强了关于系统资源监控、资源管理和分配策略等方面的支持机制.
在OnceAS/Q中,建立了可控资源的统一视图,实现了一个扩展的资源管理框架,支持资源抽象、监控和管理.
同时,为优化资源的分配设计了一个动态资源配置算法.
它基于QoS资源规约和运行时资源状况,在各种资源配置之间进行权衡,寻找优化的资源配置方案.

3.
2.
1OnceAS/Q的二级资源管理框架OnceAS/Q的系统资源抽象为两类:逻辑资源(logicalresource)是指WAS能直接感知和控制的资源类型,如组件池/缓存、消息队列、对象锁等;物理资源(physicalresource)是指内存、CPU、线程等底层资源.
OnceAS/Q更关注和更能有效控制的资源是"逻辑资源",这也是应用所更能理解的资源类型.

OnceAS/Q的资源管理建立在面向逻辑/物理资源的两级资源抽象模型之上.
在低层资源的基础上构建高层的资源视图,即物理资源是对底层实际资源的抽象,而逻辑资源与物理资源之间存在一定的映射.
该抽象模型便于对不同类型的资源进行统一管理,以及不同资源之间进行映射.
为了在系统运行时能够满足不同服务质量的需求,各个应用和服务组件所使用的资源要避免冲突.
OnceAS/Q通过QoS角色与应用QoS环境(AQE)的绑定,将应用与其所使用的运行时资源对象关联起来.
不同QoS角色所使用的逻辑资源实例不同;每个逻辑资源映射和分配到若干物理资源对象.
应用对逻辑资源进行直接的配置和操作,而逻辑资源又映射到物理资源,从而实现与底层环境资源的交互.

OnceAS/Q实现了这样的资源管理框架,称之为面向QoS的抽象资源管理框架(Qos-Enableabstractresourcemanagementframework,简称QARMF),如图7所示.
QARMF包括两个主要部分:(1)统一的资源表示(resourcerepresentation),提供了对资源的表示和访问接口;(2)资源管理(resourcemanagement)类组件.
Fig.
7Qos-Enabledabstractresourcemanagementframework图7面向QoS的抽象资源管理框架资源表示中的MetaResource是抽象资源的元接口,定义了监视资源状态,获知QoS规约等操作.
LogicalResource和PhysicalResource分别定义逻辑资源和物理资源的描述和存取方法,逻辑资源根据资源规约映射成特定的物理资源配置.
在LogicalResource和PhysicalResource的基础上,可以分别实现各种逻辑/物理ResourcemanagementResourceSpecReconfigurationcommandadmitnegotiatescheduleResourceallocatorResourcepermissionResourcespectrumResourceschedulermapPhysicalresourceResourcerepresentationQoSRoleinstantiateStatusinstantiatecreateMetaResourceLogicalresourceEnvironment(OS,network)createelPhysicalresourcemodelelLogicalresourcemodel黄涛等:OnceAS/Q:一个面向QoS的Web应用服务器1795资源的具体类(称为资源模型类).
例如,属于逻辑资源的组件池(ComponentPoolModel)、连接池ConnectionPoolModel)、锁(LockModel)等;属于物理资源的内存(MemoryModel)、文件资源(FileModel)等.
各个资源模型类中分别实现监视和分配各自对应资源的方法.
资源管理组件包括资源调度器ResourceScheduler、资源分配器ResourceAllocator、资源许可ResourcePermission、资源配额ResourceSpectrum等,它们都是QoS监控器组件(如图3所示)的主要组成部分,根据传来的资源规约和资源重配命令,相互协作完成资源的协商、分配和回收等任务.

OnceAS/Q在运行时资源重配的过程一般为:(1)QoS监控器接收资源重配请求,获取QoSContext;(2)QoS监控器从QoSContext中取出当前的QoS角色及其资源规约,计算预期的资源分配表;(3)ResourceSpectrum获得当前全局资源状态,计算当前可用资源;(4)QoS监控器通过与ResourcePermission,ResourceSpectrum的协作,进行资源协商,生成在当前运行环境下能满足资源规约的最佳资源配置参数;(5)ResourceAllocator与资源代理协作,通过LogicResource的具体实现模型,进行逻辑资源对象的分配,包括设置资源的参数值、申请新的资源、释放资源、缓存资源等;(6)逻辑资源模型的配置变化驱动物理资源模型的重配,进而完成底层资源的重新分配.

3.
2.
2资源配置的动态计算资源的重配归结到各种资源的具体参数配置.
虽然应用在QoS资源规约中规定了所使用的资源的期望数值,但是服务器需要在考虑运行时的资源状态、其他应用对资源的需求的条件下,综合权衡,找到当前系统所能容许范围内的最佳资源配置参数集.
设QoS度量(metric)集合M={m1,m2,…,mk},所有资源可配置参数为P={p1,p2,…,pn}.
资源代理(如图3所示)负责进行各种QoS指标M与资源配置参数P之间的映射.
一个mi可由若干个pj表示.
对于度量mi,根据QoS规约得到的mi的最大值和最小值分别为max(mi)和min(mi),将此二值中表示最低质量保障效果的值记为参考值ref(mi),而另一值记为最佳值opt(mi).
例如,对于响应时间而言,参考值ref取max值,最佳值opt取min值.
在此基础上,定义如下函数:(1)协商函数gm(δ):gm(δ)=a*δ+b.
函数gm(δ)表示计算QoS度量m的函数,其中a,b为正系数,δ为搜索m的最佳值时的步长,δ=λ*|mproberef(m)|/ref(m),mprobe为QoS监测器定期检测获得的QoS度量值,λ为步长调节系数.
(2)QoS优化函数Qoptimize:Qoptimize=∑=*kimiδgwi1)(.
其中wi是度量mi的权重,定义各种度量的重要性,∑=kiiw1=1.
OnceAS/Q在运行时以探测的mprobe计算Qoptimize的最佳值,确定各项QoS度量mi的取值,然后通过资源代理在资源配置参数P中进行映射,将P反馈回QoS监控器以作为配置和调整资源的依据.
目前,OnceAS/Q采用简单的爬山法(hill-climbling)[8]进行Qoptimize最佳值求解,搜索边界为∑∑==niiiniiiδgoptwδgrefw11))((,))((.
爬山法虽然比较简单,但是容易实现,在实际中能较有效地找到解.
4实验结果OnceAS/Q原型系统已经实现.
为了检验OnceAS/Q的QoS提供能力,我们对该原型进行了一组实验.
测试工具选用业界熟知的J2EE应用服务器性能测试基准ECperf[9].
ECperf重点考察EJB容器以及基础服务组件的处理能力,它包括多种QoS度量指标,如请求平均响应时间、不同业务类型的比例、吞吐量等.
ECPerf所模拟的应用规模由事务注入率(TxRate)决定,并发客户数与TxRate成正比.
ECPerf测试的实验环境为:100MEthernet局域网,受测OnceAS/Q系统所在机器的配置为DELLPowerEdge2000PC服务器(IntelXEONCPU3.
04GHz*2,2GB内存).
实验为ECPerf应用设定了3个服务级别:Level0——不启动QoS管理机制;Level1——期望的业务处理量1796JournalofSoftware软件学报2004,15(12)要求较低;Level2——期望的业务处理量要求较高.
根据服务级别,分别给出了不同的初始逻辑资源约束,见表1.
表中所列出的是对Ecperf应用具有重要影响的资源,其中Size=[minSize,maxSize],表示缓冲池容量的上下限,QueueSize指定等待队列的长度,不能及时得到处理的请求将会被放入任务队列中等待处理,RefleshCycle表示对缓冲池的刷新频率,刷新过程将会释放暂时没有被使用的资源.
Level0级对这些资源没有限制;而Level1级和Level2级都对这些资源设定了不同的约束.
Table1QoSparametersofOnceAS/QinECperfexperiments表1OnceAS/Q在ECperf测试中的主要QoS参数MetricsQoSlevelServerthreadpoolDBconnectionpoolEJBobjectpoolEJBdatacacheLevel0Size=Unlimited;Queue=UnlimitedSize=Unlimited;RefleshCycle=neverSize=Unlimited;RefleshCycle=neverSize=Unlimited;RefleshCycle=neverLevel1Size=[20,50];QueueSize=20Size=[10,30];RefleshCycle=300sSize=[100,250];RefleshCycle=60sSize=[100,250];RefleshCycle=60sLevel2Size=[40,100];QueueSize=50Size=[20,50];RefleshCycle=900sSize=[200,1000]RefleshCycle=300sSize=[200,1000]RefleshCycle=300s图8显示了在不同的QoS约束下,Ecperf应用的业务吞吐量(Bbops/min)和响应时间随TxRate值而变化的情况,图8(a)反映的是吞吐量,图8(b)反映的是响应时间.
从图8中可以明显地看出,在没有QoS管理的Level0级测试中,当TxRate为25时,服务器的服务能力接近峰值,此时它对资源的需求还能得到满足;但之后随着负载的进一步加大,服务器对资源不能进行有效的管理,从而导致服务能力出现一定程度的下降,此时关键业务的响应时间也相应地增加.
当TxRate增加到50时,服务器因为服务能力无法满足如此规模的应用需求而崩溃,从而不能完成正常的测试.
在Level1级的资源约束下,OnceAS/Q的服务能力在TxRate为30的时候接近峰值,之后由于受到所分配资源的限制,它的服务能力开始在峰值附近稳定,这也造成大批请求由于不能得到及时处理而使业务的响应时间增加.
在Level2的资源约束下,由于系统的资源供给情况有了明显的提高,所以OnceAS/Q在TxRate为40时才接近服务能力的峰值,其后与Level1类似,其受到的资源约束也使得服务器的服务能力增长非常缓慢.
因此,OnceAS/Q为具有不同QoS约束的应用所提供的服务是不同的,特别是在应用规模较大时表现的差异较明显.

(a)Throughout(b)Responsetime(a)吞吐量(b)响应时间Fig.
8ExperimentalresultsofECPerfbenchmark图8ECPerf基准测试结果为了更清楚地描绘不同服务级别下OnceAS/Q对ECPerf应用请求的处理情况,我们给出了在3种不同QoS级别中,OnceAS/Q在Ecperf测试峰值时的关键业务响应时间频率分布,如图9所示.
图中横轴表示响应时间,纵轴表示在该响应时间内的关键业务数量,TxRate值分别取25,30和40.
以曲线Level0-25为例,它表示在Level0级下,事务注入率为25时关键业务响应时间的分布频率.
从具有同一事务注入率的3条不同曲线上,可以观察不同QoS级别的资源约束对业务响应时间的影响.
黄涛等:OnceAS/Q:一个面向QoS的Web应用服务器1797Fig.
9Frequencydistributionofresponsetimesforkeytransactions图9ECPerf关键业务的响应时间频率分布图从图9中可以观察到,在TxRate为25时,虽然3种级别的OnceAS/Q的吞吐量基本相同(如图8(a)所示),但是,Level0级的OnceAS/Q服务能力已近峰值,而且响应时间介于1.
5s~2s的业务最多;而在Level1级和Level2级的情况下,关键业务响应时间大多都分布在1s~1.
5s之间,但后者比前者的分布频率更集中,这说明更高的QoS资源配给使得更多的关键业务能在较短的时间内完成,这在负载进一步加大后变得尤为明显.
可见,虽然此时OnceAS/Q在不同的资源约束下所表现的吞吐量相差不大,但是遵循给定QoS规约的资源分配会改善OnceAS/Q内部的资源竞争,从而使系统可以提供更好的服务能力.
在TxRate为30时,3个级别的频率分布曲线与此类似,不过此时Level0级的OnceAS/Q由于资源的过度争用,响应时间分布已经集中到2s~2.
5s之间.
当TxRate为40时,Level0级的OnceAS/Q服务能力已经开始明显下降,响应时间已经上升到3s~3.
5s之间;Level1级的OnceAS/Q由于资源的配给也受到约束,响应时间上升到2s~2.
5s之间;Level2级的OnceAS/Q在此时的服务能力接近峰值,其响应时间集中在1.
5s~2s之间.
图9非常微观地描绘了不同的QoS约束对OnceAS/Q服务能力的影响.
通过使用一定的QoS约束,可以避免资源争用过度而造成服务能力下降的情况.
而不同的QoS约束对OnceAS/Q的服务能力具有不同的影响,OnceAS/Q通过定义不同的QoS级别来满足不同的应用需求.
此外,我们对不同QoS资源约束条件下系统内存的使用情况进行了测量,如图10所示.
从图10中可以看到,在TxRate较低的时候,由于系统的负载较低,进行QoS资源约束比没有约束会消耗更多的内存.
但是,随着负载的增加,由于无法对资源进行按需分配和管理,从而使无QoS保障的情况比有QoS保障的情况消耗更多的内存.
而Level2由于比Level1享有更多的可支配资源,所以会消耗比Level1更多的内存,但是二者的内存消耗在到达服务峰值后开始比较稳定的缓慢增长.
以上ECPerf实验结果表明,由于采取了有效的QoS控制和管理措施,OnceAS/Q在给定QoS约束下,对资源的使用可以控制在一个可接受的范围内,会更好地提供满足应用需求的服务能力,在Ecperf应用中,这反映在业务吞吐量增大和响应时间较短等方面.
在不同的QoS资源约束下,OnceAS/Q也体现出与资源供给情况相符的服务能力,具有随需定制服务能力的特点,例如,不同服务级别下,Ecperf应用的业务响应时间的频率分布件是不相同的.
Fig.
10UsageofmemoryfordifferentQoSlevels图10不同级别的内存使用1798JournalofSoftware软件学报2004,15(12)5相关工作为中间件提供服务质量支持是中间件领域的一个重要发展趋势和研究热点[10,11],在此方面已经有不少研究工作,主要集中在多媒体、可靠性、实时系统等应用领域.
诸多具有QoS能力的中间件都提出了各自的QoS管理体系结构,以在CORBA平台上的研究为主,其中较具代表性的有:QuO[12]为有QoS需求的应用提供了一种通用的中间件支撑框架,它采用了一种与AOP(aspect-orientedprogramming)编程范型类似的技术,在中间件的公共服务层提供了一种高级QoS抽象;TAO[13]支持实时CORBA规范,它的目标主要是为实时应用的QoS需求提供支持;DynamicTAO[14]、OpenORB[15,16]通过使用反射技术提供了对系统服务和资源进行动态重配的能力;CQoS[17]主要通过Interceptor机制提供了一个支持组合多种QoS性质的可定制框架.
Java平台上的QoS中间件研究相对较少,主要借鉴了CORBA领域的研究成果.
例如,2KQ+[18]框架提供统一的QoS管理框架,主要包括QoS编程环境、Q-Compiler编译器和可重配置的中间件2KQ,为开发具有QoS需求的应用提供了系统化的方法,以及在运行时提供QoS保障;Miguel等人提出了QoSBean组件模型[19],通过扩展EJB组件模型来集成所需的实时QoS服务,但是缺乏对资源和服务重配的考虑;RAJE[20]对标准的JVM进行了扩展,在中间件的层次上提供监控资源存取和管理资源的手段.
目前大多数WAS(如WebLogic,WebSphere,Oracle9iAS等)都隐藏接口之外的实现细节,在运行期间可定制和可重配置能力低,使得QoS的提供和保障能力较差,WAS在运行期间较难根据运行环境和用户需求的变化进行适应性的变化.
以IBM的"按需计算(on-demandcomputing)"[21]、JBossAOP[22]为代表,目前的WAS也在朝QoS保障的方向努力,但是技术尚未达到成熟的地步.
与相关研究工作相比,我们针对J2EE应用服务器的QoS提供与保障方面进行了较为全面的研究.
首先提出了补充J2EE相关规范的QoS规约定义,给出了基于QoS规约,从应用层到资源层的QoS配置映射;建立了一个适应于WAS的QoS管理框架,并提供了服务组件和资源两个层次的QoS自适应机制,包括应用QoS环境(AQE)、抽象资源管理框架(QARMF)以及资源动态重配算法等.
6结束语在网络分布计算环境下,复杂的大规模应用系统对QoS具有较高的要求.
作为应用的关键性基础设施,Web应用服务器对于实现端到端的QoS保障有着重要的影响.
本文对面向QoS的应用服务器的关键技术进行了研究.
OnceAS/Q提供了一个WAS的QoS管理和控制框架,本文阐述了该框架的结构和主要组件,对与QoS相关的两个主要问题进行了研究,一是QoS规约及其映射,另一是服务/资源动态适应机制.
使用J2EE测试基准ECPerf,对OnceAS/Q与OnceAS进行了对比测试.
测试结果表明,OnceAS/Q能够根据应用需求和运行环境,提供适宜的服务能力,而且QoS管理所带来的开销是处于可接受范围之内的.
下一步研究工作主要包括:如何在现有QARMF的工作基础上,加强资源的管理和自适应能力;WAS的各种QoS性质(如可靠性、安全性、性能等)之间如何协调和权衡,以使WAS的QoS提供与保障更为准确和高效.
References:[1]MohanC.
Tutorial:Applicationserversandassociatedtechnologies.
In:SIGMOD,ed.
Proc.
ofthe2002ACMSIGMODInt'lConf.
onManagementofData.
NewYork:ACMPress,2002.
636.
[2]FanGC,ZhongH,HuangT,FengYL.
AsurveyonWebapplicationservers.
JournalofSoftware,2003,14(10):1728~1739(inChinesewithEnglishabstract).
http://www.
jos.
org.
cn/1000-9825/14/1728.
htm[3]SunMicrosystems,Inc.
Java2platformenterpriseeditionspecification(v1.
4).
2003.
[4]FanGC.
Researchonsomekeytechnologiesforwebapplicationserver[Ph.
D.
Thesis].
Beijing:InstituteofSoftware,TheChineseAcademyofSciences,2004(inChinesewithEnglishabstract).
[5]SchmidtDC,StalM,RohnertH,BuschmannF.
Pattern-OrientedSoftwareArchitecture:PatternsforConcurrencyandDistributedObjects.
Vol2,NewYork:Wiley&Sons,2000.
黄涛等:OnceAS/Q:一个面向QoS的Web应用服务器1799[6]FanGC,LinSB,DongWC,FengYL.
WebFrame:Anextensiblemulti-layerwebapplicationserver.
ChineseJournalofComputers,2004,27(4):451~460(inChinesewithEnglishabstract).
[7]SunMicrosystems,Inc.
Javadynamicproxyclasses.
URL:http://java.
sun.
com/j2se/1.
3/docs/guide/reflection/proxy.
html[8]RussellJ,NorvigP.
ArtificialIntelligence:AModernApproach.
EnglewoodCliffs:PrenticeHall,1995.
[9]SunMicrosystems,Inc.
ECperfspecification(v1.
0).
2001.
[10]Duran-LimonHA,BlairGS,CoulsonG.
Adaptiveresourcemanagementinmiddleware:Asurvey.
IEEEDistributedSystemsOnline,2004,5(7).
[11]SchantzRE,SchmidtDC.
Researchadvancesinmiddlewarefordistributedsystems.
In:ChapinL,ed.
Proc.
oftheIFIP17thWorldComputerCongress.
Deventer:Kluwer,2002.
1~36.
[12]VanegasR,ZinkyJ,LoyallJ,LoyallJ,KarrD,SchantzR,BakkenD.
QuO'sruntimesupportforqualityofserviceindistributedobjects.
In:DaviesN,RaymondK,SeitzJ,eds.
Proc.
oftheIFIPInt'lConf.
onDistributedSystemsPlatformsandOpenDistributedProcessing(Middleware'98).
NewYork:Springer-Verlag,1998.
207~223.
[13]SchmidtDC,LevineDL,MungeeS.
ThedesignoftheTAOreal-timeobjectrequestbroker.
ComputerCommunication,1998,21(4):294~324.
[14]KonF,RomanM,LiuP,MaoJ,YamaneT,MagalhesLC,CampbellRH.
Monitoring,security,anddynamicconfigurationwiththedynamicTAOreflectiveORB.
In:SventekJS,CoulsonG,eds.
Proc.
ofIFIPInt'lConf.
onDistributedSystemsPlatformsandOpenDistributedProcessing(Middleware2000).
NewYork:Springer-Verlag,2000.
121~143.
[15]BlairGS,CoulsonG,AndersenA,BlairL,ClarkeM,CostaF,Duran-LimonH,FitzpatrickT,JohnstonL,MoreiraR,ParlavantzasN,SaikoskiK.
ThedesignandimplementationofopenORBversion2.
IEEEDistributedSystemsOnlineJournal,2001,2(6).
URL:http://csdl.
computer.
org/comp/mags/ds/2001/06/o6001abs.
htm[16]CoulsonG,BlairGS,ClarkeM,ParlavantzasN.
Thedesignofahighlyconfigurableandreconfigurablemiddlewareplatform.
ACM/SpringerDistributedComputingJournal,2002,15(2):109~126.
[17]HeJ,HiltunenMA,RajagopalanM,SchlichtingRD.
ProvidingQoScustomizationindistributedobjectsystems.
In:GuerraouiR,ed.
Middleware2001.
NewYork:Springer-Verlag,2001.
351~372.
[18]WichadakulD,NahrstedtK,GuXH,XuDY.
2KQ+:AnintegratedapproachofQoScompilationandreconfigurable,component-basedrun-timemiddlewarefortheunifiedQoSmanagementframework.
In:GuerraouiR,ed.
Middleware2001.
NewYork:Springer-Verlag,2001.
373~394.
[19]MiguelMA.
IntegrationofQoSfacilitiesintocomponentcontainerarchitectures.
In:PaulR,ed.
Proc.
ofthe5thIEEEInt'lSymp.
onObject-OrientedReal-TimeDistributedComputing.
Washington:IEEEComputerSociety.
2002.
394~401.
[20]SommerNL,GuidecF.
Acontract-basedapproachofresource-constrainedsoftwaredeployment.
In:BishopJM,ed.
Proc.
oftheIFIP/ACMWorkingConf.
onComponentDeployment.
NewYork:Springer-Verlag,2002.
15~30.
[21]HernessEN,HighRH,McGeeJR.
WebSphereapplicationserver:Afoundationforondemandcomputing.
IBMSystemsJournal,2004,43(2):213~237.
[22]http://www.
jboss.
org附中文参考文献:[2]范国闯,钟华,黄涛,冯玉琳.
Web应用服务器研究综述.
软件学报,2003,14(10):1728~1739.
http://www.
jos.
org.
cn/1000-9825/14/1728.
htm[4]范国闯.
Web应用服务器关键技术研究[博士学位论文].
北京:中国科学院软件研究所,2004.