For most of my Java career, I’ve been an enterprise application development person, which is to say I’ve principally worked with application servers like Tomcat and JBoss as well as frameworks thereupon like Spring MVC, Struts, JAX-RS, blah blah. At the same time, I’ve tried to keep track of the integration space because it’s fascinating, and now I finally get to work the technologies a lot more. So here’s my chance to do a crash catch up piece on the past ten years.
Let’s start with JBI
The Java Business Integration (“JBI”) spec is hardly the beginning of enterprise integration, but it’s a good starting point for our discussion. JSR-208 was (and still is) a specification for specifying how an enterprise service bus (“ESB”) should work with pluggable components (sort of like J2EE containers). But it’s a complicated spec; from the intro:
JBI employs concepts similar to J2EE to extend application packaging and deployment functionality to include JBI Components. JBI Components are an open-ended class of components that are based on JBI abstract business process metadata. The JBI JSR itself does not define how developers code Components. Both standard and proprietary ways of coding Components may exist. A specific class of Component may provide rich business process functionality while another class of Component may provide a specialized integration function like a data transformation table or support a domain specific business rule encoding. A JBI Application is composed of one or more JBI Components and service assemblies.
Don’t worry, I didn’t understand it either, which explains the history that follows:
Enter stage left: Apache ServiceMix
Apache ServiceMix started its existence as an open source ESB by implementing the JBI in 2005. It took a couple of years and three versions to fully implement the JBI. While the JBI implementation was complete by the third version, many felt that ServiceMix had become an overly heavyweight container, which contrasted with ServiceMix’s origins as a lightweight implementation of JBI.
Around the same time that ServiceMix was maturing, OSGi was finally starting to take hold (see the withdrawn JSR-8). The ServiceMix team decided to adopt the OSGi model and implement that as a core.
(My source on this stuff is Guillaume Nodet‘s post, Thoughts about ServiceMix)
Goodbye JBI, hello again ServiceMix
Because JBI was a complex (“overly ceremonious,” according to the Fabric8 documenters) spec that effectively dictated a heavyweight container, competing technologies like Spring Integration and Camel emerged (those of us who were excited about enterprise Java app development back in the 2000s will see the analog to Spring). So the ServiceMix team abandoned JBI in it’s next major revision, version 4, and fully embraced Camel and an OSGi core.
Something else interesting starting happening after this release: ServiceMix evolved from being a monolithic project into something that looked more like a collection of pieces and parts. For example, the ServiceMix core components evolved into Apache Karaf. And ServiceMix started bundling in its other dependencies like ActiveMQ, CXF, Activiti for BPM, and etc.
Because ServiceMix is now really just a prepackaged assortment of OSGi bundles, some developers are simply using the lower-level components themselves, such as Karaf, and then deploying the specific bundles they need for their integration issues.
So what is this Fuse thing?
It’s probably safe for you to generally think of Fuse as a hardened, supported version of Apache ServiceMix, which is a Big Deal in the enterprise space: I know if I were an IT manager with a budget and mission critical applications, I would look for a supported option over a community-supported open source option every time.
The Fuse project was started by FuseSource, which Red Hat acquired in 2012. Red Hat renamed the project JBoss Fuse, and Red Hat offers all the things that Red Hat does a great job at such as stablizing the code, supporting it, documenting it, and pushing changes upstream (see my about page for disclaimer!).
And what about Fabric8?
Fabric8 takes Fuse to the next level. Fabric8 builds on Fuse by including a full web-based GUI (itself an open source project called Hawtio) and includes interesting and powerful new features such as fabrics, support for Docker containers, and so on. More about Fabric8 in a future post.
One of the things that’s easy to get confused about is the relationship between Fuse and Fabric8. That is to say that if you install Fuse from the Red Hat Network it’s basically bundled into the Fuse download you get; put differently, you can think of the supported JBoss Fuse as combing both Fuse and Fabric8.
By the way, a lot of this history I gleaned from the Fabric8 documenters here: http://fabric8.io/gitbook/overview.html.