The notification broadcasters are MBeans registered in an agent's MBean server to which our management application will need to connect. Only notifications sent by registered MBeans can be forwarded to manager applications, and a manager-side listener can receive them only by registering through a connector client or a proxy object.
Other notification broadcasters may exist independently in the manager application, but listeners will need to register directly with these local broadcasters. Nothing prevents a listener object from registering with both a connector client or proxy for remote notifications and with a local broadcaster.
The code example below shows how the sample NotificationEmitter MBean will send notifications (the code for its MBean interface has been omitted). It extends the NotificationBroadcasterSupport class to reuse all of its listener registration facilities. It only contains one operation which can be called by our manager to trigger any number of notifications.
import javax.management.MBeanNotificationInfo; import javax.management.NotificationBroadcasterSupport; import javax.management.Notification; public class NotificationEmitter extends NotificationBroadcasterSupport implements NotificationEmitterMBean { // Just to make the inheritance explicit public NotificationEmitter() { super(); } // Provide details about the notification type and class that is sent public MBeanNotificationInfo[] getNotificationInfo() { MBeanNotificationInfo[] ntfInfoArray = new MBeanNotificationInfo[1]; String[] ntfTypes = new String[1]; ntfTypes[0] = myType; ntfInfoArray[0] = new MBeanNotificationInfo( ntfTypes, "javax.management.Notification", "Notifications sent by the NotificationEmitter"); return ntfInfoArray; } // The only operation: sends any number of notifications // whose sequence numbers go from 1 to "nb" public void sendNotifications( Integer nb ) { for (int i=1; i<=nb.intValue(); i++) { sendNotification(new Notification(myType, this, i)); } } private String myType = "notification.my_notification"; } |
Our MBean invents a notification type string and exposes this information through the getNotificationInfo method. To demonstrate the forwarding mechanism, we are more interested in the sequence number: this will allow us to identify the notifications as they are received in the manager.
This MBean demonstrates that the broadcaster has total control over the contents of its notifications. Constructors for the Notification object allow you to specify all of the fields, even ones such as the time stamp. In this example, we control the sequence number, and our chosen policy is to reset the sequence number to 1 with every call to the operation. Of course, you are free to choose the notification contents, including the time-stamping and sequence-numbering policies that fit your management solution.
Due to possible loss in the communication layer and the inherent indeterminism of thread execution, the notification model does not guarantee that remote notifications will be received nor that their sequence will be preserved. If notification order is critical to your application, your broadcaster should set the sequence numbers appropriately, and your listeners should sort the received notifications.