引言

IBM 对 ESB 的立场是——并且一贯是——认为 ESB 作为 SOA 中的一种体系结构模式发挥了根本性的作用。ESB 是实现成功 SOA 采用的重要入口点，并且是任何面向服务的解决方案的关键成功因素。事实上，作为对 SOA 中的 ESB 承诺的一部分，IBM 提供了实现 ESB 模式的三个战略产品。

本系列的第 1 部分描述了企业服务总线 (ESB) 体系结构模式如何适应 IBM SOA Foundation，以及 ESB与 Foundation 的其他部分如何相关。

本文介绍以下主题：

• 设计良好和实现良好的 ESB 能够为面向服务的解决方案提供的价值
• 一些在设计和实现 ESB 时要遵循的最佳实践
• IBM 对作为 SOA 组成部分 ESB 的承诺

与 SOA 相关的 ESB

IBM SOA Foundation 白皮书描述了 IBM 交付 SOA 价值的整体方法。SOA Foundation 的参考体系结构（图 1 显示了逻辑模型视图）的核心中具有 ESB。该参考体系结构的描述声明“ESB 的存在是简化服务调用任务的基础”。虽然该白皮书是在 2005 年末发布的，但是其中预述的论点却随着时间推移而通过我们在采用 SOA 的客户方面的经验得到加强。

本系列的第 1 部分表明了 ESB 是称为 SOA 的更大体系结构模式中的一个关键体系结构模式。充当中间层的 ESB 提供了服务交互中参与者之间的松散耦合连接，从而提供了 SOA 的中枢。作为中间层，ESB 执行服务虚拟化以协调服务请求程序和服务提供程序之间的差异，并提供面向方面的连接以用作诸如管理和安全性等 SOA 策略的执行点。松散耦合允许解决方案中的组成部分之间彻底分离关注事项（时间上、技术上和组织上的分离），从而同时支持业务流程和 IT 系统的灵活性和敏捷性。

通过 ESB 实现的松散耦合的部分优点（包括本系列的第 1 部分详细描述的服务虚拟化和面向方面的连接中所固有的优点）如下：

• 请求程序和提供程序不必就消息格式、消息传输甚至目标地址达成一致。
• 请求消息可由多个提供程序中的任何一个进行处理，请求程序不必显式地确定提供程序。这种路由可以基于相应的版本、服务质量或其他度量。
• 现有的请求程序无需更改即可连接到新的提供程序。
• 现有的提供程序无需更改即可对新的请求程序公开。
• 可以对请求程序做出更改而不影响提供程序，或者对提供程序做出更改而不影响请求程序。
• 解决方案的横切方面，例如安全性和管理等等，可由 ESB 进行添加、执行或加强。
• 可以实现新级别的动态行为，因为 ESB 能够为请求程序和提供程序之间的每个交互实时执行策略。

作为 SOA 入口点的 ESB

一次性全面采用 SOA 可能是一项艰巨的任务。IBM 已确定了五个 SOA 入口点，这些入口点提供了有关如何开始渐进地采用 SOA 的指导。渐进的采用方法允许企业以最适合需要的方式和步调采用 SOA。为什么我们要确定五个入口点？简单的原因在于众口难调；企业的在成熟度级别和特定需求方面各不相同，适合于一家企业的入口点可能不适合于另一家企业。这五个入口点基于已导致我们的客户成功实现了 SOA 的方法。存在两种类别的入口点：

• 以业务为中心的入口点——人员、信息和流程——允许您从一种侧重于基本企业资产的方法开始。
• 以 IT 为中心的入口点——连接性和重用——允许您为 SOA 奠定技术基础。

您也许已经从SOA Foundation 白皮书中预料到，连接性 意味着使用 ESB 来“通过更加安全、可靠和可伸缩的方法简化 IT 环境，从而在企业内外进行连接”。IBM 认为，虽然 ESB 无疑是一种以 IT 为中心的 SOA 方法，但是“它本身交付了实际业务价值，并且是将来的 SOA 计划的核心构件”。本文中的一个关键问题（将在下面进行讨论）是如何最好地使用 ESB 来形成将来的 SOA 计划的构件，以及如何通过连接性入口点获得最大的业务价值。

存在多种利用连接性入口点的方法。有时客户已经在其环境中定义了一些服务（也许是通过合作伙伴），不过是直接连接的服务；这种情况导致缺乏灵活性并增加管理成本。如上所述，在此类环境中插入 ESB 可以提供直接的松散耦合优点。此外，ESB 的存在为将来定义附加服务、创造附加重用机会、支持新的重用渠道、降低管理成本和获得更多敏捷性的工作创造了条件。

客户通常知道 ESB 的价值并渴望开始从 ESB 中实现好处，但是他们还没有在其环境中定义服务。我们看到了两种已采用过的成功技术，这两种技术帮助在这种情况下从 ESB 获得好处。客户经常混合使用重用和连接性入口点。他们确定需要作为服务来连接的功能或应用程序（请求程序或提供程序）。同时，他们将 ESB 插入该体系结构，以提供新的服务请求程序和提供程序之间所需的松散耦合。混合方法得以流行的一个重要因素是 ESB 产品的转换和变换功能。此类功能允许使用同一个 ESB 产品作为某种形式的适配器，以便以更加可重用的形式公开功能或应用程序，并提供所需的服务虚拟化和面向方面的连接。这里成功的关键是谨慎地开始，公开少量的服务并开发对应的中介，但是这些服务和中介都在为考虑中的整个最终范围而设计的体系结构之内。

有些客户插入 ESB 以建立组织中连接的所需方向，尽管起初还没有确定要连接的服务。在此情况下，ESB 是组织的总体参考体系结构的一部分；参考体系结构 提供了体系结构方向，并强制要求最终将作为解决方案一部分而创建的所有服务（请求程序和提供程序）进行松散耦合连接。ESB 是用于实现该松散耦合的首选机制。采用 ESB 实际上消除了解决方案中的直接连接不知不觉地增长的可能性。这里成功的关键是：

• 采用一个要求并演示 ESB 使用的参考体系结构。
• 考虑解决方案的整个最终范围，并支持最佳的 ESB 产品选择。
• 随着解决方案的发展而实施强有力的治理，以确保利用 ESB 来连接到引入解决方案的新服务（请求程序和提供程序）。

SOA 入口点最佳实践

存在一组 IBM 强烈建议用于任何 SOA 采用的最佳实践。这些最佳实践的最重要元素是建立一个路线图并渐进地实现该路线图，该路线图定义了实现所需业务目标的采用计划（请参见参考资料部分以获得指向文章“Service Oriented Architecture:An Introduction for Managers”的链接）。该路线图包括两个重要组成部分：

1. 战略远景，业务或 IT 的方向陈述（包括参考体系结构和治理计划），可用作决策制定、组织参与和标准采用的指导原则。
2. 一组项目计划，定义实现项目以满足当前业务驱动因素的即时和将来需要。

此类路线图允许您渐进地实现 SOA，以在每个项目步骤中回报业务价值。

您应该在执行该路线图的早期确定您业务的最佳 SOA 入口点。您应该基于从您的总体战略远景和当前 SOA 成熟度级别得出的要求来选择该入口点。该入口点可能是也可能不是连接性入口点；它可能是上述入口点的混合。但是，连接性入口点是最普遍的入口点，因为有如此多的客户具有将请求程序连接到提供程序的即时需要，并希望获得 ESB 提供的松散耦合的好处。IBM 提供了一个在线工具 Business Value Analyzer，以帮助您选择 SOA 入口点。

另一个最佳实践是建立治理框架以确保组织遵循该路线图（请参见参考资料以获得指向文章“SOA Governance and Service Lifecycle Management”的链接）。SOA 所促进的灵活性增强和跨组织性质要求组织建立治理框架，以实现主动的决策制定、准确的跟踪、改进的服务能力和更好的交流。有效的治理通过在增添价值的同时平衡风险和回报，从而帮助实现企业的业务目标。

正如上面所建议的，渐进的 SOA 采用是成功的关键。IBM 建议从试验项目开始，该试验项目：

• 处理得到充分了解、重要但不关键的业务需要。
• 实现参考体系结构的某些重要方面（也许是 ESB 和一组示例服务、提供程序、请求程序，这些方面用于演示 SOA 的使用）。
• 需要一个超出当前能力的可达范围。
• 积累 SOA 技能。
• 用作对采用 SOA 治理和新的服务生命周期管理流程所进行的试验。
• 产生将会投入生产应用并将交付投资回报的结果。

通过 SOA 实现的关注事项分离甚至允许试验项目以能够积累专业经验和验证业务价值但不中断主要操作的方式引入 SOA。

SOA 连接性入口点最佳实践

除了 SOA 最佳实践以外，还存在其他更特定于 ESB 的最佳实践：

• 仅当 ESB 在您的路线图中有意义时才采用 ESB。例如，如果 SOA 入口点以业务为中心，您可以推迟通过 ESB 实现的松散耦合，尽管您的参考体系结构中包括了 ESB。
• 基于您的参考体系结构和一组跨全套项目计划的实际要求来设计 ESB 并选择 ESB 产品。我们说实际 是因为您应该集中于未来几年中的需要；到您超过该时间期限时，产品和需求已经发生了改变。如果仅考虑即时需求，尤其是忽略服务请求程序和提供程序的预期需要，则会导致选择非最优 ESB 产品。您必须明确地在公司的约束内行事，例如年度资金周期和预算，但您同时还希望将短期采购和决策与考虑中的长期（三至五年）目标保持一致。
• 根据情况考虑 ESB 联合。更大型的异构企业通常作为某种自治域的联合体出现，这些自治域基于各个业务部门或者职能或治理方面。在此类环境中，某些服务可以在单个域中进行共享或重用，而其他服务可以在整个企业中进行共享或重用。在这些情况下，我们建议采用某种形式的 ESB 联合，该形式的 ESB 联合与域联合的需要相匹配。ESB 联合允许在不同的域中使用不同的 ESB 产品，并支持域需求与产品功能之间的最佳匹配。路线图和参考体系结构应该为任何给定域的产品选择提供指导原则甚至选项，以确保实现企业范围的优化。我们进一步建议使用联合服务注册中心和存储库，为企业范围的管理和可重用服务的治理提供帮助。

您是否需要 ESB 来成功采用 SOA？

前面几个部分说明了从 ESB 开始成功的 SOA 之旅。另外四个入口点不需要 ESB 即可开始该旅程。然而 IBM 认为，无论其入口点是什么，绝大多数成熟的面向服务的解决方案都将包括 ESB，以最大化 SOA 中所需的敏捷性和灵活性。因此，虽然初始项目可以不包括 ESB，但是在您的长期业务和 IT 路线图中，ESB 应该是参考体系结构的一部分，以实现成功的 SOA。如果没有 ESB 提供的敏捷性和灵活性，您会发现在面临不可避免的变更时，管理解决方案将变得非常困难，并且开销很大。

这是否意味着在准备好包括 ESB 在内的所有体系结构组件之前，您还没有拥有真正的 SOA 呢？此问题没有正确或错误的答案，并且可能存在许多选项。在某种程度上，此问题并不重要——重要的是在实现新的 SOA 项目以及解决方案根据您的路线图逐渐变得成熟时，您要渐进地向业务交互越来越多的价值。

我们的客户好像同意这个观点。几乎我们的所有采用 SOA 的客户都从 ESB 开始，或最终在解决方案中使用了 ESB，并从 ESB 支持的灵活性和敏捷性中获得了重大的 IT 和业务价值。

IBM 的 ESB 产品系列

IBM 对 ESB 的重视及其对 ESB 的承诺体现在我们如何使用产品来履行对 SOA Foundation 的承诺上。IBM 推出了一个产品系列，其中包括三个实现 ESB 体系结构模式的产品：

• IBM WebSphere® Message Broker 是一个成熟的产品，此产品在多年前就已实现了该模式。
• IBM WebSphere Enterprise Service Bus 于 2005 年推出，此产品专门设计用于在侧重于标准的环境中实现该模式。
• IBM WebSphere DataPower Integration Appliance XI50 于 2006 年推出，此产品以可容易地部署和管理的工具的形式封装了该模式。

为什么要推出三个产品？同样是由于众口难调。所有三个产品都实现了 ESB 模式，但是分别强调了使它们适合于特定情况的特定功能。您将在 developerWorks 上找到许多文章和 IBM 红皮书® ，编写这些内容的目的是为了帮助在面向服务的解决方案中使用这些产品。

结束语

本文再次强调了 IBM 一如既往的信仰，即 ESB 是称为 SOA 的更大模式中的一种基本体系结构模式。您通过阅读本文了解了 ESB 如何帮助从 SOA 获得业务价值，以及 ESB 如何成为成功的 SOA 采用的重要入口点——ESB 模式是如此重要，以致于 IBM 目前在 SOA Foundation 组合中推出了三个实现该模式的战略产品。