Embedding Apache Camel inside the ActiveMQ broker provides great flexibility for extending the message broker with the integration power of Camel. Apache Camel routes also benefit in that you can avoid the serialization and network costs of connecting to ActiveMQ remotely – if you use the activemq component. One of the really great things about Apache ActiveMQ is that it works so well with Apache Camel.
If however, you want to change the behaviour of messages flowing through the ActiveMQ message broker itself you will be limited to the shipped set of ActiveMQ Broker Interceptors – or develop your own Broker plugin – and then introduce that as a jar on to the class path for the ActiveMQ broker.
What would be really useful though, is to combine the Interceptors and Camel together – making it easier to configure Broker Interceptors using Camel routes – and that’s exactly what we have done for upcoming ActiveMQ 5.9 release with the broker Camel Component. You can include a camel.xml file into your ActiveMQ broker config – and then if you want to take all messages sent to a Queue and publish them to a Topic, changing their priority along the way – you can do something like this:
<route id="setPriority">
<from uri="broker:topic:test.broker.>"/>
<setHeader headerName="JMSPriority">
<constant>9</constant>
</setHeader>
<to uri="broker:queue:test.broker.component.queue"/>
</route>A few things worth noting:
- A broker component only adds an intercept into the broker if its started – so the broker component will not add any overhead to the running broker until its used – and then the overhead will be trivial.
- You intercept messages using the broker component when they have been received by the broker – but before they are processed (persisted or routed to a destination).
- The in message on the CamelExchange is a Camel Message, but also a JMS Message (messages routed through ActiveMQ from Stomp/MQTT/AMQP etc. are always translated into JMS messages).
- You can use wildcards on a destination to intercept messages from destinations matching the wildcard.
- After the intercept, you have to explicitly send the message back to the broker component – this allows you to either drop select messages (by not sending) – or, like in the above case – re-route the message to a different destination.
- There is one deliberate caveat though, you can only send messages to a broker component that have been intercepted – i.e. routing a Camel message from another Component (e.g. File) would result in an error.
There are some extra classes that have been added to the activemq-broker package – to enable views of the running broker without using JMX – and to support the use of the broker component:
org.apache.activemq.broker.view.MessageBrokerView – which provides methods to retrieve statistics on a the broker, and from the MessageBrokerView – you can retrieve a org.apache.activemq.broker.view.BrokerDestinationView for a particular destination. This means you can add flexible routing inside the broker by doing something like the following – to route messages when a destination’s queue depth reaches a certain limit:
<camelContext id="camel" trace="false" xmlns="http://camel.apache.org/schema/spring">
<route id="routeAboveQueueLimitTest">
<from uri="broker:queue:test.broker.queue"/>
<choice>
<when>
<spel>#{@destinationView.queueSize >= 100}</spel>
<to uri="broker:queue:test.broker.processLater"/>
</when>
<otherwise>
<to uri="broker:queue:test.broker.queue"/>
</otherwise>
</choice>
</route>
</camelContext>
<bean id="brokerView" class="org.apache.activemq.broker.view.MessageBrokerView">
<constructor-arg value="testBroker"/>
</bean>
<bean id="destinationView" factory-bean="brokerView" factory-method="getDestinationView">
<constructor-arg value="test.broker.component.route"/>
</bean>This is using the Camel Message Router pattern – note the use of Spring expression language (spel) in the when clause.
great