18
Sep

Alta Disponibilidad de Sesiones con Managed Servers en Cluster en WebLogic 12c

Las sesiones que crean nuestras aplicaciones son muy importantes, perderlas no es una opción y más cuando se están manejando compras o alguna otra transacción que implique algún monto monetario. Es necesario tener alta disponibilidad de estas sesiones. Oracle WebLogic posee una característica cuyo concepto ya es muy conocido: Un Cluster.


Cada aplicación dentro de WebLogic Server está alojada en un contenedor llamado Managed Server el cual es una analogía con el ya descontinuado OC4J del antiguo OAS. Si el Managed Server se caé, la aplicación dejaria de ser accesible para nuestros clientes o usuarios, lo cual en muchas empresas no puede suceder, siempre hay aplicaciones críticas, que deben estar disponibles. En WebLogic tambien se maneja el concepto “Machine”, el cual no es más que la representación lógica de un servidor físico. Un Managed Server es asignado a un “Machine” y finalmente un “Cluster” es compuesto por uno o más Managed Servers alojados en uno o más “Machines”.


A continuación la definición que oracle dá a cada uno de estos conceptos:

Administration Server: The Administration Server operates as the central control entity for the configuration of the entire domain. It maintains the domain’s configuration documents and distributes changes in the configuration documents to Managed Servers. You can also use the Administration Server as a central location from which to monitor all resources in a domain.


Managed Server: Managed Servers host business applications, application components, Web services, and their associated resources. To optimize performance, Managed Servers maintain a read-only copy of the domain’s configuration document. When a Managed Server starts up, it connects to the domain’s Administration Server to synchronize its configuration document with the document that the Administration Server maintains.


Cluster: A cluster is a collection of multiple Oracle WebLogic Server instances running simultaneously and working together to provide increased scalability and reliability.


Por lo tanto si tenemos una aplicación desplegada en nuestro cluster, automaticamente se alojará en cada uno de los Managed Servers que componen ese cluster logrando así Alta Disponibilidad, de tal manera que si un Managed Server se caé, los demás Managed Servers involucrados en el mismo cluster tomarán las sesiones y las seguiran manteniendo disponibles.

En este ejemplo crearemos un Dominio con un cluster compuesto de dos Managed Servers.


Las variables de entorno que debemos definir antes de iniciar el ejemplo son las siguientes:


JAVA_HOME= /usr/jrockit/jrockit-jdk1.6.0_33-R28.2.4-4.1.0

MW_HOME= /u02/Middleware

WLS_HOME= /u02/Middleware/wlserver_12.1/


Primero debemos ejecutar el Asistente de Configuración de Dominios, “config.sh” el cual se encuentra en el $WLS_HOME/common/bin


$cd $WLS_HOME/common/bin

$./config.sh


En la pantalla de bienvenida seleccionar la opcion “Create a new WebLogic domain“.



En la pantalla de “Select Domain Source”, seleccionar la opcion “Generate a domain configured automatically to support the following products“. Luego dar clic en el boton Next.


Escribir el nombre del dominio, y la ruta en donde se crearán todos los archivos necesarios. Luego dar clic en el boton Next.


Especificar el usuario Administrador de nuestro dominio, su contraseña y una pequeña descripción del rol que desempeña. Luego dar clic en el boton Next.




Para nuestro ejemplo seleccionaremos la opcion “Development Mode” y Seleccionamos nuestro JDK, que en este ejemplo es UnJrockit 1.6.0_33. Clic en el boton Next.



Seleccionamos las opciones “Administration Server” y “Managed Servers, Clusters and Machines”. Pues vamos a configurar la “machine”, el cluster y sus respectivos Managed Servers. Clic en el boton Next.



Ingresamos el Nombre de nuestro “Administration Server”, la direccion en la que escuchará, el puerto y si usará algun puerto seguro. Para nuestro ejemplo unicamente especificamos los primeros tres campos: Name, Listen Address y Listen Port. Clic en el boton Next.



Creamos dos Managed Servers, uno con nombre “myserver_1” y el otro con nombre “myserver_2”, escuchando el puerto 8001 y el 8002 respectivamente. No usan conexion segura. Clic en el boton Next.



Cree un Cluster de nombre “mycluster” con modo de mensajes “unicast”. Clic en Next.




Agregar nuestros dos Managed Servers (myserver_1, myserver_2) al cluster “mycluster”.  Clic en el boton Next.




Crear una “Machine” de nombre “mymachine” que escuche todas las direcciones y que use el puerto 5556. Clic en el boton Next.



Agregar todos nuestros Managed Server incluido el Administration Server a nuestra Machine “mymachine”. Clic en el boton Next.


Confirmar todos los datos y finalmente clic en el boton “Create” para que la creacion de nuestro dominio sea creado con una machine, un cluster con dos managed servers y un administration server.


Cuando la creación del dominio finalice, verificar que no haya terminado con errores y finalmente clic en el boton “done”.



Una vez creado el dominio, levantamos nuestro Administration Server, para realizar esto debemos  realizar lo siguiente:


$cd $MW_HOME/user_projects/domains/test_domain

$./startWebLogic.sh &



Cuando nuestro Administration Server esté arriba, debemos levantar nuestro Node Manager, el cual es el encargado de comunicarse a los Managed Server y así poderlos subir desde la consola de administración web. Para levantar el Node Manager debemos ejecutar los siguientes pasos:


$cd $MW_HOME/wlserver_12.1/server/bin

$./startNodeManager.sh &



Una vez hecho esto, entramos a la consola de administración web mediante la url:


http://hostname:7001/console


Ingresamos el usuario y la contraseña de nuestro usuario administrador del dominio, tal como se muestra en la siguiente imagen:


Despues de registrarnos correctamente, iremos al panel de “Estructura de Dominio” que queda en la parte izquierda y seguiremos los siguientes pasos:
  1. Clic en Entorno
  2. Clic en Servidores
  3. Clic en la pestaña Control
  4. Seleccionar los Managed Servers myserver_1 y myserver_2.
  5. Clic en el botón “Iniciar”.

Para poder demostrar la alta disponibilidad que brinda un cluster, usaremos una aplicación ya precreada cuyo objetivo es almacenar “productos” dentro de un “carrito” e irlo guardando en una nueva sesión. Esta aplicación ya está empaquetada como un archivo “.ear” y está situado en el directorio /home/oracle de mi maquina.



Procedemos a realizar “deploy” de esta aplicación.

Dentro de la consola de administración web seguimos los siguientes pasos:

1.  Clic en Desplieges 
2.  Clic en “Instalar”


3.  Ingresamos el directorio “/home/oracle” en el campo “ruta de acceso” y elegimos la          aplicación “shoppingcart.ear”. Luego clic en el botón Siguiente.


4.  Clic en “Instalar Despliegue como Aplicación”. Clic en el botón Siguiente.


5.  Clic en “mycluster” para que la aplicación sea desplegada en “Todos los servidores del Cluster”. Clic en el botón Siguiente.

6.  Clic en “Copiar aplicación en cada uno de mis destinos” del menú “Accesibilidad de Origen”. Clic en el botón Siguiente.


7.  Clic en “No, revisaré la configuración más tarde” del menú “Configuracion adicional”. Clic en el botón Finalizar.


8.  Activar los cambios de la sesión y luego Iniciar la aplicación “Sirviendo todas las solicitudes”.


Ahora entramos a nuestra aplicación web por medio del primer managed server (myserver_1) mediante la siguiente dirección:


http://hostname:8001/shoppingcart/


Al entrar a la aplicación empezaremos a comprar productos:




Estos productos van guardándose en nuestro “Carrito” por medio de la creación de una “sesión”.


Si entramos a ver nuestro carrito aparecen los productos que hemos agregado:


Ahora Bajamos un Managed Server “myserver_1” para simular que hubo una caída del mismo, para eso entramos nuevamente a la consola de administración Web y seguimos los siguientes pasos:
  1. Clic en Entorno
  2. Clic en Servidores
  3. Clic en la pestaña Control.
  4. Seleccionamos el Managed Server “myserver_1”.
  5. Clic en el botón “Cerrar” y luego en la opción “Forzar Cierre Ahora”.

Y como vemos el Managed Server “myserver_1” ya esta apagado:



Ahora la sesión tendría que ser retomada por el Managed Server “myserver_2”  por lo cual la sesión no se perdería y también la aplicación seguiría estando disponible para todos mis usuarios o clientes.


Volvemos a entrar a nuestra aplicación web por medio del segundo Managed Server (myserver_2):


http://hostname:8002/shoppingcart/


Vuelvo a entrar a ver los productos que mi carrito lleva recaudado y vemos que los productos que ya había comprado aún siguen en el carrito, y con esto confirmamos que la sesión no se perdió y que la aplicación sigue estando disponible gracias al Cluster de Managed Servers que hemos creado.




Facebooktwitterlinkedinmailby feather
16
Sep

Oracle WebLogic 12c versión Dev

Para instalar Weblogic 12 no necesitamos tener la instalación completa, Oracle tiene una versión más liviana dedicada únicamente para ambientes de pruebas. Esta versión es de aproximadamente 183MB. La pueden descargar en la siguiente dirección:

El  archivo está bajo la categoría Zip distribution with Oracle WebLogic Server only and intended for WebLogic Server development only.

El archivo se llama: Zip distribution for Mac OSX, Windows and Linux.

Tener un ambiente Weblogic es muy facil y rápido con ayuda de este Zip, prácticamente se resume a la siguiente frase: “Descomprima y uselo”.

El servidor que estoy usando para este ejemplo tiene las siguientes características:

Sistema Operativo: Oracle Linux 5.7 64 bits.

Memoria RAM: 2GB

Espacio en Disco: 10GB

Version de java: JDK 1.6.0_34

A continuación una imagen con las características:



El zip que descargamos desde el sitio de oracle lo hubicamos en “/home/oracle”, debe tener permisos para el usuario oracley el grupo oinstall.

En la imagen podemos apreciar que el archivo se llama “wls1211_dev.zip”.

Se debe copiar el archivo wls1211_dev.zip al directorio que será nuestro “Middleware Home”, para este ejemplo se utilizó el directorio “/u01/Middleware”.

cp wls1211_dev.zip /u01/Middleware

Despues de haberlo copiado a nuestro Middleware Home, debemos establecer las variables de entorno necesarias: JAVA_HOME, PATH, MW_HOME.

Las variables para este ejemplo se establecieron a los siguientes valores:

export JAVA_HOME= /usr/java/jdk1.6.0_34      

export PATH=$JAVA_HOME/bin:$PATH

export MW_HOME=/u01/Middleware

Se aconseja que estas variables se establezcan en el archivo “.bash_profile” del usuario oracle para que sus valores queden permanentemente.

Luego de esto debemos de hacer el paso mágico, el paso considerado el más difícil de la instalación de WebLogic 12c versión Dev: =)

unzip wls1211_dev.zip


Una vez el archivo haya terminado de descomprimirse, se podrá ver que en el directorio Middleware Home se habran creado varios archivos, tal como lo muestra la siguiente imagen:



Ahora solo nos falta ejecutar el archivo que configura nuestra instalación:

$./configure.sh

Al terminar la ejecución del script, la terminal se verá como la siguiente imagen:




Cuando lleguemos a este paso ya tendríamos “instalado” nuestro WebLogic 12c para pruebas.

Ahora procederemos a crear un pequeño dominio para poder realizar deploy de nuestras aplicaciones.

Primero debemos establecer todas nuestras variables de nuestro ambiente middleware, para esto solo es necesario ejecutar el archivo setWLSEnv.sh hubicado en $MW_HOME/wlserver/server/bin, tal como lo muestra la siguiente imagen:




Oracle recomienda tener un directorio fuera al Middleware Home para alojar nuestros dominios, por lo que seguiremos esta recomendación y crearemos una carpeta en /home/oracle la cual alojará nuestro dominio.

mkdir –p /home/oracle/mydomain

cd /home/oracle/mydomain

Y crearemos el AdminServer, para esto debemos ejecutar la siguiente linea:


$java $JAVA_OPTIONS -Xmx1024m -XX:MaxPermSize=128m –Dweblogic.management.allowPasswordEcho = trueweblogic.Server

 A continuación una imagen en la que se muestran esos pasos:



El parámetro “-Dweblogic.management.allowPasswordEcho=true” se pone para evitar el error “Native library(terminalio) to read password securely from commandline not found” provocado por el bug 9094115.

Despues de ejecutar el weblogic.Server, nos aparecerá el siguiente mensaje:

No config.xml was found.

Would you like the server to create a default configuration and boot? (y/n)

Escribir “y” y luego [Enter].




nos pedirá el usuario y la contraseña con que se accederá a la consola de Administración Web. Para nuestro ejemplo, usaremos el usuario weblogic y la contraseña manager1


Finalmente veremos a nuestro AdminServer estar en RUNNING MODE.




Ahora solo nos hace falta entrar a la consola de administración web y logearnos con el usuario “weblogic”, mediante la siguiente ruta:


http://:7001/console




Facebooktwitterlinkedinmailby feather
14
Sep

Procesos muy largos en Weblogic son terminados de manera forzada

A veces nos podemos encontrar con que algunas de nuestras aplicaciones o WebServices que a simple vista  funcionan correctamente, son terminados de manera forzada por el servidor de WebLogic. Vuelven a revisar la aplicacion o WS y comprueban que está correcto. Pues sí, posiblemente el problema no sea la aplicación o WS, sino una mala configuración de los parámetros del WebLogic Server.

WebLogic Server posee la capacidad de poder detectar procesos “estancados”, estos procesos estancados son los que llevan mucho tiempo en estar ejecutandose (no en estar ociosos), sin embargo, despues de un largo tiempo no retornan una respuesta. WebLogic no sabe si en realidad el proceso que está ejecutando es muy largo o está estancado, y la decision que toma es categorizarlo como un “proceso estancado”. Luego de detectarlo, toma la decision de finalizarlo de manera forzada y así es como nuestra aplicación o WS termina abruptamente.

Lo bueno de tener herramientas de Oracle, es que “casi” todo es totalmente personalizable. Existen dos parametros que pueden ser afinados para poder detectar los procesos “estancados”. Se puede cambiar el intervalo de tiempo en que es monitoreado todos los procesos que se están ejecutando, y también se puede cambiar el tiempo que debería llevar ejecutandose un proceso antes de poder ser categorizado como “proceso estancado”.

Para poder cambiar estos parámetros debemos seguir lo siguiente:

  1. Logearse en la consola web del WebLogic Server.
  2. Clic en Environment.
  3. Clic en Servers.
  4. Clic en el ManagedServer en que está deployada nuestra aplicacion o nuestro WS.
  5. Clic en la pestaña Configuration.
  6. Clic en la sub pestaña “Tuning”.
Estando ahi los parámetros que debemos modificar son:

  • Stuck Thread Max Time: El tiempo que un proceso deberia llevar ejecutandose (no ocioso) para poder ser categorizado como un “proceso estancado”.
  • Stuck Thread Timer Interval: A cada cuanto tiempo se debería monitorear los procesos en ejecución para detectar “procesos estancados”.

A continuación una imagen donde se puede ver estos parámetros:

Adicionalmente a estos parámetros existe uno más. Este puede ser encontrado de la siguiente manera:

  1. Logearse en la consola web del WebLogic Server.
  2. Clic en Environment
  3. Clic en Servers
  4. Clic en la pestaña “Configuration”.
  5. Clic en la sub pestaña “Overload”
Ahi podemos encontrar el parámetro Stuck Thread Count el cual indica el número de “procesos estancados” que ese ManagedServer debería de tener antes de poder pasar a un estado de “FAILED”.

Recuerde reiniciar el Server despues de realizar algun cambio en estos parámetros.

Facebooktwitterlinkedinmailby feather
13
Sep

Recuperación a Desastres para un ambiente SOA

Para tener un ambiente altamente disponible debemos considerar la construcción de un DRS (Disaster Recovery Site) el cual nos proporciona ventajas como, preservar cada una de las transacciones que se realizan en nuestro ambiente de producción, protegiéndonos ante desastres naturales, virus, fallas de hardware, errores de software, o errores de usuarios; facilidad al  realizar una recuperación desde el sitio de producción o desde el sitio de contingencia; facilidad para realizar mantenimientos de ambientes completos con ayuda de un switchover.

Idealmente el sitio de contingencia debe ser construido geográficamente muy lejos, otro país.

Para poder crear un DRS para un ambiente SOA, debemos considerar los siguientes puntos:

  • El punto de acceso de los clientes a nuestro ambiente SOA.
  • Estructura de Directorios idénticos entre el sitio de producción (SITE-1) y el sitio de continencia (SITE-2), puntos de montaje, tamaño de discos, permisos, hostname, misma versión de sistema operativo, misma version de software de Middleware, etc.
  • Replicación de Archivos binarios y archivos de configuración del Middleware.
  • Replicación de la data transaccional de nuestra base de datos.
El acceso a los clientes hacia nuestro ambiente SOA debe ser lo más transparente posible ante un desastre, es decir, inicialmente los clientes van a estar conectándose a nuestro ambiente de producción (SITE-1) pero cuando ocurra un desastre se deberán conectar a nuestro ambiente de contingencia (SITE-2), este cambio debe ser lo más rápido y transparente.

A continuación se muestra una imagen en la que se  ve como estaría la configuración en un inicio.

  • Los clientes se conectan al sitio de producción (SITE-1).
  • La base de datos está replicando la data al sitio de contingencia (SITE-2).
  • Los binarios y los archivos de configuración del Middleware se están replicando hacia el sitio de contingencia (SITE-2).

Es necesario dejar claro que la replicación de los binarios y archivos de configuración es a través de mirroring entre los discos que utiliza el Middleware, mientras que la replicación de la data de nuestra base de datos es por medio de los “archived logs” generados por la base de datos de producción, enviados a la base de datos de contingencia y luego aplicados a esta última. La replicación de la base de datos se hace por medio de “Data Guard” y la configuración es llamada “Physical Standby”, para saber cómo crear una configuración de éste tipo pueden visitar el siguiente enlace:

http://docs.oracle.com/cd/B19306_01/server.102/b14239/create_ps.htm#i63561

Cuando ocurra un desastre (Failover) o se necesite realizar un mantenimiento planificado (Switchover), se deberá cortar la sincronización SITE-1->SITE-2 tanto de los binarios y archivos de configuración del middleware, como la sincronización de nuestra base de datos. Se deberá cortar la conexión de los usuarios hacia el sitio de producción (SITE-1) y redireccionarlos hacia el sitio de continencia (SITE-2) tal como se ve en la siguiente imagen:

Una vez el sitio de contingencia ya esté activado y los clientes estén debidamente redireccionados a éste nuevo sitio, la configuración quedaría de la siguiente manera para un Switchover (Mantenimiento planificado):

El SITE-2 será el ambiente de producción y el SITE-1 pasará a ser el ambiente de contingencia, la replicación seguirá realizándose, solamente que ahora en dirección inversa: desde el SITE-2->SITE-1. Por lo tanto todos los cambios que se estén realizando en el nuevo ambiente (SITE-2) no se estarían perdiendo, pues el SITE-1 se estaría sincronizando.

La siguiente imagen demuestra como quedaría la configuración:

Si se tratara de un Failover, se estaría asumiendo que el SITE-1 estaría completamente perdido. Los clientes estarían conectándose al SITE-2 y ya no habría replicación de binarios y archivos de configuración del Middleware, tampoco de la data de nuestra BD.

La configuración después de un failover quedaría como muestra la siguiente imagen:

Para más información sobre recuperación a desastres para un ambiente Middleware porfavor visite el siguiente enlace de oracle:

http://docs.oracle.com/cd/E23943_01/doc.1111/e15250/toc.htm

Facebooktwitterlinkedinmailby feather
12
Sep

TOGAF: The Open Group Architecture Framework

Togaf es una forma de llevar a la realidad el concepto SOA en nuestra empresa. Cada una de las fases de togaf se repiten durante todo los procesos pilotos hasta que finalmente la empresa llegue a obtener un completa arquitectura orientada a servicios.

En la fase A nos debemos de hacer la siguiente pregunta: ¿Como deberia de ser nuestra empresa una vez tenga una Arquitectura Orientada a Servicios?

En la fase B se trata de entender los procesos de negocio, se debe tener los procesos muy bien documentados.

En la fase C se analizan las aplicaciones que la empresa ya posee, qué funcionalidades tienen, qué datos recibe?, qué datos devuelve?, etc.

En la fase D se analizan todo el hardware que se tiene, servidores, cuanta ram poseen?, cuantos procesadores poseen?, en donde están fisicamente estos servidores?, cuales son sus ips? cuando espacio poseen? etc.

En la fase E, se detectan las posibles oportunidades y  algunos servicios a construir, estos servicios deben ser debidamente priorizados dependiendo las necesidades del negocio.

En la fase F, se trata el plan de cómo se va a llevar a la realidad lo que se hizo en la fase E.

En la fase G, se construye un comite, el cual se encargará de contestar preguntas como: ¿Quien debe construir los servicios?, ¿Quien puede consumir los servicios? ¿Quien debe pagar por los servicios?, ¿Cuando se deben construir nuevos servicios? etc.

En la fase H, se implementa un proyecto piloto con herramientas como BPEL, Oracle Service Bus, Weblogic, Enterprise Repository, Service Registry, etc.

Cada una de estas fases se vuelven a repetir para los “N” proyectos pilotos que la empresa desee.

Facebooktwitterlinkedinmailby feather
12
Sep

Mi Recorrido con Tecnologia Oracle (Parte 1)

El día de ayer me puse a pensar sobre todo lo que he recorrido en el mundo de Oracle.  Me recordé aquel 29 de Marzo del 2010 cuando recibí una llamada en la que me informaban que habia sido aceptado como becado en DATUM. S.A. una empresa que presta sus servicios en soluciones con tecnología Oracle (www.datum.com.gt). Ese día estaba muy feliz, sabia que iba a aprender muchisimo estando ahi. El 15 de Julio del 2010, esta misma empresa me brindó la oportunidad de laborar en ella. Ahi empezó formalmente mi recorrido en el mundo de Oracle. Inicie leyendo libros de Administración de la base de Datos Oracle, Enterprise Manager , Recovery Manager (RMAN), Tuning, etc. Despues de adquirir cierto conocimiento quizé empezar a dar los pasos hacia el “Oracle Database 11g Administrator Certified Professional”. Inicié estudiando durante varias horas para estar preparado para el primer examen: “1Z0-051-ENU Oracle Database 11g SQL Fundamentals I”. Programé mi examen para el dia 31 de enero del 2011, recuerdo muy bien que iba nervioso ya que no sabia si todo lo que habia leido y practicado habia sido suficiente para aprobar el examen. Finalmente terminé mi examen y vi el resultado: 96 puntos.

Despues de este examen me sentia muy feliz, ya habia iniciado la marcha hacia la certificacion, era hora de estudiar aun más fuerte para el segundo examen el cual ya incluia muchos conceptos de administración de la base de datos, Enterprise Manager, RMAN, entre otros.  La ayuda de mis compañeros de trabajo tambien influyó fuertemente en que yo asimilara los conceptos rápidamente, ya que cuando tenia dudas ellos amablemente me explicaban, entre los que más me apoyaban era “Alejandro lau, Luis Fernando Alonzo, Gerber Bautista”. Finalmente llegó el dia de mi segundo examen de certificacion, el dia 25 de marzo del 2011, el nombre del examen es: “1Z0-052-ENU: Oracle Database 11g Administration I”.  Leia detenidamente cada pregunta que venia en el examen, finalmente mi resultado fue de 95 puntos.

 
Me sentia satisfecho por el resultado obtenido, sabia que la ayuda de mis compañeros y los libros que habia leido habian dado sus frutos. Despues de este examen venia otro examen que es categorizado como uno de los más dificiles, el “1Z0-053-ENU Oracle Database 11g: Administration II”. Mis compañeros de trabajo me decian que para este examen debia estudiar más, que las preguntas eran engañosas, que se debia tener muy claro el concepto de cada proceso y/o elemento de la base de datos Oracle, fue tanto el temor a perder este examen que dupliqué mis horas de estudio, preguntaba más, todos los dias al salir de la oficina me regresaba a mi casa hablando sobre temas de oracle con el Ing. Alejandro Lau, esas pláticas diarias fueron afinando mis conceptos. Finalmente llegó el día del examen, nuevamente volvia a sentir nerviosismo, sabia que habia leido mucho más y que habia tenido una buena preparación, sin embargo, aun me sentia inseguro. El examen me lo realizé el día 02 de Mayo del 2011 y el resultado fue de 75 puntos. Lo gané. Estaba lleno de felicidad, sabia que habia logrado el titulo de OCP.

A las semanas despues de haber ganado todos los examenes y de haber recibido el curso de “Oracle Database 11g performance Tuning”, llegó mi diploma y mi tarjeta que me identificaba como un nuevo OCP en Guatemala.
Luego de este logro, quise darme un buen descanso. Habia estudiado mucho durante varios dias y hasta altas horas de la noche. Terminaba todos los dias con mucho cansancio. Sin embargo, este descanso no duró mucho ya que durante la semana del 16/may/2011 al 20/may/2011 se iba a realizar el primer “Oracle Test Fest” organizado por Oracle Costa Rica, en el cual se regalan varios tickets para realizar examenes de certificacion totalmente gratis. Solicité el examen “1Z0-402-ENU Enterprise Linux Fundamentals”, el resultado fué 97 puntos.
A las pocas semanas de haberme realizado el examen, Oracle me envió una pequeña bolsa en la cual venia una playera, un llavero, un reconocimiento de vidrio y un ipod nano 6ta generacion. Investigué porqué me habian enviado el ipod y para mi sorpresa resultó que mi nota (97 puntos) habia sido la mas alta en Centro América y fué asi como Oracle reconoció mi esfuerzo. Despues de esto recuerdo que pedí 15 dias de vacaciones pues ya me sentia muy cansado.
Luego de estó me interesaron otros productos como WebLogic y OAS. Empezé a leer más sobre estos productos y durante este tiempo se empezó a escuchar el concepto de SOA. Recibí la notificacion de mis jefes que debia especializarme en SOA y fué así como empezé otra vez a estudiar fuertemente esta nueva arquitectura. Estuve involucrado en el primer proyecto de SOA en Guatemala, esa fue una gran experiencia para mi pues estuvieron involucrados consultores de Costa Rica de los cuales aprendí muchisimo pues cada uno de ellos posee mucha experiencia. Al final del proyecto resultamos siendo muy buenos amigos, gracias por compartir sus conocimientos conmigo: Mauricio Camacho, Alejandro Sanchez y Randall Chacon.Despues de varias semanas ya me sentí seguro de poder ganar el examen de certificacion de SOA: “1Z0-451 Oracle Service Oriented Architecture Foundation Practitioner”, obtuve 76 puntos y con ello me convertí en el primer “Oracle Service Oriented Architecture Infrastructure Implementation Certified Expert” en Guatemala.

Despues de varias semanas, mis jefes me comunicaron que me enviarian a una capacitacion a Costa Rica (02/Sep/2012 al 06/Sep/2012) sobre WebLogic 12c, ahi pude reunirme nuevamente con mis amigos Mauricio Camacho, Alejandro Sanche y Randall Chacon, pues ellos tambien asistieron a la capacitacion. Costa Rica es un bonito pais lleno de lugares turísticos que por falta de tiempo no pude conocer, sin embargo, pienso regresar en un futuro cercano.

 

 

Al regresar de mi capacitacion en Costa Rica, llegando a mi escritorio de trabajo el dia 10 de Septiembre del 2012, veo que ya tenia mi diploma de SOA Expert, esto significó una gran felicidad para mi.
 
 Y esto es lo que he recorrido a mis 22 años en el largo camino de oracle. Espero conocer muchas cosas más, obtener mucha experiencia, ayudar a la comunidad y soñar en que quizás algun dia pueda convertirme en un “Oracle ACE”.

 

Facebooktwitterlinkedinmailby feather
11
Sep

Escanear un filesystem ciclicamente para leer un archivo desde BPEL

Oracle BPEL posee adaptadores para leer y procesar archivos de una manera rapida, sencilla y con una gran funcionalidad totalmente personalizable. En este ejemplo estaremos escaneando el directorio “/home/oracle/example” cada 30 segundos, y tomando únicamente aquellos archivos que ya tengan 5 segundos como mínimo de haber sido creados, se tomaran solo los archivos con extension “.txt”.

Para iniciar debemos crear una nueva “Application” en JDeveloper, y un nuevo proyecto de tipo “SOA Project”.
Luego seleccionamos con doble clic el elemento “composite.xml” que se encuentra a la izquierda para poder empezar a crear nuestros componentes.

Arrastramos un “File Adapter” hacia la seccion del “Composite” y nos aparecerá la pantalla de bienvenida del adaptador.

Dar cilck en el boton “Next”

Ingresamos el nombre del FileAdapter.

Seleccionamos la opcion “Define from operation and schema (specified later)”.

Ingresamos el filesystem que queremos estar escaneando,  en este ejemplo es “/home/oracle/example”. La opcion “Process files recursively” indica que si se deben procesar recursivamente todos los archivos aunque esten dentro de carpetas. Seleccionamos la opcion “Archive processed files” e indicamos un directorio en el cual se guardaran los archivos que ya hayan sido procesados. Seleccionamos la opcion “Delete files after successful retrieval” para que despues de procesar los archivos los borre del filesystem origen.

En el campo “Include Files with Name Pattern” escribir “*.txt” para que únicamente tome los archivos con esa extension y los demas archivos los ignore.


En el campo “Polling Frequency” escribir “30 segundos” para que a cada 30 segundos este escaneando el filesystem en busca de nuevos archivos. En el campo “Minimum File Age” establecerlo a “5 segundos”.


Clic en el boton “Define Schema for Native Format”.

En la pantalla de Bienvenida dar clic en “Next”.

Seleccionar la opcion “Create New” y luego seleccionar la opcion “Delimited”.

Elegir un archivo de ejemplo del cual el Wizard automaticamente extraerá el “XSD”.

El archivo de ejemplo que estamos utilizando es  el siguiente:


Seleccionar la opcion “File contains only one record” y dar clic en el boton “Next”.



Ingresar en el campo “Enter a name for element that will represent record” el nombre del elemento “raiz”, en este ejemplo utilizaremos el nombre “Persona”. Dar clic en el boton “Next”.


Dejar los valores default: “Delimited by comma”. Dar clic en el boton “Next”.

Ingresar el nombre de cada uno de los campos que estan en el archivo de texto, en este ejemplo utilizaremos los siguientes nombres: “ID”, “Nombre”, “Edad”, “Pais”.

Se puede ver el archivo XSD generado por el wizard en base a todos los datos que ya le hemos proporcionado incluyendo el archivo de ejemplo. Dar clic en el boton “Next”. Luego dar clic en el boton “Finish”.
Regresamos nuevamente al wizard del FileAdapter y luego dar clic en el boton “Next”. Luego dar clic en el boton “Finish”.


Ahora debemos agregar un componente de tipo “BPEL process”. Fijarse bien que el proceso bpel que estamos creando tenga el “Template” establecido a “Define Service Later”. Establecer un nombre y luego dar clic en el boton “OK”.


Unir mediante un “wire” el ReadFile (FileAdapter) con nuestro ReadFileProcess (BPEL Process).


Dar doble clic en el elemento ReadFileProcess (BPEL Process) y una vez adentro agregar un elemento “Receive”, luego un elemento “Email”.  Alambrar el “Receive” al “ReadFile” tal como se muestra en la imagen.

Despues de alambrar el “Receive” al “FileAdapter” nos aparecera una ventana en la cual hay que dar clic en la cruz verde (dentro del cuadro rojo), esto generara automaticamente una nueva variable.  Cambiar el nombre si se desea. Dar clic en el boton “OK”.


Damos doble clic en el elemento “Email” y lo configuramos. En nuestro ejemplo en el campo “Body” especificamos que enviara los datos de las “personas” recibidas desde el archivo de texto.  Luego dar clic en el boton “OK”.

En el archivo XML del BPEL Process, buscar el tag “createInstance” y poner el valor a “yes”, de lo contrario nuestra instancia de BPEL no se autocreará.

Finalmente realizar “Deploy” de nuestra aplicacion BPEL.


Testear el proceso: Para poder testear nuestro proceso situaremos el archivo “archivo.txt” en el filesystem “/home/oracle/example”, esperaremos “30 segundos” para que pueda ser escaneado y finalmente llegará un correo a mi cuenta con los datos de la persona que estoy enviando.

RESULTADO:



Facebooktwitterlinkedinmailby feather
10
Sep

Crear Alertas para Servicios Web caidos en Oracle Service Bus

Ya que en el Oracle Service Bus se tienen publicados todos los servicios web, es necesario poderlos monitorear de tal manera que cuando se caigan nos pueda avisar y así tomar alguna acción rapidamente. En este ejemplo, veremos como configurar alertas mediante envio de Correo Electrónico cuando un servicio se encuentre abajo.

Primero nos logueamos a la consola de administración del OSB.


Se ve que en este ejemplo tengo creado dos servicios web Banco1 y Banco2. Al servicio web que le configuraremos la alerta es al Banco2. Vemos que para “Banco” se tiene creado varios objetos: Business Service, Proxy Service, wsdl y xsd. Damos clic en el objeto “Business Service” (Esta dentro del cuadro rojo).

Luego debemos hacer clic en la pestaña “Operational Settings” (Recuerde crear una sesion antes de empezar cualquier cambio). Estando en la pestaña “Operational Settings” hay que configurar los siguientes parámetros:

State:Click para habilitar “Enabled”.

Offline Endpoint URIs: Establecerlo a 1 minuto.

Monitoring:Click para habilitar “Enabled”.

Aggregation Interval: Establecerlo a 1 minuto.

SLA Alerts:Click para habilitar “Enable Alerting at” y establecerlo a “Major”.

Activar los cambios de la sesion.


Creacion del Email Server:

Bajo el menu “System Administration” Elegir la opcion “SMTP Server” y luego dar clic en el boton “Add”.


Ingresamos todos los datos de nuestro servidor de correos y luego click en “Save” y luego Activamos los cambios de la Sesion dando click en el boton “Activate” que se encuentra en el “Change Center”.

Regresamos al menu “Project Explorer” y crearmos un “alert Destination”. Para esto elegimos desde la lista de valores “Create Resource” la opcion “Alert Destination”.

Ingresamos los datos para el campo “Resource Name” y “Resource Description” y luego agregamos una o varias direcciones de correos electronicos a los cuales queremos que nos lleguen las alertas, para esto damos clic en el boton “Add” del campo “e-mail Recipients”.

Ingresamos todos los datos que se nos piden, en el campo “SMTP Server” Deberia aparacer el SMTP Server que creamos anteriormente. Luego de ingresar los datos dar click en “Save”.

Despues ya nos tendria que aparacer nuestra direccion de Correo electronico agregado, una vez hecho esto dar clic en el boton “Save” y luego Activar los cambios de la sesion dando clic en “Activate” en el “Change Center”.

Luego regresamos al menu “Project Explorer” y volvemos a elegir nuestro “Business Service” del  “Banco2”. Elegimos la pestaña “SLA Alert Rules” y luego clic en el boton “Add”.

Ingresamos todos los datos necesarios y luego clic en el boton “Next”. En el campo “Alert Destination” deberia aparecer el Alert Destination que creamos anteriormente.

Luego especificar los siguientes datos tal como se muestra en el cuadro rojo, despues dar clic en el boton “Add” y finalmente nos aparecera lo que esta en el cuadro verde. Luego dar clic en el boton “Last”.

[Status][Any URL offline][=][false][evaluate on any server]

Confirmar los datos y luego dar clic en el boton “Save” y finalmente Activar los cambios de la sesion dando clic en el boton “Activate” que se encuentra en el “Change Center”.

Hasta aqui se ha creado todo lo necesario para recibir las alertas en nuestros correos cuando el webservice “Banco2” este abajo. Para esto solo queda testear la configuracion. Bajar el web service “Banco2” y esperar a que el correo se envie.

Resultado:


Facebooktwitterlinkedinmailby feather
10
Sep

¿Es ágil su empresa? ¡Evalúela usted mismo!

¿Se ha preguntado alguna vez qué tan ágil es su empresa? ¿Qué tan rápido se adapta a los cambios del mercado? ¿Qué tan rápido crea un nuevo producto o servicio? ¿IT tiene la capacidad de soportar la innovación que exige las personas de negocio?

Usted puede evaluar el estado actual de su empresa con la ayuda de la Matriz de Madurez OSIMM (Open Group Service Integration Maturity Model), la cual ayudará a crear un Mapa para la transformación incremental hacia un nivel más maduro de integración de servicios para que los beneficios de su empresa incrementen por medio de la agilidad. OSIMM es usado para determinar características de la organización y determinar si existen problemas en el nivel actual, cómo solventarlos y así poder evolucionar al siguiente nivel de madurez.


OSIMM se enfoca en el análisis de siete Dimensiones críticas de una organización o empresa:

  • Negocio
  • Organización
  • Métodos y procesos
  • Aplicaciones
  • Arquitectura
  • Información
  • Infraestructura

Y para cada Dimensión existen siete niveles de madurez. A continuación se dan a conocer los niveles, desde el nivel menos maduro (1) hasta el nivel más maduro (7):

  1. Silo
  2. Integrado
  3. Por componentes
  4. Servicios
  5. Servicios Compuestos
  6. Servicios Virtualizados
  7. Servicios Dinámicamente Reconfigurables
DIMENSIONES: A continuación se describe el concepto de cada una de las dimensiones para así tener claro qué características de la organización son tomadas en cada una de ellas:

Negocio: Está enfocada en las actuales prácticas y políticas de la organización. Cómo son ejecutados y diseñados los procesos de negocio. Cómo están estructurados, implementados y monitorizados. Qué tanto costo implica la modificación o creación de procesos. Qué tan flexible es IT para soportar las solicitudes de las personas de negocio. Estrategias y tácticas de la organización.

Organización: Está enfocada en la estructuración y diseño de la organización y su efectividad. Qué capacidad, experiencia y conocimientos poseen sus empleados para aprovechar una empresa ágil, existencia de gobernanza en sus procesos, alineación entre el negocio e IT. Como está manejado IT y que tanto presupuesto se le asigna.

Métodos y Procesos: Está enfocada en los métodos y procesos empleados por la organización para su crecimiento y su madurez alrededor del Ciclo de vida del desarrollo del software, tales como el uso de manejo de requerimientos, técnicas de estimación, manejo de proyectos, calidad de los procesos, uso de metodologías y herramientas certificadas.

Aplicación: Se enfoca en el estilo de las aplicaciones, su estructura y funcionalidad, reusabilidad, flexibilidad, confiabilidad, seguridad y escalabilidad. Si existen aplicaciones con la misma función, aunque sirvan a partes del negocio distintas (funcionalidad duplicada). Uso de buenas prácticas.

Arquitectura: Está enfocada en la topología, tipos de los datos, modelo de información del negocio, técnicas de integración, estándares y políticas.

Información: Se enfoca en aspectos del modelado de la información, acceso a los datos, abstracción de los datos, transformación de los datos, definición de procesos y servicios, manejo de identidad y credenciales de seguridad.

Infraestructura: Se enfoca en la capacidad de la infraestructura de la organización, manejo de los servicios, capacidad de transaccionalidad, operaciones de IT, manejo y administración de IT. Creación de SLAs, monitoreo, plataformas de integración.

NIVELES DE MADUREZ: Para las dimensiones anteriores, se debe tratar de ubicar cada una de ellas en alguno de los siguientes niveles:

Silo: Partes individuales de la organización están desarrollando software de manera independiente, sin integración de datos, sin procesos ni estándares. Esto limita la capacidad de la organización para implementar procesos de negocio que requieran cooperación entre las diferentes partes, y los sistemas IT no pueden ser integrados sin intervención manual, reconfiguración o recodificación.

Integrado: Se ha logrado la comunicación entre las islas de aplicaciones. La construcción de un sistema IT que integra datos a través de diferentes aplicaciones de la organización se convierte posible. Sin embargo, la integración no está basada en estándares. Además, para conectar dos sistemas, cada conexión puede requerir código a la medida y adaptadores provocando muchas veces proliferación de código, el cual es muy difícil de manejar y además los nuevos desarrollos se vuelven cada vez más complejos y costosos.

Por componentes: Los sistemas IT en islas han sido partidos en varias partes o componentes. Aunque los componentes interactúan entre sí a través de interfaces bien definidas, la manera en que esos componentes interactúan juntas no poseen Bajo Acoplamiento, el cual limita la interoperabilidad entre sistemas en diferentes partes de la organización o incluso con otras organizaciones, el cual es una limitante para el crecimiento de la empresa (adaptarse al mercado rápidamente).

Servicios: Aplicaciones compuestas pueden ser ahora construidas con Bajo Acoplamiento. La manera en que los servicios pueden ser invocados está basado en estándares, son independientes de la tecnología y están ejecutándose en una infraestructura que soporta los servicios con protocolos adecuados, mecanismos de seguridad, transformación de datos y monitoreo de servicios. Los servicios además pueden interoperar con las otras partes de la organización fácilmente o incluso con otras organizaciones externas. Además pueden ser creados SLAs para partes relevantes del negocio. Sin embargo, el flujo de control dentro de un servicio compuesto esta todavía definido por programación a la medida, en lugar de utilizar un lenguaje declarativo. Además los servicios han sido nombrados de tal manera que el nombre implícitamente indique la operación que realiza, permitiendo la creación de un Catalogo de Servicios.

Servicios Compuestos: Ahora es posible construir procesos de negocio por medio de un conjunto de servicios interactuando entre sí. Ya no se realiza código a la medida, sino que se hace uso de un lenguaje declarativo como BPEL. Esto permite ensamblar servicios simples o complejos con mucha facilidad y rapidez ya que no se necesitará escribir ni una línea de código y los cambios pueden ser entendidos por cualquier persona de negocio. Esto provoca que el diseño de servicios sea ágil y que puedan ser desarrollados tanto por las personas técnicas como las no-técnicas.

Servicios Virtualizados: Los servicios IT están ahora siendo accedidos por una fachada, un nivel de induración. Los consumidores de servicios no invocan un servicio directamente, sino que invocan un Servicio Virtual. La infraestructura realiza el trabajo de convertir la invocación virtual en una invocación física al servicio real y puede realizar cambios en los datos, ruteo, la red, el protocolo, entre otros. Los servicios virtuales también favorecen el Bajo Acoplamiento ya que elimina la reconfiguración de todos los servicios dependientes cada vez que un servicio independiente cambie.

Servicios Dinámicamente Reconfigurables: En el nivel anterior, los ensamblados de servicios, aunque son ágiles, son realizados en tiempo de diseño usando adecuadas herramientas. Ahora en este nuevo nivel, los cambios en el ensamblaje de los servicios compuestos son realizados en Tiempo de Ejecución, y con ello la organización se convierte en una: Organización totalmente ágil.

Una vez explicado cada una de las dimensiones y cada uno de los niveles de madurez, se presenta la matriz de madurez OSIMM:


¡EVALUE SU EMPRESA!


Facebooktwitterlinkedinmailby feather