lunes, 14 de diciembre de 2015

DINAMIC PROXY CLIENT WS


En esta oportunidad comentaré sobre cómo consumir Servicios Web de manera dinámica.

En proyecto donde el paradigma de la orientación a servicios es aplicado, es imprescindible para la comunicación entre servicios la generación de un Proxy Client del servicio Provider dentro de la aplicación consumidora (Consumer). Para cumplir esto existen actualmente muchas apis en JAVA que facilitan dicho manejo, tanto para generar el servicio (TopDown), como para consumirlo. Entre estas apis JAVA existan: Axis1, Axis2, JaxWs, JaxRpc, etc. Estas apis permiten mediante el TopDown aplicado generar las clases y objetos JAVA siguiendo la estructura de Wsdl/Xsd para poder hacer Get/Set de los datos según convenga.

Esto es bueno pero y estándar, pero existe una transformación detrás de este manejo. Por otro lado, es bueno saber que estas apis facilitan el manejo siempre y cuando la estructura de diseñada del WS, no sea compleja, ni dinámica. Esto se menciona ya que en algunas ocasiones debido una alta complejidad en la estructura (Request/Response), seguridad, etc del servicio provider, es necesario manejar un proxy client de manera dinámica.

Para estos escenarios es bueno conocer que se puede crear un Proxy Client dinámico, que se adapte a cualquier escenario que el negocio requiera y armar los Request. Así mismo, para obtener los datos del Response por más compleja que sea la estructura de respuesta, en vez de manejar un api Jaxb (transformación), nos podemos apoyar en "XPath" ..., ya que por medio de este lenguaje de expressions podremos navegar entre las estructuras XML del Response de una manera muy veloz y potente.

El dummy preparado permite mostrar todo lo mencionado anteriormente.

1. Desplegamos un WS, median un Mock en SOAPUI y así simular un WS Provider:

2. Definir los métodos que servirán para el procesamiento Rquest/Response y el Main que simulará el lanzamiento:

3. Se debe mapear diferentes puntos propios del servicio: URL, Namespace, ServiceName, PortName, TimeOut, etc:

4. Se definen los métodos: procesarRequestWS y procesarResponseWS:

5. Se arma el Request XML, independientemente de la estructura y/o complejidad que se tenga (esta puede está incluso mapeada en .properties y ser reutilizada):

6. Aquí se muestra el poder de XPath para obtener los datos de la cadena XML Response, independientemente que sea un dato y/o lista, se debe entender que todo en si son cadenas y se pueden manipular y obtener como tales por medio de las sentencias XPath propiamente:

7. El resultado de la prueba y consumo respectivo se muestra en LOGs:

Con esto espero haber demostrado comoconsumir dinámicamente un WS, sin usa una sola api adicional, todo apoyandonos en las librerias del JDK, así mismo como el apoyo del poderoso XPath ...!

Para los interesados, se puede descargar las fuentes del dummy aquí:
http://www.mediafire.com/download/ctbw2389i8dabaf/DummyDinamicProxyWs.zip


domingo, 15 de noviembre de 2015

WSDL 1.1 vs WSDL 2.0


Desde el 2007 la (W3C), como consorcio internacional para el desarrollo de estándares Web, publicó lo que se conoce como el futuro y mejorado estándar para servicios, el estándar WSDL 2.0.

Esta versión nueva de WSDL 2.0 maneja varias diferencias y mejoras con relación a su antecesora y aún estándar WSDL 1.1, que son las siguientes:
  • El WSDL 2.0 integra el elemento Message dentro del elemento Types, con relación al WSDL 1.1
  • El WSDL 2.0 renombra el elemento PortType como Interface, con relación al WSDL 1.1
  • El WSDL 2.0 renombra el elemento Port a Endpoint, con relación al WSDL 1.1
  • El WSDL 2.0 renombra lo parte inicial de declaración en la interface conocida como Definitions como Description, con relación al WSDL 1.1
 

 

El modelo WSDL 2.0 también impone restricciones semánticas más allá de la conformidad estructural. Con el fin de describir con precisión estas limitaciones, y como ayuda para definir con precisión el significado de cada documento WSDL 2.0, la especificación WSDL 2.0 define un modelo de componentes como una capa adicional de abstracción por encima del conjunto de información XML. El siguiente diagrama ofrece una visión de los componentes de WSDL 2.0 y su herencia.


Esta nueva estructura del modelo WSDL es más amigable, mejor diseñada y entendible. Así mismo, lo resaltante de esta versión de WSDL 2.0 es que permite a los desarrolladores elegir el modelo de desarrollo de aplicaciones de Servicios: HTTP o SOAP. Esto debido a la creciente popularidad del modelo REST y SOAP.Con respecto al HTTP, se reconoció la clara necesidad de la compatibilidad con HTTP en las descripciones de aplicaciones Web (contratos). Por tanto, el WSDL 2.0 ofrece una compatibilidad absoluta con HTTP y SOAP, lo que lo hace muy útil tanto para aplicaciones Web sencillas, como para aplicaciones de Servicios Web que requieran de funcionalidades adicionales.

Lo desagradable es que actualmente hasta la fecha, esta versión de WSDL 2.0, no se ha vuelto aún estándar, debido a ello herramientas muy conocimiento como lo son: SOAPUI, ORACLE, IBM y apis como JAXWS aún NO lo soportan, teniendo conocimiento que el único que si lo soportar es AXIS2. Esto quiere decir que seguiremos usando como estándar para nuestros desarrollos el WSDL 1.1 por algo más de tiempo.Finalmente, los que desee actualmente existe un conversor de WSDL 1.1 a WSDL 2.0 (http://www.w3.org/2006/02/WSDLConvert.html), para que se alguna manera, para los que no se acostumbran aún, de esta manera les sea más fácil la transición al nuevo futuro estándar.


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