问题
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?
回答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
回答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:
- Embedded in any kind of Java container (servlet container, application server, Spring Boot).
- Standalone as a Java process.
- 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.
回答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.
回答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.
回答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.
回答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
回答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
- 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.
来源：https://stackoverflow.com/questions/3792519/apache-camel-and-other-esb-products