No se cuando realmente empecé a trabajar en temas de integración, en mis comienzos en una empresa que manejaba transacciones de tarjetas de crédito uno de mis primeros desarrollos fue un programa que tomaba datos de un archivo que luego eran procesados y se cargaban datos que era utilizados en otros sistemas. Eso de alguna manera era una forma de integración (este tipo de integraciones es denominada integración de datos) donde un sistema que dependía de datos de otro lo hacia por medio de interfaces que eran archivos.
Tarde un poco en entender que eso era una interfase, creo que fue en una reunión con analistas de un modulo de SAP donde se hablaba de tener varias interfaces, en mi mente yo imaginaba “Uhh cuantos conectores que se va a necesitar desarrollar” pero alguien me dijo “a los archivos planos les llaman interfaces” Ohhh ahora entiendo!
El tema es que en algún momento nos vamos a topar con algún problema de integración, ya sea en sus formas mas simples (intercambio de archivos, por medio de una base de datos, o utilizando algún middleware especializado), todo esto es lo que para mi cae dentro de la categoría de AI (architecture integration, y si integro aplicaciones de negocios como un CRM , un ERP, BW, tenemos lo que hoy se llama EAI).
Por lo general en una empresa que tiene uno de estos sitemas nos encontramos con que no es el único sistema y que este provee y se alimenta de información/servicios provenientes de otros sistemas, y es donde empezamos a ver integraciones de diferentes tipos, con diferentes niveles de complejidad y en cantidades “industriales”.
La moda de querer vender SOA en todo producto que se lanza al mercado puso mas en evidencia el tema de integración y como todo paradigma emergente trajo aparejados muchos nuevos conceptos muchas nuevas siglas y mucha confusión.
Hoy ya conocemos siglas como SOA (Service oriented architecture), ESB (Enterprise service bus), EDA (Event driven architecture), WS-*(Especificaciones de Web Services), REST (Representational state transfer), BAM (Business activity monitoring), CEP (Complex event processing).
Entonces terminamos confundiendo algunos conceptos, en una trabajo que tuve que revisar, encontre que la propuesta mezclaba algunas cosas, y estas representaban errores conceptuales donde se mezclaban patrones de arquitectura con herramientas, esto me parece un error bastante grueso porque representa las bases! Y si no tenemos en claro las bases difícilmente podamos comprender el resto.
Lo mas notorio que encontré en este ultimo tiempo fue en un blog de alguien que me parece una eminencia en el tema, un desliz de este tipo, donde habla de una arquitectura llamada “ESB architecture” leyendo el blog creo entender a lo que el llama ESB architecture, pero me parece que es muy importante poder distinguir que ESB es una herramienta de integración que centraliza las comunicaciones y provee una serie de servicios para la interacción de los sistemas, pero que no es una forma de arquitectura en si, al menos para mi no lo es y para otros tampoco.
Por esto me gustaría compartir este link de un blog que para mi no tiene desperdicio que da una explicación muy buena de EAI, ademas tiene notas muy buenas sobre EDA.
