However they do this by employing different styles and approaches. The broad distinctions between Camel and the 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 :).
