Arquitecturas y Middleware

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

Taller de Sistemas de Información 1
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 Arquitecturas Al 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 Arquitecturas Arquitectura Centralizada (2)

Evolución de las Arquitecturas Minicomputadores 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

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 Arquitecturas Arq. 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

Evolución de las Arquitecturas Ejemplos
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 Arquitecturas Ejemplos (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 ). 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 Arquitecturas Ejemplos (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

Middleware Definició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

Middleware Para 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

Middleware Esquema 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

Middleware Esquema 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

Middleware Ejemplos 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

Middleware Aplicación en Arquitecturas de más de 3 niveles
Servidor WEB Cliente Servidor Aplicaciones DBMS 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 Middleware Data 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

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

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 Middleware SQL 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
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: , 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 Middleware Objetos 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 Middleware Componentes 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 Middleware ORB
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 Middleware ORB - 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

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

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 Middleware Transacció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 Middleware Propiedades 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 Middleware Monitores 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 Middleware Monitores 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

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

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

TPM OTM Taller de Sistemas de Información 1

Platform Middleware Servidores de Aplicaciones
Contexto: Arquitecturas en múltiples capas: Cliente: interface usuario. Servidor Web: Acceso http, interface usuario. Servidor de Aplicaciones: Lógica del negocio. Lógica de los datos. Gestión de Transacciones. Acceso a la BD. Balance de carga en configuraciones paralelas. Servidor de Base de Datos: almacenamiento. Taller de Sistemas de Información 1

Platform Middleware Servidores de Aplicaciones
Cubren: Nivel Servidor de Aplicaciones. Casi seguro: Gestión de Transacciones. Muy probablemente: Programación del Web Server. 3 Grandes familias: Corba Component Model (CCM): basado en estándar de la OMG. J2EE: Propuesta de Java. COM/DCOM/COM+ .NET: Propuestas de MS Taller de Sistemas de Información 1

Integration Middleware Gateways
Características: Realizan la traducción entre 2 o más protocolos. Existen gateways para: DBMS, MOM. Platform Midd: Corba COM, COM  EJB. Taller de Sistemas de Información 1

Integration Middleware Super Services
Características: Proveen APIs de muy alto nivel para otros middleware: Directorios, gestión de transacciones, seguridad en diferentes sistemas operativos. Taller de Sistemas de Información 1

Integration Middleware Integration Brokers
Características: Son intermediarios que facilitan la interacción entre programas. Proveen dos funciones de interés: Transformation: Transforma mensajes o contenidos de archivos. Transforma modelos de datos de diferentes aplicaciones a un modelo común. Flow automation (or flow control): Son tratamientos inteligentes de flujos, por ejemplo: ruteo inteligente y/o basado en contenidos. Taller de Sistemas de Información 1

Integration Middleware Integration Brokers
Características: También pueden ofrecer: Business process management (p.ej, workflow) Interpretan reglas de negocio y responden a eventos de negocio y excepciones. Ayudan a automatizar tareas. Administrative monitoring. Algunos requieren un MOM en especial (ej. IBM MQSeries),otros tienen interfases a una gran variedad de productos. Taller de Sistemas de Información 1

Integration Middleware Business Process Managers
Características: Objetivo de los BPM: Implementar la automatización de procesos. Llevar registro de las instancias de los procesos, a través de su ciclo de vida. Se ofrecen de diferentes formas: Sistemas de workflow, businessware, enterprise work management systems. Taller de Sistemas de Información 1

Algunos productos (1) Application Server: BEA WebLogic (EJB y Corba). IBM WebSphere (EJB). Imprise Visibroker (Corba) ( IONA Orbix (Corba) ( Microsoft COM/DCOM/MTS/COM+. TPMs: BEA Tuxedo y WebLogic ( IBM CICS. Taller de Sistemas de Información 1

Algunos productos (2) MOM: BEA MessageQ. IBM MQSeries. Microsoft Message Queue Services (MSMQ). Integration Middleware: BEA E-Link. MS Biztalk Server IBM MQSeries Integrator. Software AG EntireX ( Taller de Sistemas de Información 1

Ultimas tecnologías que hacen a la Integración de SI y su aparición en el tiempo Taller de Sistemas de Información 1

Arquitecturas y Middleware

Presentaciones similares

Presentación del tema: "Arquitecturas y Middleware"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Arquitecturas y Middleware

Presentaciones similares

Presentación del tema: "Arquitecturas y Middleware"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback