h1. Adding ActiveMQ to the 'Mix

Out-of-the-box, every Apache ServiceMix instance comes with an embedded ActiveMQ JMS broker.  This makes it easy to communicate between Camel routes using persistent messages on the same machine, but it will also enable you to distribute your routes over multiple instances afterwards for clustering or load-balancing.

h2. Our scenario

In this scenario, we also want to move files between directories.  Instead of logging the move directly, we are going to send an event JMS message onto a queue.  Afterwards, we will create a second Camel route to receive the events and log them.

h2. Moving files and sending event messages
The first Blueprint XML file we'll create contains a Camel route that moves the files from {{activemq/input}} to the {{activemq/output}} directory.  Afterwards, it will generate an event message and send that to an ActiveMQ queue called {{events}}.

{pygmentize:lang=xml}
<?xml version="1.0" encoding="UTF-8"?>
<blueprint
    xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
      http://www.osgi.org/xmlns/blueprint/v1.0.0
      http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">

    <camelContext xmlns="http://camel.apache.org/schema/blueprint">
      <route>
        <from uri="file:activemq/input"/>
        <to uri="file:activemq/output"/>

        <setBody>
          <simple>
            FileMovedEvent(file: ${file:name}, timestamp: ${date:now:hh:MM:ss.SSS})
          </simple>
        </setBody>
        <to uri="activemq://events" />
      </route>
    </camelContext>
</blueprint>
{pygmentize}

Save this file in ServiceMix' {{deploy}} folder and use {{osgi:list}} to check on the bundle status as you did with the simple Camel example.  You should now be able to put files in the {{activemq/input}} directory and see them being moved to {{activemq/output}}.

h2. Receiving the event messages
After deploying the first XML file, you're obviously not seeing any events being logged yet.  The event messages are sent to an ActiveMQ queue, but there's nobody to receive the events yet.  Let's change that now by creating a second Blueprint XML file.

{pygmentize:lang=xml}
<?xml version="1.0" encoding="UTF-8"?>
<blueprint
    xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
      http://www.osgi.org/xmlns/blueprint/v1.0.0
      http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd">

    <camelContext xmlns="http://camel.apache.org/schema/blueprint">
      <route>
        <from uri="activemq://events"/>
        <to uri="log:events"/>
      </route>
    </camelContext>
</blueprint>
{pygmentize}

As soon as this second file has been deployed, you'll start seeing the event messages in your {{log:display}} output.

h2. Using the shell to manage the routes

You can now start and stop both routes from the command shell.  The important thing to note here is that you can stop the event handler route while files are being processed.  As soon as you restart that bundle afterwards, you'll receive the events from all files that have been moved while the route was not running.