本文说明了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 所示。

共5页: 1 [2] [3] [4] [5] 下一页

频道声明：本频道的文章除部分特别声明禁止转载的专稿外，可以自由转载.但请务必注明出出处和原始作者 文章版权归本频道与文章作者所有.对于被频道转载文章的个人和网站,我们表示深深的谢意。 原始作者:佚名 录入时间:2006-11-23 信息来源:不详 投稿信箱:itqoo@126.com