选择与您的业务设计最匹配的企业服务总线(Enterprise Service Bus,ESB)拓扑是应用面向服务的体系结构 (SOA) 原理以实现您的业务转换目标的一个重要步骤。这个步骤按照您的治理风格使您的 IT 基础设施与业务设计保持一致。拓扑描述在变形中保持不变的几何形状的属性。因此，ESB 拓扑是由相关的 ESB 环节及其属性和关系组成的。业务结构和公司的控制方法——换句话说，组织中决策权的布置——都应该要求支持 ESB 的服务可见并可管理。选择最适合业务结构和控制方法的 ESB 拓扑将使商业利益最大化。本文通过此范例分析一些多重组合的 ESB 拓扑模式，并提供指导来帮助您进行这次重要选择。

　　引言

　　本文按照如下方式组织:首先，介绍一些常见的业务设计并描述相关的控制模式。对于每种业务模型，我们都提出一个匹配的 ESB 模式并分析其特殊注意事项和折衷。最后介绍两个与复杂的 ESB 拓扑具体相关的主题:服务注册中心和监控。

　　业务结构模式

　　大型商业组织(不管其复杂性如何)的结构都可以归结为几种常见的模式，它们反映了当前许多公司广泛采用的组织原则:

　　单一的全球化公司——在全球范围维护单一形象的公司，它们必须用其全球业务流程向各地的客户、合作伙伴和供应商提供一致和统一的交互，但是适应本地供应商和差异化，例如法律和税务差异。希望提供一致服务(而不考虑位置)的公司可以采用此模式。虽然许多公司渴望采用这种模式，但是在大多数情况下它都是不必要和非最优的——当然也不是最差的，其原因在于它很难实现。

　　多区域——公司可能分区域组织，每个地区独立运作但协同支持公司的全球目标。这样的公司所服务的客户和所联系的合作伙伴及供应商都在特定的国家或地区内。全球性合约属于例外。每个区域组织都负责满足当地法律需求。这对跨国公司来说是一种常见的模式。

　　多种业务划分——公司可能按照产品、服务或功能划分其业务，让划分的部门通过自己的服务实现自主。业务效率通常可以通过共享核心服务(例如，客户管理)来实现。没有共享差异或者重复的核心服务可能导致不必要的成本。银行通常适用这种模式，它们分别划分成小额银行业务、信用卡和抵押贷款服务。

　　存储/分支网络——有分支网络的公司通常在中央或整个地区的控制下部署集成功能、流程和能力。它们因需要允许定制分支服务而有所差异。这种模式的关键特征是所有分支都链接到中央基础设施，并通过它来接受管理。许多零售商和基于分支的金融机构适用这种模型。

　　分级制——在分级制组织中，不同的业务划分块自主定义和执行自己的流程，可能使用一些集中服务。或者——应用相同模型，但更进一步细化——部门可能向其本地操作提供服务，本地操作反过来定义和操作自己的业务流程和服务(它们是由部门所提供的服务组成的)。

　　有可能出现几种结构混合在一起的情况。一种常见的混合情况是次级结构覆盖了线性管理报告(一个单一的、定义良好的组织)的矩阵式组织。例如，主要面向产品划分的公司可能也有一个区域性结构的组织，产品组织负责产品开发，但区域组织负责市场营销。矩阵式结构中的职权可能取决于要确定的问题的类型。例如，一些公司可能将复杂业务的决策委派给代表组织影响面的跨功能团队。

　　合并和收购通常会产生复杂的问题。通常合并的组织的业务流程和数据存储库会交叠，而且一般会使用不同的体系结构和技术。在为合并的实体选择最合适的 ESB 拓扑时，企业架构师会考虑如何使用现有的一切基础设施，然后将多个功能重叠的集成组件连在一起以支持新合并的公司的业务。

　　这些模式带来了许多挑战。现实中，业务流程跨越了多个业务领域;作为致力于优化业务管理的功能，组织的结构通常会随着时间的流逝而反映出一系列组织变化。要获得完整的组织客户图、推进交叉销售和向上销售，以及提升客户的忠实度和主动性，跨业务领域的交互是必需的。分析和市场营销通常会将不同领域的信息汇聚在一起。而品牌管理可能跨多个部门和区域。

　　当前，组织不仅必须关注自己，还必须挖掘与客户、合作伙伴和供应商的横向集成机会。将业务流程扩展到企业范围外、实现效率最优化和改进客户服务是共同的商业目标。跨公司的 ESB 拓扑是存在的，但这超出了本文的讨论范围。

　　归根结底，支撑技术基础设施必须设计得简单或者能够战胜这些挑战。今天的组织正在寻求通过具有 Web 服务的 SOA 来创建简单、统一且基于标准的方法，以实现跨异构系统的应用程序无缝互操作，从而极大地提高业务灵活性和控制模型和模式

　　SOA 成功的基础在于它的控制能力。业务灵活性取决于如何选择业务来管理和控制所提供的服务。通常，组织的不同部分都有自己的管理和控制方法。

　　这里，控制指的是一组服务、策略和最佳实践，它们允许 IT 组织有效地控制业务流程的定义、创建、使用、改进和退出(生命周期)以及组成它们的要素部分。拥有一套有效且明确定义的控制流程可以促进重用、方便策略的定义和执行，以及简化生命周期管理任务。

　　请求或提供服务的业务单元是相互独立的。源于松耦合、重用和业务可扩展性的业务灵活性只有在提供给其他业务单元的服务处于良好的应用环境时才能够获得。服务的提供者和使用者之间的关系应该显式化，从而能够根据它们在满足业务需求中所扮演的角色来管理、更新、发展和退出服务。每个业务单元都必须能够依赖于组成其流程的服务的性能、可靠性、完整性和流通性。这一点只能通过 IT 控制来保证。

　　采取从集中式到分布式的控制范围。

　　集中式控制模型具有一个代表所有业务领域的控制主体，外加理解和负责解决方案的体系结构和组件技术方面的专家。此主体负责在批准服务实现之前审查服务的添加、更改或删除计划。集中式控制要求在初始时付出更多努力才能够建立此控制主体，在进行管理时也要付出更多的精力。然而，它可以通过提高重用性和跨团队共享最佳实践来为整个企业带来利益。

　　分布式控制允许每个业务领域完全控制其提供的服务，虽然可能存在一个中心主体来提供公共指导方针和标准方面的建议。它使业务的各个部分能够自我控制，但是不方便重用和共享最佳实践。

　　在权衡利弊后，组织通常选择一种介于这两种极端模型之间的控制模型。另一个关键决策是只限对 IT 应用控制模型或者也负责其范围中的业务行为(通过服务行为)。

　　控制模式起源于对业务的不同部分如何交互以支持整个业务操作和向客户提供服务的研究。任何涉及多个业务领域的交互都可能需要通过其支撑技术进行控制。下面将用一些控制模式示例(显然非详尽列举)来阐述这一点。

　　单一控制——交互可能全部都在提供其控制的业务领域内，不可以从该领域外部访问。例如，生产设备的责任可能全部都在一个区域业务内。在本例中没有专门的控制规定。

　　本地控制——完全落在一个部门内的交互(请参见图 1 到图 3)可以通过发布服务接口来被其他业务领域访问。想要使用该服务的其他领域必须遵循接口规范。在接口背后，实现是由所有者单独控制的。例如，生产设备可能完成与公司其他部分交互的客户所提出的订单。

　　图 1. 本地控制模式

　　中介控制——交互发生在一个特殊的业务领域内，其角色是方便其他业务单元之间的交互。在中介领域内，业务领域请求和提供服务，而它们之间的交互是独立(或联合)控制的。例如，可能向其他业务领域集中提供金融和管理服务。

　　图 2. 中介控制模式

　　联合控制——跨多个部门交互的每个子集都是由相应的部门控制的;这些子集使用既定的接口相互协作。例如，交互可能是接受订单的部门和完成订单的工厂之间的协商。

　　图 3. 联合控制模式

　　控制模式确定谁负责监控、定义和授权更改现有的服务，以及确定在其领域中什么时候需要新的服务。

　　通常组织会选择单一的控制模式并始终应用该模式。然而，有时一个组织也会选择用一种模型来设计服务，而用另一种模型来执行服务。您可以看到，本文最后会对这种特殊情形进行讨论。

　　ESB 拓扑模式

　　这一部分将探讨各种 ESB 拓扑模式，讨论它们的管理、控制、服务可视化和部署需求。本文对以前的工作做进一步深入:将前面部分的每个业务组织模型映射到一个匹配的 SOA，然后应用合适的 ESB 拓扑。

　　图 4. 业务设计、SOA 和匹配的 ESB 拓扑

　　我们还讨论了每个 ESB 拓扑对中介模式和用户角色的影响 [请参阅“用于实现 Web 服务的 SOA 编程模型，第 10 部分:SOA 用户角色”(developerWorks，2006 年 2 月)]。对于单一的 ESB，该系列的第 4 部分“IBM 企业服务总线介绍”已做了描述。现有的资料提出了单一 ESB、单一名称空间拓扑，在这种拓扑中，每个提供者都对跨异构的、集中管理的环境的每个请求者可见(请参阅参考资料部分列出的文章)。本文通过分析从多重组合的 ESB 派生出来的新模式来进一步阐释前面的工作。

　　单一逻辑 ESB

　　单一的国际化公司通常选择一种匹配的 SOA 模式，在这种模式中，服务是由整个组织指定和拥有的。即使它们允许存在多个物理分布的服务实例，但是每个实例都只有一个抽象定义(由组织统一管理)和一个公共实现。控制模型是集中式的。

　　相应的 ESB 模型是单一逻辑 ESB，它共享单一 ESB 的许多特征:单一名称空间、所有提供者对所有请求者可见。然而，使服务在所有区域可用——而不管请求者身在何处——是很有挑战性的:

　　从性能角度来看，可能要求有多个按区域分布的服务实例，以便请求者可以与本地服务相交互。然而关联的数据必须是一致的，这意味着需要进行数据同步。

　　从高可用性角度来看，可能要求补偿本地服务的损失，方法是将请求路由到其他地方的等效服务上;因此，服务提供者(不管是其逻辑还是数据)必须能够进行故障转移和故障反馈。此外，当首选 ESB 不可用时，需要有一种机制来将请求传递到备选 ESB 上。

　　物理 ESB 实例必须透明地将服务请求路由到合适的提供者上。

　　使这些服务提供者实例保持一致带来了很大的复杂性。在查找合适的提供者时，服务注册中心必须考虑请求者的位置和所有位置上的服务的可用性。支撑基础设施可以(在全球策略和控制下)本地管理，但服务本身必须集中管理以便在全球范围内保持一致。

　　ESB 和 SOA 用户角色有以下影响方式:

　　业务分析人员可以识别跨区域的需求和流程，因为全球统一是这种方法的特点。清晰的服务质量规范(根据业务远景确定的)有助于架构师评估服务的提供位置和方式。

　　解决方案架构师最艰巨的任务是提供支持 ESB 拓扑的组件。影响数据管理和数据完整性的决策都应该出现在用例中。设计必须反映服务质量需求和非功能需求，而且不限制服务请求者的位置。

　　解决方案管理员必须以某种方式组装和部署解决方案，在这种方式下，每个物理 ESB 都提供相同的功能，而当一个物理 ESB 发生故障时，它支持故障转移。安全性必须保持一致。

　　操作员需要能够监视要管理的服务请求的物理路由和相关行为并满足期望的服务级别。

　　中介模式与单一 ESB 中的这些要求类似，唯一的不同之处在于:

　　用于充实中介的数据必须跨物理 ESB 实例同步以确保执行时一致，从而保证数据的完整性。

　　运行时路由应该反映请求者和提供者之间的地理亲缘关系 。当本地服务不可用时，将请求透明地重路由到其他地方的服务提供者。

　　只有专心致志地推行统一的全球形象的组织才有可能追寻这种模式，它需要全球范围的一致性和集中式控制。实现此模式所需要的技术并非都轻而易举地保留到今天。清楚地理解业务需求、分析用例和对数据进行广泛考虑是定义和指定此 SOA 如何才能满足业务需求的先决条件。

　　具有单一注册中心的直连 ESB

　　在“多区域”和“多种业务划分”模型中，服务通常归各个业务单元所有。分布式控制使得业务的所有领域能够联合起来定义服务规范和实现;一定程度的集中式控制可以促进跨业务领域的服务重用和互操作。本地控制和联合控制模式都可能用于拥有和控制集成场景。

　　直连 ESB(本部分所讨论的)和代理 ESB 模式(下一部分将要讨论的)适合这些业务模型。

　　图 5. 具有单一注册中心的直连 ESB

　　直连 ESB 使得几个互连的 ESB 中的所有服务通过公共服务注册中心(它反映每个服务对其中一个 ESB 的亲缘关系)可见。请求者调用其本地 ESB，该 ESB 参考注册中心，然后将请求传递到标识的服务提供者的 ESB 中。不管拓扑中 ESB 的数目有多少，每次交互都涉及两个直接连接的 ESB。

　　这种模式适合具有多个部门或区域的组织。通过在公共注册中心中列出部门提供和管理的服务，就可以在整个企业范围内对其进行访问。每个部门保护自己的 ESB 并控制对其服务的访问。为了利用另一个部门中的服务，在本地 ESB 定义的中介允许请求者访问提供者的 ESB 和服务本身。可以定义策略来控制服务可能的使用方式。为了防止误用，部署基础设施和注册中心也都需要访问控制。

　　这种模式通过以下方式来支持服务可视化:为了调用另一个业务单元的服务，在本地 ESB 上定义了一个服务存根来封装注册中心查找。因此，通过对这两个 ESB 中的访问权限和策略进行适当管理，一个部门中的请求者要调用另一个部门提供的服务，可以通过直接连接这两个部门的 ESB。

　　我们来查看一下此模式如何影响 ESB 和 SOA 用户角色:

　　业务分析人员重点关注如何将 ESB 基础设施边界映射到业务划分块或区域，以及如何管理分块执行的跨界业务流程。计算关键性能指标或监视端到端流程可能需要来自多个部门的度量。

　　解决方案架构师考虑如何最大化地重用不同部门中的 IT 资产。要能够跨部门共享服务，需要定义 ESB(包括策略和安全性)之间的交互，也需要映射服务和数据结构。

　　集成开发人员在将服务端点集成到解决方案中时，遵循解决方案架构师的规范有助于它们被其他部门使用。

　　解决方案管理员组装解决方案、将它们部署到合适的 ESB、将服务定义导入公共注册中心，并从企业远景的角度来应用合适的安全策略和访问控制。

　　操作员主要跨部门监视和管理服务的使用。跨多个 ESB 的业务流程和事务需要聚合基础设施服务。

　　中介模式与单一 ESB 之间的区别如下:

　　充实和自定义中介可能需要访问其他场所的数据(或其本地副本)，例如服务提供者的业务单元。

　　处理请求所涉及的所有 ESB 都可能使用监视器模式。