A Look Inside FUSE ESB 4: An OSGi-Based Integration Platform
Recently, version 4 of the FUSE ESB was released, which is the enterprise support version of Apache ServiceMix 4, rebranded by Progress Software (previously IONA), but still fully open source and Apache licensed. This new major version of the FUSE ESB is founded on OSGi and introduces a number of new deployment models, in addition to JBI 1.0, which makes your life as an integration developer far easier.
In this article I’ll introduce you to the new version of FUSE ESB by explaining the new functionality of the ServiceMix Kernel and NMR projects with a number of hands-on examples. In order to try the examples covered in this article, you can download a copy of FUSE ESB from http://fusesource.com
Didn’t FUSE ESB support JBI?
Yes, in version 3 of FUSE ESB (based on Apache ServiceMix 3.x), the architecture is based on JBI 1.0. This means that the integration functionality provided by FUSE ESB can be implemented with service engines (SEs) and binding components (BCs), which are connected via a normalized message router. And with services assemblies (SAs) and service units (SUs) you can deploy integration functionality via Ant tasks or Maven plugins to the ServiceMix container. For more detailed information about version Apache ServiceMix 3 you can read another article I wrote for DZone, Pattern Based Development with ServiceMix.
But did this all change in version 4 of FUSE ESB? Well, yes and no. Version 4 is based on OSGi bundles and the classloading model of JBI 1.0 has been superseded by OSGi. You can now deploy your integration artifacts as OSGi bundles on the ServiceMix container; however, JBI 1.0 is still supported with version 4 and the JBI components like the JMS BC, File BC, Validation SE and the Bean SE are still there. So you can still deploy your good old service assemblies to the ServiceMix 4 container without any need to change the implementation from ServiceMix 3.
FUSE ESB 4 architecture
But let’s not stick too much in comparing version 3 and 4, and have a look at the new architecture of FUSE ESB 4. Fuse ESB 4 consists of two main projects: the kernel and the NMR, as shown in figure 1.
Figure 1 The architecture of FUSE ESB 4, which is based on OSGi.
The kernel component is the foundation of FUSE ESB 4. The kernel provides an OSGi-based platform using Apache Felix (although other OSGi containers can also be used) with a number of components on top. First there is the console, which is the central tool to interact with the kernel. When you start FUSE ESB, the console is started automatically, so you can manage the ESB environment. Starting the FUSE ESB is very easy, just open a command prompt and go to the installation directory of the FUSE ESB, e.g. c:\fuse-esb-18.104.22.168 Then enter the following command to start the ESB.
When the FUSE ESB has started, a console similar to figure 2 is shown.
Figure 2 A screenshot of the Fuse ESB console, which is started with the Fuse ESB.
The console is very intuitive and easy to use. There’s a handy ‘help’ option that you can use to get familiar with the commands. A command that you’ll be using quite often when using FUSE ESB is the ‘osgi list’ command. This shows an overview of all installed OSGi bundles on the container. To manage the bundles there are several commands that you can use like ‘osgi install’, ‘osgi uninstall’, ‘osgi start’ and ‘osgi stop’. An overview of all the OSGi related commands can be retrieved with the ‘osgi help’ command.
Instead of discussing all the components shown in figure 1 one-by-one, let’s first look at a small example to get familiar with the basic components of the FUSE ESB.
A short Camel ride
One of the main changes between version 3 and 4 of FUSE ESB is the integration with Apache Camel (http://activemq.apache.org/camel) to implement routing functionality. In version 3 there was already support for Camel with the Camel service engine, but in version 4 Camel is integrated in the core of the ServiceMix container. So let’s explore the use of Camel routing inside the FUSE ESB a bit.
With Camel, we have two options to implement the integration logic, a Java class using the Java domain specific language (DSL) or a Spring XML configuration file using the Camel XSD. For this first example we’ll use the Spring XML configuration option, because we can deploy this directly to the FUSE ESB without any packaging. Let’s look at a very simple example, where a file is moved from one directory, camel-test-in, to another directory, camel-test-out, in listing 1.
Listing 1 Spring configuration file, camel-file-test.xml, using Camel to move a file to another directory.
<?xml version="1.0" encoding="UTF-8"?>
As you can see in listing 1, we can define a Camel route configuration directly in a Spring XML configuration file. In this Camel configuration the Camel OSGi module is used. In the route element definition a source directory is configured with the from element and a target directory with the to element.
Before we can deploy this Camel example, we first have to install the Camel component on the FUSE ESB container. This is a good time to talk about the provisioning component implemented in the FUSE ESB kernel, also shown in figure 1. To provide a flexible way of installing new OSGi bundles to the FUSE ESB container, the kernel provides several sources, including Maven artifacts, URLs and local file paths. To interact with the provisioning component the features command can be used in the console of the FUSE ESB container. To get an overview of features that can be installed on the FUSE ESB container you can use the ‘features list’ command. A feature consists of one or more OSGi bundles and provides specific functionality that can be used to develop integration functionality. By default, the result of the ‘features list’ command is an substantial number of components, including Camel, ActiveMQ, the JBI components that we could already use in FUSE ESB 3, and the NMR project.
To get our simple Camel example running, we need to install the Camel functionality. The installation of a specific feature is very simple to do with the console. Just run the command ‘feature install camel’, where camel can of course be replaced by other features you may wish to install. The feature name should be exactly the same as the name you see as a result of the ‘feature list’ command. When the Camel feature is installed, the Camel file example can easily be deployed on the FUSE ESB by copying the Camel configuration file, camel-file-test.xml, to the deploy directory in the FUSE ESB installation directory.
If the FUSE ESB has been started you can now see that the Camel file example has been installed by executing the ‘osgi list’ command. The last OSGi bundle that is showed in the list is now the camel-file-test.xml bundle with a status of active. This means that the FUSE ESB has already started the Camel file example OSGi bundle and is polling the camel-test-in directory for files. If you copy a file to the camel-test-in directory it is consumed by the FUSE ESB container and a new file with the same content is created in the camel-test-out directory. So, we can use the components provided by Camel out-of-the-box in the FUSE ESB container, and we don’t have to create a JAR file or another deployment package, we can use a Spring XML configuration and your mediation flow is deployed and running.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)