82

嘿，
如果我们有 Apache Camel，为什么还要使用 Apache ServiceMix 和 Mule 等其他解决方案？
与这些产品相比，Apache Camel 有什么不能做的吗？
何时使用 Mule/ServiceMix 以及何时使用 Camel？

4

7 回答 7

78

现在是 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 许可下免费）和企业版（付费）。他们将社区版本定义为：

非常适合评估或预生产使用。

=> 这意味着您应该获得付费企业订阅以供生产使用。

  • 事实上，Mule ESB 社区版是在CPAL 许可下分发的。这意味着如果你仍然决定使用这个版本，Mule需要：

    • 每次启动或初始运行可执行文件和源代码或更大的作品时，必须在最终用户使用的图形用户界面上突出显示 Mulesoft 的归属信息以访问此类涵盖代码（可能包括在启动屏幕上显示） )，如果有的话。=> 基本上你需要宣传你用 Mule 构建的任何东西都在 Mule 上运行。

    • 如果您的 Mule ESB 部署是通过网络访问的（它总是会的，因为它是一个集成平台！），您还必须让访问它的任何人都可以使用您的部署源。

  • 正如上面其他人提到的，Apache Camel 是一个完全开放的项目，由社区驱动，为社区服务。所有源代码都是公开的，鼓励每个人发送拉取请求、贡献组件并在论坛中提供帮助或查询。反之，骡社区是一个封闭的社区。

  • 最后但并非最不重要的; 也许是最重要的部分。以下是 Google 趋势对 Mule ESB 与 Apache Camel的对比。请注意，我使用新的语义主题测量来获得更高的准确性，而不是标准的查询关键字。这样，我们衡量的不是动物（骡子 vs 骆驼）的受欢迎程度，而是软件的受欢迎程度！解读：从 2007 年到 2011 年，Mule 呈大幅下降趋势，而 Apache Camel 呈上升趋势。自 2011 年以来，Mule 已趋于平稳，而 Apache Camel 则保持健康向上的趋势！

Google 趋势中的骡子 vs 骆驼

Apache Camel 的技术演进

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

最后的笔记

在过去的 5,25 年中，这两种产品都发生了很大的变化！但是，由于 Mule ESB 和 Apache Camel 的许可证和社区性质不同，我认为它们不再具有可比性。

Apache Camel 完全开源❤️，而 Mule ESB 社区则要求用户归属 Mulesoft 并发布使用 Mule 的软件的源代码。Apache 软件许可证是一种商业友好型许可证：您可以自由使用 Camel，无需署名或任何其他要求。像啤酒一样真正免费！

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

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

于 2016-01-15T19:20:27.063 回答
74

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 提供基于相同核心技术的 ESB，但没有 ServiceMix JBI 历史。这在 Apache 社区中既有优点也有缺点，但真正的重点是突出 Apache 和 Mule 之间的区别。您不会在 Mule 社区中找到多个供应商。因此，IMO 像 Talend 或 ServiceMix 这样的 Apache ESB 是一个更广泛、更具包容性且最终具有竞争力的社区，而不是像 Mule 这样的封闭社区。

埃德·奥斯特

于 2011-10-27T02:58:40.017 回答
8

我的博文正好回答了这个问题：http ://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel 是一个轻量级的集成框架，ServiceMix 和等等都是完整的 ESB。

于 2012-01-11T08:56:45.940 回答
5

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

Mule 不使用 JBI有充分的理由，现在 JBI 规范已经解散（没有工作组，由最初传递 JBI 规范的 Oracle 拥有），没有充分的专业或技术理由使用 JBI。

于 2010-09-29T14:31:50.673 回答
4

Apache Camel 上的一些常见问题解答条目对这个 http://camel.apache.org/faq有所了解

以及 Apache Camel 上的链接集合 http://camel.apache.org/articles.html

有一些链接，社区中的人们可以在这里讨论并将 Camel 与其他项目进行比较。

于 2010-09-26T13:31:04.337 回答
0

克劳斯，骆驼常见问题解答中有很多错误，不出所料，没有一个对我们有利:)

  • Mule 中的 UMO 模型不再存在于 Mule 中。我们开始远离 Mule 2 中的那个模型，它在 Mule 3 中已经完全改变。我们现在有一个非常简单的消息处理器模型，这使得你关于它的声明变得多余
  • Mule 已经进行了几年的显式类型转换，这不是 Camel 的区别
  • Mule 在OSI 批准的 CPAL 1.0 许可下获得许可。这是一个开源许可证，而不是商业许可证。请尽快更新
于 2010-09-29T14:55:23.997 回答
0

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

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

在查看差异化之前，您应该知道一些事情。他们是

  1. 产品是如何开发的
  2. 其许可
  3. 它的支持功能
  4. 开源与否
  5. 如果开源可以修改和使用源等等。

以上将是您做出选择之前需要考虑的最佳因素。以上是大多数产品选择的通用内容，在这里也需要特别注意。

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

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

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

谈到 Apache camel 或其他 ESB。不同之处在于

  1. 运输数量
  2. Apache Camel 为您提供 Mule 上的各种 DSL，其他是它们没有像 Camel 中的多个 DSL。
  3. Mule 在其产品堆栈中包含 API 管理和内部云连接器，当考虑到 FUSE ESB 时，Apache Camel 是一个框架，JBoss Stack 提供了大量其他产品，可以补充您的选择。
于 2015-04-12T19:52:04.133 回答