选择与您的业务设计最匹配的企业服务总线（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 拓扑模式，讨论它们的管理、控制、服务可视化和部署需求。IBM 红皮书“Patterns:Integrating
Enterprise Service Buses in a Service-Oriented Architecture”中介绍了各种
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 都可能使用监视器模式。
具有多个注册中心的直连
ESB
直连 ESB 模式上的变量对每个 ESB 使用一个注册中心（可能通过中央注册中心来扩展，最大扩展至集中式控制）。如果没有中央注册中心，则每个业务单元都必须定义和符合向其他部门提供的服务承诺。任何一个变量都需要仔细考虑
1) 如何在多个注册中心之间对服务元数据进行复制、同步、分割、转换等，以及 2) 当服务跨多个 ESB
交互时如何维护非功能特性（不只是安全性，还有性能、可靠性、事务性等）。
代理 ESB
与前一个模式类似，代理 ESB 模式适合具有多个区域或部门的业务。它也通过集中发布服务来使本地拥有的服务跨部门可用。然而，边远的
ESB 环节只连接到代理 ESB，而没有直接相互连接。这种分离使得基础设施能够更快速地反映业务变化。它应用于中介控制模式，其中服务规范和实现是在业务单元级别控制的，并通过一定程度的集中控制来使得跨部门的服务能够重用和互操作。
图 6. 代理 ESB 模式
在代理 ESB 中，有一个公共代理来提供桥接服务，这些服务选择性地将请求者公开给其他域中的合作伙伴，以便控制多个
ESB 安装之间的共享（每个安装管理自己的名称空间）。
代理 ESB 显示以下请求流程：请求者从其本地 ESB 请求一个服务。该请求被中转和路由到该代理，它进行第二次中转，将请求路由到与提供者关连的
ESB。此 ESB 将请求传递到服务提供者，由其完成初始请求。
代理有助于克服直连 ESB 模式的点到点连接的可维护性挑战。虽然在几个 ESB 共同参与时代理有着明显的优势，但预期的服务调用量也是很可观的。这里与直连
ESB 不同的是，跨 ESB 的代理逻辑是集中放置的（虽然每个边远的 ESB 都有自己的服务注册中心），而且中央注册中心包含有利于代理的条目。
在代理 ESB 中，各个业务单元负责在其生命周期内控制和管理自己的 ESB。为了协调数据格式和策略差别，公共代理将集中控制。为了促进灵活性和重用，常用方法（例如标准企业消息格式）允许通过代理进行互操作。
除了以下几点不同外，SOA 用户角色的任务与直连 ESB 模式中的任务相匹配：
- 集成开发人员可能另外开发对公共消息格式和策略的中介。
- 操作员的任务是相同的，但围绕服务调用代理的监视和管理中心除外。
控制的重点在于通过代理进行服务交互和中介，以及通过定义和管理公共格式来提高重用性和灵活性。中介和策略所负的责任必须明确。
中介模式与直连 ESB 类似，但较松散的耦合提高了服务可见性。
代理 ESB 模式适用于业务领域开发和管理自己的服务，但只共享其中的很少一部分，或者选择性地访问另一个业务单元的服务的情况。当服务所有权更改时——例如，一个部门独立出去——则此模式可能使受影响的服务交互的修改任务减少，因为（由于可视化）只有代理受到影响。
轮辐式 ESB
存储/分支业务设计的特征是集中管理业务流程及其底层服务，并可能在分支中有一些本地服务。分支可能部署一些可以连接到中心或独立运行的服务以启用本地操作。对于特定于分支的服务，可能有一定程度的分布式控制。具有强大中心组织的本地控制模式是最为常见的。一些集成场景可能得益于联合控制。
图 7. 轮辐式 ESB
在轮辐式 ESB 模式（它最适合于存储/分支业务设计）中，几个分支 ESB 直接连接到中心 ESB，而分支之间没有直连。整个网络的服务使用者和提供者通过其中的一个
ESB 来访问服务。这种拓扑可以联合一组在监控组织监控下适度自主的分支；它还使每个分支能够灵活地提供本地服务。分支中的特定功能可以委托给中心
ESB，但是如果具有合适和一致的本地支持能力，则分支可以进行自主。
在分支中，服务请求是向本地 ESB 提出的，它再将请求转发和路由到中心 ESB，进而到中心服务提供者上。类似地，中心
ESB 发起的服务调用可以通过反方向路由到驻留在分支的服务，但分支到分支的交互是不存在的。
当发生与中心连接中断的事件时，分支可能在本地支持有限的业务功能，一旦连接恢复，随即与其同步。
分支 ESB 基础设施是集中提供的，集中提供的还有转换、策略、安全性和服务注册中心项。然而，如果分支可以自主定义和实现其他本地服务（或者集中定义本地部署的服务的变化），则控制模型需要与此相符。对本地分支
IT 技能的投入可能很少，但是对任何本地必需服务的分析、设计、实现和操作的投入却很充足。基础设施监视和管理可以集中进行，也可以在本地进行，而且应该反映控制模型。
SOA 用户角色所受影响如下：
- 业务分析人员关注维持分支活动的中心流程及服务的结构布局，以及它们如何访问必需的数据。分支到分支的交互通过中心来中转。分支中的业务分析人员捕捉其他本地需求和变化。
- 解决方案架构师定义分支和中心站点之间的交互，包括安全性、策略、监视和管理。存在的一些问题包括：如何保护分支中的用户访问、断开连接的操作、如何进行服务级监视以及数据同步延迟。带宽不足可能会限制性能或影响移动数据以支持本地服务执行的能力。架构师也定义创建本地服务或改变中心服务的机制。
- 集成开发人员遵循分支到中心和中心到分支的互操作性规范，包括中介产生的特定监视事件。
- 解决方案管理员组装解决方案，并确保对中心 ESB 和所有分支进行同等部署。分支中的用户访问通常是集中管理的。服务变化和增加需要本地管理，它们也应该是安全的。
- 操作员监视中心和分支 ESB，以便在服务级别不符合或者分支连接中断或恢复时维护可用性；也可以在分支中进行本地操作。
该中介模式类似于单一 ESB 的模式，不同之处在于：
- 根据连接性，路由会发生变化。当一个分支断开时，正常情况下发往中心的请求被送到本地提供者，以便分支继续运行。集中中转的分支到分支交互也会受到类似的影响。
- 根据连接性和性能，会动态调整请求的分发，将其分发到多个有关方，以维护请求者可接受的服务级别。
- 为了能够对服务级别进行管理，将对消息流量进行监视，公开整个分布式拓扑的活动，特别是当它与中断的分支连接有关时。
- 聚合多个消息以创建新的、复杂事件的中介必须符合业务需求，即使在期望的事件延迟或根本没有到达时也该如此。
强加式 ESB
强加式 ESB 模式（轮辐式 ESB 的一种更极端特例）适合所有服务都集中控制的存储/分支业务设计。总部或区域办事处提供所有的
IT 服务（在分支级别很少或没有投资 IT 技能），因为不允许本地自主。与轮辐式一样，可以将服务部署到分支以支持具有单点回退功能的中心连接操作。
服务请求和完成的一般模式，以及出现操作中断并在连接恢复时进行同步的可能性，都与中心和分支模式相同。
分支 ESB 的基础设施、转换、策略、安全性和服务注册中心项都是集中创建和管理的，很少或根本没有本地自定义。任何请求更改
IT 的分支请求都被提交到中心 IT 管理，由其批准和推出。监视和基础设施管理都是集中进行的。
对用户角色的影响与中介模式是类似的，除了控制和管理完全集中进行以外，因为分支所具有的 IT 人员极少。
混合控制模式对服务注册中心的使用更复杂。例如，在直连和代理 ESB 模式中，某些服务可能由业务单元以分布式方式控制，而其他服务则集中控制，或者由一个业务单元开发的服务可能由其他业务单元（或集中）提供或运行。
图 8. 级联注册中心
级联注册中心样式（支持 ESB 拓扑）允许以分割方式进行控制，其中服务调用是在企业范围内公用的，而服务设计和构造是级联的。每个业务领域都有自己控制的注册中心。顶级服务注册中心是在企业级控制的，位于创建服务的业务领域之上。服务部署方式是将其注册到顶级注册中心，然后将一些或全部注册中心项级联到本地注册中心。
此模式应用一个企业范围的 ESB，外加每个业务领域一个 ESB。非常大的部署可能对每个业务单元增加第三层级的
ESB，以便将服务请求中转到该单元。服务（包括企业服务）可以在拓扑中的任何级别提供。请求者和提供者通过最少数量的
ESB 直接交互（不需要强制通过托管顶级注册中心的企业 ESB 来进行跨层次路由）。这种拓扑通过更改注册中心控制模型来扩展直连
ESB 模型。
它影响两个 SOA 用户角色：
- 解决方案架构师定义服务部署和注册中心管理机制（它们能够对跨多个 ESB 的请求寻找最佳路由）。
- 解决方案管理员在部署和管理服务时，根据需要将注册中心项从顶级注册中心级联到其他注册中心。
此拓扑成功与否最大程度地取决于是否存在有效的企业级控制。即使服务设计是级联的，部署都是从顶级注册中心发起的。这种拓扑形成了企业范围公共的服务定义。
这种体系结构适合部门或区域以很大程度联合的方式运行的公司——部门负责大多数业务操作，而企业级控制则促进了跨所有部门的公共业务方法。典型代表是想要跨整个企业提供公共的、共享的业务服务或管理其品牌的公司。
有时候复杂的 ESB 拓扑可以从独立的事件传输渠道获得好处。
技术事件是那些用于监视支持服务水平协议的基础设施的事件。正如 SOA 所定义的，业务事件通常包括可能触发后续逻辑（业务动作）的关键性能指标（业务度量）。简单的业务事件是一个事务的直接结果，而复杂的业务事件则是业务分析人员定义的一系列变化组合而形成的结果。
业务和技术事件对 ESB 强加了一些额外需求。不仅必须记录事务更改和承认相关事件，基础设施还必须能够处理事件流。另外，事件可能被发布到订户组，也可能被记录或审核。分析人员确定事件及其支撑中介所公开的工作负载是否最适合于单一
ESB 拓扑或独立渠道。
事件生产者通常离引发动作的站点很远；这种分离性需要在控制时特别注意。事实上，对事件创建和引发动作的分布式控制通常是与对整个控制的集中式控制结合进行的。
ESB 介于事件生产者和事件使用者之间。这可能包括跨整个 ESB 拓扑的 ESB 节点的选择性事件传播。在设计
SOA 中的事件流时，要考虑以下几点：
- 在发布-订阅交互中，一次发布的事件可能作用于多个订户；订户可以使用选择器筛选主题传入的事件。
- 可能需要使用访问控制来保护事件负载免受未经授权的访问。
- 发生的相同事件可以建模为几个简单的事件或一个复杂的聚合事件——每种方法都有不同的工作负载特征。
- 如果需要，可以通过相关器来准确识别事件流中的给定事件。
本文中列举的这些 ESB 模式并不详尽，但阐述了您在计划 ESB 拓扑和控制模式以实现业务设计时所面临的一些常见方法和注意事项。实际的组织结构和控制模型远比这些复杂，采用任何拓扑模式都需要进行一些调整。您可以组合这里列举的模式来创建具有
SOA 所承诺的灵活的体系结构，以补充您的组织的独特需要。
学习
讨论
| 
