sábado, 31 de octubre de 2015

SOA vs MICROSERVICIOS


En esta oportunidad complementaré la idea de este muy bueno artículo hecho por: Andrés Hevia
http://pensandoensoa.com/2015/10/25/a-vueltas-con-los-microservicios-y-soa/, dando mi punto de vista sobre este tema tan controversial del cual se habla este último tiempo.

En si NO se debe de confundir lo que es SOAP con WS-*, ya que SOAP (Simple Object Access Protocol), es un protocolo de comunicación estándar para mensajería apoyado por la W3C como un modelo distribuido. Por otro lado, WS-* es un protocolo definido por OASIS orientado al desarrollo y la adopción de estándares. Dichos estándares son comúnmente implementados por los Vendors (ORACLE, IBM) en sus herramientas, así como en apis OpenSource.

Ahora, en si una de las diferencias que comúnmente se menciona es que SOA en su implementación debe ser desarrollada con Web Service específicamente y por otro lado, MicroServicios debe ser implementado con servicios RestFul basado en arquitectura REST. En mi opinión está mal ya que se en un proyecto SOA las implementaciones deben ser orientadas a servicios (NO Web Service), esto quiere decir que dichos servicios pueden también ser considerados de tipo RestFul, NO hay problema con ello.

Por otro lado, la gran diferencia entre ambos es que una de las características de SOA es que es recomiendable como patrón, el usar un ESB para la comunicación, seguridad, transformaciones, eliminaciones de conexiones punto a punto, etc, entre los servicios de manera desacoplada, en sí que sea la columna vertebral de las soluciones SOA. Por otro lado, MicroServicios NO manejan la visión del manejo del ESB, ellos de apoyan en lo que se denomina API Gateway que proporciona un punto de acceso central para administrar, enrutar, supervisar y asegurar el acceso a servicios expuestos públicamente.

Finalmente, desde mi punto de vista veo que un API Gateway no es un sustituto de un ESB, sino más bien una mejora para la implementación de una Arquitectura Orientada a Servicios (SOA).

martes, 27 de octubre de 2015

SOAP FAULTs vs ERROR CODE


Todos los que tenemos conocimiento y hemos trabajado con servicios sabemos que para llevar a cabo un proyecto SOA es requerida la aplicación del paradigma de la orientación a servicios, en nuestros desarrollos. Ahora es necesario, durante la implementación de estos servicios, seguir una serie de principios que ayudarán para estandarizar con buenas prácticas dichas implementaciones. Justamente el primero y más importante principio SOA, habla sobre la ''Creación de Contrato de Servicio Estandarizado", durante la definición de dicho contrato a nivel de Web Service (.wsdl), surge una gran duda que es abordada en este post, esta es cómo manejar el control de errores: con 'Soap Faults' o con 'Error Code' personalizados.

Las Excepciones y Fallos a nivel de servicios se utilizan para comunicar los errores dentro del servicio o para comunicar errores a través de límites de servicio. Por ejemplo, el protocolo HTTP utiliza códigos de estado como 404, que indica el problema a nivel de URL (No disponible). Así mismo, es importante considera lo que son excepciones por Timeout, excepciones al momento de consumir alguna BD y/o servicios que forman parte del servicio compuesto, etc.

Hay que tener en cuenta al lanzar una excepción, que se tiene que permitir a las aplicaciones consumidoras identificar la excepción y/o problema sucedidos, para que estos puedan estas interpretar y reaccionar adecuadamente a la excepción. Así mismo, debe de proporcionar información suficiente para que dicha aplicación y/o servicio (dentro del flujo compuesto), pueda entender lo que salió mal y definir cómo controlarlo.

A nivel de Web Service se pueden solucionar este problema de dos formas con Soap Faults ó con Error Code personalizados.


I. SOAP FAULTs:
Este es el modo de control de errores provisto dentro del .wsdl, para el manejo de cualquier tipo de problema dentro del servicio. La falla es registrada dentro del cuerpo elemento de un servicio web. Así mismo, para su manejo debe ser creado un tercer elemento menssage de tipo Fault dentro del PortType:

[fault message="tns:MissingName" name="NombreObjetoError" /]

Actualmente, existen en base al tipo de SOAP utilizado: (SOAP:1.1 ó SOAP:1.2), que manejan estructuras de falla diferentes por versión respectivamente.

SOAP 1.1:
 [SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"]
   [SOAP-ENV:Header/]
     [SOAP-ENV:Body]
         [SOAP-ENV:Fault]
            [faultcode]SOAP-ENV:Client[/faultcode]
                    [faultstring]INFORMACION DEL PROBLEMA[/faultstring]
                    [faultactor]http://gizmos.com/order[/faultactor]
            [detail]
                        [PO:order xmlns:PO="http://gizmos.com/orders/"]AQUÍ DETALLE COMPLETO DEL PROBLEMA[/PO:order]
                    [/detail]
           [/SOAP-ENV:Fault]
     [/SOAP-ENV:Body]
 [/SOAP-ENV:Envelope]


SOAP 1.2
[env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"]
  [env:Header/]
  [env:Body]
    [env:Fault]
      [env:Code]
         [env:Value]env:Sender[/env:Value]
      [/env:Code]
      [env:Reason]
         [env:Text xml:lang="en-US" ]INFORMACION DEL PROBLEMA[/env:Text]
      [/env:Reason]
      [env:Role]http://gizmos.com/order[/env:Role]
      [env:Detail]
         [PO:order xmlns:PO="http://gizmos.com/orders/"]AQUÍ DETALLE COMPLETO DEL PROBLEMA[/PO:order]
      [/env:Detail]
    [/env:Fault]
    [/env:Body]
[/env:Envelope]



II. ERROR CODE:
Consiste en NO manejar los message de tipo Fault dentro del PortType (Input message y Output message), y definir un estándar a nivel de .xsd (ComplexType), con los parámetros de control de errores: CodError, MsjError, donde se estandarizarán los controles de error mencionados (No disponible, TimeOut, BD, etc), ya sean de tipo Técnicos ó Funcionales (negocio). Así mismo, estos cuando se ejecuten serán controlados en la implementación del servicio e identificados por tipo de excepción, y  retornados a la aplicación consumidora en el mismo elemento: Output message (CodError, MsjError). Esto facilitaría la identificación de la falla del servicio para el cliente (transparente). 

Recomendación:
Muchos estarán a favor del manejo por Soap Faults y otros por el manejo por Error Code personalizados. Desde mi punto de vista, he trabajado con ambos formas de control y procederé a dar mis comentarios y puntos de vista:

En lo relacionado a Soap Faults, el manejo facilita el desarrollo del lado de la implementación del servicio, ya que uno como desarrollador se olvidaría un poco del control de excepciones, debido a que ante una falla, esta será lanzado por el: fault message. Por otro lado, este manejo dificulta el control e identificación del error por parte de las aplicaciones consumidoras que tendrán que pelearse con dos estructuras diferentes de Soap Fault (Versión SOAP: 1.1 y 1.2), así mismo como los problemas del lado e algunos Frameworks, que al hacer el Topdown generan problemas para acceder a la parte de Fault a nivel de código.

En lo relacionado a Error Code, el manejo dificulta el desarrollo del lado de la implementación del servicio debido a que se deberá identificar, dentro del servicio, los posibles tipos de errores que puedan generar problemas en el servicio: TimeOut, No disponible, BD, etc, y ser respondidos por el mismo objeto:  Output message. Por otro lado, este manejo facilitaría haciendo transparente el control de errores del lado de las aplicaciones consumidoras, es más se podría definir desde el inicio como parte del documento de especificaciones del servicio los posibles: codError y msjError, para los diferentes escenarios de tipo Técnicos o Funcionales (negocio). Incluso, favorecería la identificación por el lado de los administradores del servidores (a nivel de Logs).

Finalizando, solo me queda mencionar que se ha tratado de detallar datos importante, en base a experiencia en el manejo, de estas dos modalidades existentes para el Control de Errores a nivel de Web Service. De su lado, ya queda tomar nota y ver que manera de adecúa mejor a la implementación en su negocio (proyectos).



viernes, 23 de octubre de 2015

CENTRALIZACIÓN DE LOG's (SYSLOGs)


En un post anterior comenté sobre lo que es la: Importancia de los LOGs en los Servicios, en esta oportunidad hablaré y mostraré sobre algo importante que está de la mano con este tema, en si es posterior a dicho tema, este es la 'Centralización de Logs'.

La 'Centralización de Logs' como su nombre lo dice es muy importante, ya que si analizamos en un ambiente Prod, existen una gran cantidad de archivos Log que a diario se van generando y creciendo con los procesamientos de los sistemas. Para ello anteriormente también se recomendó una serie de consideraciones a tener en cuenta, sobre lo que debería contener cada Log. Adicionalmente a ello, es recomendable, pensando en proyectos relacionados de SOA, definir por servidor una Ruta Absoluta Fija (por ejemplo: /home/tdp/soa/logs), que contendrá en su interior los directorios con los nombres de los proyectos trabajados (servicios) y dentro de estos directorios se generen Logs de cada servicio. Así mismo, definir a un Operador/Administrador de servidores que sea el encargado de la revisión y mantenimiento de los Logs (ya que estos, dependiendo de los mecanismos que se utilicen para su generación, van creciendo por día considerablemente), debido a ellos dichos Operadores deben velar por el bienestar de los servidores, eliminando Logs de fechas anteriores (por ejemplo cuatro semanas de antigüedad, dependiendo del negocio) a nivel del Servidor y de los Nodos que existan (Cluster), por medio de Script por ejemplo. Esta es una tarea que si no se realiza ordenadamente, definiendo rutas absolutas fijas donde ir a buscar directamente, ante una falla del servicio, puede llevar al caos el identificar problemas existentes.

Justamente, pensando en aligerar un poco esta tarea de identificación de fallas en los servicios, nace el concepto de 'Centralización de Logs', esto consiste en que los sistemas y/o aplicaciones generadoras de Logs, por medio de un mecanismo, lancen sus Logs a un Servidor Central de Logs, estos servidores (Virtuales/Físicos), deberá tener la capacidad de recepcionar los mensajes de Logs enviados y por medio de una consola de administración, el Operador/Administrador será alertado vía emails, así como poder visualizar listado en pantalla los problemas, etc.

En esta oportunidad mostraré una solución para realizar dicha tarea de: 'Centralización de Logs', por medio de 'Log4j Syslog' y 'Kiwi Syslog Server'. Ahora explicando un poco sobre: 'Kiwi Syslog Server', es una solución de pago que trabaja como servidor syslog, brindando características de administración de archivos de registro, fácil de usar para los Operadores/Administradores y los equipos de red, de instalar y configurar, este trabaja con alertas, SNMP, eventos, etc, sobre las plataformas Windows, Linux. Para más detalles del producto visualizar el Video.

I. SYSLOG SERVER (Kiwi):
Lo bueno para el tema de pruebas es que este Syslog Server, maneja su versión Free, que se puede descargar de aquí

Un vez descargado se debe de instalar el software que trabajará fijo con Evento permanente instalado en la máquina y que escuchará los mensajes Syslog: SolarWinds_Event_LogForwarder_Setup, luego se debe instalar el Syslog Server como tal: Kiwi_Syslog_Server_9.5.0.Freeware.setup.



Terminada la instalación así se visualizará el: Kiwi Syslog Server:



II. LOG4J (Syslog):
Por medio de Log4j y su integración con Servidores de Aplicaciones como Weblogic ó WAS, uno puede configurar la autogeneración de Logs, en Rutas Absolutas Fijas por Servicio (Justo la primera parte que anteriormente ya se había mencionado y recomendado).

He creado un proyecto JAVA para simular el manejo, configuración y envío de los Logs (mensajes) al Servidor Central por medio de Syslog.


Todo debende de manejar una buena configuración de los Appender de Log4j, mi caso tengo configurado dos Appender, para que tabajen de la mano: 
  • org.apache.log4j.net.SyslogAppender:  Para la comunicación con el Servidor Central Syslog.
  • org.apache.log4j.DailyRollingFileAppender: Para la generación de los Log en las rutas absolutas fijas definidas.
 

III. TESTING:
El dummy preparado inicia desde Eclipse que mandará el Log a generarse, tanto en la Ruta Absoluta Fija definida, como en el Servidor Central Syslog:


El mensaje será registrado en el archivo Log, del directorio fijo definido.  


Así mismo, se registrará el mensaje en el Servidor Central Syslog, tal como se muestra en imagen.


Esto ayudará el Operador/Administrador, a que tenga más visión de los problemas existentes a nivel de los servicios y aplicaciones desplegadas en el Server.

Una segunda prueba, ya simulando un escenario real a nivel de servicios sería la siguiente:

Se debe configurar de manera similar el archivo log4j.xml que se tiene integrado con Weblogic Server, definiendo el Appender adicional que se deberá manejar para la comunicacion con el Servidor Centra Syslog, posteriormente reiniciamos (Asuminemos que el servicio para pruebas, ya está desplegado).


Desde SOAPUI ejecutamos la prueba del servicio respectivo y configurado:


Este lanzamiento registrará, la traza real del servicio en el archivo Log del servicio, generado en la Ruta Fija absoluta.


Así mismo, el mismo mensaje se registrará en el Servidor Central Syslog (Kiwi) de Logs.
 

Finalmente, solo que me queda mencionar que se ha tratado de mostrar uno de las tantas maneras y mecanismos que existen para la 'Centralizacion de Log', un poco más orientado a entornos SOA.

Para los interesados pueden descargar el Dummy del proyecto Log4jSyslog desde aquí: http://www.mediafire.com/download/ysjeyglklk8sa89/LoggerSyslog.zip


miércoles, 21 de octubre de 2015

'TEMPLATEs' & 'REUSE PROJECT' IN OSB 12c


Una característica muy resaltante e importante que brinda ‘Oracle Service Bus 12c’ (OSB), es la capacidad de definir y manejar Templates para diferentes tipos de proyectos OSB, en los cuales uno puede estandarizar dichos Templates en un SVN por ejemplo y compartirlos con el equipo de desarrollo para que realicen las implementaciones de los ‘Servicios Virtuales’ requeridas. Esto es importante ya que todo lo definido en los Templates se ajustan a reglas y directrices (estándares) del proyecto, esto significa eliminar la costumbre común de copiar y pegar de ciertas nodos del OSB (versión anterior 11g), y favorece la reutilización al 100%. OSB 12c cumple con tener un entorno de desarrollo mucho más integrado (vía Enterprise Manager) y con un más fácil modo de instalación como parte de todo la SOA Suite 12c.

En este artículo trataré de mostrar cómo utilizar esta nueva funcionalidad a base de Templates en OSB 12c, que tal como se comentó facilitará la construcción y reutilización de una gran cantidad de servicios a través de diferentes proyectos. Así mismo, comentaré son la reutilización de proyectos por referencia para manejar todo lo relacionado a recursos utilitarios de diferentes tipos a nivel general.

I. TEMPLATE:
El manejo de Templates se puede manejar de diferentes formas que son las siguientes:

A. En base a un proyecto existente:
En base a un proyecto existente, se puede generar un Template de la manera mostrada en la imagen, pero esto puede problemas y errores debido a las dependencias con Xquerys y archivos los cuales se tenga dependencia a nivel de rutas.


B. Definiendo Template desde cero:

El Template es creado desde cero desde la barra de menú:


Se define la ruta donde se almacenará el Template:


Dependiendo como se desee manejar el .WSDL a futuro, se define este punto. En mi caso recomiento manejarlo como WSDL SOAP (independiente de la versión), para que cuando se autogenere se exija el manejo del TopDown.



RECOMENDACIÓN:
Una recomendación que daría para el manejo de Templates, es de la siguiente manera:

Definir formalmente (estandarizar) Templates específicando, como se requieren manejar con relación a su implementación de los 'Servicios Virtuales' en sus organizaciones:

En mi caso he definido 3 posibles Templates:


- VirtualServiceAgnosticSOAP_Template.ptx:
Plantilla para AUTOGENERAR la estructura de un 'Servicio Virtual' con comunicacion AGNÓSTICA (Sin Transformación), el .WSDL debe ser reutilizado para la creación del 'Business Service' como para el 'Proxy Service'.


- VirtualServiceTransformSOAP_Template.ptx:
Plantilla para AUTOGENERAR la estructura de un 'Servicio Virtual' SIN comunicacion AGNÓSTICA (Con Transformación), el .WSDL requiere de modificaciones (campos extras) y/o modificación a nivel de Namespace. Debido a ellos los .WSDL's del 'Business Service' como para el 'Proxy Service', deben ser diferentes y america una transformación intermedia.


- VirtualServiceTransformGeneric_Template.ptx:
Plantilla para AUTOGENERAR la estructura de un 'Servicio Virtual' genérico, con espacio para para una implementación de tipo Secuencial.


- IMPORTANTE:
Los servicios en paralelos basados en 'Split-Join', NO pueden ser trabajados con Plantillas. En este caso deberán ser desarrollados como 'Servicios Virtuales' a medida.

El manejo recomendada a base de Templates, puede implementarse fácilmente tal como se muestra en la imágen, todos en un mismo proyecto y manejada la estructura, tal como se recomendó en un post anterior. Esto asegurará un correcto, rápido y estandarizado manejo con la organización.


II. REUSE PROJECT:
El manejo de reutilización de proyectos OSB, por referencia se maneja para casos como el que procederé a explicar.

Imaginemos que tal como se recomendó seguimos un estándar a nivel de estructura de directorios, y tenemos gran cantidad de 'Servicios Virtuales' que manejan de similar y repetida manera: (Xquery. Jar, Xsd, etc). Debido a este motivo es necesario definir y estandarizar también un mecanismo que permita reutilizar entre todos los proyectos lo mencionado.

Para ello es importante crear un estándar de proyecto OSB a modo utilitario donde se maneje todo lo explicado anteriormente. La propuesta de manejo sería la siguiente: 

Un directorio OSB en mi caso: UTILITY_OSB, que contenga en su interior los recursos:

  • ALERT: Alertas por nivel para ser referenciadas desde el interior de todos los proyectos. 
  • JAR: Librerías Java para ser referenciadas estáticamente para lo que son Log y Properties externos.
  • TEMPLATE: Plantillas base estándar para la generación de proyectos OSB por tipo.
  • XQUERY: Archivos de tipo XQuery para ser referenciadas desde el interior de todos los proyectos.
  • XSD: Archivos de tipo Xsd para el manejo de Auditoría, para ser incrustado a modo import/include en los .wsdl creados de todos los proyectos.

Este tipo de proyecto utilitario debe ser desplegado en el servidor (Cluster y Nodos), ya que la referencia será manejada a modo local, desarrollo como en los demás ambientes existentes en el servidor Weblogic.

No olvidar que las referencias todos los Templates estandarizados, deben estar totalmente documentados, para poder uno como desarrollador saber y tener conocimiento lo que ya está definido y falta agregar para implementar. Así mismo, todas las Templates están directamente relacionados con el tema de: Reuse Project, ya que sus recursos reutilizables referencian a lo existente en dicho proyecto utilitario OSB.  

 

Finalmente, se debe recordar tanto el manejo de: Templates, como el manejo de Reuse Project y el de Estructura de Directorios en OSB, es un tema también considerado como buenas prácticas en lo relacionado a estandarizar todo el proyecto, esto para llevar un mejor control de tal así como favorecer el desarrollo y mantenimiento respectivamente.


Para los interesados en los Templates propuestos, estos se pueden descargar desde aquí:



lunes, 19 de octubre de 2015

DEFINICIÓN DE ESTRUCTURA DE DIRECTORIOS EN OSB 12c


El manejo de los estándares en todo tipo de proyectos es importante, ya que permite definir un mismo modo de trabajo (un estándar), con relación a todo el equipo de desarrollo. Estos estándares pueden ser aplicados a prácticamente todo, desde fuentes, documentación etc.

A nivel de Oracle Service Bus (OSB), esto también es recomendable que se aplique, para la creación de los proyecto OSB relacionados los Servicios Virtuales: (Exposiciones, Virtualizaciones, etc). En esta oportunidad mostraré una forma de cómo estandarizar la Estructura de Directorios del proyecto OSB propiamente, con relación al manejo de un proyecto mediano/grande a nivel departamental. Dicha estructura de directorios debe ser capaz de soportar ser lo más ordenado y reutilizable posible, pensando en la gran cantidad de Servicios Virtuales que manejará internamente, así mismo como facilitar la segmentación y mantenimiento de estos.

La Estructura de Directorios propuesta, para este tipo de proyectos OSB de mediano/grande envergadura, así como la extensión de los archivos manejados por directorios, son las que se muestran en imagen:


Cada Estructura de Directorios tiene una finalidad con relación a lo que manejará en su interior. Esta estructura está bien detallada:


El contenido de los archivos deberán tener así como una ubicación fija (directorio), una nomenclatura estándar con relación al nombre del proyecto/servicio/operación manejado. La propuesta es la siguiente:


Finalmente, como se visualizaría dicha Estructura de Directorios estándar propuesta, a nivel de la herramienta sería de la siguiente forma: (Los nombres de empresa, servicios, etc, son subjetivos)


Así mismo, desde la consola OSB el agrupamiento departamental de los proyectos/servicios de tipo OSB, deberían visualizarse de la siguiente manera:


Espero que este post haya sido de gran importancia para eliminar duda alguna existente anteriormente, sobre la definición para el manejo de una correcta Estructura de Directorios en OSB.


CATCHING & LOAD BALANCING EN OSB


En post anteriores he explicado sobre la importancia del manejo del Cache en las aplicaciones y servicios por medio del framework Ehcache. En esta oportunidad daré detalles de cómo manejar dos temas muy importantes que son el Catching, así mismo como el Balanceo de Carga a nivel de Oracle Service Bus 12c.

Este artículo se ha creado para ayudar a aquellos que quieren poner en marcha el almacenamiento en caché por medio de OSB, ya que en él se describe cómo utilizar esta funcionalidad por medio de un ejemplo de cómo el cache maneja dicho almacenamiento y como distribuir la carga existente por medio del balanceo de carga, para mejorar el rendimiento por medio del caché y la configuración de equilibrio de carga en OSB. Así mismo,  OSB proporciona una funcionalidad que viene ya integrada, que es el soporte de caché por medio de Oracle Coherence, que brinda muchas estrategias de almacenamiento en caché, a continuación se procederá con la explicación.

Antes que nada, es necesario para el dummy preparado crear un Web Service con JaxWS, para ejecutarlo a modo local sin necesidad de desplegarlo en un servidor. Este Web Service expondrá dos servicios con diferente puerto simulando dos server distintos:
  • http://localhost:8098/ServidorWS_JAXWS_Generado/UsuarioDAOImpl?wsdl
  • http://localhost:8099/ServidorWS_JAXWS_Generado/UsuarioDAOImpl?wsdl


Luego, en la operación: sumar, hemos ingresado una línea para aplicar un delay de 10 segundos en la respuesta de dicho servicio, esto para probar posteriormente la eficacia del cache configurado.


Finalmente, crearemos en el OSB un Servicio Virtual de dicho servicio, en base al .wsdl (TopDown) ya expuesto. La URL de este servicio virtual será: 
  • http://localhost:7101/Operaciones_SB/Pipeline/OperacionesWS?wsdl



I. CATCHING:
Para el manejo del Caching en OSB, realizaremos la configuración en el: BusinessService (Operaciones_BS) previamenete ya creado. Luego, vamos a la opción: Performance y habilitamos el check: Enable Result Caching. Después, configuramos en: Expiration Time, a nivel de: Días, Hora, Minutos y Segundos, que se requiere que el Cache almacene la información para posteriormente refrescar con la nueva info. Esto se debe configurar en base a la información que proporcione el negocio en escenarios donde la información NO variará, esto para agilizar la respuesta y evitar consultas a BD y/o servicios por gusto.

Para este escenario del dummy, configuraremos solo la parte de los segundos (20 segundos), para que se refresque dicho cache en ese tiempo.


Desplegamos el Servicio Virtual dummy e iniciamos la consola de pruebas, tal como se muestra en imagen.


Verificamos que al ser ejecutado el Servicio Virtual, demora exactamente 10 segundos en mostrar la respuesta (ANTES de aplicar la configuración del cache).



Posteriormente, a la configuración del Cache, el tiempo de 10 segundos para la respuesta del Servicio Virtual, será aplicado solo la primera vez que se ejecute. Ya que a la siguiente vez automáticamente se activará el Cache configurado e iniciará el conteo de tiempo de 20 segundos configurado. Esto efecto se puede apreciar desde la consola misma de pruebas, ya que la primera vez demorará y luego de ello, uno puede ejecutar varias veces y la respuesta demorará menos de un segundo en responder, ya que se obtendrá del Cache respectivamente, durante el delay configurado.


II. LOAD BALANCING:
Para el manejo del Load Balancing en OSB, realizaremos la configuración en el: BusinessService (Operaciones_BS) previamente ya creado. Luego, vamos a la opción: Transport y seleccionamos el Algoritmo que más nos acomode (en este caso: round-robin). Luego, agregamos la segunda URL que al inicio del post definimos (con diferente puerto) a la lista y finalmente, el máximo número de reintentos posibles y el intervalo entre cada uno de estos.


Finalmente, volvemos a desplegar el Servicio Virtual en la consola OSB y validamos el efecto ya con todo el Balanceo de Carga configurado.


Esperemos que el post haya sido de su agrada y lo puedan aplicar de la mejor manera en sus proyectos OSB. Para los interesados en descargar las fuentes (Eclipse & OSB) lo pueden hacer aquí:


(XSD) INCLUDE vs (XSD) IMPORT


Tanto en los proyectos SOA donde existe la necesidad de orientar la arquitectura a nivel de servicios, como en las exposiciones de sistemas Legacy y Virtualizaciones de Servicios por medio de OSB, en todos estos proyectos nace la necesidad de desarrollar servicios de tipo Web Service. Ahora, durante el diseño de dichos Web Service lo primero que se requiere hacer son los contratos de servicio (.wsdl), ahora nace aquí el problema ¿cómo los diseño?..., por medio de una IDE o manualmente, en mi caso yo recomendaría inicialmente apoyarse en una IDE como JDeveloper o Eclipse que manejan editores que facilitan de algún modo su creación, posteriormente cuando ya tengan práctica y como yo acostumbro hacer, por rapidez y conocimiento, es definir una plantilla base y desde ultraEdit aplicar replace a los nombres estándar de: wsdl:definitions, Namespace, xsd:element, wsdl:message, wsdl:binding, wsdl:service, wsdl:port, soap:address, wsdl:part, wsdl:operation. Así mismo, la edición del modelo de negocio dentro: wsdl:types.

Jústamente, aquí es la idea de este post, ya que es recomendable NO embeber el modelo por medio de los: wsdl:types, dentro de las interfaces: .wsdl. Aquí se genera la gran duda de muchos profesionales que es: ¿Cómo lo manejo con Include o con Import?, ¿Cual es la diferencia de ambos?, y que así nomás no se encuentra su explicación. La diferencia es la siguiente:

xsd:include
Se debe usar cuando se requiere manejar los datos de un .xsd con un mismo Namespace.

xsd:import
:  
Se debe usar cuando se requiere manejar los datos de un .xsd con un diferente Namespace

Esto quiere decir que la gran diferencia entre ambos en a nivel de como uno diseñe su contrato de servicio, específicamente a como segmentará .wsdl y .xsd's con relación a sus Namespace.

Procederé a explicar mejor por medio de un dummy de un diseño que he creado para su mejor entendimiento, este consiste en un .wsdl y tres modelos .xsd:

ObtenerTecnologia.wsdl, este es el contrato de servicio el cual se ha diseñado para que NO se alterado y/o modificado posteriormente. Maneja un Namespace definido como: http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS, y segmenta su modelo de negocio de manera externa a el, por medio de un xsd.include ya que manejará el mismo Namespace

[xsd:include schemaLocation="./ObtenerTecnologia.xsd" /]



ObtenerTecnologia.xsd, es el modelo principal y base del contrato, este se ha diseñado para manejar un mismo contrato que dicho contrato: http://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS. Así mismo, desde el se referenciará a los demás modelos .xsd que se han creado:

- Persona.xsd: la referencia con relación a este modelo, será por medio de xsd.include: [xsd:include schemaLocation="./Persona.xsd" /], ya que dicho .xsd SI manejará el mismo Namespacehttp://pe.com.eai.dummySOA/bean/obtenerTecnologiaWS

- Auditoria.xsd: la referencia con relación a este modelo, será por medio de xsd.import: [xsd:import namespace="http://pe.com.eai.dummySOA/bean/auditoria" schemaLocation="./Auditoria.xsd" /], ya que dicho .xsd NO manejará el mismo Namespace (ya que este modelo será REUTILIZABLE entre diferentes proyectos). El NameSpace que manejará será: http://pe.com.eai.dummySOA/bean/auditoria


Persona.xsd
, es el modelo donde será definido los campos embebidos en los objetos: simpleType, complexType, relacionados directamente al negocio que el servicio implementado utilizará.


Auditoria.xsd
, es el modelo donde será definido los campos de auditoría especificamente, embebidos en los objetos: simpleType, complexType, que serán REUTILIZADO en diferentes proyectos (modelos).  


Finalmente, con esto se completa la explicación del post. Para los interesados en el diseño explicado, pulsar aquí:
http://www.mediafire.com/download/l152h524h6l2rrb/xsd.include++VS++xsd.import.zip


domingo, 18 de octubre de 2015

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