SISTEMAS-DISTRIBUIDOS

14-6-2017

INTEGRANTES -LEZMIT GALARZA SINCHE

Introducción La forma más básica de comunicación entre procesos distribuidos en una red de ordenadores es el paso de mensajes. En este modelo, los datos se envían a base de mensajes entre los procesos emisor y receptor. En proceso envía un mensaje como petición de un determinado servicio a un servidor. El mensaje llega al receptor que interpreta la petición y envía un mensaje como respuesta. Es una comunicación de ida y vuelta, que puede provocar nuevas peticiones y nuevas respuestas. En este tipo de comunicaciones las operaciones básicas son enviar y recibir. El cliente es el proceso activo que solicita y el servidor actúa como un proceso pasivo a la espera. Cuando la comunicación está orientado a la conexión (el cliente y el servidor tienen que estar previamente conectados para enviar el mensaje), son necesarias las operaciones de conexión y desconexión.

SISTEMA DE COMUNICACIONES La topología de las conexiones en las comunicaciones se refiere a cómo se conectan los componentes que se van a comunicar. Estos se pueden agrupar de la siguiente manera:

Fig. 1 paradigmas de comunicación en función del movimiento de datos y de código

SISTEMAS DE MENSAJERÍA Los sistemas de mensajes, constituyen un paradigma basado en una capa intermedia (middleware) que gestiona el paso de mensajes entre componentes. Por ello, se suele hablar de una capa intermedia del paradigma de paso de mensajes. El nombre más conocido de este paradigma es “Message -Oriented Middleware (MOM)”. Existen dos modelos de implementación de este paradigma: punto a punto (point to point) y publicación/suscripción (publish/subscribe). En el modelo punto a punto, el sistema de mensaje emplea colas que permiten desacoplar el emisor del receptor. Cuando un componente desea enviar un mensaje a otro, deposite el mensaje en la cola del receptor (lo que implica conocerlo) y se desentiende del mensaje. En el modelo de publicación/suscripción , cada mensaje es asociado a un evento específico, de manera que los componentes que estén i nteresados en recibir los mensajes asociados al evento, se suscriben al mismo. El sistema de mensajes es el responsable de la gestión completa de los mensajes.

MODELO DE MENSAJES DE PUBLICACION/SUSCRIPCION En este modelo, cada mensaje se asocia con un determinado tema o evento. Las aplicaciones interesadas en el suceso de un específico evento se pueden suscribir a los mensajes de dicho evento. Cuando el evento que se aguarda ocurre, el proceso publica un mensaje anunciando el evento o asunto. El middleware del sistema de mensajes distribuye el mensaje a todos los suscriptores.

El modelo de mensajes publicación/suscripción ofrece una potente abstracción para multidifusión o comunicación en grupo. La operación  publicar  permite al proceso difundir a un grupo de procesos, y la operación suscribir   permite a un proceso escuchar dicha difusión de mensajes.

Utilizando el modelo de mensajes publicación/suscripción, la implementación de nuestro sistema de subastas se realizaría de la siguiente forma:  



 



Cada participante se suscribe a los mensajes del evento comienzo-subasta. El subastador anuncia el comienzo de la sesión de subasta enviando un mensaje de evento comienzo-subasta. Tras recibir el evento de comienzo-subasta, cada participante se suscribe a los mensajes del evento fin-subasta. El subastador se suscribe a los mensajes del evento nueva-puja. Un participante que desee realizar una nueva puja lanzará el evento nueva-puja, que será reenviado al subastador. Al final de la sesión, el subastador lanzará en mensaje fin-subasta para informar a todos los participantes del resultado. Si se desea, se pueden añadir otros mensajes adicionales que permitan a los participantes conocer el estado de la subasta.

Se trata de un paradigma de envió de mensajes asíncrono mediante el cual los usuarios que publican información (productor) no la envían directamente a los usuarios que solicitan esta información (consumidor), sino que lo hacen mediante un mediador (o broker).

Fig. 2 Paradigma de publicación/suscripcion

Para que este sistema funcione, se necesitan los siguientes componentes: 

Productor de información:   Usuario que tiene la información a difundir. El productor publica la información en el mediador sin tener conocimiento alguno de los usuarios interesados en esa información.



Consumidor de la información:   Usuario interesado en recibir información. El consumidor se suscribe a los temas en los que está interesado y cuando el productor publica información, el consumidor recibe una notificación indicando que hay nueva información disponible.



Mediador (o broker):  Está situado entre el productor y el consumidor, y se encarga de recibir la información de los productores y las peticiones de suscripción de los consumidores. Además, también se encarga de enviar a los consumidores las notificaciones precisas cuando un productor publica nuevos contenidos



Canal: Se trata de los conectores lógicos entre el productor y el consumidor. El canal determina algunas de las propiedades de la información (tipo de información, formato, etc.). Además también gestiona la forma como se distribuyen los contenidos, si la información expira o es persistente, o si los datos se entregan en el momento de la publicación, o por el contrario el consumidor puede solicitarlos cuando quiera, independientemente del momento en que se generaron.

Fig.3 Componentes del paradigma de Publicación/ suscripción

1. Ventajas Escalabilidad:  En entornos relativamente pequeños, este sistema ofrece una 

mejor escalabilidad que el cliente-servidor. 

Reducción del tráfico: Este sistema envía la información sólo a los que están interesados en recibirla, evitando así búsquedas innecesarias en la red.

2. Desventajas Escalabilidad: La misma ventaja que tiene el sistema en entornos pequeños, se 

vuelve una desventaja cuando se trata de grandes entornos. El campo de la escalabilidad en entornos Publicación/Suscripción es en la actualidad un reto de los investigadores.

3. Usos Existen muchos campos donde el uso de este paradigma es realmente útil y efic iente: 

Grupos de noticias y listas de distribución de correo:  En el preciso momento que se publica una noticia, el usuario interesado en ese tema o medio recibe la información al instante.



Bolsa: Estos sistemas utilizan este paradigma, el usuario i ndica los valores de los que desea estar informado y el sistema le envía la información actualizada.



Información de tráfico:  El usuario puede indicar de que carreteras quiere saber el estado y el sistema le informa cuando se pro duce una incidencia en alguna de ellas.



Distribución de software: En programas que se necesiten actualizar a menudo, es útil para avisar de nuevas versiones al usuario.



Alertas: Servicios de alertas, monitorizaciones o sistemas de vigilancia y control.

4. Tecnologías y normas en middleware orientados a mensajerías 4.1

AMQP (Protocolo Avanzado de Espera de Mensajes) Es un protocolo estándar abierto para l a comunicación mediante un middleware orientado a mensajería, donde su objetivo principal es alcanzar la interoperatividad entre diferentes servicios (particularmente se diseñó inicialmente para servicios financieros). Se considera el estándar de facto para middleware orientado a mensajería, y surgió en 2004 de la mano de empresas como OpenAMQ, Rabiit MQ Apache Qpid o Red Hat Enterprise MRG. Actualmente la especificación se encuentra en su revisión 0.9.1, aunque un esbozo de la 1.0 ya ha sido liberado. A diferencia de otras tecnologías, AMQP no solamente define un API (Interfaz de Programación de Aplicaciones), sino también es un protocolo a nivel de cable, es decir, define el formato de los datos que son enviados a través de la red como un flujo de octetos. Por tanto, cualquier aplicación puede crear e interpretar mensajes conforme a este formato de datos, independientemente del lenguaje que se utilice.

Fig.4 Tecnología AMQP

4.2

MSMQ (Cola de Mensajes de Microsoft) Es una tecnología propietaria de Microsoft que permite que aplicaciones que están ejecutándose en diferentes lugares puedan comunicarse a través de redes heterogéneas y sistemas que pueden estar temporalmente inactivos. Las aplicaciones envían mensajes a las colas para que puedan ser leídos por otras aplicaciones

Fig. 5

Tecnología MSMQ

4.3

JMS (Servicio de Mensajería de Java) Es una API de Java diseñada por Sun y otras compañías en 1998, y cuya última versión (2.1) data del 2002. Permite a las aplicaciones crear, enviar, recibir y leer mensajes, definiendo un conjunto de interfaces y su semántica asociada, posibilitando a los programas escritos en Java comunicarse con otros mediante mensajes. Minimiza el conjunto de conceptos que un programador debe aprender para producir mensajes, proveyendo suficientes características para desarrollar aplicaciones sofisticadas basadas en el uso de mensajes. También maximiza la portabilidad de aplicaciones JMS a través de proveedores JMS dentro del mismo dominio.

4.4

Servicio de Notificaciones de CORBA El Servicio de Notificaciones de CORBA es una extensión del Servicio de Eventos de CORBA, por lo que hereda todas sus características. Más concretamente define los interfaces para la comunicación de notificaciones a través de un canal de eventos donde participan productores y consumidores de información mediante dos mecanismos de propagación: push y pull. Una de las desventajas que presenta el Servicio de Eventos de CORBA es que no ofrece soporte para el filtrado de eventos o para especificar requisitos de reparto. Sin el uso de filtros, todos los consumidores conectados a un canal tendrán que recibir las mismas notificaciones que cualquier otro. Y sin la posibilidad de especificar requisitos de reparto, todas las notificaciones que se envíen a través de este canal tendrán las garantías de reparto incluidas en la implementación. Con el objetivo de paliar este contratiempo, el Servicio de Notificaciones de CORBA incluye filtros que especifican qué eventos pueden estar interesados la aplicación. Los filtros pueden adherirse a cada proxy o intermediario en la comunicación, y de esta forma se dirigirá las notificaciones a los consumidores de eventos según las restricciones especificadas en los filtros.

Fig.6 Servicio de notificaciones de CORBA

4.5

DDS (Servicio de Distribución de Datos) Es una especificación adoptada por la OMG para el intercambio de datos en sistemas distribuidos en tiempo real, basándose en el paradigma de comunicación publicador/suscriptor. La OMG es un consorcio internacional sin ánimo de lucro formado por organizaciones que desarrollan estándares de tecnologías orientadas a objetos que se encuentran ampliamente extendidas en la actualidad dentro de la industria informática. DDS es un ejemplo de este tipo de tecnologías, y otros estándares que también han sido promovidos por la OMG son CORBA, UML, o MDA, entre otros.

La comunicación en DDS conecta por un lado a los productores de datos o publicadores, y por otro a los consumidores de datos o suscriptores, desacoplándolos en tiempo, espacio y flujo. De esta manera, la aplicación no necesita conocer el origen de la información, ni cuándo ha sido producida, ni cómo llega hasta ella, sino únicamente basta con precisar qué tipo de información es la que se quiere, y unas condiciones de c omunicación que vienen dadas unas políticas de calidad de servicio. El contendedor de la información, y nexo de unión entre publicadores y suscriptores, es el Topic, que lleva asociado un determinado nombre y un tipo de dato concreto, descrito por el lenguaje de especificación IDL de forma similar a como se realiza en CORBA.

Fig. 7 Servicio de Distribución de Datos (DDS)