|
|
8.1 Overview
8.2 Implementing Notifications
Management applications need to react to a state change or to a specific condition when it occurs in an underlying resource. XMOJO JMX implementation supports JMX Notification Model which allows MBeans to broadcast such management events, which are called Notifications. To receive the broadcasted Notifications, management applications and other objects register as listeners with the broadcaster MBean. The MBean notification model of JMX enables a listener to register only once and still receive all different events that may occur in the broadcaster.
The JMX notification model relies on the following components:
A generic event type, Notification which can signal any type of management event. The notification event may be used directly or subclassed, depending on the information that needs to be conveyed with the event.
The NotificationBroadcaster interface, which needs to be implemented by each MBean wanting to emit notifications. This listeners to get registered to it to receive the notifications emitted by an MBean.
The NotificationListenerInterface , which needs to be implemented by the objects requesting to receive notifications sent by MBeans. The notification model allows a listener to receive all types of events from a broadcaster.
The NotificationFilter interface, which needs to be implemented by objects that act as notification filter. This interface lets the notification listener provide a filter to be applied to notifications emitted by an MBean to specify only those events that are needed. Using a filter, a listener only needs to register once in order to receive all selected events of an MBean.
Any type of MBean, standard or dynamic, may be a notification broadcaster, a notification listener, or both at the same time. Notification filters are usually implemented as callback methods of the listener itself, but this is not a requirement. A JMX Notification event is generated for all the supported protocols namely SNMP, HTML, HTTP, RMI, CORBA, and TL1.
This may lead to a special case of a Standard MBean, which has an empty management interface: its role as a manageable resource is to be a broadcaster of Notifications. It must be a concrete class with a public constructor, and it must implement an MBean interface, which in this case defines no methods. The only method in its class is those implementing the NotificationBroadcaster interface. This MBean may be registered in a Multi-Protocol agent, and its management interface contains only the list of notifications that it may send.
8.2 Implementing Notifications
An MBean wanting to emit notifications must implement the NotificationBroadcaster Interface. This interface may be implemented by any type of MBean. This interface specifies three methods, which MBeans acting as notification broadcasters must implement:
Adding Notification Listeners
Getting Notification Information
Removing a Notification Listener
Adding Notification Listeners
Any notification that is emitted must be received at the other end. The objects that are configured to receive these notifications are called Listeners. These Listeners must be registered with the Notification broadcaster to receive the notification. A listener is registered when it has been added to the broadcaster’s list of notification recipients.
The method addNotificationListener() available in the NotificationBroadcaster Interface is used to add a listener to to the broadcaster’s list of notification recipients. When the broadcaster sends a notification, it will send it to all listeners that are currently registered through this interface.
The addNotificationListener() method takes the following parameters:
The NotificationListener object, which implements the NotificationListener interface. This object will handle notifications emitted by the registered MBean.
Notification Listener Interface
This interface must be implemented by all objects interested in receiving notifications sent by any broadcaster. This interface defines a unique callback method, handleNotification(), which will be invoked by a broadcaster MBean when it emits a notification.
Besides the Notification object, the listener’s hand-back object is passed as an argument to the 'handleNotification' method. This is a reference to the same object that the listener provided upon registration. It is stored by the broadcaster and returned unchanged with each notification.
Because all notifications are characterized by their type string, notification listeners implement only one handler method for receiving all notifications from all potential broadcasters. This method should then rely on the type string, other fields of the notification object, and on the hand-back object to determine the broadcaster and the meaning of the notification.
The NotificationFilter object, which implements the Notification Filter Interface. If filter is defined, it prevents the handler from receiving unwanted notifications. If not, no filtering will be performed before handling notifications.
Notification Filter Interface
This interface is implemented by objects acting as a notification
filter. It defines a unique method, isNotificationEnabled, which
will be invoked by the broadcaster before it emits a notification. This
method takes the Notification object that the broadcaster intends to emit
and, based on its contents, returns true or false, indicating whether
or not the listener should receive this notification.
The filter object is provided by the listener when it registers
for notifications with the broadcaster. Each listener may provide its
own filter. The broadcaster must apply each listener’s filter, if defined,
before calling the handleNotification method of the corresponding listener.
Listeners rely on the filter to screen all possible notifications
and handle only the ones in which they are interested. An object may be
both a listener and a filter by implementing both the NotificationListener
and the NotificationFilter interfaces. In this case, the object reference
will be given for both the listener and the filter object when registering
it with a broadcaster.
The hand-back object, which is the context to be sent to the listener when a notification is emitted. The hand-back object is provided by the listener upon registration and is opaque to the broadcaster MBean. The implementation of the broadcaster interface must store this object and return its reference to the listener with each notification. This hand-back object can allow the listener to retrieve context information for use while processing the notification. The same listener object may be registered more than once, each time with a different hand-back object. This means that the handleNotification method of this listener will be invoked several times, with different hand-back objects.
The Notification MBean has to maintain a table of listener, filter, and hand-back objects. When the MBean emits a notification, it invokes the handleNotification method of all the registered NotificationListener objects, with their respective hand-back object.
Getting Notification Information
The method getNotificationInfo() in the NotificationBroadcaster Interface gives a potential listener the description of all notifications this broadcaster may emit. This method returns an array of MBeanNotificationInfo objects, each of which describes a notification.
Removing a Notification Listener
The method removeNotificationListener() in the NotificationBroadcaster Interface unregisters the listener from a notification broadcaster. This method takes a reference to a NotificationListener object, as well as a hand-back object.
If the hand-back object is provided, only the entry corresponding to this listener and hand-back pair will be removed. The same listener object may still be registered with other hand-back objects. If the hand-back is not provided, all entries corresponding to the listener will be removed.
|
|
Note: As an alternative method of implementing Notifications, an MBean wanting to emit Notification can extend the Class NotificationBroadcasterSupport which implements the NotificationBroadcaster Interface |
The type of the Notification is assigned by the broadcaster object and conveys the semantic meaning of a particular notification. The type is given as a String field of the Notification object. This string is interpreted as any number of dot-separated components, allowing an arbitrary, user-defined structure in the naming of notification types.
All notification types prefixed by “jmx.” are reserved for the notifications emitted by the components of the JMX infrastructure defined in the specification, such as:
JMX.mbean.registered
JMX.mbean.unregistered
Otherwise, notification broadcasters are free to define all types they wish to use when naming the notifications they emit. Usually, MBeans will use type strings that reflect the nature of their notifications within the larger management structure in which they are involved.
Notifications are send to all listeners registered with the Notification Broadcaster on the occurrence of an event. The event may be a change in state of managed resource or occurrence of a specific condition. This is implementation specific.
To send Notifications, follow the steps given below:
Define the Notification : The Notification class represents a notification emitted by an MBean. It contains the necessary methods to create the notification object.
|
public Notification(java.lang.String type, java.lang.Object source, long sequenceNumber, long timeStamp, java.lang.String message) |
A Notification message format contains the following details:
Notification Type;- The Type specified in the notification. It may be a standard notification type or user defined.
Notification Source Object - The source from where the notification is emitted.
Notification Sequence Number;- The notification sequence number within the source object.
Notification Time Stamp - The date when the notification was emitted.
Notification Message - A detailed message about the notification.
Call the sendNotification() method of the registered listeners, passing the defined notification. This method can be called from anywhere from the MBean which is a Notification Broadcaster. For example, if you want to send a Notification when a get method is invoked on Attribute xxx, you have to define the Notification and call the sendNotification() method in the get method generated for xxx.
The Notification mechanism is designed to forward only notifications from registered MBeans on the agent side to proper listeners on the manager side.
Viewing Notifications Through RMI/CORBA/HTTP Adaptors
Start the Multi-Protocol agent . The agent gets started with Corba service at default port 1050, RMI server at port 1099 and HTTP Server at port 8050.
Start the MBean browser using the MBeanBrowser.bat/MBeanBrowser.sh file in the <Agent Toolkit Home><bin> directory.
Select "RMI client" in the remote browser and click "connect" button; it gets connected to the Multi-Protocol agent using the RMI protocol.
Select the View -> Notification option to view the notification details generated by the agent.
Similarly, you can connect to the CORBA client/HTTP client and view the generated notifications.
.
Viewing Notifications Through SNMP Adaptor
Start the Multi-Protocol agent . The agent gets started with SNMP service at default port 8001.
Start the MIB Browser using the MibBrowser.bat/MibBrowser.sh file in the <Agent Toolkit Home>/bin directory.
Select View -> Trap Vieweroption or Trap Viewer icon Set the port to 8003 in Trap Viewer. ClickStart button.
The traps emitted will be listed in the trap viewer as shown below.
Viewing Notifications Through TL1 Adaptor
Start the Multi-Protocol agent . The agent gets started with TL1 service at default port 9099.
Start the TL1 Browser using the TL1Browser.bat/TL1Browser.sh file in the <Agent Toolkit Home>/bin directory.
Load command set file and corresponding data set file, which is under ./<projectName>/tcs directory by selecting File -> Load option or icon. Click O.K to add it to the TL1 tree.
Load tl1security.tcs file to login to the TL1 Agent.
Choose Operations -> Connect option in the menu bar. Enter the Host Name and Port Number where the agent is running. Click OK. Now, you will be connected to the Agent.
Authenticate into the TL1 Agent using the command ACT-USER in the TL1 Security tree. The default user name and the password for the Administrator are "root" and "public" respectively. Hence, select ACT-USER command and specify the user name as root in the AID block and the password (PID) public in the MPB block.
After entering the user name and the password values, send the input message by selecting Operations -> Send from the menu bar.
The autonomous message will be displayed as shown below:
|
|
