Hi, I will check with Guillaume/Claus as to the prpoper place wher I could put a concise wiki entry.
I will also try to write a blog article on my blog site capturing this information. I am glad you liked it. Cheers, Ashwin... ==================== TheWinch wrote: > > 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/ >> >> >> > > ----- --- 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/ -- View this message in context: http://www.nabble.com/JBI-performance-tp21615804p24727311.html Sent from the ServiceMix - User mailing list archive at Nabble.com.
