Comunicación entre Procesos (página 2)

Partes: 1, 2

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