Webservice框架性能对比.docx
《Webservice框架性能对比.docx》由会员分享，可在线阅读，更多相关《Webservice框架性能对比.docx（15页珍藏版）》请在冰豆网上搜索。
Webservice框架性能对比
几种流行Webservice框架性能比照〔、拼接〕
1摘要
开发webservice应用程序中离不开框架的支持，当open-open列举的就有很多种，这对于开发者如何选择带来一定的疑惑。
性能Webservice的关键要素，不同的框架性能上存在较大差异，而当前在官方、网络资料中可以方便的找到各自框架的介绍，但是很少有针对不同框架性能测试数据。
本文选择了比拟流行几个框架：
ApacheAxis1、ApacheAxis2、CodehausXFire、ApacheCXF、ApacheWink、ossRESTEasy、sunJAX-WS〔最简单、方便〕、阿里巴巴Dubbo〔除外〕等，采用java作为测试用例，通过本机和远程两种进展测试方式，对这几种框架进展了性能测试，并对测试结果分析和性能比拟，最后并对性能优异的框架进展了推荐。
目前三种主流的web服务实现方法：
REST〔新型〕：
表象化状态转变（软件架构风格〕RESTEasy、Wink、CXF、Axis2…….
SOAP〔比拟成熟〕：
简单对象访问协议Xfire、Axis2、CXF、Axis1
XML-RPC〔淘汰〕：
远程过程调用协议〔慢慢被soap所取代〕
REST简单易用，效率高，貌似未来有很大的开展空间，也有宣称rest性能个方便比soap强大的，已经有很多框架宣称对rest进展支持比如spring、struts……..〔XX观点〕
SOAP成熟度较高，安全性较好
关键词：
Axis1、Axis2、XFire、CXF、Spring、SOAP、StAX、WSDL
2 框架介绍
2.1 ApacheAxis1
Axis本质上就是一个SOAP引擎〔ApacheAxisisanimplementationoftheSOAP〕，提供创建服务器端、客户端和网关SOAP操作的根本框架。
但Axis并不完全是一个SOAP引擎，它还包括：
● 是一个独立的SOAP服务器。
● 是一个嵌入Servlet引擎〔例如Tomcat〕的服务器。
● 支持WSDL。
● 提供转化WSDL为Java类的工具。
● 提供例子程序。
● 提供TCP/IP数据包监视工具。
2.2 ApacheAxis2
ApacheAxis2相比ApacheAxis1更加有效、更加模块化、更加面向xml，支持容易插件模块扩展新功能和特性，例如安全和可靠。
ApacheAxis2是基于ApacheAXIOM，它是一个高性能、pull-basedXML对象模型。
ApacheAxis2的关键特性：
● 解析xml更快。
采用自己的对象模型和StAX（StreamingAPIforXML）。
● 更低的内存占用。
● 支持热部署。
新服务参加到系统，无需重启服务。
● 支持异步webservice、
● MEP支持，灵活支持在定义的MessageExchangePatterns（MEPs）
● 更加灵活。
引擎给开发人员提供了充足的自由度可扩展客户头信息处理、系统管理、
● 更加稳定性。
● 传输框架不依赖于具体协议。
为集成和传输协议〔SMTP,FTP,message-orientedmiddleware,etc〕有一个简单和抽象，引擎核心是完全独立于具体的传输协议。
● 支持WSDL。
支持、。
● 方便集成其他组件〔Add-ons〕。
几个webservices已经被集成，包括：
WSS4Jforsecurity（ApacheRampart）,Sandeshaforreliablemessaging,KandulawhichisanencapsulationofWS-Coordination,WS-AtomicTransactionandWS-BusinessActivity.
● 良好的扩展性。
2.3 CodehausXFire
XFire核心是一个轻量的基于STAX消息处理模型，用来与SOAP消息交互，它支持不同类型的绑定机制、容器和传输协议。
支持webservice标准-SOAP,WSDL,WS-IBasicProfile,WS-Addressing,WS-Security,etc.
● 高性能SOAPSTACK
● 可插拔绑定POJOs,XMLBeans,JAXB1.1,JAXB2.0,andCastorsupport
● 通过Java1.5和1.4（monsattributesJSR181syntax）使用JSR181API配置服务
● 支持多中传输协议-HTTP,JMS,XMPP,In-JVM,etc.
● 可嵌入的和直观的API
● 支持Spring,Pico,Plexus,andLoom
● 支持I
● 客户端和服务端stub代码生成
● 支持JAX-WSearlyaccess
2.4 ApacheCXF
ApacheCXF是一个开源服务框架。
ApacheCXF=Celtix+XFire，ApacheCXF的前身叫ApacheCeltiXfire，现在已经正式更名为ApacheCXF了，以下简称为CXF。
CXF继承了Celtix和XFire两大开源项目的精华，比如：
JAX-WSandJAX-RS，主要特性包括：
● 支持Webservices标准。
包括：
SOAP、theWSIBasicProfile、WSDL、WS-Addressing、WS-Policy、WS-ReliableMessaging、WS-Security、WS-SecureConversation和WS-SecurityPolicy.
● 支持不同类型前端开发模型。
CXF实现了JAX-WSAPIs，支持JAX-RS开发。
● 容易使用。
CXF设计的简洁和直观，具有简洁APIs迅速的构建基于代码的服务，Maven插件使得工具集成更加容易、JAX-WSAPI支持、Spring2.xXML使得配置更加容易。
● 支持二进制和遗留协议。
CXF被设计为可插拔的架构，在不同的传输协议结合下，不仅支持XML，也支持非XML类型绑定，例如：
JSON和CORBA。
2.5RESTEasy〔XX观点较好〕
RESTEasy是oss的一个开源项目，提供各种框架帮助你构建RESTfulWebServices和RESTfulJava应用程序。
它是JAX-RS规X的一个完整实现并通过JCP认证。
作为一个OSS的项目，它当然能和OSS应用服务器很好地集成在一起。
但是，它也能在任何运行JDK5或以上版本的Servlet容器中运行。
RESTEasy还提供一个RESTEasyJAX-RS客户端调用框架。
能够很方便与E、Seam、Guice、Spring和SpringMVC集成使用。
支持在客户端与服务器端自动实现GZIP解压缩。
〔资料少无法比拟〕
有较专业的人士对CXF、Restlet、RESTEasy、Jersey框架测试【数据】，他说从性能上看RESTEasy是最好的，Jersey其次〔但Jersey连可查阅的英文文档都比拟少故个人不推荐使用〕，cxf和Restlet最差，
Dubbo〔个人观点----无理由〕
Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和 Spring框架无缝集成。
〔资料少无法比拟〕
2.7java6JAX-WS
JAX-WS2.0（JSR224）是Sun新的webservices协议栈
JAVA中有三种WebService规X，分别是JAX-WS〔JAX-RPC〕、JAX-RS、JAXM&SAAJ。
JAX-WS〔JavaAPIForXML-WebService〕，JDK1.6自带的版本为JAX-WS2.1，其底层支持为JAXB。
早期的JAVAWeb服务规XJAX-RPC〔JavaAPIForXML-RemoteProcedureCall〕目前已经被JAX-WS规X取代，JAX-WS是JAX-RPC的演进版本，但JAX-WS并不完全向后兼容JAX-RPC。
〔〕
2.8 ApacheWink
REST（RepresentationalStateTransfer） basedWebService【c:
\iknow\docshare\data\cur_work\baike.soso\v812054.htm】是相对于传统的WebService（SOAP+WSDL+UDDI）而提出的。
传统的WebService可以很好的解决异构系统之间的通信问题，但是需要首先定义好XML格式的合同（WSDL），client和server都必须严格遵守协议，不容易升级以与集群伸缩。
RESTWebService不需要事先定义格式，传输的内容也可以依据不同的client变化（json,xml,html等），最重要的是使用源URL来唯一定位资源，对资源的增删改查映射为HTTP的四个方法，无状态传输，具有非常好的伸缩性。
ApacheWink就是一个纯Java的REST框架。
它完整的实现了JSR311并扩展了局部功能，此外还提供了良好的扩展性，难能可贵的是还可以与流行的Java框架Spring无缝集成。
目前该项目还在开发中。
所谓框架无非就是定义好格式，提供一些工具和钩子，让开发人员可以专注于业务逻辑的开发。
3 测试准备
表格1测试根本元素
测试条件
描述
主机环境
B测试机：
CPU:
1.83GHz；内存：
1G
Web服务框架
应用环境
客户端代码
publicvoidtestgetVersion（）throwsjava.lang.Exception{
Stringurl="localhost:
8081/boss/services/Calculate";
//客户端初时化时间
longstartTime=System.currentTimeMillis（）;
//客户端stub代码分别是axis1/axis2/xfire/cxf框架wsdl2java生成
CalculateCalculateHttpportStubstub=newCalculateCalculateHttpportStub（url）;
longendTime=System.currentTimeMillis（）;
System.out.println（"clientinittimeis:
"+（endTime-startTime））;
//连续调用10次
for（inti=0;i<10;i++）{
longstartTime1=System.currentTimeMillis（）;
Stringret=stub.getVersion（）.get_return（）;
longendTime1=System.currentTimeMillis（）;
System.out.println（"["+i+"]elapsedtimeis:
"+（endTime1-startTime1）+"ms"）;
System.out.println（"stub.getVersion（）is:
"+ret）;
}
}
服务端代码
publicStringgetVersion（）
注：
接口无任何业务逻辑，只返回一个字符串：
"Hello";
测试方法
本机接口测试，客户端和服务端都在A测试机上进展；
远程接口测试，A测试机作为客户端，B测试机作为服务器。
本次测试是在局域网内完成。
结果精度
数字准确到小数点后两位
名词解释
服务器端：
部署到服务器的程序。
客户端：
发起请求调用服务器上webservcie的程序。
客户端初时化时间：
发起接口调用时，初始化客户端java对象所需时间。
例如：
CalculateCalculateHttpportStubstub=newCalculateCalculateHttpportStub（url）;//由框架wsdl2java生成客户端stub
表格2在端对端性能上，一个客户端驱动程序使用了一个胖客户端Web服务堆栈来发送和承受SOAP请求
Webservice服务端
Webservice客户端
Webservicestack
SOAPoverHTTP
4 性能测试
4.1 测试方法
本次假定在一样网络、主机环境条件下进展测试，因此性能的差异主要是由不同框架实现机制的所决定。
● 采用两种方式测试：
本机测试、远程测试。
● 服务器端分别采用：
axis1、axis2、xfire、CXF，对于选定的服务器端，用不同框架对应的工具包wsdl生成客户端stub代码进展测试。
● 服务端接口内部没有复杂业务逻辑，客户端调用时，仅仅返回一个字符串。
● 每次运行，采用java循环方式调用10次服务端接口，并记录下从发起到返回结果的时间。
4.2 测试结果
限于篇幅，本文仅提供了：
以CXF框架为服务端的详细测试结果，与其各个框架的综合后测试结果。
表格3以CXF作为服务端测试详细结果
本机测试结果〔单位：
ms〕
服务器端
cxf
客户端
cxf
axis1
客户端初始化
第1组
第2组
第3组
第4组
第5组
第1组
第2组
第3组
第4组
第5组
2547
2594
2563
2578
2563
2569
422
422
407
406
421
连续10次调用接口测试
第1组
第2组
第3组
第4组
第5组
第1组
第2组
第3组
第4组
第5组
1
297
281
281
282
266
234
219
219
234
219
225
2
0
0
0
15
15
0
16
0
0
16
3
0
16
16
0
0
16
15
16
16
0
4
0
0
0
0
0
0
0
0
0
15
5
16
0
0
0
0
15
16
15
0
0
6
0
15
15
0
16
0
0
0
16
0
7
0
0
0
0
0
16
16
16
0
16
8
15
0
0
0
0
0
0
0
15
0
9
0
0
0
0
15
16
15
16
0
16
10
0
16
16
15
0
0
0
0
16
0
10次平均值
后9次平均值
7
7
7
7
远程测试结果〔单位：
ms〕
服务器端
cxf
客户端
cxf
axis1
客户端初始化
第1组
第2组
第3组
第4组
第5组
第1组
第2组
第3组
第4组
第5组
2703
2547
2578
2563
2531
2584
406
406
422
407
422
连续10次调用接口测试
第1组
第2组
第3组
第4组
第5组
第1组
第2组
第3组
第4组
第5组
1
344
281
281
281
297
219
234
235
234
687
2
0
0
16
16
16
16
0
15
16
16
3
0
16
0
0
0
62
16
0
0
0
4
16
0
16
15
0
47
16
16
15
16
5
0
15
0
0
15
16
15
15
16
0
6
0
0
15
16
0
31
0
0
0
15
7
0
16
0
0
16
16
16
16
15
0
8
15
0
0
0
0
31
0
16
16
16
9
0
16
16
15
0
31
15
0
0
0
10
0
0
0
0
15
31
16
15
16
15
10次平均值
50
后9次平均值
7
7
表格4不同框架本机和远程测试结果
本机测试结果〔单位：
ms〕
服务器端
axis2
axis1
xfire
cxf
客户端
axis2
axis1
axis1
axis2
xfire+spring
axis1
cxf
axis1
客户端初始化
1138
1325
0
2569
10次中的初次调用值
1022
225
10次平均值
后9次平均值
25
远程测试结果〔单位：
ms〕
客户端初始化
1040
axis1
772
0
2994
2584
10次中的初次调用值
606
1010
1190
10次平均值
后9次平均值
4.3 结果分析
从数据可以看出，有下面几个特点：
● 客户端初次调用，初始化客户端stub对象时，大约在：
600ms～2500ms。
由于需要建立网络连接，初始化java相关对象，因此耗时较长。
● 客户端初始化stub后，接口初次调用，大约在：
400ms～1000ms。
相比后续的接口调用时间最长。
● 在第一次调用完毕后，随后的调用中，性能都明显提升。
大约在：
7ms～30ms。
● 本机测试与远程测试，性能上差距很微小，在高速的局域网内，性能差异几乎可以忽略。
● 在一样的服务端下，采用不同框架生成的stub代码调用时，时间上也存在一定的差异。
实际应用中，接口的调用都是在网络的不同的机器之间进展，本文也重点关注远程调用测试结果，在测试结果比拟上，可以看出：
● 最优组合是最差组合性能的5倍多。
⏹ 最优的组合为：
cxf客户端+cxf服务端，6ms左右。
⏹ 最差的组合为：
axis1客户端+axis1服务端，32ms左右。
● CXF作为服务端，对于不同的客户端调用时，性能最优。
从以上的结果进展分析得出用Axis2与CXF作为服务器端效率是比两外两者〔Axis1与xfire〕要高，所以下面就对CXF与Axis2进展比照
5 选择框架的方法
1.选择能够对我们的开发过程提供更多、更好帮助的Web开发框架
〔CXF与Axis2都是apache的开源框架,也是目前比拟流行的webservice框架，〕〔XX加个人观点〕
2.开发框架的学习一定要简单，上手一定要快，没有什么比使用能得到更深的体会。
那些动不动就需要半个月或者一个月学习周期的框架，实在是有些恐怖。
〔cxf学习本钱比axis2低〕【Axis2允许自己作为独立的应用来发布WebService，并提供了大量的功能和一个很好的模型，这个模型可以通过它本身的架构〔modulararchitecture〕不断添加新的功能。
有些开发人员认为这种方式对于他们的需求太过于繁琐。
这些开发人员会更喜欢CXF。
】【CXF更注重开发人员的工效〔ergonomics〕和嵌入能力〔embeddability〕。
大多数配置都可以API来完成，替代了比拟繁琐的XML配置文件，Spring的集成性经常的被提与，CXF支持Spring2.0和CXF'sAPI和Spring的配置文件可以非常好的对应。
CXF强调代码优先的设计方式〔code-firstdesign），使用了简单的API使得从现有的应用开发服务变得方便。
】{XX观点}
3.一定要能得到很好的技术支持，在应用的过程中，或多或少都会出现这样或者那样的问题，如果不能很快很好的解决，会对整个项目开发带来影响。
一定要考虑综合本钱，其实这是目前应用开源软件最大的问题，碰到问题除了死肯文档就是查阅源代码，或者是网上搜寻解决的方法，通常一个问题就会导致1-2天的开发停顿，严重的甚至需要一个星期或者更长，一个项目有上这么几次，项目整体的开发本钱嗖嗖的就上去了。
〔所以个人感觉应该选择比拟流行的框架，起码碰到问题还能上网搜索〕
4.开发框架结合其他技术的能力一定要强〔个人感觉和下同〕
5.开发框架的扩展能力一定要强。
在好的框架都有力所不与的地方，这就要求能很容易的扩展开发框架的功能，以满足新的业务需要。
同时要注意扩展的简单性，如果扩展框架的功能代价非常大，还不如不用呢。
〔axis2与cxf都支持很多优秀的框架〔上已提到〕，但axis2扩展性比cxf要好，axis2不仅支持java对c/C++提供支持〕〔个人观点〕【RESTEasy也能支持许多比拟优秀的框架】〔XX加个人观点〕
6.开发框架最好能提供可视化的开发和配置，可视化开发对开发效率的提高，已经得到业界公认。
〔暂时无法提供观点〕
7.开发框架的设计结构一定要合理，应用程序会基于这个框架，框架设计的不合理会大大影响到整个应用的可扩展性。
〔暂时无法提供观点〕
8.开发框架一定要是运行稳定的，运行效率高的。
框架的稳定性和运行效率直接影响到整个系统的稳定性和效率。
〔从上面的测试来看，cxf的效率要高于axis2，不知道在大并发量的时候系统的稳定性和安全性〕
9.开发框架一定要能很好的结合目前公司的积累。
在多年的开发中已有了很多积累，不能因为使用开发框架就不能再使用了，那未免有些得不偿失。
〔暂时无法提供观点〕
10.选择开发框架另外要注意的一点就是：
任何开发框架都不可能是十全十美的，也不可能是适应所有的应用场景的，也就是说任何开发框架都有它适用的X围。
所以选择的时候要注意判断应用的场景和开发框架的适用性。
〔暂时无法提供观点〕
6完毕语
ApacheCXF是CodehausXFire的第二代产品，目前在不同框架中性能最优，应该是开发者不错的选择，这与它本身的架构设计不无关系。
相比其他框架，CXF具有几个突出的特性：
支持JAX-WS、Spring集成、Aegi数据绑定、支持RESTfulservices、支持WS-*、Apache协议、代码实现简洁。
ApacheAxis2是ApacheAxis1的第二代产品，架构上也非常不错，关键特性：
支持多语言〔C/C++〕、支持各种规X、可插拔模块化设计、支持热部署等。
与CXF相比性能也非常优异。
RES
升级会员 