martes, 29 de octubre de 2013

Configuración del administrador de trabajo por defecto (default Work Manager) en WebLogic

Un caso muy usual durante la operación del servidor WebLogic consiste en mejorar el rendimiento y eficacia del servidor; Generalmente esto se necesita cuando se requiere un mejor tiempo de respuesta de las aplicaciones o para soportar una elevada carga de trabajo (cientos de peticiones por minuto).

Para solventar dicho requisito, es necesario realizar una afinación, no sólo del servidor WebLogic, sino también del Sistema Operativo, Red y, en algunos casos, de la Base de Datos utilizada por nuestra aplicación.

En el servidor WebLogic se pueden realizar varias tareas para mejorar el rendimiento del mismo, por ejemplo:
  • Ajustar parámetros de la Maquina Virtual de Java (JVM)
  • Ajustar nivel y tipo de registro (Logging)
  • Ajustar parámetros de orígenes de datos (DataSources), si existen
  • Ajustar la administración de trabajo, hilos y timeouts (WorkManager)
  • Ajustar sistema de Entrada/Salida (I/O System)
  • Entre otras.


En esta ocasión sólo hablaré de la administración de carga de trabajo y la configuración que podemos realizar para aprovecharlo. Con el ajuste del WorkManager se pretende principalmente lo siguiente:
  • Especificar el tiempo respuesta máximo que el servidor debería de tolerar.
  • Especificar la carga máxima de trabajo, es decir, cuantas peticiones  y/o clientes puede soportar por un tiempo.
  • Especificar el tiempo de espera máximo para la ejecución de una tarea, con el fin de liberar recursos y continuar con otras tareas.

La configuración del WorkManager la podemos aplicar de dos maneras:
  • Dentro de los archivos de despliegue de nuestra aplicación, resultando  efectivo sólo para esta aplicación. Este se denomina administrador de trabajo de aplicación (Application WorkManager)
  • Desde la consola de administración WebLogic, efectivo para una o más aplicaciones y/o recursos en el servidor. Este se denomina administrador de trabajo global (Global WorkManager)      

De manera nativa, cada dominio WebLogic  cuenta con un WorkManager por defecto, que se asigna a cada servidor manejado y al servidor de administración para  procesar el trabajo que deben ejecutar. También, por defecto este WorkManager no está visible en la consola de administración WebLogic.

Para mejorar el rendimiento del servidor WebLogic podemos sobre-escribir el WorkManager por defecto, para  ello hacemos lo siguiente:


  1. Entrar a la consola de Administración WebLogic con un usuario con privilegios de administrador.
  2. Crear un WorkManager con el nombre default, y asígnarlo a todos los servidores existentes en el dominio. Ver imagen 01.
  3. Entrar a la configuración del nuevo WorkManager y especificar los atributos del mismo, crear cada uno de ellos con los valores con los que pretendemos mejorar el rendimiento. Ver imagen 02.

          Por ejemplo:

Atributo
Tipo
Objetivo
Valor afinado
Request Class
Response Time Request Class
Mejorar el tiempo de respuesta.
500 milisegundos
Request Class
Fair Share Request Class
Mejorar el tiempo de respuesta.
75
Minimum Threads Constraint

Buena práctica
10
Maximum Threads Constraint

Soportar mayor carga de trabajo
200
Capacity Constraint

Soportar mayor carga de trabajo
100
Ignore Stuck Threads

Incrementar tolerancia a fallas
Habilitado

            Estos atributos deben tener el mismo destino que el WorManager.


Una vez guardado y activado los cambios, el WorkManager está listo. Todas las aplicaciones y recursos son atendidas por el mismo WorkManager por defecto, no obstante, ahora tiene nuevos valores para mejorar su rendimiento. 

Adicionalmente, podemos crear WorkManager personalizados y asignarlos a servidores específicos, en donde se busque un diferente rendimiento, claro, siempre será un mejor rendimiento.

En un ambiente productivo, se recomienda crear un WorkManager personalizado para una o más aplicaciones, o simplemente para una aplicación de misión crítica. Para que nuestras aplicaciones hagan uso de dicho WorkManager, es necesario incluir la referencia a éste en el descriptor de despliegue weblogic-application.xml, por ejemplo:

<?xml version = '1.0' encoding = 'windows-1252'?>
<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">
  …
  <work-manager>
    <name>MiWorkManager</name>
  </work-manager>
  …
</weblogic-application>

En este mismo descriptor se puede definir un WorkManager y todos sus atributos, que aplicarían sólo a esta aplicación.

Imagen 01.

Imagen 02.

lunes, 17 de junio de 2013

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

viernes, 7 de junio de 2013

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





viernes, 17 de mayo de 2013

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