Cómo navegar por dominios de intermediarios utilizando el Proxy del Gestor de configuración

Antes de empezar

Antes de iniciar este paso, ha de haber completado lo indicado en el apartado Conexión a un Gestor de configuración utilizando el Proxy del Gestor de configuración.

Cada objeto de dominio que pueda controlarse desde el Gestor de configuración se representa como un solo objeto en el Proxy del Gestor de configuración (CMP) e incluye:
  • Intermediarios
  • Grupos de ejecución
  • flujos de mensajes desplegados
  • Temas
  • Colectivos
  • Suscripciones
  • Topología de publicación/suscripción
  • Registro de sucesos de intermediario

El CMP también maneja conjuntos de mensajes desplegados aunque éstos sólo se manejan como atributos de grupos de ejecución desplegados.

Estos objetos, conocidos colectivamente como objetos administrados proporcionan la mayor parte de la interfaz para el Gestor de configuración y, como tales, son fundamentales para comprender la API del Proxy del Gestor de configuración.

Cada objeto administrado es una instancia de una clase Java que describe el tipo de objeto subyacente en el Gestor de configuración. A continuación se indican las posibles clases Java:
Clase Java Función de clase
TopologyProxy Describe la topología de publicación/suscripción.
CollectiveProxy Describe los colectivos de publicación/suscripción.
BrokerProxy Describe intermediarios.
ExecutionGroupProxy Describe grupos de ejecución.
MessageFlowProxy Describe flujos de mensajes que ya se han desplegado para grupos de ejecución; NO describe flujos de mensajes en la perspectiva de Desarrollo de aplicación de intermediario del kit de herramientas.
TopicProxy Describe temas.
TopicRootProxy Describe la raíz de la jerarquía de temas.
LogProxy Describe el registro de sucesos del intermediario del usuario actual.
SubscriptionsProxy Describe un subconjunto de las suscripciones activas.
ConfigManagerProxy Describe el gestor de configuración propiamente dicho.
Cada objeto administrado describe un solo objeto que puede controlarse desde el Gestor de configuración. Por ejemplo, cada intermediario dentro de un dominio de intermediarios tendrá una instancia de BrokerProxy que lo representa dentro de la aplicación de CMP, etc.

En cada objeto administrado existe un conjunto de métodos públicos que los programas pueden utilizar para consultar y manipular propiedades de objeto subyacente de Gestor de configuración al que hace referencia la instancia. Por ejemplo, en un objeto BrokerProxy que haga referencia al intermediario B1, es posible invocar métodos que hagan que el intermediario revele su estado de ejecución o que inicie todos sus flujos de mensajes, etc.

Para acceder a un objeto administrado y utilizar su API, es necesario solicitar primero un manejador para el mismo desde el objeto que sea propietario del mismo lógicamente. Por ejemplo, como los intermediarios poseen de forma lógica los grupos de ejecución, para conseguir un manejador para el grupo de ejecución EG1 que se ejecuta en el intermediario B1 la aplicación debe pedir al objeto BrokerProxy representado por B1 un manejador para el objeto ExecutionGroupProxy representado por EG1.

En el ejemplo ConnectToConfigManager se consigue un manejador para el objeto ConfigManagerProxy. ConfigManagerProxy es lógicamente el raíz del árbol de objetos administrado, lo que significa que se puede acceder, directa o indirectamente, a los demás objetos del Gestor de configuración desde éste. El Gestor de configuración es el propietario directo de la topología de publicación/suscripción y, por lo tanto, existe un método que pueden invocar las aplicaciones desde ConfigManagerProxy para conseguir un manejador para el objeto TopologyProxy. De forma similar, la topología contiene lógicamente el conjunto de todos los intermediarios y, por lo tanto, es posible llamar a métodos sobre el objeto TopologyProxy para acceder a los objetos BrokerProxy. La jerarquía completa de estas relaciones de acceso aparece abajo:


Utilizando el ejemplo ConnectToConfigManager como punto de partida, el siguiente ejemplo recorre la jerarquía del objeto administrado para descubrir el estado de ejecución de un flujo de mensajes desplegado. Tenga en cuenta que el programa supone que el flujo de mensajes MF1 se ha desplegado para EG1 en el intermediario B1, aunque es posible sustituir estos valores en el código por cualesquiera que sean válidos en el 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);
    }
  }
}
El método que ejecuta más trabajo es displayMessageFlowRunState(). Este método toma el manejador ConfigManagerProxy válido conseguido anteriormente y encuentra el estado de ejecución del flujo de mensajes como se indica a continuación:
  1. La instancia ConfigManagerProxy se utiliza para conseguir un manejador para TopologyProxy. Como hay únicamente una topología por Gestor de configuración, el método getTopology() no necesita estar calificado mediante un identificador.
  2. Si se devuelve una topología válida, la instancia TopologyProxy se utiliza para conseguir un manejador para su objeto BrokerProxy con el nombre descrito por la serie de caracteres brokerName.
  3. Si se devuelve un intermediario válido, se utiliza la instancia BrokerProxy para conseguir un manejador para su objeto ExecutionGroupProxy con el nombre descrito por la serie de caracteres egName.
  4. Si se devuelve un grupo de ejecución válido, se utiliza la instancia ExecutionGroupProxy para conseguir un manejador para su objeto MessageFlowProxy con el nombre descrito por la serie de caracteres flowName.
  5. Si se devuelve un flujo de mensajes válido, se consulta el estado de ejecución del objeto MessageFlowProxy y el resultado se visualiza.
No es necesario conocer los nombres de los objetos que piensa manipular. Cada objeto administrado contiene métodos para devolver conjuntos de objetos que posee de forma lógica. El siguiente ejemplo muestra lo anterior buscando los nombres de todos los intermediarios que hay dentro 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);
    }
  }
}
El método clave es TopologyProxy.getBrokers(Properties). Cuando se suministra con un argumento nulo, devuelve una enumeración (Enumeration) de todos los objetos BrokerProxy del dominio. El programa utiliza este método para ver todos los BrokerProxy uno a uno y visualizar su nombre.

Se puede utilizar el argumento Properties de TopologyProxy.getBrokers(Properties) para especificar con exactitud las características de los intermediarios que se han buscado. Esto es posible para casi tos los métodos que devuelven objetos administrados y es una forma potente de filtrar los objetos con los que el programa debe trabajar.

Las características que pueden usarse para filtrar visualizaciones de objetos son, por ejemplo, el estado de ejecución y una corta descripción, así como propiedades más obvias como, por ejemplo, el nombre y el UUID. Para escribir lógica para llevar esto a cabo, es necesario que comprenda la forma en que cada objeto almacena su información.

Las propiedades de cada objeto administrado se almacenan localmente dentro del objeto utilizando una tabla hash en la que cada propiedad se representa como un tuple {key, value}. Cada clave es el nombre de un atributo (por ejemplo, name) y cada valor es el valor (por ejemplo, BROKER1).

Cada nombre de clave ha de expresarse utilizando una constante desde la clase AttributeConstants (com.ibm.broker.config.proxy). Se describe un conjunto completo de claves en la documentación de Java correspondiente a la clase AttributesConstant o utilizando la función Mostrar tabla de propiedades sin procesar para este objeto en el programa de ejemplo de Prácticas con la API del Proxy del Gestor de configuración. Este último visualiza la lista completa de pares {key, value} para cada objeto administrado.

El argumento Properties suministrado para los métodos de visualización es un conjunto de los pares {key, value} que han de existir en cada objeto administrado en la enumeración que se devuelve. Para demostrar esto, considere el siguiente fragmento de código:
Properties p = new Properties();
        
p.setProperty(AttributeConstants.OBJECT_RUNSTATE_PROPERTY,
              AttributeConstants.OBJECT_RUNSTATE_RUNNING);

Enumeration e = executionGroup.getMessageFlows(p);
Suponiendo que la variable executionGroup es un objeto ExecutionGroupProxy válido, la enumeración devuelta contendrá únicamente flujos de mensajes en ejecución (OBJECT_RUN_STATE_PROPERTY equal to OBJECT_RUNSTATE_RUNNING).
Cuando se aplica el filtrado de propiedades a un método que devuelve un solo objeto administrado en vez de una enumeración de objetos, sólo se devuelve el primer resultado (que no es determinante si puede aplicarse más de una conicidencia. Esto significa que:
Properties p = new Properties();

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

TopicProxy t = topicProxy.getTopic(p);
es una alternativa a:
TopicProxy t = topicProxy.getTopicByName("shares");

Si se añaden varios pares {key, value} a un filtro de propiedad, todas las propiedades habrán de estar presentes en el objeto hijo para que un objeto pueda coincidir. No es posible realizar un OR lógico ni un NOT lógico en un filtro sin escribir un código de aplicación específico para ello.

La primera vez que se crean instancias para los AdministeredObjects en una aplicación, el CMP pide al Gestor de configuración el conjunto de propiedades actual para dicho objeto. Esto se produce de forma asíncrona, lo que significa que la primera vez que se solicita una propiedad ha de haber una pausa mientras el CMP espera a que Gestor de configuración suministre la información. Si la información no llega tras un tiempo determinado (por ejemplo, si no se está ejecutando el Gestor de configuración, se generará una excepción ConfigManagerProxyPropertyNotInitializedException. El tiempo máximo que espera el CMP se determina mediante el método ConfigManagerProxy.setRetryCharacteristics().

Tareas relacionadas
Configuración de un entorno para el desarrollo y ejecución de aplicaciones del Proxy del Gestor de configuración
Conexión a un Gestor de configuración utilizando el Proxy del Gestor de configuración
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ae33040_