登录
采取从集中式到分布式的控制范围。
集中式控制模型具有一个代表所有业务领域的控制主体，外加理解和负责解决方案的体系结构和组件技术方面的专家。此主体负责在批准服务实现之前审查服务的添加、更改或删除计划。集中式控制要求在初始时付出更多努力才能够建立此控制主体，在进行管理时也要付出更多的精力。然而，它可以通过提高重用性和跨团队共享最佳实践来为整个企业带来利益。
分布式控制允许每个业务领域完全控制其提供的服务，虽然可能存在一个中心主体来提供公共指导方针和标准方面的建议。它使业务的各个部分能够自我控制，但是不方便重用和共享最佳实践。
在权衡利弊后，组织通常选择一种介于这两种极端模型之间的控制模型。另一个关键决策是只限对 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 派生出来的新模式来进一步阐释前面的工作。
| 第1页： 第1页 |
