Integración de aplicaciones empresariales

Si la integración se aplica sin seguir un enfoque EAI estructurado, las conexiones punto a punto proliferan en toda la organización. Se añaden dependencias de forma improvisada, lo que da como resultado una estructura compleja y difícil de mantener. Esto se conoce comúnmente como espagueti, en alusión al equivalente en programación del código espagueti .

Por ejemplo, el número de conexiones necesarias para tener conexiones punto a punto completamente malladas, con n puntos, viene dado por${\displaystyle {\tbinom {n}{2}}={\tfrac {n(n-1)}{2}}}$(ver coeficiente binomial ). Por lo tanto, para que diez aplicaciones estén completamente integradas punto a punto,${\displaystyle {\tfrac {10\times 9}{2}}=45}$Se necesitan conexiones punto a punto, siguiendo un patrón de crecimiento cuadrático .

Sin embargo, el número de conexiones dentro de las organizaciones no necesariamente crece proporcionalmente al cuadrado del número de puntos. En general, el número de conexiones a cualquier punto solo está limitado por el número de otros puntos en la organización, pero en principio puede ser significativamente menor. La EAI también puede aumentar el acoplamiento entre sistemas y, por lo tanto, incrementar la carga administrativa y los costos.

EAI no se trata solo de compartir datos entre aplicaciones, sino que también se centra en compartir tanto datos empresariales como procesos de negocio. Un analista de middleware que se ocupa de EAI a menudo examinará el sistema de sistemas .

La EAI se puede utilizar para diferentes propósitos:

• Integración de datos : Garantiza la coherencia de la información en múltiples sistemas. Esto también se conoce como integración de información empresarial (EII).
• Independencia del proveedor: Extrae las políticas o reglas de negocio de las aplicaciones y las implementa en el sistema EAI, de modo que, incluso si una de las aplicaciones de negocio se reemplaza por una aplicación de un proveedor diferente, no es necesario volver a implementar las reglas de negocio.
• Fachada común: Un sistema EAI puede servir de interfaz para un conjunto de aplicaciones, proporcionando una única interfaz de acceso coherente a estas aplicaciones y evitando que los usuarios tengan que aprender a utilizar diferentes paquetes de software.

Esta sección describe patrones de diseño comunes para la implementación de EAI, incluyendo patrones de integración, acceso y ciclo de vida. Estos son patrones abstractos y pueden implementarse de diversas maneras. Existen muchos otros patrones de uso común en la industria, desde patrones de diseño abstractos de alto nivel hasta patrones de implementación altamente específicos. ^{[ 3 ]}

Existen dos topologías principales: la de concentrador y radios , y la de bus . Cada una tiene sus propias ventajas y desventajas. En el modelo de concentrador y radios, el sistema EAI se encuentra en el centro (el concentrador) e interactúa con las aplicaciones a través de los radios. En el modelo de bus, el sistema EAI es el bus (o se implementa como un módulo residente en un bus de mensajes o middleware orientado a mensajes ya existente ).

La mayoría de las grandes empresas utilizan redes zonificadas para crear una defensa por capas contra las amenazas de red. Por ejemplo, una empresa suele tener una zona de procesamiento de tarjetas de crédito (compatible con PCI), una zona no compatible con PCI, una zona de datos, una DMZ para gestionar el acceso de usuarios externos y una IWZ para gestionar el acceso de usuarios internos. Las aplicaciones necesitan integrarse en varias zonas. En este caso, el modelo de concentrador y radios sería más adecuado.

En la implementación de cada uno de los componentes del sistema EAI se utilizan múltiples tecnologías:

Autobús/centro

Esto suele implementarse mejorando los productos de middleware estándar ( servidor de aplicaciones , bus de mensajes) o implementándose como un programa independiente (es decir  , que no utiliza ningún middleware), actuando como su propio middleware.

Conectividad de la aplicación

El bus/concentrador se conecta a las aplicaciones mediante un conjunto de adaptadores (también llamados conectores ). Estos son programas que saben cómo interactuar con una aplicación empresarial subyacente. El adaptador realiza una comunicación unidireccional, ejecutando solicitudes del concentrador a la aplicación y notificándole cuando ocurre un evento de interés en la aplicación (un nuevo registro insertado, una transacción completada, etc.). Los adaptadores pueden ser específicos de una aplicación (por ejemplo  , desarrollados con las bibliotecas cliente del proveedor de la aplicación) o específicos de una clase de aplicaciones (por ejemplo  , pueden interactuar con cualquier aplicación mediante un protocolo de comunicación estándar, como SOAP , SMTP o Action Message Format (AMF)). El adaptador puede residir en el mismo espacio de procesos que el bus/concentrador o ejecutarse en una ubicación remota e interactuar con el concentrador/bus mediante protocolos estándar de la industria, como colas de mensajes, servicios web, o incluso utilizar un protocolo propietario. En el mundo Java, estándares como JCA permiten crear adaptadores de forma independiente del proveedor.

Formato y transformación de datos

Para evitar que cada adaptador tenga que convertir datos a/desde los formatos de todas las demás aplicaciones, los sistemas EAI suelen estipular un formato de datos común (o independiente de la aplicación). El sistema EAI también suele proporcionar un servicio de transformación de datos para facilitar la conversión entre formatos específicos de la aplicación y formatos comunes. Esto se realiza en dos pasos: el adaptador convierte la información del formato de la aplicación al formato común del bus. A continuación, se aplican transformaciones semánticas (conversión de códigos postales a nombres de ciudades, división/fusión de objetos de una aplicación en objetos de otras aplicaciones, etc.).

Módulos de integración

Un sistema EAI puede participar en múltiples operaciones de integración simultáneas, y cada tipo de integración es procesada por un módulo de integración diferente. Los módulos de integración se suscriben a eventos de tipos específicos y procesan las notificaciones que reciben cuando ocurren dichos eventos. Estos módulos pueden implementarse de diversas maneras: en sistemas EAI basados ​​en Java , pueden ser aplicaciones web , EJB o incluso POJO que cumplan con las especificaciones del sistema EAI.

Soporte para transacciones

Cuando se utiliza para la integración de procesos, el sistema EAI también proporciona coherencia transaccional entre aplicaciones al ejecutar todas las operaciones de integración en todas las aplicaciones en una única transacción distribuida general (utilizando protocolos de confirmación en dos fases o transacciones compensatorias ).

Actualmente, existen diversas opiniones sobre qué constituye la mejor infraestructura, modelo de componentes y estructura de estándares para la integración de aplicaciones empresariales. Parece haber consenso en que cuatro componentes son esenciales para una arquitectura moderna de integración de aplicaciones empresariales:

1. Un intermediario centralizado que gestiona la seguridad, el acceso y la comunicación. Esto se puede lograr mediante servidores de integración (como los servidores de integración de zona del Marco de Interoperabilidad Escolar (SIF) ) o ​​mediante software similar, como el modelo de bus de servicios empresariales (ESB), que actúa como gestor de servicios.
2. Un modelo de datos independiente basado en una estructura de datos estándar, también conocido como modelo de datos canónico . Al parecer, XML y el uso de hojas de estilo XML se han convertido en el estándar de facto y, en algunos casos, de jure para este lenguaje empresarial uniforme.
3. Un modelo de conector o agente en el que cada proveedor, aplicación o interfaz puede crear un único componente que pueda comunicarse de forma nativa con esa aplicación y con el intermediario centralizado.
4. Un modelo de sistema que define las API, el flujo de datos y las reglas de interacción con el sistema, de manera que se puedan construir componentes para interactuar con él de forma estandarizada.

Aunque se han explorado otros enfoques, como la conexión a nivel de base de datos o interfaz de usuario, no se ha comprobado que sean escalables ni adaptables. Las aplicaciones individuales pueden publicar mensajes en el intermediario centralizado y suscribirse para recibir ciertos mensajes de dicho intermediario. Cada aplicación solo requiere una conexión al intermediario. Este enfoque de control centralizado puede ser extremadamente escalable y altamente adaptable .

La integración de aplicaciones empresariales (EAI) está relacionada con tecnologías de middleware como el middleware orientado a mensajes ( MOM ) y tecnologías de representación de datos como XML o JSON . Otras tecnologías EAI implican el uso de servicios web como parte de una arquitectura orientada a servicios para la integración. La integración de aplicaciones empresariales tiende a centrarse en los datos. En un futuro próximo, incluirá la integración de contenido y procesos de negocio .

En 2003 se informó que el 70 % de todos los proyectos EAI fracasaban. La mayoría de estos fracasos no se debían al software en sí ni a dificultades técnicas, sino a problemas de gestión. Steve Craggs, presidente europeo del Integration Consortium, ha descrito los siete principales errores que cometen las empresas que utilizan sistemas EAI y explica las soluciones a estos problemas. ^{[ 5 ]}

1. Cambio constante: La propia naturaleza de EAI es dinámica y requiere gestores de proyectos dinámicos para administrar su implementación.
2. Escasez de expertos en EAI: La EAI requiere conocimientos sobre numerosos temas y aspectos técnicos.
3. Estándares en competencia: Dentro del campo de la EAI, la paradoja reside en que los propios estándares de EAI no son universales.
4. EAI es un paradigma de herramienta: EAI no es una herramienta, sino un sistema, y ​​debe implementarse como tal.
5. Diseñar interfaces es un arte: diseñar la solución no es suficiente. Es necesario negociar las soluciones con los departamentos de usuarios para alcanzar un consenso sobre el resultado final. La falta de consenso en el diseño de las interfaces conlleva un esfuerzo excesivo para establecer la correspondencia entre los requisitos de datos de los distintos sistemas.
6. Pérdida de detalles: La información que parecía poco importante en una etapa anterior puede volverse crucial más adelante.
7. Responsabilidad: Dado que muchos departamentos tienen requisitos contradictorios, debe existir una clara rendición de cuentas respecto a la estructura final del sistema.

En estas áreas pueden surgir otros problemas potenciales:

• Falta de coordinación centralizada del trabajo de EAI. ^{[ 6 ]}
• Requisitos emergentes: Las implementaciones de EAI deben ser extensibles y modulares para permitir cambios futuros.
• Proteccionismo: Las aplicaciones cuyos datos se integran suelen pertenecer a diferentes departamentos que tienen razones técnicas, culturales y políticas para no querer compartir sus datos con otros departamentos.

• Marco de arquitectura empresarial
• Estrategias para la integración de aplicaciones empresariales
• gestión de la semántica empresarial
• Integración de datos
• Integración de la información empresarial
• Integración empresarial
• Patrones de integración empresarial
• Autobús de servicio empresarial
• Arquitectura y metodología de referencia empresarial generalizadas
• Dispositivo de integración
• Centro de competencias de integración
• Plataforma de integración
• Integración de sistemas