Thoughts about ServiceMix
I’ve been involved in ServiceMix, the Open Source ESB, nearly since its inception. ServiceMix was started by James Strachan and Rob Davies in May 2005 and the 1.0 version was released in August 2005. I joined LogicBlaze in October 2005 (leaving Mule behind, as I was a committer on Mule) to work on the 2.x releases (2.0 was released in November 2005) and then on the 3.x after the move from Codehaus to the Apache Software Foundation (3.0 was released in May 2007) and the 4.x versions based on OSGi (4.0 was released in March 2009). Even though I’m now focusing more on the OSGi side now (being the VP of Karaf), I’ve done my share of work on ServiceMix (I’m still the first committer in terms of number of commits according to http://svnsearch.org/svnsearch/repos/ASF/search?path=/servicemix) and I’ve been the VP of ServiceMix at the ASF for a few years.
ServiceMix started as a very lightweight implementation of JBI spec. The 2.x version brought much more JBI compliance and the 3.x has seen migration from the lightweight component to fully fledge JBI components and full JBI compliance. In doing so, ServiceMix became a container, as required per the JBI spec and over-time lost a bit of its lightweight-ness. That’s exactly at the same time that Camel was created as a routing library, based on the experience with ServiceMix. After the 3.0 was released it became apparent that the JBI spec was way too limited with respect to the container (classloaders and even the packaging are a real pain in JBI), so we started experimenting with OSGi at that time and that led the path to ServiceMix 4.x and the Karaf project, which started as ServiceMix Kernel.
In 2007, the SCA spec came out, backed by IBM and Oracle, and during a few months, there were a lot of heated debate around JBI versus SCA. It eventually settled a bit when people started understanding that those specs were not really competing, as JBI was targeted around components interoperability while SCA target was application development and could be built on top of JBI. However, JBI was not backed by the big vendors (only really SUN), and when the spec lead for JBI 2.0 left SUN with no replacement, it became clear that the JBI spec was dead.
Another point is that over time, Camel grew to become a top level project and be the very successful project we know, and for some time, we did not really know what to do with the overlap between Camel components and ServiceMix components.
Since JBI 2.0 doesn't appear to be going anywhere we realised we should focus on Camel for the EIP support and connectivity and that OSGi was a better long term standard to represent the registry of endpoints, so we've refactored ServiceMix NMR to be more lightweight, based on the lightweight OSGi container and based around the OSGi registry; with JBI support an optional legacy connector. So we now have a simple lightweight approach to providing a middleware agnostic registry of endpoints with full hot-deploy and supporting powerful class loader versioning schemes via the OSGi registry.
Long live ServiceMix, Camel and OSGi!
ServiceMix started as a very lightweight implementation of JBI spec. The 2.x version brought much more JBI compliance and the 3.x has seen migration from the lightweight component to fully fledge JBI components and full JBI compliance. In doing so, ServiceMix became a container, as required per the JBI spec and over-time lost a bit of its lightweight-ness. That’s exactly at the same time that Camel was created as a routing library, based on the experience with ServiceMix. After the 3.0 was released it became apparent that the JBI spec was way too limited with respect to the container (classloaders and even the packaging are a real pain in JBI), so we started experimenting with OSGi at that time and that led the path to ServiceMix 4.x and the Karaf project, which started as ServiceMix Kernel.
In 2007, the SCA spec came out, backed by IBM and Oracle, and during a few months, there were a lot of heated debate around JBI versus SCA. It eventually settled a bit when people started understanding that those specs were not really competing, as JBI was targeted around components interoperability while SCA target was application development and could be built on top of JBI. However, JBI was not backed by the big vendors (only really SUN), and when the spec lead for JBI 2.0 left SUN with no replacement, it became clear that the JBI spec was dead.
Another point is that over time, Camel grew to become a top level project and be the very successful project we know, and for some time, we did not really know what to do with the overlap between Camel components and ServiceMix components.
Since JBI 2.0 doesn't appear to be going anywhere we realised we should focus on Camel for the EIP support and connectivity and that OSGi was a better long term standard to represent the registry of endpoints, so we've refactored ServiceMix NMR to be more lightweight, based on the lightweight OSGi container and based around the OSGi registry; with JBI support an optional legacy connector. So we now have a simple lightweight approach to providing a middleware agnostic registry of endpoints with full hot-deploy and supporting powerful class loader versioning schemes via the OSGi registry.
Long live ServiceMix, Camel and OSGi!
Comments
Now Karaf + Camel is roughly what ServiceMix is now about, though the NMR gives a real bus to interconnect your camel routes together, a registry backed by the OSGi registry, security checks, a way to bridge several versions of Camel, etc...
Also remember, Karaf was the ServiceMix Kernel at first. You may also need some OSGi bundles provided by ServiceMix (even Camel actually use those) and you may also need ServiceMix specs in order to make some JAXB or JAXWS specs work in OSGi. So you reuse most of what has been developed inside ServiceMix actually.
Now, even if not using the NMR, ServiceMix provides a tested container where you can deploy your Camel routes because we do ensure all the components actually work in the container.
Another comparison could be the following: why use Karaf when I can just use Felix/Equinox and only the bundles I need? I would simply advise to avoid re-inventing the wheel and solving the problems we already hit and solved in ServiceMix.
As I outlined, I'd like ServiceMix to become more lightweight as it used to be, meaning we may remove the default installation of the JBI layer and JBI components in some distributions of ServiceMix and you'd mostly have a well tested container based on Karaf and Camel.
Indeed, XA transaction inside ServiceMix is supported (apparently we have not finalized tests) with JBI.
How are you managing XA transaction with Karaf + Camel?
- Migrate on 4? That means to throw everything away and dive into OSGI.
- Stick to dying 3? No effort is currently put to fix bugs in 3 so one has to maintain his own version of ServiceMix.
- Will history with 3 repeat with 4? How soon 4 will be abandoned in favor of completely different 5? Isnt it better to use Camel in DM?
as you wrote Camel and ServiceMix Overlaps.
We are going to start a SOA open source project. We are focusing on business processes and ESB.
BPEL good for business process but BPMN approach of Avtiviti could be better.
We are evaluating Actitivi as BPM Engine and ServiceMix as ESB (Or Camel?). I would like to know if there is an integration between Activiti and Camel or Activiti and ServiceMix.
What do you suggest?
Thanks.