Escenario 3 Cuando el Proceso R invoca RECIBIR, los datos no han llegado El Proceso R no recoge ningún dato Para evitar un bloqueo indefinido del Proceso E, se eleva un evento en el Proceso R cuando los datos realmente se reciben Enviar síncrono y recibir asíncrono Cont. Este evento tiene asociado un manejador, que ejecuta la recepción real de los datos El manejador es un método (función) que se invoca en el momento de la recepción, normalmente en un hilo diferente Para que este esquema funcione, el mecanismo IPC debe implementar el servio de evento con retrollamada
Los tres escenarios se pueden usar cuando se requiere un transporte fiable de los datos (p.e. TCP) y, al mismo tiempo, se requiere que el receptor no se bloquee Proceso E Proceso R ENVIAR RECIBIR Asentimiento Evento
Ninguno de los dos procesos se bloquea Este mecanismo sólo tiene sentido cuando no se requiere un transporte fiable y, además, se usa un mecanismo de eventos con retrollamadas Este esquema no es muy utilizado Enviar asíncrono y recibir asíncrono Proceso E Proceso R ENVIAR RECIBIR Evento
Ventaja clara: facilita la vida del programador a la hora de sincronizar los procesos Inconvenientes: Puede producir bloqueos indefinidos de un proceso (p.e. RECIBIR sin ENVIAR) Puede producir interbloqueos (p.e. los dos extremos llaman a RECIBIR) Es inaceptable cuando se requieren altas prestaciones (p.e. servidores)
Dos estrategias para minimizar los inconvenientes de llamadas síncronas
Estrategia I: Temporizadores La mayoría de las APIs de IPC de red permiten el uso de temporizadores (timeouts) que se pueden utilizar para fijar el tiempo máximo de bloqueo Ejemplo: RECIBIR(procesoRemoto, bufferDatos, 3000)
Revisión crítica del mecanismo de bloqueo RECIBIR timeout Recepcion correcta Continúa el programa Código error o excepción
Estrategia II: Uso de múltiples hilos de ejecución Esta estrategia se utiliza habitualmente para el desarrollo de servidores Consiste en crear hilos específicos para algunas operaciones bloqueantes La operación bloqueante, sólo detiene su propio hilo sin afectar al resto Este tipo de estrategia suele requerir el uso de control de concurrencia Revisión crítica del mecanismo de bloqueo Cont. Proceso Nuevo hilo RECIBIR Nuevo hilo ENVIAR
Definición de Paradigma: “Patrón, ejemplo o modelo” “Estilo o conjunto de prácticas utilizadas para desarrollar un programa” (software) Es decir, identificar los paradigmas de la computación distribuida es identificar los modelos, patrones y prácticas que se utilizan habitualmente para desarrollar programas que funcionan en un sistema distribuido En computación distribuida existen centenares de paradigmas, vamos a identificar los más habituales y populares ordenándolos según su nivel de abstracción Paradigmas de computación distribuida Hardware Cliente–servidor, peer-to-peer RPC y RMI Servicios de red, ORB Espacios de objetos, aplicaciones colaborativas Modelo OSI, modelo TCP/IP Paso de mensajes Nivel de abstracción creciente Estudiado en cursos anteriores Estudiado en este curso No se ve en este curso
El paradigma de paso de mensajes es una abstracción para lograr IPC ¿Qué simplifica esta abstracción? Abstrae todas las complejidades del modelo en capas (es decir, de la red) Servicio con primitivas ENVIAR, RECIBIR, ESPERAR-CONEXIÓN, INICIAR-CONEXIÓN Se logra que la E/S por red sea similar a la E/S típica de ficheros ¿Qué restringe esta abstracción? Hace invisibles (e intocables) los detalles de las capas inferiores (¿Qué pasa si quiero crear un paquete IP falsificando la dirección de origen?) Ejemplo de implementación La API Sockets implementa este modelo
Paradigma de paso de mensajes Proceso E Proceso R Mensaje I Mensaje II
El paradigma cliente servidor es esencialmente un patrón arquitectural También es una abstracción sobre el modelo de paso de mensajes Se basa en establecer roles asimétricos a los procesos que colaboran Un proceso es el Servidor: Espera de manera pasiva peticiones de los clientes Responde a esas peticiones según un servicio predefinido Otro proceso es el Cliente (puede haber varios): Invoca peticiones al servidor Espera la respuesta de los clientes ¿Qué simplifica esta abstracción? Simplifica la sincronización en los procesos (se sabe quién espera y actúa) Simplifica la implementación de servicios compartidos por múltiples clientes ¿Qué restringe esta abstracción? Establece a priori el papel de cada proceso (¿Qué sucede si quiero que un cliente se convierta en servidor?) Ejemplos de implementación La mayoría de las aplicaciones más populares en Internet (HTTP, FTP, DNS, etc.) El mecanismo de servlets de Java está concebido para implementar servidores
Paradigma cliente-servidor
El paradigma peer-to-peer es un patrón arquitectural No ofrece una abstracción notable con respecto al modelo de paso de mensajes Elimina la asimetría del modelo cliente-servidor Todos los procesos son equivalentes desde el punto de vista de su habilidad para solicitar o proveer servicios a otros procesos Lo que simplifica y restringe este paradigma es muy dependiente de las facilidades que soporten las APIs que se utilicen para el desarrollo La comunicación suele basarse en mecanismos de petición-respuesta síncronos similar al del modelo cliente-servidor Ejemplos de implementación Todo tipo de aplicaciones de mensajería instantánea, intercambio de ficheros, vídeo-conferencia, etc. El proyecto JXTA o el proyecto Jabber ofrecen APIs y estándares para el desarrollo de sistemas basados en el paradigma peer-to-peer Paradigma peer-to-peer (igual-a-igual) P1 P2 P3
MOM (Message Oriented Middleware): Middleware Orientado a Mensajes Patrón arquitectural + abstracción similar a la del modelo cliente-servidor Middleware: un software que está “en medio” El modelo MOM propone la introducción de un middlerware que actúa de intermediario entre un sistema proveedor de servicios (servidor) y un sistema consumidor de servicios (cliente) desacoplándolos El emisor (cliente) deposita una petición en el sistema de gestión de mensajes El emisor queda “libre” para seguir con sus tareas El sistema de gestión de mensajes actúa como un conmutador dirigiendo la petición hacia el receptor (servidor) más apropiado para procesarla Los receptores almacenan las peticiones en una cola y las van procesando de manera asíncrona siguiendo una política predefinida (FIFO, LIFO, etc.) Cuando una petición se procesa, la respuesta es entregada al proceso emisor (quizás con la intermediación del sistema de mensajes) El proceso emisor puede recuperar la respuesta utilizando polling o a través de un mecanismo de retrollamadas Paradigma MOM
¿Qué simplifica esta abstracción? Proporciona una abstracción adicional para operaciones asíncronas con respecto al modelo de paso de mensajes que simplifica su desarrollo y comprensión Permite desacoplar el emisor del receptor (mejora manteniblidad) ¿Qué restringe esta abstracción? El modelo asíncrono elimina cualquier tipo de control que se pueda tener sobre las temporizaciones y la sincronización del emisor y el receptor Ejemplos de implementación Microsoft Message Queue (MSMQ), Java Message Service (JMS), etc. Paradigma MOM Cont. MOM Emisor Emisor Emisor Receptor Receptor
Es paradigma de publicación/suscripción es un patrón arquitectural También es una abstracción sobre el modelo de paso de mensajes Como en el modelo cliente-servidor, hay dos roles asimétricos El publisher (editor) Recibe o produce eventos de diferentes tipos Los subscritores (subscribers) Se suscriben a eventos de determinado tipo Cuando en el servidor se produce un evento, todos los suscriptores que hayan declarado su interés por ese tipo de evento son informados a través del envío de un mensaje, que contiene la información relevante sobre el evento El modelo de programación del suscriptor está basado en retrollamadas Este esquema se utiliza también para el desarrollo de aplicaciones monolíticas (p.e. en desarrollo de interfaces de usuario) Paradigma de publicación/suscripción
¿Qué simplifica esta abstracción? Facilita la implementación de servicios de multidifusión Facilita el desarrollo de aplicaciones que gestionan eventos asíncronos (pe. control) ¿Qué restringe esta abstracción? El propio modelo restringe el ámbito de aplicación Ejemplos de implementación Paradigma de publicación/suscripción Publisher Suscriptor Suscriptor Suscriptor Evento Evento Suscripciones Publicación de eventos Evento
RPC (Remote Procedure Call): Llamadas a procedimientos remotos Es una abstracción notable sobre todos los modelos basados en paso de mensajes No es un patrón arquitectural La idea es la de lograr que, desde el punto de vista del programador, el desarrollo de aplicaciones distribuidas sea idéntico al desarrollo de aplicaciones monolíticas Es decir, la idea es la de ofrecer abstracciones que eliminen todo lo que “tenga que ver” con comunicaciones, redes, mensajes, protocolos, etc. Las RPC se basa en el mimetismo del modelo de programación procedimental Existe un modelo análogo que mimetiza la filosofía orientada a objetos: el RMI ¿Qué simplifica este paradigma? Permite que desarrollar aplicaciones distribuidas sea “tan fácil” como desarrollar aplicaciones monolíticas (… lo matizaremos) El desarrollador no tiene por qué saber nada de protocolos, mensajes, formatos … ¿Qué restringe este paradigma? Hace invisibles (e intocables) todo lo que tiene que ver con protocolos, mensajes, formatos, etc. (¿Qué pasa si quiero saber si un mensaje se ha recibido duplicado?, ¿si quiero comprimir los datos de un mensaje?¿si quiero ralentizar el envío de mensajes?, etc. Está adaptado para comportamientos síncronos (petición-respuesta bloqueante) Ejemplos de implementación Java RMI, Sun RPC, DCE, etc. Paradigmas RPC y RMI
Paradigmas RPC y RMI Cont. … int x = 10 int y = 20 int z = sumar(x+y) … int sumar(int a, int b){ return a + b } Ejecución de llamada monolítica … int x = 10 int y = 20 int z = sumar(x+y) … int sumar(int a, int b){ return a + b } Ejecución de llamada RPC Mensaje Mensaje Proceso Proceso Proceso
Es una extensión del modelo RPC-RMI en la que se predefinen ciertos servicios Los proveedores de servicios se registran en un directorio en tiempo de ejecución Los consumidores pueden localizar los servicios consultando el directorio La estandarización es imprescindible para lograr interoperabilidad ¿Qué simplifica este paradigma? Permite mejorar la interoperabilidad Simplifica el problema de la localización del interlocutor Incentiva el uso directo de servicios estandarizados ¿Qué restringe este paradigma? Requiere mecanismos de definición de interfaces Restricciones similares a las del modelo RPC-RMI Depende del a implementación Ejemplos de implementación La tecnología Jini de Java se basa en este modelo Los Web Services (Servicios Web) se basan en este modelo Paradigma de servicios de red
ORB (Object Request Broker): Intermediario de peticiones a objetos El paradigma ORB es esencialmente un patrón arquitectural sobre el modelo RMI Se añaden también funcionalidades adicionales que abstraen ciertos servicios El ORB es un middleware que actúa como mediador en la petición a un objeto El ORB puede realizar multitud de labores entre las que se incluyen: Mediación entre objetos heterogéneos Localización de objetos Creación y activación de objetos bajo demanda Etc. Este paradigma es la base de la arquitectura CORBA ¿Qué simplifica este paradigma? Al leer el estándar CORBA uno diría que este paradigma no simplifica nada … … la realidad es que se elimina gran parte del trabajo tedioso, permitiendo que el desarrollador se centre en la lógica de negocio. Próximo a la filosofía orientada a componentes (el contenedor ofrece los servicios, el desarrollador la log. de negocio) Mejora enormemente la interoperabilidad de las aplicaciones ¿Qué restringe este paradigma? En general, las restricciones son similares a las del modelo RMI Implementaciones concretas pueden añadir restricciones adicionales Ejemplos de implementaciones Cualquier implementación de un ORB CORBA (Orbix, TidORB, OpenORB, etc.) Paradigma basado en ORB
Paradigma basado en ORB
| Página siguiente |