概述服务集成总线(Service Integration Bus)强大的 Web 服务消息处理功能。这个系列分两部分，第一部分对 SIBus 进行简要介绍，着重于介绍截取和处理在 SIBus 间传输的 Web 服务消息的选项，并讨论处理它们的两种主要方法的利弊。本文详细介绍了第一种方法，Chris Whyley 展示了如何编写和部署 JAX-RPC 处理程序，使其能使用目标 Web 服务发送和接收的消息来有效工作。
服务集成总线(SIBus)是 IBM® WebSphere® Application Server V6.0 (Application Server)的重要组成部分，它允许用户利用许多消息和 Web 服务选项。SIBus 结合了 Web 服务网关的功能，建立在 WebSphere 异步消息特性的基础上并允许用户通过管理面板和命令来管理 Web 服务。现存的 Web 服务可以通过 SIBus 发布，您可以将其作为代理服务器来创建，它允许用户在 SIBus 上的新目的地发布 Web 服务，处理传入和传出的消息内容(请参阅下面的图 1)。通过对服务请求者和提供者间的链接进行去耦处理，SIBus 使用户对其所管理服务的控制更为紧密。它允许:
图 1. SIBus 的高级概览图
为什么访问消息?
由于各种原因，用户也许希望访问通过 SIBus 传递的 Web 服务消息。从最基本的层面上说，消息审查对于日志纪录是很有用的，因为系统管理员可能希望纪录通过应用程序服务器传送的特定事务--为了审核的需要，或是仅仅为了记录最常用的 Web 服务。在更高级的配置中，为了审查认证信息(当使用 WS-Security 时)，或是为了处理事务(当包含 WS-Transaction 时)，用户可能希望访问消息。
但是，消息审查只是该处理的一方面。消息处理程序最强大的功能之一是处理和扩充消息内容及消息头信息。通过使用 SIBus 中的可用选项，您可以路由消息到不同的目标、修改部件和操作名称，并且将整个消息从一种格式转换到另一种格式。另外，您可以构建处理程序链，进一步加强对于消息流和消息内容的控制。
处理消息:处理程序还是中介?
当用户使用 SIBus 处理 Web 服务消息时，有两种选择:JAX-RPC 处理程序和中介。每一种都有其独特的优缺点。在试图说明您何时使用它们，及为什么要使用它们之前，这部分先分析这两种方法(总结请参阅下面的表 1)。
JAX-RPC 处理程序
在 J2EE 团体中，JAX-RPC 处理程序作为处理传入 Web 服务消息内容的实用方法，正日益普及。它们定义完善、直接部署、使用易识别的部署描述符，并且允许用户使用细粒度(fine-grained)方法控制 SOAP 消息的大多数方面，不管此消息是 JMS 的还是 HTTP 的。您可以在 JSR 921 中找到 JAX-RPC 处理程序的最新正式规范(请参阅参考资料)。这个规范描述了您如何在客户端环境或服务器环境中实现处理程序。不管您将它们放在哪里，JAX-RPC 处理程序的特性都是一样的--它们都是独立于特定传输的，具有修改某些 SOAP 体的类型和头消息内容的能力，并能处理入站或出站请求，让用户可以在 SOAP 消息传到最终接收者之前，对其进行检查或修改。多处理程序可以在 JAX-RPC 处理程序清单中链接在一起，允许使用细粒度方法对它们的执行顺序进行控制。虽然处理程序易于使用，并且可以动态部署到 SIBus 中，但它们不能修改 SOAP 消息的每一个方面 -- 例如操作信息、部件名、顺序，都不能处理。
中介
中介是 WebSphere V6.0 中的新概念，其设计的目的是为了完成与 JAX-RPC 处理程序相似的功能。它们可以访问和修改 Application Server 中的未完成(in-flight)消息。但是，与 JAX-RPC 处理程序不一样，它们也可以检查非 SOAP 内容，例如 SDO 或 JMS 消息，在访问消息的类型上，给用户更大的自由度。中介也可以控制消息传递，为重新路由消息到可选目的地提供功能强大的选项，或者复制消息并将消息分散到多个目的地以作进一步的处理。您也可以使用中介来完成消息从一种格式到另一种格式的复杂转换。简而言之，虽然中介被限制在服务器容器中运行，但它提供了许多用于管理信息的选项。当您需要更为强大的处理功能，或者您在混合消息样式环境中操作时，中介可以作为 JAX-RPC 处理程序的一个很好的替代。本文的第二部分详细讨论了中介。
表 1. 比较 SIBus 消息处理程序的性能
