6.1 Introducción a los Sistemas EAI

Integración de Aplicaciones (1)

El problema de la integración de aplicaciones consisteen hacer colaborar entre sí a aplicacionesdistribuidas, heterogéneas y posiblementeautónomas.

Una aplicación es “autónoma” con respecto al sistema de integración, si éste no puede esperar que la aplicaciónrealice ningún cambio en su forma de actuar para facilitar la integración (e.g. aplicaciones de otras empresas, aplicaciones legacy, etc.)

CORBA y WebServices solucionan el problema de comunicar aplicaciones distribuidas con entornos de ejecución y desarrollo diferentes:

Independencia de Plataforma hardware.Independencia de Sistema Operativo.Independencia de Lenguaje de programación.

Integración de Aplicaciones (2)

Sin embargo, el problema de la integraciónde aplicaciones heterogéneas es máscomplejo. Arquitectura de integración en capas:

Integración de Plataforma.RPC, RMI, ORBs, SOAP.

Integración de DatosData Warehouse (batch), sistemas federados-EII (tiempo real), …

Integración de componentes: J2EE, .NET.

Integración de Aplicaciones (3)

Arquitectura de integración en capas (cont)Integración de Aplicaciones

Definición de flujos de mensajes inter-aplicación

Integración de ProcesosProcesos de negocio como flujos de mensajes entre actividades, recursos, etc.

Integración B2BIntegración con clientes/proveedores y socios

Integración de Aplicaciones (y 4)

Veremos:Coordinación de aplicaciones.

¿Cómo crear de manera rápida y sencilla nuevasaplicaciones que utilicen las ya existentes?Programar directamente estas aplicaciones es posible, pero largo, complejo y con cambios costosos.La solución más popular hoy en día: sistemas de gestiónde flujos.

Integración de datos (Tema 7). Heterogeneidad de modelo de datos.Heterogeneidad de taxonomías.Heterogeneidad de esquema de datos.Etc.

Entorno actual de Negocio (1)

Una organización mediana/grande dependepara su funcionamiento de gran cantidad de aplicaciones informáticas:

CRM (Customer Relationship Management), ERP (Enterprise Resource Planning), Call Center, Facturación, Pagos, Portal web, etc.

Necesidad de automatización de procesos:Ahorro de costes.Evitar errores.Incrementar productividad.Rápido tiempo de reacción (real-time enterprise).Etc.

Entorno actual de Negocio (y 2)

Escribir estos procesos en CORBA o WS eslargo, costoso y cualquier cambio requierereprogramar.Las empresas modernas desean una mayor rapidez para la creación y modificación de procesos de negocio:

El objetivo ultimo sería que la creación y cambiode procesos de negocio pudiese ser realizada sin necesidad de programar -> podrían hacerlo losgestores de negocio (en la práctica, esto está muylejano).

Desearíamos tener entornos declarativos paraesta definición de procesos:

Deberían además incluir interfaces gráficas.

Procesos de Negocio

Los procesos básicos de una organización involucran la interacción entre múltiples aplicaciones preexistentes y/o personas.Normalmente, estos procesos pueden modelarse como flujos (workflows) que especifican cómo deben colaborar entre sí las distintas entidades para llevar a cabo el proceso.Un flujo especifica aspectos tales como:

La secuencia de acciones a realizar por cada entidad.Los datos intercambiados entre las entidades y la manera en que deben ser transformados.Reglas para la toma de decisiones.Restricciones a satisfacer.Etc.

Ejemplo (1)

Procesamiento de una incidencia en una operadora de telecomunicaciones.1. Incidencia recibida desde aplicación de CallCenter o ayuda

Web.2. Sistema analiza incidencia y la clasifica de acuerdo a su

urgencia y al tipo de producto al que afecta. 3. Se consulta a la aplicación de CRM (Customer Relationship

Management) para determinar si el cliente tiene contrato de mantenimiento (si no, la incidencia no se atenderá).

4. Se emite una petición a la aplicación de ERP (Enterprise Resource Planning) para que la incidencia se asigne a algún miembro del servicio técnico para que realice un diagnóstico preliminar y sugiera una acción correctora. En función de la clasificación de la incidencia, se le solicitará al ERP personal de un grupo u otro (e.g. teléfono, Internet,..).

Ejemplo (2)

5. Cuando el servicio técnico responde con el diagnóstico preliminar (usa para ello una aplicación web desarrollada por la operadora), se procesa su respuesta. Se chequea que la respuesta llegue en plazo y se comunica a la aplicación ERP (control de productividad).

6. Si la acción correctora requiere de un desplazamiento al cliente, se emite una petición a la aplicación ERP de instaladores para que, en función de las características de la incidencia y la acción correctora (localización geográfica, historial con ese tipo de actuaciones, etc.), se escojan hasta tres posibles instaladores.

7. Se solicita precio y plazo para la acción a los instaladores (Servicio web instalador, web especial de la operadora, teléfono...)

8. Se escoge el instalador para la acción en función de reglas de asignación (menor precio y plazo).

Ejemplo (3) 9. La petición de intervención es comunicada al instalador

escogido, que debe confirmar que la acepta. El instalador debe recibir la información de la incidencia y la acción correctora a ejecutar.

10. Cuando el instalador realiza la acción correctora planificada, informa del resultado.

11. Si el resultado es positivo, la incidencia se cierra. Se informa al ERP de instaladores, a la aplicación de pagos y al CRM.

12. Si el resultado es negativo, vuelve a asignarse al servicio técnico (a través de la aplicación ERP) para que recomiende una nueva acción correctora. Se adjunta el informe entregado por el instalador.

13. El servicio técnico puede determinar que la acción correctora fue mal realizada por el instalador. En ese caso, se informa al ERP de instaladores y a la aplicación de pagos para deshacer el pago.

Ejemplo (4)

En todo este proceso se necesita:Comunicación de todas las aplicaciones involucradas (Web Services, CORBA, soluciones ad-hoc …).Los mensajes intercambiados deben ajustarse a normas de formato establecidas y debe poder validarse su corrección sintáctica (XML).Los mensajes y documentos intercambiados deben poder validarse para verificar el cumplimiento de restricciones (e.g. validar si la acción correctora sugerida por el servicio técnico tiene un coste estimado que está dentro del aceptado para ese tipo de incidencia).Deben existir mecanismos para transformar y combinar documentos.

Ejemplo (y 5)

Lógica de control inter-aplicación para estructuras condicionales (e.g. si incidencia se cierra o no con éxito) y repetitivas (e.g. repetir pasos 3-11 hasta que incidencia resuelta).Ejecutar reglas que permiten tomar decisiones en función de los datos recibidos (e.g. clasificación de una incidencia, elección de instalador).Es preciso soportar interacciones asíncronas (e.g. respuestas del servicio técnico, respuestas de instaladores).Transacciones inter-aplicación (e.g. deshacer el pago previsto a un instalador, que involucra a la aplicación de pagos y al ERP de instaladores).

Enfoque Tradicional (1)

El enfoque tradicional para implementar un nuevo proceso de negocio es:1. Se identifica qué funcionalidad es necesaria de cada

aplicación.2. Se crean programas ad-hoc que acceden de la forma

deseada a cada aplicación: o bien a través de sus interfaces particulares no estándar o a través de alguna interfaz estándar (CORBA o Web Service) si la hay (no suele haberla).

Muy a menudo, se ataca directamente la BD de la aplicación saltándose su API (¡ adiós encapsulación !).

3. Se crea otro programa ad-hoc que combina las operaciones de cada aplicación de la manera deseada para construir el flujo.

Enfoque Tradicional (y 2)

Problemas:Difícil, largo y costoso de programar.

Los procesos ad-hoc deben encargarse por sí mismos de tareas complejas como el soporte de mensajería o las transacciones distribuidas.Además, a menudo esto desemboca en que cada proceso de negocio realiza estas tareas de forma diferente.

Cualquier cambio implica reprogramar. La creación de nuevos procesos de negocio involucra crear nuevo código ad-hoc para acceder a las aplicaciones y coordinar su actuación.

Sistemas de Gestión de Flujos (1)

Casi todos los procesos de negocio pueden modelarse como flujos, por lo que es posible un enfoque mejor:

Se escribe un “envoltorio” o “adaptador” para cada aplicación

Se define una interfaz remota estándar (e.g. Web Service) para el adaptador, que permite acceder a las funcionalidades de la aplicación.La información de entrada y salida a cada aplicación se modela de acuerdo a algún formato de intercambio (e.g. XML).

Sistemas de Gestión de Flujos (2)

A partir de ahí, la creación de nuevos procesos de negocio puede hacerse de manera declarativa:

El enrutamiento de mensajes entre aplicaciones, las condiciones que deben cumplirse y las transformaciones a realizar en ellos pueden especificarse con un lenguaje declarativo.Este lenguaje declarativo permite que, en gran medida, la creación del flujo pueda realizarse de manera gráfica.El soporte para el intercambio de mensajes, las transacciones y otros mecanismos genéricos de diseño es proporcionado para todos los procesos de negocio por la plataforma de gestión de flujos.

Sistemas de Gestión de Flujos (3)

Ventajas:Crear un nuevo proceso de negocio no implica programar (al menos, en gran parte).La Plataforma se encarga de algunas tareas complejas como la transaccionalidad o la mensajería.La respuesta a cambios es más rápida.No es necesario escribir cada vez código ad-hoc para las aplicaciones (esto no siempre es cierto, pero al menos, una vez añadida una funcionalidad, queda disponible para todos los procesos de negocio).

Sistemas de Gestión de Flujos (y 4)

Ventajas:Todos los procesos de negocio son gestionados de la misma forma y desde un único punto:

Facilidad de administración y obtención de informes (cuadros de mando, análisis de tendencias, etc.).Facilita la implantación de políticas globales: autenticación, seguridad, etc.

Algunas herramientas traen ya implementados:Adaptadores típicos.Flujos típicos (normalmente sirven sólo como plantilla de desarrollo):

Incidencias.PedidosEtc.

Evolución (1)

1ª Generación: WMS (Workflow Management Systems).

Orientado a que las entidades involucradas en los procesosde negocio sean personas:

Las acciones a realizar dentro de un flujo consistenfundamentalmente en el rellenado o la interpretación de formularios por parte de los usuarios.

Dificultades de integración con aplicaciones existentes.Falta de funcionalidad:

Sin soporte para transaccionesPoca escalabilidad.

Visión de muy alto nivel:No se ocupa de peculiaridades técnicas de las aplicacionesinvolucradas.En la práctica, involucra gran cantidad de trabajo “manual” de integración.

Evolución (2)

2ª Generación: Sistemas EAI (Enterprise Application Integration).

Centrados en coordinar aplicaciones, en lugar de personas: Conectores (o Adaptadores) pre-construidos para tecnologíashabituales. Opción: JCA. J2EE Connector Architecture. XML como lenguaje de comunicación inter-aplicación. Reglas de transformación de documentos XML para definir“traducciones” entre los lenguajes de cada aplicación.Soporte transaccional.

Escalabilidad y tolerancia a fallos:Basados en arquitecturas distribuidas.Trazabilidad.

Centrado fundamentalmente en Intranets (perspectiva intra-organización).Lenguajes propietarios.

Evolución (y 3)

3ª Generación: Salto al B2B. ¿Orquestación de Servicios Web?

Perspectiva inter-organización.Aumentan las preocupaciones de seguridad.Aumentan los requisitos de autonomía de las aplicaciones.Surgen nuevas posibilidades. Ejemplo: descubrimiento de aplicaciones relevantes (¿UDDI?).Etc.

Aún está por establecer la norma definitiva: BPEL4WS, WSCI, BPML,…

Arquitectura de un sistema EAI

Cada aplicación tiene asociado un adaptador (o conector, o “wrapper”) específico:

Hacen que todas las aplicaciones se ajusten a un modelocomún.Se ocupan de la comunicación inter-aplicación (Corba, RMI, Servicios Web…)Traducen mensajes del lenguaje del sistema EAI al lenguajede la aplicación y las respuestas de la aplicación al lenguajeEAI.

Un “Concentrador” (“Hub”) central:Controla las interacciones entre las aplicaciones paraejecutar un flujo.Funcionalidades de conversión de datos (“Data Mapping”).Autorización: seguridad, usuarios, permisos,…Notificaciones.Trazabilidad.

Arquitectura de un sistema EAI

Arquitectura Hub & Spoke

Adaptadores

Aplicaciones no hablan directamente entre sí sino a través del hub.La mayoría de sistemas EAI incluyen adaptadorespre-construidos fácilmente configurables paraalgunos casos:

Servicios Web, Corba...JCA: J2EE Connector Architecture.Aplicaciones de fabricantes populares: ERPs, CRMs, Gestoresde contenidos, …Para el resto de aplicaciones (normalmente un elevadoporcentaje), es necesario programar de forma manual todoo parte del adaptador implementando alguna interfaz.Se pretende que el programador de adaptadores tenga queocuparse sólo de proporcionar el “camino de acceso” a la aplicación, sin lógica ni post-procesamiento complejo. No siempre es posible.

Servicio de mensajería

Un sistema EAI requiere de funcionalidades de creación, envío y recepción de mensajes:

Garantía de entrega, de orden de mensajes...Garantía de integridad y privacidad de mensajes.Notificaciones de error.Diferentes semánticas de envío (“once and only once”, “at least once”, etc.)Mensajes multicast.Mensajería síncrona y/o asíncrona.Mensajes punto a punto: Colas de mensajes.Mecanismos de subscripción: jerarquías de temas.Muchos sistemas utilizan implementaciones de JMS (Java Message Service).

Autorización

No todos los usuarios/aplicaciones pueden hacer lo mismo.Los sistemas EAI deben incorporar o deben poderseintegrar fácilmente con una estructura de permisos.

¿Qué usuarios/aplicaciones pueden iniciar o realizar ciertosprocesos?¿Qué usuarios/aplicaciones pueden gestionar ciertosrecursos?¿Qué usuarios pueden monitorizar el sistema?

Normalmente, los sistemas EAI permiten definirgrupos de usuarios y políticas de acceso basadas en roles.

Complementos

Muchos fabricantes ofrecen una serie de herramientas complementarias a la funcionalidadbásica EAI:

Herramientas de administración: trazabilidad.Integración de información (EII).Cuadros de mando y análisis de tendencias.Creación sencilla de portales para el acceso o uso de la funcionalidad integrada en el sistema.Etc.

Fabricantes

Algunas marcas :WebMethodsVitriaTibcoBEAOracleIBMMercatorSoftware AG…