Arquitecturas y Middleware

Arquitecturas y Middleware Taller de Sistemas de Información 1 InCo – Facultad de Ingeniería Abril 2004

Temario • Evolución de las arquitecturas • Centralizada • Cliente/Servidor (2 y n-Capas) • Bases de Datos Distribuidas • Internet/Intranet. • Ejemplos • Middleware y clasificación del mismo. • Configuración del Panorama Actual. Taller de Sistemas de Información 1

Evolución según décadas Taller de Sistemas de Información 1

Evolución de las ArquitecturasAl comienzo: Mainframes y Centralización • Gerente de IT priorizaba la integridad de los datos a través de la centralización. • No se le daba importancia a la integración de sistemas heterogéneos. • Los primeros conceptos de distribución fueron recluidos a las áreas donde eran estrictamente necesarios, caso de EDI, que usualmente eran unidades completamente separadas de la organización. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Tipos de Procesamiento • DBMSs. • Lógica asociada a datos en la BD. • Lógica (reglas) del negocio. • Validaciones sobre atributos (campos). • Relacionadas con la lógica del negocio. • Según el tipo o formato de los datos. • Armado y presentación de interfase. • Despliegue de interfase. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura Centralizada • Mayoría del procesamiento en el servidor. • En el cliente: • Solo el Despliegue de la Interfase. • Ventajas: • Simplicidad. • Uso de hardware del cliente muy simple. • Desventajas: • Recarga del servidor y escalabilidad. • Problemas en acceso remoto. Taller de Sistemas de Información 1

Evolución de las ArquitecturasArquitectura Centralizada (2) Taller de Sistemas de Información 1

Evolución de las ArquitecturasMinicomputadores y comienzos de Distribución • Los principales conceptos de distribución, como la comunicación sincrónica o asincrónica o las facilidades de bajo nivel para integrarse con aplicaciones remotas, aparecieron con los minicomputadores (léase DEC VMS, Tandem, HP, etc). Ej. MQSeries, de IBM. • Oculta por el boom del surgimiento de los PCs, la distribución no tuvo auge hasta que Internet se volvió un “commodity”. • Definición: Un ambiente computacional se dice distribuido cuando sus programas o BDs están ubicados en dos o más computadores. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura Cliente – Servidor • Una forma de definirlo: • C/S es una relación entre procesos corriendo en máquinas separadas: • El servidor (S) es un proveedor de servicios. • El cliente (C) es un consumidor de servicios. • C y S Interactúan por un mecanismo de pasaje de mensajes: • Pedido de servicio. • Respuesta. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura C/S - Ventajas • La gran ventaja es usar lo mejor de ambos sistemas: • Puestos de trabajo autónomos (Cliente): • Ambiente mono-usuario. • Excelente relación potencia/costo. • Aplicaciones potentes. • Interfaces simples y amigables. • Grandes sistemas (Servidor): • Ambiente multiusuario. • Gestión centralizada de la BD. • Gran seguridad. • Compartir información y dispositivos. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura C/S – Separación y Contras • Separación del procesamiento entre Cliente y Servidor. • Cliente: Despliegue, Interfase, Validaciones, Reglas Negocio. • Servidor: Reglas Negocio, Lógica BD, DBMS. • Desventajas: • Más compleja que Centralizado. • Escalabilidad: procesamiento en C o S. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura C/S - Propiedades esperadas • Acceso a recursos: • Un S puede atender a varios C y controlar el acceso a los recursos. • Transparencia: • El diálogo entre C y S debe ser transparente a la ubicación, hardware y plataforma. • Encapsulamiento: • Un pedido indica qué servicio se desea. El S se encarga de cómo resolverlo. Se puede modificar los S sin afectar los C. • Escalabilidad: Se puede escalar sin afectar a otros componentes: • Horizontal: se agregan otros C y S. • Vertical: se cambia un S por otro más potente o se distribuye su trabajo entre varios. • Integridad: • Las funciones y datos del S son manejadas en forma centralizada. Eso beneficia el mantenimiento e integridad de los datos. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura C/S – Tipos de Clientes • Modelo “cliente flaco”: • Servidor rápidamente saturado. • Gran circulación de datos de interfase en la red. • Modelo “cliente gordo”: • Casi todo el trabajo en el cliente. • No hay centralización de la gestión de la BD. • Gran circulación de datos inútiles en la red. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura C/S – Lógica de Aplicación Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura C/S – Lógica de Aplicación • Lógica de la aplicación en el cliente: • La semántica está dividida entre los programas. • C/prog sólo maneja una parte del problema. • Los controles están “embebidos” en el código. • Problemas de mantenimiento, dupl. esfuerzo e integridad. • Lógica de la aplicación en el servidor: • Lógica centralizada y consistente. • Aumenta seguridad e integridad. • Algunos controles los puedo expresar en SQL (triggers), otros deben ser complicados. • Aumenta trabajo y complejidad del servidor. Taller de Sistemas de Información 1

Evolución de las ArquitecturasArq. en 3 Capas - Distribución de Procesos • Se tienen Servidores de Procesos o Aplicaciones. • Cliente: Despliegue, Interfase, Validaciones. • Servidor Aplicación: Validaciones, Reglas Negocio. • Servidor BD: Lógica BD, DBMS. • Ventajas: • Mas escalable. • Desventajas: • Mayor complejidad de sistema. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura de BD Distribuidas • Un opción además de distribuir procesos, es distribuir datos. • Se tiene varios Servidores de BD: • Las consultas/operaciones se distribuyen en los diferentes sitios. • Pueden haber datos replicados. • Ventajas: • Mayor disponibilidad de datos. • Distribución del procesamiento de la BD. • Desventajas: • Arquitectura más compleja. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitectura Internet/Intranet • Internet/Intranet: clientes = browsers html • Se tiene una arq. C/S en 4 capas: • Serv BD, Serv Aplic, Serv Web, Cliente. • En el Servidor Web se: • Procesa la conexión con el cliente. • Prepara la interfaz a desplegar en el cliente. • Ventajas: Cliente universal: browser html. • Desventajas: • Procesamiento de cliente limitado. • Baja conexión cliente/servidor. Taller de Sistemas de Información 1

Evolución de las Arquitecturas Arquitecturas en N Capas Taller de Sistemas de Información 1

Evolución de las ArquitecturasEjemplos • File Servers: • C pide bloques de archivos al S. • Es la primera forma de C/S. Cliente muy gordo. • Database Servers: • C hace pedidos SQL, S construye el result. y lo envía. • Hace un uso más eficiente de recursos. Lógica en C. • Transaction Servers: • C invoca proced. remotos que residen del lado del S, junto al DBMS. Cada proced. consiste de pedidos SQL para el DBMS. • Lógica en S. Taller de Sistemas de Información 1

Evolución de las ArquitecturasEjemplos (2) • Groupware Servers: • Involucra el intercambio de datos semi-estructurados (texto, imágenes, mail, workflow…). • C envía mensajes al S (Originalmente en formato propietario, nuevos productos usan email). Lógica en S. • Object Application Servers: • Una aplicación se escribe como un conjunto de objetos que se comunican usando un ORB. Un objeto C invoca métodos en objetos remotos S. El ORB encuentra al objeto S e invoca al método. • Está orientado a implementar servidores de aplicaciones en arquitecturas de +3 niveles. Taller de Sistemas de Información 1

Evolución de las ArquitecturasEjemplos (3) • Web Servers: • En la primera versión: • Un C (browser) solicita un documento por su nombre. El S retorna el documento. • C muy flaco. • El modelo ha evolucionado: • Comenzó con la ejecución de programas en el servidor. • Enriquecimiento de la web con objetos distribuídos (object web). • Arquitectura de N niveles. Taller de Sistemas de Información 1

MiddlewareDefinición • Es el “pegamento” (glue) que ayuda a la conexión entre programas (o bases de datos). • Más formalmente: • Es el soft-sistema que permite las interacciones a nivel de aplicación entre programas en un ambiente distribuido. • Por soft-sistema (system software) se entiende el software posicionado entre una aplicación y un sistema de menor nivel (s. Op, DBMS, Servicio Red). Taller de Sistemas de Información 1

MiddlewarePara qué usar Middleware ? • Dadas dos aplicaciones que se quieren conectar, hay que resolver la comunicación entre los procesos. • Si las aplicaciones se conectan directamente a soft de red, entonces no se necesita Middleware. • Este encare complica el desarrollo de las aplicaciones: • Se debe programar módulos de bajo nivel. • Este desarrollo se repite para cada aplicación a conectar. • El soft de Middleware permite realizar esta conexión a través de interfases de alto nivel, por ejemplo que permiten ver un procedimiento remoto como si fuera local. Taller de Sistemas de Información 1

MiddlewareEsquema de conexión sin Middleware • Los programas deben resolver la conexión usando medios de bajo nivel, cercanos al Sistema de Red. Programa Programa Sistema Operativo Sistema Operativo Sistema Red Sistema Red Taller de Sistemas de Información 1

MiddlewareEsquema de conexión con Middleware • La capa de Middleware permite programar la comunicación mediante herramientas de alto nivel. • Por ejemplo: procedimientos, mensajes, acceso a objetos. Programa Programa Sistema Operativo Sistema Operativo Middleware Middleware Sistema Red Sistema Red Taller de Sistemas de Información 1

MiddlewareEjemplos • Ejemplos de Middleware: • Drivers a DBMSs. • Acceso a DBMS desde un programa u otro DBMS. • Remote Procedure Call (RPC). • Invocación a procedimientos remotos como si fueran locales al programa. • Message Oriented Middleware (MOM). • Envío de mensajes entre aplicaciones. • Object Request Brokers (ORB). • Invocación a procedimientos y propiedades de objetos distribuidos en distintos equipos. Taller de Sistemas de Información 1

Cliente Cliente Cliente Cliente Cliente Servidor Aplicaciones Servidor Aplicaciones Servidor WEB Servidor Aplicaciones Servidor Aplicaciones Servidor DBMS Servidor DBMS MiddlewareAplicación en Arquitecturas de más de 3 niveles MOM TPM ORB RPC TPM TPM Conexión a DBMS Conexión a DBMS Taller de Sistemas de Información 1

Middleware Clasificación (1) • De base (Basic Middleware). • Data Middleware. • Remote File Access, Remote DB Access. • Permite el acceso a datos desde programas u otros BDs. • Communication Middleware. • Permiten la comunicación entre programas. • Ej. RPC, MOMs. • Platform Middleware. • Permiten resolver invocaciones o acceso a datos entre programas. Proveen un runtime environment, que incluye tecnologías de Middleware de datos y comunicaciones. • Ej. Application servers, ORBs, OTMs & TPMs. Taller de Sistemas de Información 1

Middleware Clasificación (2) • Integrador (Integration Middleware). • Características: • Permiten conexión de alto nivel entre aplicaciones desarrolladas independientemente, o entre sistemas con diferente Middleware. • Embeben tecnologías de Middleware básicas. • Subtipos: • Gateways, Superservices, Integration Brokers, Business Process Managers. Taller de Sistemas de Información 1

Basic MiddlewareData Middleware / SQL Middleware • Características: • Conectan programas con DBMS o DBMSs entre si a través de un API, con uso opcional de lenguaje de consulta. • Fuertemente asociados a tecnologías de DBMS. • Incluyen un componente cliente y otro servidor. • Ejemplos: • ODBC, OLEDB, JDBC Taller de Sistemas de Información 1

Basic Middleware Data Middleware / SQL Middleware La idea es que diferentes DBMS den la ilusión de ser un único sistema, es decir un sistema federado. Entonces tengo diferentes clientes accediendo al sistema federado. • Problemas que lo impiden: • SQL no es tan estándar: SQL (‘ 86), SQL2 (‘ 92), SQL3 (‘ 99). • Cada vendedor tiene sus propias extensiones (dialectos). • Diferencias en: • APIs (Application Programming Interface). • Driver: Runtime que acepta llamadas, formatea mensajes (FAP: Format and Protocols) y maneja el intercambio. • Stacks. Sólo algunos usan transporte estándar: sockets, named pipes Taller de Sistemas de Información 1

Basic Middleware Data Middleware / SQL Middleware • API común: facilita el desarrollo, pero sigue habiendo múltiples FAPs, además qué API usar ? • FAP o driver común: el uso de una FAP simplifica al cliente. Pero implica más trabajo para el servidor. Ejemplos de FAPs: IBM-DRDA, EDA/SQL. • Estandarizar API y FAP: debe soportar un súper conjunto de dialectos y facilita el desarrollo de aplicaciones y el mantenimiento. El problema es que los vendedores deben aceptar cambiar su FAPs. Es un ideal ! Taller de Sistemas de Información 1

Basic MiddlewareSQL Middleware - Call Level Interface • Objetivo: Cualquier cliente hable con cualquier servidor. • Semántica común de SQL. • Dialectos se ejecutan directamente (pass through). • Permite crear y ejecutar comandos SQL en runtime (dinámico) • Soporta sólo SQL dinámico: • No requiere pre-compilar. • Requiere el uso de drivers especializados. • Traducen llamadas CLI a código nativo. • Un driver por DBMS. • Incluye un manejador de drivers. Taller de Sistemas de Información 1

Basic Middleware SQL Middleware - Propuestas CLI • X/Open SAG CLI (SQL Access Group’ 88) • Standard ISO SQL/CLI ‘ 96. • Interfase procedural para SQL. • Codificación de tipos de datos, manejo de errores. • ODBC (Microsoft ‘ 92) • Versión extendida de SAG CLI • OLE DB (Microsoft ‘ 97) • Extensión de ODBC para ActiveX • Interfase OO. • JDBC (Javasoft ‘ 97) • Java CLI. Taller de Sistemas de Información 1

Basic Middleware Communication Middleware • RPC • Esconde la red. • Cliente invoca a una función del servidor remoto y se bloquea hasta tener el resultado. • Se pasan parámetros de la forma normal. • Message Oriented Middleware (MOM) • Aplicaciones sólo ponen y sacan mensajes de colas. • No se conectan. C y S pueden correr en diferentes tiempos. • No necesariamente se requiere respuesta. Taller de Sistemas de Información 1

Basic Middleware RPC vs. MOM • RPC: • Sincrónico: Se requiere una conexión. Cliente se bloquea. • Respuesta inmediata. • Ideal para aplicaciones que sincronizar acciones. • Ejemplo: Aplicaciones interactivas, transacciones. • MOM: • Asíncrono: Cliente y servidor operan en diferentes tiempos. • Respuesta lenta, cuando el servidor pueda contestar. • Ideal para informar, para aplicaciones poco conectadas. • Ejemplos: Email, workflow. Taller de Sistemas de Información 1

Platform Middleware • Permiten la comunicación entre programas a través de mecanismos de mayor nivel que los otros Basic Middleware. • Combinan técnicas de los Communication Middleware. • En general implementan un framework que provee funciones tales como: • Gestión de memoria y procesos del sistema operativo. • Carga de programas, inicio y fin, pasaje de mensajes. • A veces balance de carga y gestión de transacciones. • Ejemplos: • Servidores de Aplicación y ORBs. • CORBA, EJB, COM+. • TPM: • Tuxedo, CICS, Encina. Taller de Sistemas de Información 1

Platform MiddlewareObjetos Distribuidos • Programar ensamblando componentes (building blocks). • Empaquetados como piezas de código indep. y auto contenidas. • No está asociado a un programa, lenguaje o implementación. • Accedidos por invocaciones a métodos. • Interfase bien definida (IDL: Interface Definition Language). • Portabilidad e Interoperabilidad: • Transparentes al lenguaje, compilador, ubicación, s. operativo. • Se importan dentro de paletas o toolbars. • Puede ser invocado a través de espacios de direcciones, redes, lenguajes, sist operativos y herramientas. • Utilizar y reutilizar. • Se diseña para ofrecer un número limitado de operaciones. • Nivel de abstracción alto para que sea más útil. • Tiene un estado, que es modificado seteando propiedades: permite la reutilización y customización. • Metadata: Provee información sobre sí mismo: descripción, interfase, propiedades, eventos, calidad de servicio servicio, … • Mantenerse sólos, mantener recursos. • Coexistir con otros objetos. Taller de Sistemas de Información 1

Platform MiddlewareComponentes en el Servidor • Seguridad: protegerse y proteger recursos (Autenticación de los 2 lados,.control de acceso, trazas) • Licenciamiento. • Versionado de componentes. • Manejo del ciclo de vida: Creación, destrucción, clones, externalizar contenido, movimiento. • Control de transacciones y bloqueo: integridad “todo o nada” y locks para serializar acceso a recursos. • Persistencia. • Relaciones dinámicas o permanentes con otros componentes. • Auto-testeo: correr programas de diagnóstico para determinar problemas. • Auto-instalación: Instalarse, des-instalarse. y registrarse con SO. Taller de Sistemas de Información 1

Platform MiddlewareORB • Es un bus de comunicación entre objetos: • Permite hacer/recibir requerimientos en forma transparente: • Objetos locales o remotos. • Funcionamiento: • Objeto cliente invoca un método en un objeto remoto. • ORB: • Localiza una instancia del objeto servidor. • Invoca el método. • Retorna el resultado al cliente. Taller de Sistemas de Información 1

Platform MiddlewareORB - Características • 2 tipos de invocación: • Estática: interfase conocida en tiempo de compilación. • Se compila el cliente con la interfase del objeto servidor. • Dinámica: la interfase se descubre en tiempo de ejecución. • Se consultan directorios de servicios. • El cliente no se preocupa de: • Mecanismos para activar objetos. • Almacenamiento de objetos en el servidor. • Mecanismos para comunicarse (bajo nivel) con los objetos. • Tipo RPC: pedido - respuesta. • Tipo MOM: mensajes asíncronos. • Publicar y suscribir: por eventos. Taller de Sistemas de Información 1

Platform MiddlewareORB • Publicar y suscribir: • Publishers: productores de eventos. • Suscribers: consumidores de eventos. • Event broker: canal de comunicación para los eventos: • filtros, logs, colas, reglas, prioridades, ruteo basado en sujetos, multicasting, balance de carga, ... Taller de Sistemas de Información 1

Platform MiddlewareORB • Infraestructura distribuida: • Define como los objetos conviven con los contenedores: • Insertar un objeto en un contenedor de una herramienta, por ej. un formulario. • Dialogar con un DBMS, un monitor transaccional. • Ser accedido desde un servidor web. • Propuestas: • Cliente: ActiveX, JavaBeans. • Servidor: COM+, EJB, Corba Beans. Taller de Sistemas de Información 1

Platform MiddlewareTransacción • Es una secuencia de intercambios de información y el trabajo asociado (ej. actualizar una BD) que son tratados como una unidad con el propósito de satisfacer una solicitud y asegurar la integridad de los datos. Taller de Sistemas de Información 1

Platform MiddlewarePropiedades ACID • Atomicidad: • Se ejecuta completamente o no se ejecuta. • Consistencia: • Debe dejar la base de datos en un estado consistente. • Aislamiento (isolation): • No se ve afectada por otras transacciones que ejecutan concurrentemente. • Los efectos no son visibles al exterior hasta su fin. • Durabilidad: • Los efectos de una transacción que valida son permanentes. Taller de Sistemas de Información 1

Platform MiddlewareMonitores Transaccionales • Objetivo: • Es un sistema especializado en la creación, ejecución y manejo de aplicaciones de procesamiento de transacciones. • Características: • Sistemas transaccionales tienen: • Muchas transacciones pequeñas. • Muchos usuarios concurrentes. • Coordinan las transacciones con: • Subsistemas ACID locales. • Manejadores de recursos. • DBMS, manejadores de colas, objetos persistentes, transporte de mensajes. • Ejemplo: Sistema de reservas de agencias de viaje. Taller de Sistemas de Información 1

Platform MiddlewareMonitores Transaccionales - Funciones • Control de procesos: • Iniciar y monitorear servidores. • Uso optimizado de recursos. • Control de flujo. Control de disponibilidad y fallos. • Manejo eficiente de conexiones (muchos clientes). • Manejo de transacciones: • Integridad transaccional (ACID). • División y coordinación de transacciones. • Comunicación C/S. • Aplicaciones clientes se comunican por diversos mecanismos. • Conectividad para recursos heterogéneos. • Firewalls para recursos. Taller de Sistemas de Información 1

Platform MiddlewareMonitores Transaccionales • OTM: Object Transaction Monitors • Combinan ORBs con monitores de transacciones. • Maneja contenedores que corren los componentes que brindan los servicios. • Maneja objetos logrando: transaccionalidad, robustez, persistencia, seguridad, performance. • Levanta un conjunto de objetos (pool), distribuye la carga, provee tolerancia a fallos, y coordina transacciones multi-componentes. Taller de Sistemas de Información 1

Platform MiddlewareMonitores Transaccionales • OTM: • ¿Qué hace? • Intercepta los pedidos de servicios. • Invoca al objeto apropiado y le pasa el pedido. Taller de Sistemas de Información 1

Arquitecturas y Middleware