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