1 Arquitecturas de Integración Alberto Pan Universidad de A Coruña 28/04/2011

2 Introducción (1) Integración de aplicaciones Hoy en día, construir nuevas aplicaciones a menudo involucra hacer colaborar entre sí a aplicaciones distribuidas, heterogéneas y posiblemente autónomas. Distribución: las diferentes aplicaciones pueden ejecutarse en máquinas conectadas a través de una red: LAN Internet Autonomía: El sistema de integración no puede esperar que la aplicación cambie su forma de actuar para facilitar la integración Aplicaciones heredadas Aplicaciones de otros departamentos Aplicaciones de otras empresas (B2B)

3 Introducción (2) Heterogeneidad Máquinas: mainframes, servidores (Sun, IBM, HP, etc.), estaciones de trabajo (Compatibles PC, Apple Macintosh, Sun, IBM, HP, etc.) Sistemas operativos: Solaris, HP-UX, AIX, Linux, MacOS, MS- Windows (9x, NT, 2000, XP), etc. Aplicaciones en distintos lenguajes: Java, C++, Visual Basic, Visual C++, Delphi, COBOL, etc. Distintas arquitecturas de datos: ficheros, bases de datos de distintos modelos y fabricantes, sitios web,… Distintos esquemas y formatos de datos. Ejemplo: App A: DIRECCION=“C\ Alcala, 32, 28080 Madrid”. App B: CALLE=“Calle Alcalá” NUM=“32”, CP=“28080”, CIUDAD=“Madrid”.

4 Introducción (y 3) Heterogeneidad: Razones Decisiones de ingeniería Diferentes personas eligen diferentes soluciones a un mismo problema Razones de coste Se compra el tipo de software/hardware que cumpla los requisitos y tenga un precio razonable Evolución tecnológica: Aplicaciones antiguas No es posible desecharlas y rehacerlas con las tecnologías más modernas Es preciso seguir utilizándolas hasta amortizar su coste de desarrollo y obtener beneficio

5 Arquitecturas Arquitectura SOA (Service Oriented Architecture) Orientada sobre todo a aplicaciones operacionales Arquitectura Data Warehouse Orientada eclusivamente a aplicaciones informacionales Arquitectura Mashups Orientada a aplicaciones tanto operacionales como informacionales Necesidades tácticas

6 Arquitectura SOA SRM Capa de Virtualización de Datos CRM ERP App1 App2 App3 App4 Web Docum entos Ficher os Web Services Gobernanza Seguridad Gestión Componentes reusables de Lógica de negocio: JEE/.NET/ ESB /EAI Integración de Plataforma Aplicaciones Proveedoras de Servicios Aplicaciones finales de usuario

7 Arquitectura SOA (2) Aplicaciones proveedoras de servicios: Gestión de clientes (CRM), Gestión de recursos (ERP), Gestión de proveedores (SRM), Facturación, Almacén,… Aplicaciones externas: socios, proveedores, clientes. Integración de Plataforma Comunicación de aplicaciones en diferentes máquinas. Acceso a aplicaciones independientemente de localización, hardware, SO y lenguaje de programación. Paradigma dominante: RPC. Para el programador invocar una aplicación remota es muy similar a invocar una aplicación local. Paradigma emergente: REST. Basado en los principios de la Web: recursos conectados por hiperenlaces. Tecnología dominante: Servicios Web.

8 Arquitectura SOA (3) Capa de Virtualización de Datos E.F. Codd empezó el paper más influyente (*) de los últimos 40 años de Ciencia Informática como sigue: “ Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation). (…) most application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed.“ Una de las ideas clave de la historia de la Ciencia Informática es esta: las aplicaciones deberían ser independientes de la estructura física y lógica de los datos. (*) E. F. Codd. A Relational Model of Data for Large Shared Data Banks (1970)

9 Arquitectura SOA (4) Capa de Virtualización de Datos Punto único de acceso a datos. Generalización del patrón DAO (Data Access Object). Ofrece API única de acceso a datos, independiente de arquitectura de almacenamiento. Proporciona componentes de acceso a datos reusables. Ejemplo: Obtener los datos de un cliente junto con sus incidencias graves abiertas y nuestro nivel de facturación con él. Independencia Física y Lógica. Si hay cambios en la localización/esquemas de las fuentes de datos, sólo hay que tocar esta capa, no las aplicaciones. Ejemplos Una fuente cambia su esquema de datos. Una fuente (e.g. Mainframe) es sustituida por otra. Los datos que antes venían de una fuente ahora vienen de dos (fusiones). Los datos que antes venían de dos fuentes ahora vienen de una (reingeniería).

10 Arquitectura SOA (5) Capa de Acceso e Integración de Datos (cont) Gobernanza. Punto único para: Definir políticas de acceso a datos: permisos. Determinar el impacto de cambios. Monitorizar el acceso a fuentes de datos: e.g. Limitar accesos concurrentes, detectar errores...... Software de soporte a esta capa puede incorporar: Maneras declarativas de crear combinaciones de datos: Ejemplo: “join” entre información de CRM, aplicación de incidencias y aplicación de facturación. Componentes reusables sin escribir código. Optimización de consultas distribuidas. Definición de vistas virtuales. Múltiples modos de acceso: JDBC, SOAP,......

11 Arquitectura SOA (6) Componentes de Lógica de Negocio Lógica de negocio que puede ser usada por una o varias aplicaciones finales. Ejemplos: Procesar un pago de un cliente. Procesar un pedido de un cliente. Gestionar una incidencia de un cliente.... Pueden programarse con tecnologías convencionales como JEE o.NET. Sin embargo, existen tecnologías específicas que facilitan la programación de ciertos tipos de procesos de negocio: EAI (Enterprise Application Integration), ESB (Enterprise Service Bus), BPM (Business Process Management)...

12 Arquitectura SOA (7) Componentes de Lógica de Negocio (cont.) Tecnologías como JAVA están más orientadas a la realización de procesos síncronos que: Reciben su entrada de un proceso llamante. Realizan alguna lógica, quizás invocando para ello a aplicaciones externas. Devuelven un resultado al llamante. Todo el proceso dura milisegundos o segundos. Si es necesario, pueden usarse transacciones. Ejemplo. Procesar un pago.

13 Arquitectura SOA (8) Componentes de Lógica de Negocio (cont.) Ejecución de algunos procesos puede durar días: E.g. procesamiento de una incidencia de cliente. Estos procesos plantean una serie de necesidades: Invocaciones asíncronas a aplicaciones externas. E.g. esperar por resultado acción correctora. Entradas pueden venir desde múltiples aplicaciones (no sólo el llamante) y en diferentes puntos de ejecución del proceso: E.g. el cliente pasa a estado VIP durante el procesamiento de la incidencia.

14 Arquitectura SOA (9) Componentes de Lógica de Negocio (cont.) Los “resultados” puede haber que notificárselos a múltiples aplicaciones, no sólo al llamante. E.g. Actualizar saldo con empresa instaladora. No siempre es posible usar transacciones tradicionales: No se puede bloquear un registro en BD durante tres días !! Acciones de compensación: deshacer los efectos de una acción (e.g. anular un pago).

15 Arquitectura SOA (y 10) Existen lenguajes específicos que ayudan a programar este tipo de aplicaciones: Modelan un proceso de negocio como un flujo que coordina a múltiples aplicaciones. A menudo, los flujos pueden crearse de forma gráfica. Existen múltiples lenguajes propietarios de cada fabricante. Estándar emergente: BPEL (Business Process Execution Language).

16 Data Warehouse

17 Data Warehouse (2) Los datos de las fuentes se copian periódicamente a un almacén central. Pueden copiarse todos los datos o sólo un subconjunto. Para disminuir la carga de las actualizaciones, las fuentes pueden enviar sólo los cambios producidos. Requiere dicho soporte por parte de las fuentes.

18 Data Warehouse (3) Arquitectura típica de una instalación Data Warehouse: Herramienta ETL (Extraction, Transformation and Load) para extraer la información de las bases de datos origen, transformarla de la forma deseada y volcarla en el repositorio central. Base de datos OLAP. Base de datos especial optimizada para consultas que involucren grandes cantidades de datos. Herramientas de generación de informes. Permite crear de forma sencilla informes complejos que utilicen la información almacenada en el repositorio central.

19 Data Warehouse (4) Sistemas tradicionales (OLTP) están diseñados para contestar gran número de consultas simultáneas, pero dónde cada consulta es relativamente sencilla. También están optimizados para realizar transacciones de escritura y actualización. Sin embargo, algunas aplicaciones (típicamente las de creación de informes y análisis de tendencias) tienen necesidad de ejecutar menos consultas pero más costosas. Asimismo las inserciones y actualizaciones pueden ser menos críticas o realizarse sólo en modo batch. Se han desarrollado nuevas arquitecturas para tratar estas situaciones de forma eficiente (OLAP).

20 Data Warehouse (y 5) OLTP: On-Line Transaction Processing. Consultas y actualizaciones frecuentes que involucran a relativamente pocas tuplas. Ejemplos: información sobre un cliente en un call-center, consulta y reserva de información de vuelos desde la web, etc, etc. Típicamente consultas recuperan información sobre un elemento identificado por una clave (e.g. CIF cliente). OLAP: On-Line Analytic Processing Consultas largas y complejas (pueden durar horas). Inserts/Updates en modo batch. Pueden abarcar a muchos o todos los elementos de información (e.g. todos los clientes). Técnicas válidas sólo si la actualidad de los datos no es crítica. Ejemplos: productos que más se venden de forma conjunta en un supermercado, clientes que compran frecuentemente los mismos items en una tienda electrónica.

21 Mashups La arquitectura de mashups pretende que usuarios sin conocimientos técnicos avanzados (power users) puedan crear sus propias aplicaciones para necesidades “tácticas”. Dichas aplicaciones se crean combinando componentes reusables, algunos de los cuáles pueden haber sido creados por programadores: Conectores para extracción de datos de fuentes Combinaciones de datos y/o procesamientos pre-definidos Widgets visuales reusables (e.g. mapas, gráficos para informes,…)

22 Mashups: Modelo de Referencia

23 Mashups (3) Capa de acceso a datos. Acceso a fuentes heterogéneas : Feeds: RSS, ATOM. Web Services: SOAP, XML, JSON. Sitios Web. Bases de datos. … Data Mashup. Combinar e unificar datos. Widget Layer. Crear componentes visuales reutilizables (widgets). Crear automáticamente widgets para consultar data mashups. Widgets deberían poder interactuar con otros widgets creados de forma independiente.

24 Mashups (4) Widget Assembly. Componer widgets para crear la mashup visual. Registry. Directorio de componentes reusables. Collaboration. Aprovechar experiencia de usuarios previos para facilitar el proceso de creación de mashups. E.g. recomendaciones automáticas, composición automática.

25 Mashups (5)

26 ¿Qué encontramos hoy? Aplicaciones transaccionales / operacionales. Arquitectura más o menos similar a la SOA (o se aspira conscientemente a ello) Normalmente coexisten componentes de lógica de negocio reusables implementados usando tecnologías de desarrollo convencionales y tecnologías de flujos. La capa de integración / abstracción de datos muchas veces no existe, aunque esto está empezando a cambiar. Cuando la capa de integración / abstracción de datos existe, es frecuente que algunas aplicaciones finales accedan directamente a ella (no necesitan de la capa de componentes de lógica de negocio). Normalmente, se está lejos del ideal de tener una gobernanza unificada (e.g. metadatos, gestión, seguridad) pero se aspira conscientemente a ello.

27 ¿Qué encontramos hoy? (2) Aplicaciones informacionales. La mayor parte de organizaciones medianas o grandes disponen de algún tipo de data warehouse, que es útil para muchos propósitos, pero: No soporta tiempo real Herramientas no suelen soportar fuentes que no sean bases de datos o ficheros planos. Procesos de ETL tienen un nivel de reusabilidad bajo. Nuevos proyectos requieren tiempos largos. Por ello, cada vez se introduce una capa de virtualización de datos por encima del data warehouse para permitir complementar el data warehouse.

28 ¿Qué encontramos hoy? (y 3) ¿Qué hay de las mashups?. Han aparecido las primeras implementaciones industriales de este concepto. Sin embargo se están encontrando con problemas: Momento cero: escasa cantidad de componentes. Complejidad: es muy difícil hacer herramientas suficientemente potentes para abordar necesidades realistas que puedan ser usadas por personal no técnico -> Ámbito de investigación

29 Ejemplos: SOA en Biogen Used for Application Integration Data Integration Business Intelligence Partner (B2B) Integration Business Process Automation Technology Oracle FUSION Middleware Denodo Data Virtualization Business areas Mfg. & Supply Chain Compliance General and Admin Commercial Research & Discovery 29 Diverse data sources and formats Applications (Internal & External) Applications (Internal & External) Web/Intranet Data Warehouses Files Partner (B2B) Data Services App Svcs Data Svcs Derived Business Services

30 Defects RMA Predictive Analytics … EDW C3(BL) n th source... Application APIs (i.e.CSO/SSO) QDI CNC Smart Services BI Reporting (Business Objects) DQ/MDM? DQ/DV CCEM Benefits Dashboards consistency Data accuracy Scalable and repeatable Leverages Cisco-wide analytics SAVI (Data Svcs & ACE) Benefits Infrastructure designed for Analytics No degradation to CCEM Contributes analytic output to CCEM Moves AutoFocus off of Oracle Potential proof point for UCS SAVI Data Services Federated Data (Denodo) Persistent storage (ParAccel) Analytic Modeling (SAS) (DataFlux) CCEM Reports & Dashboards CCEM Cisco IT Federated Data Data Qlty Data Valdn Predictive Social Media CIP 1.x Application(s) (like PDA) DQ/ MDM? Agile reporting in CISCO CCEM SAVI ACE

31 ¿Mashups? En Navteq Web, Devices, Users, Partners, App Builders Scheduler POIs Real Time Batch Location Content Management System