ServiceMix 4 was the time when we moved to OSGi and that was three, maybe four years ago, but what we did initially was, we re-implemented ServiceMix to use OSGi under the covers. We re-implemented the JVI deployment model on top of OSGi so everything was backwards compatible, but it meant that you could just deploy bundles or Spring XMLs or a number of other different artifacts and it all just worked.
But what we found is that when we'd done that, we'd actually built this reusable kernel. For a while, we actually called it the ServiceMix Kernel, which is really a generic OSGi container framework sort of thing that made it easy to build any type of application server or container. Then we started to realize that it didn't have anything to do with ESBs anymore.
This kernel is actually really cool; it has SSH support and a really awesome shell, as well as a really easy way of upgrading and downgrading itself. So that got factored out and became Apache Karafe. Karafe, like a carafe of wine, because it's a container of nice things – Karafe with a K, though, to emphasize that it's a kernel and to make it easier to find in a Google search.
ServiceMix is based on Karafe. It's a Karafe distribution which has all of the integration components predefined. As soon as you boot up ServiceMix it knows how to install Camel CFX for Web services, Active MQ for messaging, and so on. Increasingly, we are seeing more and more things that are just Karafe distributions. For example, Fuse MQ is a distribution of Karafe, which has ActiveMQ inside. Fuse Fabric is sort of the next project in the evolution. That comes with a sort of OSGi container -a carafe [if you will]- but that has some provisioning stuff inside.
We started really talking about Fuse Fabric last year. The interesting thing about Fuse Fabric is that we initially started off writing services – a message broker, an ESB, an integration framework and so forth, eventually an OSGi kernel. We were writing all these different middleware pieces, and we gradually started decoupling them and making them simpler and more powerful and more reusable and removing dependencies to make them simpler and lighter weight. So we started writing big things and then we started forming them into smaller and smaller pieces that were easier to plug and play together in different ways.
Then we realized that now that we had a lot of pieces, some of our customers were struggling to put the pieces together into useful shapes. They had a hundred machines; they wanted ten message brokers, five ESBs and a hundred Camel routes. Fuse Fabric was the first time we took a top down approach. How do we take a big system with hundreds of machines and fit all the pieces into the JVMs?
With Fuse Fabric we sort of flipped everything on its head. We started with an integration platform of Java processes and had to figure out how to use all the pieces we have – Camel, Active MQ, CFX, and others.
Under the covers, it's implementing jars, bundles, all of the above. Well the current incarnation of Fuse Fabric is using Apache Karafe containers under the covers. So Fuse Fabric has its own implementation if you wanted a really light container – and basically Fabric provisions deployment units that work inside Karafe.
One of the really great things about OSGi is it's an extensible container so anyone can define a deployment unit. It's not like servlets where you have a well-defined WAR, and WAR is it. Anybody can write a deployer for OSGi. So Fabric can deploy a new deployer to deploy a new artifact. Basically you can deploy anything – JARs, WARs, EARs, bundles – anything.
No comments:
Post a Comment