审核Web Service

收集数据

　　一旦你决定了你要修改的函数和要通过他们收集的数据，就要考虑收集数据的机制。为了做到这一点，我们创建了一个独立的名叫SSFAudit.AuditLog的组件。分析了AuditLog.cls对象的源程序后，你会注意到两个枚举类型的变量：ActionType和AuditType。ActionType这个枚举变量列出了我们审核的所有操作的ID。为了更容易生成报告，这些值接着将被复制到SSF-Report数据库的ActionType表中。（这些报告使用这些ID来映射报告中的字符串。）每一个审核的项目都必须包括一个被ActionType枚举的值，还要设置这个操作的完成的状态。它们使用AuditType变量中的值来确定操作成功还是失败了。如果操作失败了，这个值将表明失败是由服务器端还是客户端引起的。现在让我们看看SSFLicensing.Licensing对象是如何用AuditLog对象中的函数来审核RequestLicense的。

　　AuditLog对象包括一个叫Init的方法。这个方法允许调用者设置日志项目的初始属性，包括：

　　　· 操作类型

　　　· 操作开始时间

　　　· 计数器初始化（用来判断完成这个调用用了多少毫秒）

　　　· 事件的描述

　　RequestLicense用下列语句设置了这些属性：

oAudit.Init SSFAudit.REQUEST_LICENSE, GetNowAsUTC, GetTickCount, _ Replace(Replace( _ 　MESSAGE_REQUEST_LICENSE, _ 　MESSAGE_LICENSEE_NAME_MASK, sLicenseeName), _ 　MESSAGE_URI_MASK, URI)

　　GetNowAsUTS仅仅返回了当前的格林威治标准时间。 通过使用标准时间，我们可以定义发生在1:00 A.M的操作的意义。这点在跟踪更换密码等事件的时候是很重要的，因为大家一般都知道或能轻松地算出标准时间同本地时间偏差，进而算出操作发生时的本地时间。

　　这个声明还包括了一件看起来有点奇怪的事情：代码多次调用了Replace函数。这个函数的返回值是一个包含了被许可用户的姓名和请求许可的机器的URL的字符串。常数 MESSAGE_REQUEST_LICENSE , MESSAGE_LICENSEE_NAME_MASK和MESSAGE_URI_MASL是：

Private Const MESSAGE_LICENSEE_NAME_MASK = "$$.LI2cName.##" Private Const MESSAGE_URI_MASK = "$$.UR5I.##" Private Const MESSAGE_REQUEST_LICENSE = _ "Requesting license for " _ & MESSAGE_LICENSEE_NAME_MASK _ & ". URI: " & MESSAGE_URI_MASK

　　当把作为输入参数的获许人的名字和URI设为"TestSite" 和"http://testsite.com"后， 这个消息就变成" Requesting license for TestSite. URI: http://testsite.com. "

　　一旦这些信息被设置好了，限制被审核的方法的出口的数量就变得重要了。过多的出口可能会导致开发者错过了保存审核信息的地点。当我们增加用于审核不同方法的代码的时候， 我们必须重写许多代码以去除多个出口。如果我们没这么做，代码可能会与其他项目一起被保存到审核项目中， 从而降低了源程序的可读性。

　　如果代码的执行道路是唯一的, 我们就能假设失败是到最后一个操作时才发生的-一般就是数据库的保存操作-否则就会是完全成功。因此我们用Microsoft Visual Basic 的Let操作把AuditLog.Response设置 为AUDIT_SUCCESS。当一切都做好时我们就要准备退出这个函数， 代码调用HandleCleanup ，它执行诸如调用AuditLog.Save来设置计数器结束值、调用ReportError等操作。如果ReportError被调用，它将检查相关的错误代码并设置AuditLog中的描述以与错误信息相匹配。根据错误信息，它可能会把状态设成AUDIT_CLIENT_ERROR或AUDIT_SERVER_ERROR。这个值取决于错误代码的值。我们把错误分在不同的范围之内。1000-1999范围内的错误代码用来指示客户端错误；2000-2999范围内的错误代码用来指示服务器端错误。其他的错误代码都是由操作系统发出的。当错误代码不在我们的控制范围之内时，我们把这些信息写到事件日志中，并向调用程序返回错误信息，告诉它联系站点管理员用机器上的事件日志来解决问题。

　　当我们开始设计这种功能的时候，我们对问题的考虑有所不同。我们检查返回给审核日志的SOAP错误的数字，这样用户在又遇到问题时可以帮助我们在日志查找错误信息。这可能会导致一个问题，因为这个问题也许是由于不能连接到数据库服务器引起的。如果我们不能向数据库写数据, 我们如何返回错误代号呢? 另一个好的选择是用机器自己的事件日志。这本日志可能满了或有其它问题, 但它看起来比可能错过数据库的连接要好。这个变动的另一原因与审核日志消息队列有关。我们设计了SSFAudit 对象以具有队列的能力，但我们没有时间来测试这个配置。如果对象被排在了队列中，它就不能返回一个标识符了，因为排队的对象不能返回值。最后, 最好告诉这名顾客发生错误的机器和错误发生的时间。

　　小结

　　当审核Web Service时, 有时候花些时间决定用什么方法来跟踪是很重要的。请记住，Web Service与WSDL 和SOAP不完全一样。有些部分, 譬如管理函数, 也许在你想对在Web服务器上发生的事件画出一张完全的事件图时就需要被审核。一旦你有了这张列表，就要决定要监测哪些项目。我们应避免使用太复杂的解决方案，譬如为了能够向列表增加特定事件的数据，我们增加了一个通用描述字段，却不增加一张列表。对于暴露的方法, 要确定你限定了出口的数量。出口越多，你就越难确保审核每一个事件。要确保这些函数可以捕获所有的异常和错误。不这样做意味着在错误发生时，你可能不能进行跟踪。另外，再增加新的函数来审核时一定要小心。你可能会很容易地在创建一个大工程时没能审核所有的项目。

查看本文来源