使用WebSphereESB构建企业服务总线.doc

IBM WebSphere 开发者技术期刊: 使用 WebSphere ESB 构建企业服务总线，第 1 部分WebSphere ESB 用法简介，或 WebSphere ESB 与 SIBus 的比较文档选项打印本页窗体顶端将此页作为电子邮件发送未显示需要 JavaScript 的文档选项窗体底端级别： 中级Rachel Reinitz (), 高级 IT 咨询专家, IBMAndre Tost, 高级技术人员, IBM2007 年 1 月 15 日本系列文章向您介绍如何使用 WebSphere ESB 产品构建企业服务总线 (ESB)，解决以前的系列文章中关于使用 WebSphere Application Server V6 构建 ESB 的类似问题和场景。这些文章还将阐释两种方法之间的差异，并介绍 WebSphere ESB 如何提供比以前更好的功能和工具。摘自 IBM WebSphere 开发者技术期刊。引言自从 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。回页首WebSphere ESB 与 SIBus 的比较什么是 SIBus？SIBus 是基础 WebSphere Application Server 中服务集成功能的非正式名称（也是 Websphere Application Server 管理控制台上的链接）。了解 SIBus 的主要功能很有帮助，因为只有一种功能将来可用作由 WebSphere ESB 构建的 ESB 的一部分： SIBus 的核心是一个用 Java 编写的完整 JMS V1.1 提供程序实现，支持使用 JDBC 兼容数据库的持久性消息。在 WebSphere Application Server 中，SIBus 中的缺省 JMS 提供程序提供健壮的、基于 J2EE 的消息引擎，主要提供企业级服务质量，如可靠性和高可用性。WebSphere ESB 使用此缺省 WebSphere JMS 提供程序来支持 JMS 连接性。 称为 MQLink 的 SIBus 功能提供指向 MQ 队列管理器的“链接”。对于 MQ，SIBus 相当于另一个队列管理器，对于 SIBus，队列管理器相当于另一个 SIBus。此功能经常与 WebSphere ESB 6.0.1 一起使用，以链接 MQ 系统不过，在 WebSphere ESB 6.0.2 中，本机 SCA MQ 绑定是连接 MQ 的首选方法。 SIBus 支持 Web 服务。WebSphere ESB 将 SCA 绑定用于不使用 SIBus 的 Web 服务。 SIBus 具有使用服务数据对象的中介编程模型；不过，它与 WebSphere ESB 中的 SCA 和 SMO 编程模型不同。总之，在后续文章中，我们重点将 SIBus 用作 WebSphere Application Server 的缺省 JMS 提供程序，将不使用 SIBus 的其他功能。术语“SIBus”实际上包括多个不同的部分，在将其与 WebSphere ESB 比较时，我们需要分别对它们进行分析。在 WebSphere Application Server 中，SIBus 的核心是消息传递基础结构和缺省的 JMS 提供程序，因此，在此基础上构建的每个 WebSphere 产品都使用此缺省的 JMS 提供程序进行消息传递。而且，所谓的中介处理程序可以动态访问消息。最后，称为 MQLink 的功能支持 SIBus 和独立 WebSphere MQ 环境之间的集成。考虑到这些后，让我们看一看 WebSphere ESB 和 SIBus 之间的关系，特别是了解二者关联的以下五种方式：1. 为构建 ESB，WebSphere ESB 和 WebSphere Integration Developer 提供了 SIBus 没有的功能 2. WebSphere Application Server/SIBus 将 JMS 提供程序用作 WebSphere ESB JMS 绑定的缺省 JMS 提供程序 3. SIBus 中介和 WebSphere ESB 中介之间的差异 4. 将 SIBus MQLink 与 WebSphere ESB 一起使用 5. 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 MQLi