Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Heartbeats, a common software construct, verify the continual operation of a specific component or service. With heartbeats, a targeted service continually broadcasts a signal across its environment. You can assume your system works normally when your client services can detect a targeted service's heartbeat signals. Meanwhile, if the critical heartbeat signal ceases, each component knows how to react.
As a heartbeat example, consider a backend market-price publisher that publishes realtime prices to other services on the network, as Figure 1 shows. Because a pause in price publishing could indicate either a legitimate market pause or a system problem resulting in stale price information, it's critical that other services receive proper system status information.
Figure 1. Messaging architecture scenario
To avoid stale price information, the publisher periodically issues a heartbeat signal to the client services, keeping them informed of its status. If the heartbeat signal ends, the system's customer inquiry module might warn the customer of the stale price information, but will resume shortly. Meanwhile, the application's risk management system would suspend other transactions until the publisher resumes publishing current prices.
I recently used a similar setup with a series of interdependent components such that, if one failed, the others received notification. Because the system employed JMS (Java Message Service) as a core component, I used JMS messaging as a way to transmit heartbeats between components.
However, at the project's start, I didn't realize the critical nature of the interdependencies, so a proprietary heartbeat, implemented differently each time, supported each relationship. Figure 2 shows the result.
Figure 2. The initial heartbeat implementation
All right, I exaggerate a bit. However, that would have been the result had I not implemented a different system.
In many systems, particularly high-availability operating systems, developers implement heartbeats using multicast -- suitable for broadcasting an "I'm still here!" signal, but not necessarily for targeting a specific process or consumer.
However, a JMS-based heartbeat system, as Figure 3 shows, proves ideal for periodically determining whether the overall system -- the network, the JMS server, the JVM, and so on -- remains in operation. Moreover, with a JMS-based solution, you can test the availability of other resources (see the "Dependent Publishers" section below).
Figure 3. The publish/subscribe heartbeat architecture
With my JMS-based solution, each critical component publishes a heartbeat to an exclusive known topic, and any interested client components receive the heartbeats by subscribing to that topic. Further, the publisher need not know the subscribers' nature or number. By choosing a JMS-based approach, my solution became simple, portable, reusable, and scalable.
To keep things simple and to promote reuse, I've supplied several base components.