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

　　典型地，用户的商业事务处理包括许多个服务期调用。第一个调用初始化事务，返回一个"handle" 给客户端。后来的调用查询事务的完成--客户端使用句柄调用服务来检查事务是否得到处理。通常最后一个调用可得到完成的事务的状态。因此，一个商业模型，可在客户端程序内实现的商业模型，总是使得事务与低级别的服务器调用联系起来。

　　我们可以将收集频率的组件添加到我们的标准J2EE Web服务结构上。上图中的Payload软件包在服务器和客户端都有配置。稍后我会详细的讨论这个软件包，但是从结构的意义上来讲，这个软件包提供了几个服务。例如：客户端程序可以使用beginTransaction() 和 commitTransaction()来定界事务和记录次数。客户端Web服务软件包使用Payload软件包来连载次数报告给SOAP信息附件。服务器端的Web服务软件包使用Payload软件包将SOAP附件从引入的请求中剥离出来，并将它列队登记和报告。

　　这个实现中的系统操作很少因为客户端和服务器不交换任何新的通信--完成的事务的频率报告与下一个客户端请求一起运送。引入的唯一的新的处理就是客户端上的一些连载和服务器端排队等待的附件。整个实现很轻便，因为只要添加一行代码到每个程序Web方法上，并且代码还是一样的--如果Web方法的标记不变的话他也不会发生变化。

　　引入的最后一个组件就是信息驱动的EJB组件，它可读取连载的频率附件。典型的，这些附件将会记录到一个数据库中所以企业可以保存事务服务质量的历史纪录。企业可以使用这个数据库将真实的事务响应次数与服务器资源的使用联系起来，从而可以鉴定性的判断出哪个服务器组件才是关键的服务瓶颈。因为附件是排队等待的，所以频率读取器EJB组件应该在不同的J2EE服务器上运行，我们不希望使用商业EJB组件纪录的频率附件竞争资源。