| 本文内容包括:
对将基于 XML 二进制优化打包 (XML-binary Optimized Packaging,
XOP) 的服务连接到外部服务有兴趣吗？在本文中，我们将开发桥接 Web 服务、确定文件大小阈值，并设置多个队列。理解外部文件依赖项、创建非线性队列、使用非线性读取以及设置最佳大小阈值。同时使用
IBM Rational Web Developer® 和 IBM WebSphere Business Modeler®
来简化开发流程。
引言
在本系列的第 7 部分，我们向您介绍了为何基于 XML 的 Web 服务应用程序会变得过于庞大。当大量使用
Web 服务时，这些 Web 服务将导致系统过载，进而阻塞网络通信。为了解决这个问题，我们应用 XML 二进制优化打包 (XOP)
规范来提高 Web 服务的速度。
该 XOP 规范是一个标准草案，旨在比当前 XML 解析器更有效地处理 Web 服务。解析器的行为更像是解释器，而不是编译器。当解析器读写大型文件（特别是文本格式的）时，并不能达到其读取较小的文本文件或计算简单函数的性能。甚至加密也可能使
Web 服务陷于停顿，因为必须执行复杂的计算才能获得希望的结果。
在本文中，我们将继续介绍 XOP 规范，探讨如何将一个组织内部遵循 XOP 的 Web 服务连接到外部没有遵循此规范的繁忙的
Web 服务上。当系统限制了带宽、访问控制数以及 Web 请求数时，此类连接将变得非常重要。
开发桥接 Web 服务
您需要开发桥接 Web 服务来测试从外部 Web 服务传入的文件是否遵循 XOP。如果测试成功，桥接
Web 服务将允许外部文件传入。如果测试失败，桥接 Web 服务将进行第二次测试以确定文件的大小。如果文件很小，则桥接 Web
服务允许这些文件传入。如果该文件在这两次测试中均失败，则桥接 Web 服务会将它路由到一个内部 Web 服务，然后您可以使用该服务将文件转换成二进制格式以使它遵循
XOP。在本文中，您将了解如何使用 IBM 工具来设置桥接 Web 服务中的队列以挑选出外部文件。
那么，应该考虑哪种队列呢？我们先看一个简单的队列，然后再介绍一个较复杂的队列。对于任何队列类型，首先都应该对作为桥接
Web 服务单元到达队列的外部文件的特性和为接收这些文件而设计的目标 Web 服务进行评估。图 1 显示了进入一个简单队列的外部文件。数字的粗度代表文件的大小。数字越粗，文件就越大。
图 1. 简单队列
接下来，您需要确定每个文件在进入队列之后的行为。问自己以下问题：
- 当进入队列时，文件能否处理服务延迟？
- 文件是否会不耐烦并想要进入另一个队列以获得更快的服务？
- 队列应该有多大？
- 队列的支持程度应该有多大？
- 当队列达到其最大值时，Web 服务应该如何通知发送文件的外部 Web 服务必须等待一段时间才能将文件发送到该桥接
Web 服务上？
- 它如果无法等待，则应该将文件发送到同一个桥接 Web 服务的另一个队列上，还是发送到不同的桥接
Web 服务上？
确定文件大小阈值
桥接 Web 服务中的队列如何知道最佳的文件大小是多少呢？您需要建立一套大小阈值机制，将其设置在一定水平上以衡量外部文件的大小是否最优。如果文件大小在阈值或阈值以下，则桥接
Web 服务会将该文件从其队列中释放出来，以供请求处理的面向服务体系结构 (Service-Oriented Architecture，SOA)
做进一步处理。如果文件超出阈值，则 Web 服务会将其标记为“过于庞大”。然后将被标记的文件释放并发送到 Web 服务文件优化器上。
当文件优化器接收到该文件时，会对其进行 XOP 规范的处理以使其变得更小。然后对处理过的文件进行检查，以确定其大小是否在大小阈值的范围之内。如果测试表明确实如此，则认为该文件是最优的。否则，将向您发出警报，提示您检查文件内容或编程逻辑。
设置多个队列
桥接 Web 服务中只有单个队列的问题是每个文件都必须耐心地等待轮到它的时候。文件无法绕过在它前面的另一个文件，就像在单行道上车辆无法超越在它前面行驶缓慢的车辆一样。您会问，那应该怎样解决呢？
一种可能的回答是设置两个队列。您已经了解了如何在桥接 Web 服务中设置一个队列来从外部 Web
服务接收传入的文件。如果该文件已在队列中，但不符合阈值范围，则应该对它进行标记并允许它从该队列跳到另一个队列中。在这个次“优先”的队列中，该文件会被释放并发送到
Web 服务文件优先器的队列中，此优先器将使用 XOP 规范来处理该文件。这种解决方案对于不依赖于其他文件（过于庞大或者不过于庞大的）的文件来说足够了。
理解外部文件依赖项
上述方案适用于桥接 Web 服务释放到内部 Web 服务的一系列外部文件都没有连接到其他文件的情况。如果只有外部文件有多个依赖项需要连接
SOA 中请求的 Web 服务才能完成一个或一系列任务，则会出现什么情况呢？而当内部 Web 服务中有两个经过裁减的文件需要连接到一个正等待优化的过于庞大的文件时，又会出现什么情况呢？
我们假设此请求的 Web 服务执行了两个任务。首先，它从 Web 服务文件优化器接收这两个文件。然后，它几乎同时要求这两个文件连接到仍在桥接
Web 服务的队列中的第三个文件。在连接完成后，将释放该第三个文件以便文件优化器进行处理。如果在一定时间范围内该文件没有获得最优化，则请求的
Web 服务的性能会下降。
Web 服务文件优化器中的队列是单一的，这意味着它不会在意该文件是否等待被优化而等得不耐烦。该文件必须线性地等待轮到它的时候。文件被优化需要一定的时间，这将导致请求的
Web 服务的性能下降。
创建非线性队列
处理这种等得不耐烦的文件的一种方式是在 Web 服务文件优化器中创建非线性队列。当非线性接收队列从外部
Web 服务接收过于庞大的文件时，文件优化器可以将该文件移到可以立即进行多线程优化的另一个非线性队列中。
如果有许多过于庞大的文件要处理，则可能需要根据每个文件的优先级和大小建立多个不同优先级的非线性队列。优先级较高的文件可以分配到高优先级的非线性队列中。类似地，那些优先级较低的文件可以分配到低优先级的非线性队列中。优先级在最高和最低之间的其他任何文件可以分配到合适优先级的非线性队列中。
为了使多线程有效地执行，您必须确保操作系统有足够的资源来执行优化程序（文件优化器用它来根据每个文件的优先级和大小对文件进行裁减）的不同部分。您必须谨慎地设计该程序，以保证所有线程都可以同时运行而不会相互干扰。
使用非线性读取
我们假定操作系统能够使设计为一次性将 10 个文件优化成裁减版的程序完全多线程化。并假设文件优化器以多线程方式从其队列中释放三个过于庞大的文件以供该程序做进一步处理。从非线性队列中获取这三个过于庞大的文件加速了文件相互连接的过程。
您可以使用 Rational Web Developer，以某种方式设计 Web 服务，通过这种方式，Web
服务可以根据业务流程、多线程模式、非线性算法以及文件的优先级和大小读取这些文件。图 2 显示了非线性高优先级队列和进行中的多线程优化之间的关联。
图 2. 非线性高优先级队列
设置最佳大小阈值
那么，应该如何确定需要优化的文件的大小阈值呢？您可以使用 WebSphere Business
Modeler 来帮助开发人员和业务分析人员达成一个阈值范围（允许在队列中动态更改）。设置阈值范围取决于网络流量的大小、最大无故障运行时间以及峰值时间的带宽总量。还取决于生命周期特定时刻的
Web 服务编排方式、防御深度设置、访问和执行次数的频繁程度、延迟问题，以及在给定时间内发生的 Web 请求数。
假设每个要优化的文件（全都标记为“高优先级”）的大小阈值都有显著差别。为了解决这个问题，我们考虑设置三种不同优先级的阈值队列：
- 高优先级、大小较小的阈值队列
- 高优先级、大小中等的阈值队列
- 高优先级、大小较大的阈值队列
您必须谨慎地设计该程序，以保证所有线程都可以同时运行而不会相互干扰。
结束语
在本文中您了解到，为了开发将基于 XOP 的 Web 服务连接到外部服务的桥接 Web 服务，我们需要有计划地理解文件依赖项和设置多个非线性队列。同样重要的是，团队成员（包括系统管理员、业务分析人员和开发人员）之间必须相互交流，以确保获得最佳文件大小阈值和从高优先级队列进行最佳非线性读取，以及确定可以将多少个文件导入多个非线性队列而不会导致系统过载。
为了使工作更简单，请基于用 IBM WebSphere Business Modeler 建模的业务流程并使用
IBM Rational Web Developer 开发 Web 服务。这些产品可以简化将基于 XOP 的 Web 服务连接到外部服务的工作。 |
