用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 与 SIBus 的比较感兴趣。如果您目前不是 SIBus 用户，则后半部分对您可能并不重要。

　　我们正在编写的这批新系列文章有助于促进您使用 WebSphere ESB，并解决您也可能遇到的类似问题。本文是系列文章中的第一篇，我们将探讨 WebSphere ESB 如何提供了 SIBus 所没有的功能，它实际上如何使用了 SIBus 功能，并为本系列的其余文章的内容设好了铺垫。我们会不时地重新使用以前文章中的上下文和信息(因此，我们将重复地引用这些内容)，并且还向您大致介绍关于 WebSphere ESB 和 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 的现有功能是什么——V6.0.2 中的新增功能是什么?

　　我们假定您已经了解 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。