Paradigmas para la construcción de Sistemas Distribuidos Objetos Distribuidos Contenido • Capa middleware: * Definición y funciones * Criterios de clasificación • Modelo cliente – servidor: * Cliente – servidor * Consideraciones de diseño * Arquitecturas n-tercios • Casos de estudio: * Remote Procedure Call (RPC) * Remote Method InvocaHon (RMI) Middleware § Es una capa de soLware entre las aplicaciones y el sistema operaHvo de red § Ofrece un nivel elevado de abstracción (transparencia) § Provee acceso a la información y a los recursos de cómputo Ejemplos de uso: § ReuHlización de sistemas legados § Sistemas de mediación § Arquitecturas basadas en componentes § Adaptación de clientes a través del uso de proxies Middleware (2) Funciones principales: § Esconder la distribución y la heterogeneidad § Proveer interfaces de alto nivel y estandarizadas al desarrollador de aplicaciones distribuidas para que las aplicaciones puedan inter-operar, ser reuHlizadas, portadas y compuestas § Proveer una serie de servicios comunes para realizar funciones de propósito general Criterios de clasificación: § Las propiedades de la infraestructura de comunicación § La arquitectura global y las interfaces provistas Propiedades de la comunicación § Topología fija: Las enHdades del sistema residen en localizaciones fijas y la configuración de la red no cambia § Topología variable: Algunas o todas las enHdades del sistema pueden cambiar de localización, conectarse y desconectarse a voluntad § CaracterísHcas predecibles: El sistema establece limites para alcanzar factores de eficiencia § CaracterísHcas no predecibles: No se conocen los límites del sistema, los factores de eficiencia dependen de la carga de los periféricos comparHdos Propiedades combinadas • Sistema fijo y no predecible: Caso más frecuente, e.g., Hempo de transmisión en Internet • Sistema fijo y predecible: Ambientes desarrollados especialmente para aplicaciones muy demandantes, e.g., sistemas de Hempo real • Sistema variable y no predecible: Sistemas que incluyen periféricos móviles, e.g., PDAs, celulares, ambientes ubicuos Dada la tecnología actual de comunicación, la categoría variable y predecible está vacía Arquitecturas e interfaces • Administrador de enAdades: El middleware administra diferentes enHdades que difieren en sus definiciones, propiedades y modos de comunicación, e.g., objetos, agentes, componentes • Proveedor de estructura: o Las enHdades administradas por el middleware Henen roles predefinidos (cliente, servidor, suscriptor, proveedor) o Las enHdades pueden estar al mismo nivel y asumir diferentes roles como en las arquitecturas P2P • Proveedor de interfaces: Las primiHvas de comunicación provistas por el middleware pueden seguir un paradigma síncrono (e.g., RPC, RMI) o asíncrono (e.g., colas de mensajes, sistemas publish – suscribe) Modelo Cliente-Servidor Modelo Cliente-Servidor • Modelo de ejecución síncrona con dos enHdades de ejecución: El servidor que ofrece un servicio Un cliente que uHliza tal servicio • Ambas enHdades están en general, pero no necesariamente, en dos máquinas disHntas • La definición de la interfaz de servicio ofrecido por el servidor, da independencia en la implementación. Abstrae la relación entre un cliente (consumidor) y un proveedor de servicios • Interacción basada en intercambio de dos Hpos de mensajes: PeAción (request): especificación del servicio requerido, nombre de un procedimiento y sus parámetros, código a ejecutar Respuesta (reply): resultado o indicador de algún eventual error • Ejecución – una vista abstracta Cliente/Servidor – aspectos de interés • Estructuración: § Funciones bien definidas § Separación de la interfaz entre servicio/realización § Cliente y servidor pueden ser modificados (reemplazados) independientemente • Protección: Cliente y servidor se ejecutan dentro de dominios de protección diferentes • Administración de recursos: El servidor puede estar comparHdo por varios clientes Consideraciones de diseño • Administración del estado: del servidor (con datos persistente o no) del cliente (estados memorizado por el servidor o no) • Modelo del servicio de comunicaciones: Modo conectado Modo desconectado (datagrams) • Modelos de ejecución del servidor: Uno o mas procesos Pool de procesos o creación a la demanda Servidor sin datos persistentes La ejecución del servicio no uHliza más que los parámetros de entrada: • Situación ideal • No hay una modificación del estado del servidor Solución muy favorable: • Para la tolerancia a fallas • Para el control de la concurrencia Ejemplo: Servicio del cálculo de una función matemáHca Servidor con datos persistentes • Las ejecuciones sucesivas manipulan datos persistentes: § Modificación del contexto de ejecución sobre el siHo § Problemas de control de concurrencia § Problemas para garanHzar la tolerancia a fallas • Ejemplos: § Servidor de archivos distribuidos § Servidor de bases de datos Servidor SIN estados memorizados (stateless) à El servidor NO memoriza la información relaHva al estado de las peHciones en curso • Las peAciones sucesivas deben ser independientes: o Aún si los datos globales son modificados, la peHción en curso no manHene relación con las precedentes o No es necesario respetar el orden de las peHciones • Ejemplo: El servicio de reloj en una red (servicio NTP – Network Time Protocol) Servidor CON estados memorizados (stateful ) à El servidor memoriza la información relaHva al estado de las peHciones en curso • Las peHciones sucesivas se ejecutan en función del estado dejado por las peHciones anteriores: à la preservación del ORDEN es indispensable Ejemplos: • Lectura de un registro de un archivo en acceso secuencial (que depende de un apuntador a la posición actual) • El llamado a un método en un objeto (el resultado depende del estado del objeto) Modelos de comunicación • Orientado a conexión: La entrega está garanHzada, respetando el orden del envío y libre de error (con reenvío en caso necesario) • Sin conexión (datagrams): La entrega sigue una políHca de entrega “mejor esfuerzo”: no hay garanaa en la entrega, los mensajes pueden llegar duplicados y en desorden � La principal diferencia es la fiabilidad en la entrega Modelos de ejecución El servidor puede organizarse de la siguiente manera: § Un solo proceso servidor (ejecución iteraHva) § Varios procesos o threads servidor (ejecución concurrente) o Creación de procesos o threads a la demanda o Pool de procesos o threads Procesos o threads? § Un programa puede ejecutarse con varios procesos, que implican varios espacios de ejecución con sus respecHvos controles (hilos de ejecución o threads) § Un thread es un proceso ligero, de manera que un proceso normal puede albergar varios threads que comparte un mismo espacio de ejecución cada uno con su respecHvo control Un solo servidor Un solo servidor (2) Problemas con múlHples clientes y un solo proceso servidor: § § § El servidor puede formar un “cuello de botella” El servidor introduce un punto de vulnerabilidad en caso de fallas El sistema puede estar limitado en escalabilidad Varios procesos por servidor Creación de procesos a la demanda Pool de procesos Arquitectura de sistemas Define la estructura y la organización del sistema: § Componentes del sistema § Funciones de cada componente § Interrelaciones e interacciones entre los componentes … recordar diferentes modelos de arquitectura Arquitectura cliente-servidor • Esquema básico para una aplicación distribuida: La aplicación cliente accede datos permanentes (SGBD) y despliega los resultados • Implementación inicial: § Los clientes ligeros, e.g., terminales alfanuméricas § El proceso y el acceso a los datos está entremezclado Evolución de las arquitecturas Arquitectura 2-tercios: Usada en una situación simple donde todo el proceso de recuperación y presentación de resultados puede hacerse en el cliente Limitaciones: • Poder de proceso en el cliente • Data sharing • Evolución y escalabilidad Evolución de las arquitecturas (2) Arquitectura 3-tercios Beneficios potenciales • Separación de funciones • Interfaces bien definidas, estandarización • Evolución y escalabilidad • ReuHlización de código legado Patrones de arquitecturas • Tipos de código: Presentación (P) Lógica aplicaHva (A) Acceso a datos persistentes (D) • Variantes: 1) Código monolíHco [PAD] 2) A dos niveles: • [P] + [AD] • [PA] + [D] 3) A tres niveles: [P] + [A] + [D] Opciones de implementación Opción de bajo nivel: UHlización de primiHvas del sistema de comunicación à Programación por sockets Abstracciones de alto nivel: UHlización de un middleware de comunicaciones à Llamado a procedimientos remotos (RPC) à Llamado a métodos distantes (objetos comunicantes) Código MonolíHco Código MonolíHco Arquitectura n-tercios (1) § La arquitectura n-tercios (o mulH-tercios) es una generalización del modelo cliente – servidor § Una aplicación cliente – servidor usa una arquitectura 2tercios § La arquitectura promueve una jerarquía donde los componentes en las capas superiores son clientes de la capa inmediatamente inferior § Las aplicaciones en la Web son un ejemplo del uso de esta arquitectura Arquitectura n-tercios (2) Casos de estudio • Remote Procedure Call (RPC) • Remote Method InvocaHon (RMI)