2.4 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.

2.4.1 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 receive the same notifications directly from the broadcaster MBean.

Figure 2–2 Adding Local Listeners on the Agent Side

2.4.2 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 places them in a cache buffer, to wait to be sent to the manager application. This 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 in the new RMI and JMXMP connectors are pulled periodically at the client's request. The pull mechanism is used to group notifications and reduce bandwidth usage. The connector client acts as a broadcaster and sends the notifications to their intended listeners.

Notifications in the legacy RMI and HTTP connectors are pulled in the same way as the new connectors. However, the legacy connector notifications can also can be pushed from the agent to the connector client as they are received.