Entendendo os arquivos de encadernas da série MQ

Question

Nosso aplicativo Java grava nas filas da série MQ por meio de uma ponte de mensagem JMS WebLogic. Os detalhes reais da conexão/fila da série MQ são armazenados no arquivo. Bindings da série MQ no servidor de aplicativos. Eu realmente nunca peguei minha cabeça pelo arquivo de encadernas e o que todas as entradas significam. Alguém pode fornecer orientação para entender esse arquivo?

Answer 1

Antes de abordar o arquivo .Bindings, precisamos recuar um pouco e olhar para o JNDI - a interface de nomeação e diretório Java - e como é usado pelo JMS. A fila, o tópico e vários tipos de fábrica de conexões são objetos JMS em tempo de execução com métodos e atributos. Mas você pode prejudicá-los e armazená-los em um registro em que o aplicativo JMS possa recuperá-los usando pesquisas JNDI.

Isso é útil porque os objetos são como moedas, pois têm um lado JMS e um lado específico do provedor. No lado JMS, qualquer objeto administrado parece o mesmo. Independentemente do provedor de transporte subjacente, um ConnectionFactory possui os mesmos métodos e atributos. No entanto, no lado específico do provedor, os objetos administrados parecem muito diferentes de um provedor de transporte para o outro. Por exemplo, o ConnectionFactory usado com um WebSphere MQ Transport terá um atributo para o gerenciador de filas. Nenhum outro provedor de transporte possui um "gerente da fila", portanto esse atributo é válido apenas em um contexto WMQ.

Os dois aspectos dos objetos administrados são a "cola" que permite que o JMS trabalhe independentemente do fornecedor de transporte. No seu código, você só precisa procurar um ConnectionFactory e obtém um objeto adequado para executar chamadas de método. Sob as capas, as classes JMS do provedor usam os atributos de objeto específico do provedor para fornecer contexto para converter as chamadas genéricas da API JMS em chamadas específicas do fornecedor. Assim, o objeto de conexão que você instancia resulta em uma chamada WMQ Connect que especifica um nome, host, porta, canal e uma variedade de outros parâmetros QMGR.

Ok, prometi chegar ao arquivo .bindings. Eu disse anteriormente que a pesquisa do JNDI era contra "um registro" e isso geralmente significa LDAP ou similar. Mas a Sun projetou o JNDI como o JMS, pois há uma API que seu programa usa e uma interface SPI ou provedor de serviços que é usada pelo registro. Então, embora Jndi posso ser implementado no LDAP, não há nada que diga devo ser implementado no LDAP. Uma das implementações básicas que a Sun forneceu imediatamente foi usar o sistema de arquivos local como registro. Nesta implementação, o contexto raiz é uma pasta de arquivos. Cada contexto pode armazenar outro subcontexto (outra pasta de arquivo) ou definições de objeto. Normalmente, há uma pasta para o contexto raiz e todos os objetos são definidos nesse nível. O arquivo que contém as definições de objeto é ... você adivinhou ... o arquivo .Bindings.

Os objetos no arquivo .bindings são representados em trigêmeos de nome/tipo/valor. Portanto, cada arquivo .Bindings normalmente possui muitos objetos. Cada objeto tem muitos atributos. Cada atributo tem um nome, um valor e o tipo de variável que mantém o valor. A melhor maneira de controlar o arquivo .bindings é classificá-lo, que montará todos os objetos e seus atributos e torná-lo mais legível pelo homem. Para uma lista de propriedades possíveis, consulte o manual.

Obviamente, o arquivo .bindings deve ser um artefato compilado e não pretendido ser legível por humanos. A IBM fornece a ferramenta JMSAdmin para gerar e ler o arquivo .Bindings. Você também pode usar o WMQ Explorer para gerenciar os objetos administrados em um arquivo .bindings. Estes também são discutidos no manual ligado acima. Há também um (alguns dizem) um bom tutorial em desenvolvedores aqui.