Nuevas funciones de Información de resolución de problemas de 4.2

Sun Java System Información de resolución de problemas de es un servicio de mensajería completo que proporciona funciones fiables y asíncronas, conformes con la especificación Java Messaging Specification (JMS) 1.1. Además, Información de resolución de problemas de incluye funciones que superan la especificación JMS para dar satisfacción a las necesidades de las instalaciones en grandes empresas.

Información de resolución de problemas de 4.2 es una versión menor que incluye nuevas mejoras en lo que a funciones y soluciones a fallos se refiere. Esta sección explica cómo instalar o realizar una actualización a Información de resolución de problemas de 4.2 y describe las nuevas funciones que se incluyen en esta versión:

• Varios destinos para un editor o suscriptor

• Validación de esquemas de mensajes de datos útiles XML

• Compatibilidad C-API con transacciones distribuidas

• Compatibilidad del instalador con el Registro de conexiones Sun

• Compatibilidad con la base de datos MySQL

Para obtener información sobre las funciones que se incluyen en Información de resolución de problemas de 4.0 y 4.1, consulte Nuevas funciones de Información de resolución de problemas de 4.0 y Nuevas funciones de Información de resolución de problemas de 4.1, respectivamente.

Varios destinos para un editor o suscriptor

En Información de resolución de problemas de 4.2, un editor puede publicar mensajes en varios destinos de temas y un suscriptor puede consumir mensajes procedentes 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.

El formato del nombre de destino de temas simbólico consta de varios segmentos, en los que los caracteres comodín (*, **, >) pueden representar uno o más segmentos del nombre. Por ejemplo, suponga que tiene el siguiente esquema de asignación de nombres de destinos de temas:

size.color. shape

en el que los segmentos del nombre del tema pueden tener los siguientes valores:

• size: large, medium, small, ...

• color: red, green, blue, ...

• shape: circle, triangle, square, ...

Message Queue admite los siguientes caracteres comodín:

• * hace coincidir un único segmento

• ** hace coincidir uno o más segmentos

• > hace coincidir cualquier número de segmentos sucesivos

Por lo tanto, puede indicar varios destinos de temas de la siguiente manera:

large.*.circle representaría:

large.red.circle
large.green.circle
...

**.square representaría todos los nombres que acaban en .square , por ejemplo:

small.green.square
medium.blue.square
...

small.> representaría todos los nombres de destinos que comienzan por small., por ejemplo:

small.blue.circle
small.red.square
...

Para utilizar esta función de destinos múltiples, deberá crear destinos de temas utilizando un esquema de asignación de nombres similar al descrito anteriormente. A continuación, las aplicaciones de cliente pueden crear editores o consumidores utilizando nombres de destinos simbólicos. Por ejemplo:

...
String DEST_LOOKUP_NAME = "large.*.circle";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicPublisher myPublisher = mySession.createPublisher(t)
myPublisher.send(myMessage);

...
String DEST_LOOKUP_NAME = "**.square";
Topic t = (Destination) ctx.lookup(DEST_LOOKUP_NAME);
TopicSubscriber mySubscriber = mySession.createSubscriber(t);
Message m = mySubscriber.receive();

En el primer ejemplo, el agente colocará una copia del mensaje en cualquier destino que coincida con el nombre simbólico large.*.circle. En el segundo ejemplo, se creará un suscriptor si existe al menos un destino que coincida con el nombre simbólico **.square y recibirá mensajes de todos los destinos que coincidan con dicho nombre simbólico. Si no existen destinos que coincidan con el nombre simbólico, el suscriptor no se creará hasta que exista dicho destino.

Si un administrador crea destinos adicionales que coincidan con un nombre simbólico, los editores comodín creados mediante dicho nombre simbólico se publicarán en dicho destino y los editores comodín creados mediante dicho nombre simbólico recibirán mensajes de dicho destino.

Además, las herramientas de administración de Message Queue, aparte de realizar informes acerca del número total de editores (productores) y suscriptores (consumidores) de un destino de temas, también realizarán informes sobre el número de editores que son editores comodín (incluidos sus nombres de destino simbólicos correspondientes) y el número de suscriptores que son suscriptores comodín (incluidos sus nombres de destino simbólicos), si es que existen.

Validación de esquemas de mensajes de datos útiles XML

Esta nueva función de Información de resolución de problemas de 4.2 permite la validación del contenido de un mensaje de texto (no un objeto) XML contra un esquema XML en el momento en el que se envía el mensaje 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 valor y el tipo de datos, es más rigurosa que la validación DTD.)

Las aplicaciones cliente que utilizan esta nueva función deben actualizarse desde la versión Java SE a JRE 1.5 o superior.

Para activar la validación del esquema XML, se deben configurar las siguientes propiedades de destinos físicos:

Al activar la validación XML, el tiempo de ejecución del cliente de Información de resolución de problemas de intentará validar un mensaje XML contra los XSD especificados (o contra el DTD, si no se especifica el XSD) antes de enviarlo al agente. Si el esquema especificado no puede ubicarse o el mensaje no puede validarse, el mensaje no se enviará, y se lanzará una excepción.

Las propiedades de la validación XML se pueden configurar en el momento de la creación del destino o en el momento de la actualización a través de los comandos imqcmd create dst o imqcmd update dst, respectivamente. Las propiedades de la validación XML deben configurarse cuando el destino esté inactivo: es decir, cuando no cuente con consumidores o productores, y cuando no haya mensajes en el destino.

Si no se puede acceder a un XSD durante el tiempo de ejecución, es posible que sea necesario modificar XMLSchemaURIList mientras esté activo el destino.

Si alguna de las propiedades de la validación XML se configura mientras que un destino está activo (por ejemplo, si un productor está conectado al destino), el cambio no tendrá lugar hasta que el productor se vuelva a conectar al agente. De igual forma, si se modifica un XSD, como resultado de la modificación de los requisitos de la aplicación, todas las aplicaciones cliente que produzcan mensajes XML basados en el XSD modificado deberán reconectarse al agente.

Si la propiedad reloadXMLSchemaOnFailure está configurada en true y la validación XML no se realiza de la forma correcta, el tiempo de ejecución del cliente de Información de resolución de problemas de intentará recargar el XSD antes de volver a intentar validar un mensaje. El tiempo de ejecución del cliente lanzará una excepción si la validación no se realiza correctamente al utilizar el SXD recargado.

Compatibilidad C-API con transacciones distribuidas

Según el modelo de transacciones distribuidas X/Open, la compatibilidad con transacciones distribuidas se basa en un administrador de transacciones distribuidas que supervisa y administra las operaciones que realizan uno o más administradores de recursos. En Información de resolución de problemas de 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 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 de 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 API suministradas a través del administrador de transacciones distribuidas.

Información pública

La especificación de la interfaz XA de X/Open requiere la siguiente información pública con respecto al administrador de recursos compatibles con XA de Message Queue:

• Nombre de la estructura xa_switch_t: sun_my_xa_switch

• Nombre del Administrador de recursos: SUN_RM

• La biblioteca C-API de MQ que se va a establecer como vínculo: mqcrt

• La cadena xa_close y el formato: none

• La cadena xa_open y el formato: nombre separado por “;”=pares de valores

Los siguientes pares de valores/nombre son compatibles:

Ejemplos de programación

Para programar una aplicación que utilice transacciones distribuidas, crea un servicio del lado del servidor que se ejecuta en el entorno del administrador de transacciones y el código del lado del cliente que llama a las API del administrador de transacciones. Message Queue 4.2 incluye ejemplos de programación basados en el administrador de transacciones de Tuxedo. Estos ejemplos están ubicados en el directorio de programas de ejemplo de cada plataforma dentro del directorio ./C/tuxedo.

Este directorio incluye un archivo README que explica cómo configurar Tuxedo para utilizar el administrador de recursos de Message Queue y cómo crear los siguientes programas de ejemplo en el entorno de Tuxedo:

Compatibilidad del instalador con el Registro de conexiones Sun

El instalador de Message Queue se ha mejorado para permitir el registro de Message Queue con Sun Connection, un servicio del sistema Sun que le ayuda a supervisar, organizar y mantener software y hardware de Sun.

Como parte de la instalación de Message Queue, puede elegir registrar Message Queue con Sun Connection. 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 con respecto a las funciones.

La siguiente pantalla del instalador se ha añadido a Información de resolución de problemas de 4.2 para el registro en Sun Connection:

El registro requiere que cuente con una cuenta Sun Online o que cree una. Si aún no tiene una cuenta, el instalador le proporcionará la siguiente pantalla para crear una cuenta Sun Online:

Puede registrar Message Queue durante la instalación utilizando las pantallas anteriores, o esperar a que la instalación finalice y ejecutar el instalador en el modo de sólo registro, de la siguiente manera:

# installer -r

El modo de sólo registro requiere que Información de resolución de problemas de 4.2 ya esté instalado y únicamente mostrará las pantallas del instalador relacionadas con el registro.

Compatibilidad con la base de datos MySQL

Información de resolución de problemas de 4.2 es compatible con la base de datos MySQL como almacén de datos basado en JDBC. MySQL Cluster Edition puede utilizarse como base de datos JDBC en el caso de un agente independiente, y MySQL Cluster Edition puede utilizarse como el almacén de datos compartido altamente disponible necesario para obtener un clúster de agente de alta disponibilidad. Para obtener información acerca de cómo configurar Información de resolución de problemas de para utilizar MySQL, consulte Configuring a JDBC-Based Data Store de Sun Java System Message Queue 4.2 Administration Guide así como High-Availability Cluster Properties de Sun Java System Message Queue 4.2 Administration Guide.