Homus Arquitectus

Una breve reseña sobre la evolución en la arquitectura de software.

Al principio fue el Mainframe, ohhh todo poderoso, con un sin número de clientes tontos, denominados así por su casi nula capacidad de computo. Todo residía en el Mainframe. ¿La Persistencia? En el Mainframe. ¿La lógica de negocios? En el Mainframe. ¿Las aplicaciones como tal? Adivine… En el Mainframe. ¿La capa de presentación? Allí mismo pues, en el sagrado Mainframe.

El esquema de arquitectura basado en Mainframes y clientes tontos tenía algunas ventajas como lo son:

• ·         Sencillez de arquitectura
• ·         Facilidad de Monitoreo
• ·         Control simplificado de despliegues

Pero a su vez tenía una principal desventaja, condición tal en la que centraremos las ideas de esta publicación; me refiero a la enorme incapacidad para el crecimiento o escalabilidad!!

Para resolver este problema se estableció entonces un modelo al que llamamos Cliente servidor. En el cual los Mainframes son básicamente servidores de Base de Datos, mientras que los clientes, ahora denominados clientes gordos, con muchos recursos asignados, eran los encargados de ejecutar las aplicaciones, lo que incluye la capa de presentación e incluso una buena dosis de Inteligencia de Negocio.

Este modelo resolvía gran parte del problema de escalabilidad del modelo anterior, pero trae consigo el problema conocido como la “Pesadilla del Mantenimiento”. En otras palabras, al residir los aplicativos en las máquinas clientes, cuando se precisa de una actualización es necesario idear mecanismos que permitan propagar ese cambio o actualización en todos los clientes conectados.

En ese contexto surge el modelo de 3 capas como propuesta para solventar la problemática anterior. Recuerde, aquí somos como los políticos la culpa siempre es del gobierno anterior jajaja. Volvamos al tema que nos atañe, el modelo de 3 capas, pueden ser más capas pero en esencia son 3,  proponía tener una capa de servicios, con su  hardware y software dedicados, que se encargara de atender la capa de Persistencia (bases de datos), la capa de Lógica de Negocio y la capa de Presentación. Las primeras dos estarían en servidores dedicados, mientras que la capa de presentación estaría a cargo de las máquinas clientes, siendo el navegador o browser el aplicativo o medio adoptado de preferencia para estas lides.

En este modelo la persistencia queda a cargo de los servidores (¿mainframes?) de base de datos.

La lógica de negocio, servicios y aplicaciones queda a cargo de los servidores de aplicaciones.

Mientras que la presentación, y su correspondiente lógica y servicios asociados, era manejada en las máquinas clientes a cargo del navegador u otra aplicación conveniente.

Con ello resolvíamos la escalabilidad de cara a las máquinas clientes, la escalabilidad en las máquinas de persistencia y lógica de negocio, resolvíamos además el problema de la “Pesadilla del Mantenimiento”, era suficiente con actualizar las aplicativos en los servidores de aplicaciones para que los clientes al conectarse ya tuviesen disponible la última versión disponible del software demandado; un paraíso pues… pero no tanto. Aún quedaban cosas por resolver.

Sí bien el modelo anterior hace mucho por resolver los asuntos hasta ahora mencionados, hace poco o nada por resolver otro problema de la capa de negocio, el de la redundancia de tareas o repetición de funciones, formalmente conocido como repetición de servicios. Esto se refiere al problema originado por estar los sistemas concebidos como islas funcionales, usualmente reflejando las necesidades de algún ente jerárquico de la organización, departamento, unidad, división, etc. Muchas de estas “islas” tienen que resolver problemas, o usar recursos, comunes a toda la organización y cada una de ellas, las islas, tiene su propia versión o procedimiento de cómo lidiar con el asunto y, por supuesto, cada uno cree que el suyo es el procedimiento único, válido y verdadero.

Imagine a cada isla que tenga que lidiar con la tarea de validar tarjetas de crédito. Cada una escribirá su programa, función o servicio, en su propio lenguaje de programación, con sus propias reglas y lógica de negocio y desplegándolas en sus propias plataformas particulares. Con el pasar del tiempo vamos a terminar con un montón de servicios, en esencia código y recursos, destinados a repetir una misma tarea, lo cual es a todas luces poco eficiente, difícil de gobernar, complicado de mantener e innecesario para la organización.

¿Cómo se soluciona esto? Mediante asesinos conocidos. Mediante estándares.

Es allí cuando surge el estándar propuesto como Arquitectura Orientada a Servicios, SOA de sus siglas en ingles.

Este propone una manera común, estándar, para comunicarnos con funciones o servicios. Establece de forma clara como se deben pasar los mensajes y parámetros, como se retornan los resultados y como se establece la comunicación. No importa si la implementación final de un servicio está realizada en C# o Java, mientras se ajuste al estándar podremos consumir ese servicio con éxito y usarlo en nuestros sistemas, pudiendo además unificar la administración y monitoreo de tales servicios.

Bajo este esquema de solución ya no existirán N versiones del servicio requerido para validar tarjetas de crédito, sino que por el contrario, se habrá establecido un servicio único que puede ser consumido o usado desde los diferentes sistemas de la organización. En este contexto, es válido pensar en servicios que se pueden exponer a entidades fueras de la organización, lo que abre un mundo de posibilidades en las relaciones inter-organizativas (b2b) y crea nuevas preocupaciones respecto a la seguridad, entre otros asuntos.

Si miráis con atención mis queridos lectores, estas propuestas de arquitectura, y su consecuente evolución, buscan resolver un problema subyacente, común a todas, el cual consiste en ¿Cómo hacemos que las máquinas se comuniquen eficientemente entre sí?

Puede parecer que no es ese el meollo del asunto, pero a la larga, entre todas las capas y estándares que establecemos, lo que se persigue es eso, Comunicar Máquinas con eficiencia (o partes de ellas).

Pero este es tema ya para otra publicación.