To ServiceMix or not to ServiceMix

This morning an interesting topic was posted to the Apache ServiceMix user forum, asking the question: To ServiceMix or not ServiceMix.

In my mind the short answer is: NO

Guillaume Nodet one of the key architects and long time committer on Apache ServiceMix already had his mind set 3 years ago when he wrong this blog post - Thoughts about ServiceMix.

What has happened on the ServiceMix project was that the ServiceMix kernel was pulled out of ServiceMix into its own project - Apache Karaf. That happened in spring 2009, which Guillaume also blogged about.

So is all that bad? No its IMHO all great. In fact having the kernel as a separate project, and Camel and CXF as the integration and WS/RS frameworks, would allow the ServiceMix team to focus on building the ESB that truly had value-add.

But that did not happen. ServiceMix did not create a cross product security model, web console, audit and trace tooling, clustering, governance, service registry, and much more that people were looking for in an ESB (or related to a SOA suite). There were only small pieces of it, but never really baked well into the project.

That said its not too late. I think the ServiceMix project is dying, but if a lot of people in the community step up, and contribute and work on these things, then it can bring value to some users. But I seriously doubt this will happen.

PS: 6 years ago I was working as a consultant and looked at the next integration platform for a major Danish organization, and we looked at ServiceMix back then and dismissed it due its JBI nature, and the new OSGi based architecture was only just started. And frankly it has taken a long long time to mature Apache Karaf / Felix / Aries and the other pieces in OSGi to what they are today to offer a stable and sound platform for users to build their integration applications. That was not the case 4-6 years ago.

Okay No to ServiceMix - what are my options then?
So what should use you instead of ServiceMix? Well in my mind you have at least these two options.

Use Apache Karaf and add the pieces you need, such as Camel, CXF, ActiveMQ and build your own ESB. These individual projects have regular releases, and you can upgrade as you need.

The ServiceMix project only has the JBI components in additional, that you should NOT use. Only legacy users that got on the old ServiceMix 3.x wagon may need to use this in a graceful upgrade from JBI to Karaf based containers.

Take a look at fabric8. IMHO fabric8 is all that value-add the ServiceMix project did not create, and a lot more.

James Strachan, just blogged today about some of his thoughts on fabric8, JBoss Fuse, and Karaf. I encourage you to take a read. For example he talks about how fabric becomes poly container, so you have a much wider choice of which containers/JVM to run your integration applications. OSGi is no longer a requirement. (IMHO that is very very existing and potentially a changer).

I encourage you to check out fabric8 web-site, and also read the overview and motivation sections of the documentation. And then check out some of the videos.

After the upcoming JBoss Fuse 6.1 release, the Fuse team at Red Hat will have more time and focus to bring the documentation at fabric8 up to date covering all the functionality we have (there is a lot more), and as well bring out a 1.0 community released using pure community releases. This gives end users a 100% free to use out of the box release. And users looking for a commercial release can then use JBoss Fuse. Best of both worlds.


Okay back to the question - to ServiceMix or not. Then NO.
Innovation happens outside ServiceMix, and also more and more outside Apache.

If you have thoughts then you can share those in comments to this blog, or better yet, get involved in the discussion forum at the ServiceMix user forum.

PPS: The thoughts on this blog is mine alone, and are not any official words from my employer.


Unknown said...

Where do you see "OSGi is no longer a requirement" in James post?

Claus Ibsen said...

Where he says the following

As soon as the JBoss Fuse 6.1 release is out, fabric8 will move to support Karaf, Tomcat, WildFly containers (hopefully vertx and jetty too) along with stand alone JVMs like DropWizard and Spring Boot - in addition to its current support for managed processes, OpenShift and jclouds.

Raúl Kripalani said...

Give it a break, Claus! ServiceMix has accumulated much merit over time. Many Camel users have only arrived at Camel because SMX introduced it as the integration framework in the ESB context to begin with. Take me as an example.

The ServiceMix brand has done a lot for Camel and FuseSource in the past. Now that you're linked to Red Hat, it's clear that the direction you're steering is slightly different.

However, amongst all this FUD that you're throwing, you fail to realise that SMX is no more than a packaging of the components you later propose in your blog post: Karaf, Camel, CXF, AMQ, etc.

So let's put it in a different way...

If SMX equals Karaf + Camel + CXF + AMQ...

... and Karaf + Camel + CXF + AMQ together get your approval...

... what's wrong?

The version numbers that SMX is using?!

Yes – fair enough – ServiceMix is slightly outdated. But you can fix that quickly with features:chooseurl. Isn't it?

Anyway, had to give my 2 cent because it's absolutely unfair that you badmouth and make bold, destructive statements against the ServiceMix brand.

Especially when you propose to use exactly the same components that power ServiceMix later in your post.

Claus Ibsen said...


I was giving my thoughts and answer to Cristiano Costantini, whom posted the question about To ServiceMix or Not to ServiceMix. (eg very first link).

He was coming to the same conclusion that activity on ServiceMix was low, and he was in need for a new release which was not coming. He was considering not using ServiceMix but to go and use Karaf instead, and add what he needs. Then he could upgrade and use latest releases of Camel, CXF, ActiveMQ, etc.

I still recommend people to do that. All the activity of ServiceMix happens at other Apache projects such as Karaf, and Camel in particular.

If you want to use ServiceMix then its IMHO much better to face the fact its Apache Karaf container, and that means OSGi. And you will have to learn about OSGi, and Karaf concepts such as features to be able to use it. And certainly when you want to install and run your own applications in the container.

The Apache Karaf community is much better at helping you with that. And there is published books about Karaf you can purchase and learn from.

And if you do not go using ServiceMix then you do NOT lose out of any functionality. ServiceMix offers NOTHING of use. The JBI is dead, and you should NOT use that.

Using Karaf allows you to know how to upgrade individual components in your container when you need to install a bug fix.This allows you to upgrade what you want, and minimize risks. For example with ServiceMix it often comes with a Karaf + Camel + CXF upgrade all at once (when there actually is a release, which you would have to wait a long time for). Using Karaf you can keep the Karaf version as is, and only upgrade Camel etc.

Also if you are new to ServiceMix then the latest release today comes with outdated and old releases. Karaf 2.2, Camel 2.10 (which is EOL and no longer supported), and ActiveMQ 5.8 which is also old and a bit buggy.

So if you downloaded ServiceMix today you are using old stuff. But if you use Karaf you can use latest release of Karaf / Camel / CXF / ActiveMQ in combination.

Unknown said...

Apache ServiceMix is a project of the Apache Software Foundation and was built on the semantics and application programming interfaces of the Java Business Integration (JBI) specification


and u said JBI is dead???

Claus Ibsen said...

The wikipedia article is a bit out of data.

Apache ServiceMix 3.x is JBI based. That version is EOL a long time ago.

Apache ServiceMix 4.x and 5.x is purely OSGi based. In 4.x there was a legacy JBI module, that aimed to help people migrate from 3.x to 4.x and keep using JBI until they have migrated to OSGi.

From ServiceMix 5.x onwards the JBI module has been removed.

And yeah JBI is dead. There is no other new products that implements the specification. And JBI 2.0 spec was never done.

The JBI 1.0 spec is very old.

The lead architect of ServiceMix 3.x/4.x wrote a blog post about his thoughts on SMX and JBI:

And there is a SO questions about JBI is dead

Unknown said...

The thing is, that Fusesource and now Red Hat was putting ServiceMix (yes ServiceMix under Fuse ESB brand and now under JBoss Fuse) in next levels of abstraction for years and this is still happening. But as the abstraction is getting higher and higher, JBoss Fuse is not anymore just a Karaf + Libraries (which equals to ServiceMix) but now JBoss Fuse is more a Fabric with libraries (which not equals to ServiceMix) meaning it is getting less and less basing on ServiceMix. In turn almost nothing is happening in ServiceMix project in last years except further deprecation and putting newer version of libraries which is not enough.

Some background:
For years ServiceMix was just a container with stable libraries (at least suppose to).
4-5 years ago Fusesource (which now Red Hat continue) started to work on Fabric project to add additional abstraction layer which partially can be compared to SOA Platform and its principles (mainly registry, discovery, etc.). But instead of reimplemeting idea of SOA, they have build everything basing on their own new ideas going beyond what was currently know to the world. Of course some of ideas are good, some not as personally I do not like ZooKeeper but this kind of usage evaluation happens to all new project/ideas and it is good it is happening instead of let the project to die. This rather means that it passed a test- a market needs test.

So then JBoss Fuse is not just a container, it is rather a Fabric of containers, while ServiceMix is still just a single Karaf container + set of libraries.
In fact you can add Fabric8 to ServiceMix but as it is not a part of a build, then you are taking a risk of integrating those projects together (while in case of JBoss Fuse this risk is taken by Red Hat)

So then if you are looking for just a container, ServiceMix can be for you but then you can also use just JBoss or even tomcat as a container.
If you are looking for something more, then you should go to JBoss Fuse meaning rather Fabric8.

In terms of getting ServiceMix back to life (I agree it is getting dead), someone should simply integrate Fabric8 into it to get it up to speed and back to life.

Anonymous said...

Ironically ServiceMix is ahead of Fuse in some significant ways. First it is on Karaf 3 and the latest (Fuse 6.2) is still on Karaf 2.4. This when Karaf 4 is already out.

Red Hat JBoss Fuse (not to be confused with Red Hat JBoss Fuse ServiceWorks) doesn't appear to have much wind in its sails anymore.

The Fuse 6.2 version has a vomit of Switchyard components in its quickstarts library without any real explanation. The POMs all have settings for Wildfly(!?) but no blueprint support. And no real explanation for why the JBoss AS is manifesting itself there.

Whether ServiceMix is dead or not I can't say but Fuse has become a muddled, confused and confusing mess. Part of the problem is that Red Hat hasn't been very good at communicating where this is all going.

The first version of fabric with Zookeeper was a mess. I'm not sure that putting Fabric in the ServiceMix stack would be such a great idea.

WMcDonald said...

This is an old post, but I wanted to know if you still hold your opinion about 'not to servicemix' - especially with v 7 out now.

We are looking to move off of the old fuse (6.0.0.redhat-024), and although mgmt doesn't want to go with kubernetes/fabric8, basically my choices at this point are servicemix OR karaf+camel+activemq (ie. "roll your own pieces"). From your article, it didn't sound like there was basically much technical difference between the two and that the karaf plus... setup was better since servicemix was the same thing but not released or developed as much.

Another developer is looking at spring boot also, but I have not gotten my head around what he's doing, what spring boot does and how he's using it - replacing smx or just improving the architecture with how its used with other apps.

Do you still hold the same opinion about 'to smx or not to smx' today? Has anything changed since you wrote this between the two?