本系列文章向您介绍如何使用 WebSphere® ESB 产品构建企业服务总线
(ESB)，解决以前的系列文章中关于使用
WebSphere Application Server V6 构建 ESB 的类似问题和场景。这些文章还将阐释两种方法之间的差异，并介绍
WebSphere ESB 如何提供比以前更好的功能和工具。
自从 2005 年 12 月 IBM WebSphere Enterprise Service Bus
(WebSphere ESB) 产品上市以来，就有人询问以下问题：它与我们在以前的系列文章中描述的解决方案的关系如何——该解决方案基于
WebSphere Application Server V6（或更准确地说，WebSphere Application
Server V6 中的服务集成总线 (SIBus) 技术）创建了 ESB。我们还收到咨询以下内容的问题：SIBus
和 WebSphere ESB 之间的关系是什么（特别是不同点是什么）？何时使用何种技术？有些人只想知道他们如何使用
WebSphere ESB 的功能来实现我们在以前文章中描述的 ESB 功能。最后，还有一些关于结合使用
WebSphere ESB 和另一 IBM 产品（即 WebSphere Process Server）的最佳实践的问题。
我们正在编写的这批新系列文章有助于促进您使用 WebSphere ESB，并解决您也可能遇到的类似问题。本文是系列文章中的第一篇，我们将探讨
WebSphere ESB 如何提供了 SIBus 所没有的功能，它实际上如何使用了 SIBus 功能，并为本系列的其余文章的内容设好了铺垫。我们会不时地重新使用以前文章中的上下文和信息（因此，我们将重复地引用这些内容），并且还向您大致介绍关于
WebSphere ESB 和 ESB 技术的补充性的信息性文章，而不是简单地重复已经使用的内容。
现在让我们开始吧。
总的来说，ESB 通过一组丰富的功能，实现对应用程序之间交互的管理和监视，从而提供了在企业内部和企业之间连接新的和现有软件应用程序的功能。ESB
支持服务可视化，从而在服务请求程序和服务提供程序之间提供了多方面的分离。在 developerWorks
上的其他文章中，可以找到 ESB 体系结构模式及其组件的全面讨论（请参见参考资料）。
我们认为哪些 ESB 功能是比较关键的？
- 首先，ESB 能够通过以下各种方式与服务请求程序和服务提供程序交互：从持久性消息中枢（特别是 MQ）发送和接收消息，并能够通过
HTTP 和 JMS发送和接收 Web 服务请求和响应消息（支持诸如 Web Services Interoperability
(WS-I) Basic Profile 1.1 之类的标准）。我们首先重点讨论使用 SOAP 和
XML 的基于标准的消息，但支持其他消息格式（如文本和二进制文件）也非常重要。
- 其次，能够在不同消息和传输协议之间转换，如将 HTTP 上的 SOAP 转换为 JMS 上的 SOAP。
- 然后，我们希望能够使用流行的转换语言 XSLT 转换 XML 消息。
- 另一个基本功能是能够应用消息中介（如日志记录）。此外，我们还经常需要解决某些类型的基于上下文的动态路由问题。
我们需要关注的高级功能包括消息的监视、在服务注册中心中查询端点和异步请求/响应。
在以前的文章中，我们阐释并实现了上面列出的许多关键项目，并在 WebSphere Application
Server V6 中选择了 SIBus 作为基础平台。在通用业务上下文中设置了所有示例，下面将回顾这些示例。对于阅读了以前系列文章的人来说，这些新文章似乎有些相似之处，原因是我们将重新使用以前系列文章的场景和业务上下文，并向您展示如何在
WebSphere ESB 中实现这些相同的功能。
我们假定您已经了解 WebSphere ESB 的一些基础知识；并且在其他文章（请参见参考资料）中已经详细介绍了
WebSphere ESB 及其相关工具 (IBM WebSphere Integration Developer)
的基本体系结构和功能。我们不介绍相同的背景知识，而是与您共享 WebSphere ESB 中我们认为特别重要的内容。
WebSphere ESB 非常重视标准，可以对 XML 和 SOAP 提供一流的支持。我们喜欢这些标准，因为在提供支持标准的工具和运行时情况下，它们可以使开发服务请求程序和提供程序简单得多、而且速度更快。WebSphere
ESB 利用策略 SCA/SDO 编程模型，其中重点通过工具启用组件的（可视）程序集。WebSphere
ESB 的核心是中介流组件，它是特定类型的 SCA 组件。SCA/SDO 编程模型正在标准化过程中，它可以在许多不同的组件类型中重新使用。例如，WebSphere
Process Server 还支持 SCA 编程模型，并引入了许多组件类型，如业务流程和人工任务。根据相同的编程模型和关联的工具，可以使
WebSphere ESB 与 WebSphere Process Server 组件轻松集成。
此外，我们需要 SDO 的扩展——称为服务消息对象（Service Message Objects，SMO）——它使我们能够访问所需的消息上下文和内容，这是路由和其他
QoS 中介所需的。我们喜欢预先构建的中介基元——例如，我们几乎在每个项目中都使用 XSLT 中介基元。并且，当我们需要使用不支持现成的
SOAP 或 XML 的现有系统时，WebSphere Adapters 可以为我们节省许多开发时间，因为可以将它们用作能够“连接”到
WebSphere ESB 中介的另一个 SCA 组件类型。
而且，我们对在 12 月发布的 WebSphere ESB V6.0.2 的新功能和增强功能特别感兴趣。WebSphere
ESB 6.0.2 添加了一些关键功能，以便支持大量动态行为：
- 我们能够以管理员身份在中介模块上设置属性和值，以便可以在运行时对此中介进行控制。
- 在运行时， WebSphere Service Registry 和 Repository 中介基元可以查找目标服务提供程序的端点地址；另外，也可以编写自定义中介基元来查找和设置端点。（请参见参考资料）
- 管理员可以在管理控制台更改端点地址。
而且，在版本 6.0.2 中改进了通过 WebSphere MQ SCA 本机绑定连接到 WebSphere
MQ 的支持，还提供了对 JMS SCA 绑定的增强，这样使处理非 XML 数据变得更加容易。在 V6.0.2
中，还有更多选项，其中提供了一个用于管理的新中介基元，可以为 Common Event Infrastructure
(CEI) 生成事件。 IBM Tivoli® Composite Application Manager
(ITCAM) for SOA 6.1 将在今年发布，它支持监视 SCA 模块，还提供以管理员身份启用和禁用的
WebSphere ESB 中介基元。
最后一点也非常重要，对 WebSphere ESB 进行了显著的性能提升，并在 WebSphere Integration
Developer V6.0.2 中进行了可用性改进。
在以前的系列文章中，我们介绍了示例业务场景以及 ESB 提供更好解决方案所面临的挑战：我们的 ESB
场景基于称为 Posts-R-Us 的虚构运输公司，他们面临的共同业务挑战是涉及许多独立的系统，这些系统应该彼此集成。集成这些系统将使他们能够更快地适应新的和改变的业务流程，而不需人工开发新的功能或不断地开发集成逻辑。
现在，务必记住的是，业务级需求并不直接要求企业服务总线。我们假定 Posts-R-Us 决定开始构建面向服务的体系结构
(SOA)，以创建一组直接解决与业务相关问题的服务。ESB 提供了一个层次，在这一层次中，服务请求程序和服务提供程序之间的关系是间接的和分离的，这使得可以更好地分离关注点。换句话说，集成逻辑（例如，协议转换、消息格式转换等）与业务逻辑（即，服务执行的实际功能）是分离的。ESB
可以提供虚拟服务，以便能够通过基于标准的服务接口来有效地包装现有的应用程序逻辑。因而，ESB 可以架设一座桥梁，以弥合业务问题（即，提供一组灵活的可以实现所需的业务流程的服务）和现有
IT 环境（包含所有的协议、格式以及现有的遗留应用程序）之间的差距。
对于本系列文章，我们将假设使用完全相同的业务场景，并且仅将其映射为实现的不同产品，即 WebSphere
ESB。
术语“SIBus”实际上包括多个不同的部分，在将其与 WebSphere ESB 比较时，我们需要分别对它们进行分析。在
WebSphere Application Server 中，SIBus 的核心是消息传递基础结构和缺省的
JMS 提供程序，因此，在此基础上构建的每个 WebSphere 产品都使用此缺省的 JMS 提供程序进行消息传递。而且，所谓的中介处理程序可以动态访问消息。最后，称为
MQLink 的功能支持 SIBus 和独立 WebSphere MQ 环境之间的集成。考虑到这些后，让我们看一看
WebSphere ESB 和 SIBus 之间的关系，特别是了解二者关联的以下五种方式：
- 为构建 ESB，WebSphere
ESB 和 WebSphere Integration Developer 提供了 SIBus 没有的功能
- WebSphere
Application Server/SIBus 将 JMS 提供程序用作 WebSphere ESB
JMS 绑定的缺省 JMS 提供程序
- SIBus 中介和
WebSphere ESB 中介之间的差异
- 将 SIBus MQLink
与 WebSphere ESB 一起使用
- SIBus 和 WebSphere
ESB 基础结构的共存和集成
为构建 ESB，WebSphere
ESB 和 WebSphere Integration Developer 提供了 SIBus 没有的功能
不过，在仅使用 SIBus 功能时，配置过程可能非常麻烦，需要多个手动步骤。而且，必须手动编码中介（在
SIBus 中，称为中介处理程序），而没有任何工具支持。
由于 WebSphere ESB 是通过策略 SCA/SDO 编程模型构建的，所以在 WebSphere
Integration Developer 中有强大的工具，通过可视化的导入和导出接口结构简化了中介流组件的开发。而且，顾名思义，中介流组件本身包含一个流，该流描述当消息通过
ESB 时如何对其进行处理。WebSphere Integration Developer 提供另一个可视化工具来组装中介流，从而让您可以拖放预先构建的中介基元，该中介基元构成消息流经的中介流组件。例如，一种中介基元支持通过
XSLT 样式表进行消息转换，另一种中介基元支持通过流的消息的自动记录。描述此工作方式的一篇好文章是
WebSphere Enterprise Service Bus 与 WebSphere Integration
Developer 入门。您还可以构建自已的自定义中介基元，使之包含工具中不再提供的特定逻辑。为
WebSphere Enterprise Service Bus 开发自定义中介 是一篇描述如何构建自定义中介基元的文章。
SIBus 中介处理程序框架根本不支持对流进行可视化建模的概念。可以回忆一下以前的系列文章，必须将处理程序创建为实现特定接口的普通
Java™ 类。没有提供任何可视化工具，并且不存在任何预定义的处理程序。
此外，对于同步调用，WebSphere ESB 支持不同的交互模式与请求和响应消息的自动关联，而对于为异步调用组件，则支持
SCA API，从而在请求和响应之间提供回调机制和关联。开发人员必须使用 SIBus 来自定义代码异步支持和关联逻辑。
因此，WebSphere ESB 和 WebSphere Integration Developer
的组合创建了功能强大的开发和运行时工具集，大大加快了 ESB 的开发速度，这是 SIBus 无法比拟的。
WebSphere
Application Server/SIBus 将 JMS 提供程序用作 WebSphere ESB
JMS 绑定的缺省 JMS 提供程序
WebSphere ESB 就像 WebSphere 家族中的许多其他产品一样，是基于 WebSphere
Application Server 构建的。它使用 J2EE™ 运行时以及应用服务器支持的其他功能；例如，支持集群的功能和工作负载管理。SIBus
是 WebSphere Application Server 的功能特征；因此，每个 WebSphere
ESB 安装也自动含有 SIBus 功能。
与 SCA 组件（例如 WebSphere ESB 中介流组件）通信的一种方式是使用 JMS 绑定。客户机或请求程序通过
JMS 将消息发送到 ESB；而对于请求/响应操作，则通过独立 JMS 队列接收响应消息。WebSphere
ESB 利用缺省 JMS 提供程序来提供 JMS 实现。因此可以这样说，从 JMS 角度而言，WebSphere
ESB 位于 SIBus JMS 提供程序之上并使用该提供程序，或者说 WebSphere ESB 和
SIBus 是互补的。注意，当为 WebSphere ESB 创建 JMS 绑定时，WebSphere
Integration Developer 工具会自动生成所需的 SIBus 构件（如目的地等），从而使用对用户透明的
JMS 提供程序。
SIBus 中介和
WebSphere ESB 中介之间的差异
如上所述，WebSphere ESB 和 SIBus 都提供中介功能。WebSphere ESB 可让您开发自已的自定义中介基元，而
SIBus 则利用中介处理程序框架。但是一定要注意，二者的中介框架实现、API、包装和管理模型是不同的。
几乎在任何情况下中介都需要访问消息本身，以便操作、记录和转换消息，不管在任何特定用例下，都是如此。SIBus
和 WebSphere ESB 将 SDO 用作通过总线的消息流的表现机制。对于 WebSphere ESB，使用称为
Service Message Objects (SMO) 的 SDO 扩展。因此，尽管消息的准确表示形式在两种技术中不同，但是访问消息内容所需的代码类似。
在大多数情况下，从 SIBus 迁移到 WebSphere ESB（反之亦然）需手动执行——迁移的复杂性取决于中介代码执行的内容。在本系列的后续文章中，我们将向您介绍如何替换我们开发的现有中介处理程序，以便在使用
WebSphere ESB 时可以通过 SIBus 与自定义中介基元一起使用，我们还将讨论迁移时的注意事项。
另外，SIBus 还提供非预构建的中介处理程序，而 WebSphere ESB 附带大量的中介基元，因此您可能根本不需要编写自定义代码。
将 SIBus MQLink
与 WebSphere ESB 一起使用
由于 SIBus 充当 WebSphere Application Server 的 JMS 提供程序，因此每当需要
JMS 功能时，WebSphere ESB 可以重新使用它，您可以利用 SIBus 提供的其他功能轻松地将
WebSphere ESB 与现有 WebSphere MQ 环境集成。
SIBus 通过其 MQLink 功能提供到 WebSphere MQ 的连接，该连接使 SIBus
实例能够像另一个队列管理器一样与 MQ 队列管理器通信。这可以将消息从 MQ 客户机发送到 MQ 队列，然后将消息自动转发到
SIBus 中的目的地。在此基础上，通过 JMS 导出将消息发送到中介流组件。类似地，还可以从 WebSphere
ESB/SIBus 中将消息发送到实际上是 MQ 队列的目的地。
不过，使用此方法将 WebSphere ESB 与 WebSphere MQ 集成存在一些缺陷。开发人员必须熟悉和使用配置的
SIBus 资源，而且在 MQLink 支持的故障转移的配置上还存在一些限制。
在 WebSphere ESB V6.0.2 中，添加了新的 MQ SCA 本地绑定，我们建议在 MQLink
上使用该绑定。
SIBus 和 WebSphere
ESB 基础结构的共存和集成
最后一点是 WebSphere ESB 和 SIBus 可以共存，并且可以集成独立的实例。如果您已经具有现有
SIBus 环境，那么您可以通过消息引擎的配置将一个或多个 WebSphere ESB 实例迁移到该环境，并且通过外部总线链接跨计算单元进行迁移。SIBus
和 WebSphere ESB 可以通过多个协议（例如通过 SOAP/HTTP 或 JMS）交换消息。您可以在不影响现有
SIBus 中介的情况下，通过中介流组件开始运行消息，并且每当您做好准备时，就可以将中介从 SIBus
迁移到 WebSphere ESB。
对于此系列文章中的后续文章，我们将继续使用以前的技术场景。在这些文章中，我们将：
- 详细讨论如何执行一些高级的 Web 服务功能；例如，如何操作 SOAP 标头。
- 回顾我们以前使用的协议转换示例，其中基于 JMS 的客户机可以通过总线与 SOAP/HTTP Web
服务通信。
- 通过一个示例讨论如何将 WebSphere ESB 和 WebSphere Process Server
一起使用。
- 通过使用一个现有中介处理程序的示例，讨论如何将 SIBus 中介处理程序迁移到 WebSphere
ESB 中介基元。我们将使用以前系列文章中的 JMS 消息传递示例和日志中介，但这次是在 WebSphere
ESB 上实现并部署它。
| 
