Si queremos adoptar SOA de verdad, con garantías de éxito, debemos
hacer algunos cambios en nuestro manera de ver las cosas. Un cambio de
chip mental.

Una de esas cosas es que tenemos que ver el desacoplamiento del
software, la eliminación en lo posible de las dependencias entre
ellos, como una grandísima ventaja y como un objetivo en nuestros
diseños.

Hasta SOA, estábamos acostumbrados a que desde cualquier sitio, desde
cualquier programa (sea el que sea) se podía llamar directamente a
otro programa (sea cual sea).

Es decir, que desde un programa hacíamos llamadas a otros muchos
programas, a su vez a este primer programa se llamaba desde otros
programas distintos. ¿Qué obtenemos como resultado? Dependencias de n
a n, incluso algunas de ellas circulares que como resultado tenemos
una pelota difícil de desenmarañar.

Lo que debemos tener claro, es que una aplicación de negocio, lo que
solemos llamar como backend o core de negocio, no puede actuar como
integrador de otros backends. Para eso se ha inventado el ESB, el bus
empresarial.

Si queremos adoptar SOA de verdad, con garantías de éxito, debemos hacer algunos cambios en nuestro manera de ver las cosas: un cambio de mentalidad.

Una de esas cosas es que tenemos que ver el desacoplamiento del software, la eliminación en lo posible de las dependencias entre ellos, como una grandísima ventaja y como un objetivo en nuestros diseños.

De cara al mantenimiento, uno de los mayores problemas que tenemos es el acoplamiento entre programas o entre funcionalidades dentro del mismo programa. Si todos dependen de todos, ¿Cómo podemos cambiar uno
por otro? ¿Que pasa si modificamos uno de ellos? ¿A cuantos estaremos afectando?

También hay inconvenientes técnicos y es que se diga lo que se diga, en la mayor parte de las veces (sobre todo con los backends legacy) no están preparados para invocar a otros programas que o estén en su mismo proceso o máquina.

Pensemos en un banco por ejemplo, tendremos la aplicación de Clientes, Cuentas y Préstamos por poner un ejemplo muy sencillo. Desde varios programas, módulos o procedimientos de Clientes se llaman a Cuentas, de Cuentas a Préstamos, de Prestamos a Clientes, etc. etc.

Con la normal evolución de la empresa, ahora nos piden que reemplazemos la gestión de Préstamos por poner un ejemplo, una aplicación hecha con tecnología obsoleta que urge cambiar, por un programa comercial que podemos adquirar con bajo costo.

Es fácil entender que esto nos va a suponer un gran quebradero de cabeza ya que no es posible cambiar una aplicación por otra de una manera limpia (debido al gran acoplamiento y a las dependencias con otras aplicaciones) tendremos que que cambiar las tres aplicaciones con el impacto y el riesgo que supone eso para al operativa del banco. Por no mencionar, claro el coste y el tiempo que nos va a suponer hacer esto.

Como vemos en la imagen, al sacar la lógica de integración al ESB, fuera de las aplicaciones conseguiremos evitar el acoplamiento y por tanto seremos más flexibles a la hora de incorporar nueva funcionalidad, sustituir una aplicación por otra, mejor mantenimiento, etc.

Conclusión:

Podemos ver que la integración entre aplicaciones de negocio o backends, que tal vez en su momento era la única forma de hacerlo, hoy en día está ampliamente superada y es muy desaconsejable. En su lugar hay que implantar soluciones altamente desacopladas y aquí SOA nos puede ayudar y mucho.

Comparte esta entrada:
Share