级别： 初级 Judith M. Myerson (jmyerson@bellatlantic.net), 系统架构师和工程师
2004 年 10 月 01 日 当 Web 服务应用程序与企业应用程序集成（EAI）的整合失败时，可能是因为它们没有针对各种类型的互操作性进行充分的测试 － 不仅仅是 SOAP，还有中间件（包括在面向对象体系结构（SOA）中的非 Web 服务）、业务流程、设计方面的考虑和网络基础架构。Judith M. Myerson 通过解释 Web 服务应用程序和 EAI 集成的局限性，帮助您节省集成时间并帮您更好的理解 EAI 和 Web 服务之间主要的区别。她同样向您展示了如何开发系统中断阀值，以作为提高您的 Web 服务满足 SOA 用户动态消费和生产的资源在运行时可用的 SLA 保证的一种方式。
Web 服务的局限性
让我们首先按照重要度的先后顺序了解 Web 服务的一些局限性（与 EAI 应用程序相对比），然后再讨论系统中断阀值是如何对其产生影响的。
局限 1：
Web 服务通常不能执行其自身。它需要一系列的业务流程或者 SOA 中更高级别的服务来操控多种服务的执行以实现既定目标。然而，EAI 应用程序却能自我执行，有时还能操控 Web 服务。
局限 2：
虽然 Web 服务基于日益增长的业界标准清单，但 SOAP 在行业内尚未得到充分的使用。大多数 EAI 标准是专有的。
局限 3：
集成某些 Web 服务会出现这样的问题，这个 Web 服务需要跟其他 Web 服务来在短时间内完成业务流程，而且这些 Web 服务包含了基于一系列复杂业务流程规则的长时间运行的应用程序。这是因为 Web 服务必须松散耦合而且必须同步执行，因此，Web 服务使用者必须时刻守着。然而，EAI 应用程序的耦合程度非常的紧密，而且能同步也能异步。这样 SOA 服务的使用者就不用时刻都在场了。
局限 4：
针对客户关系、产品链管理和资源规划的 Web 服务有不同的集成规则集，虽然这些规则能在企业之间集成和集合 Web 服务应用程序时互相合作。相反，EAI 系统的组件可以通过集成总线相互通信，该集成总线作为中间件存于 EAI 应用程序（包含产品链管理和其他资源规划）、遗留系统、数据库、Web 服务和非基于 Web 服务的应用程序之间。
系统中断阀值
考虑到 Web 服务主要的局限性是很少自我执行。在 SLA 中，系统中断对 Web 服务正常运行时间的可用性能产生什么影响呢？在您开发性能表来指示阀值对正常运行时间的可用性的影响时，该建立什么系统断阀值呢？
我们是否正在讨论单个 Web 服务的阀值？还是针对多个 Web 服务而言？或者我们正在把 SOA 中更高层次的服务来指导 Web 服务和不基于 Web 服务的应用程序？当 Web 服务运行超时时又会发生什么呢？运行时间超时对定义阀值有何影响？
阀值方案
首先，考虑三种可能的阀值：50％, 67％和 98％。它们都意谓着什么呢？如
图 1 所示，一个阀值为 50％ 的系统中断，意谓着整个系统在 0％和 49.999％之间的中断不太重要且不用考虑将其作为性能表的一部分。它的数值太低以至于无法计算，例如，99.5％以上的有效性。
图 1.系统中断阀值取 50％
另一方面，在 50％ 和 100％的中断很重要且应该考虑作为性能表的一部分。对 67％和 98％阀值也同样如此。（参见图
2 和
3）。更高的阀值可以计算，例如，99.7％以上的都可用。
图 2.系统中断阀值取 67％
图 3.系统中断阀值取 98％
阀值越高，监控阀值服务花的代价就越高。同样地，阀值越高，当服务提供者未能遇见某个阀值时，他需付出的阀值损失也会越高。阀值损失是除在 在 Web 服务 SLA 中指定的正常运行时间有效性损失以外的损失。
可忽略的阀值
在我写的另一篇文章“Guarantee your Web service with a SLA”中（参见
参考资料），我曾提及，当数字式话音在流向您正在查看的 Web 站点是出现断断续续，或者您的鼠标在短时间内出现了轻微颤动，这些时候都可能造成数据包丢失。不连贯的话音和抖动的光标都会在较短时间内对系统产生干扰，这些干扰对人眼来说可能是观测不到的，但是性能表指示器就能自动进行操作，对系统中断发生在0.6％的事件进行记录。
光标发生抖动只是很小的麻烦事，用户一般都可以忍耐 8 或者 10 秒钟。显然，由于数据包丢失产生的影响程度微乎其微，所以这样的中断阀值是根本无关紧要的。
重要的阀值
系统重要中断的一个很好的范例就是由于提供者的疏忽而引起的服务拒绝（denial of service），不包括客户疏忽或是故意不操作以及监控和测量系统的失败。
表 1 列举了其他异常。
表 1. 提供者疏忽异常
- 光纤意外中断
- 定期维护操作
- 网络流量过大、黑客攻击和一般攻击
- 无法得到提供 SLA 所需的供给或设备
|
|
所有这些异常都潜在地包含在 SLA 中。然而，如果竞争的服务提供了带有更少异常情况的 SLA，我们推荐让客户可以选择那些在业务运转中提供更长正常运行时间并且有更好的服务保证的协定，包括更高系统中断阀值（不可抗力、战争和罢工都确实都是确确实实的异常情况，除非根据保险业和灾难恢复代价作出说明）。
超时
当 Web 服务运行超时会发生什么呢？会对相关联的 Web 服务产生多米诺效应使其超时，从而导致系统中断发生吗？如果超时只影响单个 Web 服务，产生消息要求用户重新登录或是稍后再来，那么中断是无关紧要的。
另一方面，如果多个 Web 服务在同一时间超时，那么您可能看到“Not Found”页面，特别是在业务流程的不同阶段拒绝对用户的服务（例如，对购买一个物品进行批准和发起检查）。然而光标的轻微抖动都可能产生信息包的丢失，也可能产生 Web 服务超时的结果。
Web 服务范例
现在，在第二代 Web 服务应用程序范例中应用阀值（参见
参考资料）如
图 4 所示——特别是介于提供者和代理之间、提供者和客户之间以及客户和提供者之间的阀值。
图 4. Web 服务范例中每个参与成员的阀值
设置阀值
当应用程序提供者，如
图 4 所示，向应用程序代理发送发布服务的请求时，而且在传输途中发生了不曾预料到的中断，那么系统中断阀值必须为 98.7％ 或者更大。当代理在服务发布成功或是失败时向提供者发送警告，而且此时发生了数据包丢失，那么取 98.7％ 或是更大的网络中断阀值就十分重要。
然而，由于临时不曾预料到的中断干扰服务，代理再次给客户端发送服务发现的状态警告时，系统干扰阀值会稍微高些——这是因为指定在 SLA 协议中的 Web 服务发现的重要性取值 为 99.5％。在客户端和提供者之间的系统中断阀值设为 96.97％——比其他两个阀值稍微低些。
变化的阀值
在第二代 Web 服务应用程序中的应用程序提供者、代理和客户的阀值无需完全一致。阀值不仅可以根据每个参与者的不同而变化，还能随着时间发生变化（例如，网络流量处在高峰点或低谷点）。这就依赖于，例如，网络流量、带宽之间在进入瓶颈时的互相竞争和 SOA 中 Web 服务和不基于 Web 服务之间不同的带宽需求。
例如，在提供者向代理传送服务公布请求时将阀值设为 98.5％并在代理向提供者传送警告时设成 98.7％。同样地，当客户端向代理传送服务发现请求时将阀值设置为 99.2%，而当代理向客户端传送警告时将阀值设成 99.5％。
同意阀值
绝大多数 SLA 认为正常运行时间可用性的测量隐藏了那些 SLA 没有发觉的系统中断。一种解决该问题的方法是开发可测量的阀值，这样开发者可以用来测试 SOA 中正常运行时间的可用性。
在 SLA 中列出系统中断阀值，依赖于客户端同意的 SLA 指定的 Web 服务应用程序的不可预料的系统中断，比如 99.9％正常运行时间可用性。例如，如果客户端允许潜在重要的系统中断事件取 98.1％ 的阀值，那么您可以应用这个阀值来保证 99.9％ 正常运行时间可用性。您可以帮助客户端制定阀值协定。
结束语
您应该在一定范围考虑到由于数据包丢失和网络传输瓶颈（这两种情况根据系统的历史中断都非常可能发生）而导致对正常时间运行可用性的重要负面影响。之后，开发一套解决方案，集成 Web 服务应用程序到 EAI，以使在 SLA 中指定的正常运行时间可用性最大化。系统中断的阀值越高，SLA 为 Web 服务集成到 EAI 提供的对正常运行时间可用性的保证就越好。
参考资料
关于作者
对本文的评价
| 
