Apache Karaf Cellar 2.2.3
Around one week ago, we released Karaf Cellar 2.2.3.
In addition of the first Distributed OSGi support (DOSGi, I already wrote blog), an interesting feature of Cellar 2.2.3 is to give access the whole Hazelcast configuration.
The etc/hazelcast.xml is the core configuration of the Hazelcast instance, started by the Cellar feature. Cellar registers the Hazelcast instance as an OSGi service.
It means that we can use the Hazelcast instance just using a reference to the corresponding OSGi service. We are going to use the Hazelcast OSGi service in a Camel route defined using blueprint DSL (it works using Spring DSL as well).
Apache Camel 2.9.0 and the Hazelcast component
Camel 2.9.0 provides a new component: camel-hazelcast.
This component allows to send (as a producer/to) or receive (as a consumer/from) a Camel exchange through a Hazelcast distributed queue.
The first route timerToQueue fires a message every 5 seconds, and send to a Hazelcast distributed queue.
This distributed queue will be in the Hazelcast instance registered as an OSGi service by Cellar.
<?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"
xmlns:camel="http://camel.apache.org/schema/blueprint"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd">
<camelContext id="blueprintContext" trace="false" xmlns="http://camel.apache.org/schema/blueprint">
<route id="timerToQueue">
<from uri="timer:foo?period=5000"/>
<setBody>
<constant>Hello Remote</constant>
</setBody>
<to uri="hazelcast:seda:yet.another.queue"/>
</route>
</camelContext>
<bean id="hazelcast" class="org.apache.camel.component.hazelcast.HazelcastComponent">
<property name="hazelcastInstance" ref="hazelcastInstance"/>
</bean>
<reference id="hazelcastInstance" availability="optional" interface="com.hazelcast.core.HazelcastInstance"/>
</blueprint>
On the other hand, the queueToFile route get the exchange from the distributed queue and send to a file.
<?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"
xmlns:camel="http://camel.apache.org/schema/blueprint"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd">
<camelContext id="blueprintContext" trace="false" xmlns="http://camel.apache.org/schema/blueprint">
<route id="queueToFile">
<from uri="hazelcast:seda:yet.another.queue"/>
<to uri="file:/my/folder"/>
</route>
</camelContext>
<bean id="hazelcast" class="org.apache.camel.component.hazelcast.HazelcastComponent">
<property name="hazelcastInstance" ref="hazelcastInstance"/>
</bean>
<reference id="hazelcastInstance" availability="optional" interface="com.hazelcast.core.HazelcastInstance"/>
</blueprint>
The two routes are on different Cellar nodes, the communication uses a queue distributed on all Hazelcast instances (handle by Karaf Cellar).
Conclusion
Lot of Camel users mostly use a JMS queue to “connect” two remote Camel routes. It requires a MQ broker, with a network connector if you want failover/cluster, etc. So it’s required special configuration, etc.
Now, we have an alternative using Cellar, which is just a feature to install, without point of failure (a Hazelcast instance is present on each Cellar node).
