java web服务绩效评价：一个开发人员的角度
摘要
随着互联网的迅速发展，Web技术的发展变得非常重要。对于Web 2.0的演进，Web服务是必不可少的。Web服务是允许网络上不同平台的计算机进行交互通信的程序，而不需要额外的数据来读取诸如网页结构之类的人类阅读界面和格式。由于Web服务是互联网发展的未来趋势，用于开发的工具也很重要。尽管Web服务框架有多种选择可供选择，但开发人员应该根据框架的性能、时间和精力选择适合其应用程序的框架。在这个项目中，我们选择了四个共同的框架来比较他们在定性和定量指标。运行后，用SAS进行统计分析。
关键词：Web服务框架，性能，java，开发
1、引言
为了旅行到其他州或国家，这个人通常需要购买机票，租车，并预订酒店住宿。在处理飞机票时，大多数人甚至不得不买几张票，而不是一张票，直接把人送到最后一站。查找飞机到达和离开时间来连接每个航班可能需要数小时的搜索和计划。如果有一个虚拟代理能在短短几秒钟内完成这一切呢？所以通常人们会找代理人为他们做这件事。但是如果这个代理实际上是一个在线的虚拟代理，那该怎么办呢？如果每一个儿子刚刚进入他想从出发地、目的地、出发或到达的所需时间以及计算机所需的所有信息，一瞬间，计算机就显示出所有人可以选择和购买门票的结果。更好的是，这样的虚拟代理也有可能显示目的地的租车和酒店信息，并为你保留。通过使用这种类型的虚拟代理，可以节省大量的精力和时间，也可以比人类代理更准确。这种技术依赖于Web服务的发展和普及。
与其从头开始开发Web服务应用程序，还有很多开源框架使开发更容易。这些框架中的哪一个将是Web服务应用程序开发的更好选择？本研究通过几个测试和分析比较了四个流行的开源框架定性和定量。这四个框架是Apache轴、JBasSWS、XFLASH和Hessian。Web服务的更多介绍在第2节中完成。第3节描述了在本研究中使用的四个框架。在第4节中，更详细地解释了用于测量框架的度量。第5节介绍了用于分析测量结果的统计分析方法。在第6节中，显示和分析测试结果。结论在第7节中。
2、Web服务框架
由于Web服务被设计成以多种方式传输数据，所以一些公司和团体开发Web服务框架以方便Web服务开发人员，这样他们就不需要从头开始编写完整的Web服务。一些流行的框架作品是Apache轴心、JBasSWS、CordHuxXFARE和Ceko Hessian。在这一节中，将介绍这些框架。
2.1.Apache Axis
Apache Axis（可扩展交互系统）是一个开源的，基于java和XML Web服务架构，由Apache软件基金会（ASF）创建。该基金会是一个非营利性的公司，主要生产用于网络使用的软件，如服务器和服务器的框架。他们的项目是众所周知的合作，基于共识的开发过程和免费或开源软件。Apache轴心包有一个SOAP服务器和API用于实现和部署Web服务应用程序的实现。SOAP引擎构建SOAP处理器，如客户端、服务器和网关。这允许服务器和客户端通过SOAP消息进行通信。API支持多种局域网。除了java版，C 实现的也可以。它允许开发人员以多种方式构建应用程序。最简单的方法只需要文件的扩展名由“java”“。JWS”。这种方法的缺点是缺乏进一步配置的灵活性。
2.2.jbossws
JBossWS是JBoss实现与J2EE兼容的Web服务。该框架旨在更好地适应整个jboss架构，并且通常更适合于web服务的特定j2ee需求。JBoss没有为这个框架使用传统的Apache服务器，而是有自己的服务器，并建议在此服务器上使用该框架以获得最佳性能。与ASF类似，JBossCommunity是一组专注于开源项目的人。他们的项目强调Java企业中间件的开发，它是一种在应用程序、操作系统或两者之间架起桥梁的软件。
2.3 Codehaus XFire
Codehaus XFire是新一代的java肥皂架工作。它是一个免费开源的SOAP框架，允许您轻松轻松地实现Web服务。它还提供了许多Web服务规范中标识的特征，这些特征在大多数商业或开源工具中还不可用。它声称有较高的性能，因为它是建立在低内存STAX（流式API API）为基础的模型，但没有数据来证明这一事实。
2.4Hessian
Hessian二进制Web服务协议使开发的Web服务简单且可用，而不需要一个大的框架，这样开发人员就不必花费更多的时间和精力来学习协议的字母表。由于它是一个二进制协议，它在发送二进制数据时很好，而不需要用附件来扩展协议。J2ME设备（如手机PDA）可以使用Hessian连接到具有更好性能的Web服务，因为它是一个小协议。黑森以麻布命名，这是英国的麻布术语。它之所以命名是因为它是简单、实用、有用的，但却是非常普通的材料，这就像是Hessian协议的特性。
3、评价指标
在比较这个项目中的四个框架时，考虑了不同的因素。一些度量是为了阻止性能和效率，有些是为了显示透明性和抽象性。本节解释这些度量。
3.1潜伏期
在网络方面，延迟是将数据发送回请求所需的时间的表达式。这包括请求发送到服务器的时间，服务器在处理任务上花费的时间，以及将结果发送回的时间。网络延迟是由传播、传输、调制解调器和路由器处理、存储延迟等多种因素共同作用的结果。传播是一个物体（如数据）以光速从一个位置转移到另一个位置所需的时间。传输是从介质如光纤或无线网络的延迟。调制解调器和路由器需要时间来检查包的报头。存储延迟是实际硬件存储，如硬盘驱动器所需的时间来存储所接收的数据。在这个项目中，用不同的场景来测试延迟，例如请求1, 2, 3、4和5 MB数据，同时1、5、10、15, 20个客户端同时请求数据。从这些测试的结果，趋势可以发现并比较每个框架。
3.2.吞吐量
吞吐量是在某一时间单位内处理的客户端或数据量，如第二秒。它与延迟高度相关，因为具有高延迟的场景将导致低吞吐量，并且具有低延迟的场景将导致高吞吐量。然而，通过查看延迟图，我们只能告诉响应时间的趋势，而我们可以通过查看吞吐量图来确定框架的最有效方案。
3.3.内存使用
在计算中，内存是数据存储，用于临时存储计算机的计算数据。有各种各样的存储器，如高速缓冲存储器、闪存、随机存取存储器（RAM）、虚拟存储器等。它们都是由于成本和空间而在服务器中受到限制的。使用较少内存的框架将具有允许服务器更高容量的优点。
3.4.CPU使用情况
中央处理器（CPU），也称为处理器，是用于解释程序指令和过程数据的计算机中的一个组件。虽然它只能一次处理一个任务，但是当有多个任务要完成时，而不是完成一个任务，然后转到另一个任务，CPU被设计成在必要之前完成一个任务，这样它就可以像在S中执行多个任务一样。命名时间。然而，大型任务可能占用大量CPU时间，这会缩短为其他任务安排的时间。使用较少CPU的框架将允许服务器有更多的时间来执行其他任务。
3.5.源代码行
在框架中使用的源代码行（SLoC）可以指示框架的透明性和抽象性。框架的主要目标是通过不必从头开始编写整个代码来节省开发人员的时间和精力。因此，框架所需的代码行越少，这个框架就节省了更多的时间和精力。然而，代码行不能精确，因为有些行可能很长，而有些行是短的。因此，文件的数量和文件的大小也是一个考虑因素。
4、统计分析方法
在检索测试数据以比较性能之后，我们需要一种方法来分析结果。通过简单地计算平均响应时间并使其成为图形对于分析来说是不够的。查看平均响应时间1.5秒和1.6秒，我们不能确定这是否是很大的差异。因此，需要统计分析方法来判断差异是否显著。在这个项目中，一般的线性模型（GLM）〔9〕和双向方差分析（双向方差分析）被用于统计分析。此外，统计分析系统（SAS）〔10〕被用作辅助计算所需的统计分析的工具。
4.1.SAS系统
SAS系统是具有多种统计模块和程序的统计分析软件。他们使用第四代编程语言（4GL）来编写代码，程序由三个主要组成部分——数据步骤、过程步骤和宏语言组成。数据步骤是用于输入数据，比如在代码中插入数据或从数据文件中读取数据。过程步骤是使用统计方法和模型来分析在数据步骤中读取的数据。宏语言是为了减少在整个程序中反复使用的函数的冗余。
4.2. GLM模型
GLM模型是在一般情况下使用的统计线性模型。它是许多统计分析的基础，如t检验、方差分析、协方差分析（ANCOVA）等。了解GLM模型是如何工作的最简单的例子是两个变量的情况。该分析的目的是使用一种方法来准确地描述该图中的信息。使用GLM模型，我们试图找到一条直线，它与情节中的所有点最接近。这条线将被写成：y＝b0 b1x e，其中y是y轴变量，x是x轴变量，b0是截距（y等于x 0时的值），b1是直线的斜率，e是误差。通过求解B0和B1，我们可以得到描述该点中的点的线性线的信息。在其他两个变量的情况下，该公式可以扩展为：Y= B0 B1x1 B2x2 B3x3 hellip; bnxn e，其中n是情况变量的数目。但是解决这些问题的机制是相同的。
5、结果与分析
为了从SAS分析中获得最佳结果，每种情况被测试二十次。由于测试了四个具有五个不同数量的客户端的框架，所以有二十种不同的情况。对于二十种不同情况添加二十个测试时间将导致400个数据集由SAS计算。除了客户数量之外，还考虑了数据的大小。也有五个不同大小的数据发送，将有二十个案件，总共有400个数据集。响应时间是通过在调用Web服务之前记录时间并在接收到请求的数据之后记录时间，然后减去时差来测量的。
5.1.results
5.1.1.client场景
测试在不同的情况下的四个不同的框架，Web服务应用程序的数据是由发送出去。五种的数量是基于客户的性能测试框架四是客户客户1，5，10，15和20个客户，每个客户的客户查询，1 MB的数据。平均响应时间为每个方案和每个记录的框架是用于分析。在图1中所示的结果是相关的。通过对计算结果的吞吐量，平均每2显示了为每个客户的情况和第二框架。图2显示了每个框架最高效的客户端场景。Apache轴可以在到达10个客户端或更多客户端的情况下每秒处理4.993个客户端。树脂Hessian可以处理4.807个客户每秒在相同的场景。JBasWSWs在每个场景中每秒处理0.943个客户端。科德豪斯XFLASH似乎最有效地围绕5个客户的场景，每秒处理大约2.892个客户端。
5.1.2数据大小方案
至于基于不同数据大小的五个场景的结果和平均吞吐量，它们在图3和图4中示出。
图4显示了每个框架最有效的数据大小方案。所有帧在发送2 MB或更多数据后达到最佳性能。Apache轴的平均值为3.617 Mb/s，JBossWS为1.287 Mb/s，Codehaus XFire为1.240，树脂Hessian为1.017。
从上面的所有图表中，看起来Apache轴在所有场景中都具有最好的性能，但是SASS应该做进一步的分析。
5.2分析
显然，响应时间的数量很大程度上取决于框架的选择、数据传递的数量以及从Web服务调用任务的客户端的数量。这使得这三个因素对测试结果有意义，即响应时间。但是在进行进一步的分析之前，我们必须使用GLM模型来确定三个因素之间的相互作用是否也是重要的因素。如果交互不是，我们可以使用TUKEY方法进行多个COM比较，并且直接地看到哪个框架在所有情况下都具有更好的性能，并且更糟；如果交互是重要的因素，那么我们将需要逐个分析结果。
5.2.1客户端场景
首先分析客户端场景的结果，我们使用SAS系统来查看每个因素的重要性。这不仅是客户数量和框架选择的重要因素，而且是它们之间的相互作用。这意味着如果某个框架在某些场景中比其他一些框架明显快，则框架不一定比其他场景中的框架更快。因此，SAS不能直接比较所有场景中的所有框架。
在这种情况下，使用一般线性模型（GLM）过程的成对比较。第一帧与第一场景中的第二帧相比，然后是第一到第三，第一到第四，第二到第三，第二到第四，和第三到第四。所以在每个场景中都有六个COM选项。
表1应该一次读取一个场景，即当我们查看一个客户端场景时，我们忽略了5个客户端、10个客户端、15个客户端和20个客户端场景中的数据。具有较低字母的组具有较低的响应时间，这意味着更好的性能。在1-客户端场景中，所有框架都被放入组A中，这意味着它们在这个场景中都具有大致相同的性能。在5-客户端场景中，JBossWS被放入B组，而其他组处于A组。这意味着在这种情况下，JBasWSWs的性能比其他的性能差，而其他的仍然是相同的。在最后三个场景中，Apache轴和树脂Hessian比CoDayuxxFlash更快，而CoDayuxxFlash比JBossWS快。
虽然从SAS分析结果来看，框架的更好性能是一种情况，随着客户端数量的增加，性能COM模式趋向相同，Apache轴和树脂Hessian优于CODEHAUS XFARE，而CODEHUS XFiSE优于JBoSWSWS。
5.2.2数据大小方案
基于数据大小的性能分析过程与基于客户量的分析过程是一样的。首先，确定数据大小和框架选择之间的相互作用。
结果表明，数据大小与框架选择的交互作用也是一个重要因素。因此，再次使用相同的成对比较程序。
当发送1 MB时，Apache轴比CODHAUS XFLASE好，这比JBasSWS好，并且比树脂Hessian好。在第二种情况下，比较几乎是相同的，但是CODEHAUS XFARE和JBossWS的性能是等价的。在最后三个场景中，JBasWSWS和CoH
全文共6624字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[13017]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
