WebSphere Message Brokers
File: ae33090_
Writer: John Cooper

Task topic

This build: July 31, 2007 21:29:02

Checking the results of broker domain management using the Configuration Manager Proxy with object notification

This is part of the larger task of developing Configuration Manager Proxy (CMP) applications.

It is possible to notify applications whenever commands complete, or whenever changes occur to administered objects. By making use of the OBSERVER design pattern, it is possible to supply the CMP with a handle to a user-supplied object that has a specific method invoked if an object is modified, deleted, or whenever a response to a previously submitted action is returned from the Configuration Manager.

The user-supplied code must implement the AdministeredObjectListener interface. It defines methods that are invoked by the CMP when an event occurs on an administered object to which the listener is registered. These methods are:
  • processModify(…)
  • processDelete(…)
  • processActionResponse(…)
processModify(…) is invoked whenever the administered object to which the listener is registered has one or more of its attributes modified by the Configuration Manager. Information supplied on this notification, through the use of the processModify() method arguments are a:
  1. Handle to the AdministeredObject to which the notification refers.
  2. List of strings containing the key names that have been changed.
  3. List of strings describing any new subcomponents that have just been created for the object, for example, new execution groups in a broker.
  4. List of strings describing any subcomponents that have just been removed for the object.
The format of the strings passed to the final two parameters is an internal representation of the administered object. It is possible to turn this representation into an administered object type by using the getSubcomponentFromString() method.
Note:
  1. Strings are passed within these lists to enhance performance; the CMP does not use resource instantiating administered objects unless they are specifically requested by the calling application.
  2. The first time you call the processModify() method for a listener, the changed attributes parameter can include a complete set of attribute names for the object, if the application is using a batch method, or if the CMP is experiencing communication problems with the Configuration Manager.

processDelete(…) is invoked if the object with which the listener is registered is completely removed from the Configuration Manager. Supplied to processDelete(…) is one parameter – a handle to the administered object that has been deleted; once this method returns, the administered object handle might no longer be valid. Around the same time that a processDelete(…) event occurs, a processModify(…) event is sent to listeners of the deleted object's parent, to announce a change in the parent's list of subcomponents.

processActionResponse(…) is the event that informs the application that a previous action submitted by that application is complete, and there is only one processActionResponse(…) event received for each state-changing operation issued by the CMP application. Supplied to this event are the following pieces of information:
  1. A handle to the administered object for which a request was submitted.
  2. The completion code of the request.
  3. A set of zero, or more, informational (BIP) messages associated with the result.
  4. A set of (key, value) pairs that describes the submitted request in more detail.
Consult the Configuration Manager Proxy API Reference for information on parsing the pairs in the last parameter.

In order to register a listener, each administered object has a registerListener() method that is used to tell the CMP to call the supplied code whenever an event occurs on that object. It is possible to register the same AdministeredObjectListener for notifications from multiple administered objects. In addition, it is possible to register multiple AdministeredObjectListeners against the same administered object.

The following example demonstrates this by registering a listener on the topology object and displaying a message whenever it is modified:
import com.ibm.broker.config.proxy.*;
import com.ibm.broker.config.common.CompletionCodeType;
import java.util.List;
import java.util.ListIterator;
import java.util.Properties;

public class MonitorTopology implements AdministeredObjectListener {

  public static void main(String[] args) {
        
    ConfigManagerProxy cmp = null;
    try {
      ConfigManagerConnectionParameters cmcp =
         new MQConfigManagerConnectionParameters(
           "localhost",
           1414,
           "");
      cmp = ConfigManagerProxy.getInstance(cmcp);   
    } catch (ConfigManagerProxyException cmpex) {
      System.out.println("Error connecting: "+cmpex);
    }
        
    if (cmp != null) {
      System.out.println("Connected to Config Manager!");
      TopologyProxy topology = cmp.getTopology();
      listenForChanges(topology);
      cmp.disconnect();
    }
  }

  private static void listenForChanges(AdministeredObject obj)
  {
    try {
      if (obj != null) {
      	obj.registerListener(new MonitorTopology());
      	while(true) {
         // thread could do something else here instead
      	  try {
      	    Thread.sleep(10000);
      	  } catch (InterruptedException ex) {
      	    // ignore
      	  }
        }
      }
    } catch(ConfigManagerProxyPropertyNotInitializedException
                                                      ex) {
        System.err.println("Comms problem! "+ex);
    }    
  }
  
  public void processActionResponse(AdministeredObject obj,
                                    CompletionCodeType cc,
                                    List bipMessages,
                                    Properties refProperties) {
    // Event ignored in this example
  }
  
  public void processDelete(AdministeredObject deletedObject) {
  	// Event ignored in this example
  }
  
  public void processModify(AdministeredObject affectedObject,
                            List changedAttributes,
                            List newChildren,
                            List removedChildren) {

    System.out.println(affectedObject+" has changed:");
    ListIterator e = changedAttributes.listIterator();
    while (e.hasNext()) {
      String changedAttribute = (String) e.next();
      System.out.println("Changed: "+changedAttribute);
    }
    ListIterator e2 = newChildren.listIterator();
    while (e2.hasNext()) {
      String newChildStr = (String) e2.next();
      AdministeredObject newChild =
        affectedObject.getSubcomponentFromString(newChildStr);
      System.out.println("New child: "+newChild);
    }
    ListIterator e3 = removedChildren.listIterator();
    while (e3.hasNext()) {
      String remChildStr = (String) e3.next();
      AdministeredObject removedChild =
        affectedObject.getSubcomponentFromString(remChildStr);
      System.out.println("Removed child: "+removedChild);
    }

  }
}

The listenForChanges() method attempts to register an instance of the MonitorTopology class for notifications of topology changes. If successful, the main thread pauses indefinitely to prevent the application from exiting once the method returns. Once the listener is registered, whenever the topology changes - for example, if a broker is added - the processModify() method is called. This displays details of each notification on the screen.

There are three ways to stop receiving notifications:
  • AdministeredObject.deregisterListener(AdministeredObjectListener)
  • ConfigManagerProxy.deregisterListeners()
  • ConfigManagerProxy.disconnect()
The first method de-registers a single listener from a single administered object; the other two methods deregister all listeners connected with that ConfigManagerProxy instance. In addition, the final method shows that all listeners are implicitly removed when connection to the Configuration Manager is stopped.
Note: You can also implement the AdvancedAdministeredObjectListener interface which, when registered, yields additional information to applications.
Related tasks
Checking the results of broker domain management using the Configuration Manager Proxy
Checking the results of broker domain management using the Configuration Manager Proxy with return codes
Checking the results of broker domain management using the Configuration Manager Proxy with the last completion code
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2007Copyright IBM Corporation 1999, 2007. All Rights Reserved.
This build: July 31, 2007 21:29:02

ae33090_ This topic's URL is: