esb 和 开源esb_ESB综述第二部分：ESB用例

esb 和 开源esb

在本系列的第1部分中 ，我们从Wikipedia上的企业服务总线 （ESB）的基本定义开始。

普遍同意的观点之一似乎是，ESB与编排不同，而业务流程管理属于另一类产品。 此外，关于ESB是产品还是模式的争论也很激烈。

在本系列的第二部分中，InfoQ研究了ESB的目的-ESB的用例和需求是什么？

Sonic的Dave Chappell在上一篇文章中展开了辩论，这是本系列文章的第一部分，并提出Sonic Software实际上可能会尝试标准化一组基于UML的模式，这些模式本质上定义了ESB的参考体系结构。

Stuart Charleton （位于加拿大多伦多的BEA Systems战略咨询服务企业架构师）提供了以下使用示例：

• 消费者使用基于HTTP / S的身份验证，生产者使用WS-Security
• 消费者使用HTTP / RSS，生产者使用WebSphere MQ或JMS
• 消费者使用HTTP / REST和URI，生产者使用SOAP / WSDL
• 消费者拥有一套凭证，生产者拥有另一套凭证（钥匙串映射）。
• FTP站点是一端的“服务接口”，但是文件在另一端被分解为JMS消息
• 邮件可能需要先充实，然后再路由到目的地，因此我可以执行标注以收集更多信息
• 生产者需要与协议无关的负载平衡和/或故障转移
• 消息需要存储和转发，从而将可靠性提升到不可靠的服务上

为了扩大这些主题， Paul Fremantle （WSO2的联合创始人兼技术副总裁）补充说：

因此，ESB是启用中介的通信基础结构。 ESB应该具有哪种拓扑？ 我认为拓扑应该是灵活的：您可以将ESB作为中间的单个大型代理或大量智能端点来构建。 当然，拓扑会影响可管理性，但是只要它们是配置ESB的中央注册表/存储库，它就可以正常工作。 这样做的关键是ESB应该由策略驱动，而不是通过编写代码来驱动。

伯顿集团的安妮·托马斯·曼尼斯说：

“ ... ESB特别适合桥接到旧版应用程序，因此它是服务基础结构中的有用组件。许多ESB还支持可靠的消息传递，异步消息传递和发布/订阅交换模式。这些功能也可以非常漂亮。有用-但可能不在SOA项目的初始阶段（每个组织都有很多不需要这些功能的项目可供选择）。在SOA项目的后期，您可能还需要业务流程引擎，而大多数ESB都提供一个，但是绝对不是组织应该启动SOA计划的地方，所有这些功能都是您刚开始时就不需要的，因此ESB应该是后期购买”。

其中强调了将ESB用作遗留应用程序的桥梁。 Network Computing公司最近的一项研究使被调查的受访者使用从“完全同意到完全不同意”的量表对一系列有关ESB技术的陈述进行评分。 受访者最同意的前四项陈述是：

1. ESB必须为企业数据源（SAP，Peoplesoft，Oracle，SQL Server）提供适配器
2. ESB必须至少支持基本的业务流程管理
3. 我们的ESB实施需要开放标准（JMS，Web服务）支持
4. ESB必须与现有的企业应用程序集成（EAI）和面向消息的产品顺利集成。

这表明，诸如ERP和EAI系统之类的遗留数据源是ESB的重要接口，它们应将这些层作为基于标准的消息公开。 有趣的发现是，最终用户似乎同意ESB“必须支持”至少“基本”的业务流程管理。

最后，来自CapGemini的Steve Jones建议，实际上，ESB问题实际上是三个独立且无关的问题，即集成，构建和业务：

..一项挑战是利用当前资源并开发功能（集成），第二项挑战是构建新应用程序（Build），最后是管理这些新应用程序之间的交互（业务）。 我前一段时间在博客上写过。

集成产品的需求和驱动器与旨在在更面向标准的空间中进行交互的需求和驱动器截然不同，我不确定为什么混淆这两个域才有意义。 同样地构建新的应用程序（过程或OO语言）需要不同的技能和方法。

集成总线将通过其功能来衡量，而业务服务总线将以其简单性以及应用程序开发解决方案的灵活性来衡量。 而且，任何规模合理的企业都不会拥有适合其所有需求的解决方案。

ESB综述的第二部分希望帮助定义客户在需要ESB时要求的用例。 人们普遍认为业务流程工具与ESB不同，再加上最终用户对此功能的矛盾兴趣，表明可能将几种产品类别合并为一种。

对于此讨论，请重点关注适用于ESB的用例。

翻译自: https://www.infoq.com/articles/ESB-Roundup-Part-two/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

esb 和 开源esb