esb集成总线_为您的集成需求选择合适的ESB

esb集成总线

公司内部以及不同公司之间的不同应用程序需要相互通信。 企业服务总线（ESB）已建立为支持应用程序集成的工具。 但是什么是ESB？ 什么时候使用集成套件更好？ 哪种产品最适合下一个项目？ 本文解释了为什么没有灵丹妙药，为什么ESB也可能是错误的选择。 选择正确的产品对于项目成功至关重要。

术语“企业服务总线”的定义

来自不同供应商的许多产品都使用名称“ Enterprise Service Bus”。 不幸的是，该术语没有标准定义。 因此，产品具有许多不同的功能。 在使用ESB之前，应始终对其进行明确定义。 在下文中，ESB被定义为一种软件产品，可帮助开发人员进行应用程序集成，因此提供了实现路由，转换和其他集成功能的必要基础结构。 在集成复杂性的路径上，ESB通常介于框架和套件之间，作为应用程序集成的替代方法，如下图所示：

图1：应用程序集成的替代方案
在定义了ESB一词之后，下一部分将说明何时应考虑使用ESB，以及何时最好使用集成框架或集成套件。

整合框架

框架有助于实现企业集成模式（EIP，http：//www.eaipatterns.com），例如拆分器或基于内容的路由器，以便以标准化方式集成应用程序。 使用标准API集成产品显着降低了实现工作，并且其他开发人员更容易理解源代码。 框架非常适合于将具有不同协议和技术的不同应用程序集成在一起，并且使用诸如端点，生产者，消费者和EIP之类的概念来创建集成逻辑。 甚至隐式支持的测试自动化也使用相同的概念。
框架由一组普通库组成，因此可以与任何开发环境（甚至是经典的文本编辑器）兼容。
框架的已知示例是Java环境中的Apache Camel和Spring Integration以及.NET的NServiceBus 。
使用框架，开发团队或多或少地全权负责项目的成功。 通常没有商业支持。 工具也仅部分可用，不一定适合“关键任务”部署。 因此，本文的其余部分专门针对ESB和相应的套件，它们通常是比框架更好的选择。

企业服务总线

整合套件

比较标准

注意：我们不会提供一个将所有可用产品与各种标准进行比较的矩阵。 从作者的角度来看，几乎不可能创建一个良好且有用的矩阵，因为产品提供了太多（通常是不同的）功能和概念。 此外，功能列表实际上在IT世界中每天都在变化。
因此，建议预先定义自己的需求，然后评估最适合的产品。 专有解决方案通常非常相似，而且最常用的开源竞争对手也具有相似的特征。 因此，从一开始就想一下，私有解决方案还是开源解决方案是更好的选择。
为了做出此决定，您应该使用以下条件：

• 可用性 ：安装有多复杂？ 需要多少个工具？ 开发环境直观吗？
• 可维护性 ：您如何管理产品？ 有用于监视服务的GUI吗？
• 社区 ：是否有活跃的公共论坛或邮件列表？ 有大量文章，教程，文章和视频吗？ 产品得到多家公司的支持吗？
• 企业 支持 ：提供哪些支持选项（“工作时间”，“ 24/7”热线，电子邮件与现场支持等）？ 是否可以保证所需的服务水平协议？ 是否以您的首选语言提供支持？
• 功能性 ：是否提供了所有必需的功能？
• 灵活性 ：您可以定制产品功能以满足我的需求吗？
• 可扩展性 ：是否可以扩展产品？ 产品及其接口是否基于标准？
• 连接器 ：是否提供适用于所有必需技术的适配器？ 是否有适用于SAP或Salesforce等B2B产品的适配器？ 如何轻松构建自己的适配器？
• 成本 ：产品的全部成本（总拥有成本）是多少-包括维护，所有必需的辅助产品，连接器等）？
• 许可 ：使用哪种许可或订阅模式？ 当需求变化（更多计算机，更多CPU，切换到虚拟机等）时会发生什么？ 是否免费升级？ 也可以降级吗？ 费用是“可预见的”吗，价目表是否可以理解？

标准	所有权	开源的
使用方便	非常复杂的安装（需要咨询！！），“工具地狱”	一键安装程序（在某些情况下也适用于Mac），几分钟后即可开始使用，统一平台
可维护性和监控	强大的工具（例如，用于管理和监视），无需分析源代码，通过GUI进行重构	功能较弱的工具（例如，用于管理和监视，有时需要集成其他供应商的其他产品），不需要分析源代码，通过GUI进行重构
社区	购买支持和论坛（但没有真正的社区可以提供帮助）	基于开源项目，加上自己的社区
企业支援	24/7企业支持，所需的SLA，具有数千台服务器的部署	24/7全天候企业支持，比专有支持少的保证，检查本地咨询和支持
功能性	集成功能+更多（BAM，CEP，EDA等，等等，等等）	集成功能和更多功能
灵活性	（提出更改请求+等待较长时间+支付）或（支付很多+快速获取）	开源，改变你想要的
可扩展性	自己做（艰难）或付钱	基于标准的事实标准
连接器	技术和商业产品的适配器	技术和商业产品的适配器
费用	更多（甚至更多）	减
发牌	复杂的价格表，支付所有费用（升级，迁移到VM，“ you-name-it”）	订阅模型，包括升级在内，可预测的成本，可以降级

表1：专有和开源产品的优缺点

产品替代品

Oracle Service Bus /融合中间件

Oracle Service Bus是Oracle当前提供的ESB。 它是Oracle融合中间件（OFM）堆栈的组件，根据本文的定义，该堆栈是一个集成套件。 其中提供了许多其他产品，例如，SOA套件，一致性，复杂事件处理，BPEL流程管理器，企业消息服务，服务注册表等。
Oracle套件可能没有提供很多功能。 这些工具非常强大且稳定。 大多数产品都有图形编辑器。 还为大多数可能的服务级别协议提供支持。 如果确实需要这些功能强大的SLA，那么您在Oracle方面是对的。 这种力量当然是有代价的。 产品的高度复杂性不容小under。 此外，您应该意识到高昂的许可和支持成本以及不透明的定价模型。
OFM基于Java EE，BPEL，SOAP或SCA等标准。 这些产品是专有产品，来自Oracle长期以来的多次收购。 因此，使用了不同的代码库，并且不同的产品通常需要不同的开发工具。 下载总和可能很快超过20 Gb。 安装非常繁琐，有时甚至需要几天才能完成，即使是在笔记本电脑上进行简单安装也是如此。 产品相当重。 运行时对资源的要求很高。
顺便说一句，您可能刚刚用“ IBM”代替了“ Oracle”，而用“ WebSphere”代替了“ Fusion Middleware”。 本节的内容几乎相同，只是要提到IBM在产品组合中有三种不同的ESB：Message Broker，ESB和DataPower SOA Appliances。 此外，Tibco，Microsoft和SAP在专有ESB和集成套件市场中也发挥着重要作用。
因此，本节的结论是，专有的集成套件可以提供几乎所有可能的功能，并涵盖几乎所有的SLA。 但是，大多数项目中并不需要许多这些功能或SLA。 在这种情况下，请确保还评估开源替代方案。 下一部分将介绍最重要的部分。

ule子ESB

Mule ESB是最早成功的开源ESB之一。 它与前面提到的其他开源ESB具有许多共同点。 其中包括非常简单的“一键式”安装和基于Eclipse的直观工具。 通常，开源ESB是非常轻巧且可扩展的解决方案。 除免费的开源版本外，还提供商业企业版。 这为产品提供了附加功能和支持。
对于仍然不了解它的人，应该提到“开源”并不意味着“免费”。 甚至开源软件的供应商也必须赚钱，并且不能免费开发产品和提供支持。 但是，价格更方便客户使用，而不是像大多数专有产品那样基于晦涩的价格表。 但是，可以使用开源版本（甚至在生产中使用），而无需支付任何许可费用。 但是，开放源代码版本通常只是用于玩转游戏或进行概念验证，以便以后通过附加功能和支持升级到企业版。
顾名思义，Mule ESB是纯ESB。 与诸如Apache Camel或Spring Integration之类的框架相比，重要的优点是用于有效实施集成方案的图形编辑器以及B2B产品（例如SAP或Salesforce）的可用连接器。 但是，Mule ESB中缺少套件的功能。 对于此类用例，必须将ESB与其他供应商的产品结合使用。 Mule ESB的负面方面是小型社区，限制性许可模型和源代码的有限可用性。 竞争对手在这方面具有明显的优势。

保险丝ESB

保险丝ESB是像Mule ESB一样的纯ESB，没有套件。 它基于集成环境中的事实上的标准，例如Apache CXF和Apache Camel。 结果，一个伟大的社区已经从一开始就得到了保障。 开发环境基于Eclipse，非常直观。

Fuse ESB是FuseSource的一部分。 但是，FuseSource最近被Red Hat收购，现在属于JBoss部门。 保险丝ESB包含在当前路线图中，并将继续得到支持。 它将与已收购的BPM解决方案Polymita集成到JBoss企业SOA平台中。 统一套件还有很长的路要走，因为FuseSource和Polymita的集成仍需要几个月的时间，而现在通过JBoss ESB，Switchyard和Fuse ESB整合三种ESB产品成为可能。 在这里，其他开源供应商已经取得了更好的结果。

Talend ESB /统一平台

Talend ESB是Talend套件的一部分。 Talend ESB可以单独使用，也可以与Talend统一平台的其他组件结合使用。 所有组件都是开源的，免费提供。 企业版提供其他功能和支持。 与专有产品的区别在于，所有部分组件都基于相同的代码库，并且各处都使用相同的工具。 ESB，BPM，ETL，MDM等不同领域的使用很流畅-本身并不是一个单独的集成项目。
Talend套件的所有工具都基于Eclipse。 保留了熟悉的“外观”和直观的Eclipse使用。 Talend为所有产品零件提供视觉设计师，并使用“零编码”方法。 这样可以有效地实现集成方案。 当然，您仍然可以编写自定义逻辑并将其集成到项目中，例如通过Java类（POJO）或其他脚本语言。
与Fuse ESB一样，Talend ESB基于集成环境中的多个事实上的标准，例如Apache Camel，Apache CXF，Apache Karaf和Apache Zookeeper。 除了适用于Apache Camel的JMS，HTTP或FTP等技术的连接器外，还有许多其他B2B适配器可用，例如Alfresco，Jasper，SAP，Salesforce或主机系统。 默认情况下包括所有500+个连接器。 结果是，Talend的IDE比其竞争对手具有更高的硬件要求。 您不应该在太弱的笔记本电脑上安装Talend。 另一个缺点是缺少SOA治理功能。 计划在下一个版本中发布。

WSO2 ESB /平台

WSO2是一个相对未知的供应商。 但是，WSO2提供了套件的整个组件范围，包括业务流程服务器，业务规则服务器，业务活动监视器或治理注册表。 整个WSO2平台可以非常容易地安装，并提供一个轻量级的，基于Eclipse的开发工作室。 与Talend和FuseSource一样，WSO2还将主要的开源项目（例如Apache Synapse（轻量级ESB），Axis（Web服务实现）或ODE（业务流程引擎））放入其组件中。
除了Talend之外，WSO2是唯一提供基于单一代码库和单一开发环境的完整套件的供应商。 因此，从一小部分功能开始，到以后逐步添加更多功能，迭代开发过程没有任何障碍。 缺点是图形工具。 它支持平台的所有组件，但使用起来不像竞争对手的工具那样直观。

“自己动手” Integration Suite？

结论的警告：几个框架或产品的组合来构建您自己的自定义集成套件通常是不必要的昂贵操作，并且会导致许多其他陷阱。 由于已经存在几种解决方案，因此强烈建议不要使用各种解决方案。 需要编写“胶水代码”，必须进行测试和错误修复，万一出现问题，没有具体联系。 供应商通常仅指另一侧，即，如果您尝试将ESB与另一供应商的BPM解决方案结合使用，那么在遇到问题时应称呼哪个？ 那么，如果其他人已经在意并且整个堆栈（也是开源的）已经可用，那么为什么还要关心所有这些问题呢？

结论

没有解决集成问题的灵丹妙药。 首先，必须确定框架是否足够。 请注意，大多数源代码必须由您自己编写，并且缺乏工具和支持。 否则，ESB是更好的选择。 但是，如果以后需要某个套件的任何其他功能，则最好从一开始就使用集成套件的ESB。 这样可以确保可持续性，而不会因多个产品的组合而出现任何问题和额外费用。

如果要使用ESB或集成套件，则必须确定专有产品还是开源产品是更好的选择。 专有解决方案提供所有可能的功能和强大的支持。 但是，这也导致更高的成本和更高的复杂性。 相反，开源解决方案以较低的成本，易用性和灵活性得分。 解决此问题后，可以创建一个候选清单来详细评估替代方案。 强烈建议在做出最终决定之前进行概念验证。 确保您的团队而不是仅由供应商的顾问来实施此原型（从首次安装到最终部署和监视）。 您的团队将不得不将来单独安装产品，并独立于可能无法获得的任何顾问而独立实施集成问题。

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

esb集成总线