转自IBM----用 SLA 保证 Web 服务

服务品质协议（service-level agreement）（SLA）是服务提供者和客户之间的一个正式合同，用来保证可计量的网络性能达到所定义的品质。SLA 为服务提供者提供了一种在当今多变而又竞争激烈的市场中胜过对手的方法。服务提供者可能是一个国内的 IT 组织、一个应用程序服务提供者（ASP）、一个网络服务提供者（NSP）、一个因特网服务提供者（ISP）、一个受管服务提供者（MSP）或者任何其它类型的服务提供者。

SLA 可以非常笼统或者极度详细，它一般都包含出现故障时服务提供者和客户应采取的步骤。服务提供者保证它提供的服务在一定百分比的时间内（例如，99.9%）是可用的。提供者还能够强制向客户通知 SLA 当机时间的最长和平均响应时间，或者在网络接口发生改变之前的最长和平均响应时间，并利用基于因特网的工作流自动化、分发和报告技术。如果经过指定的一段时期后提供者无法达到所定义的性能品质，客户就可以获得一些权利和赔偿。各个 SLA 的权利、赔偿和例外情况是不同的。客户还同意接受协议一般条款的指定例外情况。

在每个 SLA 中都必须精确定义服务品质；否则各方关于 SLA 将以哪种品质衡量什么服务或性能标准将无法达成一致。例如，一个客户可能认为一个双方同意的服务品质将衡量网络 A、网络 B 和网络 C，同时后两者连接到第一个，而服务提供者却认为它只衡量网络 A。还有一点很重要的是正常运行时间可用性百分比的小数位数：例如，一年中的当机小时数和当机天数比，99.999% 的正常运行时间所允许的当机时间比 99.9% 的正常运行时间所允许的当机时间还少。SLA 应该为客户包含进一个退出条款；当因为不能圆满解决经常发生的可用性、可靠性和安全性问题而使客户的业务运转频繁中断时，客户希望他有终止协议的权利。

新方向：用 SLA 保证 Web 服务

因特网（和企业内部网）的新方向提供了将来自不同来源（通过 Web 服务）的全异系统聚合并集成在一起的新方法和机会。随着不断扩展的分布式网络系统中提供者之间的关系变得更加复杂，Web 服务已经使 SLA 变得更富有挑战性。我们看到这些 SLA 不仅仅保证网络性能和正常运行时间可用性；由于每个 Web 服务都有不同的特征和网络需求，它们还被用来保证应用程序的性能。目前，一些 SLA 可以或者早已经作为公共 Web 服务公开了。

所有的 Web 服务都提供在 Web 上集成和修改系统组件的灵活性，以允许用户更改需求和在一定网络流量条件下处理网络资源争用。然而，这种灵活性要受到简单对象访问协议（Simple Object Access Protocol，SOAP）和统一描述、发现和集成（Universal Description and Discovery Integration，UDDI）互操作性问题的限制，因为一些主要厂商对这些协议的标准规范的解释是不同的。这意味着在把 Web 服务投入到生产环境和在 UDDI 或另一个公共注册中心将其作为公共服务发布之前，必须解决互操作性问题。对于 SLA 保证的 Web 服务（我们有时候称其为 SLA Web 服务）也是如此，不管该服务是独立的还是作为一套 Web 服务的一部分。后者的一个很好的示例是一个单独的 SLA，它适用于 Web 基础架构的每一段，从因特网到 Web 服务应用程序。

为现实世界做准备：测试机制

必须监视任何符合 HTTP、HTTPS、SOAP、UDDI 和 Web 服务描述语言（Web Service Description Language，WSDL）的由 SLA 保证的 Web 服务的可伸缩性和性能。在把 SLA 保证的 Web 服务投入到生产环境之前，必须解决所有的 SOAP、WSDL 和其它的互操作性问题。如果服务无法满足一定的标准，按照 SLA 的条款，提供服务的提供者可能要付财政责任，所以确保所有这些问题都在控制范围内特别重要。

在建立 SLA 保证的 Web 服务之前，应该使用测试机制 ― 比如来自 PushtoTest 的工具和脚本 ―（请参阅下面的 参考资料部分获得链接）来测试该 Web 服务的各种协议和组件。在启动服务后，这些测试工具可以充当 SLA 监视器。

表 1是一个核对表示例，当开发者测试一个将被 SLA 保证的服务时，他应该考虑这个表。

表 1. 在发布一个服务之前应该测试的 Web 服务功能