Java.next -- Four languages that represent the future of Java
Blogger Stuart Halloway has begun a series of posts on trends that point to the future of the Java platform. In his first post, he compares Clojure, Groovy, JRuby, and Scala -- four wildly different languages that nonetheless all play together in the JRE. Find out what unites these languages and what they can tell us about the future of Java-based development ...

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Enterprise Edition >

Listen to heartbeats using JMS

Extend heartbeats using JMS publish and subscribe

By Nicholas Whitehead, JavaWorld.com, 03/15/02

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.

Background

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.

The heartbeat class library's functional components

To keep things simple and to promote reuse, I've supplied several base components.

Resources