Navegando em Domínios Intermediários Utilizando o Configuration Manager Proxy

Antes de começar

Antes de iniciar esta etapa, é necessário ter concluído Conectando a um Gerenciador de Configuração Utilizando o Configuration Manager Proxy.

Cada objeto de domínio que pode ser controlado a partir do Gerenciador de Configuração é representado como um único objeto no Configuration Manager Proxy (CMP) e isto inclui:
  • Intermediários
  • Grupos de execução
  • fluxos de mensagens
  • Tópicos
  • Coletivos
  • Assinaturas
  • Topologia de Publicação/Assinatura
  • Registro de Eventos do Intermediário

O CMP também manipula conjuntos de mensagens implementados, embora eles sejam manipulados como atributos de grupos de execução implementados.

Coletivamente conhecidos como objetos administrados, estes objetos fornecem o núcleo da interface para o Gerenciador de Configuração, além de serem fundamentais para o entendimento da API do Configuration Manager Proxy.

Cada objeto administrado é uma instância de uma classe Java que descreve o tipo de objeto subjacente no Gerenciador de Configuração. As possíveis classes Java são as seguintes:
Classe Java Função da Classe
TopologyProxy Descreve a topologia de publicação/assinatura.
CollectiveProxy Descreve os coletivos de publicação/assinatura.
BrokerProxy Descreve intermediários.
ExecutionGroupProxy Descreve grupos de execução.
MessageFlowProxy Descreve os fluxos de mensagens que já foram implementados nos grupos de execução; NÃO descreve os fluxos de mensagens na perspectiva do Broker Application Development do toolkit.
TopicProxy Descreve tópicos.
TopicRootProxy Descreve a raiz da hierarquia de tópicos.
LogProxy Descreve o registro de eventos do intermediário para o usuário atual.
SubscriptionsProxy Descreve um subconjunto das assinaturas ativas.
ConfigManagerProxy Descreve o próprio Gerenciador de Configuração.
Cada objeto administrado descreve um único objeto controlável a partir do Gerenciador de Configuração. Por exemplo, cada intermediário em um domínio intermediário terá uma instância BrokerProxy que o representa no aplicativo do CMP e assim por diante.

Declarado em cada objeto administrado está um conjunto de métodos públicos que os programas podem utilizar para consultar e manipular propriedades do objeto subjacente do Gerenciador de Configuração ao qual a instância se refere. Por exemplo, em um objeto BrokerProxy que se refere ao intermediário B1, é possível chamar os métodos que fazem o intermediário revelar seu estado de execução ou iniciar todos os seus fluxos de mensagens e assim por diante.

Para acessar um objeto administrado e utilizar sua API, primeiro é necessário solicitar uma manipulação dele a partir do objeto que o possui logicamente. Por exemplo, como os intermediários logicamente possuem grupos de execução, para obter uma manipulação de um grupo de execução EG1 em execução no intermediário B1, o aplicativo precisa solicitar o objeto BrokerProxy representado por B1 para uma manipulação do objeto ExecutionGroupProxy representado por EG1.

No exemplo ConnectToConfigManager, é obtida uma manipulação do objeto ConfigManagerProxy. O ConfigManagerProxy é logicamente a raiz da árvore de objetos administrados, que significa que todos os demais objetos no Gerenciador de Configuração são acessíveis direta ou indiretamente a partir dele. O Gerenciador de Configuração possui diretamente a topologia de Publicação/Assinatura e, portanto, existe um método que os aplicativos podem chamar a partir do ConfigManagerProxy para obter uma manipulação do objeto TopologyProxy. De forma semelhante, a topologia logicamente contém o conjunto de todos os intermediários e, portanto, é possível chamar métodos no objeto TopologyProxy para acessar os objetos BrokerProxy. A hierarquia completa destes relacionamentos de acesso é mostrada abaixo:


Utilizando o exemplo ConnectToConfigManager como ponto inicial, o programa a seguir passa pela hierarquia de objetos administrados para descobrir o estado de execução de um fluxo de mensagens implementado. Observe que o programa assume que o fluxo de mensagens MF1 esteja implementado no EG1 no intermediário B1, embora seja possível substituir estes valores no código por qualquer valor válido no domínio.
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);
    }
  }
}
O método que faz a maior parte do trabalho é displayMessageFlowRunState(). Este método utiliza a manipulação do ConfigManagerProxy válido obtida anteriormente e descobre o estado de execução do fluxo de mensagens da seguinte forma:
  1. A instância ConfigManagerProxy é utilizada para obter uma manipulação do TopologyProxy. Como existe apenas uma topologia por Gerenciador de Configuração, o método getTopology() não precisa ser qualificado com um identificador.
  2. Se for retornada uma topologia válida, a instância TopologyProxy será utilizada para obter uma manipulação de seu objeto BrokerProxy com o nome descrito pela cadeia brokerName.
  3. Se for retornado um intermediário válido, a instância BrokerProxy será utilizada para obter uma manipulação de seu objeto ExecutionGroupProxy com o nome descrito pela cadeia egName.
  4. Se for retornado um grupo de execução válido, a instância ExecutionGroupProxy será utilizada para obter uma manipulação de seu objeto MessageFlowProxy com o nome descrito pela cadeia flowName.
  5. Se for retornado um fluxo de mensagens válido, o estado de execução do objeto MessageFlowProxy será consultado e o resultado será exibido.
Não é necessário saber os nomes de objetos que você pretende manipular. Cada objeto administrado contém métodos para retornar conjuntos de objetos que ele possui logicamente. O exemplo a seguir demonstra isso consultando os nomes de todos os intermediários no domínio:
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);
    }
  }
}
O método-chave é TopologyProxy.getBrokers(Properties). Quando fornecido com um argumento nulo, ele retorna uma Enumeração de todos os objetos BrokerProxy no domínio. O programa utiliza este método para examinar cada BrokerProxy sucessivamente e exibir seu nome.

O argumento de Propriedades do TopologyProxy.getBrokers(Properties) pode ser utilizado para especificar exatamente as características dos intermediários buscados. É possível fazer isso para quase todos os métodos que retornam objetos administrados e é uma maneira eficiente de filtrar estes objetos com os quais o programa precisa funcionar.

Os exemplos das características que podem ser utilizadas para filtrar consultas de objetos são o estado de execução e a descrição resumida, além de propriedades mais óbvias como o nome e UUID. Para gravar a lógica para fazer isso, é necessário entender como cada objeto administrado armazena suas informações.

As propriedades de cada objeto administrado são armazenadas localmente dentro do objeto utilizando uma tabela hash, em que cada propriedade é representada como uma tupla {chave, valor}. Cada chave é o nome de um atributo (por exemplo, nome) e cada valor é o valor (por exemplo, BROKER1).

Cada nome da chave deve ser expresso utilizando uma constante da classe AttributeConstants (com.ibm.broker.config.proxy). Um conjunto completo de chaves e os valores possíveis para cada objeto administrado são descritos na documentação do Java para a classe AttributesConstant ou utilizando a função Mostrar Tabela de Propriedades Brutas para este Objeto no programa de amostra Exerciser da API do Configuration Manager Proxy. O último exibe a lista completa de pares {chave, valor} para cada objeto administrado.

O argumento de Propriedades fornecido para os métodos de consulta é um conjunto dos pares {chave, valor} que devem existir em cada objeto administrado na enumeração retornada. Para demonstrar isso, considere o seguinte fragmento de código:
Properties p = new Properties();
        
p.setProperty(AttributeConstants.OBJECT_RUNSTATE_PROPERTY,
              AttributeConstants.OBJECT_RUNSTATE_RUNNING);

Enumeration e = executionGroup.getMessageFlows(p);
Desde que a variável executionGroup seja um objeto ExecutionGroupProxy válido, a enumeração retornada contém apenas fluxos de mensagens em execução (OBJECT_RUN_STATE_PROPERTY igual a OBJECT_RUNSTATE_RUNNING).
Quando a filtragem de propriedades é aplicada a um método que retorna um único objeto administrado em vez de uma enumeração de objetos, apenas o primeiro resultado é retornado (que não é determinista se mais de uma correspondência se aplicar). Isto significa que:
Properties p = new Properties();

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

TopicProxy t = topicProxy.getTopic(p);
é uma alternativa para:
TopicProxy t = topicProxy.getTopicByName("shares");

Se forem incluídos vários pares {chave, valor} em um filtro de propriedades, todas as propriedades deverão estar presentes no objeto-filho para correspondência de um objeto. Não é possível desempenhar um OR lógico ou um NOT lógico em um filtro sem gravar código de aplicativo específico para fazer isso.

Quando AdministeredObjects são instanciados pela primeira vez em um aplicativo, o CMP solicita do Gerenciador de Configuração o conjunto atual de propriedades para esse objeto. Isto ocorre assincronamente, o que significa que a primeira vez que uma propriedade for solicitada, pode haver uma pausa enquanto o CMP aguarda o fornecimento de informações pelo Gerenciador de Configuração. Se as informações não chegarem dentro de um período específico (por exemplo, se o Gerenciador de Configuração não estiver em execução), será emitida uma ConfigManagerProxyPropertyNotInitializedException. O tempo máximo aguardado pelo CMP é determinado pelo método ConfigManagerProxy.setRetryCharacteristics().

Tarefas relacionadas
Configurando um Ambiente para Desenvolvimento e Execução de Aplicativos do Configuration Manager Proxy
Conectando a um Gerenciador de Configuração Utilizando o Configuration Manager Proxy
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ae33040_