Apache Camel and other ESB products

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.

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