WSO2 y como evolucionar una pequeña aplicación web en PHP hacia un sistema empresarial.

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.

Posted in arquitectura de software, WSO2