J2EE Web服务客户端质量报告(五)

　　此次实现基本上是一个取样。它收集了大多数事务——当然足够测量服务的质量——但是不是全部。要纠正它我们得对客户端应用做一些调整。提高Payload软件包可持续会话期间的次数报告，但是这仍然不能保证所有事务都报告。因为我们在次数收集失败时仍然允许事务继续，这是一个很重要的目标，整个系统必须总是一个事务取样器，而不是彻底的记录器。

　　改进和后续工作

　　这个实现可在几个方面得到改进，从而为企业提供更多的便利。

　　你可以扩展ClientReport类，这样客户端就可以报告更多关于事务的信息。当分析服务器上的响应次数时，我们知道的关于事务的信息越多，分析就会越好。辨别出哪种事务要占用很长时间，这很重要。由于服务器瓶颈问题，占用很长时间的事务与生俱来的就要复杂一些。减小服务器瓶颈的压力是原则性的目标。改进ClientReport最好的方法是添加 (attribute,value)字符串排列，该排列允许客户端报告事务的二进制特征。

　　次数收集结构也有助于企业服务管理的其它方面。当服务器在域中有上千个或者上万个客户端的话，保证服务器软件升级后仍与现有的客户端库兼容，这很重要。但是哪种软件版本是客户端运行的呢？这常常难以确定，但是如果ClientReport 类可以使用客户端软件版本域扩展，也可使用客户端操作系统版本扩展，简单的次数数据库查询就会提供该信息。

　　你可以改进Payload软件包来报告客户端软件错误。客户端异常处理可保存产生失败的上下文的细节，这样当应用程序重启时Payload软件包可以上传该信息。这突出了主要潜在问题的一个方面：警报。 次数读取器EJB组件在收到客户端软件错误报告时，就可以开始它的商业工作流程处理。它可以产生一个SNMP (简单网络管理协议)陷阱或者发送email，允许客户服务人员启动一个调用到擅长解决问题的用户那里去。

　　接收精确的客户端响应次数

　　在本文中，我展示了如何将事务响应次数记录层压到现有的J2EE服务应用上。该方法可用于测量客户端应用方面的精确的响应次数。这个实现是轻便的。客户端和服务器之间不需要新的网络通信。次数有效载荷为低优先级的登记列队等待，所以预订服务器资源来处理应用程序。（全文完）