activemq + camel VS mule - what are the features that are missing in Camel?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

activemq + camel VS mule - what are the features that are missing in Camel?

volenin
Hi,

I was reading quite a bit lately on both Mule 2.0 and Camel and trying to
pinpoint the major differences / advantages / disadvantages at this point.
The FAQ doc at
http://activemq.apache.org/camel/how-does-camel-compare-to-mule.html as well
as at http://activemq.apache.org/camel/is-camel-an-esb.html mention that
Camel (+ ActiveMQ) can be considered ESB. On the other hand, I recall there
was some article by James Strachan somewhere, which mentions that Camel is
primarily the routing solution, while Mule (and ServiceMix) is more fully
integrated ESB kind of thing that provides all kind of adapters and
connectivity.

I'm not in for the name calling, whether Camel is ESB or not... What I'm
trying to figure out is this: is there anything in Mule that is currently
missing in Camel, beyond some transport adapters? It looks like the primary
goal for both of these solutions was to implement EIP (I guess Camel project
had explicit goal like that, while Mule project just naturally converged to
it). Mule message handling is 100% SEDA based from what could be deduced
from the documentation, while Camel seems to provide SEDA handling though
the specific channel component. Are there any drawbacks / benefits beyond
additional flexibility (and complexity)?

So far I couldn't find anything from routing and message handling
prospective what Mule can and Camel can't do. Am I missing smth? What are
the most frequent use cases for both of these products, if there is anyone
here who is using both Camel and Mule?.. Thanks,

Vlad
Reply | Threaded
Open this post in threaded view
|

Re: activemq + camel VS mule - what are the features that are missing in Camel?

Charles Moulliard
To be honest, Apache Camel is a lightweight ESB comparable to Mule because they are both based on Spring + POJO and they can run in standalone mode or embedded in an OSGI server, application server. The difference between CAMEL/MULE and the Petals/OPEN-ESB/ServiceMix approach is that they can send Objects (=POJO) through messages to the endpoints of the bus. The other family of ESB is based on JBI specification where the messages send over the bus are XML normalized messages. So, everetime that you have to communicate between beans/pojo objects you have to marshall/unmarshall XMK.
If you embed Camel in Servicemix is a matter of taste. If you don't need to send normalized messages over the bus, this is not required at all.

From my point of view, Camel has more components than Mule now (Spring integration, ....) but they can sometimes differ in term of attributes available.

Mule is not at all based on Enterprise Integration Pattern and implementing a routing in Mule is harder than in Camel. Camel is based on EIP, propose XML configuration files implementing the routing (except the Dead letter channel) or DSL language. Camel is the most easiest solution to use. You don't need to create a lot of XML config files with inbound/outbound stuff like you have to do in Mule. The routing in Mule is not so intuitive and not appear directly in the XML or DSL language.





volenin wrote
Hi,

I was reading quite a bit lately on both Mule 2.0 and Camel and trying to
pinpoint the major differences / advantages / disadvantages at this point.
The FAQ doc at
http://activemq.apache.org/camel/how-does-camel-compare-to-mule.html as well
as at http://activemq.apache.org/camel/is-camel-an-esb.html mention that
Camel (+ ActiveMQ) can be considered ESB. On the other hand, I recall there
was some article by James Strachan somewhere, which mentions that Camel is
primarily the routing solution, while Mule (and ServiceMix) is more fully
integrated ESB kind of thing that provides all kind of adapters and
connectivity.

I'm not in for the name calling, whether Camel is ESB or not... What I'm
trying to figure out is this: is there anything in Mule that is currently
missing in Camel, beyond some transport adapters? It looks like the primary
goal for both of these solutions was to implement EIP (I guess Camel project
had explicit goal like that, while Mule project just naturally converged to
it). Mule message handling is 100% SEDA based from what could be deduced
from the documentation, while Camel seems to provide SEDA handling though
the specific channel component. Are there any drawbacks / benefits beyond
additional flexibility (and complexity)?

So far I couldn't find anything from routing and message handling
prospective what Mule can and Camel can't do. Am I missing smth? What are
the most frequent use cases for both of these products, if there is anyone
here who is using both Camel and Mule?.. Thanks,

Vlad
Apache Committer / Sr. Pr. Consultant at FuseSource.com
Email: [hidden email]
Twitter : @cmoulliard, @fusenews
Blog : http://cmoulliard.blogspot.com
Reply | Threaded
Open this post in threaded view
|

Re: activemq + camel VS mule - what are the features that are missing in Camel?

jstrachan
Great reply - totally agree :)

One of the big differences with Camel to Mule / Spring Integration is
that underneath the covers in camel there is an AST of the EIP model;
so that tooling, visualisations and so forth can know what the routing
really looks like. Plus in Camel you can create that routing
definition using Java / Scala / XML DSLs (or more to come later like
groovy/ruby etc).


2008/6/26 cmoulliard <[hidden email]>:

>
> To be honest, Apache Camel is a lightweight ESB comparable to Mule because
> they are both based on Spring + POJO and they can run in standalone mode or
> embedded in an OSGI server, application server. The difference between
> CAMEL/MULE and the Petals/OPEN-ESB/ServiceMix approach is that they can send
> Objects (=POJO) through messages to the endpoints of the bus. The other
> family of ESB is based on JBI specification where the messages send over the
> bus are XML normalized messages. So, everetime that you have to communicate
> between beans/pojo objects you have to marshall/unmarshall XMK.
> If you embed Camel in Servicemix is a matter of taste. If you don't need to
> send normalized messages over the bus, this is not required at all.
>
> From my point of view, Camel has more components than Mule now (Spring
> integration, ....) but they can sometimes differ in term of attributes
> available.
>
> Mule is not at all based on Enterprise Integration Pattern and implementing
> a routing in Mule is harder than in Camel. Camel is based on EIP, propose
> XML configuration files implementing the routing (except the Dead letter
> channel) or DSL language. Camel is the most easiest solution to use. You
> don't need to create a lot of XML config files with inbound/outbound stuff
> like you have to do in Mule. The routing in Mule is not so intuitive and not
> appear directly in the XML or DSL language.
>
>
>
>
>
>
> volenin wrote:
>>
>> Hi,
>>
>> I was reading quite a bit lately on both Mule 2.0 and Camel and trying to
>> pinpoint the major differences / advantages / disadvantages at this point.
>> The FAQ doc at
>> http://activemq.apache.org/camel/how-does-camel-compare-to-mule.html as
>> well
>> as at http://activemq.apache.org/camel/is-camel-an-esb.html mention that
>> Camel (+ ActiveMQ) can be considered ESB. On the other hand, I recall
>> there
>> was some article by James Strachan somewhere, which mentions that Camel is
>> primarily the routing solution, while Mule (and ServiceMix) is more fully
>> integrated ESB kind of thing that provides all kind of adapters and
>> connectivity.
>>
>> I'm not in for the name calling, whether Camel is ESB or not... What I'm
>> trying to figure out is this: is there anything in Mule that is currently
>> missing in Camel, beyond some transport adapters? It looks like the
>> primary
>> goal for both of these solutions was to implement EIP (I guess Camel
>> project
>> had explicit goal like that, while Mule project just naturally converged
>> to
>> it). Mule message handling is 100% SEDA based from what could be deduced
>> from the documentation, while Camel seems to provide SEDA handling though
>> the specific channel component. Are there any drawbacks / benefits beyond
>> additional flexibility (and complexity)?
>>
>> So far I couldn't find anything from routing and message handling
>> prospective what Mule can and Camel can't do. Am I missing smth? What are
>> the most frequent use cases for both of these products, if there is anyone
>> here who is using both Camel and Mule?.. Thanks,
>>
>> Vlad
>>
>>
>
> --
> View this message in context: http://www.nabble.com/activemq-%2B-camel-VS-mule---what-are-the-features-that-are-missing-in-Camel--tp18102806s22882p18127835.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>



--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com