In order to provide scalability, HACEP core code leverages JGroups for multicast communication between nodes. From a clustering perspective, JGroups provides leadership election among nodes as well as notification of addition and removal of nodes which allows the core code to properly implement fault tolerance and distribution of responsibilities among the various members in the cluster. JGroups is leveraged internally by the data grid for cross-network communication in HACEP’s distributed topology.

As mentioned previously, camel routes are used as a means of communicating with the Event Channel, serving as the inbound origin point of rule-related events. The core HACEP code establishes a route with a JMS endpoint from which a configurable amount of concurrent consumers will take in events from the channel and relay them to the in-memory data grid.

In cases where nodes are added or taken away from a HACEP cluster, the internal camel configuration allows for pause of route functionality while session node ownership and distribution is dealt with internally before resuming operations.

The HACEP framework was born out of a desire to leverage the complex event processing (CEP) capabilities of the JBoss Business Rule Management System (BRMS) in such a way as to meet the expectations and requirements of enterprise-level applications. While the rules engine itself lends to a rather large breadth of CEP functionality, in and of itself worthy of significant documentation, it offers nothing out-of-the-box which assists in high-availability or scalability. At the heart of HACEP, events from the inbound Event Channel are fed to distributed, replicated, CEP-capable BRMS rules sessions, where they are processed in order to facilitate some decision process defined by rules, typically authored by application developers, business users, or stake owners.

The distributed in-memory key/value data store product is used to facilitate cross-node replication of key objects such as inbound event facts and rule sessions. With HACEP, Infinispan as delivered by JDG is used in a distributed topology with the Grouping API enabled, allowing "ownership" of sessions by HACEP nodes in relation to data affinity. HACEP uses two caches called "event" (for holding facts) and "session" within the grid. The data grid internally uses JGroups for cross-node multicast communication.

Currently, HACEP core code only requires that an Event Channel server be JMS-compliant and include the JMSXGroupId attribute on all inbound events. The former ensures assumed Camel routing functionality is possible, while the latter is used for node ownership identification. In this reference architecture, a JBoss A-MQ cluster is used for the Event Channel for both the example applications included in the HACEP source code as well as for the example integration application detailed in later chapters.

In future HACEP versions, optimizations are planned to use A-MQ-based systems exclusively for the Event Channel so that the grouping algorithm used for message delivery can be mated with the one utilized by the internal data grid, making direct delivery of events to relevant nodes possible and furthering data affinity.

The JBoss A-MQ cluster used within this reference architecture relies on a ZooKeeper-based replicated LevelDB Store for master/slave coordination and redundancy. Note that this is only one of various replication strategies provided by A-MQ. Officially as of the time of writing, support within the A-MQ cluster for this specific LevelDB strategy is included as technical preview only, but given that the Event Channel configuration largely stands independently of HACEP core code, the replicated LevelDB store is utilized here as a safe example configuration which can easily be swapped to any of the other provided solutions at the behest of application and environment requirements and consistent with enterprise support.