Message Queue 4.2 es una versión secundaria que incluye varias funciones nuevas, funciones mejoradas y errores corregidos. En esta sección se describen las nuevas funciones de la versión 4.2 y se ofrecen más referencias para su uso:
Para obtener información sobre las funciones que se incluyen en Message Queue 4.1 y 4.0, consulte Nuevas funciones de Message Queue 4.1 y Nuevas funciones de Message Queue 4.0, respectivamente.
Con Message Queue 4.2, un editor puede publicar mensajes en varios destinos de temas y un suscriptor puede consumir mensajes de varios destinos de temas. Esta función se logra al utilizar un nombre de destino de temas que incluye caracteres comodín que representen varios destinos. Al utilizar dichos nombres simbólicos, los administradores pueden crear destinos de temas adicionales, según sea necesario, coherentes con el esquema de asignación de nombres comodín. Los editores y suscriptores publican y consumen automáticamente a partir de los destinos añadidos. (Los suscriptores de los temas comodín son más comunes que los editores.)
Esta función no se aplica a destinos de cola.
Puede consultar el formato de los nombres de destinos de temas simbólicos y ver ejemplos de uso en la sección Supported Topic Destination Names de Sun GlassFish Message Queue 4.4 Administration Guide.
Esta nueva función de Message Queue 4.2, permite validar el contenido de un mensaje XML de texto (no de objeto) con un esquema XML, cuando el mensaje se envía al agente. La ubicación del esquema XML (XSD) se especifica como propiedad de un destino de Message Queue. Si no se especifica ninguna ubicación XSD, la declaración DTD del documento XML se utilizará para realizar la validación DTD. (la validación XSD, que incluye la validación del intervalo de valores y el tipo de datos, es más rigurosa que la validación DTD.)
Para obtener información sobre el uso de esta función, consulte Schema Validation of XML Payload Messages de Sun GlassFish Message Queue 4.4 Developer’s Guide for Java Clients.
Según el modelo de transacciones distribuidas X/Open, la compatibilidad con transacciones distribuidas se basa en un administrador de transacciones de este tipo que supervisa y administra las operaciones que realizan uno o más administradores de recursos. Con Message Queue 4.2 la C-API de Message Queue es compatible con la interfaz XA (entre un administrador de transacciones distribuidas y Message Queue como administrador de recursos compatibles con XA), lo que permite a los clientes de la C-API de Message Queue funcionar en un entorno de procesamiento de transacciones distribuidas (tales como BEA Tuxedo) con el fin de participar en transacciones distribuidas.
Esta compatibilidad con transacciones distribuidas cuenta con las siguientes nuevas funciones de C-API (y nuevos parámetros y códigos de error) que se utilizan para implementar la especificación de la interfaz XA:
MQGetXAConnection() MQCreateXASession()
Si la aplicación de un cliente C se va a utilizar en el contexto de una transacción distribuida, debe obtener una conexión a través de MQGetXAConnection() y crear una sesión para producir y consumir mensajes mediante MQCreateXASession(). El inicio, la confirmación y la anulación de cualquier transacción distribuida se administra a través de interfaces API suministradas por el administrador de transacciones distribuidas.
Si necesita más información sobre el uso de funciones de transacción distribuida, consulte la sección Working With Distributed Transactions de Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients.
Message Queue 4.2 incluye ejemplos de programación basados en el administrador de transacciones Tuxedo. Si necesita información sobre el uso de estos programas de ejemplo, consulte la sección Distributed Transaction Sample Programs de Sun GlassFish Message Queue 4.4 Developer’s Guide for C Clients.
La función de transacción distribuida se admite en Solaris, Linux y Windows, aunque hasta ahora sólo se ha certificado para la plataforma Solaris.
El instalador de Message Queue se ha mejorado para permitir el registro de Message Queue en Sun Connection, un servicio de Sun que le ayuda a supervisar, organizar y mantener software y hardware de Sun.
Puede registrar Message Queue en Sun Connection al instalarlo. La información acerca del Message Queue instalado, como por ejemplo la versión, el nombre del sistema, el sistema operativo, la fecha de instalación y otra información básica, se transmite de forma segura a la base de datos de Sun Connection. El servicio de inventario de Sun Connection puede ayudarle a organizar su hardware y software de Sun, mientras que el servicio de actualización puede informarle de las últimas soluciones de seguridad disponibles, actualizaciones recomendadas y mejoras de funciones.
Para obtener más información sobre el registro de Message Queue con Sun Connection, consulte Sun GlassFish Message Queue 4.3 Installation Guide .
Message Queue 4.2 es compatible con bases de datos MySQL como almacén de datos basado en JDBC. MySQL Cluster Edition puede usarse como una base de datos JDBC para un agente independiente y como el almacén de datos de alta disponibilidad necesario para una agrupación de agentes mejorada. Si necesita información sobre cómo configurar Message Queue para utilizar MySQL, consulte la sección Configuring a JDBC-Based Data Store de Sun GlassFish Message Queue 4.4 Administration Guide y Enhanced Broker Cluster Properties de Sun GlassFish Message Queue 4.4 Administration Guide .
Además de las funciones descritas anteriormente, Message Queue 4.2 incluye las siguientes mejoras:
Estadísticas de mensaje generadas remotamente
Message Queue 4.4 Update 1 incluye nuevos métodos de medición de destino que pueden resultar útiles a la hora de controlar destinos en una agrupación de agentes. En una agrupación de agentes, los mensajes almacenados en un destino específico de un agente determinado de la agrupación son mensajes generados directamente para enviarlos al destino, así como mensajes enviados al destino desde agentes remotos de la agrupación. Al analizar el enrutamiento y la entrega de mensajes en una agrupación de agentes, a veces resulta útil saber cuántos mensajes de un destino son locales (se han generado localmente) y cuántos son remotos (se han generado de forma remota).
Message Queue 4.2 incluye dos nuevas cantidades de medición de destino físico: Num messages remote y Total Message bytes remote. Puede acceder a las nuevas cantidades de medición con los comandos imqcmd list dst e imqcmd query dst (consulte la sección Viewing Physical Destination Information de Sun GlassFish Message Queue 4.4 Administration Guide) o usando nuevos atributos JMX (consulte la sección Destination Monitor de Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients).
Información sobre el generador y el consumidor de comodines
Los nuevos datos de control ofrecen información que permite el uso de caracteres comodín en nombres de destino (consulte Varios destinos para un editor o suscriptor). Por ejemplo, puede ver el número de generadores y consumidores de comodines asociados con un destino con el comando imqcmd query dst (consulte la sección Viewing Physical Destination Information de Sun GlassFish Message Queue 4.4 Administration Guide) o utilizando los nuevos atributos JMX (consulte la sección Destination Monitor de Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients). La información de comodines también puede obtenerse mediante los MBeans ConsumerManager Monitor y ProducerManager Monitor.
Admisión del formato de nombre de usuario DN para la autenticación del cliente
Message Queue 4.2 admite el formato de nombre de usuario DN al autenticar la conexión del cliente con un almacén de usuarios LDAP. La compatibilidad incluye la siguiente nueva propiedad de agente (y el valor):
imq.user_repository.ldap.usrformat=dn
Esta propiedad permite al agente autenticar un usuario del cliente con un almacén de usuarios LDAP extrayendo del formato de nombre de usuario DN el valor del atributo especificado por la siguiente propiedad:
imq.user_repository.ldap.uidattr
El agente utiliza el valor del anterior atributo como nombre de usuario en las operaciones de control de acceso.
Por ejemplo, si imq.user_repository.ldap.uidattr=udi y un nombre de usuario de autenticación de cliente están en el formato udi=mquser,ou=People,dc=red,dc=sun,dc=com, se extraería “mquser” para realizar el control de acceso.
Mejora de la autenticación JAAS
Message Queue 4.2 permite la autenticación JAAS por dirección IP y por nombre de usuario.