Embed Size (px)
Citation preview
Página 1
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
Newsletter – Mayo 2013
5a. Ave. 5-55 Zona14,Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300Fax: (502)2364-5311
[email protected] Pagina 1/10
Oracle WebLogic Server 11g: Tipos de Dominio
Por Ing. Iván García
Modo Producción o Desarrollo:
Todas las organizaciones necesitan algún tipo de desarrollo interno, y esto hace necesario un ambiente en el cuál se puedan realizar pruebas de los sistemas, tareas de verificación de calidad y por supuesto, un ambiente de ejecución cuando los sistemas estén listos para producción. Oracle WebLogic Server nos permite acondicionar estos ambientes para hacer más eficiente nuestro trabajo. Oracle WebLogic Server1 es el servidor de aplicaciones de Oracle para soportar toda la plataforma Oracle Fusion Middleware, así mismo, será nuestro servidor Java para la creación y ejecución de aplicaciones empresariales. WebLogic ofrece dos formas de configurar nuestro "Dominio", entendiéndose Dominio como: una agrupación lógica de todos los recursos Java que se administrarán como una unidad; el Dominio puede estar en un solo servidor o distribuido en varios servidores, se compone de un servidor de Administración (AdminServer) y cero o más servidores administrados (Managed Servers) donde corren las aplicaciones. Ya que los dominios de WebLogic son la agrupación de nuestros recursos, es conveniente tener distintos dominios para cada ambiente de la organización. Las dos formas de configurar el Dominio de WebLogic son: Modo Desarrollo (Development Mode) y Modo Producción (Production Mode). 1 De ahora en adelante mencionado solamente como WebLogic
Contenido
Página:
1 Modo Producción o
Desarrollo
4 Oracle RAC Cache
Coherency
8 Oracle APEX Listener
Editores Generales
Deiby Mauricio Gómez
Alejandro Lau
Debbie Morán
Gerber Bautista
Autores
Contribuyentes
Iván García
Manuel Carrillo
Página 2
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
Development Mode
Un dominio de WebLogic configurado en Development Mode permite un desarrollo de aplicaciones más eficiente, brinda características que permiten la ejecución de pruebas más rápidas al relajar políticas de seguridad y facilitar el despliegue de las
aplicaciones y sus cambios continuos. Cuando se trabaja sobre un dominio configurado en Development Mode podemos aprovechar las siguientes características:
Despliegue Automático
Autodeploy es la característica que permite hacer el auto-despliegue de aplicaciones, de tal forma que no hay necesidad de llevar a cabo todos los pasos de los Asistentes de Despliegue. Se utiliza esta función colocando el archive de la aplicación (jar, war, ear, etc.) en el directorio Autodeploy localizado en $DOMAIN_HOME/autodeploy del dominio. Este directorio es revisado por WebLogic cada ciertos segundos y si detecta una aplicación nueva o una versión más nueva del archive despliega esta aplicación de forma automática sobre el AdminServer. Las aplicaciones siempre será desplegadas sobre el AdminServer, ya que es un dominio de desarrollo no es necesario tener varios Managed Servers para la ejecución de las aplicaciones.
Actualización Inmediata de Cambios
WebLogic permite el despliegue de aplicaciones tanto en archives (jar, war, ear, etc.) así como en " Exploded Directory"1, directorio explotado. Una aplicación en formato exploded directory no es más que un directorio que contiene todos los archivos que estaban encapsulados en el archive, es decir, en lugar de un MiAplicacion.ear, vamos a tener un directorio llamado MiAplicacion, el cual contendrá todos los archivos de la aplicación desempaquetados. Una restricción para que este tipo de despliegues funcione es que todos los archives deben estar igualmente desempaquetados, esto significa que si mi aplicación "ear" contiene un modulo Web llamado moduloWeb.war, este modulo debe existir dentro del directorio MiAplicacion como un directorio llamado moduloWeb y dentro de él estarán todos sus archivos jps, htmls, etc. Y así sucesivamente para todos los archives que compongan la aplicación.
1 También llamado " Expanded Directory", directorio expandido.
Página 3
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
La funcionalidad de los despliegues tipo "Exploded Directory", soportado tanto en Production Mode como en Development Mode, se aprecia utilizando la característica FastSwap del dominio en modo desarrollo. FastSwap permite que podamos hacer cambios a las clases de nuestra aplicación y que veamos los efectos inmediatamente, de esta forma podemos actualizar un .class de la aplicación y sin necesidad de volver a hacer un re-despliegue este cambio entrará en efecto. Las restricciones para que FastSwap funcione son:
Dominio en modo Desarrollo
Aplicación desplegada como "Exploded Directory"
La aplicación debe especificar el uso de FastSwap en el deployment descriptor, esto es
agregar al weblogic-application.xml (para ears) o weblogix.xml (para wars) lo siguiente:
WebLogic revisará solamente las clases dentro del directorio WEB-INF/classes de los
módulos Web.
Inicio más Rápido
El servidor de WebLogic iniciará de forma más rápida gracias a ciertos cambios en el comportamiento en modo Desarrollo. Uno es la ausencia del ingreso de credenciales de Administración para iniciar los servicios. El AdminServer subirá sin ingresar usuario/contraseña del Administrador, gracias a la utilización del archivo boot.properties creado automáticamente, el cual contiene de forma cifrada esta información. Otro es que gracias a la característica de On-Demand Deployment, Despliegue Bajo Demanda, las aplicaciones internas de WebLogic no se cargan al iniciar el servidor sino hasta que son necesarias. Esto se aplica para la Consola de Administración (/console), de tal forma que hasta que se ingrese por primera vez a la URL /console se desplegará la aplicación. Mientras se despliega se muestra una página indicando que el despliegue está en curso, los posteriores accesos será inmediatos debido a que la aplicación ya estará desplegada.
Otras Características
La posibilidad de realizar pruebas sobre los Web Services está disponible solo en modo Desarrollo, WebLogic habilita desde la Consola de Administración el link para ejecutar pruebas de los servicios Web. Los archivos de logs se rotan de forma automática al momento de iniciar el servidor de WebLogic.
<fast-swap>
<enabled>true</enabled>
</fast-swap>
Página 4
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
Production Mode
Un dominio de WebLogic configurado en Production Mode permite una ejecución de las aplicaciones más optimo y protege el dominio forzando un ambiente más estricto de seguridad.
A diferencia del modo Desarrollo un dominio en modo Producción restringe y obliga lo siguiente:
Autodeploy deshabilitado, no es posible hacer despliegue automático y se
debe utilizar el Asistente de Despliegue ya sea por medio de la Consola de Administración
(/console) o las herramientas de línea de comandos.
FastSwap deshabilitado, la actualización inmediata de las clases no está soportada en este
modo, sin embargo, si es posible utilizar los despliegues tipo "Exploded Directory". Si se
desea actualizar clases se debe proceder a realizar un re-despliegue por medio de la
Consola de Administración o las herramientas de línea de comandos.
Es necesario proveer las credenciales de Administración para iniciar y detener los
servicios. Sin embargo es posible crear de forma manual el archivo boot.properties si en
dado caso se desea automatizar estos procesos.
Las aplicaciones internas se despliegan de forma automática al iniciar el servidor de
WebLogic. Aunque sí es posible deshabilitarlas para utilizar On-Demand Deployment. Esto
se habilita en las Configuraciones Generales del Dominio ingresando a la Consola de
Administración de WebLogic (/console).
Cualquier cambio realizado sobre el dominio debe hacerse por medio del Change Center,
de tal forma que se protegen los recursos y se mantiene la consistencia de los cambios.
Se recomienda definir el Modo del Dominio desde la creación del mismo, sin embargo es posible convertir un dominio modo Desarrollo en modo Producción; este cambio se lleva a cabo desde la Consola de Administración de WebLogic, en las configuraciones generales del Dominio, simplemente se debe marcar el checkbox de Production Mode y reiniciar los servicios.
Página 5
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
Hay que tener en cuenta que el regreso de un dominio de modo Producción a modo Desarrollo no se recomienda, y aunque es posible hacerlo no es permanente y se debe especificar el modo Desarrollo cada vez que se inicien los servicios. En conclusión WebLogic nos ofrece dos tipos de configuración del Dominio, buscando en cada uno de ellos el mejoramiento del trabajo, haciendo más eficientes las tareas y optimizando los recursos, tanto tecnológicos como humanos.
Oracle RAC Cache Coherency
Por Ing. Manuel Carrillo
En un sistema clúster, en donde la concurrencia está presente por el simple hecho de compartir los mismos datos con los usuarios, la consistencia de la información debe ser mantenida como una sola imagen, misma que es compartida a todas las sesiones de todas las instancias que componen el clúster. Dentro de los componentes de Oracle RAC tenemos lo denominado Cache Coherency, que puede definirse de la siguiente manera. “En un sistema clúster, los usuarios pueden conectarse a múltiples instancias para ejecutar consultas en la base de datos. Usualmente, los usuarios estarán conectados a través de instancias diferentes, pero van a utilizar el mismo juego de datos, o el mismo conjunto de bloques de datos. Esta situación, demanda que exista un componente que regule la consistencia de datos, confinada a una instancia en particular, pero que pueda extenderse de manera efectiva a múltiples instancias. Dicho componente se denomina Cache Coherency”. (1) Las instancias requieren control sobre tres tipos básicos de concurrencia: Lecturas concurrentes en múltiples instancias –Cuando los usuarios en dos instancias diferentes necesitan leer el mismo conjunto de bloques. Lecturas y escrituras concurrentes en diferentes instancias –Cuando un usuario intenta leer un bloque de datos que ha sido modificado recientemente, y la lectura puede ser de la versión actual del bloque o de una versión previa también consistente. Escrituras concurrentes en diferentes instancias –Cuando el mismo conjunto de bloques de datos son modificados por diferentes usuarios en diferentes instancias.
Página 6
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
En el siguiente ejemplo, se utilizará la herramienta Oracle Enterprise Manager de la versión 11gR2 para poder analizar un problema relacionado a eventos de clúster.
Página de RAC Cache Coherency
En la imagen anterior, podemos observar que existe contención en uno de los componentes de clúster, posiblemente por un bloqueo que esté provocando consumo de recursos por una o varias sesiones en diferentes instancias. Dentro de la página de RAC Cache Coherency, también tenemos acceso a las sesiones que están provocando el mayor consumo de recursos, en este caso se trata de sentencias de tipo UPDATE e INSERT.
Página 7
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
TIP TÉCNICO DEL MES Diferencia entre vistas v$ y vistas gv$: Para cada vista v$, oracle tiene una vista correspondiente con gv$. Adicionalmente a la información en la vista v$, la vista gv$ tiene un campo llamado "inst_id" el cual es un numero que identifica la instancia de la cual se extrajo la información. Entonces la vista v$ es utilizada para consultar información local y gv$ es para consultar información global. Por Ing. Deiby Gómez [email protected]
Análisis de ADDM Dentro del análisis generado por ADDM, podemos observar que tanto las sentencias vistas anteriormente provocaron un bloqueo en diferentes instancias, por lo que se incrementó el evento de espera por clúster.
Conclusión Muchos de los problemas involucrados en los diferentes eventos de espera pueden ser investigados y resueltos mediante los hallazgos de Enterprise Manager, sin embargo es necesario conocer los diferentes componentes, en este caso de Oracle RAC, para llegar de una manera mucho más rápida a la causa raíz y solución del problema.
Página 8
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
Oracle APEX Listener
Por Ing. Manuel Carrillo
Oracle APEX Listener es un componente que brinda una alternativa al uso de un servidor Oracle HTTP (OHS) junto con el módulo mod_plsql. La implementación de este componente provee flexibilidad en cuanto al desarrollo y despliegue de aplicaciones utilizando Oracle Weblogic, Oracle Glassfish u OC4J. Oracle APEX necesita alguna forma en la cual un servidor Web pueda procesar las diferentes peticiones realizadas desde un navegador hacia el engine propio de Oracle APEX. Oracle APEX Listener fue creado para poder satisfacer la necesidad mencionada anteriormente, sin embargo posee algunas características que lo hacen más flexible a través de diversas configuraciones. Por ejemplo, el uso de Oracle APEX Listener simplifica el desarrollo de algunos procesos, ya que no existe un ORACLE_HOME necesario, ya que la conectividad es provista por un driver JDBS embebido.
Configuración Estándar: La configuración estándar de Oracle APEX Listener es aplicable a la mayoría de instalaciones en sistemas locales. Oracle APEX Listener debe estar instalado en un servidor web que soporte J2EE, a los usuarios debe otorgarse la dirección del servicio de Oracle APEX de acuerdo a la siguiente imagen.
Administración: Dentro de las diferentes propiedades de Oracle APEX Listener podemos
mencionar las siguientes.
Conexión: Mediante una conexión podemos proveer credenciales de base de datos y
propiedades de JDBC.
Seguridad: Los mecanismos de seguridad proveen protección validando procedimientos de envío
y recepción de peticiones.
Caching: Oracle APEX Listener provee la capacidad en colocar en cache cierto contenido para un
acceso mucho más rápido.
Página 9
5a Av. 5-55 Zona14, Europlaza World Business Center, Torre II, Nivel 12
PBX (502) 2364-5300 Fax (502) 2364-5311
Procesamiento Pre-Post: Los procedimientos de “PRE” y “POST” permiten especificar
procedimientos de base de datos a invocar antes o después de ejecutar procedimientos especificados en el URL.
Status: Información de estadísticas, rastreo de errores e información de logging.
Misceláneo: Opciones para colocar página de inicio por defecto, habilitar diferentes tipos de
reportes de error y de logging.
