【 tulaoshi.com - 编程语言 】
概要
本文实现了记录J2EE（Java2平台企业版）Web服务的客户端响应次数的一个通用的结构。记录的响应次数是真实的客户端响应次数，所以它们实际上反映了用户对服务质量的看法。
![]()
![]()
![]()
![]()
!-- frame contents -- !-- /frame contents --
![]()
![]()
![]()
![]()
实验的样品是使用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组件纪录的频率附件竞争资源。进入讨论组讨论。
