The Notification Model

The JMX architecture defines a notification model that enables MBeans to broadcast notifications. Management applications and other objects register as listeners with the broadcaster MBean. In this way, MBeans can signal asynchronous events to any interested parties.

The JMX notification model enables a listener to register only once and still receive all the various notifications that an MBean can broadcast. A listener object can also register with any number of broadcasters, but it must then sort all notifications it receives according to their source.

Local Notification Listeners

In the simplest case, listeners are objects in the same application as the broadcaster MBean. The listener is registered by calling the addNotificationListener method on the MBean. The MBean server exposes the same method so that listeners can also be added to an MBean identified by its symbolic name.

In Figure 2–2, one listener has registered directly with the MBean and another has registered through the MBean server. The end result is the same, and both listeners will receive the same notifications directly from the broadcaster MBean.

Figure 2–2 Adding Local Listeners on the Agent Side

Remote Notification Listeners

The connector client interface also exposes the addNotificationListener method so that notifications can be received in remote management applications. Standard proxies expose this method as well and transmit any listener registrations through the connector client.

Listeners do not need to be aware that they are remote. The connector transmits registration requests and forwards notifications back to the listeners. The whole process is transparent to the listener and to the management components.

As shown in Figure 2–3, the connector components implement a complex mechanism for registering remote listeners and forwarding notifications. Because notifications are based on the Java event model, broadcasters cannot send notifications outside their Java virtual machine. So the connector server instantiates local listeners that receive all notifications and place them in a cache buffer, waiting to be sent to the manager application. The enables the connector to avoid saturating the communication layer in case of a burst of notifications.

Figure 2–3 Adding Remote Listeners on the Manager Side

Notifications either can be pushed from the agent to the connector client as they are received, or they can be pulled periodically at the client's request. The pushing mechanism is the simplest, but the pull mechanism can be used to group notifications and reduce bandwidth usage. In either case the connector client then acts as a broadcaster and sends the notifications to their intended listeners.

The management application configures the forwarding mechanism through the connector client. The manager can choose either push or pull mode, and in pull mode it can set the pull interval and the caching policy. The manager should set these parameters according to the notification emission rate, to avoid saturating the communication layer and yet receive notifications in a timely manner.