I’ve been recently, with Jean-Michel BEA, to an event organized by FUSE/progress software (fusesource starting from the beginning of the week) which propose enterprise support around some apache technologies. We work in FastConnect on various ESB platform and ServiceMix is one of them.
In ServiceMix 3.x everything relied on the JBI specification. This has changed for good in ServiceMix 4. Indeed the JBI specification implies many constraint (internal format of messages must be XML, services have SOAP interfaces etc…). This creates constraints on both performance and usability in many situations.
On top of the JBI facilities to define services and connections, ServiceMix uses Apache Camel for routing. ServiceMix 3.x versions created constraints on the product learning curve as you had to know the JBI specifications/configurations, Apache Camel and understand how to configure all this into ServiceMix.
With ServiceMix 4 you can still use JBI and Camel for routing but the new point is that the preferred way to create a new ServiceMix 4 application will be to just use Camel. Configuration as pure Camel is easy and you get rid of the Xml format constraint solving your usability and performance issues (of course if your working with Xml and SOAP you can still do it).
The question we can point out is now:
– If JBI is recognized as a wrong standard and kind of a failure what is the point of ServiceMix now ?
Let me explain, if we use Camel configuration only, why should we use ServiceMix and not just Apache Camel ? Such a new way to define things point more Camel as the ESB and ServiceMix as the ESB « preferred container ». Well people told me that using the internal bus (NMR) is great to integrate with existing JBI (that’s for sure) and potentially with BPM (Apache Agila etc…) when BPM server/process is used in the same VM as ServiceMix.
So what I understood from all this and my vision of the overall tools
– If you have existing JBI and you want to move smoothly to a more Camel based application then yes ServiceMix4 makes sense.
– If you are starting your ESB adoption from scratch on top of Apache/FUSE technologies then I guess you can just use pure Camel. And then choose the container that suits your need in which you will deploy your ESB application.
Regarding ServiceMix 4 as a container it offers to you the following benefits:
– Integration with Camel has been tested and certified.
– Integration with Apache Agila if you want to use both of them embedded in the same VM is performant (thanks to ServiceMix NMR)
But it also get with the following constraint:
– ServiceMix 4 runtime is based on Apache Karaf, you will then benefits from all the great modularity and deployment features from OSGi… But well as any OSGi container it means that you have to use OSGi and to be honest this sounds more like a constraint to me.
I’ll be interested to get your feedbacks on this subject