If you have spent some time looking at or working with Fuse ESB then you will be aware of what powerful option its pluggable component architecture represents. If you have not come across Fuse ESB before then Fuse Source describe it as:
Based on Apache ServiceMix, FUSE ESB is an open source enterprise service bus (ESB) that provides a standardized methodology, server, and tools to deploy integration components, freeing architects from the dependencies that have traditionally locked enterprises into proprietary middleware stacks.
During the past year Answer have worked on a number of Fuse based implementations and have picked up several tips and tricks which are helpful to both the development and operations teams. Over the next few articles we will be capturing some of these handy hints and trying to highlight how they can be used.
The Camel routes that form the core of Fuse can be described using both the Camel DSL and Camel XML formats. If your defining a Camel route during the course of your project then the DSL is certainly my preference as it has a number of strong advantages over the XML format; including greater IDE support, easer route reuse, enhanced debug support and ease of reading. That said, thanks to the ServiceMix hot deploy capabilities there are a couple of situations where the XML routes can be extremely useful. It is this that we will look at in this article.
Camel XML Routes
The Camel XML language utilises Spring namespaces so that they can be defined within your Spring configuration files. The simple example below takes a file from msg-in directory, puts it on the MESSAGE.TRANSPORT queue and then saves it back to the msg-out directory under its original filename.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:c="http://camel.apache.org/schema/spring"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd">
<c:camelContext>
<c:route>
<c:from uri="file://tmp/msg-in/"/>
<c:to uri="activemq:MESSAGE.TRANSPORT"/>
</c:route>
<c:route>
<c:from uri="activemq:MESSSAGE.TRANSPORT"/>
<c:to uri="file://tmp/msg-out?fileName=${id}"/>
</c:route>
</c:camelContext>
</beans>
What you might not be aware of is that if you drop this XML file into the fuse deploy directory then ServiceMix will hot deploy this route without the need to package it inside an OSGi bundle. Now this is certainly not the recommended approach for deploying your business critical routes, as properly bundled, released packages, that are managed using a features file is a safer way to create a controlled, reproducible infrastructure. However, if used properly then it can be a very powerful option.
So how can I use this?
Lets look at a couple of situations where this might be very useful in both test and production infrastructures. Consider a test deployment where one of the external message queues is not available and you want a simple stub service without having to deploy an externalised consumer (e.g. Performance testing). In this case you could hot deploy a XML based route to consume these messages such as the snippet below. Using a hot deployed message consumer in this case allows you to build a standard environment of released software components without the need for customisation of your core application code.
<c:camelContext>
<c:route>
<c:from uri="activemq:MESSSAGE.TRANSPORT"/>
<c:to uri="file://tmp/msg-out?fileName=${id}"/>
</c:route>
</c:camelContext>
Now lets consider another example in the production environment. Lets say that for what ever reason there has been a problem with some of the messages passing through the bus and as a result they have been placed onto the error or dead letter queues. These messages are important and they need to be rectified so that processing can continue. This could easily be achieved using the hot deployed XML route option. The snippet below could be provided to the Operations team as a means of taking the messages off the error queue and saving them to a directory.
<c:camelContext>
<c:route>
<c:from uri="activemq:INVALID.MESSAGE.QUEUE"/>
<c:to uri="file://tmp/fuse-esb-error-out?fileName=${id}"/>
</c:route>
</c:camelContext>
Once in the directory then they can be edited to resolve the issue before a second route puts them back onto a queue so that the processing can continue..
<c:camelContext>
<c:route>
<c:from uri="file://tmp/fuse-esb-error-resolved"/>
<c:to uri="activemq:MESSAGE.QUEUE"/>
</c:route>
</c:camelContext>
Once deployed these temporary routes can be stopped/started/undeployed as any other bundle using the ServiceMix console.
Summary
Hopefully these simple examples have demonstrated the potential power of the XML routes and ServiceMix hot deploy capabilities. That said, this is certainly one of these capabilities that falls into the ‘just because you can, doesn’t mean you should’ set as it has a lot of great potential but if misused then it could also lead to an over complex, uncontrolled environment. Consider the pro’s and con’s before taking this approach and if it still seems the right thing to do then go with it.
