A veces los árboles no nos dejan ver el bosque. Con tanta orientación a servicios, Gobierno SOA, BPM, análisis de servicios, etc. etc. nos olvidamos de los más simple.

Y lo más simple es que en SOA es que hay unos que proporcionan servicios y otros que consumen servicios. Incluso hay un tercero grupo que hacen las dos cosas, proveer y consumir servicios, vamos, como la vida misma.

Proveedores de servicios

En una arquitectura SOA tendremos un conjunto de programas, los de más bajo nivel, que no consumen ningún servicio y son por lo tanto 100% proveedores. Estos servicios implementan la lógica de negocio más simple, más atómica.

En una aplicación de gestión de cuentas corrientes de un banco, por ejemplo, estos servicios contendrían las lógicas de “consultar saldo”, “realizar reintegro” y “realizar aportación”.

Internamente estos servicios tratan directamente con el repositorio de información, normalmente una base de datos relacional, realizando las operaciones más simples. También son llamados servicios de núcleo o de backend.

Consumidores de servicios

Aquellos programas que únicamente consumen servicios, sin proveer a su vez servicios son los 100% consumidores.

¿que programa no provee ningún servicio? normalmente las aplicaciones de frontal, las que implementan la interfaz de usuario.

También tendríamos, aunque en una definición amplia, podrían ser también los programas batch o no interactivos.

Proveedores y consumidores de servicios

En esta tercera categoría estarían aquellos programas que consumen servicios, de más bajo nivel, para proveer a su vez un servicio de más alto valor añadido.

Son los servicios compuestos, servicios que gracias a la característica de SOA de composición, pueden combinar servicios ya existentes y crear nuevos servicios.

Este tipo ya no se programa como tal mediante sentencias de bajo nivel en el lenguaje de programación correspondiente. En lugar de programar, se combinan los ya existentes. Tanto es así, que existen en el mercado herramientas de desarrollo gráficas que representan los servicios de bajo nivel como cajas, enlazadas por flechas que representan el trasiego de información entre ellos.

En el ejemplo del banco, podríamos tener un servicio de negocio que haga una transferencia de una cuenta a otra de la siguiente manera: si la cuenta corriente de origen tiene un saldo mayor que lo que se pide, entonces “realizar un reintegro” de la cuenta de origen y “realizar una aportación” a la cuenta de destino.

¿Cuánta programación haría falta en este caso? con las herramientas adecuadas, ninguna.

Conclusión:

En SOA hay proveedores de servicios, consumidores y programas que son ambas cosas. Sin embargo, no hay pantallas proveedores de servicios ni servicios de núcleo consumidores. Reglas muy básicas y muy sencillas.

Comparte esta entrada:
Share