cesta huevos
Una de las típicas arquitecturas para una aplicación web la conocida como la de “tres capas”. Es decir, que hay una “capa” o parte del software separada dedicada a la presentación, otra a la lógica de negocio y otra dedicada a la persistencia.

A medida que dejamos de poner el foco en una aplicación en concreto y “alejamos” el zoom sobre una aplicación en concreto, y vemos como se relacionan con otras aplicaciones, formando un sistema, podríamos ver que básicamente también existen tres capas (aunque con otro significado).

Frontales, lógica de integración, lógica de negocio

Si dejamos aparte el tema de los procesos de negocio automatizados el BPM, y si lo miramos a un alto nivel, creo sinceramente que la estructura de las soluciones software de nuestra empresa basadas en SOA no es tan complicado como pueda parecer.
Como suelo decir, simplificando mucho por supuesto, tenemos tres cestas y lo que hay que hacer es saber en qué cesta hay que poner cada “huevo”, atendiendo al tipo de huevo en cuestión.
capas

Primer tipo de cesta: los consumidores puros o frontends

El primer tipo de huevo, el que iría en la cesta de la izquierda, serían los consumidores puros de servicios. Los llamo así porque sólo consumen, no son “productores” de servicios a su vez. En esta cesta tendremos las aplicaciones web con interfaz de usuario, las aplicaciones de escritorio y las aplicaciones moviles sean cuales sean su arquitectura interna.
El objetivo de los frontends es ofrecer la mejor experiencia de usuario posible y para ello deben estar diseñados. Esto implica que es posible que cada grupo de usuarios deba tener una aplicación diferente, por ejemplo, una aplicación web responsive para el acceso desde el PC y móviles de nuestros clientes, una aplicación nativa móvil para los empleados que trabajan en la calle y una aplicación nativa de escritorio para el centro de atención a usuario, que necesita una gran rapidez y no perder en ningún momento la relación con el cliente que está al otro lado del teléfono.
No suele funcionar, por lo tanto, reaprovechar una aplicación de frontal para determinados grupos de usuarios o canales.
Como consumidores de servicios, las aplicaciones de frontend no tienen lógica de negocio: esto tiene una razón fácilmente entendible. Si ponemos la lógica de negocio aquí, como tendremos varias aplicaciones en función de los usuarios a los que va dirigido, nos encontraremos que tendremos duplicar y triplicar  la misma lógica. Es por lo tanto, de sentido común, concentrar la lógica en un sólo punto, accesible de manera universal por cualquier aplicación… y este punto son los servicios.
Los frontales únicamente deben ocuparse de interactuar con el usuario, presentarle los datos, obtener los datos que introduce el usuario, acceder a los sensores y periféricos del dispositivo (como la cámara de fotos de los móviles), navegar por las pantallas, presentar la información en el idioma del usuario, etc. etc. ni más ni menos.

Segundo tipo de cesta: los servicios o lógicas de integración

Como su nombre indica, en esta cesta estarán aquellas lógicas, software o servicios (como se llame en nuestra arquitectura) encargada de hacer la composición de servicios a partir de lógicas de backend y de otros servicios de integración y adaptarlas para un tipo de canal de consumo. Por ejemplo, unos servicios más complejos con muchos parámetros para la aplicación de terminal financiero de la empresa y o de unos servicios más ligeros con menos parámetros para las aplicaciones móviles.
En una arquitectura “clásica” SOA esta cesta estaría implementada por un Enterprise Service Bus. Este Middleware está precisamente diseñado para hacer la transformación de datos, enrutado de los mensajes y composición de servicios. Sin embargo, hay que tener en cuenta que el ESB es más que un producto software, un patrón de diseño. Y como tal puede ser implementado de múltiples formas, algunas más simples con un framework de integración o con un desarrollo ad-hoc. Hay ocasiones que la complejidad de adoptar una gran suite del tipo de Oracle o IBM supera las ventajas que conllevan y se deberían descartar. En otras ocasiones, si la empresa puede permitirse pagar lo que valen, para proyectos complejos pueden ser una gran ventaja para la implementación del software de la empresa.
Esta “cesta” tiene que basarse en todo caso en estándares. Nunca se puede saber a ciencia cierta qué tipo de clientes vamos a tener en el lado de la izquierda (aplicaciones móviles, webs internas, extranets, B2B, etc.) y también el panorama de de backends que hay que conectar a la derecha puede ser muy heterogéneo y verse modificado en el futuro. Por lo tanto, es mejor cubrirnos las espaldas y elegir la mejor herramienta posible, teniendo en cuenta su precio, productividad, dificultad de uso y gestión y el tipo de empresa de la que se trate, pero siempre con estándares.
¿Qué pasaría si la lógica de integración se pusiera en los frontales? Pues es fácil de ver, creo, que entonces, en cada frontal que hagamos, tendríamos que repetir de nuevo todo ese desarrollo una y otra vez. Lo que hace esta capa de integración, reutilizada por todos los frontales, es sacar “fuera” la parte común de un software (de los frontales a la capa de integración) de la misma manera que un código que se repite en nuestro programa lo sacamos a una clase o un procedimiento aparte para reutilizarlo y no repetir el mismo código.

Tercer tipo de cesta: los backends con la lógica de negocio

En esta cesta es donde realmente se encuentra la lógica de negocio pura de la empresa. Y por puro quiero decir que sólo se ocupa de conceptos de negocio y no de, por ejemplo, como se van a presentar estos datos. Nos debería dar igual si el usuario va a interactuar con la empresa a través de una web, aplicación móvil o un terminal financiero.
Los backends se deben caracterizar por no tener estado y no realizar lógicas de integración. Es decir, un backend debería recibir una petición, ejecutar la lógica, responder a esa petición y olvidarse de la misma. Por supuesto, en el transcurso de la ejecución se puede hacer persistencia de los datos de negocio en la base de datos pero eso no se entiende como “estado” en un servicio.
Si dejamos que los backends llamen a otras aplicaciones de otros backends entonces empezaremos a tejer la madeja de llamadas punto a punto que harán de nuestra empresa una maraña de dependencias (incluso dependencias cíclicas) que nos impedirán evolucionar la T.I. de nuestra empresa como nos gustaría.

Colocar los huevos en su cesta correcta

Teniendo estos conceptos claros, vamos a avanzar un gran trecho cuando tratemos con personas que no conocen SOA ni una arquitectura de software como la que tratamos.
Es decir, ahora hay que escuchar a los analistas, ver lo que piden, y nosotros como arquitectos diremos en qué cesta hay que poner cada huevo en particular.
Evidentemente, si nos piden una aplicación móvil, ésta estará en la cesta de la izquierda, la de los frontends. Pero si esta app necesita la información combinada de tres lógicas de backend, esta composición se hará en la cesta de en medio, que es precisamente la que se dedica a esto.
Si tenemos una lógica de negocio, que no depende de nadie más para su ejecución, no llama a ninguna otra aplicación por ejemplo, es el candidato perfecto para ponerlo en la cesta de la derecha.

Conclusión

Supongo que como lector de este blog, encontrarás esta teoría de las “cestas y de los huevos” una cosa de perogrullo demasiado evidente. Si lo ves así, me alegro. Sin embargo, hay que tener en cuenta que tenemos que tratar con compañeros que no tienen por qué saber de arquitectura ni de SOA, y tener a mano la “teoría” de las cestas y de los huevos nos ayudará mucho en explicarle las características del desarrollo que hay que hacer y ver al menos, cuantas aplicaciones de frontal, cuantos servicios de integración y cuantos backends intervienen en la solución software que hay que construir.
Anuncios