BEA WebLogic: Guía de Administración

Usando la Consola de Administraci�n, definimos los atributos de configuraci�n para:

• Activar JMS.
• Crear servidores de JMS
• 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:

1. Arrancamos la Consola de Administraci�n.
2. Seleccionamos el bot�n JMS bajo Services en el panel izquierdo para expandir la lista.
3. 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:

1. Arrancamos la Consola de Administraci�n.
2. Seleccionamos el nodo JMS bajo Services, en el panel izquierdo, para expandir la lista de servicios JMS.
3. Seleccionamos el nodo JMS Server bajo JMS en el panel izquierdo.

   La informaci�n sobre los servidores JMS se muestra en el panel derecho.

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

5. 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:

1. Actualizamos el Domain Name Service (DNS) para que el alias del servidor referencie a la nueva direcci�n IP.
2. Reiniciamos el servidor y arrancamos los procesos de servidor.
3. 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.