Nuestra aplicación Java escribe en colas de la serie MQ a través de un puente de mensajes JMS Weblogic. Los detalles de la conexión/cola de la serie MQ real se almacenan en el archivo .bindings de la serie MQ en el servidor de la aplicación. Nunca he entendido bien el archivo de enlaces y lo que significan todas las entradas. ¿Alguien puede proporcionar una guía para entender este archivo?Descripción de los archivos de enlaces de la serie MQ
Antes de abordar el archivo .bindings, tenemos que retroceder un poco y observar JNDI - la Interfaz de nombres y directorios de Java - y cómo es utilizado por JMS. Cola, tema y varios tipos de Factory Connection son todos objetos JMS en tiempo de ejecución con métodos y atributos. Pero puede predefinirlos y almacenarlos en un registro donde la aplicación JMS pueda recuperarlos utilizando búsquedas JNDI.
Esto es útil porque los objetos son como monedas porque tienen un lado JMS y un lado específico del proveedor. En el lado de JMS, cualquier objeto administrado tiene el mismo aspecto. Independientemente del proveedor de transporte subyacente, ConnectionFactory tiene los mismos métodos y atributos. Sin embargo, en el lado específico del proveedor, los objetos administrados se ven muy diferentes de un proveedor de transporte al siguiente. Por ejemplo, ConnectionFactory utilizado con un transporte de WebSphere MQ tendrá un atributo para el Administrador de colas. Ningún otro proveedor de transporte tiene un "gestor de colas", por lo que este atributo solo es válido en un contexto WMQ.
Los dos aspectos de los objetos administrados son el "pegamento" que permite a JMS trabajar independientemente del proveedor de transporte. En tu código, solo tienes que buscar una ConnectionFactory y obtienes un objeto adecuado para realizar llamadas de método en contra. Bajo las cubiertas, las clases JMS del proveedor utilizan los atributos de objeto específicos del proveedor para proporcionar contexto para convertir las llamadas API JMS genéricas en llamadas específicas del proveedor. Por lo tanto, el objeto de conexión que crea una instancia da como resultado una llamada WMQ CONNECT que especifica un nombre de QMgr, un host, un puerto, un canal y una variedad de otros parámetros.
Bien, prometí llegar al archivo .bindings. Dije previamente que la búsqueda JNDI estaba en contra de "un registro" y que generalmente significa LDAP o similar. Pero Sun diseñó JNDI como JMS porque hay una API que usa su programa y una interfaz SPI o proveedor de servicios que utiliza el registro. Por lo tanto, aunque JNDI puede implementarse en LDAP, no hay nada que lo indique debe implementarse en LDAP. Una de las implementaciones base que Sun proporcionó de manera inmediata fue utilizar el sistema de archivos local como registro. En esta implementación, el contexto raíz es una carpeta de archivos. Cada contexto puede almacenar cualquier otro contexto secundario (otra carpeta de archivos) o definiciones de objetos. Normalmente, hay una carpeta para el contexto raíz y todos los objetos se definen en ese nivel. El archivo que contiene las definiciones de objeto es ... lo adivinó ... el archivo .bindings.
Los objetos en el archivo .bindings se representan en tripletas Nombre/Tipo/Valor. Por lo tanto, cada archivo .bindings normalmente tiene muchos objetos. Cada objeto tiene muchos atributos. Cada atributo tiene un nombre, un valor y el tipo de variable que contiene el valor. La mejor forma de manejar el archivo .bindings es ordenarlo, lo que juntará todos los objetos y sus atributos y lo hará más legible para el ser humano. Para obtener una lista de posibles propiedades, consulte the manual.
Por supuesto, se supone que el archivo .bindings es un artefacto compilado y no pretende ser legible por humanos. IBM proporciona la herramienta JMSAdmin para generar y leer el archivo .bindings. También puede usar WMQ Explorer para administrar los objetos administrados en un archivo .bindings. Estos también se discuten en el manual vinculado anteriormente. También hay un (algunos dicen) buen tutorial en developerWorks here.