Despliegue de un cliente Axis en WebLogic

Recientemente un cliente necesitaba consumir un servicio Web en Axis que adicionalmente está protegido con una política WSS4J (token x509), dada la no interoperabilidad con Oracle Web Service Manager para esta política se desarrolló una aplicación cliente que pudiera consumir el servicio. Ahora el desafío era hacer el deploy de dicha aplicación en Oracle WebLogic Server, esta aplicación estaría expuesta como servicio Web para que pudiese ser utilizada desde un proceso BPEL.

En este caso utilizamos JDeveloper para configurar nuestra applicación, es de gran ayuda para crear los descriptores de despliegue que se requieren. Los puntos clave para lograr el deploy son:

1. Dar prioridad a las librerias requeridas en el descriptor de despliegue weblogic.xml. Si no existe lo creamos dentro del directorio WEB-INF de nuestra web application.

<?xml version = '1.0' encoding = 'UTF-8'?>

<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                  xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"

                  xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">

  <container-descriptor>

    <prefer-web-inf-classes>true</prefer-web-inf-classes>

  </container-descriptor>

</weblogic-web-app>

2. Especifiar los paquetes que debe utilizar, en este caso los de Axis y no los de WebLogic, así como los parsers de XML requeridos por el mismo axis. Creamos o modificamos el descriptor weblogic-application.xml, por ejemplo:

<?xml version = '1.0' encoding = 'UTF-8'?>

<weblogic-application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                      xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-application http://www.bea.com/ns/weblogic/weblogic-application/1.0/weblogic-application.xsd"

                      xmlns="http://www.bea.com/ns/weblogic/weblogic-application">

  <xml>

    <parser-factory>

      <saxparser-factory>org.apache.xerces.jaxp.SAXParserFactoryImpl</saxparser-factory>

      <document-builder-factory>org.apache.xerces.jaxp.DocumentBuilderFactoryImpl</document-builder-factory>

      <transformer-factory>org.apache.xalan.processor.TransformerFactoryImpl</transformer-factory>

    </parser-factory>

  </xml>

  <prefer-application-packages>

    <package-name>org.w3c.dom.*</package-name>

    <package-name>org.xml.sax.*</package-name>

    <package-name>com.ctc.wstx.*</package-name>

    <package-name>com.sun.activation.*</package-name>

    <package-name>com.sun.org.apache.*</package-name>

    <package-name>oracle.core.lmx.*</package-name>

    <package-name>oracle.core.lvf.*</package-name>

    <package-name>oracle.jdbc.*</package-name>

    <package-name>oracle.jdbc.connector.*</package-name>

    <package-name>oracle.jdbc.driver.*</package-name>

    <package-name>oracle.jdbc.internal.*</package-name>

    <package-name>oracle.jdbc.oci.*</package-name>

    <package-name>oracle.jdbc.oracore.*</package-name>

    <package-name>oracle.jdbc.pool.*</package-name>

    <package-name>oracle.jdbc.util.*</package-name>

    <package-name>oracle.jdbc.xa.*</package-name>

    <package-name>oracle.jpub.runtime.*</package-name>

    <package-name>oracle.net.ano.*</package-name>

    <package-name>oracle.net.jndi.*</package-name>

    <package-name>oracle.net.ns.*</package-name>

    <package-name>oracle.net.nt.*</package-name>

    <package-name>oracle.net.resolver.*</package-name>

    <package-name>oracle.security.o3logon.*</package-name>

    <package-name>oracle.sql.*</package-name>

    <package-name>oracle.sql.converter.*</package-name>

    <package-name>org.apache.*</package-name>

    <package-name>org.springframework.*</package-name>

  </prefer-application-packages>

</weblogic-application>

3. Hacer el deploy de la aplicación (EAR) no del proyecto, para que se lleve el weblogic-application.xml. Y no olvidemos especificar que el empaquetado del proyecto (WAR) incluya las librerías requeridas.

4. Opcionalmente, si el servicio Web que va a consumir nuestro cliente esta protegido con WSS4J, registramos el proveedor de seguridad en el JDK que utiliza nuestro servidor WebLogic (esto requiere reiniciar el servidor).

     - Colocar la libreria bcprov-jdk15-132.jar en $JDK_HOME/jre/lib/ext

      - Modificar el archivo java.security localizado en $JDK_HOME/jre/lib/security. Agregar la clase org.bouncycastle.jce.provider.BouncyCastleProvider como provider. Por ejemplo:

security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider

     Con esta configuración evitamos el siguiente error:

org.apache.axis2.AxisFault: WSHandler: Encryption: error during message processingorg.apache.ws.security.WSSecurityException: An unsupported signature or encryption al

gorithm was used (unsupported key transport encryption algorithm: No such algorithm: http://www.w3.org/2001/04/xmlenc#rsa-1_5)

Aqui les dejos algunos sitios que me ayudaron a realizar el deploy:
http://techasilo.blogspot.mx/2007/04/call-to-web-service-has-become-nerve-of.html
http://blog.guident.com/2011/12/deploying-axis2-applications-on-oracle-weblogic-server/
http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/200609.mbox/%3c4e3ba4880609010756i59e0a5b6s12d875f0b2263c1f@mail.gmail.com%3e

Cambiar la versión de Java (JDK) en WebLogic

Algunas veces es necesario actualizar o cambiar la versión de Java (JVM - JDK) que actualmente tenemos instalado. Podemos hacer este cambio ya sea para toda la instalación del software que tiene como raíz nuestro Middleware Home o simplemente para un dominio WebLogic.

Voy a presentar el procedimiento que se realizo para cambiar la versión del JDK 1.6 a la 1.7 de una instalación WebLogic y que además cuenta con Oracle SOA Suite, Oracle Service Bus.

En este escenario tenemos dos servidores de aplicación, soahost1 y soahost2, aprovisionados con:

WebLogic Server 11g

Oracle SOA Suite con Oracle Service Bus 11g

$MW_HOME representa nuestro Middleware Home.

1. Parar todos los servicios, tanto en los servidores de aplicación como en el servidor Web.

a.       Node Manager

b.      Servidores Manejados

c.       Servidor de Administración

2. Actualizar el archivo commEnv.sh con la ruta del JDK 1.7

$MW_HOME/wlserver_10.3/common/bin/commEnv.sh

3. Actualizar el archivo setDomainEnv.sh de nuestros dominio(s) WebLogic.

$MW_HOME /user_projects/domains/soa_domain/bin/setDomainEnv.sh

4. Opcionalmente y para ser consistente actualizamos el archivo nodemanager.properties de nuestros Node Managers.

$MW_HOME /wlserver_10.3/common/nodemanager/nodemanager.properties

5. Iniciar los servicios

6. Comprobar que se ha tomado la nueva versión de Java, revisamos los logs

Importar certificados en WebLogic

Una tarea administrativa muy común es la de importar certificados digitales en el servidor WebLogic para comunicarse con otros sistemas utilizando un medio de comunicación seguro, en este caso a través del protocolo SSL.

Esta tarea se convierte en obligatoria cuando tenemos una aplicación que necesita consumir una aplicación o servicio externo, ya sea que se encuentre en otro servidor WebLogic, o cualquier otro servidor de aplicaciones.  Normalmente, para tener acceso a estas aplicaciones remotas utilizamos el protocolo HTTPS, lo cual es una versión del protocolo HTTP con soporte del protocolo SSL.

En esta entrada voy a ejemplificar como importar un certificado en el servidor WebLogic para que pueda conectarse al sistema de ElasticEmail, el cual requiere una comunicación con HTTPS. ElasticEmail está disponible en la siguiente URL https://api.elasticemail.com.

Pre-requisitos

• Cuenta de usuario administrador WebLogic
• Acceso a la utilería openssl
• Acceso a la utilería keytool

Procedimiento

1. Existen distintas formas y medios para obtener el certificado de un sistema/servidor, desde un navegador Web (Internet Explorer, Google Chrome, etc) hasta programas dedicados como openssl. En este caso voy a utilizar openssl para crear una conexión ElasticEmail:

-bash-3.2$ openssl s_client -connect api.elasticemail.com:443

2. Ubicar el certificado, delimitado por las cadenas -----BEGIN CERTIFICATE----- y -----END CERTIFICATE-----

Por ejemplo:

3. Copiar y pegar el certificado en un archivo

-bash-3.2$ vi elastic-email.crt

4. En este ejemplo voy a utilizar la utilería keytool del JDK de java para importar el certificado generado en el paso anterior en el keystore de confianza (trust keystore) del servidor WebLogic:

keytool -import -v -trustcacerts -alias elastic-email  -file elastic-email .crt -keystore /opt/oracle/middleware/wlserver_10.3/server/lib/DemoTrust.jks  -storepass DemoTrustKeyStorePassPhrase

Nota: Para efectos de ejemplo, el certificado se importa en el keystore demo del servidor WebLogic. En su ambiente productivo importelo en su propio trust keystore.

5. Finalmente, se debe reiniciar el módulo SSL del servidor WebLogic, o en su defecto reinicar todo el servidor Weblogic en donde se encuentra la aplicación que requiere conectarse a ElasticEmail.

En mi experiencia, en algunos casos ha sido necesario agregar el certificado al keystore del JDK, me refiero al archivo cacerts que se encuentra en $JAVA_HOME/jre/lib/security. Esto ah sido necesario en certificados como los de Google. En este caso podemos usar:

keytool -import -v -trustcacerts -alias elastic-email  -file elastic-email .crt -keystore  $JAVA_HOME/jre/lib/security/cacerts  -storepass changeit

Configuración de dominio WebLogic (1a Parte)

En esta entrada voy a ejemplificar la creación de un dominio WebLogic. Vamos a considerarlo un dominio básico debido a que no vamos a utilizar recursos que conllevan una configuración más compleja y avanzada, como un cluster WebLogic. Sin embargo, este ejemplo puede ser útil aún para un ambiente productivo.

En un ambiente productivo es recomendable que el dominio WebLogic cuente con al menos un servidor manejado (Managed Server) en el que se realice el despliegue de las aplicaciones, dejando al servidor de Administración únicamente con tareas administrativas. Otras recomendaciones son:

• Configurar el dominio en modo producción (Production mode).
• Asignar la dirección IP o hostname a cada instancia WebLogic (una instancia es un servidor de administración o un servidor manejado), es decir, no dejar en blanco este valor de lo contrario el servidor utilizará todas las direcciones disponibles, consumiendo recursos innecesarios.
• Deshabilitar los puertos planos (puertos que utilizan el protocolo SSL).
• Cambiar la cuenta de administración por default (weblogic).
• Cambiar puertos por default, etc.

Antes iniciar la creación del dominio nos aseguramos de que tenemos definidos y disponibles los siguientes recursos:

• Dirección IP para el servidor de administración.
• Si es posible, una dirección IP para el servidor manejado, de lo contrario se utiliza la anterior.
• 4 puertos, por los cuales las aplicaciones estarán disponibles.

Nota: Utilizo Xming server para poder exportar el display del servidor linux a mi maquina Windows, desde donde realizo la configuración de forma remota.
Nota: No olvidemos verificar que a nivel de sistema operativo los puertos estan abiertos para comunicación TCP.

Voy a seguir el procedimiento gráfico, debido a que es mas sencillo y comprensible, éste consiste en lo siguiente:

1. Ejecutar el asistente de configuración de dominio "Configuration Wizard". Este asistente lo corremos con el script config.sh que se localiza dentro de la instalación WebLogic, Middleware Home, en el subdirectorio wlserver_10.3/common/bin. Por ejemplo:

/opt/oracle/mw/wlserver_10.3/common/bin/config.sh

2. Crear un dominio WebLogic nuevo.

3. Seleccionar características especiales para nuestro dominio. En este caso selecciono la opción para dar soporte a mecanismos avanzados para Servicios Web basados en JAX-WS, como el soporte de la política WS-ReliableMessaging.

 Nota: Si nuestras aplicaciones no requieren de estas características no seleccionamos ninguna opción.

4. Mientras nuestra empresa no tenga ninguna política que nos obligue a darle un nombre en especifico a nuestro dominio, podemos darle cualquiera. Proporcionamos la ruta donde se instalará el dominio (DOMAIN_HOME).

5. Cambiamos el nombre de la cuenta de administración inicial.

6. Configuramos el dominio en modo Production. En este modo el servidor habilita otras políticas,  más que en development, para proteger los recursos internamente; También proporciona una mayor cantidad de subprocesos para resolver la carga de trabajo, etc.

7. Seleccionamos las casillas para la personalización de las instancias WebLogic (servidor de administración y servidor manejado).

8. Cambiamos los puertos por defecto del servidor de administración y asignamos IP/hostname para evitar que abra puertos por direcciones no deseadas y evitar desperdicio de recursos.

9. Creamos servidor manejado para el despliegue de las aplicaciones. Asignamos dirección y puertos.

10. Dejamos en blanco la configuración de Clusters.

11. Creamos una maquina (machine) para asociarla al servidor manejado, y también al servidor de administración, considerando que sólo contamos con un equipo de computo y no es necesario más de 1 maquina, ambos servidores correran en el mismo sistema. Definimos la dirección IP y puerto que utilizará el node manager de la maquina para comunicarse con los servidores WebLogic.

 12. Asignamos servidores WebLogic a la maquina.

13. Revisamos el resumen de configuración.

14. Esperamos la ejecución del asistente.

15. Cerramos el asistente. La configuración a concluido correctamente.

En este momento se ha creado un dominio WebLogic con un servidor manejado dedicado para el despliegue de aplicaciones. Aún no hay nada funcionando, para echar andar el dominio el primer paso es iniciar el servidor de administración.

Iniciamos el servidor de administración con el script startWebLogic.sh que se encuentra en el subdirectorio bin del DOMAIN_HOME. Por ejemplo:

1) $./opt/oracle/mw/user_projects/domains/jupiter_domain/bin/startWebLogic.sh

 
    El proceso no se envía a segundo plano, podemos agregar un & al final del comando para correr el proceso en background.
2) Proporcionamos usuario y password administrador.

El código de mensaje BEA-000360 nos indica que el servidor ha iniciado correctamente y se encuentra en ejecución.

Para evitar introducir el usuario y password la próxima vez, creamos el archivo boot.properties en el directorio home del servidor de administración que se ubica en DOMAIN_HOME/servers/AdminServer,  por ejemplo:

Ahora, iniciamos el servidor manejado con el script startManagedWebLogic.sh, ubicado en el mismo directorio que startWebLogic.sh. Por ejemplo:

1) $./opt/oracle/mw/user_projects/domains/jupiter_domain/bin/startManagedWebLogic.sh jupiter1  http://10.1.120.50:22701

El proceso no se envía a segundo plano, podemos agregar un & al final del comando para correr el proceso en background.

2) Introducimos usuario y password. Posteriormente podemos aplicar el mismo procedimiento para generar el boot.properties para este servidor.

3) El código de mensaje BEA-000360 nos indica que el servidor ha iniciado correctamente y se encuentra en ejecución.

Finalmente, para comprobar la disponibilidad de los servidores WebLogic, ingresamos a la consola de administración WebLogic Server.

1. Abrimos un explorador Web y vamos a la URI http://direcciónIP:puerto/console. Dirección IP y puerto se refieren a las del servidor de administración.

2. Clic en link Servidores
3. Checamos el status de los servidores de administración y nuestro servidor manejado jupiter1, listo para el despliegue de aplicaciones.

Hasta aquí tenemos un nuestro dominio WebLogic listo para deployar aplicaciones, de ahora en adelante nuestro trabajo consiste de tareas que garanticen el buen funcionamiento, rendimiento y desempeño, del servidor de administración y principalmente, del servidor manejado; Así como de tareas que garanticen la correcta administración y mantenimiento del dominio.

En nuestra próxima entrada voy a presentar un procedimiento para la configuración del node manager que nos facilite la administración del ciclo de vida de los servidores WebLogic; iniciar, detener y reiniciar los servidores WebLogic son tareas que automáticamente el node manager puede llevar a cabo.

Instalación de WebLogic Server

En esta entrada voy a mostrar una forma de instalar el servidor de aplicaciones WebLogic. Antes de iniciar la instalación es recomendable verificar que nuestro equipo de computo cuenta con el hardware y software suficiente, desde mi punto de vista para un ambiente de desarrollo la lista de requisitos sería como la que sigue:

• Memoria RAM de 2 GB o más
• Uno o más CPUs (cores) a 1.2 GHz o más
• Espacio de almacenamiento, local o externo, mínimo de 10GB
• En el siguiente link podemos encontrar la matriz de certificación y determinar si nuestro Sistema Operativo (SO) esta soportado por el producto. 
• Oracle Fusion Middleware Supported System Configurations
• Para este caso utilizamos Linux Red Hat 5.5 con arquitectura de 64bits.
• Para este ejemplo utilizamos Oracle WebLogic Server 11gR1, WebLogic Server 10.3.6. El software lo podemos descargar de:
• OTN - WebLogic Downloads
• e-delivery. 
• Para nuestro caso descargamos el software compatible para plataformas de 64 bits, normalmente denominado como "generic" bajo la etiqueta Additional Platforms.
• Importante: Dada la arquitectura x86_64 requerimos descargar e instalar de manera indepediente el JDK de Java,  el software de WebLogic para esta arquitectura no contiene el instalador de éste JDK y por defecto RHL instala una versión antigua de Java la cual no nos sirve. En el siguiente link podemos descargar el JDK de Java más reciente y soportado por el producto.
• Java SE downloads
• Ejemplos de instalación del JDK aqui o aqui

El JDK de Java debe ser instalado antes de WebLogic Server. Podemos realizar la instalación en diferentes tipos: gráfico, console y silent. Para nuestro caso utilizaremos el modo gráfico por su sencillez, facilidad y por estar acostumbrados a ver ventanas, en cualquiera de los casos ni una u otra opción agrega un valor adicional.

Una vez que descargamos el software al equipo donde se desea instalar y verificamos los requisitos procedemos a la instalación con algún usuario, en este ejemplo utilizo el usuario oracle, el cual no requiere privilegios especiales, sin embargo es importante definir un directorio donde se hará la instalación del software y asignar al usuario oracle como propietario de éste. 

Nota: Utilizo Xming server para poder exportar el display del servidor linux a mi maquina Windows, desde donde realizo la instalación de forma remota.

Los pasos para la instalación son:

1. Ejecutar instalador, por ejemplo: 

/opt/oracle/java/jdk1.6.0_31/bin/java -jar wls1036_generic.jar

2. Definir el repositorio central para la instalación de WebLogic Server, se denomina "Middelware Home Directory" y le damos el valor del directorio definido para este proposito /opt/oracle/mw/ 

3. Opcionalmente proporcionamos nuestra credencial de My Oracle Support para registrar nuestra instalación en este servicio.  

4. Seleccionar el tipo de instalación para identificar los componentes a instalar.

5. Para un ambiente productivo eliminamos los ejemplos y la base de datos de evaluación, no debería de ser necesarios, lo contrario a un ambiente de desarrollo donde pueden ser útiles.

6. Confirmar el JDK que se utilizará para nuestra instalación.

7. A mi recomendación, dejar intactos las rutas de instalación de los componentes.

8. Clic Next y esperar a que se ejecute la instalación.

9. Cerrar el asistente, la instalación ha concluido correctamente.

En este punto tenemos instalado Oracle WebLogic Server, ¿Que sigue? 

Ahora requerimos crear un dominio WebLogic, donde se generan los recursos para el despliegue de las aplicaciones Java, donde realmente comienza a trabar el poder WebLogic.

En mi próxima entrada les mostrare un ejemplo para crear un dominio WebLogic.

Referencias

Guía de Instalación Oficial