Está en la página 1de 60

Oficina Técnica para la Gestión y Supervisión de

Servicios TIC
Subdirección de Tecnologías de la Información

Best practices de desarrollo sobre


Oracle Weblogic Server
para la capa de negocio

Referencia documento:
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc
Fecha: 13 de enero de 2011
Versión: 2.1.0
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Registro de Cambios

Fecha Autor Versión Notas

13 de enero de 2011 Emilio Nestal 2.0.0 Versión inicial

Revisiones

Nombre Role

Jonathan Ortiz Advanced Support Engineer

Distribución

Copia Nombre Empresa

1 Subdirección de Tecnologías de la Servicio Andaluz de Salud, Junta de


Información Andalucía
2 Servicio de Coordinación de Consejería de Innovación, Junta de
Informática de la Consejería de Andalucía
Innovación

Pág. 2 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Índice de Contenidos

CONTROL DE CAMBIOS .........................................................................................................................5


INTRODUCCIÓN ....................................................................................................................................6
OBJETIVOS DE ESTE DOCUMENTO ..........................................................................................................7
BEST PRACTICES DE DESARROLLO SOBRE WEBLOGIC SERVER ...............................................................8
BEST PRACTICES PARA JDBC ................................................................................................................9
Tecnología JDBC ..............................................................................................................................9
Drivers JDBC ....................................................................................................................................9
Arquitectura JDBC ......................................................................................................................... 10
Consideraciones sobre los drivers JDBC ....................................................................................... 11
Pool de Conexiones ......................................................................................................................... 11
Data Sources ................................................................................................................................... 12
PinnedToThread.............................................................................................................................. 14
Batch Updates ................................................................................................................................. 15
Gestión de transacciones ................................................................................................................ 15
Niveles transaccionales ................................................................................................................... 15
BEST PRACTICES PARA JAVA MESSAGE SERVICE................................................................................. 17
Dos tipos de dominios JMS ............................................................................................................. 18
Arquitectura JMS ............................................................................................................................ 18
Operativa de clientes JMS .............................................................................................................. 19
Agregación y flujo de mensajes ....................................................................................................... 19
Persistent Stores .............................................................................................................................. 19
Paging ............................................................................................................................................. 20
Tamaño del buffer del mensaje ....................................................................................................... 20
Throttling ........................................................................................................................................ 21
Cuotas JMS ..................................................................................................................................... 22
Umbrales o threshold ...................................................................................................................... 23
Control de flujo ............................................................................................................................... 23
Gestión de expirados ....................................................................................................................... 24
Acuse de recibo (Acknowledgement) ............................................................................................... 25
Store and Forward (SAF)................................................................................................................ 26
BEST PRACTICES PARA ENTERPRISE JAVABEANS ................................................................................ 28
Interfaces EJB ................................................................................................................................. 28
Estructura de aplicaciones EJBs..................................................................................................... 29
Beans de tipo Stateless Session ....................................................................................................... 29
Message-Driven Beans (MDB) ....................................................................................................... 31
Stateful Session Beans ..................................................................................................................... 32
Beans de entidad (Entity beans) ...................................................................................................... 36
Estrategias de concurrencia para Entity Beans .............................................................................. 39
Entity Bean Bulk Updates ............................................................................................................... 41
Cacheo de relaciones (relationship caching) .................................................................................. 42
Container-Managed Transactions (CMT)....................................................................................... 44
BEST PRATICES PARA CLUSTERING ...................................................................................................... 48
Balanceo de carg y failover ............................................................................................................ 48
Arquitectura básica de un clúster ................................................................................................... 49
Arquictura multi capa de un clúster ................................................................................................ 49
Balanceadores de carga .................................................................................................................. 50

Pág. 3 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Replicación de sesión ...................................................................................................................... 51


Replicación basada en memoría ..................................................................................................... 51
Persistencía basada en JDBC ......................................................................................................... 52
Persistencía basada en file system compartido ............................................................................... 52
Configuración de los tipos de replicación ...................................................................................... 52
BEST PRACTICES PARA WORK MANAGERS .......................................................................................... 54
Default Work Manager ................................................................................................................... 54
Clases de tipo Request .................................................................................................................... 54
Clases de tipo Fair Share Request .................................................................................................. 55
Clases de tipo Response Time Request ........................................................................................... 55
Clases de tipo Context Request ....................................................................................................... 55
Resctricciones (Constraints) ........................................................................................................... 56
Resctricción Maximum Threads ...................................................................................................... 56
Resctricción Minimum Threads ...................................................................................................... 56
Resctricción Capacity ..................................................................................................................... 57
Clases y restricciones de tipo Referencing...................................................................................... 57
Global-Level Work Managers ......................................................................................................... 57
Work Manager a nivel de aplicación .............................................................................................. 58
Work Managers a nivel de aplicaciones Web ................................................................................. 58
Work Manager para Stuck Threads ................................................................................................ 59
Colas de ejecución (Execute queues) .............................................................................................. 59

Pág. 4 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Control de cambios
Cambio Descripción Página

Pág. 5 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Introducción
Este documento recoge una serie de recomendaciones de Oracle Soporte planteadas
como buenas prácticas de desarrollo para aplicaciones que hagan uso de Oracle
WebLogic Server 11gR1.

Estas recomendaciones están encaminadas a minimizar los posibles problemas de


rendimiento en sistema de cualquier tamaño y en la gran mayoría de los casos se
basan en la experiencia de casos reales gestionados por Oracle Soporte.

Finalmente, este documento también recoge una serie de conceptos de componentes,


módulos y tecnologías relacionadas con Oracle WebLogic Server 11gR1., que a juicio
de Oracle Soporte, deberían tenerse claros para asegurar la aplicación de las
recomendaciones recogidas en este documento, y de manera general, entender los
productos Oracle sobre los que se sustentan los sistemas y aplicaciones.

Pág. 6 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Objetivos de este documento


A lo largo de los puntos de este documento se irá definiendo una guía de buenas
prácticas para el desarrollo de aplicaciones sobre Oracle WebLogic Server 11gR1.

Esta guía contendrá tanto prácticas recomendadas como prácticas a evitar y se


apoyará en ejemplos y en información que permita analizar las recomendaciones en
cada uno de los entornos de desarrollo y preproducción.

Este documento se centra principalmente en las versiones Oracle WebLogic Server


11gR1, aunque algunas de las recomendaciones son igualmente aplicables a las
versiones anteriores.

El objetivo de esta guía de buenas prácticas tiene varios objetivos:

Aprovechamiento de las características del producto

o Rendimiento

o Escalabilidad

o Alta disponibilidad

o Balanceo de carga

Facilitar la implantación y modificación del aplicativo en producción con


sistemas basados en Oracle WebLogic Server 11gR1.

Pág. 7 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Best practices de desarrollo sobre Weblogic Server


<TODO>
Versión
Objetivo
Bussiness Layer
</TODO>

Pág. 8 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Best Practices para JDBC


Tecnología JDBC

JDBC es una API que proporciona una interfaz común de programación para el
acceso a diferentes bases de datos. JDBC lleva a cabo las conexiones a las bases de
datos mediante un driver que transforma llamadas de JDBC en llamadas nativas a la
base de datos.

La independencia de plataforma es una característica inherente de Java conseguida


por la máquina virtual. Las aplicaciones que utilizan JDBC no tienen que
preocuparse de la arquitectura de la máquina o del sistema operativo, ya que esto es
abstraído por la máquina virtual.

Java proporciona un amplio soporte para la gestión de objetos remotos a través de su


Remote Method Invocation API y Enterprise Java Beans. Esto permite a los
desarrolladores, centrase más en los procesos de gestión de datos y menos en
cuestiones particulares del sistema (transparencia de ubicación).

JDBC se ha convertido en una API para el acceso a cualquier tipo de forma de


manejo de datos como hojas de cálculo, ficheros planos y por supuesto, de bases de
datos.

JDBC está basado en el estándar de facto ODBC de Microsoft. ODBC por su parte,
está basado en la especificación X/Open CLI. ODBC está disponible para Windows
y puede ser accedido mediante C, C++, Visual Basic y muchos otros lenguajes.

Mientras que ODBC simplemente una API a nivel de C, JDBC representa una capa
completa orientada a objeto de acceso a bases de datos. Ya que JDBC sigue de cerca
el funcionamiento de ODBC, se puede implementar un driver JDBC sobre un driver
ODBC (un “puente” JDBCODBC), que fue lanzado al mercado por INTERSOLV.

Drivers JDBC

Los drivers JDBC drivers son clases de implementación para operaciones de bases de
datos. Podemos dividir los drivers en dos categorías:

• Two-tier, donde el cliente se comunica directamente con la base de datos.


• Three-tier, donde el cliente se comunica con una capa intermedia, normalmente
Weblogic Server, que delega a una base de datos

Pág. 9 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Los drivers JDBC drivers son una simple colección de clases que implementan
métodos conocidos y definidos por las especificaciones del driver JDBC. Estos
drivers se dividen en dos clases: two-tier y three-tier.

Los drivers Two-tier se usan por un cliente, independientemente de qué cliente


es, para accede a una base de datos directamente.

En un driver three-tier, WebLogic Server actúa como capa intermedia,


optimizando las conexiones para la base de datos, normalmente mediante un
pool de conexiones. Un pool de conexiones es una colección de conexiones a una
base de datos. WebLogic Server crea as conexiones de un pool de conexiones en
tiempo de arranque. Estas conexiones se configuran para usar un driver JDBC en
particular y para conectarse a una base de datos específica.

El gráfico anterior, muestra cómo las aplicaciones pueden conectarse directamente a


una base de datos usando JDBC ó usando Weblogic Server, que a su vez utiliza
JDBC, para la conexión.

Arquitectura JDBC

Las aplicaciones que usan JDBC pueden usar uno de los cuatro tipos de drivers
JDBC distintos.

El primer tipo de driver es el puente JDBC-ODBC. El programa Java accede a la base


de datos a través de una conexión ODBC client-configured. Una aplicación cliente,
puede incluso usar un driver JDBC que tiene acceso al driver nativo de la API
instalado en el lado del cliente para una base de datos particular

Pág. 10 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Un driver de tipo 2, proporciona un puente desde la API Java JDBC hasta el driver
native instalado en el cliente. El driver nativo tiene los protocolos para comunicarse
directamente con la base de datos.

El driver de tipo 3, ó implementación multi-capa, utiliza un servidor de red para


pasar las peticiones JDBC a la base de datos.

Un driver de tipo 4 es una implementación Java del driver nativo JDBC de la base de
datos. La base de datos y la aplicación JDBC realizan llamadas Java-to-Java usando
este tipo de driver. Los drivers JDBC que permiten a una máquina cliente
comunicarse directamente con la base de datos se llaman implementaciones de dos
capas (two-tier), mientras que al driver de tipo 3 se le llama implementación multi
capa.

Consideraciones sobre los drivers JDBC

La elección del tipo de driver correcto es tan importante que puede tener una gran
influencia en el rendimiento.

Un driver de Tipo 2 no es necesariamente más rápido.


El driver Thin de Oracle 10g es significativamente más rápido que el driver Thin
de 9i.

Pool de Conexiones

Una de las ventajas de usar un pool de conexiones sobre una conexión directa es que
las conexiones ya existirán cuando las aplicaciones quieran conectarse a una base de
datos.

Esto ahorra a las aplicaciones la sobrecarga de la creación de conexiones. Incluso el


software de la capa intermedia, Weblogic Server, puede aplicar un balanceo de carga
mediante la asignación de conexiones a aplicaciones usando una base de datos, y
luego liberando y poniéndolas disponibles para otras aplicaciones cuando no estén
en uso.

El balanceo de carga puede incluso incluir un crecimiento y una reducción dinámica


del número de conexiones en un pool de conexionespara adptarse a condiciones de
cambio de cargas. El pool de conexiones añade otras ventajas como la aplicación de
seguridad a una conexión.

El gráfico muestra que el servidor de aplicaciones aloja el pool de conexiones y que


las aplicaciones utilizan los pools en función de sus necesidades.

Pág. 11 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Data Sources

Un data source es un concepto J2EE que permite abstraer una conexión JDBC. Con
un data source, un desarrollador o administrador puede especificar un objeto que
representa una base de datos. En el caso de WebLogic Server, un data source
contiene y gestiona un pool de conexiones.

Un usuario puede acceder a un data source y usarlo para crear una conexión a la
base de datos via el pool de conexiones asociado con el data source. El concepto de
data source permite a los desarrolladores despreocuparse completamente del pool
de conexiones o de la base de datos que se emplean para crear la conexión.

El gráfico muestra como las aplicaciones Java usan JNDI para obtener una referencia
a un data source. Esto lo hace con la llamada lookup(). La aplicación Java toma
después una conexión del data source usando una llamada al método
getConnection(). A partir de ese momento, la aplicación Java está lista para hacer
llamadas a la base de datos usando esa conexión.

Tamaño del Pool de Conexiones

Capacidad Inicial: El número de conexiones físicas a crear cuando se crea un


pool de conexiones. Es también el número mínimo de conexiones físicas que el
pool de conexiones mantendrá disponibles.

Capacidad Máxima: El número máximo de conexiones físicas que el pool de


conexiones puede contener.

Incremento de Capacidad: El número de conexiones creadas al añadir nuevas


conexiones al pool de conexiones. Cuando no hay más conexiones físicas
disponibles para satisfacer las peticiones de conexión, WebLogic Server crea
este número de conexiones físicas adicionales y las añade al pool de
conexiones.

Shrink Frequency

WebLogic Server reduce periódicamente el pool de conexiones a su capacidad inicial


en function del uso.

El parámetro Shrink Frequency se usa para especificar el número de segundos a


esperar antes de reducer un pool de conexiones.
Si está a 0, shrinking está deshabilitado. Esto puede ser muy útil en un entorno
de producción.

Pág. 12 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Testeo de conexiones

Test Connection On Reserve: Habilita a WebLogic Server para hacer un test


sobre una conexión antes de dársela a un cliente. El test añade un pequeño
retraso en la petición del cliente para una conexión del pool, pero asegura que
el cliente reciba una conexión viable.

Test Frequency: El número de segundos que pasa entre los tests que realiza
WebLogic Server sobre conexiones que no se están usando. Las conexiones que
fallan en el test se cierran y se vuelven a abrir para intentar reestablecer una
conexión física válida. Si se pone a 0, estos tests periódicos se deshabilitan.

Nota: Ambos parámetros requieren que se le indique un nombre de tabla para el test
y sobre la que se realizará un consulta de tipo SQL, select * from <tabla>.

Row Prefetch

El row prefetching mejora el rendimiento al cargar multiples filas del servidor al


cliente en un único acceso. El tamaño óptimo del prefetch depende de las
particularidades de la consulta. En general, el incremento del tamaño suele mejorar
el rendimiento, hasta que se alcance un valor particular.

Row Prefetch Enabled: Habilita la precarga de multiples filas (es decir, las que se
envían desde el servidor al cliente) en un acceso al servidor. Cuando un cliente
externo accede a una base de datos usando un driver JDBC a través de
WebLogic Server, el row prefetching mejora el rendimiento mediante la
precarga de múltiples filas desde el servidor al cliente en un solo acceso.
WebLogic Server ignora esta opción y no usa la precarga cuando el cliente y
WebLogic Server están en la misma JVM.

Tamaño del Row Prefetch: Si está habilitado el row prefetching, especifica el


número de filas que se precargan. El tamaño óptimo del prefetch depende de las
particularidades de la consulta. En general, el incremento del tamaño suele
mejorar el rendimiento, hasta que se alcance un valor particular. En este caso, no
tendríamos una mejora muy significativa en el rendimiento. Muy raramente
conseguiremos mejorar el rendimiento al exceder de 100 filas.

Los valores mínimo y máximo para este parámetro son respectivamente 2 y 65536.

Cacheo de sentencias

Un objeto de tipo sentencia JDBC o statement se usa para enviar sentencias SQL a la
base de datos al igual que un objeto de tipo JDBC PreparedStatement se usa para
enviar sentencias SQL precompiladas con uno o más parámetros.

Los objetos PreparedStatement se usan para sentencias SQL que se usan de forma
repetida con posibles variaciones en las variables, y al estar precompiladas se
aumenta el rendimiento de dichas llamadas. En el caso de llamadas a procedimiento
y funciones almacenadas, es necesario usar otro tipo de objetos, JDBC
CallableStatement.

El comportamiento de Weblogic Server en cuanto a la funcionalidad de cacheo de


sentencias puede controlarse a través del parámetro Statement Cache Type. Es

Pág. 13 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

parámetro define el algoritmo usado para mantener las sentencias preparadas


almacenadas en el statement cache.

Las opciones son:

• LRU, es decir, cuando llega una sentencia nueva, ya sea de tipo prepared o tipo
callable statement, la sentencia menos usada es reemplazada por la nueva en la
caché.

• FIXED, es decir, se cachean las N primeras sentencias, ignorando el resto


respecto al cacheo.

Para determinar el tamaño de la caché, Weblogic Server usa el parámetro Statement


Cache Size, que permite determinar el número de prepared y callable statements que
se almacenan en caché.

Dos características adicionales para esta característica:

• Cada conexión en el pool de conexiones tiene su propio cache de sentencias.

• Si se indica un valor de Statement Cache Size igual a 0, se deshabilita esta


opción.En caso contrario, los valores mínimo y máximo para este parámetro son
respectivamente 0 y 1024.

PinnedToThread

PinnedToThread es una opción que puede mejorar el rendimiento al permitir que las
execute threads mantengar la conexión a base de datos incluso después de que la
aplicación cierre la conexión lógica.

Cuando PinnedToThread está habilitado, WebLogic Server fija una conexión del
pool de conexiones a la hebra la primera vez que ésta reserva la conexión. En el
momento que la aplicación termina de usar la aplicación e invoca a
connection.close(), devolviendo la conexión al pool, Weblogic Server mantiene esta
relación y no la devuelve realmente. Cuando la aplicación a través de la hebra
vuelve a realizar una petición a base de datos, ya tiene disponible una conexión a
ésta.

Un efecto de esta configuración, es que se reduce la potencial contención que se crea


cuando múltiples hebras intentan reservar una conexión en un momento del tiempo
y existen suficientes conexiones dentro del pool para todas ellas.

En este caso, donde la aplicación reserva más de una conexión dentro de una misma
hebra de ejecución, Weblogic Server creará una conexión adicional y la mantendrá
asociada a dicha hebra gracias a esta funcionalidad.

Pág. 14 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Batch Updates
Una aplicación típica puede llegar a ejecutar una gran cantidad de sentencias de
manipulación de datos, operaciones de tipo insert, update o delete.

Este tipo de situaciones, se pueden obtener benecificios si:

• Las combinamos de forma apropiada podremos mejorar el rendimiento.


• Usamos Statement.addBatch() y Statement.executeBatch() para realizar
operaciones por lotes o batching updates.

Gestión de transacciones

La gestión de la transaccionalidad de una aplicación pueden requerir un esfuerzo


extra por parte de sistemas con el fin de evitar situaciones de inconsistencias y/o
corrupciones por parte de los datos que maneja una aplicación.

En el caso de las bases de datos, las transacciones consumen y mantienen muchas


clases de recursos en uso para asegurar que se aplican las propiedades ACID, es
decir, atomicidad, consistencia, aislamiento y durabilidad, a una transacción.

Con el fin de reducir esta carga extra de trabajo, se puede recomendar que, en la
medida de lo posible, múltiples transacciones se unifiquen dentro del menor número
de transacciones posibles.

Por defecto, las conexiones JDBC trabajan en modo auto-commit, lo que significa que
todas las operaciones enviadas a la base de datos se ejecutan automáticamente como
una transacción separada.

Al deshabilitar el auto-commit e indicando explícitamente los límites de las


transacciones se puede conseguir mejorar el rendimiento de las aplicaciones. Para
ello, basta con utilizar simplemente la sentencia JDBC siguiente:

Connection.setAutoCommit(false)

La API de JDBC proporciona también el método Connection.getAutoCommit() que


devuelve el valor actual del modo auto-commit. Cuando se deshabilita el auto-
commit, sera necesario el uso de los métodos Connection.start(),
Connection.commit() y Connection.rollback().

Niveles transaccionales

El nivel de aislamiento de una transacción suele definirse como el balanceo de las


siguientes características:

• La integridad de los datos frente a


• La velocidad de acceso concurrente

En base a este balanceo se establecen cuatro nieveles transaccionales:

• TRANSACTION_READ_UNCOMMITTED

Pág. 15 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

• TRANSACTION_READ_COMMITTED
• TRANSACTION_REPEATABLE_READ
• TRANSACTION_SERIALIZABLE

Como veremos, cuando más alta es la integridad de los datos, más lento es el acceso.
Estos dos aspectos pueden ser controlados por el nivel de aislamiento de la
transacción.

Pero ¿a qué nos referimos con integridad? Cuando hay un problema con la
integridad significa que hay una discrepancia entre los datos de dos transacciones. A
continuación tenemos varios escenarios que muestran problemas de integridad:

• Dirty reads: Una fila ha sido modificada por otro proceso y esa modificación no
ha hecho commit aún.
• Non-repeatable read: Una fila ha sido modificada por otro proceso que ha
confirmado la modificación..
• Phantom row: Un fila ha sido eliminada por otro proceso, y el borrado no ha
sido confirmado aún.

Volviendo a los cuatro niveles de aislamiento transaccionales:

• TRANSACTION_READ_UNCOMMITTED: Se permiten Dirty reads, non-


repeatable read y phantom reads. Es el nivel más permisivo.

• TRANSACTION_READ_COMMITTED: No se permiten las dirty reads. Sin


embargo, si están permitidas las non-repeatable reads y las phantom reads.

• TRANSACTION_REPEATABLE_READ: No se permiten las dirty reads nil as


non-repeatable reads. Las Phantom reads si están permitidas.

• TRANSACTION_SERIALIZABLE: No se permiten Dirty reads, non-repeatable


read ni phantom reads. Es el nivel más restricctivo.

Pág. 16 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Best Practices para Java Message Service

Un sistema orientado a mensajería es aquel que a través de un sistema de


mensajería, permite el intercambio de información entre procesos basándose en
mensajes.

Java Message Service (JMS) el API estandar para el acceso a sistema de mensajería en
Java.

Sin embargo hay que tener en cuenta que JMS no es un proveedor de servicio ó un
servidor Message-Oriented Middleware (MOM). Es simplemente un conjunto de
interfaces que definen un estándar de Java para acceder a productos de tipo
Enterprise Messaging (EM).

Por tanto, a través de JMS :


• Se permite a las aplicaciones Java compartir un sistema de mensajes para el
intercambio de mensajes.

• Se simplifica el desarrollo de las aplicaciones proporcionando una interfaz


estándar para la creación, envío y recepción de mensajes

El gráfico muestra cómo dos programas pueden estar desacoplados gracias a un


sistema MOM, done el proveedor de datos pone el mensaje en él y el consumidor
toma dicho mensaje y lo procesa.

La especificación JMS define muchos aspectos de los mensajes, como su formato y su


interacción con los distintos proveedores de servicios. Sin embargo, la especificación
JMS no se ocupa de temas como:

• Balanceo de Carga
• Tolerancia a fallos
• Notificación de errores
• Administración
• Seguridad e integridad de los mensajes
• Protoco de envoi para mensajes binarios

El gráfico muestra que los clientes JMS son aplicaciones conectadas al sistema MOM,
es decir, tanto el emisor como el receptor del mensaje son considerados clientes JMS.

Pág. 17 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Dos tipos de dominios JMS

La especificación JMS define dos dominios accesibles:

el dominio punto a punto, point-to-point o PTP.


y el dominio proveedor/consumidor, publish/subscribe o pub/sub.

La especificación JMS clasifica en terminos generales todos los productos de


mensajería en uno de estos dominios.

• Un ejemplo de dominio point-to-point es una aplicación que envía un mensaje


de log a una cola, que es escrito a un fichero de texto por otro proceso.
• Un ejemplo de dominio publish/subscribe es una aplicación que publica el valor
de una acción en mútiples sistemas de venta de acciones que previamente
estaban suscritos.

El gráfico muestra como en la mensajería point-to-point el mensaje solo es recibido


por un único cliente o receptor. En el caso de publish/subscribe, el mensaje llega a
varios consumidores o suscriptores.

Arquitectura JMS

JMS es una API para el acceso a sistemas de mensajería empresarial. JMS permite a
las aplicaciones Java compartir un sistema de mensajería para el intercambio de
mensajes. Simplifica el desarrollo de aplicaciones proporcionando una interfaz
estándar para la creación, envío y la recepción de mensajes.

En este ámbito de JMS, JNDI se usa para crear un contexto inicial para una
connection factory de tipo JMS, que se usará para crear conexiones a proveedores de
servicio basados en JMS.

Pág. 18 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

El gráfico muestra que para que un proveedor pueda enviar un mensaje,


necesitamente previamente crear un connection factory y una conexión con el
servidor JMS.

Un objeto ConnectionFactory encapsula información de configuración de conexiones


y habilita a las aplicaciones JMS para la creación de conexiones. Cuando se establece
la conexión, se invoca a una sesión que habilita al proveedor para enviar el mensaje
al destinatario.

Operativa de clientes JMS


Una llamada desde un cliente JMS a un servidor MOM implica los siguientes pasos:

• Crear una connection factory desde el servicio de nombres (JNDI)


• Usarla para crear la conexión JMS.
• Usar la conexión para crear una sesión.
• Acceder a los destinos, ya sean de tipo queue o de tipo topic a través de JDNI.
• Usar la sesión y el destino para establecer si se va a producir o consumir
mensajes.
• Crear y enviar mensajes o recibir y consumir mensajes.

Agregación y flujo de mensajes


Existen ocasiones donde desde un mismo punto y con el mismo destino se envian
varios mensajes asíncronos. En esta situación es recomendable agruparlos y
enviarlos en un único envio ya que:

• Esto implica que el servidor JMS agregue las peticiones concurrente de una
mismo cliente en una única operaciones de E/S.
• Los mensajes pueden ser entregados a través de listeners de mensajes.
• Se permite múltiples mensajes en una misma llamada de red.
• Puede parametrizarse la cantidad maxima de mensajes a través de la connection
factory.

Persistent Stores

Si el número de mensajes almacenados incrementa, el almacenamiento necesario


para persistir los mensajes se incrementay por tanto, aumenta la cantidad de
memoria necesaria para la ejecución de WebLogic Server.

Los componentes JSM de Weblogic Server pueden almacenar mensajes de forma


persistente en un almacenes basados en archivos ó en un base de datos a través de
JDBC.

Veamos a continuación comparación entre ambas opciones:

• Ambos tienen la misma semántica de transacciones y garantías


• Ambos tienen la misma interfaz de aplicación.
• Los almacenes de archivos suelen ser generalmente más rápidos y fáciles de
configurar.
• Los almacenes de archivos son más flexibles para el volcado o paging de
mensajes no que no es necesario persistir.

Pág. 19 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

• Los almacenes JDBC pueden hacer más fácil las labores de recovery en caso de
fallos ya que, al almacenarse en una base de datos, lo mas probable que se
encuentre en otra máquina de la red.

Persistencia basada en ficheros

En el caso de la persistencia basada en ficheros es necesario definir la política de


escritura síncrona que se va a emplear. Esta política afecta en el rendimiento de los
almecenes JMS, en la escalabilidad y en la fiabilidad general del sistema.

Las opciones de política válidas son:

• Direct-Write, donde las escrituras en el almacen se hacen directamente a disco.


Esta política está soportada en Oracle Solaris, HP-UX, y MS Windows. En este
último caso, MS Windows, esta opción generalmente es más rápida que la
opción de Cache-Flush.

• Disabled, donde las transacciones se completan tan pronto como se cachean sus
escrituras en memoria, en lugar de esperar a que las escrituras alcancen al disco.
Esta política es la más rápida, pero la menos fiable desde el punto de visdta
transaccional. Puede ser más de 100 veces más rápido que otras políticas, pero
los cortes de luz ó fallos del sistema operativo pueden causar pérdidas ó
mensajes duplicados.

• Cache-Flush, donde las transacciones no se pueden completar hasta que todas


las escrituras se envíen a disco. Esta política es fiable y escala bien cuando el
número de usuarios simultáneos incrementa.

Paging

Durante situaciones de gran carga de mensajes, éstos se paginan en disco para


conservar memoria.

En esta situación, hay que tener en cuenta que:

• Para mejorar el rendimiento, se recomienda que el directorio de paginación debe


ser diferente del persistent store o almacen del servidor JMS.

• Una paginación excesiva podría degradar el rendimiento.

• Se puede minimizar la paginación mediante:


Incremento el tamaño del buffer del mensaje
Incremento del tamaño de heap de la JVM
Usando técnicas de throttling

La paginación está siempre habilitada en WebLogic Server. Si no se especifica un


directorio de paginación, los cuerpos de los mensajes a paginar se escriben en el
directorio por defecto /tmp que se encuentra dentro del subdirectorio servername
del directorio principal del dominio.

Tamaño del buffer del mensaje

Pág. 20 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

La opción Message Buffer Size especifica la cantidad de memoria que se usará para
almacenar el cuerpo de los mensajes en memoria antes de que se paginen a disco. EL
valor por defecto de Message Buffer Size es aproximadamente un tercio del
maximum heap size para la JVM, con un máximo de 512 megabytes.

Cuanto más grande es este parámetro, más memoria consumirá los servidores JMS
cuando haya mensajes esperando en queues o topics. Una vez que se cruce este
umbral, el servidor JMS podrá escribir los cuerpos de los mensajes a un directorio
especificado por la opción Paging Directory con la intención de reducir el uso de
memoria.

Es importante destacar que este parámetro no es una quota. Si el número de


mensajes en el servidor supera el umbral, el servidor escribirá mensajes a disco y los
desaloja de memoria tan rápido como puede para reducir el uso de ésta. Sin
embargo, no parará de aceptar nuevos mensajes. Esto no impide que se acabe la
memoria si los mensajes siguen llegando más rápido de lo que tardan en ser
paginados.

Por tanto, los servicios con una alta carga de mensajes deben considerar fijar una
quota, ó un umbral, y habilitar control de flujo para reducir el uso de memoria en el
servidor.

Throttling

El tráfico de mensajes bajo condiciones de un alto volumen puede ser impredecible y


producirse a diferentes ritmos de llegada y salida:

En esta situación:

• Los mensajes se pueden producir mucho más rápido de los que tardan en
consumirse, causando una congestión.

• Esta condición requiere que el mensaje que se envía pase por el control de flujo.

• El throttling también aborda el problema de que los productores saturen a los


consumidores, compartan o no los mismos recursos.

En la mayoría de los sistemas de mensajes, el emisor del mensaje es más rápido que
el receptor, ya que normalmente tiene que hacer menos trabajo. Sin embargo, el
receptor tiene una carga de trabajo superior, ya que tiene que enviar un ACK o
acknowledge, por cada mensaje que recibe.

Si no está limitado, este desequilibrio puede llevar a condiciones de desbordamiento


de tiempo de respuesta que pueden causar incluso que la instancia de WebLogic
Server se quede sin memoria.

Técnicas para la implementación de throttling

La implmentación de Weblogic Server de JMS proporciona las siguientes técnicas de


throttling:

• Configuración de cuotas de mensajes, la configuración de cuotas ayuda a evitar


que el servidor se quede sin memoria.

Pág. 21 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

• Tuning flow control:


El control de flujo es configurable a través de una connection factory. A partir
de Weblogic Server 7.0 se proporciona control de flujo para frenar a posibles
productores excesivamente activos. Este control de flujo tiene efecto cuando se
sobrepasa el umbral de mensajes configurables aunque también puede
expecificarse en número de bytes. Es esta situación, se fuerza a los producers a
ir más lento mediante el retraso inducido en las llamadas que producen el
mensaje de respuesta.

• El diseño de aplicaciones usando un patrón de tipo petición/respuesta:


El patrón de petición/respuesta es un método efectivo y común de throttling
que se incorpora al diseño de una aplicación. En esta técnica, el que hace la
petición se bloquea, y no puede enviar otro mensaje hasta que reciba una
respuesta del receptor.

• Incremento del blocking send timeout:


Los servidores JMS de Weblogic Server bloquean temporalmente el envío de
operaciones por parte del productor si se alcanza un valor de cuota. Si la cuota
se alcanza durante el tiempo que el productor envia el mensaje, éste tendrá
éxito. Esto mejora el rendimiento de aplicaciones que reintentan enviar el
mensaje una vez alcanzada la quota. Por defecto, los produces bloquean hasta
10 mensajes.

• Configuración de política de expiración de mensajes:


Se dice que un mensaje expira, si este es consumido, borrado, o es redirigido a
otro destinatario. Se puede usar esta característica para aliviar las condiciones
de desbordamiento, ya que provoca la limpieza y eliminación de los mensajes
más antiguos.

Cuotas JMS

Máximo número de bytes.

Define el número total de bytes que pueden ser almacenados en un destinatario que
usa esta cuota. Un valor de 0, significa que no se pueden enviar mensajes a un
destinatario sin exceder la quota. Un valor de -1 evita que WebLogic Server imponga
un límite.

Es importante recordar que un volumen excesivo de bytes puede causar una


saturación de memoria, Oracle recomienda que el máximo corresponda con la
cantidad de memoria del sistema disponible después de contabilizar las aplicaciones
desplegadas y su consumo de memoria.

Número máximo de mensajes

Define el número máximo de mensajes que pueden ser almacenados en un servidor


JMS. Un valor de -1 elimina cualquier límite por parte de WebLogic Server.

Es importante recordar que un volumen excesivo de bytes puede causar una


saturación de memoria, Oracle recomienda que el máximo corresponda con la
cantidad de memoria del sistema disponible después de contabilizar las aplicaciones
desplegadas y su consumo de memoria.

Pág. 22 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Política de bloqueo de envíos (Blocking Send Policy)

Determina si el servidor JMS de Weblogic Server puede entregar los mensajes más
pequeños antes que los más grande cuando un destinatario ha excedido si número
máximo de mensajes.

Por tanto, a través de esta técnica, desactivamos la política FIFO que impide que el
servidor JMS entregue mensajes pequeños cuando haya mensajes grandes ya
esperando por espacio, al permitir que los mensajes pequeños se adelanten a los
grandes cuando hay espacio suficiente para mensajes pequeños en el destinatario.

Esta política se define sólo en el servidor JMS, no se puede establecer en los


destinatarios individuales.

Tamaño máximo de mensaje

Define el número máximo de bytes permitido en mensajes individuales en un


servidor JMS de Weblogic Server.

El tamaño de un mensaje incluye el cuerpo del mensaje, cualquier propiedad


definida por el usuario y los campos de las cabeceras definidos por el usuario como
JMSCorrelationID y JMSType.

Umbrales o threshold

Se define bytes threshold high, como el umbral superior, en número de bytes


almacenados en este servidor JMS, que lanza el control de flujo y los eventos. Un
valor de -1 deshabilita los eventos para este servidor JMS.

En cuando a bytes threshold low, se define como el umbral inferior, en


número de bytes almacenados en este servidor JMS, que lanza el control de flujo y
los eventos. Un valor de -1 deshabilita los eventos para este servidor JMS.

Igualmente pude definirse por número de mensajes, a través de messages


threshold high y messages threshold low.

Control de flujo
Flow Maximum
El número máximo de mensajes por segundo permitido para un productor que está
experimentando una condición de umbral (threshold condition). Cuando se controla
el flujo de un productor, nunca podrá sobrepasar el número FlowMaximum de
mensajes por segundo.

Si un productor no está limitando su flujo cuando se alcanza una condición umbral,


el límite de flujo inicial se fija en FlowMaximum. Si un productor ya está limitando
su flujo cuando se alcanza una condición umbral (el límite de flujo es inferior a
FlowMaximum), el productor continuará con su límite hasta la próxima vez que se
evalúe el flujo.

Flow Minimum

Pág. 23 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

El número mínimo de mensajes por segundo permitido por un productor que está
experimentando una condición umbral. Es el límite inferior de flujo de un productor.
Esto es, WebLogic JMS no relentizará a un productor que haya alcanzado el umbral
de FlowMinimum.

Flow Interval
El período de tiempo, en segundos, mientras que un productor ajusta su flujo desde
el número FlowMaximum de mensajes hasta el FlowMinimun, ó viceversa.

Flow Steps
El número de pasos cuando un productor ajusta su flujo desde una cantidad de
mensajes Flow Maximum a una cantidad de mensajes Flow Minimum, ó viceversa.

El Flow Interval se divide entre el número de pasos (por ejemplo, 60 segundos


divididos entre 6 pasos dan 10 segundos por paso).

Flow Control Enabled


Especifica si un productor creado usando una connection factory permite control de
flujo. Si está activado, los productores de mensajes correspondientes, reducirán su
velocidad si un servidor JMS o un destino alcanzan su umbral máximo.

Gestión de expirados

La política de expiración define qué acción debe tomar un destinatario en caso de


que se encuentre un mensaje expirado. La política puede descartar el mensaje,
descartar el mensaje y registrar su eliminación, o redireccionar el mensaje a un
destinatario alternativo.

No se recomienda el uso del parámetro Expiration Logging Policy ya que se


considera en estado deprecated en esta versión de WebLogic Server 10g y
superiores.

En su lugar, Oracle recomienda el uso de Message Life Cycle Logging, que


proporciona una vista más comprensiva de los eventos básicos por los que pasarán
los mensajes JMS una vez que son aceptados por un servidor JMS, incluyendo datos
detallados de la expiración del mensaje.

Configuración de políticas de expiración

Las plantillas JMS proporcionan una forma eficiente de definir múltiples


destinatarios, sean topics o queues, con características y ajustes similares.

Si se usan plantillas JMS para configurar múltiples destinatarios, se puede usar el


campo Expiration Policy para configurar una política de expiración en todos los
destinatarios. Para anular o modificar la política de expiración para destinatarios
específicos, se puede modificar a nivel de cada destinatario de forma particular.

Para configurar una política de expiración de mensaje en una plantilla existente para
los destinatarios, se puede seleccionar uno de las siguientes opciones de la lista de
Políticas de Expiración en la página Delivery Failure de la pestaña de Configuración:

• Discard: Elimina los mensajes expirados del sistema de mensajes. La eliminación


de mensajes no se registra, y los mensajes no se redirigen a otra ubicación.

Pág. 24 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

• Log: Elimina los mensajes expirados y escribe una entrada en el archivo de log
del servidor indicando que los mensajes se han eliminado del sistema. Esta
característica ha sido declarada como deprecated.

• Redirect: Mueve los mensajes expirados de su ubicación actual al destino


definido como Error Destination para el destinatario.

Escaneo de mensajes expirados

La política de expiración definirá la cantidad de tiempo en que los mensajes


expirarán y lo que ocurre una vez que expiran. Sin embarego, los mensajes no se
eliminan necesariamente del sistema ni se moverán a un nuevo destinatario llegado
este momento.

Para ello, se puede configurar un servidor JMS para explorar activamente los
mensajes expirados de los diferentes destinos.

Para definir esto, se puede especificar el valor, en segundos, en el campo Expiration


Scan Interval de la pestaña General en sobre la pestaña de Configuración. El valor
especificado en este campo es la cantidad de tiempo que se quiere que el servidor
JMS se pause entre sus ciclos de escaneo de destinatarios para el procesado de
mensajes expirados. El valor por defecto es 30 segundos, los que significa que el
servidor JMS espera 30 segundos entre cada intervalo de exploración. Para
deshabilitar la exploración, introducir un valor de 0 segundos.

Los mensajes expirados se eliminarán de forma pasiva del sistema cuando se


descubran.

Acuse de recibo (Acknowledgement)

Se recomienda usar las póliticas de acuse de recibo DUPS_OK_ACKNOWLEDGE y


AUTO_ACKNOWLEDGE ya que poseen un mejor rendimiento que la pólitica
CLIENT_ACKNOWLEDGE.

Es importante destacar que:

• Ambos AUTO_ACKNOWLEDGE y DUPS_OK_ACKNOWLEDGE garantiza la


entrega de mensajes, pero el mecanismo de doble acuse de recibo a pesar de
tener un mejor rendimiento posee el coste de que ocasionalmente se pueda
duplicar un mensaje.

• Hay que diferenciar entre los acuses de recibo o acknowledgments JMS y las
operaciones de commits.

Para establecer el modo de acuse de recibió, o acknowledgement mode, se debe


realizar en tiempo de creación del objeto de sesión desde la conexión, tal como se
muestra a continuación:

Session session = connection.createSession(false,


Session.AUTO_ACKNOWLEDGE);

Pág. 25 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Store and Forward (SAF)

Store and forward (SAF) es un mecanismo asíncrono de comunicación que permite a


un proveedor pueda enviar un mensaje a un consumidor en un lugar remoto,
independientemente de la disponibilidad del elemento remoto.

En esta situación, el mensaje se almacenará en un almacen persistente o persistent


store o en memoria del punto local y se reenviará al punto remoto cuando éste esté
disponible.

Otra de las funcionalidades que SAF permite, es el envio de mensajes a aplicaciones


distribuidas en otras instancias de Weblogic Server. Por ejemplo, la aplicación A se
ejecuta en un Weblogic Server local y se comunica con la aplicación B que se ejecuta
en otro Weblogic Server remoto. Las aplicaciones A y B pueden desconectarse dado
que la red no es totalmente segura. En esta situación, la aplicación A envía un
mensaje a la aplicación B usando un servicio SAF de Weblogic Server, el mensaje se
almacenará bien en un almacen bien en la memoria del servidor local.
Posteriormente el mensaje se enviará a la aplicación B cuando esté disponible.

SAF usar un sistema unificado de subsistemas de almacenamiento de Weblogic


Server 10g y posteriors. A través de este subsistema, ya sea en fichero o en base de
datos, el almacen se creará para el servicio SAF de Weblogic Server.

Los servicios SAF de Weblogic Server pueden ser usados tanto por aplicaciones JMS
como por aplicaciones que usen Web Services Reliable Messaging (WA-RM). En el
primer caso, los productores locales JMS pueden enviar mensajes a destinos JMS
remotos. En el segundo, en los servicios SAF de tipo WSRM, los Web Services
pueden estar en Weblogic Server separados para intercambiar mensajes.

Las ventajas de SAF son:

• Habilita una entrega rápida y fiable de mensajes en las aplicaciones que corren
en WebLogic Server

• Asegura la entrega secuencial de mensajes mediante el mecanismo Unit-of-


Order

• Es transparente a las aplicaciones que lo usan.

Las desventajas de SAF son:

• No puede reenviar mensajes a versiones anteriores de WebLogic Server 10g.

• No puede interoperar con productos JMS de terceros.

Ajuste de rendimiento para servicios SAF

Intervalo de Ventana

Un agente emisor de mensajes esperará para reenviar el mensaje de tipo batch hasta
que:

• El número de mensaje en la fuente destino es mayor o igual que el tamaño


configurado como Window Size.

Pág. 26 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

• Ha esperado el tiempo indicado a través del parámetro Window Interval, lo que


suceda antes.

El intervalo de ventana, Window Interval, tiene efecto y mejora el rendimiento sólo


en casos donde el que reenvía está capacitado para reenviar mensajes tan rápido
como lleguen. En este caso, en lugar de reenviar inmediatamente los nuevos
mensajes que llegan, el que reenvía, se pausa en un intento de acumular más
mensajes y reenviarlos como un proceso por lotes.

Tamaño de Ventana

Para WS-RM, se define como el número máximo de mensajes no confirmados, o


unacknowledged messages, permitido entre una fuente y un destino durante una
conversación.

En caso de definirse, un agente emisor debe esperar para reenviar un mesaje de tipo
batch hasta que el número de mensajes en la fuente destino sea mayor ó igual que
este valor.

Pág. 27 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Best Practices para Enterprise JavaBeans

La especificación Enterprise JavaBeans (EJB) es una especificación de arquitectura


de componentes que define la estructura de beans, la estructura de contenedores en
los cuales operan, y los métodos para la interacción con sus clientes.

Infraestructura de servicios, implementación de servidor de aplicaciones y la


implementación del cliente se definen por los desarrolladores y por el fabricante del
servidor de aplicaciones. Para más información sobre EJBs y para ver la
especificación visitar

http://java.sun.com/products/ejb/index.html.

Cada EJB tiene un enfoque de diseño en particular y unos requerimientos para su


construcción. Se pueden obtener muchos beneficios teniendo una buena variedad de
tipos de EJB.

Las diferencias entre los tipos de EJB permiten al servidor de aplicaciones optimizar
el rendimiendo siendo capaz de hacer estimaciones sobre el estado y el nivel de
persistencia del componente. Los EJBs que no tienen gestión del estado pueden tener
un mayor grado de pooling que los EJBs que tienen estado. Los tres niveles de
conducta que un componente puede asumir son:

• No mantener el estado entre las peticiones de los clientes como lo EJBs stateless
session o los EJBs de tipo message-driven.
• Mantener el estado, pero no persistente, como los EJB stateful session.
• Persistente, como los EJBs de entidad.

Interfaces EJB

Excepto los de tipo message-driven, los EJBs tienen las siguientes interfaces que un
cliente puede usar:

• Home interface
Local Home interface
• Remote interface
Local interface

Pág. 28 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Estructura de aplicaciones EJBs


Una aplicación EJB está compuesta por

• Es una archivo JAR


• Uno o más EJBs.

Estructura mínima de una aplicación EJB estándar es la siguiente:

EJBFiles.class
\relative\path\of\package\name\EJBFiles.class
\META-INF\ejb-jar.xml
\META-INF\weblogic-ejb-jar.xml

En el caso de uso de beans de entidad será necesario el archivo que configura


opciones específicas de WLS:

\META-INF\weblogic-cmp-rdbms-jar.xml

Beans de tipo Stateless Session

El tipo de bean de tipo stateless session poseen las siguientes características:

• Proporcionan servicios no conversacionales


• No mantiene ningún estado del cliente con el que dialogan.
• Son síncronos
• No sobreviven a una caida del servidor que los atiende.
• Se mantienen en memoria
• Las instancias pueden ser cacheados y reusados entre diferentes peticiones.
• Dos clientes no pueden acceder a una misma instancia de forma concurrente.

Gestión del pool

Un contenedor de servidor de aplicaciones puede precrear y mantener EJBs de tipo


stateless session y hacer que sean reutilizables por diferentes clientes. Aunque
múltiples clientes pueden solicitar el uso de EJB de tipo stateless session, no es
necesario que el contenedor cree una instancia para cada cliente ya que lo normal es
que optimice el número de instancias que mantiene para hacer el servidor más
escalable.

La especificación EJB indica que una sesión EJB sólo puede ser accedida por un
cliente en cualquier momento. Esto significa que si un contenedor sólo creó una
instancia EJB y hay 10 clientes solicitando el uso de dicha instancia, sólo un cliente

Pág. 29 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

podrá acceder al mismo tiempo. El resto de los clientes deberán bloquearse y esperar
a que el primer cliente termine de usar EJB de tipo stateless session.

En caso de uso por parte de un cliente, éste no puede mantener el control de un bean
para siempre. Hay un período de timeout, RMI request timeout, después del cual, la
llámada al método falla y el bean queda libre de nuevo.

El gráfico anterior muestra cinco clientes intentando acceder a un EJB en un


contenedor. Dado que el pool para este tipo se ha dijado para un máximo de tres
beans, dos de los clientes se bloquearán en espera del acceso.

El gráfico anterior muestra el flujo de creación de un stateless EJB en el pool, como lo


avandona para atender una aplicación, permanecindo en estado ocupado, par
posteriormete volver al pool para ser inactivado.

Cuando Weblogic Server arranca crea y publica el pool de EJBs libres con la cantidad
de instancias que se han indicadp a traves del elemento de despliegue initial-beans-
in-free-pool en el fichero weblogic-ejb-jar.xml. Por defecto, este valor es 0.

Cuando la llamada al método se completa, la instancia EJB se devuelve al pool libre.


Dado que WebLogic Server desvincula al bean del cliente después de cada llamada,
la instancia que un cliente usa puede cambiar de invocación en invocación.

Si todas las instancias de una clase EJB están activas y se alcanza el max-beans-in-
free-pool, las nuevas peticiones de clientes sobre las clases EJB se quedarán
bloqueadas hasta que un EJB activo complete la llamada al método. Si la transacción
caduca o, para llamadas no transaccionales, pasan mas de cinco minutos, WebLogic
Server lanza una RemoteException al cliente remoto o una EJBException para el
cliente local.

Tamaño del pool

Cuando se elige el valor para initial-beans-in-free-pool y max-beans-in-free-pool,


hay que balancear el consumo de memoria con el retraso procido en la aplicación
debido a la creación de los instancias necesarias.

Si el número de EJBs de tipo stateless session es muy alto, el pool contiene instancias
inactivas que consume memoria. Si el número es muy bajo, un cliente puede no
obtener una instancia cuando lo necesite.

Pág. 30 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Normalmente max-beans-in-free-pool debe ser igual al número de hebras en la


instancia del servidor, de forma, que cuando una hebra intente completar una
petición, siempre exista una instancia disponible.

Configuración del pool de EJBs stateless session

Por defecto, no existen instancias EJB de tipo stateless session en WebLogic Server en
el momento de arranque. Como los clientes acceden a los beans individualmente,
WebLogic Server inicializa nuevas instancias de EJB a medida que las necesita.

Sin embargo, si se quiere que existan instancias inactivas de EJB en WebLogic Server
cuando se arranca, hay que especificar el número en el descriptor de despliegue
initial-beans-in-free-pool en el archivo weblogic-ejb-jar.xml.

Esto puede mejorar el tiempo inicial de respuesta cuando los clientes acceden a EJBs,
porque las peticiones iniciales de los clientes se pueden satisfacer mediante la
activación del bean desde el free pool, en lugar de inicializarlo y luego activarlo. Por
defecto, initial-beans-in-free-pool está a 0.

El tamaño máximo del free pool se limita por la memoria disponible o por el valor
del elemento de despliegue max-beans-in-free-pool.

<weblogic-enterprise-bean>
<ejb-name>InsuranceQuoteBean</ejb-name>
<stateless-session-descriptor>
<pool>
<max-beans-in-free-pool>15</max-beans-in-freepool>
<initial-beans-in-free-pool>5</initial-beans-infree-
pool>
</pool>
</stateless-session-descriptor>
...
</weblogic-enterprise-bean>

Message-Driven Beans (MDB)

Los Message-driven beans se introdujeron como parte de la especificación EJB 2.0.


Estos beans se comportan de manera similar a los beans de tipo stateless session,
pero son asíncronos.

Los componentes síncronos son aquellos que implementan un bloqueo y esperan su


comportamiento. Por ejemplo, cuando un cliente invoca a un método en un bean
stateless session, la aplicación cliente se bloquea y espera a que el bean complete la
ejecución. La aplicación cliente no puede continuar hasta que el bean haya acabado.

En cambio, en un modelo asíncrono, un cliente puede invocar un bean y no tener


que esperar a que el método se complete antes de continuar con otras actividades.
Los Message-driven beans son componentes asíncronos que desacoplan lo beans de
sus usuarios.

Los MDB dependen en gran medida de los conceptos de mensajería que se definen
como parte de la especificación JMS. La especificación JMS define un conjunto de
interfaces que abstraen los detalles de implementación de sistemas middleware
orientados a mensajes. Los clientes JMS envían mensajes a destinatarios JMS

Pág. 31 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

alojados en servidores de aplicaciones. La publicación de mensajes es una actividad


muy ligera para los clientes. Despues de publicar un mensaje, al cliente no le
importa como es direccionado y entregado. El servidor JMS es el responsable de esta
tarea.

En este ámbito, los MDBs son EJBs especiales encargados de recibir los mensajes
enviados de los clientes JMS.

El gráfico muestra un cliente entregando mensajes en un destinatario JMS y a su vez


los mensajes son consumidods por diferentes MDBs.

Configuración del pool para MDBs

Se puede gestionar el pool de MDB bien limitando el número de instancias o bien


definiendo un tamaño inicial del pool, tal como se muestra a continuación.

<weblogic-enterprise-bean>
<ejb-name>InsuranceQuoteBean</ejb-name>
<message-driven-descriptor>
<pool>
<max-beans-in-free-pool>15</max-beans-in-freepool>
<initial-beans-in-free-pool>5</initial-beans-infree-
pool>
</pool>
</message-driven-descriptor>
...
</weblogic-enterprise-bean>

Stateful Session Beans

Los Stateful session beans son muy similares a los stateless session beans, hasta tal
punto que se implementan exactamente de la misma manera.

Sin embargo, los beans stateful session se ocupan de mantener el estado del cliente a
través de múltiples llamadas, al almacenando las propiedades de estado en los
atributos del propio componente. Un contenedor EJB es el responsible de, en
subsecuentes llamadas, enrutar la petición al mismo bean stateful que almacena su
información de estado.

Gestión del pool

Weblogic Server permite controlar cuantas instancias de stateful session EJB puede
haber en memoria por cada tipo de EJB en un instante de tiempo, estableciendo
umbrales por tipo de EJB.

No se puede fijar ningún umbral que aplique a un grupo de tipos de EJBs juntos.
Además, sólo se puede controlar el número de EJBs que se permiten en cache—no

Pág. 32 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

hay mecanismos para controlar la cache, por ejemplo, por la cantidad de memoria
ocupada por la suma de las instancias.

Con este nivel de gestión de caché, hay que contestar a estas preguntas:

• ¿Cómo de grande se quiere la caché?


• ¿Qué ocurre con los EJB cuando la caché se llena?

El gráfico muestra que el servidor de aplicaciones alojará los stateful session beans
hasta el número especificado en la opción max-beans-in-cache.

WebLogic Server usa una caché de instancias para mejorar el rendimiento de los
EJBs stateful session. El mecanismo de cache almacena instancias activas de EJBs en
memoria para que estén disponibles inmediatamente para las peticiones de los
clientes.

El gráfico siguiente se muestra el cache de WebLogic Server y los procesos en los


cuáles los EJBs stateful entran en la caché y/o la dejan. Es importante destacar, que
no existen instancias de stateful session EJB en WebLogic Server en tiempo de
arranque.

Antes de que un cliente empiece a acceder a un bean stateful session, crea una nueva
instancia de bean para usar durante su sesión con el bean. Mientras la sesión está
activa, la instancia se cachea en memoria y cuando la sesión se acaba, la instancia se
destruye.

El proceso de activación o Activation es la transferencia de una instancia EJB de


almacenamiento secundario a memoria, así como passivation es la transferencia de
una instancia EJB de memoria a almacenamiento secundario.

Ajustando max-beans-in-cache a un valor muy alto, se consume mucha memoria de


forma innecesariamente. El contenedor EJB realiza una passivation cuando la caché

Pág. 33 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

se llena y cuando el objeto de sesión EJB se necesita de nuevo, el bean se activa


mediante un contenedor.

¿Qué pasa cuando la cache se llena?

Weblogic Server ofrece dos opciones ante esta situación con el fin de liberar memoría
en la caché:

Destruir EJBs que hace tiempo que no se usan.


Aplicar el mecanismo de Passivatization a EJBs en concreto.

Ambas acciones tienen como efecto la reducción del número de EJBs que están
consumiendo parte de la caché de forma que un slot quede disponible para otro EJB.

Configuración del tamaño de la cache

Determinar el tamaño apropiado de caché para el conjunto de beans de tipo stateful


session requiere un trabajo de análisis y un amplio conocimiento del aplicativo.

El tamaño de la caché debe depender de la cantidad de memoria disponible para el


consumo de EJBs. Y hay que tener en cuanta que cuando todos los EJBs están activos
simultáneamente en el sistema, su consumo total de memoria nunca debe exceder la
cantidad disponible en el heap de la JVM.

Para ello, hay que calcular el tamaño aproximado de cada tipo EJB, el número de
tipos EJB desplegados en un sistema y la cantidad total en el heap. A esta cantidad
se le debe sumar coste adicional y fijo de entre dos o tres MB de RAM para
administración.

Finalmente, hay que considerar la opción del clustering como solución de cache
remota, ya que la replicación de EJBs se encargará de usar el espacio libre de otros
servidores.

Idle Timeout and Eligibility

WLS hace barridos constantes de caché porque intentan optimizar el rendimiento, de


forma que asegure que la cantidad de caché tomada por los EJBs se encuentra en un
nivel apropiado por lo que es importante el rendimiento general del sistema que esta
operación sea eficiente en el servidor.

Si un EJB excede su valor <idle-timeout-seconds> especificado en el archivo META-


INF\weblogic-ejb-jar.xml file, puede ser destruído por Weblogic Server.

Pero debemos tener en cuenta que un EJB es elegible para passivation si no ha


excedido su valor de <idle-timeout-seconds>, no está participando en una
transacción, y no se encuentra ejecutando un método.

Por tanto, sólo ciertos tipos de EJBs son elegibles para el proceso de passivation.

Pág. 34 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Políticas para la gestión de la cache

Cuando se activa la política LRU para la gestión de la cache, el contenedor realiza las
siguientes operaciones:

• Envía instancias a disco, tan pronto como una instancia se vuelve inactiva por
idle-timeout-seconds, independientemente del valor de max-beans-in-cache.
También realiza esta operación si se alcanza max-beans-in-cache, aunque idle-
timeout-seconds no haya expirado

• Elimina una instancia en modo passivated de disco después de que se vuelva


inactiva por idle-timeout-seconds después de la passivation. Esto se le denomina
eliminación perezosa o lazy remove.

• Elimina una instancia de la caché cuando idle-timeout-seconds expira y no se


pasa a disco. A esto se le denomina eager remove. Un eager remove asegura que
una instancia inactiva no consume memoria o recursos de disco.

• Manda instancias a disco cuando se alcanza max-beans-in-cache, aunque idle-


timeout-seconds no haya expirado.

Configuración de la cache para EJB stateful session

No hay instancias de EJBs de tipo stateful session en tiempo de arranque de


Weblogic Server. Cuando los clientes buscan y obtienen referencias a beans
individuales, Weblogic Server inicializa nuevas instancias de la clase EJB y las
almacena en caché.

Si se alcanza max-beans-in-cache y hay EJBs en caché que no se están usando,


Weblogic Server provoca que se pase a pasivo algunos de esos beans aunque no
hayan alcanzado su límite idle-timeout-seconds.

Cuando un EJB se convierte en elegible para el proceso de passivation, no significa


que Weblogic Server provoca que se arranque el proceso de passivation para el bean
immediatamente.

El proceso de passivation se produce sólo cuando el EJB es elegible para ello y hay
presión por falta de recursos en el servidor, o bien Weblogic Server lleva a cabo un
mantenimiento regular de caché.

Se puede especificar ese mecanismo de forma explícita para EJBs que hayan
alcanzado idle-timeout-seconds modificando el elemento cache-type del archivo
weblogic-ejb-jar.xml.

• Especificar LRU como política, si se requiere una proceso de passivation más


agresiva de EJBs.
• Especificar NRU cuando haya presión de memoria en caché y se quieran
mantener en memoria los beans que el cliente utilice más frecuentemente.

Cuando escasean los recursos y la caché necesita memoria, Weblogic Server examina
los EJBs que están acercándose a su límite de max-beans-in-cache. De esos beans,

Pág. 35 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Weblogic Server elimina las instancias EJBs que no hayan sido usadas durante idle-
timeout-seconds de la caché, en lugar de moverlos a disco.

Una vez que una instancia de un EJB stateful session pasa a disco, un cliente tiene
idle-timeout-seconds para utilizar la instancia EJB. Pasado este tiempo, WLS lo
elimina de disco.

Alternativamente, se puede ajustar el valor de los descriptores maxbeans- in-cache y


el idle-timeout-seconds de un EJB de tipo stateful sesión, tal como se muestra a
continuación:

* @ejbgen:session max-beans-in-cache="1000" idle-


timeoutseconds="60"
* ejb-name = "ShoppingCartBean"

<weblogic-enterprise-bean>
<ejb-name>ShoppingCartBean</ejb-name>
<stateful-session-descriptor>
<stateful-session-cache>
<max-beans-in-cache>1000</max-beans-in-cache>
<idle-timeout-seconds>60</idle-timeout-
seconds>
</stateful-session-cache>
</stateful-session-descriptor>
...
</weblogic-enterprise-bean>

Beans de entidad (Entity beans)

Cuando decimos que un EJB es persistente, nos referimos a que los datos del EJB
persistirán o existirán esté o no el EJB en memoria. La persistencia de un EJB puede
ser implementada de varias formas. Por ejemplo, el objeto puede ser almacenado en
una base de datos relacional, en un archivo o colocado en otro medio.

Cuando se crea un entity EJB, el dato que representa el EJB se coloca en un


almacenamiento persistente, por ejemplo, con un insert en una base de datos, y una
copia del dato se almacena en memoria como parte del EJB ó como una agregación
de objetos que gestiona el EJB.

Cada vez que los atributos de los objetos en memoria se modifican, sus homólogos
persistentes se actualizan automáticamente. Ya que el valor del EJB se almacena de
manera persistente, múltiples clientes pueden acceder a los mismos datos en el
mismo instanta. Los contenedores pueden implementar dos peticiones de acceso por
parte de los clientes al mismo dato de distintas formas.

Por ejemplo, el contenedor puede serializar el acceso a los datos a través de un single
object, permitiendo sólo a un single client el uso del objeto al mismo tiempo, o puede
crear dos copias del dato persistente donde el contenedor sería responsable de
coordinar modificaciones concurrentes de los datos.

Dos clientes que usan la misma entidad EJB no es lo mismo que dos clientes que
usan el mismo session EJB. De hecho, dos clientes que usan el mismo entity EJB
significa que ambos tienen acceso a los mismos datos persistentes. El contenedor
puede crear una instancia o múltiples para gestionar cómo múltiples clientes

Pág. 36 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

“comparten” los mismos datos. Este es un concepto un poco complicado que


Weblogic Server aplica de múltiples formas.

Configuración de la cache y el pool para EJB de tipo Entity

Definir los tags en el archivo weblogic-ejb-jar.xml para un entity bean es muy similar
a como se hace con el resto de tipos de beans.

Se debe incluir un tag <entity-cache> para albergar un tag <max-beans-in-cache>, ya


que tiene el mismo significado que en los stateful session bean, controla el número
de beans en el pool que se permiten en memoria al mismo tiempo. El tag <pool> es
igual que en los stateless session beans, tal como se muestr a continuación:

<weblogic-enterprise-bean>
<ejb-name>OrderBean</ejb-name>
<entity-descriptor>
<pool>
<max-beans-in-free-pool>15</max-beans-in-freepool>
<initial-beans-in-free-pool>5</initial-beans-infree-
pool>
</pool>
<entity-cache>
<max-beans-in-cache>1000</max-beans-in-cache>
<idle-timeout-seconds>60</idle-timeout-seconds>
</entity-cache>

Caches combinadas para EJBs Entity

El cacheo a nivel de aplicaciones tiene las siguientes ventajas:

• Reduce el número de cacheos de entity bean y por tanto el esfuerzo de


configurar la caché.

• Hace un mejor uso de la memoria y heap space de la JVM al reducir la


fragmentación. Por ejemplo, si un EJB en particular, experimenta un pico de
actividad, puede usar toda la memoria disponible de caché, mientras que se
paginan otros EJBs. Si dos EJBs usan cachés diferentes, cuando una caché se
llene, el contenedor no puede paginar EJBs en el caché del otro bean, y el
resultado es un gasto de memoria.

• Proporciona una mejor escalabilidad.

Para usarla, necesitamos definir una entidad de caché de nivel de aplicación que se
define en el fichero weblogic-application.xml:

<weblogic-application>
<ejb>
<entity-cache>
<entity-cache-name>appLevelCache1</entity-cache-
name>
<max-beans-in-cache>1000</max-beans-in-cache>
<caching-strategy>MultiVersion</caching-strategy>
</entity-cache>
...

Pág. 37 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Además de una referencia a una entidad de caché de nivel de aplicación definida en


el fichero weblogic-ejb-jar.xml:

<weblogic-enterprise-bean>
<ejb-name>CorporateAddressRO</ejb-name>
<entity-descriptor>
<entity-cache-ref>
<entity-cache-name>appLevelCache1</entity-cache-
name>
<read-timeout-seconds>600</read-timeout-seconds>
<cache-between-transactions>true</cache-between-
transactions>
<concurrency-strategy>ReadOnly</concurrency-
strategy>
<estimated-bean-size>20</estimated-bean-size>
</entity-cache-ref>
...

Cada valor del elemento <entity-cache-name> en weblogic-ejb-jar.xml debe coincidir


con el valor de un elemento <entity-cache-name> en weblogic-application.xml.

Cache y transacciones

Si hacemos un llamada del contenedor para invocar al método ejbLoad() por cada
transacción simple, podemos encontrarnos con un problema de lentitud en el
procesamiento de éstas.

Aunque esta técnica se realiza para prevenir problemas de sincronización, En


algunos casos, es posible cambiar este comportamiento para optimizar el
procesamiento.

Para hacerlo, hay que poner el tag <cache-between-transactions> en el archivo


weblogic-ejb-jar.xml.

Es importante destacar que si más de un cliente está accediendo a los datos al mismo
tiempo, puede haber pérdida de datos con se usa esta técnica y además no estará
disponible en entornos basados en clústeres.

Veamos el gráfico anterior:

Pág. 38 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

1. Un cliente llama a un método que genera una transacción.


2. Comienza una transacción.
3. Si cache-between-transactions es false, la llamada del contenedor ejbLoad() antes
de ejecutar el método, de lo contrario el método se ejecuta.
4. Cuando la transacción se confirma, commit, se produce la llamada a ejbStore().

<weblogic-enterprise-bean>
<ejb-name>AccountEJB</ejb-name>
<entity-descriptor>
<entity-cache>
<max-beans-in-cache>1000</max-beans-in-cache>
<cache-between-transactions>True
</cache-between-transactions>
</entity-cache>
<persistence></persistence>
</entity-descriptor>
<jndi-name>AccountEJB</jndi-name>
</weblogic-enterprise-bean>

Estrategias de concurrencia para Entity Beans

Dado que múltiples clientes pueden acceder a un mismo entity bean de forma
concurrente, los servidores EJB deben dar soporte a niveles de concurrencia.

Weblogic Server soporta cuatro estrategias de concurrencia:

Exclusive
Database, por defecto
ReadOnly
Optimistic

En momento que se tiene un servidor donde más de una hebra puede acceder a un
recurso protegido, como datos, el servidor necesita soporte a niveles de concurrencia
para proteger los recursos y a los clientes que acceden a los mismos.

En este caso de entity beans, los recursos serán típicamente datos. Se puede dar una
situación en que más de un cliente esté accediendo a la misma primary key a través
del entity bean, y por tanto al mismo dato. Es lo que se llama un „dirty read.‟

Finalmente, recordar que la elección de la estrategia adecuada para una aplicación


puede mejorar el rendimiento.

Estrategias de concurrencia

• Exclusive
Establece un bloqueo exclusivo en instancias cacheadas de entity EJB cuando el
bean está asocidado a una transacción.
Bloqueaa otras peticiones para la instancia EJB hasta que la transacción se
completa.

• Database
Aplaza el bloqueo de peticiones para un entity para la base de datos.
Distribuye una instancia separada de entity bean y permitir a la base de datos
manejar el bloqueo y el cacheo.

Pág. 39 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

• ReadOnly
Activa un nueva instancia para cada transacción, así las peticiones se procesan
de forma paralela para los entity beans.
Configura Weblogic Server para comprobar mediante un timeout de lectura y
si los datos de caché son más antiguaos
Invalida los read-only beans cuando se llama al método invalidate() y envia un
mensaje multicast a través del cluster para invalidar las copias cacheadas en el
resto de nodos.

• Optimistic
Los bloqueos no se mantienen en el contenedor EJB ni en la base de datos
durante una transacción.

El contenedor EJB verifica que no ha cambiado ningún dato actualizado por la


transacción antes de la confirmación de la misma, commit, y el contenedor EJB
deshace la transacción si se produjo algún cambio.

La estrategia de concurrencia “exclusive” era la que estaba por defecto en WebLogic


Server en versiones anteriores como, 4.5.1 y 5.1. Y permitía un acceso fiable a datos
EJB y evita llamadas innecesarios a ejbLoad() para refrescar los campos persistentes
de la instancia EJB.

Sin embargo, el bloqueo exclusivo no proporciona el mejor modelo para acceso


concurrente a datos por parte de los EJBs. Una vez que un cliente ha bloqueado una
instancia EJB, otros clientes se bloquean si intentan acceder a los campos
persistentes.

El contenedor EJB en WebLogic Server puede usar el mecanismo de bloqueo


exclusivo para instancias de entity EJB. Cuando los clientes seleccionan un EJB o un
método EJB en una transacción, WebLogic Server bloquea la instancia EJB durante la
transacción. Otros clientes que soliciten el mismo EJB o método se bloquearán hasta
que se complete la transacción actual.

La estrategia de concurrencia “Database” es la estrategia de concurrencia por


defecto. Con el mecanismo de bloqueo de base de datos, el contenedor EJB puede
continuar cacheando instancias de clases de entity EJB. Sin embargo, el contenedor
no cachea el estado intermedio de una instancia EJB entre transacciones. En su lugar,
WebLogic Server llama a ejbLoad() para cada instancia al principio de una
transacción para obtener los últimos datos de EJB. La petición para confirmar los
daots se pasa posteriormente a la base de datos. Y por tanto, ésta maneja toda la
gestión de bloqueos y la detección de deadlock para los datos de EJBs.

Pág. 40 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Se puede especificar cacheo de read-only entity bean a nivel de aplicación o de


componente. Para habilitar el cacheo de read-only en entity bean es necesario:

• Especificar la opción ReadOnly en la opción del descriptor de despliegue


concurrency-strategy para cada archivo JAR ó EAR.
• Especificar el elemento concurrency-strategy para cachés de nivel de
aplicaciones (EARS) en el archivo weblogic-application.xml.
• Especificar el elemento concurrency-strategy para cachés de nivel de
componente (JARS) en el archivo weblogic-ejb-jar.xml.
• Invalidar un read-only entity bean mediante la llamada al método invalidate()
de la interfaz CachingHome ó CachingLocalHome:

public interface CachingHome {


public void invalidate(Object pk) throws
RemoteException;
public void invalidate (Collection pks) throws
RemoteException;
public void invalidateAll() throws RemoteException;
}
Cuando se llama al método invalidate(), los read-only entity beans se invalidan en el
servidor local, y se envía un mensaje multicast al resto de servidores del cluster para
invalidar sus copias en caché. La siguiente llamada a un read-only de tipo entity
bean invalidado causa una llamada a ejbLoad().

Finalmente, la estrategia de concurrencia “Optimistic” no mantiene ningún bloqueo


en el contenedor EJB ni la base de datos mientras la transacción está en proceso.
Cuando se especifica esta opción, el contenedor EJB se asegura que los datos que se
actualizan con la transacción no han cambiado. Realiza un “smart update”
comprobando los campos antes del commit de la transacción.

<weblogic-enterprise-bean>
<ejb-name>PurchaseOrderBean</ejb-name>
<entity-descriptor>
<entity-cache>
<concurrency-strategy>
Exclusive | Database | | Optimistic | ReadOnly
</concurrency-strategy>
</entity-cache>
</entity-descriptor>
</weblogic-enterprise-bean>

Entity Bean Bulk Updates

Existen situaciones donde múltiples instancias del mismo bean de entidad de tipo
CMP cambian en una misma transacción. Si el contenedor EJB ejecuta sentencias
SQL/DML para todas las instancias de beans CMP, las actualizaciones pueden
convertirse en un cuello de botella en cuestiones de rendimiento.

Las operaciones por lotes o en batch en actualizaciones de EJBs solucionan este


problema mediante la actualización de múltiples entradas en una tabla de la base de
datos en un batch de sentencias SQL/DML. Con ello se mejora el rendimiento
haciendo múltiples inserts, deletes o updates para los beans CMP en un envío a la
base de datos.

Pág. 41 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Para permitir inserts, updates o deletes en modo batch en una base de datos, es
necesario habilitar el elemento enable-batch-operations del archivo weblogic-cmp-
jar.xml poniendolo al valor true tal como se muestra a continuación:

<weblogic-rdbms-jar>
<enable-batch-operations>
True
</enable-batch-operations>
</weblogic-rdbms-jar>

Directiva include-updates

De acuerdo con la especificación EJB, las actualizaciones hechas por una transacción
deben ser reflejadas en los resultados de los query-finders y ejbSelects emitidos
durante la transacción.

Este requerimiento puede disminuir el rendimiento ya que realmente se procede a


limpiar el caché antes de ejecutar la query. Para ello es necesario cambiar el valor del
elemento include-updates de true a false en el archivo weblogic-cmp-jar.xml.

La decisión de deshabilitar cache flushing depende de si el rendimiento es más


importante que ver la mayor cantidad de datos. Poniendo include-updates a False
obtenemos el mejor rendimiento pero las actualizaciones de la transacción actual no
se reflejan en la query.

<weblogic-rdbms-jar>
<weblogic-query>
<query-method>
<method-name>findGoldCustomer</method-name>
<method-params>...</method-params>
</query-method>
<ejb-ql-query>...</ejb-ql-query>
<include-updates>True</include-updates>
</weblogic-query>
</weblogic-rdbms-jar>

Cacheo de relaciones (relationship caching)


El cacheo de relaciones o relationship caching mejora el rendimiento de los beans de
tipo entidad al cargar en caché los beans relacionados con el primero, evitando así
realizar múltiples consultas utilizando una join query para los mismos.

Veamos algunas características:

• En entity relationships, se usan múltiples queries para cargar entity beans


relacionados.

• El rendimiento se puede mejorar cargando todos los beans relacionados en


caché

• Esto se puede conseguir activando relationship caching en weblogic-cmp-


jar.xml.

• Relationship caching usa joins multinivel para cargar múltiples beans usando
una sentencia SQL.

Pág. 42 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Configuración del cacheo de relaciones

Veamos un ejemplo de configuración del cacheo de relaciones:

<weblogic-cmp-jar>

<relationship-caching>
<caching-name>cacheMoreBeans</caching-name>
<caching-element>
<cmr-field>accounts</cmr-field>
<group-name>acct_group</group-name>
<caching-element>
<cmr-field>address</cmr-field>
<group-name>addr_group</group-name>
</caching-element>
</caching-element>
<caching-element>
<cmr-field>phone</cmr-field>
<group-name>phone_group</group-name>
</caching-element>
</relationship-caching>

</weblogic-cmp-jar>

No hay limitación en el número de caching-elements a especificar. Sin embargo, si se


disponen muchos niveles, se podría obtener un impacto negativo en el rendimiento
de la transacción.

Campos de grupos

Un grupo especifica un conjunto de atributos persistentes de un bean de entidad. Un


campo de grupo o field-group representa un subconjunto de los campos CMP y
CMR de un bean.

Se pueden poner campos relacionados en un bean en grupos que van en memoria


como una unidad. Igualemnte, se puede asociar un grupo con una query o relación,
de forma que cuando se carga un bean como resultado de ejecutar una query o fruto
de una relación, sólo se cargan los campos mencionados en el grupo.

<weblogic-rdbms-bean>
<ejb-name>MedicalBean</ejb-name>
<field-group>
<group-name>medical-data</group-name>
<cmp-field>insurance</cmp-field>
<cmr-field>doctors</cmr-fields>
</field-group>
</weblogic-rdbms-bean>

El mecanismo de eager loading es una forma de especificar qué datos se cargan y si


se cachean en la duración de una transacción. Si un método de tipo finder se usa en
una transacción, y en una transaction posterior el bean devuelto por el método
finder vuelve a ser accedido, usando por ejemplo un método get, el campo accedido
se carga de nuevo, ya que los datos podrían haber cambiado.

Pág. 43 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Si está habilitado el cacheo entre transacciones, entonces se usará el mecanismo


eager loading la primera vez para cachear los datos, pero posteriormente se usarán
los datos almacenados en caché. Hay que verificar que finders-load-bean es true, o
bien no indicarlo. Cuando está a false, los query methods cargarán siempre los
valores de las primary keys del bean devuelto por la query.

Container-Managed Transactions (CMT)

Una forma de usar transacciones en EJBs es delegando al contenedor todo el manejo


de éstas. A esto se le conoce como container-managed transactions ó CMT.

Con CMT, se puede deciridr qué métodos deben tener una transacción activa
durante su ejecución y el contenedor comenzará la transacción antes de llamar al
método y hacer commit o rollback de la transacción una vez completado el método.

El gráfico muestra el proceso:


• El cliente hace la invocación.
• El contenedor empieza la transacción como parte del proceso de pre-invocación.
• Se invoca el bean.
• Se hace rollback o commit de la transacción como parte del proceso de post-
invocación.

Tag <container-transaction>

Cuando se indica el tag <transaction-type> como container, el tag <container-


transaction> se usa para indicar el tipo de comportamiento de la transacción que
debe existir para los diferentes métodos del bean.

Este tag contiene, a su vez, los tags <method> y <trans-attribute>. El primero indica
el comportamiento que debe adoptar el contenedor cuando se llama a estos métodos.
El segundo especifica uno o más métodos de un EJB.

...</enterprise-beans>
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>JspSession</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
... </assembly-descriptor>

Una revisión rápida de la sintaxis del tag <method>:

Pág. 44 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

<ejb-name>
o Especifica el nombre del EJB que aloja el método.

<method-intf>
o Es opcional y especifica la interfaz donde se ubican los métodos. El valor
puede ser Home, Remote, Local ó LocalHome. Si se omite, los métodos
de todas las interfaces deben especificarse.

<method-name>
o Es el nombre de un método o *, que indica todos los métodos.

<method-params>
o Es opcional y contiene una lista de tags <method-param>. Si múltiples
métodos tienen el mismo nombre con diferentes parámetros, se puede
especificar el prototipo del método.
o No se puede usar con *.

Valores para el tag <trans-attribute>

El tag <trans-attribute> puede tener uno de estos seis valores:

Never: Especifica que el EJB no puede ser invocado en el contexto de una


transacción.

NotSupported: Provoca que las transacciones se suspendan durante la ejecución


de EJBs.

Supports: Implica que el EJB se incluirá en cualquier transacción iniciada por el


cliente.

Required: Fuerza al EJB a ejecutarse en una transacción iniciada por el cliente o


el contenedor.

RequiresNew: Fuerza al EJB a ejecutarse en una nueva transacción iniciada por


el contenedor.

Mandatory: Obliga al cliente a pasar una transacción global al EJB.

Cada valor indica el comportamiento que el contenedor debe adoptar cuando los
métodos que generan, o estén expuestos a, transacciones son invocados. Cada
atributo indica qué hacer con una transacción iniciada por un cliente y si debe
iniciarse una nueva transacción.

Estos seis atributos de transacción generan un gran número de escenarios posibles.


Hay que tener en cuenta que un EJB puede ser cliente de otro EJB, lo cual multiplica
las posibilidades.

Nivel de aislamiento

Es posible ajustar el nivel de asilamiento con el tag <transaction-isolation>. Este tag


contiene dos cosas: el nivel de aislamiento y los métodos que aplican en este nivel.
Este tag puede repetirse tantas veces como sea necesario.

Pág. 45 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Los cuatro niveles de aislamiento disponibles son:

• TRANSACTION_READ_UNCOMMITTED: Operaciones dirty reads, non-


repeatable reads, y phantom reads están permitidas. Este es el nivel de
aislamiento más permisivo.
• TRANSACTION_READ_COMMITTED: No se permiten dirty reads. Sí se
permiten non-repeatable reads y phantom reads.
• TRANSACTION_REPEATABLE_READ: No se permiten dirty reads ni non-
repeatable reads. Si se permiten phantom reads.
• TRANSACTION_SERIALIZABLE: No se permiten dirty reads, non-repeatable
reads o phantom reads. Este es el nivel de aislamiento más restrictivo.

<weblogic-ejb-jar>

<transaction-isolation>
<isolationlevel>
TRANSACTION_READ_UNCOMMITTED</isolation-level>
<method> <ejb-name>dogEJB</ejb-name>
<method-name>*</method-name> </method>
</transaction-isolation>

</weblogic-ejb-jar>

Consideraciones de diseño

• La configuración de las transacciones pueden tener un gran impacto en el


rendimiento.
• Muchas transacciones muy atómicas generan un tráfico excesivo de
transacciones y pueden provocar la satuación de los resource managers.
• Transacciones que actualizan mutitud de registros pueden bloquear a otros
clientes accediendo a los mismos recursos.
• Como buena práctica, puede tratarse de crear un bean de sesión que a través del
patrón fachada o facade envuelva o agrupe múltiples invocaciones a métodos
EJB para eliminar la acreación de múltiples transacciones.

Todas las consideraciones de diseño están orientadas a la reducción del número de


transacciones y asegurar que el alcance de cada transacción es a través de la menor
cantidad de recursos posibles.

Finalmente, es importante asegurarse de limitar las transacciones, por ejemplo, en


una petición Web, y no permitir que que las transacciones abarquen peticiones que
tengan relación con el control o el flujo Web.

Timeout de transacciones

Veamos ahora las características del mecanismo de timeout dentro del control
transaccional:

• Evitan que los recursos permanezcan innecesariamente ocupados por períodos


largos, asegurando que la transacción nunca incluye la entrada de usuario.

• Aseguran que las transacciones provocan bloqueos de filas en la base de datos del
menor tiempo posible.

Pág. 46 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Para configurar el timeout de transacción es necesario modificar el fichero weblogic-


ejb-jar.xml, tal como se muestra a continuación:

<weblogic-enterprise-bean>
<transaction-descriptor>
<trans-timeout-seconds>20</trans-timeout-
seconds>
</transaction-descriptor >
</weblogic-enterprise-bean>

Pág. 47 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Best Pratices para clustering

El Clustering es un grupo de WebLogic Servers que actúan de manera coordinada


para proporcionar a los clientes un acceso a los servicios que ofrecen los servidores
que forman el cluster. Los servicios que proporciona un cluster pueden ser un super
conjunto de los servicios que proporciona uno de los servidores del cluster.

Sin embargo, es una buena práctica que todos los servidores que pertenecen a un
mismo cluster den los mismos servicios. De cara al cliente, el cluster aparece como
una única instancia, ya sea el cliente un cliente Web ó una aplicación Java. Al
replicar los servicios proporcionados por un servidor, este tipo de arquitecturas
construyen sistemas escalables y con tolerancia a fallos.

La alta disponibilidad se consigue mediante la replicación de los servicios, así


cuando un servicio falla, un segundo servicio puede reanudar por donde se quedó el
primero. La escalabilidad se consigue mediante el balanceo de las peticiones que
llegan a todos los servidores del cluster. Por ejemplo, si hay cuatro servidores en un
cluster y cuatro peticiones, se pueden balancear las peticiones de forma que cada
servidor reciba una de ellas.

Un cluster estára formado por diversos servidores de un mismo dominio, aunque no


es obligatorio que todos los servidores pertenezcan a una cluster. Por regla general,
éstos están precedidos de frontales, bien balanceadores bien servidores proxy, que se
encargan de dirigir la carga de las peticiones a todos los elementos del clúster como
un todo, y en ocasiones limitando el acceso de forma directa a un componente en
concreto.

Balanceo de carg y failover

Balanceo de carga

Para conseguir una buena escalabilidad, cada servidor de un cluster debe usarse de
forma que se maximice su capacidad de uso. Dicho de otra manera, que sea usado
de forma completamente y de forma independiente y transparente al número de
componentes que lo formen. A este conjunto de técnicas se recogen bajo el balanceo
de carga.

El desafío de implementar el balanceo de carga es balancear de una forma simple y


efectiva. Si todos los servidores del cluster tienen recursos equivalentes y ofrecen los
mismos servicios, un algoritmo simple de balanceo de carga que no requiere
conocimiento de los servidores valdrá.

Si por el contrario, los servidores varían en potencia o en el tipo de servicios, hay que
especificar un algoritmo que tenga en cuenta estas diferencias.

El proxy plug-in de Weblogic Server mantiene una lista de instancias WebLogic


Server que alojan un elemento clusterizado, como un servlet o un JSP, y reenvía
peticiones HTTP a esas instancias utilizando la estrategia round-robin.

Pág. 48 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Los clusters que usan un balanceo de carga hardware pueden usar cualquier
algoritmo de balanceo de carga soportado por el hardware.
Failover

Las instancias WebLogic Server son capaces de detectan fallos en el resto de los
miembros del clúster gracias a una monitorización activa de cada uno de los
elementos que lo forman.

Como ejemplo de esta monitorización, podemos comentar la monitorización de las


conexiones a través de sockets entre los elementos del cluster. Si un servidor se
conecta a uno de sus iguales en el clúster y comienza a transmitir datos a través de
un socket, un cierre inesperado de éste puede causar que dicho servidor quede
marcado en estado FAILED y sus servicios asociados se eliminen del árbol JNDI del
clúster.

Arquitectura básica de un clúster

La arquitectura básica recomendada de un cluster de Weblogic Server combina


todos los niveles de las aplicaciones web, es decir, HTTP estático, capa de
presentación y capa de negocio, en un mismo clúster.

La arquitectura básica tiene algunas ventajas claras:

Fácil administración, ya que un clúster simple al alojar todos los elementos,


páginas HTTP estáticas, servlets y EJBs, se pueden configurar, desplegar y/o
eliminar objetos y aplicaciones web de forma atómica, usando, por ejemplo, la
consola de administración.

Balanceo de carga flexible, el uso de balanceo de carga hardware en un cluster


WebLogic Server permite el uso de políticas avanzadas de balanceo de carga
para el acceso a contenido tanto dinámico como estático.

Seguridad robusta, ya que al poner un firewall en el hardware de balanceo de


carga, permite crear una “zona desmilitarizada” o DMZ para las aplicaciones
web con un mínimo de políticas de seguridad respesto a los firewalls.

Mediante una arquitectura de niveles combinada como la recomendada, se


satisfacen las necesidades de la gran mayoría de aplicaciones web.

Arquictura multi capa de un clúster

La arquitectura multi capa o multi-tier recomendienda el uso de almenos dos


clusters de WebLogic Server separados. El primero de ellos, para servir contenido
estático y dinámico HTTP y el segundo para servir objetos de tipo EJBs en clúster.

La arquitectura multi capa proporciona las siguientes ventajas:

Balanceo de carga en métodos EJBs, ya que mediante el alojo de servlets y EJBs


en clusters separados, las llamadas a métodos desde los servlets a los EJBs se
pueden balancear en múltiples servidores.

Pág. 49 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Mejor balanceo de carga en el servidor, ya que al separar los niveles de


presentación y de negocio, donde residen los objetos en cluster, se proporciona
más opciones para distribuir la carga de las aplicaciones. Por ejemplo, si la
aplicación accede a contenido HTTP y servlets más frecuentemente que a
contenido servido a través de EJBs, se pueden usar una mayor cantidad de
instancias de WebLogic Server en el nivel de presentación del cluster
minimizando el número de servidores que alojan los EJBs.

Disponibilidad más alta, ya que mediante el uso de instanicas de WebLogic


Server adicionales, la arquitectura multi capa tiene menos puntos de fallo que la
arquitectura anterior. Por ejemplo, si un Weblogic Server que alberga un EJB en
clúster falla, la capa de presentación podrá reencaminar la petición a otro
miembro del cluster, y por tanto continuar de forma transparente.

Mayor seguridad, ya que al separar las capas de presentación y negocio en dos


clústeres independientes, se pueden establecer políticas de seguridad y de
firewalling para cada una de las dos zonas, creando un DMZ en la zona de
presentación y una zona segura en la capa de negocio.

Clustering para entornos Metropolitan Area Network (MAN)

Los recursos en las redes de tipo MAN suelen esta en diferentes localización, pero lo
suficientemente cerca como para que la latencia de este tipo de redes sea un
problema a tener en cuenta.

Este tipo de redes suelen proveer servicios de alta velocidad y baja latencia, por lo
que los clústeres de Weblogic Server se pueden instalar sin mayores problemas en
este tipo de redes.

Para mejorar el failover de Weblogic Server en redes MAN, éste permite un


mecanismo basado en memoria capaz de trabajar con dos clúster distantes. Esto es
posible gracias a la replicación síncrona de un clúster a otro soportando por la baja
latencia de la red. Este factor debe comprobarse y asegurarse, ya que es clave en el
correcto funcionamiento del sistema.

Balanceadores de carga

Básicamente existen de dos tipos, hardware como los fabricados por Cisco, Foundry
Networks yBig IP, y los software, como Apache, Netscape, MS IIS o WebLogic
Server a través de proxy plug-ins.

Consideración para balanceadores de carga por hardware

A continuación se enumeran algunas consideraciones a tener en cuenta durante la


configuración de Weblogic Server sobre balanceadores de carga hardware.

Passive cookie

El mecanismo de persistencia a través de passive cookie permite a Weblogic Server


crear una cookie que contiene un parámetro de sesión que a través del balanceador
de carga llega al cliente.

Pág. 50 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

En el caso de uso de balanceadores de tipo hardware es obligatorio la configuración


de este mecanismo para evitar que se sobreescriba dicha cookie que es usada por
Weblogic Server para comprobar y seguir la correspondencia de los servidores
primerio y secundario de la replicación en memoria.

Esta cookie posee el siguiente formato:

• Una cadena de texto con el valor de la session ID más un byte como carácter
delimitador.
• Una cadena de texto de una longitud de diez para almacenar la pareja de valores
de primario y secundario.

Active cookie

El mecanismo de persistencia basado en active cookies está soportado por Weblogic


Server siempre y cuando dicho mecanismo asegure que las cookies no serán
sobreescritas o modificadas. En es caso, no es necesario ninguna configuración extra
además de la indicada en el caso del mecanismo de pasive cookies.

Persistencia SSL

En el caso de SSL, es el balanceador el responsable de encriptar y desencriptar la


información que circula entre los clientes y el clúster a través de una cookie en texto
plano que mantiene la correspondencia entre el cliente y el servidor dentro del
clúster.

Replicación de sesión
Componentes Web como servlets o páginas JSP mantienen datos de clientes en
instancias del objeto HttpSession. Por tanto, si deseamos tener la capacidad de alta
disponibilidad, esta información tiene que ser compartida por todos los nodos del
clúster.

Para ello las instancias de HttpSession puede ser replicada a través de la replicación
en memoria o in-memory replication, persistencia en file system o persistencia en
base de datos

Replicación basada en memoría


En el caso de la replicación basada en memoría o in-memory replication, los objetos
replicados no son accesibles por la totalidad los servidores del cluster. Sin embargo,
cuando se crea un objeto, objeto primario, se crea una imagen de backup en otro
servidor del clúster, llamado objeto secundario. En el caso de perdida del primero, el
secundario es promocionado al primario para el resto de futuras peticiones. De la
misma forma, se busca un nuevo servidor, capaz de albergar al nuevo objeto
secundario que es creado a partir del nuevo primario.

De esta forma, se reduce los canals de comunicación necesarios para la replicación


de un objeto realizándose entre parejas de servidores y no a través del clúster
completo.

Pág. 51 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Persistencía basada en JDBC

En el caso de la replicación basada en persistencia JDBC, es necesaria una base de


datos que almacene la información de los objetos de tipo HttpSession.

Una vez configurado, cada una de los managed server que forman el cluster usarán
la misma configuración para crear el pool de conexiones que le permita acceder a la
información compartida por la base de datos.

En esta situación, si por ejemplo, un servlet crea un objeto de sesión, éste almacena la
información en la base de datos. Las siguientes peticiones del cliente, sea al miembro
del clúster que sea, podrán manejarse de igual forma, ya que todos tiene acceso a la
información almancenada.

Este mecanismo posee una mejor capacidad de failover dado que cualquier servidor
puede resolver y atender cualquier petición desde los clientes, pero por el contrario,
tiene una reducción significativa de rendimiento al tener que sincronizar cualquier
cambio con la base de datos.

Persistencía basada en file system compartido

Finalmente, la persistencia de sesión basada en file system parte de la capacidad de


éste de ser compartido a nivel de acceso por todos los miembros del clúster.

En esta caso, cuando un servlet crea un instancia de HttpSession, Weblogic Server


escribe los datos correspondientes en una datastore vinculado a un file system
compartido.

Al igual que en el caso anterior, posee buenas características de failover pero


también presenta problemas de rendimiento, especialmente en la sincronización de
las escrituras y lectura de todos los miembros del clúster.

Configuración de los tipos de replicación

Replicación de tipo In-memory:

<session-descriptor>
<persistent-store-type>replicated</persistent-store-type>
<session-descriptor>

<session-descriptor>
<persistent-store-type>replicated_if_clustered</persistent-
store-type>
<session-descriptor>

Replicación de tipo File System:

<session-descriptor>
<persistent-store-type>file</persistent-store-type>
<persistent-store-dir>Directory Path</persistent-store-dir>
<session-descriptor>

Pág. 52 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Replicación de tipo JDBC:

<session-descriptor>
<persistent-store-type>jdbc</persistent-store-type>
<persistent-store-pool>Data Source Name</persistent-store-
pool>
<session-descriptor>

Pág. 53 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Best practices para Work Managers

Weblogic Server usa un mecanismo de pool de hebras único que se adapta de


manera automática para maximizar la productividad del sistema. A este proceso se
le conoce como mecanismo de self-tuning.

En este proceso, los queue monitor evalúan la carga del sistema a través del tiempo y
así como información histórica para ajustar el valor del número de hebras necesario,
incrementando o decrementando según sea necesario de una forma totalmente
interna al pool de hebras.

Weblogic Server prioriza la carga de trabajo recibida basandose en las reglas


definidas por los adminsitradores y en base a sus métricas de rendimiento internas,
como el tiempo empleado en ejecutar una petición o el ratio de entrada y salida de
las petición al pool de hebras.

De esta forma se hace más sencillo para los administradores ajustar la cantidad de
recursos necesarios y se reduce, en general, las tareas de monitorización y ajuste de
colas configuradas por ellos.

Default Work Manager

Weblogic Server, por defecto, usa una única cola de ejecución basada en prioridades
donde todas las aplicaciones desplegadas tienen la misma prioridad de ejecución.

A este tipo de reparto de prioridades se le conoce como reparto equitativo o fair


share.

Este work manager por defecto, llamado default work manager, puede
reconfigurarse creando y configurando un work manager global también llamado
defualt. En él, el tamaño del pool de hebras puede ser configurado tanto es su límite
máximo como en su límite mínimo.

Clases de tipo Request

Los adminsitradores puede determiner una serie de guías y asociarla a una o más
aplicaciones o a un componente en particular. Weblogic Server usará estas guías
para realizar la asignación del trabajo pendiente.

Las clases de tipo Request permite planificar el trabajo en base a la prioridad. Hay
que tener en cuenta que básicamente existen dos componentes en un work manager:
las clases request y las restricciones (constraints). Pueden usarse cualquier de ellas
para controlar el rendimiento de una aplicación referenciando el nombre del
componente en descriptor de despliegue. O bien puede crear un work manager que
encapsule estos componentes y referenciar a éste también en el descriptor de
despliegue.

Pág. 54 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

Clases de tipo Fair Share Request

Tal como hemos comentando en los work managers configurados como fair share, la
gestión se basa en prioridades. Y aunque todas las aplicaciones tiene por defecto la
misma prioridad, ésta puede cambiarse de forma, que una aplicación con un valor
para fair share de 1000, será la que tenga la prioridad mas alta de todas las posibles.

Vemoas un ejemplo, asumimos que existen tres modulos en ejecución. El work


manager para el modulo A indicar una fair-share-request-class de 90, mientras que
el módulo B lo hace de 10. En caso de producirse la suficiente demanda sobre el
servidor que los conteniene a ambos, Weblogic Server repartirá los recursos en uso
en un 90 y un 10% respectivamente para los modulo A y B.

fair-share-request-class>
<name>high_priority</name>
<fair-share>90</fair-share>
</fair-share-request-class>

<fair-share-request-class>
<name>low_priority</name>
<fair-share>10</fair-share>
</fair-share-request-class>

Clases de tipo Response Time Request

Aunque el objetivo de tiempo de respuesta no se aplica a las peticiones de forma


individual, Weblogic Server reliza los cálculos necesarios para asegurar que el
tiempo de respuesta tolerable mediante la subtracción del tiempo empleado por la
hebra del tiepo total de respuesta. De esta forma, Weblogic Server planifica este tipo
de peticiones dentro de la media de espera por petición proporcional al tiempo de
espera indicado. Veamos un ejemplo, si Weblogic Server ejecuta dos módulos, A y B,
y deseamos un ratio de 1:8 entre ellas, usaremos la siguiente configuración:

<response-time-request-class>
<name>fast_response_time</name>
<goal-ms>1000</goal-ms>
</response-time-request-class>

<response-time-request-class>
<name>slow_response_time</name>
<goal-ms>8000</goal-ms>
</response-time-request-class>

Clases de tipo Context Request

Este tipo de clases permite asignar una clases de tipo de request en base a una valor
de la petición y/o a una propiedad de un role. Es decir, mapea el contenido con las
clase de tipo request que debe ejecutarse.

<context-request-class>

Pág. 55 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

<name>simple_context</name>
<context-case>
<user-name>system</user-name>
<request-class-name>high_fairshare</request-class-name>
</context-case>
<context-case>
<group-name>everyone</group-name>
<request-class-name>low_fairshare</request-class-name>
</context-case>
</context-request-class>

Resctricciones (Constraints)
Las restricciones definen:

El valor máximo y mínimo de hebras que se crear para ejecutar las peticiones.
El número total de peticiones que encoladas antes de que Weblogic Server
comience a rechazas peticiones.

Existen tres tipos de restricciones:

max-threads-constraint
min-threads-constraint
capacity

Resctricción Maximum Threads


Esta restricción limita el número máximo de hebras que concurrentemente ejecutan
este tipo de petición.

Las opciones de configuración son las siguientes:

Name: Nombre de la restricción.


Count: Número de hebras, por defecto -1.
Data Source: Opcionalmente, el nombre de la connection pool de donde se
tomará el valor máximo.

<max-threads-constraint>
<name>max_threads</name>
<count>10</count>
<connection-pool-name></connection-pool-name>
</max-threads-constraint>

Resctricción Minimum Threads

Esta restricción limita el número mínimo de hebras que concurrentemente ejecutan


este tipo de petición.

Las opciones de configuración son las siguientes:

Name: Nombre de la restricción.


Count: Número de hebras, por defecto -1.

Pág. 56 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

<min-threads-constraint>
<name>min_threads</name>
<count>1</count>
</min-threads-constraint>

Resctricción Capacity

Este tipo de restricción permite que el servidor rechace peticiones en caso de que se
alcance el límite de capacidad establecido para evitar la sobrecarga del sistema.

Las opciones de configuración son las siguientes:

Name: Nombre de la restricción.


Count: Número de hebras, por defecto -1.

<capacity-constraint>
<name>my_capacity</name>
<count>50</count>
</capacity-constraint>

Es importante destacar, que las peticiones son rechazadas tanto si se alcanza el límite
de forma individual como de forma global.

Clases y restricciones de tipo Referencing

Un work manager puede definirse mediante la encapsulación de una clase de tipo


request y una o más restricciones.

Las opciones de configuración son las siguientes:

Name: Nombre de la restricción o de la clase.

<work-manager>
<name>priority_work_manager</name>
<fair-share-request-class>
<name>very_high_priority</name>
<fair-share>1000</fair-share>
</fair-share-request-class>
<min-threads-constraint>
<name>min_five_Threads</name>
<count>5</count>
<min-threads-constraint>
</work-manager>

Global-Level Work Managers

Este tipo de work managers, como su propio nombre indica, afecta a todos los
módulos y aplicaciones desplegadas en el servidor, y pueden crearse tango con la
consola de administración como directamente sobre el fichero config.xml.

<self-tuning>
<fair-share-request-class>

Pág. 57 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

<name>HighFairShare</name> <target>mainserver</target>
<fair-share>500</fair-share>
</fair-share-request-class>
<max-threads-constraint>
<name>MoreThreads</name> <target>mainserver</target>
<count>20</count>
<connection-pool-name></connection-pool-name>
</max-threads-constraint>
<work-manager>
<name>priority_work_manager</name>
<target>mainserver</target>
<fair-share-request-class>HighFairShare</fair-share-
request-class>
<response-time-request-class xsi:nil="true"></response-
time-requestclass>
<context-request-class xsi:nil="true"></context-request-
class>
<max-threads-constraint>MoreThreads</max-threads-
constraint>
</work-manager>
</self-tuning>

Una vez creado, se debe crear al menos una clase de tipo request o una restricción. A
partir de ese momento, el work manager las usará para priorizar la carga de trabajo.

Work Manager a nivel de aplicación

Este tipo de work manager, aplican exclusivamente sobre las aplicaciones o modulos
a los que se le asocia a través del fichero de despliegue weblogic-
application.xml tal como se indica a continuación:

<weblogic-application>
<max-threads-constraint>
<name>app_max_threads</name>
<count>10</count>
</max-threads-constraint>
<min-threads-constraint>
<name>app_min_threads</name>
<count>5</count>
</min-threads-constraint>
<work-manager>
<name>AppScopedWorkManager</name>
</work-manager>
</weblogic-application>

Work Managers a nivel de aplicaciones Web


Este tipo de work managers está exclusivamente disponibles para aplicaciones de
tipo Web a través del fichero de políticas, weblogic.xml.

<weblogic-web-app>
<wl-dispatch-policy>LowPriority</wl-dispatch-policy>
<work-manager>
<name>LowPriority</name>

Pág. 58 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

<fair-share-request-class>
<name>LowFairShare</name>
<fair-share>50</fair-share>
</fair-share-request-class>
<max-threads-constraint>
<name>LessThreads</name>
<count>2</count>
</max-threads-constraint>
</work-manager>
</weblogic-web-app>

Work Manager para Stuck Threads

Este tipo de work managers, de tipo Stuck Threads, se configuran para detener el
work manager en uso elimando todas las hebras siguiendo la parametrización que se
índique, aunque también pueden usarse para prevenir la sobrecarga de los managed
servers.

Las opciones de configuración son las siguientes:

Max Stuck Thread Time, es el número de segundos que una hebra debe trabajar
de forma continuada en la misma tarea antes de que el sistema la considere
bloqueada o en estado stuck.

Stuck Thread Count, es el número de hebras en estado stuck para que el servidor
sea transladado al estado FAILED.

En el ejemplo siguiente se muestra la configuración para un work manager con 5


hebras en estado stuck mas de 60 segundos.

<weblogic-web-app>
<wl-dispatch-policy>
stuckthread_workmanager
</wl-dispatch-policy>
<work-manager>
<name>stuckthread_workmanager</name>
<work-manager-shutdown-trigger>
<max-stuck-thread-time>60</max-stuck-thread-time>
<stuck-thread-count>5</stuck-thread-count>
</work-manager-shutdown-trigger>
</work-manager>
</weblogic-web-app>

Colas de ejecución (Execute queues)

Retrocompatibilidad

Desde la versión 10 de Weblogic Server se prove de la posibilidad de usar la


retrocompatibilidad de las colas de ejecución con el fin de facilitar las tareas
derivadas de las migraciones desde versiones anteriores.

Esta retrocompatibilidad permite que:

Pág. 59 / 60
InfV5_JASAS_WLS_BusinessLayer_BestPractices_V210.doc, Ver. 2.1.0
13 de enero de 2011

los work managers configurados se conviertan a execute queues en tiempo de


ejecución por parte del servidor.
El número de hebras de una execute queue se base en una restricción o
constraint.
Y que en caso de que un work manager no implemente alguna restricción, se use
la global default execute queue.

Para que ello sea posible, es necesario realizar uno de los dos cambios siguientes:

• Usar la opción siguiente en la linea de comando de los servidores:


-Dweblogic.Use81StyleExecuteQueues=true

• Añadir la siguiente cláusula al fichero de configuración config.xml:


<use81-style-execute-queues>true</use81-style-execute-
queues>

Pág. 60 / 60

También podría gustarte