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.
