选择与您的业务设计最匹配的企业服务总线(Enterprise Service Bus,ESB)拓扑是应用面向服务的体系结构 (SOA) 原理以实现您的业务转换目标的一个重要步骤。这个步骤按照您的治理风格使您的 IT 基础设施与业务设计保持一致。拓扑描述在变形中保持不变的几何形状的属性。因此，ESB 拓扑是由相关的 ESB 环节及其属性和关系组成的。业务结构和公司的控制方法——换句话说，组织中决策权的布置——都应该要求支持 ESB 的服务可见并可管理。选择最适合业务结构和控制方法的 ESB 拓扑将使商业利益最大化。本文通过此范例分析一些多重组合的 ESB 拓扑模式，并提供指导来帮助您进行这次重要选择。
引言
本文按照如下方式组织:首先，介绍一些常见的业务设计并描述相关的控制模式。对于每种业务模型，我们都提出一个匹配的 ESB 模式并分析其特殊注意事项和折衷。最后介绍两个与复杂的 ESB 拓扑具体相关的主题:服务注册中心和监控。
业务结构模式
大型商业组织(不管其复杂性如何)的结构都可以归结为几种常见的模式，它们反映了当前许多公司广泛采用的组织原则:
单一的全球化公司——在全球范围维护单一形象的公司，它们必须用其全球业务流程向各地的客户、合作伙伴和供应商提供一致和统一的交互，但是适应本地供应商和差异化，例如法律和税务差异。希望提供一致服务(而不考虑位置)的公司可以采用此模式。虽然许多公司渴望采用这种模式，但是在大多数情况下它都是不必要和非最优的——当然也不是最差的，其原因在于它很难实现。
多区域——公司可能分区域组织，每个地区独立运作但协同支持公司的全球目标。这样的公司所服务的客户和所联系的合作伙伴及供应商都在特定的国家或地区内。全球性合约属于例外。每个区域组织都负责满足当地法律需求。这对跨国公司来说是一种常见的模式。
多种业务划分——公司可能按照产品、服务或功能划分其业务，让划分的部门通过自己的服务实现自主。业务效率通常可以通过共享核心服务(例如，客户管理)来实现。没有共享差异或者重复的核心服务可能导致不必要的成本。银行通常适用这种模式，它们分别划分成小额银行业务、信用卡和抵押贷款服务。
存储/分支网络——有分支网络的公司通常在中央或整个地区的控制下部署集成功能、流程和能力。它们因需要允许定制分支服务而有所差异。这种模式的关键特征是所有分支都链接到中央基础设施，并通过它来接受管理。许多零售商和基于分支的金融机构适用这种模型。
分级制——在分级制组织中，不同的业务划分块自主定义和执行自己的流程，可能使用一些集中服务。或者——应用相同模型，但更进一步细化——部门可能向其本地操作提供服务，本地操作反过来定义和操作自己的业务流程和服务(它们是由部门所提供的服务组成的)。
有可能出现几种结构混合在一起的情况。一种常见的混合情况是次级结构覆盖了线性管理报告(一个单一的、定义良好的组织)的矩阵式组织。例如，主要面向产品划分的公司可能也有一个区域性结构的组织，产品组织负责产品开发，但区域组织负责市场营销。矩阵式结构中的职权可能取决于要确定的问题的类型。例如，一些公司可能将复杂业务的决策委派给代表组织影响面的跨功能团队。
合并和收购通常会产生复杂的问题。通常合并的组织的业务流程和数据存储库会交叠，而且一般会使用不同的体系结构和技术。在为合并的实体选择最合适的 ESB 拓扑时，企业架构师会考虑如何使用现有的一切基础设施，然后将多个功能重叠的集成组件连在一起以支持新合并的公司的业务。
这些模式带来了许多挑战。现实中，业务流程跨越了多个业务领域;作为致力于优化业务管理的功能，组织的结构通常会随着时间的流逝而反映出一系列组织变化。要获得完整的组织客户图、推进交叉销售和向上销售，以及提升客户的忠实度和主动性，跨业务领域的交互是必需的。分析和市场营销通常会将不同领域的信息汇聚在一起。而品牌管理可能跨多个部门和区域。
当前，组织不仅必须关注自己，还必须挖掘与客户、合作伙伴和供应商的横向集成机会。将业务流程扩展到企业范围外、实现效率最优化和改进客户服务是共同的商业目标。跨公司的 ESB 拓扑是存在的，但这超出了本文的讨论范围。
归根结底，支撑技术基础设施必须设计得简单或者能够战胜这些挑战。今天的组织正在寻求通过具有 Web 服务的 SOA 来创建简单、统一且基于标准的方法，以实现跨异构系统的应用程序无缝互操作，从而极大地提高业务灵活性和控制模型和模式
SOA 成功的基础在于它的控制能力。业务灵活性取决于如何选择业务来管理和控制所提供的服务。通常，组织的不同部分都有自己的管理和控制方法。
这里，控制指的是一组服务、策略和最佳实践，它们允许 IT 组织有效地控制业务流程的定义、创建、使用、改进和退出(生命周期)以及组成它们的要素部分。拥有一套有效且明确定义的控制流程可以促进重用、方便策略的定义和执行，以及简化生命周期管理任务。
请求或提供服务的业务单元是相互独立的。源于松耦合、重用和业务可扩展性的业务灵活性只有在提供给其他业务单元的服务处于良好的应用环境时才能够获得。服务的提供者和使用者之间的关系应该显式化，从而能够根据它们在满足业务需求中所扮演的角色来管理、更新、发展和退出服务。每个业务单元都必须能够依赖于组成其流程的服务的性能、可靠性、完整性和流通性。这一点只能通过 IT 控制来保证。
采取从集中式到分布式的控制范围。
集中式控制模型具有一个代表所有业务领域的控制主体，外加理解和负责解决方案的体系结构和组件技术方面的专家。此主体负责在批准服务实现之前审查服务的添加、更改或删除计划。集中式控制要求在初始时付出更多努力才能够建立此控制主体，在进行管理时也要付出更多的精力。然而，它可以通过提高重用性和跨团队共享最佳实践来为整个企业带来利益。
分布式控制允许每个业务领域完全控制其提供的服务，虽然可能存在一个中心主体来提供公共指导方针和标准方面的建议。它使业务的各个部分能够自我控制，但是不方便重用和共享最佳实践。
在权衡利弊后，组织通常选择一种介于这两种极端模型之间的控制模型。另一个关键决策是只限对 IT 应用控制模型或者也负责其范围中的业务行为(通过服务行为)。
控制模式起源于对业务的不同部分如何交互以支持整个业务操作和向客户提供服务的研究。任何涉及多个业务领域的交互都可能需要通过其支撑技术进行控制。下面将用一些控制模式示例(显然非详尽列举)来阐述这一点。
单一控制——交互可能全部都在提供其控制的业务领域内，不可以从该领域外部访问。例如，生产设备的责任可能全部都在一个区域业务内。在本例中没有专门的控制规定。
本地控制——完全落在一个部门内的交互(请参见图 1 到图 3)可以通过发布服务接口来被其他业务领域访问。想要使用该服务的其他领域必须遵循接口规范。在接口背后，实现是由所有者单独控制的。例如，生产设备可能完成与公司其他部分交互的客户所提出的订单。
中介控制——交互发生在一个特殊的业务领域内，其角色是方便其他业务单元之间的交互。在中介领域内，业务领域请求和提供服务，而它们之间的交互是独立(或联合)控制的。例如，可能向其他业务领域集中提供金融和管理服务。
联合控制——跨多个部门交互的每个子集都是由相应的部门控制的;这些子集使用既定的接口相互协作。例如，交互可能是接受订单的部门和完成订单的工厂之间的协商。
控制模式确定谁负责监控、定义和授权更改现有的服务，以及确定在其领域中什么时候需要新的服务。
通常组织会选择单一的控制模式并始终应用该模式。然而，有时一个组织也会选择用一种模型来设计服务，而用另一种模型来执行服务。您可以看到，本文最后会对这种特殊情形进行讨论。
ESB 拓扑模式
这一部分将探讨各种 ESB 拓扑模式，讨论它们的管理、控制、服务可视化和部署需求。本文对以前的工作做进一步深入:将前面部分的每个业务组织模型映射到一个匹配的 SOA，然后应用合适的 ESB 拓扑。
