Communication between two remote Camel routes using Karaf Cellar

Apache 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.

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).