企业服务总线(ESB)
思考：
1. ESB的定义是什么？它是一种产品还是一种架构模式？
2. ESB的实际用途是什么？
ESB的定义
目前企业服务总线还没有普遍接受的定义。根据供应商和来源有多种定义，包括：
一种集成架构风格，支持提供者和服务用户之间通过由各种点对点连接组成的公共通信总线进行通信。
“企业用来在其应用程序环境中集成服务的基础设施。”
“使用面向服务来支持异构环境之间的互操作性的架构模式。”
图1：ESB架构模式分为以下主要系统架构
ESB 用于服务虚拟化，通常管理大量服务，并且位于Intranet 内。
何时使用ESB？
在集成三个或更多应用程序或服务时，是否应考虑决定何时使用ESB 实现的最佳实践？连接两个应用程序时，点对点集成既简单又经济高效。如果您的公司希望从其无法控制的外部服务提供商获取服务，您也可以考虑使用ESB。 ESB 可用于监控外部提供商保证的服务级别协议。 ESB 继续提供稳定的接口，同时对消息进行必要的更改，进一步最大限度地减少服务合同调整的影响。
如果您使用多种不同的协议（例如http、SQAP、FTP）并希望将它们标准化为一种协议（例如SOAP），ESB 可以执行必要的协议转换。当需要将服务集成到单一架构中以接收、处理和生成消息时，使用ESB 也是合适的。当需要访问一组预定义的组件和适配器时，也会使用ESB，支持以标准化方式集成不同协议和遗留应用程序。当需要安全可靠地处理消息时，ESB 可以简化两个不同事务数据源之间事务消息流的实现。
当需要通过总线以许多独立消息发送大量数据时，使用ESB 可能会带来一些问题。 ESB 不应取代ETC 工具等传统数据集成。将数据从一个数据库复制到另一个数据库时，使用数据集成可能会更有效，因为此操作只会给ESB 带来不必要的负担。
如果您需要实现长期业务流程，您的ESB 应支持无状态消息流。长时间运行的业务流程是有状态的，最好使用BPEL 或BPMN 来实现。这些流程通常无法通过ESB 实现，但可以通过业务流程管理系统(BPMS) 实现。
ESB 蓝图
由于缺乏标准化，ESB 市场非常混乱。尽管许多产品都声称是ESB，但它们提供的解决方案却截然不同，并且基于不同的架构。为了更有效地评估ESB 产品，我们将分配给ESB 的各种功能组织成蓝图（图2）。
图2：企业服务总线蓝图
ESB 蓝图不包括“编排”或“流程编排”组件，因为它们被视为BPMS 类别的一部分。它们提供针对长时间运行的有状态业务流程优化的专门运行时环境，并支持BPMN 和BPEL 等语言。 ESB 应该是无状态的，并配置为尽可能高效地处理消息。
运营管理模块
图7：服务版本控制
如果ESB 通过直通直接服务版本2.0（如场景1），情况可能会更简单。同时，必须提供1.0版本的接口，同时适配现有的消息流，防止服务提供者调用1.0版本。相反，消息在发送到新服务之前会从版本1.0 转换为2.0。根据两个版本之间的差异，此转换可能相对复杂。可能需要对1.0 版本消息进行其他增强，以提供调用2.0 版本所需的所有信息。
应维护ESB 转换和接口1.0，直到没有服务使用者使用旧接口。 ESB 执行此转换而不是在服务提供商处从版本1.0 映射到2.0 的原因如下：
映射是技术问题，与业务相关问题无关
外部服务提供商不受影响。
ESB 使遗留接口的使用变得透明。
一旦所有服务客户都切换到接口2.0，就无需更换服务提供商。
总结
ESB 是一种中间件解决方案，它使用面向服务的模型来促进和支持异构环境之间的互操作性。没有任何规范可以准确定义ESB 是什么或它提供什么功能。虽然ESB主要与“监管”和“集成”等概念相关，但它也适合作为提供服务的平台以及应用服务器。 ESB 代表了称为“集成”和“应用程序服务器”的产品类别的统一。
ESB 的一个关键特性是服务虚拟化。本文中介绍的ESB 蓝图是功能的有序排列，构成评估ESB 产品的基础。
要点
企业服务总线应该被视为一种架构风格或模式，而不是一种产品。
ESB 没有定义或规范，因此也没有标准。
ESB 有助于实现系统之间的松耦合。
ESB 上的服务是无状态的。长时间运行的流程不是ESB 的一部分，但在使用BPEL 和BPMN 等语言的BPM 系统中受到支持。
“滥用”ESB 执行批处理时要小心，因为这可能会对性能产生负面影响。
参考
[REF-1] http://www.oracle.com/technetwork/cn/articles/soa/ind-soa-esb-1967705-zhs.html
原创文章，作者：小条，如若转载，请注明出处：https://www.sudun.com/ask/82747.html
