Apache的骆驼和其他ESB产品

Question

嘿，结果 如果我们有Apache的骆驼为什么要使用其他解决方案，比如Apache ServiceMix的和Mule？点击 有什么Apache的骆驼不能做比较，这些产品？点击 当使用骡/ ServiceMix的以及何时使用骆驼？

Answer 1

Apache的骆驼是一个库，器具的企业集成模式（EIP）。虽然可以使用Spring作为IOC框架，它甚至不是依赖于春天，所以它是完全独立于平台。这是“只是”一个库。所以，你可以运行任何JVM的环境中，例如简单的JVM，servlet中，EJB，OSGi的。它不与任何容器，例如骡子的好处（或开销）带来的。它，我认为，在这一领域的关注清洁器分离。

骡还可以被嵌入在不同的环境中，但我认为骡同时具有的优点和它们的EIP库耦合到它们的容器的缺点。当你部署骡子servlet或EJB环境里面，你真的要进行所有的骡子容器的那个行李？我不是骡子专家，我想你大概可以花的功夫比较适量的干净一些冗余能力。 （注意，这是不是在所有情况下不好的能力，如果你正在运行嵌入到另一个容器内它仅仅是多余的。）

的Apache ServiceMix的是使用骆驼实施EIP作为ESB的基础OSGi容器。虽然ServiceMix的历史，其在JBI根开始，它已经从JBI搬走，并已演变成（IMO）一个很好的分层结构结合同类最佳的Apache CXF，骆驼，和的ActiveMQ在OSGi容器中。这里的主要价值是不是真正的ServiceMix和JBI支持，但潜在的OSGI容器的标准的耦合到成熟的Apache运输喜欢CXF的Web服务和ActiveMQ的JMS的。 OSGi是一个成熟的标准，提供了一个容器地址相同类型的.NET出现之前困扰微软“DLL”地狱。虽然没有.NET也不OSGI解决潜在的问题的本质复杂性，它们至少提供解决它的方法。 OSGI具有其他好处，但是从产品选择角度的标准基于容器是主要的，其基本特征在于骡（和Java一般）不地址是依赖管理。

要注意的一些重要的事情在骡子和Apache社区比较。骡子就像是在这个意义上说红帽虽然它是一个开放源码许可它是不是真的在我看来，一个开放的社会。任何人都可以参加的Apache，而MuleSoft拥有骡子社区和最终路线图。其次，虽然骡社区可以说是相当积极的，我认为Apache社区大得多（自然如此，因为它不是一个封闭社区）。这两种方法都同时具有加分和短处。一个积极的到Apache的做法是，有基于骆驼，CXF，ActiveMQ的，和OSGI ESB的多个供应商。例如，上了Talend没有ServiceMix的JBI历史相同的核心技术，提供了一个ESB。这既有加分和劣势Apache社区内，但真正的问题是要突出Apache和骡子之间的差异。你不会找到在骡社区multilple供应商。所以IMO一个Apache ESB像了Talend或ServiceMix的是更广泛和更包容，最终有竞争力的社区比封闭的社区等骡。

版Ost的

Answer 2

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:

  1. Embedded in any kind of Java container (servlet container, application server, Spring Boot).
  2. Standalone as a Java process.
  3. Inside an OSGi environment (Apache Karaf).

• 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.

• Back then, Camel had 88 components, it now has 220 components including integrations with Facebook, Twitter, Salesforce, Apache Ignite, Apache Cassandra, AWS, Apache Kafka, MongoDB, Apache Spark etc.
• 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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

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

1. How the products is developed
2. Its licensing
3. Its support features
4. Open Source or not
5. 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.

1. Community support
2. Product stack
3. Extensibility in terms of modifying your own code
4. Learn-ability and Usability
5. 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

1. The number of Transport
2. Apache Camel providing you the Variety of DSL over Mule and other are are that they do not have multiple DSL as in Camel.
3. 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.