Navigazione nei domini broker mediante Proxy di Gestione configurazione

Prima di iniziare

Prima di eseguire questo passo, è necessario aver completato Connessione a Gestione configurazione mediante il Proxy di Gestione configurazione.

Ciascun oggetto del dominio che può essere controllato da Gestione configurazione è rappresentato come oggetto singolo in CMP (Configuration Manager Proxy/Proxy di Gestione configurazione) ed include:
  • Broker
  • Gruppi di esecuzione
  • flussi di messaggi distribuiti
  • Argomenti
  • Collettivi
  • Sottoscrizioni
  • Topologia di pubblicazione/sottoscrizione
  • Registrazione eventi del broker

CMP inoltre gestisce le serie di messaggi distribuite, sebbene queste siano gestite come attributi dei gruppi di esecuzione distribuiti.

Tali oggetti, conosciuti come oggetti gestiti, forniscono la maggior parte dell'interfaccia per Gestione configurazione e quindi sono fondamentali per la comprensione dell'API Proxy di Gestione configurazione.

Ciascun oggetto gestito è una istanza di una classe Java che descrive il tipo di oggetto sottostante in Gestione configurazione. Di seguito sono riportate le classi Java possibili:
Classe Java Funzione della classe
TopologyProxy Descrive la topologia di pubblicazione/sottoscrizione.
CollectiveProxy Descrive i collettivi di pubblicazione/sottoscrizione.
BrokerProxy Descrive i broker.
ExecutionGroupProxy Descrive i gruppi di esecuzione.
MessageFlowProxy Descrive i flussi di messaggi già distribuiti ai gruppi di esecuzione; NON descrive i flussi di messaggi nella prospettiva Sviluppo dell'applicazione broker del toolkit.
TopicProxy Descrive gli argomenti.
TopicRootProxy Descrive la parte principale della gerarchia dell'argomento.
LogProxy Descrive la registrazione eventi del broker per l'utente corrente.
SubscriptionsProxy Descrive una serie secondaria delle sottoscrizioni attive.
ConfigManagerProxy Descrive Gestione configurazione.
Ciascun oggetto gestito descrive un singolo oggetto controllabile da Gestione configurazione. Ad esempio, ogni broker all'interno di un dominio broker avrà una istanza BrokerProxy che lo rappresenta all'interno dell'applicazione CMP e così via.

In ciascun oggetto gestito è dichiarato un insieme di metodi pubblici che i programmi possono utilizzare per gestire le proprietà dell'oggetto Gestione configurazione sottostante a cui l'istanza fa riferimento. Ad esempio, su un oggetto BrokerProxy che fa riferimento al broker B1, è possibile richiamare metodi che impongono al broker di rivelare il proprio stato di esecuzione oppure di avviare tutti i propri flussi di messaggi e così via.

Per accedere ad un oggetto gestito ed utilizzare la relativa API, è necessario prima richiedere un handle dall'oggetto che lo possiede logicamente. Ad esempio, poiché i broker possiedono logicamente i gruppi di esecuzione, per ottenere un handle per il gruppo di esecuzione EG1 in esecuzione sul broker B1 l'applicazione deve richiedere all'oggetto BrokerProxy rappresentato da B1 un handle per l'oggetto ExecutionGroupProxy rappresentato da EG1.

Nell'esempio ConnectToConfigManager, l'handle viene fornito all'oggetto ConfigManagerProxy. ConfigManagerProxy è logicamente la parte principale della struttura degli oggetti gestiti; ciò significa che tutti gli altri oggetti in Gestione configurazione sono direttamente o indirettamente accessibili da essa. Gestione configurazione possiede direttamente la topologia di pubblicazione/sottoscrizione, per cui esiste un metodo che le applicazioni possono richiamare da ConfigManagerProxy per ottenere un handle all'oggetto TopologyProxy. Allo stesso modo, la topologia contiene logicamente l'insieme di tutti i broker, per cui è possibile richiamare i metodi sull'oggetto TopologyProxy per accedere agli oggetti BrokerProxy. Di seguito è riportata la gerarchia completa di tali relazioni di accesso:


Utilizzando l'esempio ConnectToConfigManager come punto di partenza, il programma riportato di seguito attraversa la gerarchia dell'oggetto gestito per rilevare lo stato di esecuzione di un flusso di messaggi distribuito. Notare che il programma suppone che il flusso di messaggi MF1 sia distribuito a EG1 sul broker B1, sebbene sia possibile sostituire tali valori nel codice con altri valori validi nel dominio.
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);
    }
  }
}
Il metodo che esegue la maggior parte delle operazioni è displayMessageFlowRunState(). Questo metodo utilizza l'handle ConfigManagerProxy raccolto precedentemente e rileva lo stato di esecuzione del flusso di messaggi come riportato di seguito:
  1. L'istanza ConfigManagerProxy viene utilizzata per ottenere un handle a TopologyProxy. Poiché esiste solo una topologia per Gestione configurazione, il metodo getTopology() non deve essere qualificato con un identificativo.
  2. Se viene restituita una topologia valida, l'istanza TopologyProxy viene utilizzata per ottenere un handle al proprio oggetto BrokerProxy con il nome descritto dalla stringa brokerName.
  3. Se viene restituito un broker valido, l'istanza BrokerProxy viene utilizzata per ottenere un handle al proprio oggetto ExecutionGroupProxy con il nome descritto dalla stringa egName.
  4. Se viene restituito un gruppo di esecuzione valido, l'istanza ExecutionGroupProxy viene utilizzata per ottenere un handle al proprio oggetto MessageFlowProxy con il nome descritto dalla stringa flowName.
  5. Se viene restituito un flusso di messaggi valido, viene interrogato lo stato di esecuzione dell'oggetto MessageFlowProxy e viene visualizzato il risultato.
Non è necessario conoscere i nomi degli oggetti che si desidera gestire. Ciascun oggetto gestito contiene i metodi per restituire gli insiemi di oggetti che possiede logicamente. L'esempio riportato di seguito illustra questa ricerca dei nomi di tutti i broker all'interno del dominio:
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);
    }
  }
}
Il metodo principale è TopologyProxy.getBrokers(Properties). Quando viene fornito con un argomento null, restituisce una numerazione di tutti gli oggetti BrokerProxy nel dominio. Il programma utilizza questo metodo per ricercare ciascun BrokerProxy e visualizzarne il nome.

L'argomento Properties di TopologyProxy.getBrokers(Properties) può essere utilizzato per specificare in modo esatto le caratteristiche dei broker ricercati. E' possibile eseguire questa operazione per quasi tutti i metodi che restituiscono oggetti gestiti ed è un potente mezzo di filtrare gli oggetti con cui il programma deve lavorare.

Esempi di quelle caratteristiche che possono essere utilizzate per filtrare gli oggetti sono lo stato di esecuzione e la descrizione breve, oltre ad altre proprietà più ovvie come il nome e l'UUID. Per scrivere il codice che consente di ottenere questo risultato, è necessario comprendere il modo in cui ciascun oggetto gestito memorizza le proprie informazioni.

Le proprietà di ciascun oggetto gestito sono memorizzate localmente all'interno dell'oggetto mediante una tabella hash, in cui ciascuna proprietà è rappresentata come una coppia {chiave, valore}. Ciascuna chiave è il nome di un attributo (ad esempio, name) e ciascun valore è il valore (ad esempio, BROKER1).

Ciascun nome di chiave deve essere espresso mediante una costante dalla classe AttributeConstants (com.ibm.broker.config.proxy). Un insieme completo di chiavi e valori possibili per ciascun oggetto gestito è descritto nella documentazione Java per la classe AttributesConstant oppure utilizzando la funzione Mostra la tabella di proprietà non elaborate per questo oggetto nel programma di esempio Proxy di Gestione configurazione API Exerciser. Quest'ultimo visualizza l'elenco completo di coppie {chiave, valore} per ciascun oggetto gestito.

L'argomento Properties fornito ai metodi di ricerca è un insieme di quelle coppie {chiave, valore} che devono esistere in ciascun oggetto gestito nella numerazione restituita. Per dimostrare questo concetto, considerare la seguente parte di codice:
Properties p = new Properties();
        
p.setProperty(AttributeConstants.OBJECT_RUNSTATE_PROPERTY,
              AttributeConstants.OBJECT_RUNSTATE_RUNNING);

Enumeration e = executionGroup.getMessageFlows(p);
Se la variabile executionGroup è un oggetto ExecutionGroupProxy valido, la numerazione restituita contiene solo flussi di messaggi in esecuzione (OBJECT_RUN_STATE_PROPERTY uguale a OBJECT_RUNSTATE_RUNNING).
Quando è applicato il filtro delle proprietà ad un metodo che restituisce un oggetto gestito singolo invece che una numerazione di oggetti, viene restituito solo il primo risultato (che non è deterministico se sono valide più corrispondenze). Ciò significa che:
Properties p = new Properties();

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

TopicProxy t = topicProxy.getTopic(p);
è un'alternativa a:
TopicProxy t = topicProxy.getTopicByName("shares");

Se vengono aggiunte più coppie {chiave, valore} ad un filtro delle proprietà, tutte le proprietà devono essere presenti nell'oggetto secondario per la corrispondenza dell'oggetto. Non è possibile eseguire un OR logico oppure un NOT logico su un filtro senza scrivere codice specifico dell'applicazione.

Quando gli oggetti AdministeredObjects vengono istanziati per la prima volta in un'applicazione, CMP richiede a Gestione configurazione l'insieme di proprietà corrente per tale oggetto. Ciò si verifica in modo asincrono: ciò significa che la prima volta che viene richiesta una proprietà potrebbe verificarsi una pausa mentre CMP attende che le informazioni vengano fornite da Gestione configurazione. Se le informazioni non vengono ricevute entro un determinato intervallo di tempo (ad esempio, se Gestione configurazione non è in esecuzione), viene generata un'eccezione ConfigManagerProxyPropertyNotInitializedException. L'intervallo di attesa massimo di CMP è determinato dal metodo ConfigManagerProxy.setRetryCharacteristics().

Attività correlate
Configurazione di un ambiente per lo sviluppo e l'esecuzione di applicazioni Proxy di Gestione configurazione
Connessione a Gestione configurazione mediante il Proxy di Gestione configurazione
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ae33040_