Apache Camel和其他ESB产品

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

Answer 1

Apache Camel是一个实现企业集成模式（EIP）的库。 虽然它可以使用Spring作为它的IOC框架，但它不依赖于Spring，所以它完全是平台独立的。 这只是一个图书馆。 所以你可以运行任何JVM环境，比如简单的jvm，servlet，ejb，osgi。 它没有带来像mule这样的容器的任何好处（或者开销）。 在我看来，这个领域的问题更加清晰。

Mule也可以embedded到不同的环境中，但是我认为Mule将EIP库耦合到它们的容器的优点和缺点。 当你在一个servlet或ejb环境中部署Mule时，你真的要携带Mule容器的所有行李吗？ 我不是一个mule子的专家，我认为你可能会花费相对适中的努力，并清除一些冗余的能力。 （请注意，在所有情况下这都不是什么坏事，只是在另一个容器中运行embedded的时候，这是多余的。）

Apache ServiceMix是一个OSGI容器，它使用Camel来实现EIP作为ESB的基础。 尽pipeServiceMix在JBI历史上起源于JBI，但它已经从JBI转移到了IMO（IMO），它已经发展成一个在OSGI容器中结合了最佳的Apache CXF，Camel和ActiveMQ的分层架构。 这里的主要价值并不是真正的ServiceMix和它的JBI支持，而是底层的OSGI容器标准与经过validation的Apache传输（如用于Web服务的CXF）和ActiveMQ for JMS相结合。 OSGI是一个成熟的标准，它提供了一个容器来解决在.NET出现之前困扰Microsoft的相同types的“DLL”地狱。 虽然.NET和OSGI都不能解决底层问题的基本复杂性，但至less可以提供解决这个问题的方法。 OSGI也有其他的好处，但是从产品select的angular度来看，基于标准的容器是主要的，它的基本特征是Mule（和Java一般）不能解决依赖pipe理问题。

在比较Mule和Apache社区时需要注意的一些重要的事情。 mule就像Redhat一样，虽然它是一个开源许可证，但在我看来并不是一个开放的社区。 任何人都可以参与Apache，而MuleSoft拥有Mule社区和最终路线图。 其次，尽pipemule社区非常活跃，但我认为Apache社区更大（自然也是如此，因为它不是门控社区）。 两种方法都有好处和坏处。 Apache方法的一个好处是有多个基于Camel，CXF，ActiveMQ和OSGI的ESB供应商。 例如，Talend提供了一个没有ServiceMix JBI历史的相同核心技术的ESB。 这在Apache社区中既有利弊也有弊端，但真正的重点是突出Apache和Mule之间的差异。 你不会在mule社区find多个供应商。 因此IMO像Talend或ServiceMix这样的Apache ESB是一个比像Mule这样封闭的社区更广泛，更包容，最终竞争的社区。

Ed Ost

Answer 2

现在是2016年，自从这个问题最初提出以来，很多已经改变了，所以我想重新审视这个新的观众。

从战略上讲

• Apache Camel 始终坚持自己的根本 ，并没有发展成为一个重量级的，也没有完全成熟的运行时平台。 它是多function和模块化的，可以运行：

  1. embedded在任何一种Java容器（servlet容器，应用服务器，Spring Boot）中。
  2. 作为Java过程独立 。
  3. 在OSGi环境中 （ Apache Karaf ）。

• Apache Camel一直在不断发展，并且每个月都会获得一定的推动力和活跃度，正如我从OpenHub提取的这一点下的图表所描绘的那样。 用户群也在不断增加。

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

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

理想的评估或预生产使用。

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

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

  • 每次启动或初始运行“可执行文件”和“源代码”或“较大作品”时，都必须在最终用户使用的graphics用户界面上显示Mulesoft的归属信息，以访问此类涵盖代码（可能包括启动屏幕上的显示），如果有的话。 =>基本上你需要做广告 ，无论你用mule子build立的是在mule子上运行。

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

• 就像上面提到的其他人一样，Apache Camel是一个完全开放的项目， 受社区的驱动，面向社区 。 所有源代码都是公开的，鼓励大家发送请求，提供组件，帮助或在论坛中查询。 相反，mule社区是一个封闭的社区 。

• 最后但并非最不重要的; 也许是最重要的部分。 Google Trends对Mule ESB和Apache Camel的评价如下 。 请注意，我正在使用新的语义主题测量来获得更高的准确性，而不是使用标准查询关键字 。 这样，我们不是衡量动物（muleVS骆驼），但软件的stream行！ 解释：从2007年到2011年，mule子大幅下降，而阿帕奇骆驼趋于上升。 自2011年以来，mule子已经高原，而阿帕奇骆驼保持健康趋势！

Apache Camel的技术发展

只是想给你一些有关Apache Camel从2010年9月25日起，当你最初问这个问题的演变的function指标。 这是当时的来源树 。

• 当时，骆驼有88个组件，现在有220个组件，包括与Facebook，Twitter，Salesforce， Apache Ignite ， Apache Cassandra ，AWS， Apache Kafka ，MongoDB， Apache Spark等的集成。
• 许多技术改进：asynchronous路由引擎，消息历史logging，断路器EIP，许多对EIP如聚合，分离，dynamic路由等的改进和增强。
• 生态系统已经发展到现在还包括Hawtio监控和pipe理， fabric8的部署等。
• 从那时起，已经有超过5500张门票被解决，包括新function，改进，错误等等。
• 还有很多，更多！

最后的笔记

在过去的5，25年中，这两种产品都经历了很多变化！ 但是，由于Mule ESB和Apache Camel的许可证和社区性质的不同，我不认为它们可以相互比较。

Apache Camel完全开放源代码❤️，而Mule ESB社区要求用户归类Mulesoft并发布使用Mule的软件的源代码。 Apache软件许可证是一项适用于企业的许可证：您可以自由使用骆驼而不需要任何其他要求。 真正像啤酒一样自由 ！

希望过去几年的这种思考能够帮助新观众！ 🙂

---

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

Answer 3

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

Answer 4

在Apache Camel上有一些常见问题解答条目，在这个http://camel.apache.org/faq上提供了一些信息;

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

有一些链接在社区的人谈话和骆驼比较其他项目。

Answer 5

骆驼是一个调解引擎，而mule是一个轻量级的集成平台。 不同之处在于，Mule提供了ESB的所有function，包括用于部署应用程序，REST和Web服务的容器。 可以用Camel的方式embeddedMule，以允许应用程序开发人员在应用程序代码中embedded其集成代码。 都与Spring紧密结合。

Mule没有使用JBI是因为很好的原因 ，现在JBI规范已经解散了（没有任何工作组，由Oracle拥有，最初通过了JBI规范），没有好的专业或技术理由来使用JBI。

Answer 6

克劳斯，在骆驼常见问题中有一些错误，毫不奇怪，他们没有在我们的利益:)

• mule子的UMO模型不再是mule子了。 我们开始从Mule 2中移除这个模型，并且在Mule 3中已经完全改变了。现在我们有了一个非常简单的Message Processor模型，
• mule子已经有几年明确的types转换，这不是骆驼的区别
• Mule获得OSI许可的CPAL 1.0许可 。 这是一个开源许可证，不是商业版本。 请尽快更新

Answer 7

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

ESB产品之间可能会有很多差异。

在分析之前，你应该知道一些事情。 他们是

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

以上将是您select前需要考虑的最佳因素。 以上是大多数产品select的通用方法，在这里也需要特别注意。

次要的产品差异将是特定于工具和它的领域。这可能是你正在寻找的答案。 在select之前查找您需要反省的列表。

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

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

谈到Apache骆驼或其他ESB。 将会造成的差异是

1. 运输的数量
2. Apache Camel为您提供了Mule等多种DSL以及它们不像Camel那样拥有多个DSL。
3. 其产品堆栈中的Mule包含APIpipe理和内部云连接器，当考虑到FUSE ESB时，Apache Camel是一个框架。JBoss Stack提供了大量的其他产品，可能会对您的select有所帮助。