Pensamientos de Aztlek

Este escrito explica el concepto de intermediación entre sistemas.  La intermediación es uno de los conceptos más poderosos de los sistemas, es la base conceptual del bus de servicios SOA (del que ya escribí un artículo: El bus de servicios en SOA), del software multicapa, del mapeo objeto relacional, en general de las capas de abstracción de software y está detrás de conceptos hardware como el buffer y el caché .  Pero parece no haber desarrollos conceptuales al respecto así que este escrito es una pequeño aporte de mi parte al tema.

El concepto de intermediación es muy sencillo lo puedes ver en el siguiente diagrama.

Diagrama de la intermediación entre sistemas

Como vez,  el intermediador es el centro de la estructura, está en medio de dos sistemas (o más) mediando la comunicación entre estos sistemas. En éste patrón (la intermediación) para que los sistemas se comuniquen tienen que hacerlo a través del intermediador. ¿Pero, para que quiero tener un intermediario entre dos sistemas? La respuesta es, por modularidad,  flexibilidad y desacoplamiento de los sistemas.

Todo esto que te estoy contando lo puedes ver en el siguiente mapa conceptual.

Mapa conceptual del la intermediación en sistemas

Pero volviendo al tema, la intermediación aumenta la modularidad del sistema y entre los sistemas. La razón de esto es que con la intermediación se aumenta el desacoplamiento entre los módulos de un sistema. Como el primer sistema no se comunica directamente con el segundo, si hay algún cambio en éste último, por ejemplo se hace más lento, o es cambiado por uno nuevo más rápido o simplemente desaparece, el primer sistema no deja de cumplir sus función.

Por ejemplo, si desarrollas una aplicación que hace uso intensivo de una base de datos, puedes tener las siguientes formas de implementar la conexión a la base da datos. La primera opción es conectar directamente la aplicación al motor de base de datos. La segunda opción, es mediante una intermediación, usar una capa de abstracción de conexión a la base de datos, como por ejemplo un mapeo objeto-relacional. En la primera opción, la de la conexión directa, se ejecutan sentencias SQL directamente en el motor de base de datos. En la segunda opción, la del mapeo objeto-relacional, se ejecutan sentencias orientadas a objetos que son traducidas a sentencias relacionales.

A primera vista tiene más ventajas la primera opción de implementación, pues es mucho más rápida y más directa. Pero piensa por un momento que tengas que cambiar tu motor de bases de datos. Esto puede ser por varias razones, por ejemplo: subió mucho el precio del mantenimiento del motor comercial de base de datos que estás usando y te toca cambiar a otra alternativa más racional, o también se puede dar el caso que se desarrolla una nueva tecnología de bases de datos no relacional que se adapta tanto a los tipos de datos que se manejas en tu aplicación que sería mucho más eficiente con esta nueva tecnología, o también puede ser el caso que se aprueba una nueva ley o política que para cumplirla tienes que cambiar tu motor de base de datos. Y hay muchos otros casos que en este momento que ni se me ocurren.

Por la razón que sea, tienes que cambiar tu motor de base de datos. En la primera opción tu aplicación está tan acoplada al motor de base de datos que solo tienes dos caminos: el primero reescribir toda tu aplicación desde cero, con todos los costos y tiempo que ello implica; el segundo, es no hacer nada. Y aunque no me creas, este último camino es el que la mayoría de las veces se escoge. Es por ello que en muchas organizaciones encontramos sistemas de información desarrollados con tecnologías muy, pero muy viejas, pero sobre todo inapropiadas para el problema que se supone están resolviendo.

En la segunda opción, en la que utilizas una intermediación, el mapeo objeto-relacional, sólo tienes que cambiar ese módulo y automáticamente toda tu aplicación queda actualizada a la nueva tecnología. El costo de la migración pueden ser mínimo o en el peor de los casos mucho menor que en la primera opción.

Otro ejemplo, di tu que tienen, como en todas las organizaciones, una multitud de sistemas de información que implementan otra multitud de procesos de la organización. Estos sistemas, están desarrollados en plataformas tecnológicas distintas: distintos lenguajes, distintos manejadores de bases de datos, distintos frameworks, en general, distintos paradigmas. Y en la organización ya llegó el momento de madurez organizacional que implica que todos los sistemas de información se comporten como uno sólo. Y eres tu al que han contratado para resolver ese problema. ¿Qué haces?

Tienes varias opciones: La primera renunciar. La segunda, reescribir todos los sistemas de información desde cero utilizando una plataforma homogénea. La tercera opción usar alguna intermediación que te permita interconectar esos sistemas de información. La primera opción no la voy ha considerar por que no es una opción real por que evade el problema. La segunda opción es posible pero inviable, por que es altamente costosa e implica mucho, pero mucho tiempo. Además considera que los sistemas actuales hacen bien su trabajo, ¡por eso todavía se usan!

La tercera opción, usar una intermediación es una opción con unos costos y tiempos más aceptables. Consiste en usar los sistemas que ya funcionan modificándolos muy poco o nada, pero si escribiendo algún código nuevo. Esta solución pasa por usar una intermediación, una arquitectura orientada al servicio (SOA), por ejemplo. En esta, las aplicaciones existentes se pueden comunicar unas con otras a través de protocolos estándares muy definidos y para ello solo es necesario escribir algo de código y en muchos casos ese código viene con la solución SOA por lo que muchas veces es sólo configurar y escribir algo menos de código. Pero es mucho menor que el código que tendrías que hacer si escribes todos los sistemas de información desde cero.

Un ejemplo final, cuando yo empecé en la computación por allá en los años ochenta del siglo pasado, los que llamábamos en ese entonces microcomputadores, eran máquinas que solo podían correr un programa a la vez, eran monoproceso (increíblemente hay algunos dispositivos móviles actuales que parecen máquinas de esa época, pero ese es otro tema). Esa característica hacía que cuando imprimíamos el computador se bloqueaba hasta que terminara. Hay que recordar que aún entonces los procesadores eran mucho más rápidos de lo que es una impresora, inclusive de las de hoy día. Entonces el procesador quedaba ocioso y no se podía hacer nada más que ir a tomarse un café. Entonces empezaron a aparecer impresoras que incluían un buffer,  esto es, una memoria intermedia en la que se puede escribir mucho más rápido que imprimir. Entonces uno mandaba la impresión a ese buffer que recibía todos los bytes rápidamente y se liberaba rápidamente el procesador y uno podía seguir trabajando. Incluso después se incluyó otro buffer en el sistema operativo que aumentaba el tamaño de los trabajos que se podía imprimir sin bloquear el procesador.

Este buffer es un ejemplo en hardware del concepto de intermediación, y ejemplifica otra característica de este poderosa concepto: La intermediación también sirve para sincronizar dos sistemas que trabajen a velocidades distintas.

Generalizando, la intermediación sirve para interrelacionar sistemas con interfaces incompatibles entre si o que tienen implementaciones con con rendimientos diferentes. Además de las ventajas que ya mencioné: aumentar la modularidad y por ende el desacoplamiento y  la flexibilidad de los sistemas.

Claro, no todo son ventajas, la intermediación tiene un costo asociado pues se aumenta un módulo, lo que hace que el sistema se vuelva más complejo y también hace, en algunos casos, que se presente un único punto de fallo que es el intermediador. Pero con un buen diseño puede incluso hacer que el sistema se simplifique y se puede montar el intermediador en soluciones de alta disponibilidad y tolerantes a fallos. Esto hace que las ventajas superen con creces las desventajas y que la intermediación debe ser un concepto que debemos tener en cuenta como clave al diseñar las arquitecturas de nuestros sistemas de información.