test

Sun GlassFish Message Queue 4.4 Update 1 - Notas de la version

Nuevas funciones de Message Queue 4.4 Update 1 y versiones recientes

Las nuevas funciones de Message Queue 4.4 Update 1 y versiones anteriores de la familia Message Queue 4.x se describen en las siguientes secciones:

Nuevas funciones de Message Queue 4.4 Update 1

Message Queue 4.4 Update 1 es una versión menor que incluye nuevas mejoras en lo que a funciones y soluciones a fallos se refiere. En esta sección se describen las nuevas funciones incluidas en esta versión:

Nuevo programa de instalación

Message Queue 4.4 Update 1 incluye un nuevo instalador multiplataforma basado en el sistema pkq(5), también conocido como IPS (Image Packaging System). Para obtener más información sobre este programa de instalación, consulte Sun GlassFish Message Queue 4.4 Update 1 Installation Guide.

Admisión de registros de transacciones para agrupaciones

Message Queue 4.4 Update 1 incluye un mecanismo de persistencia de transacción para almacenes de datos basados en archivos que es compatible con agrupaciones de agentes. Este mecanismo proporciona otras funciones, descritas en Optimizing File-Based Transaction Persistence de Sun GlassFish Message Queue 4.4 Administration Guide.

Agente interno del proceso

Message Queue 4.4 Update 1 permite ejecutar un agente desde el cliente Java. Un agente de este tipo, llamado agente interno del proceso o incrustado, se ejecuta en la misma JVM que el cliente Java encargado de la creación y el inicio. Si necesita más información, consulte el Capítulo 6, Embedding a Message Queue Broker in a Java Client de Sun GlassFish Message Queue 4.4 Developer’s Guide for Java Clients.

Nuevas funciones de Message Queue 4.4

Message Queue 4.4 es una versión secundaria que incluye nuevas mejoras de funciones y soluciones de errores. En esta sección se describen las nuevas funciones incluidas en esta versión:

Servicio de conexión JMS

Debido a que la especificación JMS no define un protocolo para la comunicación entre agentes y clientes, cada proveedor de soluciones JMS (incluido Message Queue) utiliza su propio protocolo patentado. Esta situación ha provocado que las soluciones JMS de diferentes proveedores no sean compatibles.

El servicio de conexión JMS de Message Queue 4.4 soluciona este problema al permitir que un agente de Message Queue asigne sus destinos a destinos de proveedores JMS externos. Esta asignación permite que el agente de Message Queue se comunique de manera efectiva con clientes del proveedor JMS externo.

El servicio de conexión JMS permite asignar destinos de proveedores JMS externos que:

Muchas soluciones JMS de otros proveedores, tanto de código abierto como comerciales, cumplen estos requisitos; por lo que el servicio de conexión JMS es un sistema efectivo para integrar Message Queue en entornos de mensajería con otros proveedores JMS.

Si necesita más información sobre el servicio de conexión JMS, consulte:

Servicio de conexión STOMP

Como se ha mencionado anteriormente, la especificación JMS no define un protocolo de conexión para la comunicación entre agentes y clientes. El proyecto de código abierto STOMP (Streaming Text Oriented Messaging Protocol) de http://stomp.codehaus.org define un protocolo de conexión simple que pueden usar clientes escritos en cualquier lenguaje para comunicarse con cualquier proveedor de mensajería compatible con el protocolo STOMP.

Message Queue 4.4 es compatible con el protocolo STOMP mediante el servicio de conexión STOMP. Este servicio permite a un agente de Message Queue comunicarse con clientes STOMP.

Si necesita más información sobre el servicio de conexión STOMP, consulte:

Mejoras adicionales

Message Queue 4.4 también incluye las siguiente mejoras adicionales:

Nuevas funciones UMS (Universal Message Service)

Ahora, el servicio UMS proporciona funciones que utilizan HTTP GET para ofrecer múltiples servicios:

Para obtener más información sobre estas nuevas funciones, consulte Query and utility functions using HTTP GET en https://mq.dev.java.net/4.4-content/imqums/protocol.html.

Para ver una descripción general de UMS, consulte Universal Message Service (UMS). Para consultar la documentación de la API UMS, visite https://mq.dev.java.net/4.4-content/imqums/protocol.html. Para ver ejemplos de programación en diferentes lenguajes, consulte https://mq.dev.java.net/4.4-content/imqums/examples/README.html.

Admisión de paquetes IPS

Ahora, Message Queue se empaqueta para su distribución con el sistema de código abierto IPS (Image Packaging System), también conocido como sistema pkg(5). Este sistema de empaquetado se utiliza para integrar Message Queue con Sun GlassFish Enterprise Server 2.1.1.

Función de registro de auditoría reincorporada

Message Queue 3.7 incluía una función de registro de auditoría que se eliminó en Message Queue 4.0. Esta función se ha reincorporado en Message Queue4,4. Para obtener más información acerca de esta función, consulte Audit Logging de Sun GlassFish Message Queue 4.4 Administration Guide.

Nuevas funciones de Message Queue 4.3

Message Queue 4.3 es una versión secundaria que incluye varias mejoras de funciones y errores corregidos. En esta sección se describen las nuevas funciones incluidas en esta versión:

Universal Message Service (UMS)

Message Queue 4.3 incluye un nuevo servicio UMS (Universal Messaging Service) y una API de mensajería que permiten acceder a Message Queue desde cualquier dispositivo con http. Como resultado, prácticamente cualquier aplicación puede comunicarse con otras aplicaciones y aprovechar la fiabilidad y el envío garantizado de la mensajería JMS. Además, el servicio UMS ofrece una mayor escalabilidad para la mensajería JMS, lo que permite aumentar el número de clientes de mensajería hasta proporciones de escala de Internet.

Arquitectura

La siguiente figura muestra la arquitectura UMS básica:

Figura 1–1 Arquitectura UMS

Ilustración que muestra el servicio UMS como puerta de enlace entre clientes no JMS y un proveedor JMS.

UMS, que se ejecuta en un servidor web, es un servicio independiente de la plataforma y con lenguaje neutro. El servicio UMS actúa como una puerta de enlace entre cualquier aplicación cliente no JMS y un proveedor JMS. Recibe mensajes enviados con la API UMS, los transforma en mensajes JMS y los produce en destinos del proveedor JMS mediante el protocolo nativo del proveedor. De modo similar, extrae mensajes de destinos del proveedor JMS, los transforma en mensajes de texto o SOAP y los envía a clientes no JMS según lo soliciten los clientes mediante la API UMS.

La API UMS, sencilla, independiente del lenguaje y basada en protocolo, admite tanto aplicaciones web como no basadas en web, y puede usarse con lenguajes de secuencias de comandos y de programación. La API está disponible en dos modelos: una API de mensajería sencilla que utiliza un protocolo de tipo REST (REpresentational State Transfer), y una API de mensajería XML que incrusta el protocolo en un encabezado de mensaje SOAP. En ambos modelos, la API sólo necesita una solicitud http para enviar o recibir un mensaje.

La sencillez y flexibilidad de la API UMS permite que aplicaciones AJAX, .NET, Python, C, Java y de otro tipo puedan enviar mensajes de texto o SOAP (con adjuntos) a destinos JMS o recibir mensajes de destinos JMS. Por ejemplo, las aplicaciones Python pueden comunicarse con aplicaciones .NET, las aplicaciones de iPhone pueden comunicarse con aplicaciones Java, etc.

Para Message Queue 4.3, el servicio UMS sólo admite Message Queue como proveedor JMS.

Funciones adicionales

La función del servicio UMS va más allá que una simple puerta de enlace, descrita anteriormente. Admite sesiones cliente con estado y sin estado. Si lo solicita el cliente, el servicio UMS mantendrá el estado de sesión de la aplicación cliente en varias solicitudes de servicio. El servicio UMS puede utilizar autenticación administrada por contenedor, o configurarse para autenticar los clientes mediante el agente de Message Queue, o ambos. El servicio UMS también admite transacciones, lo que permite a las aplicaciones cliente confirmar o deshacer varias solicitudes de servicio como una única unidad atómica.

El servicio UMS admite un gran número de clientes en una única conexión con el agente de Message Queue, lo que reduce la carga de los servicios de conexión del agente y permite una escalabilidad máxima. Además, la capacidad del servicio UMS puede aumentarse con escalado horizontal, lo que permite trabajar con cargas de mensajes de escala de Internet.

En el cliente, gracias a la sencillez de la API UMS basada en protocolo, no se necesitan bibliotecas de cliente. Como resultado, la API puede ampliarse en el futuro para aplicar nuevas funciones JMS sin necesidad de actualizar las aplicaciones del cliente.

Uso del servicio UMS

Para utilizar el servicio UMS debe implementar UMS en un contenedor web compatible con las especificaciones Servlet 2.4 o posterior, iniciar el agente de Message Queue, crear los destinos correspondientes y escribir una aplicación de mensajería que utilice la API UMS para enviar o recibir mensajes.

El archivo UMS imqums.war, incluido en Message Queue 4.3, se instala en la siguiente ubicación, según la plataforma:

Puede cambiar el nombre del archivo .war según sus necesidades.

Tabla 1–5 Ubicación del archivo imqums.war

Plataforma 

Ubicación de imqums.war

Solaris 

/usr/share/lib/imq

Linux 

/opt/sun/mq/share/lib

AIX 

IMQ_HOME/lib

Windows 

IMQ_HOME\lib

Cuando haya implementado el archivo imqums.war en un contenedor web en localhost:puerto, podrá consultar la documentación de UMS en:

http://localhost:puerto/imqums

De lo contrario, puede encontrar la documentación de UMS como se indica a continuación:

Contenedores web compatibles

Actualmente, los siguientes contenedores web admiten UMS:

Compatibilidad con la plataforma AIX

Message Queue 4.3 incluye paquetes para la plataforma AIX y el instalador correspondiente.

La implementación AIX de Message Queue admite el siguiente software:

Si necesita instrucciones de instalación, consulte el Capítulo 4, AIX Installation, de la Sun Java System Message Queue 4.3 Installation Guide.

En la plataforma AIX, los archivos de Message Queue se instalan en un único directorio raíz de Message Queue, IMQ_HOME. IMQ_HOME se refiere al directorio mqInstallHome/mq, mqInstallHome es el directorio raíz de la instalación especificado al instalar el producto (de manera predeterminada, es home-directory /MessageQueue).

La estructura de directorios de Message Queue resultante es la misma que en Windows (consulte la sección Windows del Apéndice A, Distribution-Specific Locations of Message Queue Data de Sun GlassFish Message Queue 4.4 Administration Guide.)

Message Queue es compatible con la plataforma AIX, incluida la C-API de Message Queue. Si necesita instrucciones para generar y compilar aplicaciones C en la plataforma AIX, consulte XREF.

Nuevo instalador basado en Zip

Message Queue 4.3 incluye un nuevo instalador para distribuciones basadas en zip, en lugar de distribuciones de paquete nativo. El instalador permite instalar las nuevas distribuciones .zip de Message Queue para la plataforma AIX.

El nuevo instalador extrae los archivos .zip de Message Queue en cualquier directorio para el que el usuario tenga derechos de escritura (no son necesarios privilegios root) y también permite registrar la instalación de Message Queue con Sun Connection.

Para minimizar el tamaño de los paquetes de descarga, Java Runtime no se incluye en la distribución basada en zip (la mayoría de sitios ya lo tienen). Por lo tanto, el comando installer requiere que se especifique un JDK o JRE, ya sea mediante la variable de entorno JAVA_HOME o utilizando la opción -j en la línea de comando, como se muestra a continuación:

$ installer -j ruta-JDK/JRE

ruta-JDK/JRE es la ruta del JDK o JRE especificado.

Compatibilidad con plataformas ampliada

Message Queue 4.3 será compatible con las siguientes plataformas adicionales:

Mejoras adicionales

Message Queue 4.3 incluye las siguientes mejoras adicionales:

Nueva estructura de directorios en Windows

La estructura de directorios de la instalación de Message Queue en Windows se ha modificado con respecto a versiones anteriores, para que sea igual que en la plataforma AIX. En el futuro, esta estructura de directorios se utilizará también en Solaris y Linux para facilitar el uso de varias instalaciones en un único equipo y las actualizaciones automáticas de Message Queue mediante Sun Connection; un servicio de Sun que facilita el control, la organización y el mantenimiento de hardware y software de Sun (consulte Compatibilidad del instalador con el registro en Sun Connection).

Nuevas propiedades de agente

Pueden utilizarse las siguientes propiedades nuevas para configurar un agente:

Tabla 1–6 Propiedades de envío y enrutamiento de agente

Propiedad 

Tipo 

Valor predeterminado 

Descripción 

imq.transaction.producer.maxNumMsgs

Entero 

1000

El número máximo de mensajes que un productor puede procesar en una única transacción. Se recomienda que el valor sea inferior a 5000 para evitar que se agoten los recursos.  

imq.transaction.consumer.maxNumMsgs

Entero 

100

El número máximo de mensajes que un consumidor puede procesar en una única transacción. Se recomienda que el valor sea inferior a 1000 para evitar que se agoten los recursos.  

imq.persist.jdbc.connection.limit

Entero 

5

El número máximo de conexiones que pueden estar abiertas en la base de datos. 

Mejoras de la API de administración JMX

Se han añadido claves de datos compuestas y un atributo nuevo a la API JMX:

Si necesita más información, consulte el Capítulo 3, Message Queue MBean Reference de Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients.

Listado de suscripciones duraderas de suscriptores comodín

El comando para obtener una lista de las suscripciones duraderas:

list dur [-d topicName]

se ha mejorado para poder especificar el nombre de tema. Si no se especifica ningún tema, el comando muestra todas las suscripciones duraderas de todos los temas, incluidas las que contengan caracteres comodín.

Nuevas funciones de Message Queue 4.2

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.

Varios destinos para un editor o suscriptor

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.)

Nota –

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.

Validación del esquema de mensajes de carga de datos XML

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.

Admisión de C-API para transacciones distribuidas

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.

Nota –

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.

Compatibilidad del instalador con el registro en Sun Connection

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 .

Admisión de bases de datos MySQL

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 .

Mejoras adicionales

Además de las funciones descritas anteriormente, Message Queue 4.2 incluye las siguientes mejoras:

Nuevas funciones de Message Queue 4.1

Message Queue 4.1 es una versión secundaria que incluye varias funciones nuevas, funciones mejoradas y errores corregidos. Esta sección describe las nuevas funciones de la versión 4.1 y le ofrece más referencias para su uso:

Para obtener información sobre las funciones nuevas de Message Queue 4.0, consulte Nuevas funciones de Message Queue 4.0.

Agrupaciones de agentes de alta disponibilidad

Message Queue 4.1 incluye una agrupación de agentes nueva y mejorada. En comparación con una agrupación de agentes convencional, que sólo ofrece disponibilidad de servicio de mensajería (si un agente falla, hay otro agente disponible para ofrecer el servicio de mensajería), las agrupaciones de agentes de alta disponibilidad también incluyen disponibilidad de datos (si un agente falla, están disponibles sus mensajes persistentes y sus datos de estado para que otro agente los utilice con el fin de hacerse cargo del envío de mensajes).

El sistema de alta disponibilidad que se utiliza en Message Queue 4.1 utiliza un almacén de datos compartido basado en JDBC: en lugar de que cada agrupación de agentes tenga su propio almacén de datos persistente, todos los agentes de la agrupación comparten la mima base de datos JDBC. Si un agente en particular tiene algún error, otro agente de la agrupación asume el envío del mensaje del agente que ha fallado. Al hacer esto, el agente sustituto utiliza datos e información sobre el estado del almacén de datos compartido. Los clientes de mensajería del agente que ha fallado se reconectan al agente de sustitución, que ofrece un servicio de mensajería sin interrupciones.

El almacén compartido basado en JDBC utilizado en la implementación de alta disponibilidad de Message Queue 4.1 debe ser de por sí altamente disponible. Si no cuenta con una base de datos de alta disponibilidad o si el envío de mensajes ininterrumpido no le resulta importante, puede continuar utilizando agrupaciones convencionales, que ofrecen disponibilidad de servicios sin disponibilidad de datos.

Para configurar una agrupación de agentes mejorada en Message Queue 4.1, debe especificar las siguientes propiedades de cada agente de la agrupación:

Para utilizar el sistema de agrupación de agentes mejorada, debe hacer lo siguiente:

  1. Instalar una base de datos de alta disponibilidad.

  2. Instalar el archivo .jar del controlador de JDBC.

  3. Crear el esquema de la base de datos para el almacén de datos persistente de alta disponibilidad.

  4. Establecer propiedades de alta disponibilidad para cada agente de la agrupación.

  5. Iniciar cada uno de los agentes de la agrupación.

Si necesita una explicación del concepto de agrupaciones de agentes mejoradas en relación a las agrupaciones convencionales, consulte el Capítulo 4, Broker Clusters de Sun GlassFish Message Queue 4.4 Technical Overview. Si necesita información sobre los procedimientos y datos de referencia sobre las agrupaciones de agentes mejoradas, consulte el Capítulo 10, Configuring and Managing Broker Clusters de Sun GlassFish Message Queue 4.4 Administration Guide y la sección Cluster Configuration Properties de Sun GlassFish Message Queue 4.4 Administration Guide.

Si ha estado utilizando una base de datos de alta disponibilidad con Message Queue 4.0 y desea cambiar a una agrupación de agentes mejorada, puede utilizar la herramienta Database Manager (imqdbmgr) para convertir el sistema en un almacén de datos persistente compartido. Consulte también Agrupaciones de agentes si necesita más información sobre problemas conocidos y limitaciones.

Compatibilidad con JAAS

Además de los mecanismos de autenticación basados en archivos y en LDAP integrados, Message Queue 4.1 también es compatible con JAAS (Java Authentication and Authorization Service), que le permite conectar un mecanismo de autenticación externo al agente para autenticar los clientes de Message Queue.

Para obtener una descripción de la información que un agente pone a su disposición en un servicio de autenticación compatible con JAAS y una explicación acerca de cómo configurar el agente para utilizar dicho servicio, consulte Using JAAS-Based Authentication de Sun GlassFish Message Queue 4.4 Administration Guide.

Cambio del formato del almacén de datos persistente

El almacén de datos basado en JDBC de Message Queue 4.1 se cambió para admitir agrupaciones de agentes mejoradas. Por este motivo, el formato del almacén de datos basado en JDBC se ha ampliado a la versión 410. Las versiones con formato 350, 370 y 400 se migran automáticamente a la versión 410.

Tenga en cuenta que el formato del almacén de datos persistente basado en archivos permanece en la versión 370 dado que no se realizaron cambios en el mismo.

Configuración del entorno del agente

La propiedad IMQ_DEFAULT_EXT_JARS se ha añadido al archivo de configuración del entorno de Message Queue 4.1, imqenv.conf. Puede configurar esta propiedad para especificar el nombre de las rutas de los archivos .jar que deben incluirse en CLASSPATH al iniciarse el agente. Si utiliza esta propiedad para especificar la ubicación de los archivos .jar externos, ya no necesitará copiar estos archivos en el directorio lib/ext. Los archivos .jar externos pueden hacer referencia a los controladores de JDBC o a módulos de registro JAAS. La siguiente propiedad de ejemplo especifica la ubicación de los controladores JDBC.

IMQ_DEFAULT_EXT_JARS=/opt/SUNWhadb4/lib/hadbjdbc4.jar:/opt/SUNWjavadb/derby.jar

Compatibilidad con Java ES Monitoring Framework

Message Queue 4.1 es compatible con Sun Java Enterprise System (Java ES) Monitoring Framework, que permite controlar los componentes de Java ES mediante una interfaz gráfica común. La interfaz se implementa mediante una consola basada en web llamada "Sun Java System Monitoring Console". Los administradores pueden utilizar la Consola para ver las estadísticas de rendimiento, crear reglas para realizar un control automático y alarmas de confirmación. Si ejecuta Message Queue junto con otros componentes de Java ES, le resultará más cómodo gestionar todos los componentes con una única interfaz.

Para obtener más información sobre cómo utilizar la función Java ES Monitoring Framework para controlar Message Queue, consulte XREF.

Administración de transacciones mejorada

Anteriormente, los administradores sólo podían deshacer transacciones que estuvieran en estado PREPARED Es decir, si una sesión que formara parte de una transacción distribuida no terminaba correctamente, la transacción permanecía en un estado que era imposible de reorganizar para el administrador. Con Message Queue 4.1, el usuario puede utilizar la herramienta Command (imqcmd) para limpiar (deshacer) transacciones que se encuentren en los siguientes estados: STARTED, FAILED, INCOMPLETE, COMPLETE y PREPARED.

Para poder determinar si una transacción puede deshacerse (especialmente si no se encuentra en un estado PREPARED), la herramienta Command proporciona datos adicionales en la información imqcmd query txn generada: el id de la conexión que ha iniciado la transacción y la hora a la que se creó la misma. Basándose en esta información, el administrador puede decidir si es preciso deshacer o no la transacción. Por lo general, el administrador debe evitar deshacer una transacción prematuramente.

Puertos fijos para las conexiones de los clientes C

En Message Queue 4.1, los clientes C, como los clientes Java, pueden conectarse a un puerto de agente fijo en lugar de a un puerto asignado dinámicamente por el servicio Port Mapper del agente. Las conexiones a puertos fijos son útiles si intenta utilizar un servidor de seguridad o si necesita omitir el servicio Port Mapper por alguna otra razón.

Para configurar una conexión a puerto fija, debe configurar el agente y el tiempo de ejecución del cliente C (ambos extremos de la conexión). Por ejemplo, si desea conectar a su cliente con el puerto 1756 mediante ssljms, tendría que hacer lo siguiente:

Nota –

La propiedad de conexión MQ_SERVICE_PORT_PROPERTY ha pasado al puerto anterior de Message Queue 3.7 Update 2.

Nuevas funciones de Message Queue 4.0

Message Queue 4.0 es una versión secundaria que se limita a ser compatible con Application Server 9 PE. Incluía algunas nuevas funciones, algunas mejoras relacionadas con las funciones y soluciones a fallos. Esta sección incluye una descripción de las nuevas funciones de esta versión:

Precaución – Precaución –

Uno de los cambios más insignificantes que incorporaba la versión 4.0, pero que puede provocar interrupciones, era la anulación de la opción de línea de comandos para especificar una contraseña. De ahora en adelante, debe guardar todas las contraseñas en un archivo tal y como se describe en Opción de contraseña eliminada, o introducirlas cuando se le soliciten.

Compatibilidad con la API de administración JMX

Se ha añadido una nueva API a Message Queue 4.0 para configurar y supervisar los agentes de Message Queue de acuerdo con la especificación Java Management Extensions (JMX). Con esta API, puede configurar y supervisar las funciones de agente de forma práctica desde una aplicación Java. En versiones anteriores de Message Queue, sólo era posible acceder a estas funciones desde las utilidades de administración de línea de comando o la consola de administración.

Si necesita más información, consulte la Sun GlassFish Message Queue 4.4 Developer’s Guide for JMX Clients .

Registro del tiempo de ejecución del cliente

Message Queue 4.0 incluía compatibilidad con el registro de conexión del tiempo de ejecución del cliente y eventos relacionados con las sesiones.

Para obtener más información sobre el registro del tiempo de ejecución del cliente y cómo configurarlo, consulte la página 137 de la Guía para desarrolladores de Java.

API de notificación de sucesos de conexión

Message Queue 4.0 incluía una API de notificación de sucesos que permitía que el tiempo de ejecución de cliente informase a una aplicación sobre los cambios en el estado de la conexión. Las notificaciones de los sucesos de conexión permiten al cliente de Message Queue escuchar los sucesos de cierre y reconexión, y tomar las medidas oportunas en función del tipo de notificación y del estado de conexión. Por ejemplo, si se produce un error y el cliente se vuelve a conectar a otro agente, es posible que una aplicación quiera limpiar el estado de su transacción y continuar con una nueva.

Para obtener información acerca de los eventos de conexión y sobre cómo crear un receptor de eventos, consulte la página 96 de la Guía para desarrolladores de Java.

Mejoras en la administración del agente

En Message Queue 4.0, se añadieron varias opciones de comando y un nuevo subcomando a la utilidad Command (imqcmd) para permitir a los administradores desactivar un agente, cerrar un agente tras un intervalo específico, destruir una conexión o establecer propiedades del sistema java (por ejemplo, propiedades relacionadas con la conexión).

Encontrará toda la información sobre la sintaxis del comando imqcmd en el Capítulo 16, Command Line Reference de Sun GlassFish Message Queue 4.4 Administration Guide.

Mostrar información sobre el almacén de datos basado en JDBC

En Message Queue 4.0 se añadió un nuevo subcomando query a la utilidad Database Manager, imqdbmgr. Este subcomando se utiliza para mostrar información sobre el almacén de datos basado en JDBC, como la versión de la base de datos, el usuario de la base de datos y si se han creado las tablas de la base de datos.

A continuación, se muestra un ejemplo de la información mostrada por este comando.


imqdbmgr query
 

[04/Oct/2005:15:30:20 PDT] Using plugged-in persistent store:
        version=400
        brokerid=Mozart1756
        database connection url=jdbc:oracle:thin:@Xhome:1521:mqdb
        database user=scott
Running in standalone mode.
Database tables have already been created.

Compatibilidad con el proveedor de JDBC

En Message Queue 4.0, Apache Derby Version 10.1.1 ya es compatible como proveedor de almacén de datos basado en JDBC.

Cambios en el formato del almacén de datos persistente.

Message Queue 4.0 introdujo cambios en el almacén de datos basado en JDBC para optimizar el sistema y permitir mejoras en el futuro. Por este motivo, el formato del almacén de datos basado en JDBC se amplió a la versión 400. Tenga en cuenta que en Message Queue 4.0, la versión del almacén de datos basado en archivos sigue siendo la 370, porque no se ha realizado ningún cambio.

Propiedades de mensajes adicionales

Message Queue 4.0 añadió dos nuevas propiedades que están configuradas en todos los mensajes ubicados en la cola de mensajes inactivos.

Compatibilidad con SSL

Desde la versión Message Queue 4.0, el valor predeterminado de la propiedad de fábrica de la conexión del cliente imqSSLIsHostTrusted es false. Si su aplicación depende del valor predeterminado anterior true, deberá cambiar la configuración y establecer la propiedad explícitamente en true.

Puede elegir si desea confiar en el host cuando el agente está configurado para utilizar certificados autofirmados. En este caso, además de especificar que la conexión debe usar un servicio de conexión basado en SSL (con la propiedad imqConnectionType), debería establecer la propiedad imqSSLIsHostTrusted en true.

Por ejemplo, para ejecutar de forma segura las aplicaciones del cliente cuando el agente utiliza certificados autofirmados, utilice un comando como el siguiente:

java -DimqConnectionType=TLS 
      -DimqSSLIsHostTrusted=true ClientAppName

Para utilizar la utilidad Comando (imqcmd) de forma segura cuando el agente utiliza certificados autofirmados, utilice un comando como el siguiente (para enumerar los servicios del conector).

imqcmd list svc -secure -DimqSSLIsHostTrusted=true