The Notification Model

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

The JMX notification model enables a listener to register only once and still receive all different notifications that an MBean may broadcast. A listener object may 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 may also be added to an MBean identified by its symbolic name.

Figure 2-2 Adding Local Listeners on the Agent Side

In the figure above, 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.

Remote Notification Listeners

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

Listeners do not need to be aware of the fact 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.

Figure 2-3 Adding Remote Listeners on the Manager Side

As shown in the figure above, the connector components implement a complex mechanism for registering remote listeners and forwarding notifications. Since notifications are based on the Java event model, broadcasters cannot send notifications outside their Java VM. So the connector server instantiates local listeners who receive all notifications an place them in an cache buffer, waiting to be sent to the manager application. The buffer allows the connector to avoid saturating the communication layer in case of a burst of notifications.

Notifications can either 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, in order to avoid saturating the communication layer and yet receive notifications in a timely manner.