Hello, I agree with vincent. And could you please explain a bit more what you said about smx4 & OSGI? You mean the problem you mention a few posts ago about bridging with camel disappear with smx 4? How is that?
Regards, Vivian -----Message d'origine----- De : Vincent GIRARDREYDET [mailto:[email protected]] Envoyé : vendredi 24 juillet 2009 09:11 À : [email protected] Objet : Re: JBI performance Ashwin, Is there a way you could put this on a wiki page in the servicemix wiki ? I find your explanations very clear and in few sentences you have explained me everything I had'nt understood before about the Camel vs ServiceMix difference. I guess this might be usefull to other people as well :-). Vincent Ashwin Karpe a écrit : > Hi, > > Camel and Servicemix are both fundamentally about applying Enterprise > Integration patterns to solve complex integration problems across > different technology sets. > > However, they do this by employing different styles and approaches. > The broad distinctions between Camel and Servicemix JBI technology > stack, in my view, are the following > - Camel is standardized via DSL (Domain Specific Language), > Servicemix on the other hand is an implementation of the JBI standard > - Both use message exchanges internally to move payloads > between endpoints using routes (Camel) and workflows (JBI). However, > in Camel, a MessageExchange is an Interface which is implemented by > different technology sets in their own way i.e HTTP Exchange, FTP > Exchange etc and employs type conversion to normalize data between > these message exchanges. In Servicemix, a Message Exchange is a > standardized Data structure with XML as its message payload. > - Messages in Camel may be of any type (binary, text, > serialized object etc). Messages in Servicemix are XML only. > - Camel utilizes URI's to express endpoints, Servicemix uses > the WSDL conventions (ServiceEndpointReference) to express endpoints. > - Camel has a broader palette due to a simpler/more efficient > and expressive way of wiring endpoints using routes. It is more easily > embeddable in traditional Java Apps and can be run from a command line. > Servicemix on the other hand is fundamentally based on a framework > (JBI) and its services/endpoints are deployment in a JBI/OSGi based container. > - The core JBI framework provides its endpoints key > infrastructure services/facilities out of the box (location > transarency, mediated messaging via NMR) and is more suited for > viewing as a traditional ESB. Camel is more suited for being viewed as > an easy to use, yet sophisticated piece of DSL based integration technology. > > BTW, Servicemix 4 (OSGi) blends/brings together both these > technologies beautifully. Servicemix-Camel and Camel can seamlessly > coexist and provide seamless navigation between JBI and Camel routes. > > I like both for their own quirks, elegance & oddities. To each his > own, I guess :). > > Cheers, > > Ashwin... > > > boday wrote: > >> Ashwin... >> >> So you are basically saying that in high-volume scenarios, Camel >> shouldn't use JBI components because there is a higher overhead >> associated with these requests? I'm seeing similar performance >> issues using Camel and am tempted to move all my JBI services into >> Camel components to eliminate as much overhead as possible. >> >> If I do this, then why do I need SMX at all. Camel supports all the >> binding components (activemq, http, file, etc) that SMX does and >> seems to be add more flexibility with routing and exception handling. >> >> What is SMX providing otherwise? I'm starting to feel that Camel and >> SMX are competing technologies that happen to work together (using >> servicemix-camel binding). Can someone please elaborate on why I >> need SMX if Camel components seem to do everything... >> >> thanks in advance... >> >> >> Ashwin Karpe wrote: >> >>> Hi, >>> >>> Based on your example, the following will happen in JBI. >>> >>> 1> Camel SA1 invoking the JBI service myService will cause the >>> following additional work to take place.It will cause the running >>> thread in the servicemix-camel component to create an In-only >>> Message exchange, copy the message from the processor to the >>> exchange. The exchange will be sent to the NMR to locate and forward to >>> myService. >>> 2> Now myService though in another SA is also a servicemix-camel >>> endpoint registered with the NMR and will cause the exchange to be >>> picked up by another servicemix-camel thread and processed. The >>> payload will be pulled out of the JBI Message exchange and moved >>> into a Camel Exchange that is forwarded to the second processor. The >>> JBI Message exchange is now set to Done and pushed back and sent to >>> the original thread for >>> Camel-SA1 for further processing and cleanup (due to JBI MEP >>> processing rules). >>> 3> The exchnage cleanup has to be done by the servicemix container >>> after the servicemix-camel thread SA1 does nothing further with the >>> exchange. >>> >>> The trouble you run into when it is all running in the same >>> servicemix-camel container is that the code becomes re-entrant, more >>> and more time is spent in exchange creation and management within >>> servicemix-camel, exchanges start to pile up pretty quickly, thereby >>> driving down the overall processing speed. Also, this activity chews >>> up threads pretty quickly in a high volume scenario. >>> >>> Note that this does not happen in the pure JMS situation. The >>> servicemix-camel component does not have to create any fresh JBI >>> exchanges and manage them since it has no NMR involved. The camel >>> routing scenario can entirely executed in a running thread that can >>> grab a message from the Broker managing the Topic, process and and >>> send it to another Topic. Another thread then picks up from the >>> second Topic and processes the message. There is no need to create >>> and manage JBI exchanges. I guess the difference is the difference >>> between a routing and a bridging scenario. Hence the much better >>> performance. >>> >>> Hope this helps. The only thing that surprised me was how much the >>> cost differential was. You might try to increase the number of >>> threads for the Camel component via configuration >>> (servicemix.properties in the conf >>> directory) and see if that makes a difference. I bet increasing the >>> thread pool will improve performance, however the performance of the >>> pure-JMS solution should improve as well :). >>> >>> Cheers, >>> >>> Ashwin... >>> >>> >>> >> > > > ----- > --- > Ashwin Karpe, Principal Consultant, PS - Opensource Center of > Competence Progress Software Corporation > 14 Oak Park Drive > Bedford, MA 01730 > --- > +1-972-304-9084 (Office) > +1-972-971-1700 (Mobile) > ---- > Blog: http://opensourceknowledge.blogspot.com/ > > >
