Apache Camel和其他ESB产品

81

嘿，
如果我们有Apache Camel，为什么要使用其他解决方案，例如Apache ServiceMix和Mule？
与这些产品相比，Apache Camel无法做些什么？
何时使用Mule / ServiceMix和何时使用Camel？

apache-camel  mule  esb  apache-servicemix 
— 凯龙
source

Answers:

73

Apache Camel是一个实现企业集成模式（EIP）的库。尽管它可以使用Spring作为其IOC框架，但它甚至不依赖于Spring，因此它是完全独立于平台的。它只是一个图书馆。因此，您可以在任何JVM环境中运行它，例如简单的jvm，servlet，ejb，osgi。它不会带来像Mule这样的容器的任何好处（或开销）。我认为，它在这一领域的关注点更加清晰。

Mule也可以嵌入不同的环境中，但是我认为Mule具有将其EIP库耦合到其容器的优点和缺点。当您在servlet或ejb环境中部署Mule时，您真的要携带Mule容器的所有行李吗？我不是Mule专家，我认为您可能需要花费相对较少的精力并清理掉一些冗余功能。（请注意，这在所有情况下都不是一项糟糕的功能，如果您正在另一个容器中嵌入式运行，则这只是多余的。）

Apache ServiceMix是一个OSGI容器，使用Camel来实现EIP作为ESB的基础。尽管ServiceMix的历史悠久始于JBI，但它已脱离JBI，并发展成为（IMO）一个很好的分层体系结构，在OSGI容器中结合了同类最佳的Apache CXF，Camel和ActiveMQ。这里的主要价值实际上不是ServiceMix及其JBI支持，而是底层的OSGI容器标准加上经过验证的Apache传输，例如用于Web服务的CXF和用于JMS的ActiveMQ。OSGI是一种成熟的标准，提供了一个容器，用于解决在.NET出现之前困扰Microsoft的相同类型的“ DLL”地狱。虽然.NET和OSGI都无法解决根本问题的本质，但它们至少提供了解决该问题的方法。OSGI也有其他好处，但是从产品选择的角度来看，基于标准的容器是主要的，而Mule（通常是Java）不能解决的基本功能是依赖关系管理。

在将Mule与Apache社区进行比较时要注意的一些重要事项。从某种意义上说，Mule就像Redhat一样，尽管它是一个开放源代码许可证，但在我看来它并不是一个开放社区。任何人都可以参加Apache，而MuleSoft拥有Mule社区和最终的路线图。其次，尽管可以说Mule社区非常活跃，但我认为Apache社区要大得多（自然而然，因为它不是封闭式社区）。两种方法都有优点和缺点。Apache方法的一个优点是，基于Camel，CXF，ActiveMQ和OSGI的ESB有多家供应商。例如，Talend在没有ServiceMix JBI历史的情况下提供了基于相同核心技术的ESB。在Apache社区中，这既有优点也有缺点，但是真正的重点是要突出Apache和Mule之间的区别。在Mule社区中找不到多个供应商。因此，与像Mule这样的封闭社区相比，IMO的Talend或ServiceMix之类的Apache ESB是一个更广泛，更具包容性的最终竞争社区。

埃德·奥斯特

— 埃德·奥斯特
source
76

现在是2016年，自最初提出该问题以来，发生了很多变化，所以我想为新观众重新审视它。

从策略上讲

  • Apache Camel秉承了自己的根基，尚未发展成为重量级或功能完善的运行时平台。它是通用和模块化的，可以运行：

    1. 嵌入任何类型的Java容器（servlet容器，应用程序服务器，Spring Boot）中。
    2. 作为Java进程独立。
    3. 在OSGi环境中（Apache Karaf）。

  • 正如我从OpenHub摘录的图表所描绘的那样，Apache Camel每月都在不断发展并获得吸引力和活动。用户群也在不断增加。

每月Apache Camel贡献者

  • 2012年，红帽收购了FuseSource，后者是Apache Camel，ActiveMQ，ServiceMix和CXF的主要推动者和开发商之一。Red Hat现在雇用了一些提交者和PMC成员来从事Apache Camel的工作。

  • Mule ESB提供其产品的两个版本：社区（根据CPAL许可证免费）和企业（收费）。他们将社区版本定义为：

评估或生产前使用的理想选择。

=>意味着您应该获得用于生产用途的付费Enterprise订阅。

  • 实际上，Mule ESB社区版是在CPAL许可下发行的。这意味着，如果您仍然决定使用此版本，则Mule需要：

    • 每次启动或最初执行可执行代码和大型代码时，最终用户使用的图形用户界面上必须显着显示Mulesoft的归因信息，以访问此类涵盖代码（可能包括在初始屏幕上显示） ）（如果有）。=>基本上，您需要宣扬使用Mule构建的任何内容都可以在Mule上运行。

    • 如果您通过网络访问Mule ESB的部署（由于它是一个集成平台，它总是会的！），您还必须使访问源可以访问您的部署源。

  • 如上所述，Apache Camel是一个完全开放的项目，由社区驱动，对于社区而言。所有源代码都是公开可用的，并且鼓励每个人发送拉取请求，贡献组件以及在论坛中进行咨询。相反，the子社区是封闭式社区。

  • 最后但并非最不重要的; 也许是最重要的部分。这是Google趋势对Mule ESB与Apache Camel的评价。请注意，我正在使用新的语义主题度量来提高准确性，而不是使用标准查询关键字。这样，我们不是在衡量动物（M子对骆驼）的流行程度，而是软件的受欢迎程度！解释：从2007年到2011年，M子的趋势大幅下降，而Apache Camel的趋势则上升。自2011年以来，M子一直处于平稳状态，而Apache Camel则保持健康发展趋势！

Google趋势中的子vs骆驼

Apache Camel的技术演进

自2010年9月25日最初提出该问题以来，只是想为您提供有关Apache Camel演变的一些功能指标。这是当时的源代码树。

  • 当时Camel有88个组件，现在有220个组件，包括与Facebook，Twitter，Salesforce，Apache Ignite，Apache Cassandra，AWS，Apache Kafka，MongoDB，Apache Spark等的集成。
  • 许多很多技术改进：异步路由引擎，消息历史记录，断路器EIP，对EIP的许多改进和增强，例如聚合，拆分，动态路由等。
  • 生态系统已发展到现在还包括Hawtio进行监控和管理，fabric8部署等。
  • 自那时以来，已经解决了5500多个票证，包括新功能，改进，错误等。
  • 还有更多！

最后的笔记

在过去的5.25年中，这两种产品都有很大的发展！但是，由于许可证的不同以及Mule ESB和Apache Camel的社区性质，我认为它们之间不再具有可比性。

Apache Camel是完全开源的❤️，而Mule ESB社区要求用户将Mulesoft赋予属性并发布使用Mule的软件的源代码。Apache软件许可证是一种对企业友好的许可证：您可以自由使用Camel，而无需注明出处或任何其他要求。真正免费的啤酒！

希望对过去几年的反思能对新观众有所帮助！:)

免责声明：我是Apache Camel项目的提交者和PMC成员。

— 怒吼
source
3
我发布了一篇博客文章，其中对骆驼和M子
— 克劳斯·易卜生
2
感谢劳尔的更新。我先阅读Claus的博客并发表评论，并在这里向您提出问题，您认为将Apache Camel的商业实现与Talend或JBossFuse等运行时或与Mule中的Anypoint进行比较会更好吗？否则像前面提到的Camel是开源的，而Mule是关于金钱的，所以已经有了差异，这会影响产品的发展方式。
— Souciance Eqdam Rashti
1
问题是我在比较项目，而不是产品。事实是，ule子既是项目又是产品，因此它们不可能分开。实际上，公平的是将Mule与（Apache Camel + JBoss Fuse + Talend ESB）进行比较，这将为Camel生态系统带来更高的指标！但是我不想把分析推到这么远，因为根据我的数据，大多数Camel用户都是香草Apache Camel用户。希望有道理。
— raulk
是的，但是我的意思是，大多数使用Mule的企业都使用企业版，并且带有运行时，开发和监视环境等。它基本上是完整的软件包，因此将JBoss或Talend与通过功能比较来进行ule和做一个功能。开放性和社区贡献很重要，但是在选择集成层时当然不是决定性因素。
— Souciance Eqdam Rashti
5

Camel是中介引擎，而Mule是轻量级集成平台。区别在于，Mule提供了ESB的所有功能，包括用于部署应用程序，REST和Web服务的容器。Mule可以采用与Camel相同的方式进行嵌入，以允许应用程序开发人员将应用程序代码及其集成代码嵌入其中。两者都与Spring紧密集成。

Mule出于充分的理由不使用JBI ，并且由于JBI规范已被解散（没有工作组，最初是通过JBI规范的Oracle所拥有），没有充分的专业或技术理由来使用JBI。

— 罗斯·梅森
source
2
骆驼与Spring兼容，但与Spring紧密集成。
— 小鹏-ZenUML.com 2015年
4
Camel不使用-从未使用过-JBI。
— raulk
0

克劳斯，骆驼常见问题解答中有很多错误，毫不奇怪，没有一个对我们有利：)

  • Mule中的UMO模型不再在Mule中。我们开始从Mule 2中的那个模型中移开，而在Mule 3中它已经完全改变。
  • Mule进行显式类型转换已经有几年了，这与Camel并没有区别
  • Mule已获得OSI批准的CPAL 1.0许可证的许可。这是一个开放源代码许可证，而不是商业许可证。请尽快更新
— 罗斯·梅森
source
我更新了FAQ，以声明其基于Mule 1.x / 2.x。这是James编写FAQ条目的时间。
— 克劳斯·易卜生
0

首先，您需要了解Service Mix就像一个可以运行Apache Camel代码的容器，而Mule ESB本身就是一个单独的产品

您可以在ESB产品之间提供很多差异。

在研究差异化之前，您应该了解一些事情。他们是

  1. 产品如何开发
  2. 它的许可
  3. 其支持功能
  4. 是否开源
  5. 如果是开放源代码，则可以修改和使用源代码，依此类推。

以上是您进行选择之前需要研究的最佳因素。以上是大多数产品选择所通用的，这里也需要特别注意。

次要产品差异将特定于工具及其领域。这很可能是您正在寻找的答案。进行选择之前，找到您需要自省的列表。

  1. 社区支持
  2. 产品栈
  3. 关于修改自己的代码的可扩展性
  4. 学习能力和可用性
  5. 作为企业购买时的产品支持

这可能是您需要自己进行选择差异的一项研究。任何增加价值的方法都会使产品适合您的组织，而不是在市场上说出最好的。

说到Apache骆驼或其他ESB。将会带来的改变是

  1. 运输数量
  2. Apache Camel在Mule上为您提供了各种DSL，其他原因是它们没有Camel中的多个DSL。
  3. Mule产品堆栈中包含API管理和内部云连接器，其中考虑到FUSE ESB时，Apache Camel是一个框架。JBossStack提供了大量其他产品，这些产品可能会补充您的选择。
— 纳文·拉吉
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.