It is now 2016 and a lot has changed since the question was initially asked, so I'd like to revisit it for new viewers.
Strategically speaking
Apache Camel has stayed true to its roots and has not evolved into a heavyweight nor fully-fledged runtime platform. It is versatile and modular, and can run:
Embedded in any kind of Java container (servlet container, application server, Spring Boot).
Apache Camel has continued to evolve and gain a traction and activity on a monthly basis, as portrayed by the graph under this point which I extracted from OpenHub. The userbase also keeps increasing.
In 2012, Red Hat acquired FuseSource, one of the main promoters and developers behind Apache Camel, ActiveMQ, ServiceMix and CXF. Several committers and PMC members are now employed by Red Hat to work on Apache Camel.
Mule ESB offers two versions of their product: Community (free under the CPAL license) and Enterprise (paid). They define their Community version as:
Ideal for evaluation or pre-production use.
=> Meaning that you should acquire a paid Enterprise subscription for production usage.
In fact, Mule ESB Community Edition is distributed under the CPAL license. This means that if you still decide to use this version, Mule REQUIRES THAT:
Each time an Executable and Source Code or a Larger Work is launched or initially run, a prominent display of Mulesoft's Attribution Information must occur on the graphic user interface employed by the end user to access such Covered Code (which may include display on a splash screen), if any. => Basically you need to advertise that whatever you have built with Mule is running on Mule.
If your deployment of Mule ESB is accessed over the network (it always will, since it's an integration platform!), you must also make the Source of your deployment available to whoever is accessing it.
As someone else mentioned above, Apache Camel is a completely open project and driven by the community, for the community. All the source code is publicly available, and everybody is encouraged to send in pull requests, contribute components and help or inquire in the forums. Conversely, the Mule community is a gated community.
Last, but not least; perhaps the most important part. Here is what Google Trends has to say about Mule ESB vs. Apache Camel. Note that I'm using the new semantic topics measurement for higher accuracy rather than the standard query keywords. That way we are not measuring the popularity of the animals (Mule vs Camel), but of the Software! Interpretation: Mule trended down heavily from 2007 until 2011, while Apache Camel trended up. Since 2011, Mule has plateaued, while Apache Camel keeps trending up healthily!
Technical evolution of Apache Camel
Just wanted to give you some functional metrics on the evolution of Apache Camel since 25th September 2010, when you originally asked the question. This was the source tree at that point in time.
Many, many technical improvements: Async Routing Engine, Message History, Circuit Breaker EIP, many many improvements and enhancements to EIPs like Aggregation, Splitting, Dynamic Routing, etc.
The ecosystem has grown to now also include Hawtio for monitoring and management, fabric8 for deployment, etc.
Since then more than 5500 tickets have been resolved including new features, improvements, bugs, etc.
And much, much more!
Final notes
Both products have evolved a lot over the last 5,25 years! However, due to the difference in licenses and the community nature of Mule ESB and Apache Camel, I don't think they are comparable any longer to one another.
Apache Camel is fully Open Source ❤️, while Mule ESB Community requires users to attribute Mulesoft and to publish the source code of the software that uses Mule. The Apache Software License is a business-friendly license: you are free to use Camel without attributions nor any other requirements. Truly free as in beer!
Hope this reflection upon the last years helps new viewers! :)
Disclaimer: I am a committer and PMC member at the Apache Camel project.
Apache Camel is a library that implements enterprise integration patterns (EIP). While it can use Spring as its IOC framework, it is not even dependent upon Spring, so it is completely platform independent. It is "just" a library. So you can run it any JVM environment, e.g. simple jvm, servlet, ejb, osgi. It does not bring with any of the benefits (or the overhead) of a container such Mule. It has, in my opinion, cleaner separation of concerns in this area.
Mule can also be embedded in different environments, but I think Mule has both the advantages and disadvantages of coupling their EIP library to their container. When you deploy Mule inside a servlet or ejb environment, do you really want to carry all of that baggage of the Mule container? I am not a Mule expert, and I think you can probably spend a relatively modest amount of effort and clean out some of the redundant capability. (Note this is not bad capability in all cases, it is just redundant if you are running embedded inside another container.)
Apache ServiceMix is an OSGI container that uses Camel to implement EIP as the basis of an ESB. Although ServiceMix historically started with its roots in JBI, it has moved away from JBI and has evolved into (IMO) a nice layered architecture combining best of breed Apache CXF, Camel, and ActiveMQ in an OSGI container. The main value here is not really ServiceMix and its JBI support, but the underlying OSGI container standard coupled to proven Apache transports like CXF for web services and ActiveMQ for JMS. OSGI is a mature standard that offers a container that addresses the same types of "DLL" hell that plagued Microsoft before the advent of .NET. While neither .NET nor OSGI solves the essential complexity of the underlying problem, they at least provide a means for addressing it. OSGI has other benefits as well, but from a product selection perspective the standards based container is primary, and its essential feature that Mule (and Java in general) does not address is dependency management.
Some important things to note in comparing Mule with Apache communities. Mule is like Redhat in the sense that although it is an open source license it is not really in my opinion an open community. Anyone can participate in Apache whereas MuleSoft owns the Mule community and the final roadmap. Second, although the Mule community is arguably pretty active, I think the Apache community is much larger (and naturally so since it is not a gated community). Both approaches have both plusses and minuses. One positive to the Apache approach is that there are multiple vendors for ESB's based on Camel, CXF, ActiveMQ, and OSGI. For example, Talend offers an ESB on the same core technologies without the ServiceMix JBI history. This has both plusses and minuses within the Apache community, but the real point is to highlight the difference between Apache and Mule. You won't find multilple vendors in the Mule community. So IMO an Apache ESB like Talend or ServiceMix is a broader and more inclusive, and ultimately competitive community than a closed community like Mule.
Camel is a mediation engine while Mule is a light-weight integration platform. The difference is that that Mule offers all the capabilities of an ESB including a container for deploying applications, REST and Web Services. Mule can be embedded in the same way Camel to allow application developers to embed there application code with their integration code. Both integrate tightly with Spring.
Mule does not use JBI for good reasons and now that the JBI spec has been disbanded (no working group, owned by Oracle who passed on the JBI spec originally) there is no good professional or technical reason to use JBI.
Claus, there are a number of mistakes in the Camel FAQ, unsurprisingly, none of them in our favour :)
the UMO model in Mule is no longer in Mule. We starting moving away from that model in Mule 2 and it has been completely changed in Mule 3. We now have a very simple Message Processor model which makes your statement about it redundant
Mule has had explicit type conversion for a few years now, this isn't a differentiator for Camel
Mule is licensed under the OSI approved CPAL 1.0 license. This is an open source license not a commercial one. Please update this ASAP
First you need to understand that Service Mix is like a container which can run Apache Camel code and Mule ESB is a separate product by itself
There could be a lot of differentiations that you can provide between ESB products.
You should know a few things before looking in the differentiation. They are
How the products is developed
Its licensing
Its support features
Open Source or not
If open source can the source be modified and used
and so on.
The above will be a best factors that you need to look into before you make a selection. The above is generic to most of the product selection and it needs special attention here as well.
The Secondary product difference will be specific to the tools and its domain.This is probable the answer you are looking for. Find the list that you need to introspect before making a selection.
Community support
Product stack
Extensibility in terms of modifying your own code
Learn-ability and Usability
Product support when bought as enterprise
This is probably a research that you need to do on your own to select the difference. Any ways there are many value adds that make the product suitable to your organizational rather than to say best in the market.
When it comes to Apache camel or Other ESB. The difference that will make are
The number of Transport
Apache Camel providing you the Variety of DSL over Mule and other are are that they do not have multiple DSL as in Camel.
Mule in its product stack contains API management and in house Cloud connectors where as Apache Camel is a framework when FUSE ESB is taken into account JBoss Stack provides a decent amount of other products that may compliment your selection.
发布评论
评论（7）
现在已经是 2016 年了，自最初提出问题以来发生了很多变化，所以我想为新观众重新审视这个问题。
从战略上讲，
Apache Camel一直忠于其根源，并且没有发展成为重量级或成熟的运行时平台。它是多功能且模块化的，并且可以运行：
Apache Camel 不断发展，每月都获得关注和活动，正如我从 OpenHub。用户群也在不断增加。
2012 年，红帽收购了 FuseSource，FuseSource 是 Apache Camel、ActiveMQ、ServiceMix 和 CXF 背后的主要推动者和开发者之一。一些提交者和 PMC 成员现在受雇于红帽，从事 Apache Camel 工作。
Mule ESB 提供其产品的两个版本：社区< /strong>（根据 CPAL 许可证免费）和企业（付费）。他们将其社区版本定义为：
=>这意味着您应该获取付费企业订阅以供生产使用。
事实上，Mule ESB 社区版是根据CPAL 许可证分发的。这意味着，如果您仍然决定使用此版本，Mule 要求：
每次启动或最初运行可执行文件和源代码或较大的作品时，最终用户用于访问此类涵盖代码（可能会包括在启动屏幕上的显示）（如果有）。 =>基本上，您需要宣传您用 Mule 构建的任何内容都可以在 Mule 上运行。
如果您的 Mule ESB 部署是通过网络访问的（它总是会这样，因为它是一个集成平台！），您还必须使您的部署的源可供访问它的任何人使用。
正如上面其他人提到的，Apache Camel 是一个完全开放的项目，由社区驱动，为社区服务。所有源代码都是公开的，并且鼓励每个人发送拉取请求、贡献组件以及在论坛中提供帮助或查询。相反，Mule 社区是一个封闭社区。< /p>
最后但并非最不重要的一点；也许是最重要的部分。 以下是 Google 趋势对 Mule ESB 与 Apache Camel 的评价。请注意，我使用新的语义主题测量来提高准确性，而不是使用标准查询关键字。这样我们就不会衡量动物（骡子与骆驼）的受欢迎程度，而是衡量软件的受欢迎程度！解读：从 2007 年到 2011 年，Mule 呈大幅下降趋势，而 Apache Camel 呈上升趋势。自 2011 年以来，Mule 已趋于稳定，而 Apache Camel 则持续健康发展！
Apache Camel 的技术演变
只是想向您提供一些自 2010 年 9 月 25 日您最初提出问题以来 Apache Camel 演变的功能指标。 这是当时的源代码树。
最后说明
在过去 5.25 年里，这两种产品都发生了很大的变化！然而，由于 Mule ESB 和 Apache Camel 的许可证和社区性质不同，我认为它们不再具有可比性。
Apache Camel 是完全开源的❤️，而 Mule ESB 社区则要求用户归属 Mulesoft 并发布使用 Mule 的软件的源代码。 Apache 软件许可证是一个商业友好许可证：您可以自由使用 Camel，无需归属或任何其他要求。真正像啤酒一样免费！
希望对过去几年的反思能够帮助新观众！ :)
免责声明：我是 Apache Camel 项目的提交者和 PMC 成员。
It is now 2016 and a lot has changed since the question was initially asked, so I'd like to revisit it for new viewers.
Strategically speaking
Apache Camel has stayed true to its roots and has not evolved into a heavyweight nor fully-fledged runtime platform. It is versatile and modular, and can run:
Apache Camel has continued to evolve and gain a traction and activity on a monthly basis, as portrayed by the graph under this point which I extracted from OpenHub. The userbase also keeps increasing.
In 2012, Red Hat acquired FuseSource, one of the main promoters and developers behind Apache Camel, ActiveMQ, ServiceMix and CXF. Several committers and PMC members are now employed by Red Hat to work on Apache Camel.
Mule ESB offers two versions of their product: Community (free under the CPAL license) and Enterprise (paid). They define their Community version as:
=> Meaning that you should acquire a paid Enterprise subscription for production usage.
In fact, Mule ESB Community Edition is distributed under the CPAL license. This means that if you still decide to use this version, Mule REQUIRES THAT:
Each time an Executable and Source Code or a Larger Work is launched or initially run, a prominent display of Mulesoft's Attribution Information must occur on the graphic user interface employed by the end user to access such Covered Code (which may include display on a splash screen), if any. => Basically you need to advertise that whatever you have built with Mule is running on Mule.
If your deployment of Mule ESB is accessed over the network (it always will, since it's an integration platform!), you must also make the Source of your deployment available to whoever is accessing it.
As someone else mentioned above, Apache Camel is a completely open project and driven by the community, for the community. All the source code is publicly available, and everybody is encouraged to send in pull requests, contribute components and help or inquire in the forums. Conversely, the Mule community is a gated community.
Last, but not least; perhaps the most important part. Here is what Google Trends has to say about Mule ESB vs. Apache Camel. Note that I'm using the new semantic topics measurement for higher accuracy rather than the standard query keywords. That way we are not measuring the popularity of the animals (Mule vs Camel), but of the Software! Interpretation: Mule trended down heavily from 2007 until 2011, while Apache Camel trended up. Since 2011, Mule has plateaued, while Apache Camel keeps trending up healthily!
Technical evolution of Apache Camel
Just wanted to give you some functional metrics on the evolution of Apache Camel since 25th September 2010, when you originally asked the question. This was the source tree at that point in time.
Final notes
Both products have evolved a lot over the last 5,25 years! However, due to the difference in licenses and the community nature of Mule ESB and Apache Camel, I don't think they are comparable any longer to one another.
Apache Camel is fully Open Source ❤️, while Mule ESB Community requires users to attribute Mulesoft and to publish the source code of the software that uses Mule. The Apache Software License is a business-friendly license: you are free to use Camel without attributions nor any other requirements. Truly free as in beer!
Hope this reflection upon the last years helps new viewers! :)
Disclaimer: I am a committer and PMC member at the Apache Camel project.
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 支持，而是与经过验证的 Apache 传输（例如用于 Web 服务的 CXF 和用于 JMS 的 ActiveMQ）相结合的底层 OSGI 容器标准。 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 社区中找不到多个供应商。因此，在我看来，像 Talend 或 ServiceMix 这样的 Apache ESB 是一个比 Mule 这样的封闭社区更广泛、更具包容性、最终具有竞争力的社区。
艾德·奥斯特
Apache Camel is a library that implements enterprise integration patterns (EIP). While it can use Spring as its IOC framework, it is not even dependent upon Spring, so it is completely platform independent. It is "just" a library. So you can run it any JVM environment, e.g. simple jvm, servlet, ejb, osgi. It does not bring with any of the benefits (or the overhead) of a container such Mule. It has, in my opinion, cleaner separation of concerns in this area.
Mule can also be embedded in different environments, but I think Mule has both the advantages and disadvantages of coupling their EIP library to their container. When you deploy Mule inside a servlet or ejb environment, do you really want to carry all of that baggage of the Mule container? I am not a Mule expert, and I think you can probably spend a relatively modest amount of effort and clean out some of the redundant capability. (Note this is not bad capability in all cases, it is just redundant if you are running embedded inside another container.)
Apache ServiceMix is an OSGI container that uses Camel to implement EIP as the basis of an ESB. Although ServiceMix historically started with its roots in JBI, it has moved away from JBI and has evolved into (IMO) a nice layered architecture combining best of breed Apache CXF, Camel, and ActiveMQ in an OSGI container. The main value here is not really ServiceMix and its JBI support, but the underlying OSGI container standard coupled to proven Apache transports like CXF for web services and ActiveMQ for JMS. OSGI is a mature standard that offers a container that addresses the same types of "DLL" hell that plagued Microsoft before the advent of .NET. While neither .NET nor OSGI solves the essential complexity of the underlying problem, they at least provide a means for addressing it. OSGI has other benefits as well, but from a product selection perspective the standards based container is primary, and its essential feature that Mule (and Java in general) does not address is dependency management.
Some important things to note in comparing Mule with Apache communities. Mule is like Redhat in the sense that although it is an open source license it is not really in my opinion an open community. Anyone can participate in Apache whereas MuleSoft owns the Mule community and the final roadmap. Second, although the Mule community is arguably pretty active, I think the Apache community is much larger (and naturally so since it is not a gated community). Both approaches have both plusses and minuses. One positive to the Apache approach is that there are multiple vendors for ESB's based on Camel, CXF, ActiveMQ, and OSGI. For example, Talend offers an ESB on the same core technologies without the ServiceMix JBI history. This has both plusses and minuses within the Apache community, but the real point is to highlight the difference between Apache and Mule. You won't find multilple vendors in the Mule community. So IMO an Apache ESB like Talend or ServiceMix is a broader and more inclusive, and ultimately competitive community than a closed community like Mule.
Ed Ost
我的博客文章准确回答了这个问题： http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel是一个轻量级集成框架，ServiceMix等是完整的ESB。
My blog post answers exactly this question: http://www.kai-waehner.de/blog/2011/06/02/when-to-use-apache-camel/ => Apache Camel is a lightweight integration framework, ServiceMix and so on are full ESBs.
Camel是一个中介引擎，而Mule是一个轻量级集成平台。不同之处在于，Mule 提供了 ESB 的所有功能，包括用于部署应用程序、REST 和 Web 服务的容器。 Mule 可以以与 Camel 相同的方式嵌入，以允许应用程序开发人员将应用程序代码与其集成代码一起嵌入其中。两者都与 Spring 紧密集成。
Mule 不使用 JBI 有充分的理由< /a> 现在 JBI 规范已经解散（没有工作组，由最初传递 JBI 规范的 Oracle 拥有），没有充分的专业或技术理由来使用 JBI。
Camel is a mediation engine while Mule is a light-weight integration platform. The difference is that that Mule offers all the capabilities of an ESB including a container for deploying applications, REST and Web Services. Mule can be embedded in the same way Camel to allow application developers to embed there application code with their integration code. Both integrate tightly with Spring.
Mule does not use JBI for good reasons and now that the JBI spec has been disbanded (no working group, owned by Oracle who passed on the JBI spec originally) there is no good professional or technical reason to use JBI.
Apache Camel 上有一些常见问题解答条目，这些条目对此提供了一些启示
http://camel.apache.org/faq
以及 Apache Camel 上的链接集合
http://camel.apache.org/articles.html
有一些链接供社区中的人们使用讨论并将 Camel 与其他项目进行比较。
There are some FAQ entries at Apache Camel which shed some light on this
http://camel.apache.org/faq
And the link collection at Apache Camel
http://camel.apache.org/articles.html
Have some links where people in the community talks and compare Camel to other projects.
Claus，Camel FAQ 中有很多错误，毫不奇怪，没有一个对我们有利:)
Claus, there are a number of mistakes in the Camel FAQ, unsurprisingly, none of them in our favour :)
首先，您需要了解 Service Mix 就像一个可以运行 Apache Camel 代码的容器，而 Mule ESB 本身是一个单独的产品。
您可以在 ESB 产品之间提供很多差异化。
在查看差异化之前，您应该了解一些事情。它们是
等等。
以上将是您在做出选择之前需要考虑的最佳因素。以上是大多数产品选择的通用内容，这里也需要特别注意。
次要产品差异将特定于工具及其领域。这可能是您正在寻找的答案。在做出选择之前找到您需要反思的列表。
这可能是您需要自己进行的研究以选择差异。无论如何，有许多附加值可以使产品适合您的组织，而不是说市场上最好的。
当谈到 Apache Camel 或其他 ESB 时。不同之处在于
First you need to understand that Service Mix is like a container which can run Apache Camel code and Mule ESB is a separate product by itself
There could be a lot of differentiations that you can provide between ESB products.
You should know a few things before looking in the differentiation. They are
and so on.
The above will be a best factors that you need to look into before you make a selection. The above is generic to most of the product selection and it needs special attention here as well.
The Secondary product difference will be specific to the tools and its domain.This is probable the answer you are looking for. Find the list that you need to introspect before making a selection.
This is probably a research that you need to do on your own to select the difference. Any ways there are many value adds that make the product suitable to your organizational rather than to say best in the market.
When it comes to Apache camel or Other ESB. The difference that will make are