Enterprise Integration Patterns

Actualmente los sistemas de una empresa son producto de sistemas hechos a la medida, componentes comprados de terceras partes, o forma parte de sistemas legados. Desde la perspectiva de un consumidor el pago de un producto o la realización de una operación parece ser una simple transacción, pero en la práctica y al interior de la organización pueden interactuar diferentes aplicaciones, que en muchas ocasiones se encuentran en diferentes plataformas, diferentes lenguajes, cuentan con fuentes de información en diferentes formatos, etc. De aspectos como estos, surge la necesidad de integrar para compartir sus recursos (datos, información, componentes, modulos) de forma eficiente, confiable y segura.

• Al enfrentar este proceso, se debe partir del hecho que muchas aplicaciones corren en diferentes plataformas y en diferentes ubicaciones, y utilizar software de EAI (Enterprise Application Integration) solo cubre una parte de las complejidades de integración. Por tal motivo se debe:
• Establecer comunicación entre grupos IT y unidades de negocio.
• La solución de integración tiene gran alcance y debe cubrir primero los las funciones de negocio más importantes y evitar cualquier cambio de comportamiento negativo.
• Ofrecer “endpoints” de comunicación para sistemas legados, que por sus idiosincrasias o por políticas no pueden ser conectadas de manera adecuada.
• Tener en cuenta estándares de integración como XML, XLS o Servicios Web. Siendo estos últimos los que más ofrecen puntos de extensión y nuevas interpretaciones de los estándares.
• Hay diferentes semánticas entre sistemas, estas diferencias implican grandes decisiones técnicas y de negocio.
• Desarrollar habilidades no solo para implementar soluciones EAI, sino también para manejarlas.

Acoplamiento
Con el fin de obtener una comunicación de bajo acoplamiento entre los diferentes sistemas a integrar se deben superar los siguientes obstáculos y dependencias con el fin de poder concebir una solución que sea tolerante a cambios:

• Plataforma Tecnológica
• Localización
• Time de disponibilidad
• Formato de Datos

Estilos de integración

En este aspecto, destacamos los siguientes criterios a ser aplicados:

• Acoplamiento de Integración: Las aplicaciones integradas debería minimizar sus dependencias para evolucionar por aparte sin causarle daño a las demás. La interfaz de integración debería contener información suficiente para la implementación.
• Simplicidad de Integración: El código que se utiliza para la integración debería ser mínimo, dando el menor impacto posible a la aplicación y ofreciendo la mejor integración en la empresa.
• Tecnología de Integración: Herramientas especializadas en integración pueden ser costosas, y sin ayuda del vendedor pueden incrementar el costo de tiempo y entendimiento entre los desarrolladores sobre estas herramientas.
• Formato de Datos: Las aplicaciones integradas deben acordar que tipos de datos van a intercambiar, cómo pueden evolucionar estos datos y afectar estas aplicaciones.
• Duración de Datos: Acuerdos para la duración de un dato y para que sea consumido apenas sea publicado.
• Datos o Funcionalidad: Las aplicaciones integradas pueden querer no solamente compartir datos sino también funcionalidades.
• Asincronicidad: las aplicaciones integradas pueden no querer que siempre sus invocaciones tengan respuesta inmediata.

File Transfer: Múltiples aplicaciones construidas independientemente con diferentes lenguajes y plataformas y entre ellas necesitan consumir información (En el caso de VehiAlpes la aplicación de inventarios, de gestión de clientes, garantías, etc.). Estas aplicaciones deciden en qué formato de archivo comparten la información (se podría estandarizar en XML el cual es el mas usado). Como la construcción de estos archivos requiere de un esfuerzo, es necesario configurar una periodicidad para su construcción, así como la frecuencia para eliminarlos.

Shared Database: Necesidad de tener la última versión de los datos, rápida y consistentemente. Se debe tener una base de datos centralizada para que las aplicaciones la puedan acceder cuando sea que la necesiten. Las aplicaciones no se preocupan por el formato de los archivos puesto todas conocen SQL a través de diferentes herramientas (clientes SQL). Sus desventajas:

• Necesidades reunidas de las aplicaciones, haciendo que se origine un esquema unificado difícil para trabajar entre los programadores.
• Conflictos humanos debido a las políticas establecidas en el esquema.
• Problemas al no querer trabajar con paquetes externos, sino con sus propios esquemas.
• Cuellos de botella y bloqueos debido a las modificaciones hechas por las múltiples aplicaciones.

Remote Procedure Invocation: Compartir datos a menudo no es suficiente; también se requiere compartir funcionalidad. Los datos se pueden enviar utilizando encapsulamiento al llamar a una función, haciéndolo un mecanismo poderoso. Las aplicaciones son susceptibles a los cambios continuos sobre una base de datos. Se requiere crear mecanismos con encapsulamiento de datos y proveer una o más interfaces que permita interactuar a las aplicaciones, manteniendo los datos de cada una consistentes (CORBA, Java RMI, COM, .NET Remoting, etc; siendo la moda actual Web Services a través de SOAP y XML).

Messaging: Los llamados remotos de “Remote Procedure Invocation” pueden ser lentos y pueden fallar. Existen organizaciones que no les gusta compartir los detalles de su estructura, inclusive si sus detalles son sus interfaces.
Messaging transfiere paquetes de datos de forma confiable, frecuente, inmediata y asíncronamente, utilizando formatos de datos personalizados. La desincronización es importante porque se pueden enviar datos sin estar listos para recibirlos aún. El desacoplamiento de los formatos de datos hace que múltiples sistemas puedan recibir mensajes.