Simplificar los intercambios de información

La integración de aplicaciones ha sido tradicionalmente uno de los caballos de batalla de los departamentos de Tecnologías de la Información de cualquier compañía. La multitud de áreas funcionales que es necesario cubrir hace necesaria la implantación de soluciones heterogéneas compuestas por un conjunto de aplicaciones de distintos fabricantes y en la mayoría de los casos basadas en tecnologías totalmente distintas. Esta situación viene dada por la evolución de los sistemas de información que ha hecho que en una compañía convivan sistemas desarrollados en momentos, para problemáticas y con tecnologías distintas.

La integridad de la información a lo largo del ciclo de negocio de la compañía es, en la mayoría de los casos, una tarea que recae en el departamento de Tecnologías de la Información que, sobre la base de un flujo de negocio claramente definido, programa los interfaces entre las distintas aplicaciones. El número de interfaces es función del número de aplicaciones a conectar. Valga como ejemplo decir que si pretendemos conectar dos sistemas necesitaremos desarrollar un único interfaz bidireccional pero si aumentamos las aplicaciones hasta cinco el número de interfaces podría aumentar hasta diez y para seis necesitaríamos dieciocho interfaces. Modificaciones en el flujo de negocio o en las aplicaciones relacionadas implican necesariamente modificaciones en la codificación de estos interfaces. Con lo que la inclusión de nuevos productos o servicios, la modificación de modelos de gestión, las reestructuraciones de organización o cualquier otro cambio que afecte a los sistemas de información no pueda ser acometido con la eficiencia que requiere el mercado actual, lo que resta competitividad a las compañías.
El concepto de EAI (Enterprise Application Integration) nace con el objetivo de simplificar los intercambios de información entre aplicaciones mediante un conjunto de productos que permiten conectar las distintas aplicaciones de negocio de una empresa a través de un canal común de comunicación, que distribuye información de procesos. Esta integración hace que el flujo de información entre sistemas sea flexible, permitiendo la modificación de los flujos de negocio con simples modificaciones a los parámetros del sistema. Así mismo reduce el número de interfaces a desarrollar, ya que los productos de EAI suelen incorporar conectores estándar para la mayor parte de los ERP’s del mercado. En caso de no existir conector estándar bastaría con desarrollar un conector para el nuevo sistema, independientemente del número de sistemas con los que deba intercambiar información.
Los métodos de comunicación, el nivel de integración y los métodos de definición de los flujos de negocio son tres de las características diferenciales de los middleware de mercado. Cada uno de los métodos aporta sus beneficios, y la selección del producto de EAI dependerá del perfil de las aplicaciones a conectar. Esto significa que el rol (interacción con el usuario, conexión sistema a sistema), comportamiento (on-line, batch) de una aplicación, la arquitectura de la misma, la complejidad y características del flujo de negocio tienen gran influencia en los requisitos que debe cumplir el middleware de integración. La comunicación entre aplicaciones se puede llevar a cabo siguiendo numerosos caminos. Una aplicación puede tener múltiples tipos de comunicación - con otras aplicaciones -.
Independientemente de si la comunicación es síncrona o asíncrona, existen, básicamente, cinco modelos o esquemas fundamentales de comunicación, que pueden usarse para la interacción entre aplicaciones:
Conversacional: Los programas interactúan con otros estableciendo un diálogo entre ellos. Ambas partes deben estar disponibles al mismo tiempo, así este esquema no puede funcionar de modo totalmente asíncrono. Este modelo se implementa habitualmente utilizando API's de comunicación a bajo nivel como APPC o CPI-C; y se suele emplear más para el desarrollo de software de sistema que para soportar aplicaciones de negocio.
Petición/Respuesta: El modelo petición/respuesta (request/reply o request/response) es un esquema interactivo, pero difiere del modelo conversacional en que está basado en una única petición que genera una única respuesta. Un programa envía un mensaje de petición, un receptor recoge la petición, la procesa y devuelve el resultado. El peticionario queda bloqueado hasta obtener la respuesta.
Paso de Mensajes: El método de paso de mensajes (Message Passing o Messaging) es el método de comunicación más simple, ya que la comunicación se establece en un único camino, es decir una petición no tiene respuesta. En este caso el proceso que envía el mensaje no queda bloqueado, ya que no espera ninguna respuesta.
Mensajes Encolados: El método de mensajes encolados (Message-and-Queuing o store-and-forward) se basa en la utilización de un sistema intermedio de almacenamiento (colas). Una cola es una base de datos de mensajes en tránsito. Un mensaje es enviado al sistema y este lo coloca en la cola correspondiente (esta cola puede residir en el sistema cliente, en el sistema servidor final o en cualquier otro nodo de la red). Posteriormente se lleva a cabo la entrega del mensaje al destinatario final que se encarga de procesar el mensaje enviado y si este mensaje necesita una respuesta, enviará la respuesta utilizando el mismo sistema de colas. Con este esquema el peticionario del mensaje no queda bloqueado esperando la respuesta.
Publicación y Suscripción: Este es un método de comunicación (Publish-and-Subscribe) en el que las fuentes de información "publican" (es decir, envían) información a una infraestructura middleware, y los consumidores de información "suscriben" especificando que tipo de información quieren recibir de la infraestructura. El middleware debe ser capaz de transportar físicamente mensajes de uno o varios publicadores a uno o varios suscriptores. Este esquema soporta comunicación uno a uno, uno a varios o varios a varios, en contraste con los métodos de paso de mensaje o mensajes encolados. Publicadores y suscriptores en este modelo se pueden identificar dinámicamente cambiando sus reglas de suscripción en tiempo de ejecución.
De la misma forma que existen varios métodos para comunicar las aplicaciones entre sí, existen también varios niveles de integración de sistemas.
Integración a nivel base de datos: El esquema de integración de sistemas a nivel base de datos implica que un sistema maneja (busca, lee, y modifica) información contenida en una base de datos "propiedad" de otro sistema. Este esquema presenta el problema fundamental de la integridad de la información, al estar accediendo varios sistemas, a la vez, a los mismos datos.
Integración a nivel transacción: En este esquema de integración, una transacción de un sistema de información ejecuta una transacción de otro sistema de información que está desarrollada específicamente para ser ejecutada por un sistema externo. Esta integración se realiza habitualmente con API's o two-fase commit. Esta aproximación garantiza la integridad de la información aunque implica la necesidad de que ambos sistemas de información estén disponibles para realizar la oper