Java en castellano. BEA WebLogic: Guía de Administración java jsp

Crear y/o personalizar valores de servidores JMS, factorías de conexiones, destinos (colas y tópicos), plantillas de destinos, claves de destino, almacenes de sesiones y consumidores de conexiones.

Configurar aplicaciones JMS personalizadas.

Definir umbrales y cuotas.

Activar las características JMS deseadas, como cluster de servidores (ver la siguiente sección), proceso de mensajes concurrentes, ordenación de destinos, y mensajería persistente.

WebLogic JMS proporciona valores por defecto para algunos atributos de configuración; nosotros debemos proporcionar valores para los otros. Si especificamos un valor no válido para cualquier atributo de configuración, o si no especificamos un valor para un atributo para el que no existe valor or defecto, el Servidor WebLogic no iniciará JMS cuando lo arranquemos. Con el producto se proporciona un ejemplo de configuración JMS.

Cuando migramos desde una versión anterior, la información de configuración se convertirá automáticamente, según se describe en Migrar Aplicaciones Existentes.

Para configurar los atributos de WebLogic JMS, realizamos los siguientes pasos:

Arrancamos la Consola de Administración.

Seleccionamos el botón JMS bajo Services en el panel izquierdo para expandir la lista.

Seguimos los procedimientos descritos en las siguientes secciones...

Una vez configurado WebLogic JMS, las aplicaciones podrán enviar y recibir mensajes usando el API JMS.

Configurar Factorías de Conexiones

Las factorías de conexiones permiten a los clientes JMS crear conexiones JMS. Configuramos las factorías para crear coenxiones con atributos predefinidos.

Para configurar las factorías de conexiones, usamos el nodo Connection Factories en la Consola de Administración para definir lo siguiente:

Configurar atributos, incluyendo:
- Nombre de la factoría de conexiones.
- Nombre para acceder a la factoría de conexiones desde dentro del espacio de nombres JNDI.
- Identificador de Cliente (client ID) que puede ser usado por los clientes con subcriptores durables.
- Atributos de envío de mensajes por defecto (es decir, prioridad, tiempo-de-vida, y modo).
- Máximo número de mensajes en espera que podrían existir en una sesión asíncrona y la política de sobrecarga, (es decir, la acción a tomar, en sesiones multicast, cuando se alcanza el máximo).
- Si está permitido o no que el método close() sea llamado desde el método onMessage().
- Atributos de Transación (time-out de transación y si están permitidas las transaciones de un usuario JTA).

Fuentes (WebLogic Servers) que están asociadas con una factoría de conexiones para soporte de clustering. Las Targets nos permiten limitar el uso de servidores, grupos, y/o clusters en los que se podría desplegar la factoría de conexiones.

WebLogic JMS define una factoría de conexiones, por defecto: weblogic.jms.ConnectionFactory. Todos los atributos de configuración están seleccionados a sus valores por defecto en esta factoría.

Si la definición de la factoría de conexiones por defecto es apropiada para nuestra aplicación, no necesitamos configurar ninguna otra factoría adicional.

Nota:
Usando la factoría de conexiones por defecto, no tenemos control sobre el servidor JMS en el que la factoría podría estar desplegada. Si queremos dirigirnos a un servidor JMS particular, creamos una nueva factoría de conexiones y especificamos el servidor (o servidores) JMS fuente apropiados.

Algunos atributos de la factoría de conexiones son sonfigurables dinámicamente. Cuando los atributos dinámicos se modifian durante la ejecución, los nuevos valores sólo son efectivos para las nuevas conexiones, y no afectan al comportamiento de las conexiones existentes.

Configurar Plantillas

Las plantillas proporcionan una forma eficiente de definir múltiples destinos con selecciones de atributos similares. Las plantillas ofrecen los siguientes beneficios:

No necesitamos re-introducir cada selección de atributo cada vez que definamos un nuevo destino; podemos usar la plantilla y sobreescribir cualquier selección a la que queramos asignar un nuevo valor.

Podemos modificar dinámicamente las selecciones de atributos compartidos simplemente modificando la plantilla.

Para definir los atributos de configuración de la plantilla de destino, usamos el nodo Templates de la Consola de Administración. Los atributos configurables para una plantilla de destino son los mismos que los configurados para un destino. Estos atributos de configuración se heredan por los destinos que usan, con las siguientes excepciones:

Si el destino que está usando una plantilla especifica un valor que sobreescribe un atributo, se usa el valor sobreescrito.

El atributo Name no es heredado por el destino. Este nombre sólo es válido para la plantilla. Todos los destinos deben definir explícitamente un nombre único.

Los atributos JNDI Name, Enable Store, y Template no están definidos para plantillas de destino.

Los atributos Multicast no están definidos para plantillas de destino porque sólo se aplican a tópicos.

Cualquier atributo que no se haya definido explícitamente para un destino es asignado a su valor por defecto. Si no existe valor por defecto, debemos asegurarnos de especificar un valor dentro de la plantilla de destino o como un atributo de destino sobreescrito. Si no hacemos esto, la información quedará incompleta, fallará la configuración de WebLogic JMS, y WebLogic no se iniciará.

Configurar Claves de Destino

Las claves de destino se usan para definir el orden de ordenación para un destino específico.

Para crear una clave de destino, usamos el nodo Destination Keys de la Consola de Administración y definimos los siguientes atributos de configuración:

Nombre de la clave de destino.

Nombre de la propiedad por la que ordenar.

Tipo de clave esperada.

Dirección en la que ordenar (ascendente o descendente).

Configurar Stores

El Store consiste en un fichero o base de datos que se usa para mensajería persistente.

A través del uso del JDBC, JMS nos permite almacenar los mensajes existentes en una base de datos, a la que accedermos a través del almacen de conexiones JDBC designado. La base de datos JMS puede ser cualquier base de datos que sea accesible a través de un driver JDBC. WebLogic soporta y proporciona drivers para las siguientes bases de datos:

Cloudscape

Informix

Microsoft SQL (MSSQL) Server (Versiones 6.5 y 7)

Oracle (Versión 8.1.6)

Sybase (Versión 12)

Opcionalmente, podemos restringir la lista de control de acceso (ACL) para el almacen de conexiones JDBC. Si restringimos esta ACL, deberemos incluir al usuario system de WebLogic y a cualquier usuario que envíe mensajes JMS en la lista.

Nota:
Los ejemplos JMS están configurados para trabajar con la base de datos Cloudscape de Java. Con WebLogic Server se incluye una versión de evaluación de Cloudscape y una base de datos de ejemplo: demoPool.

Para crear un fichero o base de datos, usamos el nodo Stores de la Consola de Administración y definimos los siguientes atributos:

Nombre del store.

(Para un fichero store) Directoriro en que se grabó el fichero.

(Para un store de base de datos JDBC) el almacen de conexiones JDBC y el nombre de la tabla de la base de datos para usar con múltiples ejemplares.

Aviso:
No podemos configurar un almacen de conexiones XA con un store de base de datos JDBC.

Nota:
Los stores JMS pueden incrementar la cantidad de memoria requerida durante la inicialización de un Servidor WebLogic según se incrementa el número de mensajes almacenados. Si la inicialización falla debido a la memoria insuficiente cuando estámos reiniciando un Servidor WebLogic, debemos incrementar el tamaño de la pila de la Máquina Virtual Java (JVM) proporcionalmente al número de mensajes que haya almacenados en el store JMS. E intentamos reiniciar otra vez.

Sobre los Stores JMS

La base de datos JMS contiene dos tablas de sistema que JMS genera y utiliza automáticamente:

<prefix>JMSStore

<prefix>JMSState

El nombre prefix identifica de forma única tablas JMS en el store. Especificar un prefijo único permite que existan varios stores en la misma base de datos. El prefijo se configura mediante la Consola de Administración cuando configuramos el store JDBC. Un prefijo se adhiere al nombre de la tabla cuando el DBMS requiere un nombre totalmente cualificado, o cuando necesitamos diferenciar entre tablas JMS para dos servidores WebLogic, permitiendo que puedan almacenarse distintas tablas en una sola DBMS.

El prefijo debería especificarse usando el siguiente formato, lo que resultará en un nombre de tabla válido que será añadido al nombre de la tabla JMS:

[[catalog.]schema.]prefix

Aviso:
No se debería permitir que dos stores JMS usen las mismas tablas de la base de datos, ya que esto resultaría en una corrupción de los datos.

Selecciones de JDBC Connection Pool para Stores JMS

Para implementaciones que usan un store JDBC, si el DMS debería desconectarse y ponerse en línea de nuevo, WebLogic JMS no podrá acceder al store hasta que se reinicie el Servidor WebLogic. Para evitar esta situación, deberíamos configurar los siguientes atributos en el JDBC Connection Pool asociado con el store JMS:

TestConnectionsOnReserve=”true” TestTableName=”[[[catalog.]schema.]prefix]JMSState”

De otra forma, si los recursos JDBC se desconectan y vuelven a ponerse enl ínea, el JMS no podrá reutilizarlos hasta que el Servidor WebLogis sea reiniciado.

Configurar Servidores JMS

Un Servidor JMS maneja conexiones y peticiones de mensajes por cuenta de los clientes.

Para crear un servidor JMS, usamos el nodo Servers de la Consola de Administración y definimos lo siguiente:

Configuración de atributos incluyendo:
- Nombre del servidor JMS.
- Store (fichero o base de datos JDBC) requerido para mensajes persistentes. Si no asignamos un store para un servidor JMS, la mensajería persistente no estára soportada en ese servidor.
- Plantilla usada para crear todos los destinos temporales, incluyendo colas temporales y tópicos temporales.
- Umbrales y cuotas para mensajes y bytes (número máximo y umbrales alto y bajo).

Fuentes (WebLogic Servers) que están asociados con un servidor JMS para soportar clustering. Las fuentes nos permiten limitar el conjunto de servidores, grupos y/o clusters en lo que so podría desplegar un servidor JMS.

Nota:
El despliegue de un servidor JMS es diferente del de una factoría de conexiones o una plantilla. Un servidor JMS se despliegua en un sólo servidor. Una factoría de conexiones o una plantilla puede ser ejemplarizada en múltiples servidores simultáneamente.

Configurar Destinos

Un destino identifica una cola o tópico. Una vez que hemos definido un Servidor JMS, podemos configurar sus destinos. Podemos configurar uno o más destinos por cada servidor JMS.

Podemos configurar destinos explícitamente o configurando una plantilla de destino que pueda ser usada por múltiples destinos con similares selecciones de atributos, como se describe en Configurar Plantillas.

Para configurar destinos explícitamente, usamos el nodo Destinations de la Consola de Administración, y definimos los siguientes atributos de configuración:

Nombre y tipo (cola o tópico) de destino.

Nombre para acceder al destino dentro del espacio de nombres JNDI.

Si hay disponible o no un Store para almacenar mensajes persistentes.

Plantilla usada para crear destinos.

Claves usadas para definir la ordenación para un destino específico.

Umbrales y cuotas para mensajes y bytes (número máximo, y umbrales superior e inferior),

Atributos de mensaje que pueden ser sobreescritos (como prioridad, tiempo-de-vida, y modo de entrega).

Atributo de Multicasting, incluyendo dirección de multicast, puerto y tiempo-de-vida (sólo para topicos).

Algunos atributos de destino son configurables dinámicamente. Cuando los atributos se configuran en tiempo de ejecución, sólo se ven afectados los mensajes entrantes, los mensajes almacenados no se ven afectados.

Configurar Almacenes de Sesión

Los almacenes de sesión de servidor hacen posible que una aplicación procese mensajes de forma concurrente. Una vez que hemos definido un servidor JMS, tenemos la opción de configurar sus almacenes de sesión de servidor.

Podemos configurar uno o más almacenes de sesión por cada servidor JMS.

Para configurar los almacenes de sesión, usamos el nodo Session Pools de la Consola de Administración y definimos los siguientes atributos de configuración:

Nombre del almacén de sesión del servidor.

Factoría de conexión con la que está asociada el almacen de sesión de servidor y que es utilizada para crear sesiones.

Clase oyente de Message usada para recibir y procesar mensajes concurrentemente.

Atributos de transación (modo de reconocimiento y si el almacen de sesiones crea sesiones transacionales).

Número máximo de sesiones concurrente.

Algunos atributos de almacenes de sesión se pueden configurar dinámicamente, pero los nuevos valores no tendrán efecto hasta que se reinicien los almacenes de sesiones.

Configurar Clientes de Conexiones

Los consumidores de conexiones recuperan sesiones de servidor y procesan mensajes. Una vez hemos definido un almacen de sesión, tenemos la opción de configurar sus consumidores de conexiones.

Podemos configurar uno o más consumidores de conexión por cada almacen de sesión.

Para configurar consumidores de conexión, usamos el nodo Session Pools en la Consola de Administración para definir los siguientes atributos de configuración:

Nombre del consumidor de conexión.

Número máximos de mensajes que puede acumular el consumidor de conexión.

Selector de expresión JMS usado para filtrar mensajes.

Destino sobre el que escuchará el consumidor de conexión.

Monitorizar JMS

Se proporcionan estadísticas para los siguientes objetos JMS: servidores JMS, conexiones, sesiones, destinos, productores y consumidores de mensajes, y almacenes de sesión de servidor. Podemos monitorizar estas estadísticas usando la Consola de Administración.

Las estadísticas JMS continúan incrementándose mientras se esté ejecutando el servidor. Solo se pueden resetear cuando se reinicia el servidor.

Para ver la información de monitorización JMS, seguimos los siguientes pasos:

Arrancamos la Consola de Administración.

Seleccionamos el nodo JMS bajo Services, en el panel izquierdo, para expandir la lista de servicios JMS.

Seleccionamos el nodo JMS Server bajo JMS en el panel izquierdo.
La información sobre los servidores JMS se muestra en el panel derecho.

Seleccionamos el servidor JMS que queremos monitorizar en la lista de servidores JMS o, desde los Servidores JMS mostrados en el panel de la derecha.
La información sobre los servidores JMS se muestra en el panel derecho.

Seleccionamos la pestaña Monitoring para ver los datos monitorizados.

Recuperar después de un Fallo del Servidor WebLogic

Las siguiente secciones describen como reiniciar o reemplazar un Servidor WebLogic en el evento de un fallo del sistema, y proporcionan consideraciones de programación para una terminación amistosa de una aplicación cuando sucede dicho evento.

Rearrancar o Reiniciar el Servidor WebLogic

En el caso de que falle un Servidor WebLogic, hay tres métodos que podemos usar para realizar una recuperacuón del sistema:

Reiniciar el servidor que ha fallado.

Arrancar un nuevo servidor usando la misma dirección IP que el servidor que ha fallado.

Arrancar un nuevo servidor usando una dirección IP diferente a la del servidor que ha fallado.

Para reiniciar el servidor que ha fallado o arrancar un nuevo servidor usando la misma dirección IP, reiniciamos el servidor y arrancamos los procesos de servidor.

Para arrancar un nuevo servidor usando una dirección IP diferente:

Actualizamos el Domain Name Service (DNS) para que el alias del servidor referencie a la nueva dirección IP.

Reiniciamos el servidor y arrancamos los procesos de servidor.

Opcionalmente realizamos una o más de las siguientes tareas:

Si nuestra aplicación usa... Realizamos las tareas...

Persistent messaging—JDBC Store

Si el store JDBC existe físicamente en el servidor que ha fallado, migramos la base de datos al nuevo servidor para asegurarnos de que el atributo URL del almacen de conexiones JDBC refleja la localización apropiada.

Si la base de datos JDBC no existe físicamente, los accesos a la base de datos no se han visto impactados, y no es necesario ningún cambio.

Persistent messaging—File Store Migramos el fichero al nuevo servidor, asegurándonos de que el path dentro del directorio home del Servidor WebLogic es el mismo que en el servidor original.

Transactions

Migramos el log de transaciones al nuevo servidor copiando todos los ficheros llamados <servername>*.tlog. Esto se puede realizar almacenando los ficheros de log de transaciones en un disco con doble puerto que puede montarse en cualquier máquina, o copiando los ficheros manualmente.

Si los ficheros están localizados en un directorio diferente en el nuevo servidor, actualizamos la configuración del atributo TransactionLogFilePrefix antes de arrancarlo.

Nota:
Si la migración sigue a un crash del sistema, es muy importante que los ficheros de log de transaciones estén disponibles cuando se rearranque el servidor en su nueva localización. De otra forma, las transaciones en proceso de ser enviadas en el momento del crash podrían no resolverse corectamente, resultando en una inconsistencia de datos.

Todas las transaciones no enviadas serán deshechas.

Consideraciones de Programación

Podríamos querer programar que nuestra aplicación termine de forma amistosa en el caso de un fallo de un Servidor WebLogic. Por ejemplo:

Si un Servidor WebLogic falla y ...	entonces...
Estámos conectados al Servidor WebLogic que ha fallado.	Se le enviará una `JMSException` al oyente de excpeciones de conexión. Debemos rearrancar la aplicación una vez que el servidor se haya reiniciado o se reemplazado.
No estámos conectados al Servidor WebLogic que ha fallado.	Debemos re-establecer todo una vez que el servidor se haya reiniciado o reemplazado.
Un Servidor JMS está apuntando al Servidor WebLogic que ha fallado.	Se enviará una `ConsumerClosedException` al oyente de excepciones de sesión. Debemos re-establecer cualquier consumidor de mensajes que se haya perdido.