Tijs Rademakers和Jos Dirksen在开源ESB上

InfoQ已出版了Tijs Rademakers和Jos Dirksen 所著的《开源ESB在行动》一书中的一章样本 ，并借此机会采访了作者在现实世界项目中使用开源ESB的经验。

InfoQ：鉴于开源ESB的当前状态，您是否认为它们与商业替代品相当？

Tijs Rademakers（TJ） ：我有幸与商业（封闭源）和开源ESB一起工作。 使用Mule ESB时，我发现的惊人之处在于，它使企业集成和面向服务的复杂工作变得更加容易。 与商业ESB一起工作意味着前期许可证费用巨大，安装过程繁重，必须学习新的IDE以及必须从可用的文档和售后顾问中学习。 在解决了这些前期成本之后，WebSphere，Tibco，Sonic等知名的封闭源ESB会很好地完成工作。 使用开源ESB，您首先要下载ESB，然后在10分钟后，使用一些可用示例运行ESB。 然后，您将查看示例配置文件，并且可以轻松实现自己的集成解决方案。 实现一项自定义功能意味着编写Java类并使用Mule ESB Java API。 对于Java开发人员来说，这非常容易理解。 而且，如果您什么都不懂，那么可以在邮件列表上找到活跃的大型社区来提问。

Jos Dirksen（JD） ：我认为，当您查看核心ESB功能时，开源领域的当前领军者肯定与商业替代产品相当。 例如，路由，转换和连接在所有方面都是开源ESB必不可少的，甚至比许多商业替代品还要好。 同样，在易用性方面，我认为开源ESB的得分要比许多商业产品更好。

TJ ：也许令人惊讶的是，开源ESB的功能与其商业替代品非常相似。 而且更令人惊讶的是，由于易于配置的机制和简洁的API，集成解决方案的配置和开发对开发人员更加友好。 商业产品通常会提供一个IDE，您可以在其中拖放在一起的集成解决方案，顺便说一句，顺便说一句，但实现拖放支持所无法提供的功能可能会非常痛苦。 简而言之，在为您的组织选择ESB时，您确实应该考虑使用开源ESB。

InfoQ：您如何看待ESB在SOA中的角色？ 它应该是中心，焦点还是边缘？

JD ：取决于场景。 通常您会听到，每个SOA架构都应在其核心处具有ESB，但我并不认为这是必需的。 如果您已经有了现代的（例如面向Web服务的）体系结构，则不一定总是需要引入ESB。 如果在这种情况下引入注册表，则可以创建一个非常漂亮且优雅的面向服务的体系结构。 当您拥有一个更加异构的环境（例如，许多旧式，.net与Java，大型机相结合）时，您可能需要一个更“智能”的集成层，以面向服务的方式公开这些应用程序。 在那种情况下，我认为ESB应该是SOA的中心点。

TJ ：SOA被某些人宣布为无效，因此我当然不想将ESB列入清单：-)我认为SOA不仅仅是一个集成旧系统和通过ESB提供服务的话题。 SOA具有业务视图和技术视图，而ESB最重要的是技术。 因此，ESB是很小但很重要的部分，可用于实现SOA。 ESB是至关重要的部分，它可以提供诸如路由，转换，安全性和协议转换之类的功能，这些功能可以帮助服务彼此通信，并使（BPEL）流程与服务通信。

InfoQ：您认为开源SOA解决方案的改进空间最大，您最想念的是什么？

JD ：我最想念的是……有趣的问题。 我个人最想念的是一个非常好的集成解决方案。 当我们使用开源进行SOA项目时，我们通常不仅仅使用ESB，例如，我们还需要BPM引擎。 当前，尽管它正在改进，但是BPM引擎，规则引擎和ESB之间的集成并不完美。 因此，通常我们需要在这些组件之间编写自己的集成代码。 我认为这是可以做出很大改进的领域。

TJ ：实际上，开源SOA项目空间中有很多活动。 有ESB项目（Mule，ServiceMix，Synapse，Open ESB等），BPM项目（JBoss jBPM，Apache ODE，Open ESB BPEL组件等），服务注册表（Mule Galaxy，WSO2注册表等），业务规则引擎（Drools / JBoss）规则）。 因此，有许多出色的SOA项目可用。 但是我认为将这些组件集成在一起还有一些改进的余地。 商用或开源SOA产品要领先一些，因为它们提供了完整的SOA工具堆栈。 但是，缺点当然是供应商锁定。

JD ：我认为开源ESB可以改进的领域是管理和图形支持。 当您查看商业ESB时，它们的管理支持通常会更好，在支持工具，开源ESB可以做的改进的开发环境方面也是如此。 但是，我认为后者对高级用户的重要性不高，因为它们可能比图形工具所限制的更深层次地进入ESB。 就我个人而言，我希望看到一个良好的集成解决方案，提供BPM，业务规则和良好的服务存储库。

InfoQ：您是否可以从案例研究中分享一些非功能性统计信息？

TJ ：难题。 当然，在ESB环境中，非功能统计信息通常难以检索。 但是，我们已经在以JORAM作为消息传递引擎的Mule ESB上以每秒多条消息的速度完成了项目。

JD ：我目前正在从事的项目是处理城市居民与地方当局之间互动的项目。 这是一个基于Mule的系统，在该系统中，我们有800.000公民通过.net前端与一组后端服务进行通信。 服务之间的所有交互都是通过Mule完成的。 Mule还将一组旧的后端应用程序公开为Web服务。

InfoQ：您如何分别区分MuleESB和ServiceMix的优缺点？ 关于何时使用哪个的任何建议？

JD ：两者都有优点和缺点。 我喜欢ServiceMix的模型，该模型可以很容易地热部署新的集成流程，并且它基于标准。 即使JBI标准并没有获得太多的关注，它还是一个非常好的规范，当您了解JBI时，使用ServiceMix会非常简单。 我喜欢您具有用于集成的可插入组件的方式，即使这些组件都是可热部署的。 对于ServiceMix来说，包含Camel也是很重要的一点。 我真的很喜欢使用DSL来开发集成流程.ServiceMix的缺点与它的优点息息相关。 JBI规范确实带来了另一个难度，并且对XML的关注并不总是与您在集成领域中遇到的要求非常吻合。 另一方面，Mule使创建集成流变得非常容易，并且非常简单。 它具有一组非常广泛的路由器，易于扩展，并且具有许多开箱即用的连通性，路由和转换选项。 借助Mule，您可以在数分钟内启动并运行相当复杂的集成流程。 但是，ule子确实有一些缺点。 虽然不算什么，但是对我个人而言最大的缺点是您不能热部署新的集成流程。 如果Mule应该集成OSGi或其他易于更新集成流程的方式，那将是一个很大的优势。

TJ ：ServiceMix当前分为两个单独的项目：ServiceMix 3.2.x / 3.3.x和ServiceMix4。在我们的书中，我们使用ServiceMix 3.2.x（基于JBI），但我们也对ServiceMix 4（OSGi）进行了简短介绍。 -基于，并支持JBI）。 因此，ServiceMix和Mule ESB之间的主要区别在于ServiceMix基于JBI，而Mule ESB实现了基于Java的自定义模型。 但是，两个ESB之间也有很多重叠（Spring支持，带有CXF的Web服务支持，XML配置）。 但是，让我们关注差异。

Mule ESB是一个以Java为中心的ESB，它使Java开发人员可以很容易地开始使用它。 有一套真正强大的XML模式，可以进行真正干净和可读的XML配置并提供代码完成支持。 当您想实现一条转换逻辑或路由逻辑时，可以轻松地开发一个简单的Java类/ Spring bean /脚本文件并将其包含在XML配置中。 如果我不得不指出Mule的缺点，那就是缺乏对热部署的支持。

ServiceMix是一个以JBI为中心的ESB，它提供了许多JBI组件，例如JMS，Web服务，Camel和BPEL组件。 当然，您也可以使用其他基于JBI的ESB中的JBI组件，例如我们在本书中展示的PEtALS和Open ESB。 ServiceMix为每个JBI组件提供了一种简单的XML配置语言，并提供了热部署功能来部署您的集成解决方案。 ServiceMix的缺点是进入JBI的学习曲线。 因此，这是您最希望在Mule和ServiceMix之间选择的一个问题。 ServiceMix提供JBI支持，BPEL集成，XML消息焦点和热部署功能。 Mule提供了以Java为中心的模型，jBPM支持，与消息无关的支持，而没有热部署功能。

JD ：实际使用哪个取决于您的要求。 当您拥有以XML标准为中心的格局时，与ServiceMix集成是一个不错的选择。 如果您需要更多低级集成，则ule子可能是一个更好的选择。 这两个ESB都是出色的开源集成解决方案，将非常适合解决许多集成问题。

InfoQ：为什么您最终选择ServiceMix和Mule而不是其他选择？ 对Apache Synapse或Spring Integration有任何意见吗？

TJ ：ServiceMix和Mule是成熟的开源ESB的很好的例子，它具有非常活跃的社区，代表着以JBI为中心的ESB和以Java为中心的ESB方法。 我们还考虑了其​​他替代方案，其中以Apache Synapse为主要替代方案。 顺便说一句，我们在本书中包含了Apache Synapse和Spring Integration的示例。 Apache Synapse是基​​于Apache Axis2的基于Web服务的ESB的一个很好的示例。 当您最需要WS- *支持和Rest支持时，Apache Synapse当然是您可能要考虑的ESB。 Spring Integration是一个不错的框架，我发现它与Apache Camel非常相似。 它们都为Hohpe和Woolf描述的企业集成模式提供了支持，您可以轻松地将其集成到Java应用程序中，而无需单独的集成容器。 因此，这些框架对于能够在应用程序级别上实现集成功能而无需引入中央ESB容器非常有用。

JD ：我个人在Spring集成方面还没有做太多事情，我们目前正在将它用于一个较小的项目，以使自己有感觉。 到目前为止，我们喜欢的事实是它是一个非常轻量级的解决方案，可以很容易地与我们编写的其余Spring应用程序结合使用。 当我们开始写这本书时，开源ESB空间还没有现在成熟，现在有更多成熟的解决方案。

TJ ：一定要注意开放源代码的ESB空间，因为这里有很多活动，可以选择很多项目和活跃社区！

InfoQ：谢谢！

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