h1. The role of Hazelcast

The idea behind the clustering engine is that for each unit that we want to replicate, we create an event,
broadcast the event to the cluster and hold the unit state to a shared resource, so that the rest of the
nodes can look up and retrieve the changes.

!/images/shared_architecture.jpg!

For instance, we want all nodes in our cluster to share configuration for PIDs a.b.c and x.y.z. On node
"Karaf A" a change occurs on a.b.c. "Karaf A" updated the shared repository data for a.b.c and then notifies
the rest of the nodes that a.b.c has changed. Each node looks up the shared repository and retrieves changes.

The architecture as described so far could be implemented using a database/shared filesystem as a shared
resource and polling instead of multicasting events. So why use Hazelcast ?

Hazelcast fits in perfectly because it offers:

* Auto discovery
** Cluster nodes can discover each other automatically.
** No configuration is required.
* No single point of failure
** No server or master is required for clustering
** The shared resource is distributed, hence we introduce no single point of failure.
* Provides distributed topics
** Using in memory distributed topics allows us to broadcast events/commands which are valuable for management and monitoring.

In other words, Hazelcast allows us to setup a cluster with zero configuration and no dependency to external
systems such as a database or a shared file system.

See the Hazelcast documentation at http://www.hazelcast.com/documentation.jsp for more information.