Durch Broker-Domänen unter Verwendung des Konfigurationsmanager-Proxys navigieren

Vorbereitungen:

Dieser Schritt setzt voraus, dass zunächst der unter Verbindungen zu einem Konfigurationsmanager unter Verwendung der Konfigurationsmanager-Proxy herstellen beschriebene Schritt ausgeführt wurde.

Jedes Domänenobjekt, das über den Konfigurationsmanager gesteuert wird, wird als einzelnes Objekt im Konfigurationsmanager-Proxy dargestellt. Dazu gehören:
  • Broker
  • Ausführungsgruppen
  • Implementierte Nachrichtenflüsse
  • Themen
  • Brokerverbünde
  • Subskriptionen
  • Publish/Subscribe-Topologie
  • Brokerereignisprotokoll

Das CMP verarbeitet auch implementierte Nachrichtensätze, obwohl diese als Attribute implementierter Ausführungsgruppen verarbeitet werden.

Diese Objekte, die alle zusammen als verwaltete Objekte bezeichnet werden, ergeben den Großteil der Schnittstelle zum Konfigurationsmanager. Daher sollte man sich mit diesen Objekten vertraut machen, um die Funktion der Konfigurationsmanager-Proxy-API zu verstehen.

Jedes verwaltete Objekt ist eine Instanz einer Java-Klasse, die den zugrundeliegenden Objekttyp im Konfigurationsmanager beschreibt. Die möglichen Java-Klassen sind:
Java-Klasse Klassenfunktion
TopologyProxy Beschreibt die Publish/Subscribe-Topologie.
CollectiveProxy Beschreibt die Publish/Subscribe-Brokerverbünde.
BrokerProxy Beschreibt Broker.
ExecutionGroupProxy Beschreibt Ausführungsgruppen.
MessageFlowProxy Beschreibt Nachrichtenflüsse, die bereits für Ausführungsgruppen implementiert sind; beschreibt KEINE Nachrichtenflüsse in der Toolkit-Perspektive 'Brokeranwendungsentwicklung'.
TopicProxy Beschreibt Themen.
TopicRootProxy Beschreibt das Stammverzeichnis der Themenhierarchie.
LogProxy Beschreibt das Ereignisprotokoll des Brokers für den aktuellen Benutzer.
SubscriptionsProxy Beschreibt eine Untergruppe der aktiven Subskriptionen.
ConfigManagerProxy Beschreibt des Konfigurationsmanager selbst.
Jedes verwaltete Objekt beschreibt ein einzelnes Objekt, das über den Konfigurationsmanager gesteuert wird. Es gibt beispielsweise für jeden Broker in einer Brokerdomäne jeweils eine BrokerProxy-Instanz, durch die er in einer CMP-Anwendung darstellt wird usw.

Für jedes verwaltete Objekt gibt es eine Gruppe von deklarierten allgemein zugänglichen Methoden, über die Programme Merkmale des zugrundeliegenden Konfigurationsmanager-Objekts, auf das die Instanz verweist, abfragen und bearbeiten können. Beispiel: Für ein BrokerProxy-Objekt, das auf Broker B1 verweist, können Methoden aufgerufen werden, über die der Ausführungsstatus des Brokers abgefragt werden kann, oder die den Broker dazu veranlassen, alle zugehörigen Nachrichtenflüsse zu starten usw.

Um auf ein verwaltetes Objekt zugreifen und die zugehörige API nutzen zu können, müssen Sie zunächst eine Kennung anfordern, und zwar von dem Objekt, das der logische Eigner des verwalteten Objekts ist. Beispiel: Da Broker die logischen Eigner von Ausführungsgruppen sind, muss die Anwendung zum Erlangen einer Kennung für Ausführungsgruppe EG1, die auf Broker B1 ausgeführt wird, eine Kennung für das ExecutionGroupProxy-Objekt, das durch EG1 dargestellt wird, vom BrokerProxy-Objekt, das durch B1 dargestellt wird, anfordern.

Im Beispiel ConnectToConfigManager wird eine Kennung für das ConfigManagerProxy-Objekt empfangen. Das ConfigManagerProxy-Objekt ist das logische Stammverzeichnis der Baumstruktur mit den verwalteten Objekten. Das bedeutet, dass von dort aus auf alle anderen Objekte im Konfigurationsmanager direkt oder indirekt zugegriffen werden kann. Der Konfigurationsmanager ist der direkte Eigner der Publish/Subscribe-Topologie, und daher gibt es eine Methode, über die Anwendungen vom ConfigManagerProxy-Objekt aus eine Kennung für das TopologyProxy-Objekt anfordern können. Ebenso ist die Topologie logischer Eigner aller Broker, so dass es möglich ist, Methoden auf dem TopologyProxy-Objekt für den Zugriff auf die BrokerProxy-Objekte aufzurufen. Die vollständige Hierarchie dieser Abhängigkeiten ist im Folgenden dargestellt:
Wenn man das Beispiel ConnectToConfigManager als Ausgangspunkt heranzieht, geht das folgende Programm die Hierarchie mit den verwalteten Objekten durch, um den Ausführungsstatus eines implementierten Nachrichtenflusses zu ermitteln. Beachten Sie, dass im Programm davon ausgegangen wird, dass der Nachrichtenfluss MF1 für EG1 auf Broker B1 implementiert wird, obwohl diese Werte im Code durch andere gültige Werte in der Domäne ersetzt werden können.
import com.ibm.broker.config.proxy.*;

public class GetMessageFlowRunState {

  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!");
      displayMessageFlowRunState(cmp, "B1", "EG1", "MF1");
      cmp.disconnect();
    }      
  }

  private static void displayMessageFlowRunState(
                                 ConfigManagerProxy cmp,
                                 String brokerName,
                                 String egName,
                                 String flowName) {
    try {
      TopologyProxy topology = cmp.getTopology();
            
      if (topology != null) {
        BrokerProxy b = topology.getBrokerByName(brokerName);

        if (b != null) {
          ExecutionGroupProxy eg =
            b.getExecutionGroupByName(egName);

          if (eg != null) {
            MessageFlowProxy mf =
              eg.getMessageFlowByName(flowName);

            if (mf != null) {
              boolean isRunning = mf.isRunning();
              System.out.print("Flow "+flowName+" on " +
                egName+" on "+brokerName+" is ");

              if (isRunning) {
                System.out.println("running");
              } else {
                System.out.println("stopped");
              }
            } else {
              System.err.println("No such flow "+flowName);
            }
          } else {
            System.err.println("No such exegrp "+egName+"!");
          }
        } else {
          System.err.println("No such broker "+brokerName);
        }
      } else {
        System.err.println("Topology not available!");
      }
    } catch(ConfigManagerProxyPropertyNotInitializedException
                                                      ex) {
      System.err.println("Comms problem! "+ex);
    }
  }
}
Die Methode displayMessageFlowRunState() führt den Großteil der auszuführenden Aktionen durch. Die Methode empfängt die zuvor angeforderte gültige ConfigManagerProxy-Kennung, und ermittelt den Ausführungsstatus des Nachrichtenflusses wie folgt:
  1. Die ConfigManagerProxy-Instanz wird verwendet, um eine Kennung für das TopologyProxy-Objekt zu erlangen. Da es nur eine Topologie pro Konfigurationsmanager gibt, ist die Angabe einer ID in der Methode getTopology() nicht erforderlich.
  2. Wenn eine gültige Topologie zurückgegeben wird, wird die TopologyProxy-Instanz dazu verwendet, für das zugehörige BrokerProxy-Objekt mit dem Namen, der durch die Zeichenfolge brokerName beschrieben wird, eine Kennung zu erlangen.
  3. Wenn ein gültiger Broker zurückgegeben wird, wird die BrokerProxy-Instanz dazu verwendet, für das zugehörige ExecutionGroupProxy-Objekt mit dem Namen, der durch die Zeichenfolge egName beschrieben wird, eine Kennung zu erlangen.
  4. Wenn eine gültige Ausführungsgruppe zurückgegeben wird, wird die ExecutionGroupProxy-Instanz dazu verwendet, für das zugehörige MessageFlowProxy-Objekt mit dem Namen, der durch die Zeichenfolge flowName beschrieben wird, eine Kennung zu erlangen.
  5. Wenn ein gültiger Nachrichtenfluss zurückgegeben wird, wird der Ausführungsstatus des MessageFlowProxy-Objekts abgefragt, und das Ergebnis angezeigt.
Sie brauchen die Namen der Objekte, die Sie bearbeiten möchten, nicht unbedingt zu kennen. Jedes verwaltete Objekt enthält Methoden, über die Mengen von Objekten zurückgegeben werden, deren Eigner das jeweilige verwaltete Objekt ist. Dies wird durch folgendes Beispiel, in dem die Namen aller Broker innerhalb der Domäne ermittelt werden, vorgeführt:
import java.util.Enumeration;
import com.ibm.broker.config.proxy.*;

public class DisplayBrokerNames {

  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!");
      displayBrokerNames(cmp);
      cmp.disconnect();
    }
  }

  private static void displayBrokerNames(ConfigManagerProxy cmp)
  {
    try {
      TopologyProxy topology = cmp.getTopology();
            
      if (topology != null) {
        Enumeration allBrokers = topology.getBrokers(null);
        
        while (allBrokers.hasMoreElements()) {
          BrokerProxy thisBroker =
            (BrokerProxy) allBrokers.nextElement();
          System.out.println("Broker "+thisBroker.getName());
        }
      }
    } catch(ConfigManagerProxyPropertyNotInitializedException
                                                      ex) {
        System.err.println("Comms problem! "+ex);
    }
  }
}
Die Methode TopologyProxy.getBrokers(Merkmale) ist die Schlüsselmethode. Bei Angabe eines Nullarguments gibt die Methode eine Aufzählung aller BrokerProxy-Objekte in der Domäne zurück. Das Programm verwendet diese Methode, um alle BrokerProxy-Objekte nacheinander zu suchen und die zugehörigen Namen anzuzeigen.

Mit dem Argument "Merkmale" der Methode TopologyProxy.getBrokers(Merkmale) können die Kenndaten der gesuchten Broker genau angegeben werden. Dies ist für nahezu alle Methoden, die verwaltete Objekte zurückgeben, möglich, und ermöglicht die effektive Filterung von Objekten, mit denen das Programm arbeiten muss.

Beispiele für Merkmale, die zum Filtern einer Objektsuche angegeben werden können, sind der Ausführungsstatus, die Kurzbeschreibung oder offensichtlichere Merkmale wie der Name und die UUID. Damit Sie die entsprechende Logik erstellen können, müssen Sie wissen, wie Informationen in den jeweiligen verwalteten Objekten gespeichert werden.

Die Merkmale eines verwalteten Objekts werden lokal im Objekt unter Verwendung einer Hashtabelle gespeichert, wobei jedes Merkmal als {Schlüssel, Wert}-Tupel dargestellt ist. Jeder Schlüssel entspricht dem Namen eines Attributs (z. B. Name), und jeder Wert entspricht dem Wert (z. B. BROKER1).

Für jeden Schlüsselnamen muss eine Konstante aus der AttributeConstants-Klasse verwendet werden (com.ibm.broker.config.proxy). Eine vollständige Liste mit den Schlüsseln und gültigen Werten für die jeweiligen verwalteten Objekte finden Sie in der Java-Dokumentation zu AttributesConstant-Klassen. Alternativ hierzu können Sie die Funktion Show raw property table for this object (Tabelle mit unformatierten Merkmalen für dieses Objekt anzeigen) im Konfigurationsmanager-Proxy-API-Testprogramm verwenden. Wenn Sie die Funktion aufrufen, wird eine vollständige Auflistung der {Schlüssel, Wert}-Paare für die jeweiligen verwalteten Objekte angezeigt.

Das Argument "Merkmale" in den Suchmethoden ist eine Gruppe dieser {Schlüssel, Wert}-Paare, die in jedem verwalteten Objekt in der zurückgegebenen Aufzählung enthalten sein muss. Sehen Sie sich folgendes Codefragment zur Veranschaulichung an:
Properties p = new Properties();
        
p.setProperty(AttributeConstants.OBJECT_RUNSTATE_PROPERTY,
              AttributeConstants.OBJECT_RUNSTATE_RUNNING);

Enumeration e = executionGroup.getMessageFlows(p);
Vorausgesetzt, dass die Variable executionGroup ein gültiges ExecutionGroupProxy-Objekt ist, enthält die zurückgegebene Aufzählung ausschließlich aktive Nachrichtenflüsse (OBJECT_RUN_STATE_PROPERTY entspricht OBJECT_RUNSTATE_RUNNING).
Wenn bei Ausführung einer Methode, die ein einziges Objekt und keine Aufzählung von Objekten zurückgibt, nach Merkmalen gefiltert wird, wird nur das erste Ergebnis zurückgegeben (bei mehr als einer Übereinstimmung ist dies nicht deterministisch). Dies bedeutet, dass
Properties p = new Properties();

p.setProperty(AttributeConstants.NAME_PROPERTY,
              "shares");

TopicProxy t = topicProxy.getTopic(p);
eine Alternative zu Folgendem ist:
TopicProxy t = topicProxy.getTopicByName("shares");

Wenn mehrere {Schlüssel, Wert}-Paare zu einem Merkmalfilter hinzugefügt werden, müssen, damit ein Objekt passt, alle Merkmale im untergeordneten Objekt enthalten sein. Sie können keine logische OR- oder NOT-Operation für einen Filter ausführen. Hierzu müssen Sie einen speziellen Anwendungscode schreiben.

Wenn AdministeredObjects in einer Anwendung zum ersten Mal instanziiert werden, fordert das CMP die Merkmale für dieses Objekt vom Konfigurationsmanager an. Diese Vorgänge laufen asynchron ab, d. h., wenn ein Merkmal zum ersten Mal angefordert wird, wird die Ausführung möglicherweise angehalten, während der CMP auf die Informationen, die vom Konfigurationsmanager zurückgegeben werden, wartet. Wenn die Informationen nicht nach Ablauf eines bestimmten Intervalls zurückgegeben werden (weil beispielsweise der Konfigurationsmanager inaktiv ist), wird die Ausnahmebedingung ConfigManagerProxyPropertyNotInitializedException ausgegeben. Die maximale Wartezeit des CMPs wird durch die Methode ConfigManagerProxy.setRetryCharacteristics() bestimmt.

Zugehörige Tasks
Umgebung für das Entwickeln und Ausführen von Konfigurationsmanager-Proxy-Anwendungen konfigurieren
Verbindungen zu einem Konfigurationsmanager unter Verwendung der Konfigurationsmanager-Proxy herstellen
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ae33040_