En la entrada anterior de esta serie, parte1, vimos el caso de estudio de una aplicación simple para la gestión de las actividades de un banco, la cual fue desarrollada inicialmente en PHP y MySQL. Pero cuando esta aplicación fue puesta en producción surgieron nuevos requisitos, por lo cual en la presente entrada se muestra como rediseñar la arquitectura del sistema usando los productos de WSO2, que proporcionan una manera eficiente de resolver esos problemas [1].
Por lo general, cuando las personas piensan acerca de los servicios web, tienen la falsa idea de que es algo que solo se debe usar para aplicaciones de alta complejidad técnica en grandes compañías. Es por eso que muchos programadores prefieren ir con lenguajes simples como PHP. Otro hecho es que los desarrolladores han oído historias de horror de muchos fracasos de proyectos SOA, y es por ello que no estudian temas de SOA. Pero esas personas están equivocadas. Por supuesto, si nos fijamos en los productos de, por ejemplo Oracle, relacionados con SOA en realidad son muy complejos. Para usar esos productos debes descargar muchos gigabytes solo para enviar un mensaje. Y no se puede esperar nada más de una empresa que está dirigida por abogados, no por ingenieros de software.
La elección de la tecnología adecuada.
Cuando usted está eligiendo una tecnología para la implementación de un proyecto, tradicionalmente se reduce a elegir entre unas pocas opciones, aprovechando lo que ya tiene en su compañía. Como por ejemplo, si tiene un servidor de aplicaciones, optara por usarlo. Es probable que también opte por elegir una tecnología con la cual esté familiarizado el equipo de desarrollo. Hoy, sin embargo, estas opciones están cambiando. ¿Qué tecnología le da el mejor tiempo de respuesta a la hora de implementar un proyecto? También hay que gestionar la flexibilidad y aspectos de mantenimiento. La capacidad de adaptarse a los nuevos requisitos con facilidad es muy importante. Cuando usted tiene que implementar un nuevo módulo para la aplicación (sin dejar de hablar en términos de nuestro ejemplo banco) si se toma 6 meses para lograrlo, entonces no es eficiente.
Vamos a recapitular nuestros nuevos requisitos y pensar cómo podemos rediseñar con eficiencia el sistema.
- Su aplicación ahora debe soportar múltiples interfaces de usuario en varios dispositivos.
- Tienen que abstraer algo de lógica de negocio en un conjunto de reglas.
- La información debe ser fácil de integrar en otros sistemas.
- La información debe ser fácil de exponer de forma segura a diferentes sistemas y personas. Debe existir un mecanismo de acceso a la información basado en roles.
- Debe ser capaz de identificar patrones de las transacciones que se realizan.
- Debe ser capaz de extenderse para adoptar e integrar sistemas legados.
- Tienen que ser capaces de exponer y enviar información de forma fiable sin tener ninguna pérdida de mensajes en el sistema.
- Cualquier parte del sistema debe ser capaz de escalar fácilmente.
- 9. Tiene que tener un sistema de vigilancia que sea fácil de configurar para la adición de los nuevos módulos, así como el control de la configuración distribuida que vamos a tener.
- Al entrar en funcionamiento y tener una configuración distribuida tenemos que ser capaces de asegurar la comunicación que está pasando entre los módulos y sistemas externos.
Cómo los productos de WSO2 resuelven este problema.
Vamos a empezar con la interfaz visual. WSO2 tiene las tecnologías que se pueden utilizar para desarrollar la interfaz de usuario, el núcleo y middleware de la aplicación. Hay varias maneras en que puede desarrollar la interfaz de usuario. Si usted está utilizando la tecnología de WSO2 la forma más fácil de desarrollar la interfaz es utilizando Jaggery, que es un framework JavaScript del lado del servidor, similar a NodeJS. WSO2 está desarrollando un nuevo producto llamado “WSO2 User Engagement Server (UES)”, que permite crear interfaces arrastrando y soltando componentes. Arrastre una tabla y coloque la URL que tiene los datos y ya está listo, los datos serán obtenidos y mostrados. Aunque la página web del producto aún no ha sido creada, la versión beta está disponible! Puedes descargarlo desde aquí. Descomprimir y ejecutar el fichero script wso2server.{ Sh, bat } en la carpeta bin. Una vez iniciado el servidor puede acceder al portal, desde su navegador en la dirección: http://localhost:9763/portal/. La configuración predeterminada de usuario / contraseña para iniciar sesión es: admin / admin. Pruébalo, ¡es increíble!
Ya tiene la interfaz visual y también puede permitir a los usuarios crear cuadros de mando (dashboards) personalizados. ¿Y ahora qué? Ahora es necesario tener un conjunto de APIs que implementan las funcionalidades del negocio. Cuando usted tiene eso es fácil conectar diferentes aplicaciones / interfaces / servicios para obtener datos. Si va a conectar dispositivos móviles, es posible que desee manejar datos JSON para facilitar su procesamiento. Como estas APIs pueden estar expuestas no sólo a las aplicaciones internas, sino también a las aplicaciones externas, entonces usted necesita para tener seguridad. También necesitara tener capacidad de monitoreo para supervisar quién está utilizando una API, cual es la frecuencia de uso y el tiempo de respuesta. Para ello usted puede utilizar: “WSO2 API Manager” que permite la creación y gestión del ciclo de vida de la API a través de una consola web de fácil administración.
Las API necesitan comunicarse con un servicio o un conjunto de servicios que implementan funcionalidades de negocio. Dado que en nuestro ejemplo estamos tratando con módulos como el depósito a plazo fijo, créditos y cheques, pues cada uno de ellos se puede implementar como un servicio y agrupar todas las funcionalidades relacionadas con ese servicio. Los servicios web animan a hacer todo de una manera sin estado, así que es fácil de escalar cuando ello sea necesario. La implementación del servicio se puede hacer en Java y alojarlo en el servidor de aplicaciones (Application Server). El servidor de aplicaciones se está ejecutando en una instancia de Tomcat empotrado. Ahora usted tiene la lógica de negocio implementada y alojada en el servidor de aplicaciones. El siguiente paso es utilizar el bus de servicios empresariales (Enterprise Service Bus) que permite la comunicación entre los componentes que forman parte el sistema y actúa como un punto que permite integrar diferentes sistemas. Los sistemas bancarios legados de nuestro ejemplo.
A continuación, se puede desarrollar una capa de servicios de datos en la parte superior de la base de datos que estaba utilizando, para exponer esos datos como servicios web. Así, al implementar servicios de negocios, estos pueden hablar con los servicios de datos para realizar operaciones a nivel de datos. Esto proporciona una interfaz limpia para interactuar con la base de datos y hacer la lógica de aplicación mucho más simple. Usted no tendrá que utilizar las llamadas JDBC o utilizar una capa de persistencia / ORM como Hibernate. Cuando usted está accediendo a los datos en la base todo lo que tiene que hacer es otra llamada de servicio web. A continuación, la capa de acceso a datos puede tener su propio mecanismo de seguridad independiente de los demás sistemas. Esto es fácil con el servidor de servicios de datos (Data Services Server) donde se puede exponer a cualquier tabla de base de datos o una consulta personalizada como un servicio web.
Ahora vienen las reglas de negocio. Se puede utilizar el Servidor de Reglas del Negocio (Business Rules Server, BRS) para crear un conjunto de reglas reutilizables de la que la lógica empresarial. BRS expondrán todas sus reglas de negocio como un servicio web. Por lo tanto, cuando usted está pidiendo una regla de negocio para evaluar, todo lo que tiene que hacer es llamar a otro servicio web. Veamos cómo luce esta solución:
Como se puede ver en la imagen hemos incluido la herramienta Business Activity Monitor (BAM) para la supervisión. Los componentes API Manager, ESB, AppServer etc, tienen agentes de publicación que envían los datos estadísticos sobre las invocaciones de servicio al BAM. Usted sólo tiene que dar la información de conexión y los detalles sobre estadísticas de los servicios serán recogidos en el BAM. A continuación, puede configurar UES para mostrar un panel personalizado de todos o un subconjunto de los eventos. Una de las ventajas de esta solución es que puede escalar cada uno de los componentes sin tener un efecto adverso sobre otras partes del sistema. Por ejemplo si el servicio de cuenta de ahorros está atrayendo una gran cantidad de tráfico, puede colocar un clúster el servidor de aplicaciones. Si el sistema está generando una gran cantidad de eventos que se envían a BAM entonces usted puede poner en un clúster el BAM y así sucesivamente.
En el diagrama de arriba hay un ESB independiente que se ocupa de los aspectos de integración, y también está allí para proporcionar y conectar con los sistemas heredados que se utilizarán.
Fuera de los requisitos que hemos hablado, hay algo más que no hemos considerado en la imagen de arriba. Que está relacionado con la identificación de los patrones acerca de las transacciones fraudulentas de tarjetas de crédito. Para ello podemos utilizar WSO2 Complex Event Processing Server (CEP). Como el CEP analiza flujos de eventos, el lugar natural para colocar el CEP es dentro del BAM. Porque nosotros de todos modos estamos enviando todos los eventos al BAM para fines de control. A continuación, puede configurar diferentes alertas en base a los criterios que necesita.
Conclusión
En resumen, hemos puesto el ejemplo de una aplicación web sencilla y luego vimos como los requisitos aumentaron con la necesidad de integrar sistemas adicionales y la ampliación de las diferentes partes, analizando las posibles dificultades técnicas que se introducen para hacer esos cambios. Entonces explicamos que si usted piensa en esos problemas de forma anticipada, puede diseñar arquitectura diferente para el sistema, que se ajuste bien a las necesidades. Y por último se mostró cómo algunos de los productos de WSO2 resuelven, sin mucho esfuerzo, esos problemas difíciles.
