Thanks...I still don't fully understand though. FYI I do plan to use ServiceMix and Camel inside of it, not thinking of using only Camel.
Looking at it, it seems I have an option of doing everything inside Camel (which seems simpler) or do some parts inside Camel and others outside of Camel (NMR, CXF, etc) - which seems more complex. I can't understand what the benefits of the more complex option are, and why I would use it. 2) You use CXF as an example. Camel also has a CXF component. How is it better to use "Camel can use a NMR endpoint provided by CXF." which I understand to be CXF => NMR => Camel than just utilize the Camel CXF component (not going to NMR at any point)? 3) How is the solution that uses NMR more configurable / better than the one that just uses Camel? I understand it decouples the "IN" and "OUT" messages from each other, but in this example I can change both endpoints just as easily in both examples. - I also need the integration processing to be reliable, so that if ServiceMix crashes during the processing of the message at any point, the message is not lost and processing continues next time. Does this change the design, and the reasonings behind doing everything inside Camel or splitting work between Camel and rest of ServiceMix? On Mon, Feb 28, 2011 at 11:46 AM, Jean-Baptiste Onofré <[email protected]> wrote: > Hi Janne, > > Some comments > > 1/ ServiceMix is an integration platform. It embeds ActiveMQ, CXF, Camel, > ODE, NMR to provide a complete Enterprise ESB powered by OSGi. > 2/ NMR is a complete messaging platform. It allows you to decouple the > different integration tiers. For instance, Camel can use a NMR endpoint > provided by CXF. It introduces a new abstraction layer to allow you plug and > play of endpoints, these endpoints could be provided by Camel, CXF, or your > own implementation. Please, don't think that NMR == JBI, it's not the case, > JBI is only an endpoint implementation on top of the NMR. > More over, the NMR provides additional stuff such as a complete Event API, > an Audit layer, etc. > You can take a look on examples/cxf-camel-nmr to see how it works. > 3/ Your scenario could be implemented directly using Camel (using camel-jms > endpoint). Your Camel route could look like: > <from uri="jms:"/>><to uri="jms:"/> > You can also use the NMR to decoupled in two routes: > <from uri"jms:"/><to uri="nmr:"/> > <from uri="nmr:"/><to uri="jms:"/> > It allows you to be able to totally change the second route without changing > the first one. > > Hope it helps. > Regards > JB > > On 02/28/2011 10:38 AM, janne postilista wrote: >> >> The roles of ServiceMix 4 and Camel (and others) are a bit confusing to >> me. >> >> Take the ServiceMix architecture pictured as: >> >> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html >> (could not find similar pic in servicemix.apache.org) >> >> Lets say I'm building an integration system which reads from an JMS >> queue A, does some processing to the messages, and writes them to >> another queue B. >> >> Wouldn't I just implement all of this inside Camel? Camel has features >> for routing and processing the messages, and components for reading / >> writing all kinds of protocols (JMS/file/ftp/...). Is this a typical >> way of using ServiceMix? >> >> In which situations it would be better to use the parts outside of >> Camel, pictured in >> >> http://fusesource.com/docs/esb/4.3.1/esb_getting_started/ESBGetStartedArchIntro.html >> - NMR, JMS, JAX-WS? >
