本文说明了WebSphere Application Server Version 6 如何用来优化 XML 的消息处理，以及如何使企业成为可持续的大容量操作环境。我们建立了一个独特的体系结构视图，它能够引起那些关注于使用 SOA 和 Web 服务以实现高吞吐量的 J2EE 和 XML 技术读者的共鸣。

　　引言

　　请您考虑一个问题:”我的 SOA 环境的吞吐量给用户带来影响了么?如果答案是“是”，您并不是唯一碰到该问题的人。根据对全球 2000 强公司的几项近期调查(包括 In-Stat/ Reed Elsevier Business Information Network and Summit Strategies, Inc 在 2005 年发布的报告)，在金融服务、运输、电信以及全球制造行业的调查对象中，百分之七十六的企业将吞吐量作为2006 年开发和部署 SOA 驱动的企业软件(尤其是使用 Web 服务)的工作中最关键的问题之一。

　　相同的调查对象说明了为什么吞吐量如此重要:业务需求要求以实时或非实时的方式来更新存储，每秒钟处理上千项服务请求(SRS)，并在企业范围以及全球扩展价值链中发送财务和订单信息。除了大容量之外，基于SOA 的解决方案常常需要允许以各种数据格式(如 ACORD、IFX 和TINA)通过 HTTP 或 JMS 等多种协议进行消息转换，处理高峰时期的瓶颈而不降低服务级别，并且提供全面的审核记录。

　　服务请求者和服务提供者之间基于 XML 的信息交换是支持 SOA 技术(比如 Web 服务)的关键。XML提供了重要的优点，但这些优点是以性能和吞吐量为代价的。

　　首先，使用 XML编码方式的消息比二进制编码的消息平均要大六至八倍。并且它们还在不断地增大，即信息交换中使用的是整个文档(如附带配送信息、信用报告、详细地图和产品目录的购买订单)。如今，大小超过40K 字节的消息是很常见的。

　　其次，例如，与通过 RMI/IIOP 传递的数据和/或对象相比，将消息绑定到程序对象和数据操作时涉及到的XML 编码需要进行更多的计算。

　　通常最后的结果是，服务端点上的服务器可能无法处理 Web 服务网络所要求的吞吐量。其代价就是服务请求丢失。

　　在大容量(SRS 超过 1000)的系统中，吞吐量问题尤为棘手，因为它需要多方面的解决方案，其中还将不断出现许多组件。例如，业界正在开发一系列“快速 Web 服务”标准。这些标准尝试通过定义消耗更少带宽、更加快速且需要更少内存的基于二进制的消息来解决 XML 编码的问题。

　　与此同时，目前在大容量和异构消息传递系统中确保高吞吐量的最常用的办法是增加容量。

　　有几种不同的增加容量的方法。第一种是由服务提供者(即服务端点端)增加可使用的物理资源。升级服务器(例如，使用功能更强大的支持更多 CPU 或者更快的芯片的硬件)或者添加额外的服务器(例如，水平扩展或者使用服务器集群)是最流行的做法，尽管所增加的重复软件开销和高昂的管理费用通常使得这些方法的开销非常高。

　　另一种方法是使用垂直伸缩技术(比如 WebSphere? Application Server Network Deployment 引入的多单元模型)来扩展可用的应用程序服务器节点(映像)的数目。这种方法可能是有效的，但就其本身而言，它只是“提升”了Web 服务消息处理容量(平均起来，吞吐量可能增加百分之二十五到三十五)，而与现有的吞吐量级别相比，这并不是全方位的增加(许多倍以上)。这样也许满足了目前的工作负载需求，但长期的容量需求问题仍然存在。

　　那么，有没有什么方法可以在水平和垂直伸缩的基础上限制容量的增长呢?另外，目前有没有可行的技术解决方案呢?幸运的是，这两个问题的答案都是“有”。

　　高性能的面向消息的中间件 (MOM)

　　社区长期提倡合理地将消息处理任务分解为更小的相关联的系统，以保证可伸缩性。这里的最终目标是创建一个优化的计算环境，它结合了传统伸缩方法最佳的特点，即垂直或水平伸缩应用程序的能力以及在分布式方式中允许控制许多独立进程的结构方法(如XML 处理、访问业务对象和访问企业数据源)，并部署为应用程序级消息处理程序的覆盖网络。将精力集中于部分而非整体;或者说，进行分治处理。

　　目前大多数用于消息处理的 SOA 技术是在顺序消息截获模型的环境中开发的。Apache 的 Axis 或者类似的框架就是很好的例子，如图 1 所示。

　　如图 1 所示，Web 服务启用程序是提供各种“通道”以访问所需服务的抽象层。使用特定的通道对传入的XML消息在其到达时进行评估，以确定目标服务。可能有多个“筛选器”，假如它们绑定于允许对请求消息和应答消息进行截获和操作的目标服务，例如，将某种格式的消息转换为其他新的格式。这些筛选器可能作为策略强制层，消息首先在这里经过安全和服务质量(QoS) 检查，然后排队等待处理。

　　通道是连接到服务提供者的逻辑路径。它也可以用作静态“路由”开关。在 SOA 中，Web服务启用程序负责进行通道的选择，并启用服务基础结构来更好地控制筛选器应用程序，比如 Axis 的 SOAP 处理程序链。

　　尽管因为可以为不同的协议(例如，从物理实现的角度来看，使用 HTTP 和JMS)设计不同的通道，所以这种消息传递模型似乎创建了“分解的”消息，但从总体上看，所得到的体系结构本质上是整体的，因为它受到作为中心服务器或者类似配置的服务器集群的核心系统的完全支持。

　　为具有各种 XML消息传递的大型目标信息受众而设计的系统面临着功能的高度非线性使用:在不同的时刻，有些功能(如转换消息格式)，和所有其他的功能相比只被少部分的工作负载所使用。大体说来，将所有的消息处理功能整合为一个核心平台会带来不必要地“过度使用”，这将会造成不合理的工作负载预期并增加了该平台可伸缩性的挑战。

　　XML消息处理层的开发需要了解每个基础服务组件，因此这种结构方法是不合适的。而应该采用分治处理的办法，通过各个组件来解决相似的客户需求，如安全强制或转换，将这些组件划分成组，并且将这些组独立地部署到服务器网络中。

　　简单说来:将 XML 消息工作负载分段为“相似的”功能，并且根据功能段来使用处理资源，这对于产生稳定的响应时间是至关重要的，而且对于确保基于 Web 服务的系统中高吞吐量级别也是必不可少的。

　　在 J2EE 体系结构中经常使用分段工作负载技术的应用程序。例如，分段通常直接应用于表示层(Web服务器)和业务层，这些层次通常是分散的，并由不同的服务器提供支持。但是，在大容量 Web服务的环境中，需要在更细的粒度上进行分段，将消息处理分割为更易于优化的段，并因而提供更加稳定的伸缩和响应时间，即使这种技术可能需要更加复杂的服务管理机制。

　　当然，如果 XML 消息分段很简单，那么现在就会更加普遍地使用了。该技术的一个问题就是如何实现分段。更为重要的是，该体系结构调用了截获 XML消息的多层方法。我们应该如何正确地去完成这项工作呢?同时，在分段工作负载之后，可能还需要平衡工作负载分段的附加基础结构。这就带来了另一个问题，即什么是进行面向分段的负载平衡的最有效的方案?下面的讨论将会回答其中的部分问题，并提供了使用SOA 消息传递来处理这些问题的提示和技巧。

　　消息处理模式

　　在 SOA 环境中，有两种主要的用于进行 XML 消息处理的结构模式，如图 2 所示:消息拦截器网关模式，用于在 Web 服务层之前集中和协调 XML 消息相关的任务，它与 Facade 或者适配器模式相似，扮演了 Web 服务基础结构“代理”(前端)的角色，在消息抵达服务端点之前进行安全强制或中介等执行大量消息处理的任务，换句话说，截获进入服务的消息。

　　消息检查器模式，用于在 Web 服务层中执行所有的 XML 消息相关的任务，换句话说，在消息到达服务之后对其进行处理。

　　图 2. 消息处理

　　消息拦截器网关模式常用来处理 Internet 和 Intranet 环境之间的 Web 服务调用。具体说来，要使得内部 Web 服务可以在企业范围之外可用，或者要使得外部 Web 服务在内部系统中可用，就可以应用该模式。

　　网关模式最主要的优点之一是，它允许服务以未经设计的协议来提供。并且，如果同一个服务有好几种不同的实现，那么可以实现在网关中为每个传入的请求选择最合适的目标服务的机制。

　　消息检查器模式用于处理企业内的 Web 服务调用，以实现企业内部目的。这种模式对于在调用操作前进行参数验证是最有效的。应用程序特定参数的验证包括验证 XML 模式、业务数据的相关方面及其特性(如数据类型，字符串或整型，格式、长度、范围)，以及检查字符集、区域、上下文和可用值(尤其是对空值的处理)。

　　从模式实现来看，这两种模式最常用的实现技术都是使用 JSR 101 和 921 所定义的 JAX-RPC 处理程序。JAX-RPC 处理程序的使用越来越广泛，因为不论处理程序部署于 Web 服务层之内还是之外，它们都能够提供良好的 SOAP 格式消息的查询(通过 HTTP 或 JMS 协议)，包括对 SOAP Body 和 Header 的大多数元素的双向修改。然而 JAX-RPC 也有其局限性。最重要的是，它只能用于 SOAP 格式的消息，并且不能修改消息部分的类型或者消息查询的顺序，而对于大容量情况而言，这一点有时是至关重要的。

　　WebSphere Application Server V6 带来了什么?

　　请允许我重申引入的基于“分治处理”原则的结构方法的精髓。此方法是关于提供上述两种模式中的 XML 消息处理功能，并且支持在分布式的网络方式下提供这些功能，从而充分利用 SOA 独特的异构优势。

　　这种结构方法展示了“对应用程序逻辑层中的内容进行分割”的概念的演化，特别是在业务逻辑(处理作为应用程序功能的完整单元的“服务功能”)和应用程序逻辑(处理“服务表现”，即如何为服务客户提供最好的服务，而不论实际请求如何组织以及通过什么协议进行传递)之间。

　　您可能会说，“请稍等，这不正是 Enterprise Service Bus (EBS) 吗?”如果我们将 ESB 看作一种结构模式，而不是特殊的技术，那么答案是“对”。在功能方面，EBS 是服务端点的“前端”，目标是提供协议/传输映射、安全功能、消息结构的中介、SOAP 消息审核等等。但不幸的是，目前的商用 ESB 实现并没有为网络服务器容器(例如，Java 虚拟机)中的功能分段和分段分发提供简便的可配置选项。但是，如果我们不仅将 ESB 看作一种模式，而且将其看作是特殊的技术，那么和这里所描述的相似，面向分段的消息传递体系结构的实现就不同于传统的 ESB 技术。进而，SOA 的面向分段的体系结构的实现应该被看作是 ESB 之外的。因此，根据前面提出的体系结构模式，目前还没有现成的技术能够明确地实现分段。

　　然而从实际实现的角度来看，有趣的是 WebSphere Application Server Version 6 为分段和跨多个服务器容器分配消息处理提供了所需的功能。让我们来详细地探讨这一点。

　　WebSphere Application Server V6 是 WebSphere Application Server 的首个明确解决消息分段问题的发行版本。WebSphere Application Server V6 提出了一个称作“服务集成总线 (SIBus)”的新框架。SIBus 用来扮演服务请求者和服务提供者之间的特殊层(在需要时，既是逻辑的也是物理的)，启用消息截获与检查功能以支持协议切换、安全支持、路由和消息转换。

　　由于以下几点关键原因，SIBus 比 ESB 提供了更多的组成部件:

　　◆它使用了常见的 JAX-RPC 处理程序和一些新的东西，即所谓的“中介器”，在一个框架中允许对 SOAP 和非 SOAP 消息传递进行直接的应用程序控制。

　　◆它接收现有的服务目标，并动态地、无缝地将它们替换为使用所谓的“入站与出站”Web服务的新生成的端点。

　　◆它允许配置网关和代理服务来建立对传入的 Web 服务请求的单点控制，由此进行消息间的协议转换(例如，在 SOAP/HTTP 和 SOAP/JMS 服务间进行切换)。WebSphere Application Server Version 5 引入的 Web 服务网关在 WebSphere Application Server Version 6 中得到扩展，允许单个网关服务端点有多个目标服务。从而可以定义多个网关实例来划分或分段网关和代理服务，以允许简单的伸缩。

　　◆它提供了称为“Buss Object”的 EIBus 资源分组的具体构造。Buss Object，在 WebSphere Application Server Version 6 文档中又称作“Buss”，是逻辑分组构造，在它之上定义了所有的其他资源(网关/代理服务、中介器、入站/出站服务等等)。

　　中介器能做些什么?

　　EIBus 中介器是一个无状态会话的 EJB，它实现了com.ibm.websphere.sib.mediation.handler.MediationHandler 接口并且依赖于一些特定的部署描述符配置细节，以将其标识为 EIBus 中介器。除了 JAX-RPC 处理程序，还可以使用中介器，尤其当需要:

　　◆将消息从一种格式转换为另一种格式，特别是处理复杂的行业特定的格式转换时(如 ACORD 和 IFX 之间的格式转换)。

　　◆访问和增加消息内容来添加或删除数据，或者将应答(出站)XML 文档的消息部分重新打包。

　　◆通过重定向端口来选择最合适的目标服务。

　　创建中介器的过程和创建任何 EJB 类似。首先，创建一个包含将要作为中介器的 EJB 的企业应用程序。然后，创建实现com.ibm.websphere.sib.mediation.handler.MediationHandler 接口的中介处理程序类，并为这个类添加所需的逻辑。最后，更新 EJB 部署描述符，以将新创建的中介器添加至中介处理程序列表。中介处理程序列表可能包含一个或多个中介，并且控制中介的执行顺序。

　　EIBus 中介器可以关联于特定总线中的任何目标以创建中介目标。例如，可以将中介器关联于处理请求和响应消息的网关服务，或者出站服务，以协调动态端口选择/重定向到最合适的目标服务。然而，考虑到本文的背景是消息处理的“分段”，中介器是最好的实现消息检查器模式的方式。

　　WebSphere Application Server V6 的核心分段模式

　　图 3 展示了 WebSphere Application Server V6 的核心分段模式。图 3 要求遵循以下两个关键要点:

　　1. 同时使用 Web 服务网关和入站服务，允许应用同一处理程序和大量不同服务使用者之间的中介列表，以不同的绑定方式(SOAP/HTTP 或者
SOAP/JMS)从多个目标 Web 服务中请求信息;该网关使得不需要为使用者——目标服务交互的每一种类型创建独立的拦截器类型(或代理)服务。

　　2. 同时使用出站服务和带有中介列表的出站服务，允许将单个转换或配置资源应用于许多 Web 服务。

　　图 3. 分段模式

　　下面的实际场景中展示了这些方法，以及对于大容量 SOA 系统如何采用图 3 所示的基于面向分段模式的体系结构。

　　假设我们正在处理一个信用评估和授权系统，它服务于:银行、保险公司、汽车销售商、公寓租赁商、其他。由于我们要处理的是系统提供的高度机密的信息，这个场景中的消息处理的关键业务问题可以分为如下几类:

　　◆建立通用的安全处理功能，请求的验证/授权、消息源验证、或许还要启用元素级别的安全(不应该让所有的使用者获得所有的信用信息)。

　　◆提供消息记录和审核。 　

　　◆提供消息互操作能力，由于需要为多个不同的使用者服务，所以应该支持多种格式消息(例如，对银行使用 IFX，对保险公司使用ACORD，对租赁者使用专有格式等等)。

　　根据负载大小和消息表现来将消息路由到多个端点(例如，有些请求可能需要返回完整的信用报告，其他的可能只需要信用评分)。

　　该策略使用了图 3(使用 Web 服务网关)中的模式 A。如图 4 所示，该策略基于为紧耦合于中介层次的不同的绑定创建通道，而中介层次管理使用者和服务提供者之间所有可能的转换选择。这种策略带来了对服务分发机制进行优化的设计能力，以实现与不同级别的筛选(主题、内容、内容加规则)的协同工作，或者支持消息负载的不同格式(如 XML、PDF 和 JPEG)。

　　总结

　　尽管 WebSphere Application Server V6 中引入的 EIBus 主要是一个逻辑构造，但可以使用 WebSphere Application Server 集群在物理上对其进行外部化。经过物理外部化之后，单个总线可以扮演一组一个或多个互相连接的 WebSphere Application Server V6 服务器或集群的角色，作为消息引擎组与组成员(如入站/出站服务、中介器或者 JAX-RPC 处理程序)所定义的属性或者功能关联。应用程序连接到使用文中介绍的模式所实现的消息引擎之一，然后访问组属性。