views:

159

answers:

5

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?

A: 

I answered this some time ago here - http://stackoverflow.com/questions/2705043/java-messaging-difference-between-activemq-mule-servicemix-and-camel/2708298#2708298 .

If you want more verbose answer don't hesitate to ask.

Henryk Konsek
Mule/ServiceMix are ESB products, while Camel is an implementation of EAI. So what is the difference?
El Gusto
"It also provides many infrastructural features not available in Camel (like services OSGI bundle support). SM makes heavy use of Camel." SM adds deployment and infrastructural layer to the Camel Routing Engine. Bare Camel Context embedded into the Tomcat may not be sufficient for complex system integration with 99.9999% uptime requirements.
Henryk Konsek
JBI compliance may also be an issue.
Henryk Konsek
Mule isn't JBI compliance but I doesn't look like an issue.
El Gusto
Not for you, but it may be for business people who hire you.
Henryk Konsek
A: 

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 Ibsen
+1  A: 

If you compare Camel and Mule, you'll see that they are built on similar concepts (enterprise integration patterns, possibility to use SEDA queues...).

A key differentiator is the number of available transports (Camel vs. Mule). Moreover, Mule can run embedded (like Camel) or as a standalone integration broker, with support for application hot deployment. On top of that, Mule's Enterprise Edition offers an advanced management console that can make a difference in production.

David Dossot
David, there is definitely not a key differentiator in the number of transports available. You just had to continue clicking on the components link and you will get to to 70+ or more transports offer out of the box with Camel.
Claus Ibsen
Claus, thanks for the precision. I notice the Camel transport page has been reviewed to clearly show the numerous transports it supports. I therefore stand corrected and retract the number of available transports as a differentiator.
David Dossot
Thanks David. That transports page was really not exposed in the documentation. People go to the components page normally. Anyway you brought this to our attentions. Both Camel and Mule have a lot of transports out of the box. And both continue to add new components in new releases.
Claus Ibsen
A: 

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.

Ross Mason
+1  A: 

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
Ross Mason
I updated the FAQ to state its based on Mule 1.x/2.x. This was the time when James wrote the FAQ entry.
Claus Ibsen