sábado, 14 de diciembre de 2013

ESB de WSO2 y Transacciones.

El ESB de WSO2 es un buen ESB pero a veces es  frustante la falta de documentación apropiada en determinados temas como pueden ser las transacciones.

En su documentación en línea podemos ver el mediador transaction.
Y en el ejemplo que usan siempre lo ponen de conjunto con el mediador dbreport en operaciones CRUD sobre bases de datos.

La realidad es que los usuarios de este ESB buscan mucho más que eso y  se puede evidenciar cuando vemos las preguntas hechas en SO. Algunas de las cuales son:

  1. How to Manage Transaction across sequences in WSO2 ESB
  2. WSO2 ESB Distributed Transations
  3. In WSO2 ESB 4.7.0 can we do JMS rollback in receiving sequence?
Y ahora acabo de encontrar esta otra.

Entre mis preocupaciones están las siguientes:

  1. Se puede usar el mediador transaction con cualquier otro mediador? Esto no queda claro en la documentación.
  2. Se puede usar el mediador transaction para acciones realizadas en varias secuencias? En las respuestas dadas en SO tal parece que no, pero esta información no aparece en la documentación oficial del ESB de WSO2.
  3. En vez de seguir poniendo siempre el mismo ejemplo de uso del mediador en cada nueva versión de la documentación del ESB, por qué no incluir nuevos ejemplos que respondan a las preguntas hechas por la comunidad de desarrollo de WSO2 en StackOverflow?
Al final terminé posteando una pregunta en SO con algunas de estas preocupaciones.

Introducción al ESB de WSO2 a través de ejemplos prácticos. III



Para darle continuidad a la serie de introducción al ESB:

En esta entrada veiamos como se podía solucionar un problema a través del ESB de WSO2.

Luego en la segunda entrada  veíamos como se podía implementar un servicio proxy en el ESB para darle solución al problema planteado en la primera parte, e incorporar elementos de seguridad y prueba usando el SOAPUI.
 
En esta tercera entrada quisiera compartir con ustedes una forma muy útil de agregar seguridad de grano fino a nuestros servicios y aplicaciones web con la ayuda del WSO2 ESB y el WSO2 IS.

Ahora solo presentaré un diseño de alto nivel, en otra entrada veremos su implementación.

La idea parte de definir una arquitectura de seguridad para una organización que se va moviendo hacia un entorno orientado a servicios, donde deben coexistir aplicaciones legadas y  compuestas, así como servicios web y restful, y todo debe estar protegido por políticas de seguridad a diferentes niveles de granularidad.


La arquitectura genérica puede ser la siguiente:


Todos los accesos se realizarían a través del ESB de WSO2 el cual controlaría con la ayuda del WSO2 IS quien tiene acceso o no a los servicios.
Para lograr esto se dispone de un repositorio de políticas de autorización y de un almacén de credenciales.
 
El cómo interactúan el ESB y el IS de WSO2 se ve en la siguiente imagen.



De esta manera la seguridad se puede definir a nivel de políticas, no solo de roles, con un nivel tan detallado como se desee, esto se logra gracias a la arquitectura XCML que implementa el IS de WSO2

En otra entrada estaremos viendo cómo se implementa esta solución en el ESB+IS de WSO2.

martes, 10 de diciembre de 2013

WSO2 y el monitoreo de aplicaciones web en Java.


La suite de WSO2 tiene cosas para casi todo, y en esta entrada quisiera compartir con ustedes una de las que más utilidad queremos sacar. El monitoreo de aplicaciones web.

La idea es que buscamos saber de las aplicaciones web la siguiente información:

  • Cantidad de solicitudes de acceso, respuesta e intentos fallidos.
  • Promedio del tiempo de respuesta de la aplicación web.
  • Tiempos mínimos y máximos de respuesta.
  • Cantidad de visitas de usuarios.
  • Tiempo promedio de estancia de los usuarios en la aplicación web.

Para lograr esto basta con seguir los pasos explicados en el siguiente tutorial [1] y podrán monitorear todo lo anterior. A continuación les dejo algunas pantallas para que puedan ver.




Enlaces:


viernes, 6 de diciembre de 2013

WSO2 Identity Server. Otro caso de éxito más.

Estaba revisando un nuevo caso de éxito de WSO2 relacionado con el tema de la seguridad y como una imagen vale más que mil palabras aquí les dejo la siguiente:


Se trata de un proyecto desarrollado en Arabia Saudita, para gestionar diferentes programas relacionados con la seguridad social y programas de asistencia para personas sin empleo, los cuales permitan que se entren solicitudes de trabajo y se gestionen diferentes tipos de pagos.

El tema en cuestión es que este proyecto inició con un solo programa, luego al incorporársele nuevos programas identificaron  la necesidad de un mecanismo de gestión de las identidades para todos los involucrados en los programas, y de un mecanismo de  autenticación centralizado que implementara el Single Sign On, o la autenticación única, la cual permite que una vez autenticado en un sistema ya no tengas que autenticarte nuevamente en los otros sistemas asociados al mismo dominio de seguridad, lo cual facilita a los usuarios la gestion de sus credenciales ya que solo necesitan una para todos los sistemas y no una para cada uno de ellos.

Nos comentan que la primera decisión arquitectónica tomada fue escoger entre los diferentes proveedores de sistemas para implementar SSO y al final se decantaron por el WSO2 Identity Server. La segunda decisión fue escoger entre OpenID y SAML, seleccionando finalmente a OpenID.

La implementación de la solución llevó 2 meses y el resultado final el siguiente:


Un clúster de 5 instancias del WSO2 Identity Server que permiten manejar 2000 peticiones de autenticación por segundo, con 4 millones de usuarios. Claro que eso no es todo, así que los invito a ver el pdf original.

Pueden ver el artículo en [1].



domingo, 17 de noviembre de 2013

WSO2. CEP. II - Input Event Adaptors

Hola buenas,

  Ya que este es mi primer post me voy a presentar primero, me llamo Andrés Gómez Ferrer y soy estudiante de ingeniería de telecomunicación en la Universidad de Sevilla, España.

    Introducción

  Como ya os advirtió Jorge en el último post acerca de WSO2-CEP, vamos a hablar para comenzar de la primera parte de CEP, ya que podemos decir que esta separada en módulos como se puede ver en la figura1.

Figura1. Modulos de CEP.

  En este post nos vamos a centrar concretamente en el modulo de entrada o también conocido como "Input Event Adaptor". El software de CEP trae por defecto en su paquete los siguientes adaptadores:

  1. email
  2. jms
  3. ws-event
  4. ws-event-local
  5. wso2event
  Donde podemos encontrar más información acerca de ellos en el siguiente enlace: Input Event Adaptors

  Aparte de estos adaptadores, también podemos crear los nuestros personalizados que posteriormente se integran en el sistema con bastante comodidad. Esto quizás pueda ser más interesante y ya que la información es algo más escasa en la web nos detendremos algo más, de todas formas aquí os dejo el enlace al manual: Custom Event Adaptors .

  Comenzar mencionando que hay dos tipos de Custom Event Adaptors, los de entrada y los de salida en este post vamos a analizar únicamente los de entrada, y posteriormente en otro post comentaremos los de salida.

    Preparación del entorno.

  Mi recomendación para trabajar con los custom event adaptors es utilizar un IDE como puede ser ECLIPSE o NETBEANS ambos software libre y fácil de encontrar. El adaptor de entrada se crea a partir de un OGSI Bundle, por lo que debemos empezar creando un proyecto de este tipo. Personalmente trabajo con netbeans y es fácilmente crear un proyecto MAVEN del tipo OGSI Bundle, si usamos MAVEN deberemos incluir en el pom.xml el siguiente repositorio:

<repositories> 
     <repository> 
          <id>wso2-maven2-repository</id> 
          <name>WSO2 Maven2 Repository</name> 
          <url>http://dist.wso2.org/maven2</url> 
     </repository> 
</repositories>

y las siguiente dependencia:

<dependency>
         <groupId>org.wso2.carbon</groupId>
         <artifactId>org.wso2.carbon.event.input.adaptor.core</artifactId>
         <version>1.0.0</version>
 </dependency>

  Que sera necesario para acceder a las librerías que usa el adaptor, por otro lado si preferimos incluir las librerías como jar, también las podemos encontrar en <CEP_HOME>/repository/components/plugins/org.wso2.carbon.event.input.adaptor.core_1.X.X.jar

    Profundizando en el código

Tenemos que crear una clase que extienda de la clase "AbstractInputEventAdaptor", la cual contiene los siguientes métodos:

-> Metodo que devuelve un string con el nombre que se mostrada en la web de gestión de CEP.
String getName()

-> Devuelve una lista con los tipos de mensajes soportados para el event builder, pueden ser:
       * JSON
       * MAP
       * TEXT
       * XML
       * WSO2EVENT 
List<String> getSupportedInputMessageTypes()

-> Metodo que se llama a la hora de ejecutar. Normalmente se usa para indicar las Propiedades.
void init()

-> Se definen la características configurables desde la web para tu custom adaptar.
List<Property> getInputAdaptorProperties()

-> Se definen la características configurables desde el eventBuilder.
List<Property> getInputMessageProperties()

-> Es el metodo que se va a ejecutar y el cuerpo de nuestro custom adaptor, se llama al instanciarlo.
 String subscribe(
            InputEventAdaptorMessageConfiguration inputEventAdaptorMessageConfiguration,
            InputEventAdaptorListener inputEventAdaptorListener,
            InputEventAdaptorConfiguration inputEventAdaptorConfiguration,
            AxisConfiguration axisConfiguration)

-> Es el metodo que se va a ejecutar cuando se cierre el wso2-CEP.
void unsubscribe(
            InputEventAdaptorMessageConfiguration inputEventAdaptorMessageConfiguration,
            InputEventAdaptorConfiguration inputEventAdaptorConfiguration,
            AxisConfiguration axisConfiguration, String s)

  Vamos a centrarnos algo más en el metodo suscribe donde ya que es el corazón de nuestro adaptor, comenzamos mencionando algunos de los parámetros que tienen mayor intereses.

  * inputEventAdaptorMessageConfiguration: Obtenemos la configuración introducida en la ventada de eventBuilder para ello usamos el metodo getInputMessageProperties().

  * inputEventAdaptorListener: Podemos considerarlo la puerta de enlace entre nuestro adaptador y CEP, ya que mediante su metido .onEvent() se envían los mensajes a CEP.

  * inputEventAdaptorConfiguration: Obtenemos la configuración introducida en la ventada de eventBuilder para ello usamos el metodo getInputProperties().

  Después de configurar a nuestro gusto el adaptor, tenemos que crear una clase que implemente "InputEventAdaptorFactory" la cual solo contiene un metodo llamado: AbstractInputEventAdaptor getEventAdaptor() el cual devuelve una instancia creada de la clase de nuestro adaptor "AbstractInputEventAdaptor".

En el próximo post, seguiremos hablando de los Input Event Adaptors y analizaremos a fondo un Custom Adaptors para apache-Kafka-0.8.1 con zookeeper.

Un saludo,

Andrés Gómez

viernes, 15 de noviembre de 2013

Escenarios de aplicación de SOA

Como muchos deben saber SOA es un concepto no es algo concreto, es una forma de pensar cuando tenemos que resolver determinados problemas. Y generalmente estos problemas se enmarcan en determinados escenarios donde podemos aplicar lo que SOA como paradigma y estilo arquitectónico nos da: guías, patrones, principios, buenas prácticas, etc.

Un resumen de estos escenarios se pueden ver en la siguiente imagen.



A groso modo estos escenarios exponen dos temas fundamentales: integración e interoperabilidad entre diversas soluciones.

Una breve descripción de los escenarios de la imagen.
  • Optimización de procesos de negocio: Se basa en un problema común de las empresas que definen sus procesos de negocio por un lado y compran aplicaciones por otro lado, existiendo un defasaje entre procesos y aplicaciones que generalmente termina en que las aplicaciones son las que dictan como se hacen las cosas dentro de la empresa, un ejemplo común es cuando una empresa compra SAP o algún otro ERP. Con la ayuda de SOA y BPM, se pueden exponer las funcionalidades principales de las aplicaciones legadas existentes como servicios, rediseñar e implementar los procesos usando BPMN y BPEL y vincular entonces las actividades de esos procesos con los servicios expuestos por las aplicaciones. Esto conlleva a la posible creación de nuevas aplicaciones e incluso a exponer procesos como servicios que puedan ser consumidos por clientes, socios y proveedores de la empresa.
  • Integración: Otro problema muy normal en las empresas que genera la compra sin mucho pensar de aplicaciones es que estás están desarrolladas para diferentes sistemas operativos, en variadas plataformas tecnológicias y lenguajes de programación, y no fueron diseñadas para comunicarse entre si. Por lo que a la hora de querer combinar dos o más es prácticamente imposible hacerlo. SOA y los patrones de integración permiten resolver este problema.
  • Racionalización del portafolio de aplicaciones: de conjunto con los dos escenarios anteriores, el uso de los principios de SOA permite definir cuales son las funcionalidades de TI que requiere una empresa, y donde estas residen, en qué aplicaciones, y entonces se pueden tomar decisiones sobre qué aplicaciones dejar, cuales eliminar, o cuales combinar en nuevas aplicaciones que oculten las viejas para los usuarios final. El resultado es un portafolio renovado de aplicaciones, muy ágil y dinámico que ahorra $$ y trabajo a los departamentos de TI.
  • Federación: Los escenarios anteriores generalmente van a lo interno de la empresa. Este escenario se basa en como la empresa se relaciona con otras empresas y negocios y como puede formar parte de la actual globalización luchando por un posicionamiento en el mercado. SOA permite esta integración global donde no solo se exponen funcionalidades, si no identidades y se externalizan determinados recursos de la empresa a ser desarrollados o brindados por otras empresas. Esto mejora el ROI y permite a empresas que no pueden darse el lujo de tener grandes departamentos de TI de poder usar recursos de otras empresas que se brindan como servicios.

En la siguiente imagen se pueden ver estos escenarios un poco más desglosados y con una representación en cuanto a tiempo de duración, su orientación en la empresa y su alcance.



En la imagen se muestran los distintos escenarios en función de su alcance, el tiempo de duración y quien es el que lo conduce, si es el Negocio o el departamento de TI de las organizaciones.

martes, 12 de noviembre de 2013

WSO2 y su Procesador de Eventos Complejos. CEP. I


Todas las empresas para sus operaciones y transacciones diarias deben generar un sinnúmero de información a ser intercambiada entre emisores y receptores. Si estas acciones son automatizadas en sistemas informáticos pues tendremos un gran flujo de información a través de las redes de la empresa y hacia y desde el exterior. Este flujo de información consiste en un flujo constante de eventos que se generan y aquellas empresas que son capaces de capturar y analizar en tiempo real los eventos tienen una ventaja mayor con respecto a sus competidores. Esto se debe a que pueden saber qué pasa en todo momento en su negocio y reaccionar rápidamente ante eventos o patrones incorrectos.

Claro que implementar una solución que capture los eventos, los procese y genere respuestas en dependencia de los patrones que ocurran no es tarea fácil, y es ahí donde WSO2 viene a nuestra ayuda.

El CEP o Complex Event Processor de WSO2, que en español vendría siendo “Procesador de Eventos  Complejos” es una herramienta que recibe eventos generados por el resto de las herramientas de la suite y cualquier otra solución que se configure para ello, y es capaz de determinar en tiempo real si determinados patrones de eventos están ocurriendo y reaccionar ante ellos. Está de más decir que la herramienta está bajo licencia apache v2, y que tiene un alto rendimiento y escala de lo mejor.

Cuando comentaba que recibe eventos de las herramientas de la  suite y de cualquier otra herramienta que se configure para que lo haga, es que en el caso de las herramientas de la suite hay que ajustarlas para que todos los eventos generados por ella sean enviados al servidor del CEP, y en el caso de otros tipos de herramientas o soluciones informáticas pues igualmente hay que implementar para que hagan lo mismo. Por suerte es muy similar a como se hace con el BAM.

La arquitectura del CEP puede verse como un poco compleja al inicio, pero es bastante fácil de entender:


Como ven los eventos son generados de diferentes maneras, bien sea a través de brokers de mensajería, a través de los publicadores de datos de WSO2, vía email o por llamadas REST.

Cuando estos eventos llegan al CEP son recibidos por un “Input Event Adaptor” que se corresponde a la forma en que se mandó el evento recibido. Lo interesante es que si hemos implementado una aplicación que manda los eventos al CEP de una manera no registrada aquí, pues podemos implementar nuestro propio adaptador e incluirlo dentro del CEP. Espero que pronto veamos un trabajo realizado en este tema en el blog.

Luego los eventos son pasados al “Event Builder” que se encarga de convertir el formato de los eventos a un formato estándar “WSO2Event” y de esta manera llegan los eventos al core del CEP, el “Event Processor”.

En el “Event Processor” se manejan diferentes planes de ejecución con la ayuda de Siddhi, que es el framework base usado por el CEP para el manejo de eventos. Aquí es donde ocurre la “magia”. Y veremos como se hace en otras entradas de esta serie sobre el CEP.

Luego los eventos son nuevamente convertidos de “WSO2Event” a su formato de destino  en el “Event Formatter”.

La publicación de los eventos ocurre entonces en el “Output Event Adaptor ” encargado de mandar los eventos publicados a sus destinatarios.

Para entender la utilidad del CEP veamos algunas cosas que se pueden hacer:

  • Se puede implementar un plan de ejecución que detecte en tiempo real cuando el precio de determinadas acciones en el mercado han cambiado un más de un 2% en menos de 1min, y notificar a los usuarios subscritos a este evento.
  • Se puede implementar un plan de ejecución que detecte en tiempo real cuando un vuelo viene retrasado y notifique a los usuarios subscritos a este evento, bien sea vía correo electrónico, sms, o a través de una aplicación web.
  • Se puede implementar un plan de ejecución que detecte múltiples intentos de autenticación erróneos usando una misma cuenta, por ejemplo desde diferentes IP, o con un criterio de más de 5 intentos en un segundo, y notificar al dueño de la cuenta.

Y así cualquier cosa que se quiera detectar se puede implementar usando el CEP de WSO2, y lo más interesante es que será en tiempo real.

lunes, 11 de noviembre de 2013

WSO2 y su arquitectura basada en componentes OSGI

Cuando en las clases de la universidad me decían que la arquitectura que estaba diseñando estaba basada en componentes y usando UML tenía que diseñar los diagramas de componente y despliegue según RUP, realmente no entendía el alcance de lo que estaba haciendo.

Luego comprendí el poder de una arquitectura basada en componentes, al permitir una reutilización casi total de los mismos. Y digo casi total porque cuando leí un libro sobre OSGI fue que entendí que realmente lo que diseñaba antes no era componentes completamente reutilizables y desacoplados, si no que solo se acercaban un poco a la idea de los teóricos de este tipo de arquitectura.

Con OSGI si se puede tener componentes 100% reutilizables y desacoplados completamente, y que esta arquitectura sea usada por WSO2 pues lo hace más geníal aun.

WSO2 con su suite de productos tienen un núcleo base, llamado WSO2 Carbon, es el framework donde están todas aquellas funcionalidades requeridas por todas las herramientas.

Luego las distintas herramientas son la suma del framework CARBON más un conjunto de features, que le dan el "sabor" a cada producto.

En la siguiente imagen pueden ver lo que les explicaba de forma gráfica. Si quisieramos tener el BAM solo tendríamos que usar el framework CARBON más las features que se corresponden al BAM y listo.



Pero bueno, WSO2 nos elimina este paso al darnos ya cada herramienta lista para ser usada, aunque queda la idea de mezclar herramientas e ir creando plataformas nuevas en función de nuestros requerimientos.

Y eso es lo que estamos haciendo en mi  trabajo ahora con el WSO2 BAM y el WSO2 CEP:
tener en una sola plataforma las capacidades análiticas y de almacenamiento del BAM de conjunto con un potente motor de eventos complejos, de esa forma tendremos el monitoreo en tiempo real y basado en estadísticas, un 2 en 1.

Para saber donde están las features de cada versión de las herramientas, les recomiendo usar este enlace.

WSO2: Mejorando la relación B2D gracias al AppFactory.


En una entrada muy interesante, Asanka Abeysinghe , desarrollador de la empresa WSO2, nos comentaba sobre la relación entre negocio y desarrolladores en el nuevo enfoque de la Computación en la Nube y el desarrollo basado en APIs.

El autor menciona que gracias al uso de las APIs se puede controlar y gestionar la forma en que los recursos interno de una organización se exponen hacia sus clientes y consumidores, de manera segura y bajo un gobierno previamente definido. Esto se puede lograr usando el API Manager de WSO2.

El problema según Asanka es que eso no es suficiente para tener un gestión adecuada sobre las aplicaciones que  usan estas APIs, y pone el ejemplo del entorno de trabajo que debe montar los desarrolladores para implementar las aplicaciones. Argumenta que aun cuando todos los desarrolladores usan los mismos lineamientos en cuanto a la tecnología a emplear sus entornos de trabajo no son identicos y para lograr resolve este tema y todos los demás relacionados con la gestión de las aplicaciones propone el uso de WSO2 App Factory.

Las razones son diversas pero todas dan en la diana:

  1. Se soluciona el problema de la creación de los ambientes de trabajo pues estos estarán ya creados con posibilidad de ser modificados, en la Nube.  Incluso los entornos locales se pueden mantener sincronizados con los entornos de desarrollo y todo el conjunto de construcciones, pruebas y despliegues se realizan de manera online.
  2. Respecto al código fuente argumenta que el AppFactory se basa en templates, ya sea para proyectos, código y procesos, lo que acelera mucho el desarrollo disminuyendo los tiempo y aumentando los ahorros por proyecto.
  3. El desarrollo basado en APIs está por defecto con acceso al AppStore desde donde se podrá tener acceso a las APIs existentes y consumirlas de forma segura.
  4. Se mejora y mucho el tema de integración continua, ya que al crearse un proyecto automáticamente se le asocia un sistema de control de versiones y gracias a maven se puede vincular con los test de pruebas, automatizando esta parte tambien, para los diferentes ambientes de trabajo creados.
De esta manera los invito a probar el AppFactory entrando a este enlace.

domingo, 10 de noviembre de 2013

Hace poco pude leer esta entrada http://engwar.com/blog/2013/07/01/introduction-to-wso2-platform/ y la verdad es que me gustó mucho. Les haré un resumen en español pero los invito a que la lean desde la fuente   :-D

El autor nos habla sobre un banco ficticio que ha desarrollado un sistema que tiene varios módulos, asociados a sus operaciones diarias. Dado lo simple del sistema fue hecho en PHP sobre un servidor Apache. Algo como esto:

Este sistema entra en producción y claro está, siempre que un sistema es nuevo la gente comienza a usarlo y  a querer que haga más cosas. Así que aparecen un conjunto de nuevos requerimientos, algunos de ellos son:
  • Se necesita que la Interfaz de monitoreo del sistema se pueda ver desde un Ipad, y quien dice un Ipad dice desde cualquier dispositivo móvil.
  • Se necesita tener la posibilidad de cambiar las reglas de negocio sin tener que editar/modificar el código PHP cada vez que se requiera.
  • Se requiere que uno de los módulos se pueda integrar con un nuevo sistema que se está desarrollando por otro conjunto de desarrolladores, fuera de la empresa.
  • Se necesita exponer información sobre las cuentas y usuarios hacia bancos para crear listas negras de malos usuarios.
  • Se necesita un mecanismo para detectar rápidamente operaciones fraudulentas sobre las transacciones en las tarjetas de crédito.
  • Se necesita que este sistema se integre con algunos sistemas viejos que existen en el banco para que extraiga información de ellos y la muestre desde la nueva interfaz gráfica.
  • Se usará un sistema de procesamiento de cheques de otro banco, por lo que toda la información relacionada con los cheques debe ser enviada vía internet hacia ese otro banco de forma segura y confiable.
Y bueno ya esto es un dolor de cabeza para los desarrolladores en PHP que tenían un simple sistema monolítico con unos cuantos script en PHP que se conectaban a una BD.


Algunos problemas que aparecen son:
  • Todos los módulos están en un mismo sistema y servidor.  Si uno de estos módulos es de alto tráfico y colapsa, pues el sistema completo colapsa.
  • Si se desea separar las funcionalidades se puede hacer usando XML-RPC para llamadas remotas, pero hay que tener en cuenta que entonces se debería proteger la comunicación entre los módulos desplegados en diferentes servidores.
  • Para asegurar las comunicaciones habría que encriptar la información en cada nodo, así que tendríamos mucho código duplicado.
  • Las dependencias aumentarían así que habría que asegurarse que si un módulo se cae, el resto de los módulos pueda seguir funcionando de manera estable y transparente para los usuarios.
  • El tema de escalar esta solución también es un problema. Se llega a un momento en que tendremos un montón de servidores Apache, balanceados a través de un BC(balanceador de carga) y hay que pensar cómo manejar las sesiones de los usuarios que van de un módulo a otro.
  • Otro problema viene con las pruebas al sistema, las cuales deben ser lo suficientemente abarcadoras para garantizar que todo el sistema funcione como debe, que sea escalable, robusto y seguro.
Como ven son muchos problemas para la simple aplicación del inicio.
En la entrada original vuelven a listar los requerimientos antes de entrar en el tema de WSO2, así que lo hago también acá para nuestros lectores de habla hispana:

  • La aplicación debe soportar múltiples UI en múltiples dispositivos.
  • Se debe abstraer determinada lógica de negocio en un conjunto de reglas, y manejar estas reglas de forma separada al código de la aplicación.
  • La información debe ser fácilmente integrable con otros sistemas.
  • La información debe ser expuesta de forma segura fácilmente hacia otros sistemas y personas. Puede ser requerido un acceso basado en roles.
  • El sistema debe ser capaz de identificar patrones en las transacciones realizadas.
  • El sistema debe ser capaz de integrar sistemas legados.
  • El sistema debe ser capaz de exponer y enviar información de forma confiable sin perder ningún mensaje en el camino.
  • Cualquier parte del sistema debe ser fácilmente escalable.
  • Se debe tener un sistema de monitoreo que fácilmente pueda seguir los nuevos módulos añadidos.
  • Cuando el sistema esté distribuido en diferentes nodos debe ser capaz de garantizar la seguridad en las comunicaciones entre cada parte del mismo.

Enfocados en WSO2 se propone lo siguiente:

  • Para la capa de presentación se puede usar un framework como Jaggery, que aunque verde aun, ya deja hacer sus cosas. Personalmente me fuera por algo como ZK, Vaadin, SP, Primefaces, etc..
  • A la hora de conectar mis UI con la lógica de negocio, lo que se estila ahora es tener un conjunto de APIs las cuales constituyen la capa de más arriba a la cual se conectarán todos los sistemas que deseen tener acceso a los datos y funcionalidades. Para esto se puede usar el API Manager, AM, de WSO2.
  • Siguiendo hacia abajo las APIs necesitan interactuar con la lógica de negocio que contiene las funcionalidades reales del sistema. Algunos pueden optar por tener su código como siempre, pero una propuesta puede ser la de  encapsular ese código en servicios web y desplegarlos en el Application Server, AS, de WSO2. Estos servicios web se corresponderían a diferentes partes del sistema que requieren estar desacoplados, pero que al comunicarse entre sí deben hacerlo de una manera segura y confiable.
  • Para lograr esto último se necesita un ESB que permita este tipo de integración así que usaríamos el ESB de WSO2.
  • Para el acceso a los datos se propone que estos no se accedan directamente si no que se haga desde una capa de servicios de acceso a datos que permita ocultar cosas como duplicación de información, inconsistencias, esquemas duplicados, etc….Se propone entonces que se tenga un Data Service Server, DSS, de WSO2.
  • Por último para el tema de las reglas de negocio se propone que los analistas determinen que reglas deben ser independientes del resto del código y que estas sean expuestas como servicios web usando el Bussiness Rule server, BRS, de WSO2.
Una imagen que representa lo anterior la pueden ver a continuación:

Si se fijan se ha incluido el BAM para el monitoreo de todas las acciones y yo de paso incluyera el CEP para el tema de detectar patrones en transacciones fraudulentas.

Los desarrolladores de PHP podrían decir que ya esto es mucha complicación, pero qué sistema empresarial no es complicado? Realmente llegar a este momento es importante, y las nuevas configuraciones más que complicar lo que hace es dejar un sistema preparado para en el futuro poder ser escalable, seguro, fácilmente integrable y permitir de forma ágil cualquier cambio que se le imponga.

Evidentemente este es un pensamiento estratégico de cada empresa a mediano y corto plazo, pero depende mucho de la visión del CEO saber en qué momento es que se debe hacer este cambio, para minimizar los daños por no poder responder en tiempo a las demandas del mercado.

viernes, 8 de noviembre de 2013


Ya ha terminado WSO2Con 2013 en San Francisco y entre las noticias fundamentales tenemos que tanto Boeing el gigante de la aeronautica, como Trimble Navigation están apostando por una visión tecnológica basada en una arquitectura sobre la nube de la mano de WSO2.

La noticia la pueden ver aquí.

Esto sigue  avalando la suite de WSO2 como la mejor suite en el mundo opensource para los temas de SOA y la Computación en la Nube.

martes, 5 de noviembre de 2013

Técnicas de Identificación de Servicios para SOA.

Dentro de las metodologías para SOA una técnica siempre fundamental es la de identificación de servicios.

En el libro "SOA in Practice" se mencionan algunas como pueden ver en la siguiente imagen.







Con la que más me he involucrado en el trabajo es con la descomposición de procesos de negocio ya que:

  1. Permite vincular directamente a SOA con BPM.
  2. A partir del negocio se establece un enlace directo con el análisis, la arquitectura y el diseño.
  3. La estructuración en capas de la arquitectura fluye de forma natural desde el mismo inicio del proyecto
Esta técnica se ve instanciada en una técnica de descomposición de procesos de IBM que se puede ver en la siguiente imagen.







Como pueden ver la descomposición es muy natural, y la separación nos permite identificar rápidamente los diferentes tipos de servicios si usamos una taxonomía apropiada. Incluso nos dice cuales procesos serán de corta duración y cuales  de larga duración, lo que es importante para los temas de BPM que llevan actividades humanas incluidas.

Además nos permite definir usando la notación BPMN diversos patrones de integración que son muy útiles a la hora de implementar el tenerlos a mano.

De la imagen anterior podemos hacer una correlación con las tecnologías a emplear como se puede ver:



Además de estas tecnologías, donde claro WSO2 está a la cabeza estamos empezando a analizar algunas como Vaadin para el desarrollo de las UI y portlets para desplegarlos en un portal como Liferay y herramientas BPMS como Bonita.

lunes, 4 de noviembre de 2013

WSO2 y las APIs.

Desde hace unos meses WSO2 le ha estado apostando bastante al tema de las APIs.

Rápidamente desarrollaron el API Manager o WSO2 AM, gracias a su arquitectura basada en OSGI y al parecer es un producto considerado entre los líderes del mercado según Forrester. Lo que no entiendo completamente es por qué es el de menor presencia como se muestra en la siguiente imagen.


De todas formas es muy bueno ver que WSO2 sigue avanzando en posicionarse como una de las suite más prometedoras del mercado.

Esquema general de una metodología para Iniciativas SOA

Por lo general una metodología para el desarrollo de iniciativas SOA debe permitir:
  1. Afrontar cualquier tipo de escenario. Ya sea en función del alcance, su complejidad, cantidad de proyectos, nivel de madurez de la empresa, etc.
  2. Incluir diversidad de técnicas de identificación, análisis, diseño, implementación y pruebas de servicios.
  3. Una gestión de la iniciativa que se adapte a las necesidades de la empresa.

Por este motivo siempre es bueno tener una metodología marco a partir de la cual se pueda construir una metodología específica para cada iniciativa. Esto como es lógico tiene sus pro y sus contra pero lo mejor es que mientras más iniciativas se realicen más cerca se está de lograr una metodología genérica que sirva para casi todo tipo de proceso.

En la imagen a continuación les muestro una imagen que puede servir como marco para el desarrollo de este tipo de metodología.


viernes, 1 de noviembre de 2013

WSO2: Introducción al ciclo de vida de los servicios con GREG. I

La gestión del ciclo de vida de los servicios es parte fundamental de cualquier metodología para el desarrollo de iniciativas SOA.

Un ciclo de vida correctamente definido y controlado permite saber en todo momento que pasa con los servicios, como se están usando, si su desarrollo va en tiempo, si cumplen con las pruebas requeridas, si es necesario modificarlos, en fin.

A continuación muestro una imagen de una propuesta de ciclo de vida genérica que puede servir como base para una mejora enfocada a determinado tipo de proyecto. Es la que uso siempre como base y acondiciono de acuerdo a las necesidades y metodología empleada.





WSO2 tiene entre sus herramienta el GREG o Governance Registry. Esta herramienta nos permite:

  • Gestionar los metadato de los servicios desde su identificación.
  • Crear múltiples ciclos de vida a través de un XML, es lo malo, que se puede ir ajustando en el tiempo.
  • Gestión de los diferentes estados de los servicios definiendo los requerimientos a cumplir para ir de un estado a otro.
  • Notificaciones instantáneas sobre cambios en los estados de los servicios.
  • Exponer los servicios web vía UDDIv3 o usando WS-Discovery, la variante que más me gusta.
  • De conjunto con el resto de las herramientas permite la publicación de servicios web implementados o desplegados en el AS y el ESB, los cuales se hacen visibles en el GREG y pueden ser gestionados desde ahí.

En otras entradas mostraremos como realizar cada uno de estos puntos.

miércoles, 18 de septiembre de 2013

WSO2: Nuevo caso de éxito en escenarios de integración.







Suva, es una empresa suiza proveedora líder de seguros federales para las compañías y sus empleados, usan el ESB de WSO2 para que actúe como plataforma central de integración para habilitar servicios web entre diferentes plataformas involucradas en proveer una atención completa para los asegurados.

En el caso de estudio publicado recientemente, sobresale:

·         La decisión de Suva para adoptar una arquitectura orientada a servicios para desacoplar los proveedores y consumidores de servicios web, soportando el mapeo de protocolos, seguridad y datos.

·         El uso del ESB de WSO2 como hub central hacia el cual todas las plataformas realizan llamadas incluyendo:
1.       SAP business management software,
2.       Oracle Weblogic,
3.       Oracle Tuxedo,
4.       Microsoft .NET framework,
5.       Aplicaciones legadas escritas en COBOL.

·         Cómo Suva usa el Developer  Studio de WSO2 para crear la integración manejada por el ESB de WSO2.
      Nota: el Developer Studio de WSO2 es un plugin para el IDE Eclipse que permite el desarrollo de los diferentes componentes y mediadores que serán desplegados en el ESB, y para otras herramientas de la suite.


·         El rol del ESB de WSO2 en el soporte de las diferentes capas de seguridad dentro de la empresa.

Lo pueden ver con más detalles desde este enlace