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/
