PROCESOS PARALELOS CON 'SPLIT-JOIN'

Los procesos paralelos son muy importantes en todo flujo de tareas, así mismo en 'Oracle Service Bus 12c' (desde ahora OSB) este tratamiento también es utilizado en la mediación, debido a que es una buena práctica, ya que son mucho más ágiles y rápidos que los procesos secuenciales comúnmente usados.

OSB ofrece el manejo de este tipo de procesos por medio de su colección nodos, pero lastimosamente este manejo en paralelo no es muy utilizado comúnmente en los diferentes proyectos. OSB brinda lo que se conoce como Split-Join (Para los procesos PARALELOS) y Pipeline (Para los proceso SECUENCIALES). Así mismo, Split-Join proviene de un patrón que es SPLITTER este patrón consiste en dividir los mensajes grandes en muchos mensajes más pequeños y ser manejados todos estos en paralelo y por medio de JOIN, se vuelven a unir. Es importante mencionar que para el tratamiento en paralelo se debe antes que nada verificar que las tareas que se irán a poder en paralelo NO tengan dependencia alguna entre ellas.

En esta oportunidad mostraré como crear dicho Split-Join, con el objetivo de exponer dos servicios virtuales: DatosClienteService.wsdl y DeudaClienteService.wsdl, por medio de un SOAP-UI MockServices, dichos servicios simularan los posibles servicios creados en BPEL. Estos servicios serán virtualizado por medio de OSB y con los mismo .wsdls se generarán nuevas URLs propias del OSB. Estos Servicios Virtualizados son parte del proyecto: ExternalService (estos dos serán los servicios que se utilizarán en el posterior proceso en paralelo). Luego, se ha creado un proyecto: InternalService, en el cual se expondrá el servicio compuesto de tipo: Split-Join, que procesará los mensajes de cada Servicio Virtual (por medio de los: BusinessService's), y posteriormente integrará los mensajes de ambas respuestas en una sola respuesta final.

Los detalles de los recursos trabajados son:


Servicio Virtual #1:
http://localhost:7101/ExternalService/ClienteService/Pipelines/DatosClienteWS?wsdl

SOAP-UI (Mock#1):
DatosClienteService => DatosClienteService.wsdl 
http://localhost:8090/mockDatosClienteService?wsdl



Servicio Virtual #2:
http://localhost:7101/ExternalService/ClienteService/Pipelines/DeudaClienteWS?wsdl

SOAP-UI (Mock#2):        
DeudaClienteService => DeudaClienteService.wsdl   
http://localhost:8091/mockDeudaClienteService?wsdl   

Servicio Principal (Split-Join):
http://localhost:7101/InternalService/ClienteService/SplitJoin/InfoClienteWS?wsdl

Tal como se mencionó anteriormente, primero se debe de construir el proyecto base llamado: ExternalService, que contendrá los servicios que se procesarán en paralelo (BusinessServices):
 

Dentro de cada Pipeline, se debe redireccionar por medio de un nodo: route, del: Servicio Virtual, al servicio expuesto por los SOAP-UI MockServices:

Dentro del proyecto: InternalService, se debe de crear dos procesos: un Pipeline y un Split-Join. El proceso: Pipeline servirá solo para redireccionar el ProxyService creado (TopDown en base al: InfoClienteService.wsdl), al proceso: Split-Join. Dentro de este se manejará el proceso en paralelo respectivamente:

Dentro del proceso: Split-Join se diseñará todo el proceso en Paralelo requerido:

Las 'Variables Locales' almacenan el resultado los mapeos respectivos por medio de los nodos: Assign, así como por medio de los nodos: Invoke Service, se puede consumir los Servicios Virtuales respectivamente.

Finalmente, por medio de un nodo: Assign se integran todos los mensajes resultantes del consumo de los dos Servicios Virtuales, para luego ser integrados en un solo mensaje por medio de: XQuery.

Es importante recordar que para los mapeos en OSB 12c, la estructura de los XQuery, varía con relación a la estructura de creación de los XQuery (Tanto del editor como de código generado) con relación a la versión 11g, esto quiere decir que no se podrán reutilizar los XQuery que ya se tengan, pero no es complicada de interpretarlo.

 

Así mismo, tener en cuenta que NO todo el mapping se podrá realizar desde el editor, ya al igual que se hacía en la version 11g, para el tema de las listas se tendrá que hacer el mapping manualmente tal como se muestra en el ejemplo con dos FOR para la obtención de los atributos de la list de respuesta:

Considerar la creación de los XQuery como arma principal para todo trabajo de transformación a nivel de OSB, prefieriendo su uso antes al de XLST por tenas de rendimiento. Así mismo, evitar el uso de XQuery incrustado dentro del los nodos: Assign, por temas de mantenimiento.  

Esperemos que con el post se hayan cubierto todas las dudas con relación al manejo de Split-Join y puedan a partir de ahora aplicarlos en sus proyectos. Para los interesados se pueden descargar las fuentes del post desde aquí: http://www.mediafire.com/download/44dzwabl2ibo452/OracleServiceBusApp_SplitJoin.zip

 

APLICACIÓN DE SEGURIDAD EN OSB 12c

Debido a la constante necesidad para la comunicación entre servicios existentes en diferentes inventarios de servicios (externos), es importante conocer que el OSB al ser el bus de comunicación entre ellos soporta como una de sus características, el manejo de la seguridad entre estos. Esta será aplicada de modo que sólo los usuarios válidos pueden invocar. Por esta razón, en esta oportunidad mostraré cómo aplicar seguridad a los servicios virtuales desarrollados en OSB.

El dummy que mostraré consiste en una virtualización de un servicio (ya previamente creado), que por medio de la capa OSB, se accede al servicio compuesto principal (SOAPUI MockService).

Con fines del tema principal del tutorial que es la seguridad en sí, procederé a aplicar y mostrar los pasos a seguir para poder realizar dicha protección en OSB 12c.

Antes que nada resumiré los puntos principales a configurar para la seguridad:

• CREAR EL USUARIO DE ACCESO.
• APLICAR POLITICA DE SEGURIDAD (2 FORMAS).

I. CREAR EL USUARIO DE ACCESO:

Como primer paso, es necesario crear los usuarios que puedan ser invocados por las aplicaciones consumidoras (Muchas organizaciones manejan sus usuarios en el directorio LDAP, pero la configuración de amarre no es parte de este tutorial). Este usuario será creado desde la consola Weblogic de la siguiente manera:

Desde el árbol de la consola de Weblogic (http://localhost:7101/console) acceder a: MyDomain/Dominios de Seguridad y seleccionar: myrealm:

Seleccionar la pestaña: Usuarios y Grupos y seleccionar el botón: Nuevo:

Ingresar los datos para la autenticación del usuario al que se le brindará el acceso entre: servicio & OSB:

Luego de registro se debe poder visualizarse de la siguiente manera en la tabla de usuarios:

II. APLICAR POLÍTICAS DE SEGURIDAD:

Como herramienta el OSB está completamente integrado con: Oracle Webservices Administrador (OWSM), que ofrece gran cantidad de las políticas de seguridad que se pueden utilizar para asegurar los servicios virtuales.

Entre las políticas una de las más resaltantes es denominada: oracle/wss_username_token_service_policy, para la protección por medio de un: user/password definir y creado en el paso anterior. Esta es la que se utilizará en la demostración:

Para la aplicación de las políticas de seguridad se mostrarán dos formas:


A.    DESDE LA FUENTE OSB:

Esta forma consiste en la aplicación de la política desde la misma fuente del proyecto OSB (específicamente desde el: Proxy Service): 

Desde las fuentes (proyecto OSB), ingresar al proxy del servicio virtual que se desea enmascarar y proteger. Luego, seleccionar: Policies, dar check en: From OWSM Policy Store.

Agregar desde: Security, la política requerida, en nuestro caso será: oracle/wss_username_token_service_policy y pulsar el botón: OK.

Verificar que la política se haya agregado correctamente:

 
 
Una vez terminado esto ya se puede desplegar el servicio virtual.


A.    DESDE LA CONSOLA OSB:

Esta forma consiste en la aplicación de la política desde la misma consola OSB: http://localhost:7101/sbconsole, ya que como se mencionó posee conexión directa con OWSM. Ingresar a la consola y seleccionar el proyecto OSB desplegado. Luego, dar check en: De Almacén de Políticas OWSM:

Asociar la política requerida, en nuestro caso será: oracle/wss_username_token_service_policy:

Ingresar la descripción de la política deseada y pulsar: Activar:

Verificar que la política se haya agregado correctamente. Luego, pulsar el botón: Guardar y luego: Activar:

Una vez terminado esto ya se puede probar el servicio virtual. IMPORTANTE, esta configuración de este modo estará activa siempre y cuando no se despliegue de nuevo el servicio (Se tendrá que aplicar luego de cada despliegue).

III. PRUEBA DEL SERVICIO VIRTUAL:

Una vez terminado las configuraciones ya sea de cualquiera de las dos formas anteriormente mencionadas, validaremos la URL expuesta en el navegador donde se verificará los tags de las políticas que se han agregado:

Las pruebas realizadas se pueden realizar tanto desde SOAPUI como desde el tester de la consola OSB. Una vez configura y expuesto el servicio, si se desea probar sin ingresar los tags de policy adicionales en la cabecera o ingresándolos incorrectamente el: user/password, se mostrará el error siguiente:

Agregando el contenido correcto de los tags en la parte del header con relación a las políticas, el servicio deberá responder correctamente:

   [soapenv:Header]
    [wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"]
       [wsse:UsernameToken]
          [wsse:Username]USUARIO[/wsse:Username]
          [wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText"]PASSWORD[/wsse:Password]
       [/wsse:UsernameToken]
      [/wsse:Security]
   [/soapenv:Header]

Así mismo, se puede realizar la misma prueba en la consola OSB, desde el Proxy Service respectivamente:

Luego, de ingresar el bloque de policy en el header al igual que se hizo desde SOAPUI, el resultado de las pruebas sería el siguiente:

Con esto se termina el post, esperando que lo puedan aplicar en sus proyectos OSB.

BUENAS PRÁCTICAS Y LECCIONES APRENDIDAS EN OSB

Para la implantación de un proyecto SOA es importante considerar el manejo de un ESB que controle la comunicación entre los servicios entre otros puntos importantes. Por otro lado, el contar con dicha capa de virtualización los clientes no podrán consumir directamente los servicios expuestos por los proveedores, proporcionando agilidad en las transformaciones, orquestaciones, desacoplamiento entre servicios expuestos y/o los servicios consumidores. Así mismo, los beneficios a considerar por utilizar OSB son:

- La mediación.
- La transformación.
- El redirecionamiento.
- La eliminación de conexiones punto a punto.
- Virtualización.
- Orquestamiento.
- Balanceo entre servicios.
- Aseguramiento de Servicios.
- Desacoplamiento entre clientes y proveedores.

Para el cumplimiento de esto ORACLE, ofrece su propio ESB denominado OSB (Oracle Service Bus), con la finalidad de cubrir dichos puntos importantes. Así mismo, con relación a los desarrollos en esta herramienta, se debe tener claro que el OSB deberá ser el intermediario de los servicios, convirtiéndose  en la columna vertebral de integración empresarial, debiendo ofrecer un altísimo desempeño en el bus, para cumplir esta meta se debe de considerar algunos puntos conocidos como buenas prácticas y/o lecciones aprendidas en base a la experiencia en muchos proyectos de similar calibre. Estos son:

A. ¿QUE SE DEBE CONSIDERAR EN OSB?:

• Se debe de considerar que el OSB debe tener altísimo desempeño, monitoreo, soporte a legacy, disponibilidad 24x7, siendo considerado como única plataforma base de la infraestructura SOA. 
  
• Se debe utilizar XmlObject y XmlCursor en Java Callout , ya que con esto se puede manejar toda la potencia de las bibliotecas Java, para cubrir necesidades de procesamiento de mensajes.
  
• Se debe de generar automáticamente los WSDL (topDown). Lo mismo puede decirse acerca de las transformaciones de XQuery.
  
• Se debe de reutilizar en los WSDL  los  XSD de manera externa en un servidor SOA-MDS, esto para fomentar la reutilización de estos.
  
• Se debe redefinir la URL del servicio virtual expuesto por el OSB, esto debido a que la URL generada es muy extensa. Esta desde ser redefinida desde el Transport del Proxy Service respectivamente.
  
• Se debe establecer por cada  Proxy Service y Business Service un tiempo de espera (TimeOut).
  
• Se debe de incentivar el uso de Split-Join para reducir la latencia. Esto debido a que las ejecuciones en paralelo se utilizan para reducir la latencia cuando se consume altos recursos del sistema. Se debe analizar que si un conjunto de actividades no tienen dependencia (unos de otras), estas pueden ser ejecutadas en paralelo.
  
• Se debe de usar un Dynamic Routing para dinámicamente invocar un diferente Business Service.
  
• Se debe de usar un HTTP Transport  de un Proxy Service para aceptar llamadas RESTful. Mapear métodos HTTP (GET/PUT/POST/DELETE) para la operación SOAP, usando un nodo: Branch Conditional.
  
• Se debe de usar el transporte JEJB en ambos extremos de OSB, para desacoplar los EJB consumers de los EJB  providers.
  
  
  
• Se debe de usar un  Conditional Branch o un Routing Table en lugar de una sola acción de Routing.
  
• Se debe usar un Result Caching para almacenar en memoria la información del OSB.
  
• Se debe usar un adaptador JCA para integrar los sistemas Legacy a través de adaptadores proporcionados por la SOA Suite, tales como, DB, File, FTP adapters y EJB, JMS, File y FTP Transport.
  
• Se debe considerar el control de Exception (fault) y logging en todos los servicios.
  
• Se debe de manejar la  auditoría para el rastreo de los servicios. Un complexType que contenga tiempo de respuesta, codResp, DetaResp, nombUsuario, nomApplicacion, ipAplicacion. Se debe  registrar eficientemente dicha información por ejemplo con log4j  de manera asíncrona a un archivo. 
  
  
• Se debe configurar siempre el controlador de errores a nivel de servicio. Cualquier tipo de error existente en el Pipeline debe ser controlado por medio de los nodos que brinda el OSB. Esto se puede aplicar  en las 4 áreas diferentes en el OSB: Pipeline, Proxy Service, Route Node, Stage Node. Esto para que no exista una respuesta de error estándar (como un error de SOAP que puede auto generar con el TopDown).
  
• Se debe considerar si un servicio de proxy tiene un WSDL con múltiples operaciones, generalmente se recomienda el uso de: operational branch, para manejar mensajes por separado para cada operación en vez de blogues: IF.
  
• Se debe considerar las acciones de actualización como: Delete, Insert, Replace, Rename, son más eficientes para correcciones pequeñas en un documento, que usando Asign con XQuery debido a que regenera todo el documento, sobre todo si el documento es grande.
• Se debe utilizar para transformaciones con XQuery el uso de XQuery mapper. Esto debido a puede ser más productivo (más rápido). Así mismo, una subRutina XQuery puede ser menos eficiente que acciones de transformación como: Rename, Delete, etc.
  
• Se debe de configurar los servicios en OSB en modo alta disponibilidad  (cluster), esto para que el procesamiento de carga sea compartido por cada server (físico / virtual) , así mismo para que el servicio pueda estar expuesto  y si uno URL no está disponible,  se pueda acceder de forma automática al otro server.
  
• Se debe en vez de tener un solo controlador de errores en todo el Pipeline, apoyarse en cada nodo Stage ya que en un diseño request/response Pipeline, se puede controlar los errores existentes en su interior por cada Stage.
  
• Se recomienda configurar el Throttling para la protección de los servicios OSB, con relación a los picos de sobrecarga. Throttling puede definir políticas de limitación de peticiones para un servicio de negocio dentro de OSB. Esto para evitar que se alcance la capacidad de un servicio web y se continúe aceptando conexiones.
  
• Se debe utilizar para la creación de DataSource de tipo Select (Operaciones Query), el los Driver que brinda Weblogic de tipo: non-XA. Esto con relación al futuro manejo del JCA que será autogenerado.
  
• Se recomienda el uso de expresiones FLOWR (acrónimo de: For, Let, Where, Oorder By, Return), en la creación de los XQuery.

B. ¿QUE SE DEBE EVITAR EN OSB?:

• No se debe  tratar de desarrollar toda una solución sólo en OSB. Ya que el OSB es un ESB y este NO debe ser usado para manejar lógica de negocio y ser utilizador exclusivamente para desarrollos ESB (Mediación, redireccionamiento, transformación).  Es muy común que en muchos proyectos se cometa este error (el desarrollo de la totalidad de su solución en OSB).
  
• No se debe diseñar flujos transaccionales StateFul dentro de OSB. Esto debido a que OSB es una herramienta de tipo StateLess, que no debe ser utilizada para manejar transacciones StateFul. Para este manejo transaccional StateFul se debe utilizar como solución BPEL o BPM en vez de OSB.
  
• No se debe usar OSB para ejecutar SQL ó llamados a Store Procedimientos complejos: Aunque OSB proporciona mecanismo para ejecutar estos dentro del ‘pipeline’, se debe restringir su manejo sólo para operaciones para recuperar datos (SELECT), nunca se debe de ejecutar para operaciones SQL de tipo CRUD (INSERT / UPDATE / DELETE) dentro del pipeline en OSB.
  
• No se debe usar Java CallOut para satisfacer necesidades de negocio. Esto debido a que las llamadas Java es la característica más abusado de OSB (y a veces se abusa de su manejo). Sea cual sea la lógica de negocio no debe ser manejada a través de OSB  (Java CallOut) para implementaciones de lógica de negocio compleja, dentro de  OSB pipeline. Puede ser utilizada para tareas utilitarias como transformaciones puntuales o para log. 
  
• No se debe desarrollar lógica de negocio compleja dentro de OSB pipeline: Teniendo en cuenta el hecho de que se puede cambiar fácilmente en Runtime desde la consola OSB. Oracle SOA Suite maneja lo que se conoce como OBR (Oracle Business Rule) para definir la lógica de negocio, así que por qué definir reglas de negocio en otro lugar (OSB). Se debe de definir reglas de negocio en OBR y exponerlas como servicio web, para posteriormente consumir dichas reglas de negocio en OSB (como WS) cuando sea requerido.
  
• No se debe utilizar la consola OSB para el desarrollo. Anteriormente en OSB no había existía el apoyo de IDEs, pero actualmente el desarrollo directamente desde la consola OSB es considerado reliquia. Actualmente, soluciones como OEPE  permiten crear proyectos OSB y componentes de manera local, que puede ser fácilmente controlados. Así mismo, se debe tener en cuenta que desarrollos OSB por medio de OEPE tiene muchas ventajas sobre la consola OSB como Xquery editor, split-join, etc.
  
• No se debe utilizar WS Policy para el control de  Seguridad en OSB. Para implementar la seguridad alrededor de Servicio OSB utiliza OWSM (Oracle Web Service Manager), esto debido a que las políticas en Weblogic no están actualizadas.
  
• No se debe desarrollar los flujos de mensajes completos en un solo Stage dentro de un Pipeline. Esta es una mala práctica muy común, el manejar  todo en un solo Stage así como definir los nombres sin mucho significado. Se debe manejar cada parte que tenga acciones relevantes (agrupando), con nombres de Stage explicando claramente lo que hacen.
  
• No se debe procesar archivos de gran tamaño a través de OSB. Ya que OSB no es para trabajo pesados, para estos casos se debe utilizar ODI (Oracle Data Integrator), que es una herramienta especializada para el procesamiento de archivos de gran tamaño.
  
• No se debe manejar comodines en expresiones de tipo XPath. Se debe evitar el uso de caracteres comodines con:      * u operadores recursivos de ruta como: "//" con  XPath. Esto debido a que su manejo causa impacto en el rendimiento significativo. Se debe evitar lo más que pueda.
  
• No se debe crear un Proxy Service es de tipo: Any SOAP, Messaging type services o Any XML ya que OSB tiene problemas al autogenerar WSDL eficaces para este tipo de servicios, es preferible seleccionar los tipos SOAP desde .WSDL ó XML desde .WSDL, esto para favorecer los estandarizado con el TopDown (todos lo objetos definidos dentro de la interface): element, message, portType, etc. Así mismo, posteriormente apoyarse con el nodo: Operationa Branch para automáticamente reconocer cada operación existente.
  
• No se debe abusar en las comunicaciones de datos, enviando parámetros en XML (como Texto). Estas se deben de minimizar ya que el Marshalling / Unmarshalling de mensajes, es de las acciones más costosas en OSB.
  
• No se debe abusar del manejo de Proxies EJBs (EJB Transport). Esto permiten la transformación de: XML a Java, pero son caros tanto para el mantenimiento como para el rendimiento. Si es necesaria la interacción  con el mundo Java, verificar si es que no se pueda realizar simplemente usando un Java Callout. EJB Transport está diseñado para ofrecer un débil acoplamiento orientados a la interface por medio de un WSDL autogenerado. Este binding tiene un costo de trasformación que es aceptable cuando el EJB representa un servicio reutilizable. Así mismo, un Java Callout puede ser una mejor solución para acceder a un EJB, y obtener un más bajo acoplamiento.
  
• No se debe  crear de muchas variables de contexto OSB, que se utilicen una sola vez dentro de algún XQuery. En si la creación de variables se debe de realizar con el objetivo de la reutilización en varias partes del OSB.
  
• No es recomendable el manejo de XLST en proyectos en OSB. Si analizamos XSLT es para XQuery como JavaScript es para Java y en actualmente no existe una equivalencia en versiones con relación al motor de transformaciones de xsl existente en OSB con el actual generando por ello muchos errores. Debido a ello de preferencia para todo tipo de transformaciones en OSB es mejor considerar trabajarse con XQuery. 
  
• No se debe de crear componentes JCA para consumir Store Procedure que manejen ORACLE Types, esto debido a que el OSB  como herramienta autogenera unos ORACLE Package como Wrappers que contienen todo el parseo de equivalencias. Esto genera problemas con las áreas de QA, ya que por su estructura es muy complicada su prueba como Script (PL/SQL) y traerá problemas al momento del pase. Es preferible referenciar a Store Procedure que manejen parámetros de tipos nativos.

Esperemos que estas recomendaciones sean consideradas y aplicadas de la mejor manera, para que mejoren el rendimiento de estos en sus proyectos de tipo OSB.

STATELESS vs STATEFUL

Muchas dudas existen sobre la diferencia entre: 'StateLess' y 'StateFul', con relación al control del estado. A continuación una diferencia resaltante para entender el concepto: 

• StateLess: Significa que NO se controla la memoria del pasado (ya procesada). Cada transacción se realiza como si se está haciendo por primera vez. Ejemplo:

public int agregar( int numero ){
           return (numero + 1);
}

• StateFul: Significa que SI se controla la memoria del pasado (ya procesada). Cada transacción anterior se recuerda y puede afectar a la transacción actual. Ejemplo:

private int numero = 0;

public int agregar(){
           numero ++;
           return numero ;
}

Así mismo, es importante tener concimiento que como conceptos a nivel de herramientas Oracle SOA son considerados:

- BPEL: (StateFul)
- OSB: (StateLess)

OBTENCIÓN DE .WADL EN SERVICIOS REST (BASADOS EN JERSEY)

Para el manejo de servicios basados en REST, a diferencia de los servicios basados en SOA que tienen estandarizado su contrato de servicio (.wsdl), estos servicios REST no lo tienen de manera formal, pero aún así muchas vendors como ORACLE ó IBM manejan dicha interface .wadl en sus herramientas, para facilitar los TopDowns manejados. Debido a ello es bueno conocer que algunas librerías como Jersey, soportan su obtención automática de dichas interfaces, al ser expuesto el servicio en el servidor de aplicaciones.

La manera de obtener la el .wadl es la siguiente:

De la URL del servicio principal:

http://localhost:8080/DummyCompletoREST/soa_01/json/procesarMsj_02/EAI001/41816133?tipo=2

Obtenemos la URI base respectiva y le agregamos /application.wadl:

http://localhost:8080/DummyCompletoREST/application.wadl

Es importante recordar que esta forma de obtención de .wadl es exclusiva en Jersey.Simplemente, desde el navegador dando: click derecho + guardar como archivo y se le cambia la extencion a .wadl.

"IMPORTANCIA DE 'LOG' EN LOS SERVICIOS"

El manejo de LOGs a nivel de servicios es muy importante, ya que en el refleja la traza de cómo el flujo de los mensajes se va transmitiendo entre servicio y servicio. Este manejo de LOGs debe ser realizado de la mano con un mecanismo estandarizado de auditoría en donde el 'idTransaccion' refleje la relación que existe de las trazas generadas en los servidores distribuidos, a nivel de servicios. Esto permitirá a los administradores de servidores y/o operadores de estos poder identificar, ante alguna caída de un servicio embebido dentro del servicio compuesto, la causa exacta del problema.

En lo relacionado a ¿Que debemos imprimir en los LOGs?, esto es muy importante ya que recordemos que los LOGs no deben ser gigantes, ya que estos se almacenan en disco. Debido a ello, se debe estandarizar que es lo que debemos imprimir en ellos. Una recomendación para esta tarea de manejo de LOG es la siguiente:

• Cada línea de LOG generada, debe indicar: "Fecha, Hora y idTransaccion", muy a parte del mensaje que se desea imprimir.
• Se debe imprimir todo mensaje REQUEST y RESPONSE de cada servicio compuesto.
• Se debe de imprimir el tiempo de duración en segundos y/o milisegundos, al final de cada servicio compuesto.
• Se debe imprimir todo mensaje REQUEST y RESPONSE de cada servicio ‘proxy client’ que se consume en el flujo.
• Se debe de imprimir datos importantes de los servicios o BD como: "URL endPoint, nombre PACKAGE/OWNER/PROCEDURE, nombre JNDI, etc"
• No se deben imprimir datos como passwords (si lo hacen deben figurar como encriptados).
• No se deben imprimir un llamado a LOG dentro de un bucle (dentro de una lógica), que podría generar, en algún posible escenario, infinita generación de LOG.   

Estas son algunas de las recomendaciones para la aplicación de LOGs respectivamente. Por otro lado, es muy importante que los servicios no manejen 'System.out' embebidos (si es que están desarrollado en JAVA), ya que estos escriben directamente en la consola del server. Debido a este problema, en algunos proyectos SOA se acostumbra destinar un servicio de tipo 'Util' a este trabajo de Loggin (siguiendo la orientación de servicios), para que ante cada necesidad de impresión de LOG se invoque a dicho servicio. Desde mi punto de vista, por un lado está bien la lógica según la orientación respectiva, pero analizando este servicio por cada Request y Response que se realice ¿cuantas veces será invocado?, debido a ello en otros proyectos para este tipo de tareas se elimina el manejo de este servicio como utilitario y se reemplaza por el manejo de un ‘Framework de loggin’, Debido a ello en la actualidad hay varios opciones entre las que resalta la 'LO4J', que permite la realización de este labor de manera rápida, configurable por niveles (INFO, DEBUG, ERROR, etc) y fácilmente integrable a servidores de aplicaciones como Weblogic, WAS, etc, de manera externa a la aplicación.

Esto quiere decir que los administradores de servidores, mediante su manejo pueden definir una ruta absoluta fija en los servidores, destinada a la generación de archivos logs de todas las aplicaciones corriendo en los servidores, para que antes cualquier necesidad de búsqueda en dicha ruta encontraran el archivo "NombreServicio.log" por fecha automáticamente ordenado.

APLICACIÓN DE 'EHCACHE' CON 'SPRING'

El manejo de 'Cache' en las aplicaciones y servicios es muy importante, ya que agiliza la obtención de los datos evitando estar constantemente golpéando la BD. La ventaja que proporcionan en si las 'caches' básicamente es eliminar los tiempos de acceso a un recurso externo, para recuperar los datos que se encuentran mantenidos en cache, pero hay que tener cuidado en tener claro cuando y como realizarlo, así mismo como configurarlo.

En esta oportunidad mostraré una forma de como trabajar con una de las librerías open source más conocidas para el manejo del 'cache' que es 'Ehcache'. Esta librería posee un principio básico que es dividir la caché en diversas 'regiones' configurables donde se ubican los objetos.

Sus características principales son:

• Rápido y simple de usar.
• Pequeño (menos de 700 kb) y con pocas dependencias.
• Escalable: permite, por un lado, escribir a disco y, por otro, trabajar con muchos caches en paralelo.
• Flexible: permite trabajar con Objects o Serializables y configurarlo mediante xml o programaticamente.
• Extensible: se pueden adicionar plug-ins, loaders, listeners, JMX y exceptions handlers. Trabaja con varias APIs como JTA o frameworks como Hibernate.
• Distribuído: posee muchas opciones de replicación de los datos.

El propósito de este post es mostrar de froma detallada su integración con 'Spring', configuración y aplicación, mediante un dummy.

Las librerias requeridas para desarrollar este dummy son las siguientes:



Es necesario que desde 'Spring' se maneje un archivo de configuración exclusivo para 'EhCache' (applicationCache.xml):



Así mismo 'EhCache' maneja un archivo 'xml' referenciado desde 'applicationCache.xml', en donde maneja toda la configuración personalizada del cache, para cada escenario donde se desee aplicar:



Se debe de tener muy claro el significado de la definición de cada propiedad que se maneja. Aquí el detalle de cada una de ellas:



La prueba del 'dummy' la realizaremos mediante una clase main, que levantará el contexto de 'Spring' y ejecutará 2 metodos de prueba (estos trabajan independientes, se puede comentar y probar el que desee):



Metodo#1: Simulación del consumo de DB (1 vez), luego se obtendrá del 'EhCache' el mismo dato durante '10' seg. Despues golpeará la BD otra vez:

El resultado de la prueba es que al ejecutar en un tiempo de 20 segundos, solo se ha obtenido de BD (simulada) la 1ra fecha (2015/09/19 09:33:17) y como ven la hora se mantiene ya que las demás consultas son obtenidas del 'EhCache' configurado, para que mantenga la información por 10 segundos, poteriormente a ellos volvera a actualizar la información con la BD:

Metodo#2: Simulación del consumo de DB (1 vez), luego se obtendrá del 'EhCache' el mismo dato durante '10' seg. Despues golpeará la BD otra vez y se iran agregando 5 registros a la lista anterior existente:



El resultado de la prueba es que al ejecutar en un tiempo de 20 segundos, solo se ha obtenido de BD (simulada) la 1ra lista de Mensajes con una cantidad de registros de 5 y como ven la hora se mantiene ya que las demás consultas son obtenidas del 'EhCache' configurado, para que mantenga la información por 10 segundos, poteriormente a ese tiempo volvera a actualizar la información con la BD y como se aprecia la lista ahora devuelve 10 registros, ya que existe una simulación que cada 10 segundos se le agregarán 5 registros (por efecto de la prueba respectiva):



Para los interesados las fuentes se pueden descargar aquí: http://www.mediafire.com/download/aasn2aysfu2aoyi/Dummy_Spring_EhCache.zip