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 <[EMAIL PROTECTED]>: > > 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
