La responsabilidad sobre el dato; de EAI a API

Una de las diferencias mas destacables entre EAI y SOA es que mientras EAI pretendía mantener sincronizada la información entre sistemas mediante la copia de dichos datos en los diferentes sistemas a medida que se producían cambios. SOA por su parte proporciona servicios para acceder a los datos de forma remota, evitando la necesidad de duplicar datos.

Hay que reconocer que todo lo que se puede hacer en SOA, se puede hacer con EAI. Del mismo modo que todo lo que se puede hacer en API se puede hacer con SOA. Son solo cambios de enfoque. Pero si pensamos que en realidad todo se puede hacer con rutinas de ensamblador, nos damos cuenta que los cambios de enfoque no son cambios desdeñables.

En SOA las entidades (datos) deben de existir en un solo sistema. Este sistema ofrece servicios a terceros para acceder a estas o modificar estas entidades. Se dice que el sistema que ofrece ese servicio es el responsable del dato. Un único sistema que controla y secuencia las operaciones garantizando seguridad y calidad del dato, y que mantiene y proporciona la copia “buena” del dato a quien la necesite.

Cualquier otro servicio puede replicar para sí, datos de los que no es responsable con el fin de agilizar el procesamiento (por ejemplo para poder crear vistas sql conjuntas). Pero ha de ser consciente de que su copia no es la copia valida, y que por tanto debe de tender a pedir en cada momento una copia actualizada del dato a su sistema responsable. Esta tendencia nos lleva a mantener referencias de los datos de terceros, en vez de copias.

Por ejemplo el dato cliente, debería de ser mantenido en un solo sistema, por ejemplo el CRM. El resto de sistemas conocerán una referencia al cliente, por ejemplo su numero de cliente. Cada vez que querramos saber el email del cliente se lo pediremos al crm. Esto siempre será mas fácil que replicar el cliente cada vez que este se actualice, en cada sistema capaz de enviar emails.

Tradicionalmente estas referencias a datos externos eran simplemente el identificador del dato dado por el responsable del dato, o como mucho una urn (que identifica responsable, tipo y entidad)

No obstante, la tentación es fuerte, y muchos son los casos en que se utiliza SOA para duplicar los datos en vez dejar que el responsable del dato los gestione autónomamente. Especialmente con la aparición de EDA, que es una manera muy fácil de hacer un EAI encubierto, duplicando (el mantenimiento de) datos según los eventos nos indican que estos cambian.

API elimina tentaciones haciendo el consumo del recurso referenciado más atractivo que el duplicado. ¿Cómo?
Con una doble motivación:
  • Técnicamente:
    • introducimos el identificador en una URL facilitando su localización. HATEOAS la técnica mas habitual.
    • se puede filtrar el numero de campos, paginar o indicar que subestructuras llegan completas o solo enlazadas. De este modo el dato se puede consumir directamente, no necesitas enriquecer ni tratar el dato
    • Herramientas como Swagger permiten documentar los recuros APIs a la vez que probar su funcionamiento
  • Económicamente:
    Puesto que una api es un producto monetizable, tiene un creador interesado se consuma. Así que no piensa en que solo funcione, sino en que sea util, rápida y cómoda. Por ejemplo las capacidades para búsqueda y filtrado de entidades suelen ser mejores en APIs que en servicios SOA tradicionales, sin haber limitaciones técnicas que lo justifiquen.
Si ves un dato que no es tu responsabilidad, !no lo guardes! guardate solo la referencia, y ve a buscar el detalle justo cuando lo necesites y cada vez que lo necesites, pues puede cambiar.
Si aún así pensais que preferís tener los datos cerca, plantearos el uso de un almacén de datos distribuido o incluso un blockchain. El almacén distribuido será la responsable del dato, y el dato estará distribuido, no duplicado.
Anuncios

#api, #eai, #eda, #soa