SISTEMAS DISTRIBUIDOS
TEMA 4: Comunicación Indirecta
1. Comunicación indirecta vs. punto a punto
Comunicación punto-a-punto (directa). En una comunicación directa los participantes
necesitan estar funcionando simultáneamente. Otra consecuencia de la comunicación
directa es que el emisor necesita conocer la dirección del receptor (no tiene por qué ser la
dirección IP del otro extremo, puede ser cualquier referencia como proxy, URL o puntero).
Por estas características, la comunicación directa no es buena forma de comunicación
cuando existen varios participantes.
Comunicación indirecta. La comunicación indirecta es otra forma de comunicación en la que
entre el emisor y el receptor existe un intermediario. De esta forma, emisores/receptores
están desacoplados en tiempo y espacio.
o Desacoplamiento en espacio significa que los emisores no necesitan conocer la
identidad de los receptores y viceversa. Solo necesitan conocer la referencia del
intermediario. Así, los emisores/receptores pueden ser reemplazados, migrados o
replicados sin problema.
o Desacoplamiento en tiempo. Emisores y receptores no tiene que ejecutarse
simultáneamente, ya que el intermediario puede almacenar el mensaje
temporalmente.
Dependiendo del tipo de comunicación indirecta, se utilizan unos nombres u otros. Por
eso, ss importante tener en cuenta que cuando hablamos de emisor nos referimos a
publicador o generador, mientras que receptor es sinónimo de subscritor.
¿Cuándos es adecuado utilizar comunicación indirecta?
-Adecuado para escenarios donde usuarios conectan y desconectan muy a menudo. Por
ejemplo, entornos móviles en los cuales las notificaciones son asíncronas (aparecen sin
que el usuario haga nada) y servicios de mensajería.
-Adecuado para escenario con un gran número de usuarios que van a acceder a un
conjunto limitado de contenido. Por ejemplo, a Spotify no le interesa tener una conexión
uno a uno con cada uno de sus usuarios.
-Diseminación de eventos donde los receptores son desconocidos y cambian a menudo.
Por ejemplo, la tecnología RSS.
2. Desventajas de la comunicación indirecta
-Sobrecarga de rendimiento debido a la introducción de un nivel de indirección. El intermediario
tiene que recibir todo el tráfico de los emisores y encargarse de transmitirlo a todos los
1
receptores. Puede considerarse por tanto como un cuello de botella, que, si falla, falla todo el
sistema. En los sistemas distribuidos se intenta evitar los puntos únicos de fallo.
-Mayor dificultad de gestión debido al desacoplamiento entre emisores / receptores.
-Dificultad para alcanzar propiedades end-to-end como tiempo real y seguridad.
3. Modelos de comunicación indirecta
Hasta ahora habíamos entendido el intermediario de la comunicación directa como un programa
en ejecución que recibe una serie de mensajes por un socket y los envía por otros sockets. Sin
embargo, el concepto de intermediario es algo más abstracto y depende del modelo de
comunicación indirecta que se utilice.
Grupos de comunicación (Group communication). En este tipo comunicación indirecta, el
emisor envía un mensaje a un grupo de usuarios que es entregado sin conocer la identidad
del grupo de usuarios.
La principal característica de este modelo de comunicación es que el emisor envía los
mensajes a un grupo multicast, pero no existe un intermediario como tal.
Sistemas basados en eventos (Event-based system). Este tipo de comunicación indirecta
está basado en un sistema de publicación de eventos, a través de un intermediario (llamado
bróker de eventos), al que está subscritos determinados procesos.
Colas de mensajes (Message queues). En los sistemas basados en colas de mensajes el
intermediario es una cola. En alguna parte de la red, existe una cola en la que los emisores
mandan mensajes y los receptores reciben los mensajes de esta cola.
Sistemas de memoria compartida distribuida (Distributed shared memory). Los sistemas
de memoria compartida distribuida tratan de simular una interfaz de memoria compartida.
En este caso, se considera la memoria compartida como el intermediario de la
comunicación.
4. Sistemas distribuidos basados en eventos
Un sistema distribuido basado en eventos o sistema distribuido publicador/suscriptor es un
modelo de comunicación indirecta en el cual unos procesos llamados publicadores publican
eventos en un sistema de eventos o bróker, el cuál se encarga de enviar copias de esos eventos
a cada uno de los suscriptores que están suscriptos a esos eventos. Por tanto, los suscriptores
deciden qué información le interesa y esperan a recibir dicha información por parte del bróker.
Características del modelo publicador/suscriptor. El modelo de sistemas
distribuidos basado en eventos tiene dos características principales:
-Heterogeneidad.
-Asíncrono.
2
Roles
-Publicador. Publica contenido en un servicio de eventos.
-Suscriptor. Que un determinado proceso se subscriba a un determinado evento
significa que está interesado en ese evento y, por tanto, va a ser informado cada vez que
un publicador publique eventos.
-Servicios de eventos o bróker. Recibe eventos de los publicadores y los
distribuye a los subscritores en función de sus intereses.
Ejemplos de sistemas de notificación de eventos.
Los sistemas basados en eventos se utilizan en una gran variedad de dominios de aplicación,
aunque mayoritariamente en aquellos relacionados con la diseminación de eventos a gran
escala. Algunos ejemplos son:
-Mercado de valores financieros.
-Otras áreas basadas en datos en tiempo real como los archivos RSS o feedss
RSS
-GUIs. Los propios widgets dentro de una interfaz gráfica también pueden
comunicarse mediante un sistema de notificación de eventos.
-Aplicaciones de monitoreo como aplicaciones para consultar el tiempo o los
niveles de contaminación
Para entender mejor el concepto de sistemas distribuidos basados en eventos, vamos a mostrar
un ejemplo que se refiere a una red de venta de computadores. En realidad, podría ser una red
de ventas de cualquier elemento, ya que cuando se necesita tener un control muy fino de un
stock, se suele utilizar comunicación indirecta.
3
4.1 Modelo de programación
El modelo de programación en los sistemas de publicador-suscriptor están basados en un
pequeño conjunto de operaciones mostradas en la siguiente imagen:
-Los publicadores propagan un evento e a través de la operación publish(e) y los subscritores
expresan su interés en una serie de eventos mediante la suscripción. Para ello, utilizan la
operación subscribe(f) donde f se refiere a un filtro (un patrón definido sobre un el conjunto de
todos los posibles eventos).
-Es importante tener en cuenta que el filtrado de eventos se realiza en el bróker, lo que
supone una mejora en eficiencia para el subscritor, pues solo va a recibir eventos en los
cuales está interesado.
-Los filtros son expresiones con un formato (expresiones regulares) o lenguaje (SQL)
determinado.
-Cuando un subscriptor ya no esté interesado en un determinado tipo de eventos, puede
cancelar su subscripción haciendo uso de la operación subscribe(f).
-Por otro lado, el bróker de eventos utiliza la operación notify(e) para entregar un evento a un
subscritor.
-Además, algunos sistemas completan este conjunto de operaciones introduciendo el concepto
de anuncios. Con los anuncios, los publicadores tienen la posibilidad de declarar la naturaleza
de los eventos a través de la operación advertise(f). En otras palabras, los subscritores
manifiestan sus intereses en función de a qué eventos estén suscriptos, y los publicadores
opcionalmente, declaran el tipo de un evento mediante los anuncios.
Tipos de subscripciones.
En función de cómo se realice el filtrado de eventos, se pueden distinguir cuatro tipos de
sistemas de propagación de eventos.
-Basados en canal. En este enfoque, cada bróker de eventos dispone de una
serie de canales, de tal forma que los publicadores indican en que canal quieren publicar
4
un evento y los subscriptores se subscriben a algunos de esos canales para recibir todos
los eventos que se publiquen en ese canal.
Un ejemplo en es el servicio de eventos de CORBA.
-Basados en topic. En este enfoque, las subscripciones se hacen en función de
una serie de campos denominados topic (tema). Son similares a los basados en canales,
con la diferencia de que, en los basados en canales, los topics están definidos
implícitamente en el canal y en el caso de los basados en topic, el tema se declara
explícitamente.
-Basados en contenido. Es una generalización de los basados en topic ya que
permiten al subscriptor definir una expresión de filtrado. Más concretamente, un filtro
basado en contenido es una consulta definida sobre los valores de los atributos del
evento.
Esto implica que el subscritor tiene que conocer qué estructura tienen los eventos. Por
ejemplo, para un evento con una estructura con los siguientes campos:
struct Event{
string name;
Color color;
}
Una suscripción puede ser algo como: [Link] (color=”rojo”)
-Basados en tipo. Este enfoque está relacionado con el paradigma de
programación orientado a objetos, donde cada objeto define un tipo específico. Así
pues, las suscripciones se definen en términos del tipo de evento.
[Link] (type=A)
Formas de implementar los brokers.
El objetivo de un sistema de publicación-subscripción es garantizar que los eventos se entregan
de manera eficiente a todos los subscriptores que tienen filtros definidos que coinciden con los
del evento. Además de esto, se pueden considerar requisitos de seguridad, escalabilidad,
tolerancia a fallos, concurrencia y calidad del servicio. Esto hace que la implementación de
sistemas de publicación-suscripción sea bastante compleja, y, por tanto, es bastante importante
elegir la arquitectura general del sistema para implementar publicación-subscripción.
-Implementación centralizada. Consiste en centralizar la implementación del
bróker en único nodo. Los publicadores publican eventos y los suscritores envían
subscripciones a este nodo.
Ventajas: Sencillo de implementar.
Inconvenientes: Presenta problemas de escalabilidad. Se necesitan canales de
comunicación con mucho ancho de banda porque todos los eventos irán a la
misma máquina.
5
-Implementación distribuida. Una red de bróker que cooperan en la
distribución de eventos. Es decir, tenemos nodos diferentes en la misma o
diferentes redes que soportan cada uno parte del trabajo.
Normalmente están basados en canales o topics, y lo que se haces es que cada
canal esté en un bróker. Si un bróker falla, su canal se podría mover a otro
bróker. Basado en contenido y basado en tipo es muy difícil de implementar con
esta arquitectura.
Sistemas basados en contenido
El enrutamiento basado en contenido es la capacidad de enrutar un mensaje en función de uno
o más valores contenidos dentro del mensaje. El servicio de enrutamiento inspecciona cada
mensaje y lo enruta al extremo de destino en función del contenido del mensaje
Existen diversas formas de implementar este enrutado:
-Inundación (Flooding)
-Filtrado
-Anuncios. El publicador indica el tipo de los eventos que genera.
-Rendezvous.
5. IceStorm
Como ejemplo de sistema de propagación de eventos vamos a ver IceStorm, un servicio de Ice
que tiene las siguientes características:
-Orientado a invocaciones (no a datos). A diferencia de otros servicios similares en otros
middlewares, IceStorm propaga invocaciones a métodos en lugar de objetos o estructuras
de datos.
-Basado en topic. Los publicadores pueden publicar en varios topics y los suscriptores
pueden estar subscriptor a un topic o a varios.
6
-Federable. Los topics se pueden enlazar.
-Bróker centralizado. IceStorm es un servicio de eventos centralizados, pero dispone de una
réplica primaria llamada HA-IceStorm.
-Utiliza únicamente semántica push. En este sentido, publicar significa invocar métodos sin
valores de retorno.
-Desacopla producción y consumo.
-Permite usar cualquier protocolo de transporte en cualquier productor o consumidor.
-Tiene características de filtrado muy simples. Proporciona un mecanismo básico de filtrado
basado en pesos.
6. Sistemas de colas de mensajes
Las colas de mensajes distribuidos forman una importante categoría dentro de los sistemas de
comunicación indirecta. Mientras que los grupos de comunicación y los sistemas basados en
eventos proporcionan un servicio de comunicación uno a muchos, las colas de mensajes
proporcionan un servicio punto a punto que utiliza el concepto de una cola de mensajes para
lograr las propiedades de desacoplamiento en tiempo y espacio:
1. Un emisor pone un mensaje en una cola de mensajes determinada.
2. Un (único) receptor consume elimina el mensaje de la cola.
En los sistemas de colas de mensajes, las colas son normalmente una estructura FIFO (First In
First Out), aunque algunas implementaciones proporcionan prioridad o criterios de selección.
7
En este tipo de comunicación indirecta, los mensajes están formados por un identificador de
cola, metadatos y payload.
Ejemplos de middleware
1. WebSphere MQ, Oracle AQ
2. JMS (Java Message Service)
Características
-Validez. Todo mensaje enviado es finalmente recibido. Los sistemas de colas de mensajes
garantizan que los mensajes serán entregados, pero no pueden decir nada sobre el momento
de la entrega.
-Integridad. El mensaje recibido es idéntico al enviado y no se entregan mensajes duplicados.
-Persistencia. Las colas de mensajes almacenan los mensajes de forma indefinida (hasta que son
consumidos).
Modelo de programación
El modelo de programación ofrecido por las colas de mensajes para sistemas distribuidos
soporta tres formas de recibir mensajes:
-blocking receive (pull) El receptor se bloquea hasta que este disponible un
determinado mensaje.
- non-blocking receive (polling). Recepción sin bloqueo. Se comprueba el estado de la
cola y se obtiene un mensaje si el evento está disponible.
- notify (push). Operación de notificación que emitirá una notificación de evento cuando
un mensaje este disponible en una cola determinada.
6.1Rabbit MQ
8
RabbitMQ gestor de colas de mensajes que puede utilizarse como middleware para cubrir las
necesidades de mensajería de una aplicación. Para ello, RabbitMQ implementa un protocolo
estándar llamado AMPQ (Adavanced Message Queuing Protocol). AMQP es un protocolo de la
capa de aplicación que estipula el comportamiento tanto del servidor que provee los mensajes
como del cliente de la mensajería.
La siguiente imagen muestra las entidades usadas en el modelo AMQP para la transferencia de
un mensaje
Conceptos
-Publicadores. Envían mensajes a los exchanges.
-Exchanges. son entidades AMQP desde donde se enrutan los mensajes hacia
las colas.
-Consumidores. Declaran las colas y la vincula a un exchange para recibir los
mensajes.
-Colas. son las entidades sobre las que el broker almacena los mensajes que
recibe de los productores, desde donde los consumidores obtienen dichos
mensajes.
-Routing. Se pueden utilizar reglas de enrutamiento para decidir a qué colas se
entregará un mensaje. Cada cola tiene asociada un routing key,y cuando se
envía un mensaje al bróker, el bróker enviará el mensaje a la cola dependiente de su
routing key.
Hola Mundo
9
Vamos a mostrar dos pequeños programas escritor en Python: un productor que envía un único
mensaje y un consumidor que recibe este mensaje y lo imprime. En el siguiente diagrama, “P”
es nuestro productor, y C” es el consumidor. La caja del medio es una cola -un buffer de
mensajes que mantiene RabbitMQ-.
10
Enlace flexible.
6.2 Celery
Celery es un conjunto de herramientas que nos permite trabajar fácilmente con múltiples
servicios viéndolos como tareas. No puede decirse que sea un sistema de comunicaciones,
ya que el sistema de comunicaciones es RabbitMQ
11
