J2EE Web服务客户端质量报告(一)[Java编程]

概要

本文实现了记录J2EE（Java2平台企业版）Web服务的客户端呼应次数的一个通用的构造.记录的呼应次数是真实的客户端呼应次数,所以它们实际上反映了用户对服务质量的见解.实行的样品是利用Sun ONE （开放式网络环境）利用服务器和IDE成立起来的,但是这个办法很普通,很简单奉行到别的J2EE实现上.

Web服务正疾速的成为实现客户端-服务器系统的首选构造.它的长处是:企业可以正式的定义一组服务,然后生成通讯用的完好的客户端和服务器的代码库,从而简化新的客户端对合理的Web资源的拜候.

但是,Web 服务在简化客户端-服务器系统的成立的同时,监控服务质量就变得很重要. 假定有一个在用户的态度上提交处理的客户端利用程序.而企业事件普通要调用好几个Web服务:初始调用递交工作内容,接下来的调用查抄实现,终究调用得出后果.一个调用就是一个特别的HTTP/SOAP (简单对象拜候协议)交换.假定你是IT部门专门负责监控服务器装载和猜测将来需求的工作人员,你必须得答复这个基本问题:"我目前管理我的客户端怎样呢?关于将来的管理,我还需求什么东西?"

假如你只有HTTP日记的话,就很难答复上述问题了.客户端只关心事件的处理,但是因为每个事件包含几个HTTP恳求,关于评价服务质量,你最多只能开辟自定义数据采集软件,该软件可通过HTTP日记做出指导并成立用户事件处理的模子.就算是这样,你所拥有的信息仍旧有限,因为它不能反映网络传送大概客户端利用程序的内务操作.

本文的中央机惟是:事件服务质量用客户端评价最好.这儿采取的办法就是答应客户端记录实际的事件呼应次数.客户端利用程序通过将呼应时间报告增添到下一个弹出的事件处理恳求上,从而上传呼应时间报告给服务器.服务器取出这些附件并将他们列队储存和在线解析.

构造

基于客户端的频率记录构造的目标就是:记录用的下部构造必须是轻型的,它不但有利于实现运行的内务开销还可以减轻增添它到一个现有的实现的负担.我们也但愿该构造对供应的服务没有限制,我们很想可以将服务增添到一个现有的、可以尽大概简单地利用Web服务的客户端-服务器系统上.

我们的构造的另一个目标是:企业利用程序自身的坚固性不要太差.我们将引入一些新的、简单做到的步骤到利用程序的处理工作流程中.并且我们可以保证这些新步骤中的任何弊端都可以得处处理,我们不会因为不能将频率用于程序就让企业事件的处理失利

下图显示了一个典型的J2EE(Java 2 平台企业版)Web服务的客户端-服务器利用程序.典型的组件用粗线标明;我们增添的新组件用于汇集频率,它采取红线标明.

J2EE Web services: Metrics-gathering architecture

"J2EE Application Server"区域表示现有的服务器资源.他们是用来处理客户端恳求的企业JavaBeans (EJB) 组件.工具可自动的生成Web服务软件包.EJB组件和相关的 Web 服务模块被当作J2EE利用程序配置到J2EE服务器上.当利用程序配置时,客户端可以通过调用程序WSDL (Web 服务描写语言)服务来判断一个服务.WSDL服务对程序供应的服务给出正式的定义.

"Application Client"区域由程序组件和Web服务软件包构成.程序组件实现商业逻辑和用户界面.Web服务软件包可自动地通过WSDL编译器和J2EE服务器程序供应的WSDL服务成立出来.

从理论上来说,整个客户端-服务器系统有两层.利用程序层在服务器端拥有EJB组件,在客户端拥有一个利用程序.Web 服务层有一个服务器实现和一个客户端实现,二者都可以自动产生.

典型地,用户的商业事件处理包含很多个服务期调用.第一个调用初始化事件,返回一个"handle" 给客户端.后来的调用查询事件的完成--客户端利用句柄调用服务来查抄事件能否得处处理.普通最后一个调用可得到完成的事件的状况.因此,一个商业模子,可在客户端程序内实现的商业模子,老是使得事件与初级别的服务器调用接洽起来.

我们可以将汇集频率的组件增添到我们的尺度J2EE Web服务构造上.上图中的Payload软件包在服务器和客户端都有配置.稍后我会具体的谈论这个软件包,但是从构造的意义上来说,这个软件包供应了几个服务.比方:客户端程序可以利用beginTransaction() 和 commitTransaction()来定界事件和记录次数.客户端Web服务软件包利用Payload软件包来连载次数报告给SOAP信息附件.服务器端的Web服务软件包利用Payload软件包将SOAP附件从引入的恳求中剥离出来,并将它列队登记和报告.

这个实现中的系统操作很少因为客户端和服务器不交换任何新的通信--完成的事件的频率报告与下一个客户端恳求一同运送.引入的唯一的新的处理就是客户端上的一些连载和服务器端列队等候的附件.整个实现很简便,因为只要增添一行代码到每个程序Web办法上,并且代码还是一样的--假如Web办法的标志不变的话他也不会发生改变.

引入的最后一个组件就是信息驱动的EJB组件,它可读取连载的频率附件.典型的,这些附件将会记录到一个数据库中所以企业可以保存事件服务质量的历史记录.企业可以利用这个数据库将真实的事件呼应次数与服务器资源的利用接洽起来,从而可以断定性的判断出哪个服务器组件才是关键的服务瓶颈.因为附件是列队等候的,所以频率读取器EJB组件应当在差别的J2EE服务器上运行,我们不但愿利用商业EJB组件记录的频率附件竞争资源.

　　以上是“J2EE Web服务客户端质量报告(一)[Java编程]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：