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.

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.