Apache Camel and other ESB products

Question

Hey,
If we have Apache Camel why to use other solutions like Apache ServiceMix and Mule?
Is there something Apache Camel can't do comparing to these products?
When to use Mule/ServiceMix and when to use Camel?

Solution 1

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

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

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

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

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

View more solutions

Comments

[Claus Ibsen]

I updated the FAQ to state its based on Mule 1.x/2.x. This was the time when James wrote the FAQ entry.

[Devs love ZenUML]

Camel works well with Spring, but does not integrate tighly with Spring.

[raulk]

Camel doesn't use – and has never used – JBI.

[Claus Ibsen]

I posted a blog post with my additional comments to Raul's excellent answer with some additional key differentiator (IMHO) between Camel and Mule - davsclaus.com/2016/01/apache-camel-and-other-esb-products.ht‌​ml

[Souciance Eqdam Rashti]

Thanks Raul for the update. I read Claus's blog first and put a comment and will raise a question with you here, don't you think it would be better to compare commercial implementations of Apache Camel with a runtime such as Talend or JBossFuse or similar with Anypoint from Mule? Otherwise like mentioned Camel is open source and Mule is about money so already there you got differences which has effects how the products evolve.

[raulk]

The thing is that I'm comparing projects, not products. The fact is that Mule is both the project and the product, so they're impossible to separate. In fact, the fair thing would be to compare Mule vs. (Apache Camel + JBoss Fuse + Talend ESB), which would yield even higher metrics for the Camel ecosystem! But I didn't want to push the analysis that far because the bulk of Camel users are vanilla Apache Camel users anyway, according to my data. Hope that makes sense.

[Souciance Eqdam Rashti]

That is true, but what I mean is, most enterprises who use Mule, use the enterprise edition, and that comes with a runtime, development and monitoring environment etc. Its basically a complete package, hence probably more reasonable to compare JBoss or Talend to Mule and do a feature by feature comparison. Openness and community contribution is important but off course not the deciding factors when selecting your integration layer.