Overview of FUSE ESB

One of the big projects coming up in my new role is implementing an Enterprise service bus (ESB) as the backend of our IT operations.  I’d never even heard of an ESB before starting here, so this has all been new ground for me which makes it all the more interesting. The first thing I needed to do was understand what an ESB is and what it does.  This part is pretty simple once you understand the problem that an ESB is designed to solve,namely how to enable many disparate systems, written in different languages and running on different machines to share information and form an integrated business platform.

Tranditionally applications have shared information (if at all!) directly, by one application (app A) using the API of another (app B) to push information directly from A to B.  We can see thwat with just 2 applications we only need 1 interface (A-B).  However if we introduce another application the number of interfaces required for full integration jumps to 3 (A-B, B-C, A-C), and with 4 apps we need 5 interfaces (A-B,B-C,C-D,B-D,C-D).  More importantly each of these interfaces requires custom code to translate between the different formats and interfaces required. You can see that as the number of applications increases we have more interfaces with custom code.  And what happens if we decide to change one of the applications?  Each interface to that application now needs rewriting, which is a huge amount of work.

An ESB aims to simplify this problem of integration by becoming a ‘hub’ that sits in the middle of all your applications and facilitates message routing between them.  Instead of every applicaiton interfacing with every other application, each application now just has one interface to the ESB.  the ESB is responsible for translating messages to / from a common format and routing them to destinations.  The major saving in this approach comes if you have to replace any of your applications.  Instead of writing a whole host of new interfaces, you now only have one to worry about (between your application and the ESB).

The ESB we’re going to be using is ‘FUSE ESB‘ which is a packaged and supported version of Apache servicemix.  Servicemix is a (as the name suggests) made up of several difefrent parts, which come together to provide an end to end ESB solution.  The major parts are:

• Apache Karaf:  An OSGI application server kernel.  This is basically the ‘container’ in which your routes will sit, you can think of this as an application and the routes you write as scripts for that application
• Apache Camel: An integration framework.  Camel provides the ‘bits’ (components, chunks of processing code) that you can plug together to make up messaging routes within your integration solution
• Apache ActiveMQ: A messaging solution.  ActiveMQ provides a simple queueing framework which is easy to integrate with Camel

With these 3 frameworks we have the basis of an incredibly powerful and flexible integration solution.  I’ll be looking at some use cases for this technology in future articles.