¿Desacoplamiento versus integración?

image

Cuando nos enfrentamos por primera vez a los principios de SOA, una de las impresiones que nos podemos formar es que el desacoplamiento es enemigo de la integración. A fin de cuentas, el desacoplamiento aboga por la separación de los módulos o servicios de negocio y la mínima dependencia con el resto de activos de nuestra empresa.
Por su parte, la integración busca la sinergia, la asociación o combinación con otros elementos software para formar un nuevo activo software compuesto por otros más simples para dar más valor a la empresa (lo que conocemos como servicio compuesto).
Así pues, parece que el desacoplamiento y la integración son dos términos puestos… pues nada más lejos de la realidad.
Tal como yo lo veo, el desacoplamiento es el primer paso para lograr una verdadera integración según los principios de SOA.
Por ejemplo, en una aplicación silo que se comunica con el resto de la empresa gracias a mil y una triquiñuelas improvisadas: ficheros, FTP, tablas, colas, etc. Y digo improvisadas porque cuando se diseñó la aplicación no se pensó siquiera en que en un futuro no podría seguir estando aislada del mundo y que tendría que colaborar con el resto de aplicaciones de la empresa.
Pues bien, cuando tenemos una aplicación de este tipo, lo primero sería partirla en trozos funcionales (módulos software). ¿Cómo se hace esto? esa es la pregunta del millón…

Al menos no deberíamos perder de vista aquella frase que nos repetían una y mil veces en la universidad: un módulo software debe tener la máxima cohesión interna y el mínimo acoplamieno externo. ¿Qué significa esto y cómo se traduce en la práctica?

Cohesión es la característica de que algo es homogéneo y es muy igual entre sí (al menos esa es la definición intuitiva que a mí se me ocurre). Así que lo primero que tenemos que ver en un módulo para ver que realmente merece ese nombre es lo que hace. Por una elemental separación de cometidos (separation of concerns) un módulo no puede, por ejemplo, ocuparse de las cuentas corrientes de un banco y de los clientes… ¿por qué? porque no tienen nada que ver uno con otro, no tendría ninguna cohesión.

Otra forma practica es ver las llamadas que se hacen desde los diferentes elementos del módulo y a dónde las hacen. Si resulta que un elemento de un módulo hace más llamadas fuera del módulo que hacia dentro del módulo mismo debemos sospechar. ¿Tiene sentido que un elemento de un módulo, si tiene cohesión, se relacione más con el resto del mundo que con sus “compañeros” de módulo? pues no.

Pues bien, una vez que hemos descompuesto un programa en sus módulos de software, es el momento de integrarlo. Pero esta vez, de manera correcta, siguiendo los principios de SOA y su desacoplamiento.

¿Cómo se hace esto? Creo que con unas pocas reglas básicas, si se siguen con disciplina, podemos salir del paso de la mayoría de los casos que se nos presenten:
1.- Los backends no se llaman entre sí. Se entiende backend, el módulo o módulos donde se ejecuta la lógica de negocio de la compañía, lo que se llama también el “core” de la empresa
2.- Un backend, por no llamar, no llama a nadie fuera del mismo backend.
3.- Dos módulos, incluso en el mismo backend, no se llaman directamente. Son llamados por un tercero que coordina u orquesta las llamadas entre sí.

En conclusión, antes de realizar la integración de un sistema ya existente, el primer paso para ello es el desacoplamiento.

About these ads

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s