oracle ibÉrica, s.r.l. junta de andalucia › kb › node › 2440 › ...las java server pages...

ORACLE IBÉRICA, S.R.L. ADVANCED CUSTOMER SERVICES

JUNTA DE ANDALUCIA

BEST PRACTICES DESPLIEGUES WEBLOGIC

SOLUTION SUPPORT CENTER

La información incluida en el presente informe es confidencial, siendo para el uso exclusivo del cliente indicado. Si usted no es el destinatario del informe le informamos que está totalmente prohibida cualquier divulgación, distribución o reproducción del contenido de dicho informe.

Referencia documento: InfV5_CAPDER_WLS_Deployment_BestPractices_V10.doc Fecha: 24 de junio de 2019 Versión: 1.1 Copyright(c) 2.019 ORACLE IBÉRICA Todos los derechos reservados

InfV5_WLS_Deployment_BestPractices_V10.doc, Ver. 1.1

24 de junio de 2019

Certificado ISO-9001-2000 Pág. 2 / 34 Nº: 20845/G

Registro de Cambios

Fecha Autor Versión Notas

21/11/2018 Pablo Fernández 1.0 Creación del documento

24/06/2019 Pablo Fernández 1.1 Actualización

Revisiones

Nombre Role

Agustín Calvo Technical Account Manager

Distribución

Copia Nombre Empresa

1 Servicio de Informática Junta de Andalucía

2 Agustín Calvo Oracle Ibérica

3 José María Gómez Oracle Ibérica


24 de junio de 2019


Índice de Contenidos

INTRODUCCIÓN .................................................................................................................................... 4 OBJETIVOS DE ESTE DOCUMENTO .......................................................................................................... 5 TIPOS DE APLICACIONES PROPORCIONADAS POR EL PROVEEDOR ........................................................... 6

El rol del Servidor Web ..................................................................................................................... 6 Aplicaciones Web .............................................................................................................................. 7 Aplicaciones Java EJB .................................................................................................................... 11 Aplicaciones Java Enterprise .......................................................................................................... 15

DESPLIEGUE DE APLICACIONES SOBRE WEBLOGIC SERVER EN UN ENTORNO DE DESARROLLO ........... 18 Pasos en un proceso de Despliegue ................................................................................................ 18 Métodos de Despliegue ................................................................................................................... 19

DESPLIEGUE DE APLICACIONES EN UN ENTORNO DE PRODUCCIÓN SOBRE WEBLOGIC SERVER ............ 21 Métodos de Despliegue ................................................................................................................... 21

OPCIONES AVANZADAS DE DESPLIEGUE QUE PROPORCIONA WEBLOGIC SERVER ................................ 25 Plan de Despliegue ......................................................................................................................... 25 Redespliegue en entornos de Producción ....................................................................................... 26 Distribución de Aplicaciones .......................................................................................................... 28 Posibles modos staging en el despliegue de aplicaciones en WebLogic Server ............................. 29 Classloaders en WebLogic Server................................................................................................... 31 Filtrado de clases en WebLogic Server ........................................................................................... 33 Best practices en el uso de librerías compartidas ........................................................................... 33


24 de junio de 2019


Introducción

Este documento recoge una serie de recomendaciones de Oracle Soporte planteadas como buenas prácticas para realizar una correcta puesta en producción o despliegue de aplicación dentro de un entorno de servidores de aplicaciones que hagan uso de Oracle WebLogic Server 12c. Estas recomendaciones están encaminadas a utilizar la metodología más adecuada según las características de la aplicación y a minimizar los posibles problemas de configuración y despliegue de las aplicaciones en el servidor de aplicaciones Oracle WebLogic Server 12c.


24 de junio de 2019


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 despliegue de aplicaciones en servidores de aplicaciones Oracle WebLogic Server 12cR2.

El propósito de esta guía de buenas prácticas incluye los siguientes objetivos:

Conocimiento de las diferentes aplicaciones que nos puede proporcionar un proveedor y sus principales características y diferencias.

Recomendaciones para realizar despliegues de aplicaciones en entornos de desarrollo, así como las herramientas que proporciona Oracle WebLogic Server 12c para llevarlo a cabo.

Recomendaciones para realizar despliegues de aplicaciones en entornos de desarrollo y producción, incluyendo el uso de las herramientas que proporciona Oracle WebLogic Server 12c para llevarlo a cabo.

Recomendaciones para despliegues avanzados como pueden ser los siguientes:

o Uso de Aplicaciones de Terceros.

o Redespliegues de aplicaciones (actualizaciones o cambios de versión de aplicaciones ya desplegadas).

o Buenas prácticas en el uso de planes de despliegue (deployment plans).


24 de junio de 2019


Tipos de aplicaciones proporcionadas por el proveedor

En este apartado se detallarán los distintos tipos de aplicaciones Java que nos podemos encontrar desarrolladas por un proveedor; se comentarán las características que las diferencias, y siempre teniendo como referencia un entorno de WebLogic Server 12c.

El rol del Servidor Web

El Servidor Web

Un servidor Web es responsable de manejar las peticiones HTTP de los clientes. HTTP es un protocolo sin estado (stateless). Esto significa que, por cada petición, una conexión es establecida entre el cliente y el servidor; la petición se maneja, y luego se cierra la conexión. No hay nada en el protocolo HTTP que permita a un servidor tratar una petición concreta de manera diferente dependiendo de la cantidad de veces que se ha solicitado. Tal comportamiento puede, sin embargo, ser simulado con el uso de cookies.

Oracle WebLogic Server es un servidor web totalmente funcional que puede controlar sitios web con un alto volumen de datos, carga, etc. Sirve tanto archivos estáticos como archivos HTML y archivos de imagen como contenido dinámico, mediante servlets y JavaServer Pages (JSP). Oracle WebLogic Server es compatible con la especificación HTTP 1.1.


24 de junio de 2019


Aplicaciones Web

Aplicaciones Web

Una aplicación Web en Oracle WebLogic Server incluye los siguientes ficheros:

Servlets, JSPs, y otras clases Java.

De forma opcional, un descriptor de despliegue web.xml, que es un documento de Java EE XML estándar que describe el contenido de un archivo Web (WAR).

De forma opcional, un descriptor de despliegue weblogic.xml, que es un documento XML que contiene elementos de Oracle WebLogic Server específico para aplicaciones Web.

Una aplicación Web también puede incluir páginas HTML y otro contenido estático como imágenes y archivos multimedia.

Un servlet es una clase Java que se ejecuta en un servidor Java EE. Se ocupa de procesar una petición HTTP (HTTP request), y proporciona una respuesta HTTP (HTTP response), por lo general en forma de una página HTML. El uso más común de los servlets HTTP es crear aplicaciones interactivas utilizando navegadores web estándares para la presentación desde el lado del cliente. Los servlets pueden acceder a bases de datos, Enterprise JavaBeans (EJB), recursos JMS, sesiones HTTP, y otros servicios de Oracle WebLogic Server.

Las Java Server Pages (JSP) son páginas web con un código HTML extendido que permite incrustar código Java. Una JSP puede llamar a una clase Java personalizada, conocida como librerías de etiquetas (tag libraries), usando HTML como tags. El

compilador appc compila las JSPs y las traduce a servlets.

Oracle WebLogic Server automáticamente compila JSPs si el archivo class del servlet no está presente o es más antiguo que el archivo de código fuente de la JSP. También puede realizar precompilación de JSPs, empaquetando el servlet resultante en el archivo WAR, para evitar la compilación en el servidor bajo demanda.

Empaquetado de Aplicaciones Web

Antes de desplegar una aplicación empaquetada y registrarla contra Oracle WebLogic Server, se recomienda seguir estos pasos para empaquetarla:

1. Organizar los recursos en una estructura de directorios.

2. Editar el descriptor de despliegue web.xml.


24 de junio de 2019


3. Editar el descriptor de despliegue weblogic.xml (que incluirá la

configuración específica de WLS).

4. Empaquetar la aplicación en un fichero .war usando la utilidad Java

Archive (jar) en línea de comandos, o cualquier otra herramienta que facilite el empaquetado de aplicaciones Web, como entornos de desarrollo (JDeveloper, NetBeans, Eclipse, etc.).

5. Desplegar la aplicación Web dentro de Oracle WebLogic Server.

6. Configurar los recursos y servicios necesarios por la aplicación Web desde la Consola de Administración de Oracle WebLogic Server.

El empaquetado y despliegue de una aplicación Web es un proceso relativamente simple. Los puntos más complicados del proceso son la configuración de los descriptores de despliegue (archivos XML). Hoy en día lo más fácil, cómodo y menos susceptible de cometer errores es usar una herramienta para la edición de dichos descriptores, como los entornos de desarrollo mencionados anteriormente. El

objetivo y la descripción de los dos archivos principales (web.xml y

weblogic.xml) será cubierto más adelante a lo largo de este documento.

NOTA: La tarea de creación de los ficheros web.xml y weblogic.xml está asociada a desarrollo y no forma parte de las funciones específicas de administración, por lo que cualquier aplicación debe incluir estos dos ficheros pre-configurados.

Estructura de una Aplicación Web

Tras desarrollar una aplicación Web con una estructura de directorios específica para que pueda ser empaquetada y desplegada en Oracle WebLogic Server, u otro servidor compatible con Java EE., todos los servlets, clases Java, archivos estáticos, y otros recursos que pertenecen a dicha aplicación se organizan en una jerarquía de directorios. La raíz de esta jerarquía define la raíz de la aplicación Web. Todos los archivos bajo este directorio raíz se pueden servir al cliente, a excepción de los

archivos bajo el directorio WEB-INF. Todos los archivos en WEB-INF son privados y no se sirven a peticiones de clientes, incluyendo los descriptores de despliegue XML.


24 de junio de 2019


Un archivo WAR contiene a su vez los archivos que componen una aplicación Web. El archivo WAR se despliega como una unidad en una o más instancias de Oracle WebLogic Server. El archivo WAR se puede desplegar solo o empaquetado en un Enterprise Archive (EAR) con otros componentes de aplicación. Si se pretende

desplegar solo, el archivo debe terminar con una extensión .war. Si se ha incluido

como parte de un archivo EAR, éste debe tener extensión de .ear.

Oracle WebLogic Server permite realizar el despliegue de la aplicación Web sin necesidad de empaquetar la misma, directamente usando la estructura de directorios. Esta técnica es especialmente útil mientras la aplicación está en fase de desarrollo. Es lo que se conoce como despliegue desde el directorio o despliegue desde archive exploded directory. Hay que tener en cuenta que este tipo de despliegue solo se permite sobre el servidor de Administración, no sobre los managed servers.

Por tanto, una aplicación Web puede ser:

Un fichero empaquetado (.war) que incluye toda la estructura de la aplicación Web.

Un directorio con toda la estructura de la aplicación Web (sin empaquetar).

Los archivos privados deben estar ubicados en el directorio WEB-INF, dentro del directorio raíz. Hay que asegurarse de que la aplicación contiene los siguientes directorios y archivos:

MiAppWeb/: Se trata del directorio raíz de la aplicación Web. En él podrán

incluirse archivos estáticos, como archivos HTML y JSPs, directamente a nivel del directorio raíz o bien en subdirectorios.


24 de junio de 2019


/WEB-INF/web.xml: El descriptor de despliegue que incluye la

configuración de la aplicación Web

/WEB-INF/weblogic.xml: El descriptor de despliegue específico de

WebLogic que define y mapea los recursos mencionados en el archivo web.xml a los recursos que residen dentro de Oracle WebLogic Server. Este archivo también se utiliza para definir los atributos de sesión HTTP y JSP.

/WEB-INF/classes (opcional): Contiene clases Java, como servlets y

otras helper clases.

/WEB-INF/lib (opcional): Contiene librerías Java, es decir ficheros .jar,

que son usadas por la aplicación

Ficheros de Configuración de una aplicación Web

web.xml

El descriptor de despliegue web.xml sigue la especificación Servlet 3.0 (JSR-000315). Se empaqueta junto con los componentes de la aplicación

Web en un archivo .war, que se despliega en Oracle WebLogic Server.

Se utiliza para configurar los siguientes elementos de la aplicación Web:

o Registrar Servlets y JSPs.

o Parámetros de inicialización de Servlets.

o Tags de librerías JSP.

o Mapeo de tipos MIME.

o Páginas de error.

o Restricciones de seguridad y roles.

o Recursos.

o Referencias a EJBs.

webLogic.xml

El descriptor de despliegue weblogic.xml sigue un esquema propietario que se utiliza sólo para Oracle WebLogic Server. Permite configurar las

http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-oth-JSpec/


24 de junio de 2019


características de la aplicación Web que no son parte de la especificación Java EE, a saber:

o El context root de la aplicación.

o Configuración de logging de la aplicación.

o Mapeo de roles de seguridad.

o Configuración avanzada de sesiones.

o Configuración de sesiones en clúster.

o Referencias a las librerías compartidas (shared libraries).

o Referencias a los recursos definidos a nivel del servidor (data sources, recursos JMS, etc.).

o Configuración de work managers y hebras.

o Directorios virtuales.

o Opciones del compilador de JSPs.

Aplicaciones Java EJB

Aplicaciones EJB

Incluyen los denominados Enterprise Java Beans o EJBs. Los EJBs tienen las siguientes características:


24 de junio de 2019


Permiten estandarizar el desarrollo y despliegue de componentes

distribuidos en el servidor.

Son una de las APIs que forman parte del estándar de construcción de aplicaciones empresariales JavaEE.

Incluyen descriptores de despliegue XML específicos para este tipo de aplicaciones. Desde la versión EJB 3.0, los descriptores de despliegue son opcionales, ya que pueden ser sustituidos por anotaciones Java (Java annotations).

Soporta las siguientes funcionalidades:

o Comunicación remota (entre JVMs distintas) mediante el protocolo RMI-IIOP.

o Transacciones.

o Control de la concurrencia.

o Producción o consumo de mensajes utilizando JMS (Java messaging service)

o Servicios de nombres y de directorio (JNDI).

o Seguridad.

Tipos de Enterprise Java Beans:

o Stateless Session Beans

No mantienen estado, y su invocación es asíncrona.

Ejemplo de uso: Comprobar la validez de un valor en el mercado de valores (stock symbol).

o Stateful Session Beans

Mantienen estado, lo que permite al cliente mantener una conversación con el EJB.

Ejemplo de uso: Gestionar un carrito de la compra, realizar una reserva de un vuelo online.

o Singleton Session Beans

http://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones

http://es.wikipedia.org/wiki/J2EE

http://es.wikipedia.org/wiki/JMS


24 de junio de 2019


Mantienen un único estado para toda la JVM.

Ejemplo de uso: cargar una única lista de precios global que será consultada por todos los usuarios.

o Message Driven Beans

Son asíncronos y stateless, y permiten consumir mensajes de un destino JMS.

Ejemplo de uso: Almacenar los mensajes de log.

o NOTA: desde EJB 3.0, los denominados entity beans han sido sustituidos por la denominada Java Persistence API (JPA).

Estructura de Aplicaciones EJB

El descriptor de despliegue JavaEE, ejb-jar.xml, se describen las características de los EJBs que están empaquetados en una aplicación EJB, como por ejemplo los roles de seguridad y los atributos de transaccionalidad de los métodos de dichos EJBs.

Además del descriptor estándar de la especificación JavaEE, existe opcionalmente el

descriptor de despliegue específico de WebLogic Server, weblogic-ejb-jar.xml, donde se configuran elementos como nombres de JNDI, propiedades de clustering y configuración del pool y la caché de EJBs.

Los módulos EJB se empaquetan como archivos con la extensión .jar. Al igual que las aplicaciones Web, también pueden ser desplegados desde un archive exploded directory.

NOTA: Desde EJB 3.1, es posible empaquetar EJBs en aplicaciones Web (.war).

A continuación se muestra la estructura de un módulo EJB:


24 de junio de 2019


Ficheros de configuración de Aplicaciones EJB

ejb-jar.xml

Es el descriptor estándar JavaEE para módulos de EJBs. Desde EJB 3.0, no es necesario incluirlo, ya que la mayor parte de la configuración se realizará mediante anotaciones Java. En caso de estar presente, permite declarar información estructural relativa a los EJBs del módulo

webLogic-ejb-jar.xml

Sigue un esquema propietario que es utilizado sólo por Oracle WebLogic Server. Permite activar y configurar características de EJBs que no forman parte de la especificación JavaEE, como por ejemplo:

o Mapeo de los security roles presentes en las anotaciones de los EJBs a las identidades del realm de la seguridad WebLogic

o Habilitar el balanceo de carga y failover para invocaciones remotas EJB.

o Optimización de rendimiento EJB utilizando pool y configuración de la memoria caché.

o Asignación de un WebLogic WorkManager para procesar las peticiones contra un EJB.

o Tuning de las hebras o threads para ajustar el comportamiento que se utiliza para procesar las peticiones contra un EJB.


24 de junio de 2019


Aplicaciones Java Enterprise

Aplicaciones Enterprise

Una aplicación Enterprise es una agrupación de varios recursos en una unidad de

despliegue que se empaqueta en un archivo con extensión.ear.

Estos recursos incluyen:

Aplicaciones Web (.war)

Aplicaciones EJB (.jar)

Módulos de aplicaciones de cliente o client application modules (.jar)

Resource adapters (.rar)

Librerías Java (.jar)

Permite que aplicaciones relacionadas sean desplegadas como una única unidad, favoreciendo el acceso a recursos comunes.

Estructura de Enterprise Aplicaciones

Las Aplicaciones Enterprise pueden ser desplegadas como un fichero empaquetado

con la extensión .ear o desde un archive exploded directory, tal y como ocurría con las aplicaciones Web y los módulos EJB. De nuevo hay que tener en cuenta que esta segunda opción se permite solo en entornos de desarrollo, cuando el target es el servidor de Administración.

El descriptor de despliegue opcional, application.xml, se encuentra en el

directorio META-INF, y contiene un elemento para cada aplicación Web, EJB y módulo de resource adapter, así como los elementos adicionales para describir los roles de seguridad y recursos de la aplicación como conexión a bases de datos.

Si este descriptor está presente, el despliegue en WebLogic recoge la lista de los módulos de este descriptor. Sin embargo, si este descriptor no está presente, el contenedor sugiere los nombres de módulo y los tipos en función de la estructura empaquetada y de las anotaciones definidas en las clases de Java.

Por defecto, las clases Java presentes en los módulos EJB incluidos en el .ear están accesibles desde cualquier módulo de una aplicación Web que se encuentre en la aplicación Enterprise. Sin embargo, las clases Java dentro de un módulo de aplicación Web sólo están disponibles para ese módulo. Para compartir archivos de clases y librerías, entre todos los módulos, hay que almacenarlos en el directorio


24 de junio de 2019


APP-INF. Estos recursos serán puestos a disposición de todos los módulos de aplicación.

A continuación se muestra la estructura de un fichero .ear:

Ficheros de configuración de Aplicaciones Enterprise

application.xml

Es el descriptor estándar de JavaEE para aplicaciones Enterprise. Es opcional, ya que puede ser sustituido por anotaciones Java. Tal y como se mencionó anteriormente, define la lista de cada módulo incluido en la aplicación, indicando elementos como el context root para aplicaciones Web o los directorios de librerías Java para todos los módulos de la aplicación Enterprise o para cada módulo.

webLogic-application.xml

Se trata del descriptor de despliegue específico de WebLogic Server, y solo es necesario en caso de querer configurar alguna de las características de WebLogic Server, como por ejemplo:

o Referencias a módulos de librerías compartidas que son desplegados fuera de esta aplicación.

o Asignación de WorkManagers de WebLogic Server para procesar las peticiones contra de los módulos de aplicación.


24 de junio de 2019


o Tuning de las hebras para procesar las peticiones contra los módulos de

aplicación.

o Cambiar el timeout de sesión HTTP para todos los módulos de aplicación Web.

o Cambiar el nombre de la cookie por defecto que se utiliza para mantener las sesiones HTTP para todos los módulos de aplicación Web.

o Habilitar funcionalidades de clustering y replicación, como la replicación en memoria y la persistencia de todos los módulos de aplicación Web.

o Configuración de una caché de EJB para toda la aplicación.


24 de junio de 2019


Despliegue de aplicaciones sobre WebLogic Server en un entorno de desarrollo

En este apartado se hace referencia a la metodología, buenas prácticas, opciones y herramientas a utilizar dentro de un entorno de desarrollo en el que se hagan uso de servidores de aplicaciones Oracle WebLogic Server.

Pasos en un proceso de Despliegue

Overview

El proceso de despliegue consta de diferentes fases:

1. Fase de Preparación

Consiste en la preparación de las aplicaciones y módulos para su despliegue. Se pueden desplegar aplicaciones, ya sea como archivos empaquetados o como directorios de archivo (archive exploded directory). De nuevo recordar que esta opción solo se permite en entornos de desarrollo.

Antes de desplegar una aplicación, un administrador prepara los módulos de despliegue mediante la creación de un directorio de instalación de la aplicación y copia del archivo empaquetado de la aplicación.

2. Fase de Configuración

Los administradores suelen recibir una nueva aplicación (o una nueva versión de una aplicación ya existente) desde el equipo de desarrollo, y deben desplegar la aplicación en un entorno de desarrollo o de producción.

Oracle WebLogic Server ayuda a configurar fácilmente una aplicación para un dominio sin tener que editar manualmente los archivos del descriptor de despliegue previsto por el equipo de desarrollo.

Los cambios de configuración para un entorno específico se almacenan en una nueva configuración dentro de lo que se conoce como un plan de despliegue o deployment plan, que será visto con más detalle a lo largo documento.

3. Fase de Despliegue

Se procede al despliegue de la aplicación sobre Oracle WebLogic Server, después de preparar los archivos de despliegue y configuración. Las aplicaciones se distribuyen a los servidores de destino del dominio Oracle WebLogic y se activan para permitir procesar peticiones.


24 de junio de 2019


Métodos de Despliegue

Oracle WebLogic Server 12cR2 soporta hasta cinco métodos nativos distintos (esto es, incluidos directamente desde fábrica en el propio producto) para el despliegue de aplicaciones, que proporcionan alternativas para los diferentes posibles escenarios. Los métodos disponibles son los siguientes:

Consola de Administración

WebLogic Scripting Tool (WLST)

Clase webLogic.Deployer

Wldeploy Ant

Auto-deploy desde directorio

En principio, en un entorno de desarrollo no se establecerán limitaciones sobre el método a emplear, por lo que el desarrollador puede elegir con el que se sienta más cómodo. Sin embargo, cuando se trate de entornos de pre-producción o producción, para evitar posibles problemas y errores inesperados, se recomienda realizar las pruebas unitarias y pruebas de despliegue de la aplicación en un dominio de Oracle WebLogic Server configurado en modo de producción.

La Consola de Administración proporciona una serie de asistentes o wizards de despliegue basado en Web que guiarán en el proceso de despliegue. La Consola de Administración también ofrece controles para cambiar y monitorizar el estado de despliegue, y cambiar valores del descriptor de despliegue

El directorio de dominio autodeploy permite desplegar rápidamente una aplicación (sin necesidad de realizar el empaquetado de la misma) para la evaluación o prueba en un entorno de desarrollo. Hay que tener en cuenta que este método solo funciona en el servidor de Administración, no en los managed servers.

FastSwap

La funcionalidad FastSwap de Oracle WebLogic Server permite cambiar clases en

caliente, es decir, sustituir el .class de una clase por otra sin necesidad de recargar el classloader.

Tiene las siguientes características:

Permite usar los descriptores de despliegue WebLogic.

Sólo está disponible si el dominio no se está ejecutando en production mode.


24 de junio de 2019


WebLogic automáticamente vuelve a cargar clase Java modificada.

Los desarrolladores pueden realizar el desarrollo iterativo sin un redespliegue explícito

Configuración de Fast-Swap en el fichero de configuración weblogic.xml para el

caso de aplicaciones .war o fichero weblogic-application.xml para aplicaciones .ear.

[…]

<fast-swap>true</fast-swap>

[…]

Despliegue desde la Consola

Dentro de los métodos de despliegue en un entorno de desarrollo, otro de los métodos recomendados para su uso es el despliegue desde la Consola de Administración.

Es un método que permite el control manual sobre todo el proceso de despliegue.

Puede ser usado en entornos de desarrollo, aunque se cubrirá en detalle en el siguiente apartado, de Despliegue de aplicaciones en un entorno de producción sobre WebLogic Server.


24 de junio de 2019


Despliegue de aplicaciones en un entorno de producción sobre WebLogic Server

En este apartado se hace referencia a la metodología, buenas prácticas, opciones y herramientas a utilizar dentro de un entorno de producción en el que se hagan uso de servidores de aplicaciones Oracle WebLogic Server.

Métodos de Despliegue

En principio, en un entorno de producción se limitará el método de despliegue a:

Despliegue desde la Consola de Administración.

Despliegue desde weblogic.Deployer.

Despliegue desde WLST.

El administrador puede elegir la opción con la que se sienta más cómodo.

De nuevo, insistir en que para evitar posibles problemas y errores inesperados cuando el despliegue se realice en un entorno de producción, se recomienda realizar las pruebas unitarias y pruebas de despliegue de la aplicación en un dominio de Oracle WebLogic Server configurado en modo de producción.

Despliegue desde la Consola de Administración

El método de despliegue desde la Consola permite el control manual sobre el proceso de despliegue. Las aplicaciones pueden instalarse directamente desde una ubicación de red (recomendado en entornos distribuidos) o desde un disco local a la máquina donde corre el servidor de WebLogic.

También permite realizar ciertas modificaciones a nivel de configuración de la aplicación y desplegar de forma selectiva sobre uno, varios o todos los managed servers miembros de un clúster.

Todos los tipos de aplicaciones JavaEE se despliegan de la misma forma en Oracle WebLogic Server, y los pasos son los siguientes:

1. En el panel de la izquierda de la Consola, seleccionar Deployments.

2. En el panel de la derecha de la Consola, hacer click en Install.


24 de junio de 2019


3. Localizar el fichero que corresponda a la aplicación que se desee instalar

usando el file browser o bien introducir la ruta en el sistema de archivos local de forma manual, y posteriormente hacer click en Next.

4. Si se trata de aplicaciones JavaEE, seleccionar Install this deployment as an application. En el caso de que lo se esté instalando es una librería compartida o shared library, seleccionar Install this deployment as a library compartida que puede ser referenciada por otras aplicaciones.

5. Seleccionar los managed servers o clusters sobre los cuales se desee desplegar la aplicación y hacer click en Next.


24 de junio de 2019


Despliegue desde la Línea de Comandos

La utilidad weblogic.Deployer es una herramienta basada en Java que proporciona una interfaz de línea de comandos para tareas de despliegue. Permite desplegar una nueva aplicación (deploy), actualizar de una aplicación existente (redeploy), o eliminar una aplicación (undeploy). También puede desplegar módulos JMS, JDBC, y WebLogic Diagnostic Framework (WLDF).

La sintaxis es la siguiente:

Recomendación de directorios para entornos de Producción

En un entorno de producción es muy recomendable establecer una estructura de directorios que permita separar los archivos de configuración generados a partir de los archivos de aplicación de los propios archivos de aplicación, de modo que los archivos de configuración pueden ser fácilmente modificados o reemplazados sin alterar la propia aplicación.

La estructura recomendada también ayudara a organizar y mantener varias versiones de los archivos de despliegue de la misma aplicación. El diagrama de la imagen muestra la jerarquía de directorios para almacenar una aplicación o un módulo de despliegue.


24 de junio de 2019


El directorio app contiene los desplegables mientras que el directorio plan contiene

el fichero plan.xml o plan de despliegue.

Despliegue de aplicaciones con comprobación previa

En entornos de producción, es una buena práctica instalar las aplicaciones inicialmente en el denominado modo de administración. De esta forma, los administradores pueden desplegar una aplicación en un entorno de producción sin exponer la aplicación a los clientes externos.

El acceso a la aplicación se limita a un canal configurado de administración. Durante esta fase, el administrador del entorno podrá realizar comprobaciones básicas de funcionalidad de la aplicación directamente en el entorno de producción, sin interrupciones de los clientes. Una vez que las comprobaciones son satisfactorias, se puede exponer la aplicación al exterior.

Para hacer uso del modo de administración, una vez desplegada la aplicación, procederemos a arrancarla con la opción Servicing only administration requests:

Comprobado que todo esté bien, la arrancaremos con la opción Servicing all requests. Esto solo es válido para aplicaciones nuevas, ya que si se trata de una aplicación existente (y por tanto de un redespliegue), el redespliegue implica automáticamente el arranque de la aplicación, es decir, su disposición a recibir peticiones de clientes.


24 de junio de 2019


Opciones avanzadas de despliegue que proporciona WebLogic Server

En este apartado se hace referencia a buenas prácticas, opciones avanzadas y herramientas a utilizar dentro de un despliegue que se hagan uso de servidores de aplicaciones Oracle WebLogic Server.

Plan de Despliegue

Plan de Despliegue

Se trata de un documento XML opcional que reside fuera de la aplicación. Se configura una aplicación para su despliegue en un entorno de WLS específico. Es creado y gestionado por los administradores o desarrolladores de un entorno particular.

Se utiliza para definir la configuración de despliegue de una aplicación para un entorno de servidor, como puede ser desarrollo, preproducción o producción. Contiene propiedades de despliegue que sobrescriben las existentes los descriptores de despliegue.

Una de las principales motivaciones a la hora de usar planes de despliegue es que cualquier recurso externo requerido por la aplicación está sujeto a cambios cuando la aplicación se despliega en un entorno diferente. Por ejemplo, los nombres JNDI de los datasources que se utilizan en el entorno de desarrollo pueden ser diferentes de los utilizados en producción.

Ventajas de usar un Plan de Despliegue

Permite reemplazar el valor de las propiedades de despliegue que se definen en el descriptor de despliegue de una aplicación.

Ayuda a modificar fácilmente la configuración de una aplicación para el despliegue en diferentes entornos de WebLogic Server sin modificar los archivos de descriptor de despliegue que se incluyen en el archivo de aplicación.

Permite que una aplicación se despliegue en varios servidores o clusters que tienen una configuración diferente dentro del mismo dominio.


24 de junio de 2019


Figura: Ejemplo de plan de despliegue

Los elementos básicos de un plan de despliegue cumplen las siguientes funciones:

deployment-plan: Encapsula el contenido del plan de despliegue.

aplication-name: Corresponde al nombre de despliegue de la aplicación o módulo.

variable-definition: Define una o más variables. Cada definición de variable incluye el nombre de una variable y un valor, que puede ser nulo.

Module-override: Incluye, para cada módulo, el tipo de módulo, y para cada elemento del descriptor de despliegue, el nombre de la variable que permitirá asignarle valor a dicho elemento.

Herramientas para crear un Plan de Despliegue:

webLogic.PlanGenerator

Consola de Administración

Una vez creado el plan de despliegue, podemos editarlo para ajustar las distintas variables, y proceder al despliegue de la aplicación usando dicho plan de

despliegue. Por ejemplo, usando weblogic.Deployer, lo haríamos de la siguiente forma:

En el ejemplo de arriba, estamos desplegando una aplicación de nombre myApp

sobre un target myCluster usando el plan de despliegue myAppPlan.xml.

Redespliegue en entornos de Producción

Redespliegue en producción

java weblogic.Deployer -adminurl t3://localhost:7001 -user

weblogic -password welcome1 -deploy -name myApp -source

myApp.war -targets myCluster -stage -plan myAppPlan.xml


24 de junio de 2019


El redespliegue en producción esta soportado principalmente para aplicaciones con un punto de entrada aplicación Web (clientes HTTP).

Redespliegue en producción permite a un administrador volver a desplegar una nueva versión de una aplicación en un entorno de producción sin detener la versión de la aplicación desplegada actualmente y no interrumpir la disponibilidad de la aplicación a los clientes.

Oracle WebLogic Server 12cR2 gestiona las peticiones provenientes de sesiones en curso que están haciendo uso de la versión anterior de una aplicación de tal manera que solo sean las peticiones de sesiones nuevas (posteriores al despliegue de la nueva versión) las que hagan uso de la nueva versión de la aplicación.

La posibilidad de realizar un redespliegue en producción nos permite activar una versión revisada de una aplicación de producción y permitir que conviva con la versión anterior, con las siguientes características:

Sin afectar a los clientes que están trabajando actualmente con la aplicación.

Sin interrumpir la disponibilidad de la aplicación de tal manera que:

o Los clientes existentes continúan utilizando la antigua versión de la aplicación.

o Las nuevas peticiones de cliente se redirigen a la nueva versión de la aplicación.

Para soportar estrategias de redespliegue en producción, Oracle WebLogic Server

reconoce una única versión del archivo manifest, la que se encuentra en META-

INF/MANIFEST.MF.


24 de junio de 2019


Ventajas de usar redespliegue de aplicaciones:

Evitar programación de paradas de aplicaciones (downtime).

Evitar la necesidad de crear servidores redundantes para acoger las nuevas versiones de aplicaciones.

Gestión de acceso del cliente a múltiples versiones de aplicaciones de forma automática.

Retirada de anteriores versiones de una aplicación de forma manual.

El redespliegue en producción esta soportado para:

Aplicaciones o módulos Web (WAR) y aplicaciones Enterprise (EAR), cuyo cliente accede a través de una aplicación Web (vía HTTP).

Aplicaciones Enterprise a las que se accede por mensajería JMS desde un destino JMS o desde peticiones JCA.

Todo tipo de web services, incluyendo conversational web services.

El redespliegue en producción no está soportado para:

Aplicaciones EJB o módulos de recursos (RAR).

Las aplicaciones que acceden a recursos JDBC vía DriverManager (práctica que está deprecated).

Cuando se redespliega una nueva versión de una aplicación, las siguientes características no se pueden modificar:

El targeting del despliegue ( los servidores donde se despliega)

El modelo de seguridad de la aplicación.

La configuración del almacenamiento de persistencia (persistent store)

Distribución de Aplicaciones

Distribución de aplicaciones antes de realizar el despliegue


24 de junio de 2019


La distribución es una alternativa al despliegue completo de una aplicación.

Si optamos por distribuir una aplicación, WebLogic se encargará de prepararla para el posterior despliegue copiando sus archivos a todos los servidores de destino, realizando una validación de los mismos.

Una vez distribuida la aplicación (en status distributed), se puedes iniciar en el modo de administración. El acceso a la petición se limita a un canal configurado de Administración. Hay que tener en cuenta que el redespliegue de una nueva versión de una aplicación pone a la aplicación inmediatamente en uso y la hace disponible a peticiones de clientes.

Posibles modos staging en el despliegue de aplicaciones en WebLogic Server

Con Oracle WebLogic Server se tiene el control sobre si o no, dónde y por quién los archivos de la aplicación se copian antes de ser desplegados.

Existen tres posibles estrategias:

Stage Mode

Previamente al despliegue, el fichero de la aplicación que va a ser desplegada sobre los managed servers es copiado por el servidor de Administración al propio managed server, antes de pasar a la fase de preparado. Este es el modo de despliegue por defecto, conocido como staging (StagingMode = stage).

Nostage mode

Si los managed servers se ejecutan en una máquina que no sea la misma que el servidor de Administración, y la ubicación de la aplicación está en un sistema de archivos que sea accesible para el managed server, entonces estaremos usando el


24 de junio de 2019


denominado no-stage mode (StagingMode = nostage). En este caso todos los managed servers usan la misma copia del fichero.

External_stage mode

Como última opción, si el usuario o alguna herramienta de terceros realiza la copia de los ficheros antes al directorio de stage de los managed servers, estaremos usando el denominado external stage mode (StagingMode = external_stage).

Se puede configurar el despliegue a nivel de servidor o a nivel de aplicación como:

Staged (modo por defecto): Los archivos se copian en el directorio de preconfigurado para la preparación y activación de la aplicación (que por

defecto es $SEVER_HOME/stage, aunque es configurable).

No stage: Los archivos se despliegan desde un lugar concreto, que debe ser accesible desde las máquinas donde residen cada unos de los severs donde se despliega la aplicación.

External stage: Los archivos se copian por un usuario o una herramienta de terceros antes del despliegue al directorio de stage.

Como recomendación al uso de uno u otro método de distribución de los ficheros se recomienda el uso del modo por defecto staged.


24 de junio de 2019


Classloaders en WebLogic Server

Los Classloaders son módulos fundamentales en Java. Un classloader es una parte de la JVM que carga clases en memoria; el classloader es el responsable de encontrar y cargar los ficheros de clases (.class) en tiempo de ejecución.

Los classloaders son jerárquicos con parent classloader y child classloader, cuando se solicita la ejecución de una clase determinada, para la carga de dicha clase, se siguen las siguientes reglas por defecto:

1. La implementación del classloader chequea si la clase ya ha sido cargada y está presente en el classloader al que se tiene acceso.

2. Si no fue cargada, se solicita al classloader padre (nivel superior en la jerarquía) que cargue la clase.

3. Si el classloader padre no puede cargar la clase, se intenta cargar la clase en el classloader propio.

4. Si una clase existe en el Classloader Parent y en el Classloader Child, la versión del classloader parent se cargará.

Por defecto, el cargador de clases o classloader de Oracle WebLogic Server sigue un modelo top down, tal y como indica la especificación JavaEE:

Bootstrap Class Loader – Es el root en la jerarquía de Classloaders. Carga las clases internas del JDK, normalmente carga el rt.jar y otras clases de core, por ejmplo las clases del paquete java.lang*

Extensions Class Loader – Carga las clases desde el directorio extensions de JDK, normalmente el directorio JAVA_HOME/lib/ext del JRE. Es decir se cargará cualquier clase que se coloque en el directorio JAVA_HOME/lib/ext. Importante: las clases del directorio extensions tienen que ser autocontenidas es decir sólo pueden referenciar a clases que estén en el JAVA_/HOME/lib/ext

System ClassLoader. Extiende al Extensions ClassLoader, son las clases que se cargan en el CLASSPATH especificado en el arranque de la JVM, por ejemplo carga las clases WebLogic. [Nota: fuera del contexto de Weblogic también puede denominarse Application ClassLoader]

Domain ClassLoader. Carga las clases alojadas en $DOMAIN_HOME/lib. Los ficheros .jar del $DOMAIN_HOME/lib no son añadidos al System ClassLoader sino que este Classloader es un CHILD del System Classloader es decir, las clases del System Classloader no tienen visibilidad sobre el Domain ClassLoader. Sí estarán disponibles dichas clases a todas las


24 de junio de 2019


aplicaciones desplegadas en Weblogic. [Nota: NO se recomienda usar el $DOMAIN_HOME/lib como método para compartir librerias]

Application ClassLoader. Carga las shared libraries referenciadas en

weblogic-application.xml, y las librerías alojadas en /APP-

INF/lib.

Web App ClassLoader. Carga las shared libraries referenciadas en

weblogic.xml y bajo WEB-INF/lib, y las clases bajo WEB-INF/clases.

Weblogic Server creará para cada una de las aplicaciones desplegadas un Application Classloader independiente, es decir no existe visibilidad entre las clases cargadas por una Aplicación A y las clases cargadas por otra Aplicación B.

Se recomienda que las aplicaciones que dispongan de JSP, servlets, aplicaciones web, ejbs y otros recursos, sean empaquetadas como ficheros .ear, para la creación de la jerarquía de classloader mostrada en la figura.

En este caso:

Weblogic crea automáticamente una jerarquía de classloader como el de la figura cuando se despliega la aplicación.

En este caso el Root ClassLoader son los .jar que carga la aplicación EJB

o Los .jar que carga las aplicaciones Web son CHILD del Root ClassLoader, es decir tendrán visibilidad de las clases ejb y dichas clases ejb tendrán preferencia al ser el padre.

o A su vez dentro de cada una de la aplicación Web, las JSP class tienen su propio classloader que es CHILD del WebApplication ClassLoader


24 de junio de 2019


Filtrado de clases en WebLogic Server

Adicionalmente existe un Filtering Clasloader. Este classloader permite el denominado classloader filtering, o lo que es lo mismo, alterar el modelo de delegación para cargar clases incluidas en la aplicación en lugar de cargar esas mismas clases mediante el system classLoader, en caso de que existiesen también a nivel de WebLogic Server.

Existen dos formas de configurar el classloader filtering en una aplicación web.

Mediante el tag <prefer-application-packages> en weblogic.xml, que permite a una aplicación web usar las librerias de terceros,

especificando ciertos paquetes, alojadas en WEB-INF/lib en lugar de las cargadas por WebLogic Server.

Mediante el tag <prefer-web-inf-classes>, que permite a una

aplicación Web utilizar sus propias clases incluidas en WEB-INF/classes

o WEB-INF/lib, en caso de que el WebLogic Server también cargase dichas clases. Este tag es un switch, y por tanto su valor solo puede ser

false (valor po defecto) o true.

Las dos opciones anteriores son excluyentes, de tal manera que si se pretende usar

<prefer-application-packages>, entonces el valor de <prefer-web-inf-

classes> debe ser false, y viceversa, si fijamos <prefer-web-inf-classes>

a true, entonces no podemos usar <prefer-application-packages>.

Además de hacerlo a nivel de aplicación Web, el classloader filtering puede

configurarse a nivel de aplicación Enterprise, incluyendo el tag <prefer-

application-packages> en weblogic-application.xml y las librerías que

queremos usar en /APP-INF/lib del fichero EAR.

Oracle recomienda usar <prefer-application-package> para configurar el classloader filtering, ya que ofrece un mayor nivel de granularidad.

Oracle WebLogic Server 12c dispone de una herramienta denominada CAT (ClassLoader Analisys Tool) para detectar posibles conflictos de clases. La herramienta se distribuye como una aplicación Web, y se encuentra bajo

$WL_HOME/server/lib/wls-cat.war. Una vez desplegada en el servidor de aplicaciones, se puede acceder a ella vía http://<host>:<port>/wls-cat

CAT es capaz de analizar los posibles conflictos y generar la correspondiente configuración para el FilteringClassLoader.

Best practices en el uso de librerías compartidas

En el epígrafe Classloader en Weblogic se ha indicado que no se use $DOMAIN_HOME/lib como método general para compartir librerías entre las aplicaciones desplegadas en Weblogic.


24 de junio de 2019


Oracle recomienda que se usen las Java EE libraries como método para compartir uno o más tipos de módulos Java entre las Enterprise Applications desplegadas en weblogic.

Las buenas prácticas a aplicar en el uso de librerías compartidas son:

Usa Java EE Libraries compartidas cuando se necesite compartir uno o más Java EE modules (EJBs, Web applications, enterprise applications, or plain Java classes) con múltiples Enterprise applications (.ear desplegados en Weblogic)

Si se necesita desplegar un módulo Java EE standalone, por ejemplo un EJB Jar, como librería compartida, empaquetar el módulo dentro de un .ear. Haciendo esto se evitan los potenciales conflictos de URI, puesto que el URI de la librería de un módulo standalone es derivado del nombre del despliegue.

Si se elige desplegar una librería compartida como un módulo Java EE standalone, especificar siempre un nombre de despliegue conocido durante el despliegue y usar ese nombre como el URI en las aplicaciones que lo referencian.

Usar optional packages cuando varios ficheros Java EE archive necesitan compartir un conjunto de clases Java.

Sólo en el caso que existan un conjunto de clases que tienen que estar disponibles a todas las aplicaciones desplegadas en el dominio, y dichas clases no sean actualizadas frecuentemente, usar el directorio /lib del dominio en lugar de librerías compartidas o optional packages. Las clases en el directorio /lib estarán disponibles a todas las aplicaciones desplegadas en el dominio.

Siempre especificar el specification version y el implementation version, incluso si no hay el requisito de forzar una versión en la aplicación. Especificando el versionado para las librerías compartidas se permite desplegar múltiples versiones de los ficheros compartidos para su testeo.

Siempre especificar un Extension-Name por cada Java EE Library compartida. Si no se especifica un extensión name, se generará uno del nombre del despliegue de la librería. Los nombres de despliegue por defecto son diferentes para despliegue archive y despliegues exploded.

Cuando se desplieguen Web Application como Java EE Library compartida, usa un único context root. Si el context root tiene conflictos con el context root de una Java EE application dependiente, usar el context-root en el descriptor de despliegue del EAR weblogic-application.xml para sobreescribir el context root de la librería

Empaquetar librerías compartidas como archive para producción. Puede usarse librerías desplegadas como exploded archive directores en las fases de desarrollo

Despliega librerías compartidas en todas las instancias Weblogic server en las que existan aplicaciones dependientes. Si una librería no existe en un servidor Weblogic en el que se despliega una aplicación dependiente el despliegue fallará.

oracle ibÉrica, s.r.l. junta de andalucia › kb › node › 2440 › ...las java server pages...

Documents