6.1 Introducción a los sistemas EAI
Integración de Aplicaciones (1) El problema de la integración de aplicaciones consiste en hacer colaborar entre sí a aplicaciones distribuidas, heterogéneas y posiblemente autónomas. Una aplicación es autónoma con respecto al sistema de integración, si éste no puede esperar que la aplicación realice 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ón de aplicaciones heterogéneas es más complejo. Arquitectura de integración en capas: Integración de Plataforma. RPC, RMI, ORBs, SOAP. Integración de Datos Data Warehouse, sistemas federados (EII), 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 Procesos Procesos de negocio como flujos de mensajes entre actividades, recursos, etc. Integración B2B Integració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 nuevas aplicaciones 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ón de 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 depende para 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. Etc.
Entorno actual de Negocio (y 2) Escribir estos procesos en CORBA o WS es largo, costoso y cualquier cambio requiere reprogramar. 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 cambio de procesos de negocio pudiese ser realizada sin necesidad de programar -> podrían hacerlo los gestores de negocio (en la práctica, esto está muy lejano). Desearíamos tener entornos declarativos para esta 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. Pedidos Etc.
Evolución (1) 1ª Generación: WMS (Workflow Management Systems). Orientado a que las entidades involucradas en los procesos de negocio sean personas: Las acciones a realizar dentro de un flujo consisten fundamentalmente 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 transacciones Poca escalabilidad. Visión de muy alto nivel: No se ocupa de peculiaridades técnicas de las aplicaciones involucradas. 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ías habituales, 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 intraorganización).
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 modelo común. Se ocupan de la comunicación inter-aplicación (Corba, RMI, Servicios Web ) Traducen mensajes del lenguaje del sistema EAI al lenguaje de la aplicación y las respuestas de la aplicación al lenguaje EAI. Un Concentrador ( Hub ) central: Controla las interacciones entre las aplicaciones para ejecutar 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 adaptadores pre-construidos fácilmente configurables para algunos casos: Servicios Web, Corba... Aplicaciones de fabricantes populares: ERPs, CRMs, Gestores de contenidos, Para el resto de aplicaciones (normalmente un elevado porcentaje), es necesario programar de forma manual todo o parte del adaptador implementando alguna interfaz. Se pretende que el programador de adaptadores tenga que ocuparse 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 poderse integrar fácilmente con una estructura de permisos. Qué usuarios/aplicaciones pueden iniciar o realizar ciertos procesos? Qué usuarios/aplicaciones pueden gestionar ciertos recursos? Qué usuarios pueden monitorizar el sistema? Normalmente, los sistemas EAI permiten definir grupos de usuarios y políticas de acceso basadas en roles.
Complementos Muchos fabricantes ofrecen una serie de herramientas complementarias a la funcionalidad bá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 : WebMethods Vitria Tibco BEA Oracle IBM Mercator Software AG