7 | Patrón Publica-Suscribe

En capítulos anteriores hemos hablado cómo algunos estilos arquitectónicos utilizan

un modelo de comunicación más clásico en el que un componente invoca un servicio en
otro componente, espera un resultado y después realiza una acción considerando dicho re-
sultado. Muchas veces, sin embargo, la comunicación entre los componentes de un sistema
requiere ser menos clásica. Pensemos en el sistema de una línea aérea. Si por aguna razón
un vuelo se cancela, este evento debe comunicarse a varios componentes con el propósito
de que cada uno de estos realicen una acción específica. Por ejemplo, un componente po-
dría tener la responsabilidad encontrar otro vuelo para cada pasajero; otro componente la
de emitir cupones de comida para algunos de ellos; otro la de emitir cupones de hotel si
esto fuera necesario; etc. En lugar de realizar estas acciones secuencialmente, comunicar
este evento al mismo tiempo a todos estos componentes permite que estas acciones sean
realizadas por los componentes a su propio ritmo, contribuyendo así a que el sistema sea
más rápido y escalable.

Una arquitectura basada en eventos es un estilo arquitectónico caracterizado por la

existencia de una serie de componentes, relativamente independientes, que se comunican a
través de eventos para lograr un objetivo. La forma más básica de este tipo de arquitecturas
sigue un Patrón Publica-Suscribe, el cual se describe en este capítulo.

7.1. Descripción
El Patrón Publica-Suscribe (Publish – Subscribe Pattern, como se le conoce en el idioma
inglés) es un patrón arquitectónico, frecuentemente utilizado en el desarrollo de muchos
sistemas actualmente. El patrón se basa en el envío asíncrono de mensajes, que representan
eventos, permitiendo que un conjunto de componentes publicadores envíen éstos a un
conjunto de componentes suscriptores. Un evento es un tipo especial de mensaje –que
emite un componente, para informar –a otros componentes iteresados, que algo sucedió en
el pasado.
Los publicadores no tienen conocimiento explícito de los suscriptores que existen. Igual-
mente, los suscriptores no tienen conocimiento explícito de los publicadores que existen.
Los eventos que se transmiten pueden clasificarse por tipos y de esta forma los suscriptores
pueden sucribirse para recibir los eventos de su interés.
Implementaciones básicas de este patrón incluyen uno o más componentes de tipo Pu-
blicador (Publisher, como se le conoce en el idioma inglés), dos o más componentes de
tipo Suscriptor (Subscriber, como se les conoce en el idioma inglés) y un conector llamado
Distribuidor de Mensajes (Broker, como se le conoce en el idioma inglés). La Tabla 7.2
describe con más detalle dichos elementos así como otros aspectos de interés sobre el Pa-
trón Publica-Suscribe.

25
26 7. PATRÓN PUBLICA-SUSCRIBE

Elementos Publicador: componente que envía mensajes, que representan

eventos de interés.
Suscriptor: componente que recibe mensajes, que representan
eventos de interés.
Distribuidor de Mensajes: conector que permite el envío de eventos
de interés entre Publicadores y Suscriptores.
Modelo de Publica: relaciona al Publicador con el Distribuidor de Mensajes;
comunica- permite y regula el envío de eventos desde el Publicador hacia el
ción Distribuidor de Mensajes.
Consume: relaciona a los Suscriptores con el Distribuidor de Men-
sajes; permite y regula el envío de eventos desde el Distributor de
Mensajes hacia los Suscriptores.
Callback: relaciona a un Suscriptor con el Distribuidor de Men-
sajes y al Distribuidor de Mensajes con un Publicador; permite y
regula el envío de un mensaje de retorno que notifica al Publicador
que el evento ha sido recibido por un Suscriptor. Esta relación es
opcional.
Modelo de Los Suscriptores se suscriben para recibir eventos de interés a
computación través del Distributor de Mensajes. Cuando un evento es enviado
por un Publicador, el Distributor de Mensajes lo recibe y lo re-
envía, de forma asíncrona, a todos los Suscriptores interesados en
ese evento.
Restricciones Todos los componentes (el Publicador y los Suscriptores) deben
estar conectados al Distribuidor de Mensajes.
No se permite la comunicación directa entre Publicadores, ni entre
Suscriptores.
Principios de Bajo acoplamiento: hay bajo acoplamiento entre Publicadores y
diseño y atri- Suscriptores. Un Publicador desconoce a qué Suscriptor será entre-
butos de cali- gado el evento que emite. Un Suscriptor desconoce qué Publicador
dad ha enviado el evento que ha recibido.
Cohesión: cada elemento del patrón realiza procesamiento especí-
fico y relacionado a una única función.
Facilidad de mantenimiento: Es fácil realizar cambios en un Pu-
blicador o Suscriptor ya que están desacoplados. Igualmente, los
cambios en la lógica de un Publicador o Suscriptor son fáciles
porque están localizados ya que su implementación es cohesiva.
Desempeño, escalabilidad: en una implementación robusta con tec-
nología adecuada, se pueden agregar Publicadores y Suscripto-
res registrándolos en el Distributor de Mensajes sin deteriorar el
desempeño.

Cuadro 7.1: Descripción de elementos y otros aspectos de interés del Patrón Publica-
Suscribe.

En la figura 8.1 se muestra una vista estática del patrón Publica - Subscribe, en términos
de la información descrita anteriormente. Por otro lado, en la figura 8.2 se muestra una
vista dinámica del patrón, en donde se puede observar cómo interactúan sus elementos.
7.1. DESCRIPCIÓN 27

Figura 7.1: Vista estática del Patrón Publica-Suscribe.

Figura 7.2: Vista dinámica del Patrón Publica-Suscribe.

28 7. PATRÓN PUBLICA-SUSCRIBE

7.2. Ejemplo Práctico

En esta sección presentamos una instancia de uso del Patrón Publica-Suscribe utilizan-
do un ejemplo práctico. Para ello, inicialmente se expone una descripción general de este
ejemplo. Posteriormente, se describen los requerimientos de arquitectura. Considerando
estos requerimientos, después se presenta un diseño arquitectónico del sistema utilizando
el Patrón Publica-Suscribe. Finalmente, se describe una posible implementación del diseño
utilizando la tecnología RabbitMQ [Piv17] y el lenguaje de programación Python [Pyt22].

7.2.1. Descripción General

Para el ejemplo práctico vamos a suponer la existencia de un lugar llamado Seten. Este
lugar es un hogar de retiro para adultos mayores que desean vivir esta etapa de manera
plena, independiente, disfrutando de un ambiente cordial y una diversidad de servicios que
mejoran su calidad de vida. Parte del personal que trabaja en Seten, entre otras tareas, se
dedica a monitorear el estado de salud de estas personas.
Supongamos también la existencia de una comunidad llamada Girls that Code in Pyt-
hon y que esta, a manera de donación, le desarrolló a Seten un sistema de software para
mejorar las actividades de monitoreo del estado de salud de los adultos mayores. Para ello,
esta comunidad utilizó un conjunto de dispositivos “wearables”, de la marca Xiaomi My
Band que fueron donados por el gobierno estatal, y que portan cada uno de los adultos
mayores y permiten conocer algunos de sus signos vitales. Así, mediante el envío de infor-
mación sobre ritmo cardiaco, presión arterial y temperatura estos dispositivos permitirán
a los usuarios del sistema monitorear en tiempo real a cada uno de los adultos mayores y
de esta forma ser más eficientes en la prevención y atención de incidencias.

7.2.2. Requerimientos de Arquitectura

El objetivo de negocio que soporta la razón de ser de este sistema es:

Disminuir el tiempo requerido para la prevención, atención y seguimiento de incidencias

de salud de los adultos mayores.

Considerando este objetivo de negocio, se especificaron los siguientes requerimientos de

arquitectura:

(a) Requerimientos de usuario:

- Como Enfemera/o necesito recibir alertas en mi teléfono móvil cuando un adulto
mayor presente signos vitales anormales, de forma que pueda brindarle atención
inmediata.

- Como Asistente de Área necesito visualizar en mi monitor una alerta cuando un adul-
to mayor presente signos vitales anormales, de forma que pueda ayudar a asegurar
que se le brinde atención inmediata.

- Como Asistente de Área necesito consultar la infomación actual sobre los signos
vitales de un adulto mayor, de forma que pueda prevenir o dar seguimiento a una
incidencia de salud.

- Como Administrador/a necesito gestionar los dispositivos “wearables”, para mante-

ner un catálogo actualizado.
7.2. EJEMPLO PRÁCTICO 29

- Como Administrador/a necesito gestionar los usuarios del sistema, para mantener
un catálogo actualizado.

(b) Atributos de calidad:

- Desempeño: cuando un adulto mayor presente un signo vital anormal, la alerta co-
rrespondiente debe llegar a los usuarios interesados en no más de 1.5 segundos.

- Confibialidad: el sistema deberá tener una precisión en las medidas de los signos
vitales de al menos 99.9 %.

- Disponibilidad: el sistema deberá estar disponible al menos 99.9 %.

- Escalabilidad: el sistema deberá soportar la operación de hasta 100 dispositivos “wea-

rables”.

- Auditabilidad: el sistema deberá guardar en un log los eventos de signos vitales

anormales que se detectan.

(c) Restricciones técnicas:

- Se deberá utilizar Python como lenguaje de programación ya que este es el que mejor
conoce la comunidad Girls that Code in Python.

- Se deberá utilizar el API de Xiaomi My Band para la comunicación con los disposi-
tivos “wearables”.

7.2.3. Diseño del Sistema

La vista estática en la figura 7.3 presenta un diagrama de contexto que permite en-
tender los límites del Sistema de Monitoreo de Adultos Mayores, SMAM, sus usuarios y
los componentes externos con los que este interactúa. Como puede observarse, y conside-
rando los requerimientos de usuario, los usuarios del SMAM son Enfermera/o, Asistente
y Adminstrador/a. La figura también muestra que el sistema recibirá información de los
signos vitales desde un conjunto de dispositivos de hardware llamados Xiaomi My Band.
Cada “wearable” enviará al SMAM periódicamente información sobre los signos vitales
del adulto mayor.
La vista estática en la figura 7.4 muestra la arquitectura principal del SMAM. Co-
mo puede observarse el SMAM consta de varios componentes, entre los cuales se han
encerrado en un recuadro rojo los que forman el Patrón Publica-Suscribe. Existe un com-
ponente Distribuidor de Mensajes cuya responsabilidad es conectar a los Publicadores con
los Suscriptores y así establecer una comunicación entre ambos grupos de componentes
para lograr el envío de eventos. Además, existen 3 componentes que procesan los eventos
de los signos vitales recibidos desde el Distribuidor de Mensajes (ver Notificador de alertas
de signos vitales, Log, Monitor). El diagrama indica para algunos de los componentes la
tecnología utilizada para su implementación. Note que para la implementación del compo-
nente Distribuidor de Mensajes se utilizará RabbitMQ [Piv17], tecnología que se explica
más adelante en este capítulo.
La figura 7.5 muestra una vista dinámca del SMAM. En esta vista es posible observar
cómo los componentes del sistema, que se muestran en la figura 7.4, realizan algunos de los
requerimientos de arquitectura de este sistema. Primero tenemos al publicador represen-
tado por un el dispositivo de hardware Xiaomi My Band. Por simplicidad solo mostramos
30 7. PATRÓN PUBLICA-SUSCRIBE

Figura 7.3: Diagrama de contexto del Sistema de Monitoreo de Adultos Mayores (SMAM).

un publicador aunque en el SMAM real son varios. Después tenemos el conector que es-
tá representado por el distribuidor de mensajes. El sistema cuenta con tres suscriptores
en donde cada uno recibe los eventos de valores extremos de signos vitales para dar un
tratamiento específico considerando los requerimientos arquitecturales.

7.3. Implementación con RabbitMQ

7.3.1. RabbitMQ
RabbitMQ es una tecnología de tipo “middleware” (como se le conoce en el idioma
inglés) que implementa un Distribuidor de Mensajes y que puede ser (re)utilizada para el
diseño e implementación de sistemas que usan la estrutura del Patrón Publica - Suscribe.
RabbitMQ es compatible con muchos sistemas operativos y lenguajes de programación.
Esta tecnología utiliza, entre otros, un Protocolo Avanzado de Encolamiento de Mensa-
jes (AMQP, por sus siglas en inglés), lo que permite un soporte más robusto durante el
intercambio de mensajes entre los Publicadores y Suscriptores. RabittMQ permite robus-
7.3. IMPLEMENTACIÓN CON RABBITMQ 31

Figura 7.4: Vista de módulos del Sistema de Monitoreo de Adultos Mayores (SMAM).

tecer el envío de mensajes implementando mecanismos para garantizar el desempeño, la

escalabilidad, disponibilidad, confiabilidad así como la facilidad de mantenimiento en los
sistemas que con este se desarrollan.

En la siguiente tabla se describen los elementos que deben considerarse al utilizar

RabbitMQ en la implementación de sistemas con arquitectura Publica - Suscribe. Una
referencia mas detallada puede encontrarse en [Piv17].
32 7. PATRÓN PUBLICA-SUSCRIBE

Figura 7.5: Vista dinámica del Sistema de Monitoreo de Adultos Mayores (SMAM).
7.3. IMPLEMENTACIÓN CON RABBITMQ 33

Publicador: componente que envía mensajes.

Exchange: mecanismo que recibe y enruta los mensajes enviados
por los Publicadores hacia una cola específica.
Cola: mecanismo que almacena los mensajes recibidos
mendiante el Exchange para ser posteriromente en-
tregados a los Suscriptores.
Suscriptor: componente que recibe mensajes.

Cuadro 7.2: Elementos que utiliza RabbitMQ para su implementación.

Para la implementación del SMAM estos elementos fueron utilizados como se muestra
en la figura 7.6. Como puede observarse se implementaron 3 colas que permiten establecer
conexión con los Suscriptores (ver Notificador de alertas de signos vitales, Log, Monitor).
El elemento Exchange se conecta con los “weareables” para recibir la información que
estos tienen sobre los signos vitales. El Exchange enruta los mensajes que contienen esta
información a la cola correspondiente, para su entrega a los Suscriptores.
Por otro lado, en la figura 7.7 es posible observar la vista dinámica presentada ante-
riormente pero ahora con los componentes que conforman al Distribuidor de Mensajes.
34 7. PATRÓN PUBLICA-SUSCRIBE

Figura 7.6: Elementos de RabbitMQ en el Sistema de Monitoreo de Adultos Mayores

(SMAM).

7.3.2. Implementación
El código del SMAM se puede descargar del siguiente repositorio, desde el directorio
correspondiente al capítulo 4:

https://gitlab.com/tareas-arquitectura-de-software-curso/publica-suscribe

En la figura 7.8 se muestra la estructura del directorio del capítulo 4. Se pueden obser-
var tres directorios: “docs”, ”publicadores” y “suscriptores”. El directorio “docs” contiene
documentos complementarios para el proyecto; El directorio “publicadores” contiene el
código fuente de los publicadores del sistema SMAM. Por otro lado, el directorio ”suscrip-
tores” contiene el código fuente de los suscriptores del sistema SMAM. La versión actual
del sistema fue realizada usando el lenguaje de programación Python en su versión 3.8
7.3. IMPLEMENTACIÓN CON RABBITMQ 35

Figura 7.7: Vista dinámica del Sistema de Monitoreo de Adultos Mayores (SMAM) con
los elementos de RabbitMQ.

y RabbitMQ versión 3. Es importante aclarar que en la implementación presentada en

este libro los “wereables” son simulados con componentes de software. Esto es, no son los
dispositivos reales.
 36 7. PATRÓN PUBLICA-SUSCRIBE

Figura 7.8: Estructura de directorios del repositorio SMAM

En la tabla 7.3 se describe el contenido de los directorios.

docs directorio de archivos complementarios del sistema

SMAM.
publicadores directorio que contiene la implementación de los pu-
blicadores del sistema SMAM.
suscriptores directorio que contiene la implementación de los sus-
criptores del sistema SMAM.
.gitignore omisiones de git
README.md archivo que contiene la descripción del sistema
requirements.txt dependencias del sistema SMAM

Cuadro 7.3: Descripción del contenido de la estructura de directorios del repositorio.

7.3.3. Descripción del Código

En esta sección se describirá un extracto del código fuente que se utilizó para imple-
mentar el ejemplo práctico.

Publicador
En el código 7.1 se muestra un extracto del código fuente de un “wereable”, que como
ya se explicó anteriormente, corresponde a un Publicador en el SMAM. Específicamente,
se muestra el código que corresponde a la simulación de la lectura de los signos vitales de
un adulto mayor.

Código 7.1: Simulación de lectura de signos vitales en xiaomi_my_band.py

1 def run ( self ) :
2 self . temperature = random . uniform (33 , 39)
3 self . step_count += random . randint (20 , 200)
4 self . battery_level -= random . randint (1 , 5)
5 self . sleep_hours = 7 - random . randint (1 , 5)
6 self . calories_burned = random . randint (1500 , 2500)
7 self . heart_rate = random . randint (60 , 150)
8 self . blood_pressure = random . randint (100 , 200)
9 self . date = datetime . datetime . now () . strftime ( " %d/ %m/ %Y %H: %M: %S " )
 7.3. IMPLEMENTACIÓN CON RABBITMQ 37

Cómo se puede observar, el “wearable“ Xiaomi my band a través de la librería “random“

simula y establece los valores de los signos vitales de un adulto mayor en un determinado
momento, que posteriormente son procesados en el sistema SMAM; Los signos vitales
simulados incluyen, entre otros datos, la “temperatura“, el “ritmo cardiaco“ y la “presión
arterial“ de un adulto mayor.
Por otro lado, en el código 7.2 se muestra el cómo son enviados los datos de los signos
vitales recolectados por el “wearable“ Xiaomi my band hacia el Distribuidor de Mensajes
a través de la publicación de un mensaje.

Código 7.2: Envío de signos vitales al Distribuidor de Mensajes

1 def publish ( queue , data ) :
2 connection = pika . BlockingConnection ( pika . ConnectionParameters ( host = ’
localhost ’) )
3 channel = connection . channel ()
4 channel . queue_declare ( queue = queue , durable = True )
5 channel . basic_publish ( exchange = ’ ’ , routing_key = queue , body = json . dumps (
data ) , properties = pika . BasicProperties ( delivery_mode =2) )
6 connection . close ()

En el código anterior, en la línea 2 "connection = pika.BlockingConnection(pika.ConnectionParameters

(host=’localhost’))", se crea la conexión hacia el Distribuidor de Mensajes RabbitMQ; en-
seguida, en la línea 3 "channel = connection.channel()", se crea el canal de comunicación que
se utilizará para el envío de mensajes desde el Publicador hacia el Distribuidor de Mensa-
jes; después, en la línea 4 "channel.queue_declare(queue=queue, durable=True)", se configura el
canal creado en línea anterior indicado el nombre y tipo de la Cola que se utilizará durante
el envío de mensajes; luego, en la línea 5 "channel.basic_publish(exchange=’’, routing_key=
queue, body=json.dumps(data), properties=pika.BasicProperties(delivery_mode=2))", se realiza
el proceso del envío del mensaje hacia el Distribuidor de Mensajes, adicional al mensaje
se indica el exchange, routing_key y properties que son parámetros utilizados por el Dis-
tribuidor de Mensajes al momento de entregar el mensaje a los suscriptores; por último,
en la línea 6 "connection.close()"se termina y cierra la conexión utilizada por el Publicador
para comunicarse con el Distribuidor de Mensajes.

Suscriptor
En el código 7.3 se muestra un extracto del código fuente del “monitor” del sistema,
que es el responsable de mostrar las alertas de los signos vitales anormales detectados entre
los adultos mayores. Este ”monitor” corresponde a un suscriptor que se comunica con el
Distribuidor de Mensajes para recibir los signos vitales.

Código 7.3: Código fuente del suscriptor Monitor

1 def consume ( self , queue , callback ) :
2 try :
3 connection = pika . BlockingConnection ( pika . ConnectionParameters (
host = ’ localhost ’) )
4 channel = connection . channel ()
5 channel . queue_declare ( queue = queue , durable = True )
6 channel . basic_qos ( prefetch_count =1)
7 channel . basic_consume ( on_message_callback = callback , queue = queue
)
8 channel . start_consuming ()
9 except ( KeyboardInterrupt , SystemExit ) :
10 channel . close ()
11 sys . exit ( " C o n e x i n finalizada ... " )
 38 7. PATRÓN PUBLICA-SUSCRIBE

12
13 def callback ( self , ch , method , properties , body ) :
14 data = json . loads ( body . decode ( " utf -8 " ) )
15 print ( " ADVERTENCIA !!! " )
16 print ( f " [{ data [ ’ wearable ’][ ’ date ’]}]: asistir al paciente { data [ ’
name ’]} { data [ ’ last_name ’]}... con wearable { data [ ’ wearable ’][ ’ id ’]} " )
17 print ( f " ssn : { data [ ’ ssn ’]} , edad : { data [ ’ age ’]} , temperatura : {
round ( data [ ’ wearable ’][ ’ temperature ’] , 1) } , ritmo cardiaco : { data [ ’
wearable ’][ ’ heart_rate ’]} , p r e s i n arterial : { data [ ’ wearable ’][ ’
blood_pressure ’]} , dispositivo : { data [ ’ wearable ’][ ’ id ’]} " )
18 print ()
19 time . sleep (1)
20 ch . basic_ack ( delivery_tag = method . delivery_tag )

Como se puede observar, en el código anterior se definen dos métodos, consume y callback
; el primero es el encargado de realizar la conexión hacia el Distribuidor de Mensajes;
mientras que el segundo es responsable de procesar los mensajes recibidos desde Distri-
buidor de Mensajes. A continuación se describirá con más detalle la implementación su
implementación.
La conexión entre el suscriptor y el Distribuidor de Mensajes se realiza con el código
7.4, mostrado a continuación.

Código 7.4: Suscripción del Monitor al Distribuidor de Mensajes

1 def consume ( self , queue , callback ) :
2 try :
3 connection = pika . BlockingConnection ( pika . ConnectionParameters (
host = ’ localhost ’) )
4 channel = connection . channel ()
5 channel . queue_declare ( queue = queue , durable = True )
6 channel . basic_qos ( prefetch_count =1)
7 channel . basic_consume ( on_message_callback = callback , queue = queue
)
8 channel . start_consuming ()
9 except ( KeyboardInterrupt , SystemExit ) :
10 channel . close ()
11 sys . exit ( " C o n e x i n finalizada ... " )

Cómo se puede observar en el código anterior, en la línea 3 "connection = pika.BlockingConnection

(pika.ConnectionParameters(host=’localhost’))", se crea la conexión hacia el Distribuidor de
Mensajes; luego, en la línea 4 "channel = connection.channel()", se crea el canal que se uti-
lizará para la recepción de mensajes desde el Distribuidor de Mensajes; enseguida, en las
líneas 5, 6 y 7 se configura el canal creado en la línea 4 indicando el nombre, el tipo de la
Cola que se utilizará durante la recepción de los mensajes y el método que procesará los
mensajes recibidos; después, en la línea 8 "channel.start_consuming()", se inicia el proceso
de suscripción hacia el Distribuidor de Mensajes. A partir de este momento el suscriptor
comenzará a recibir mensajes desde el Distribuidor de Mensajes.
Por último, en la línea 10 "channel.close()", se cierra el canal de comunicación utilizado
por el suscriptor para comunicarse con el Distribuidor de Mensajes.
El procesamiento de los mensajes recibidos desde el Distribuidor de Mensajes en el
suscriptor se realiza con el código 7.5, mostrado a continuación.

Código 7.5: Procesamiento de mensajes en el monitor

1 def callback ( self , ch , method , properties , body ) :
2 data = json . loads ( body . decode ( " utf -8 " ) )
3 print ( " ADVERTENCIA !!! " )
 7.3. IMPLEMENTACIÓN CON RABBITMQ 39

4 print ( f " [{ data [ ’ wearable ’][ ’ date ’]}]: asistir al paciente { data [ ’
name ’]} { data [ ’ last_name ’]}... con wearable { data [ ’ wearable ’][ ’ id ’]} " )
5 print ( f " ssn : { data [ ’ ssn ’]} , edad : { data [ ’ age ’]} , temperatura : {
round ( data [ ’ wearable ’][ ’ temperature ’] , 1) } , ritmo cardiaco : { data [ ’
wearable ’][ ’ heart_rate ’]} , p r e s i n arterial : { data [ ’ wearable ’][ ’
blood_pressure ’]} , dispositivo : { data [ ’ wearable ’][ ’ id ’]} " )
6 print ()
7 time . sleep (1)
8 ch . basic_ack ( delivery_tag = method . delivery_tag )

Después de recibir el mensaje, el “monitor” procesa el mensaje, tal como se muestra

en la línea 2 "data = json.loads(body.decode("utf-8"))", para después mostrarlo al Asistente
utilizando las líneas 3, 4, 5 y 6.

7.3.4. Ejecución
Una vez descargado el sistema, Sigue los siguientes pasos para ejecutarlo.
Lo primero será instanciar el Distribuidor de mensajes RabbitMQ utilizando Docker.
Utiliza el siguiente comando para instanciar el Distribuidor de mensajes con Docker.

docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management

Una vez instanciado el Distribuidor de mensajes, podrás acceder al portal de adminis-

tración web ingresando a la url http://localhost:15672/ desde cualquier navegador. La
figura 7.9 muestra la página de login de Distribuidor de mensajes, utiliza como usuario y
contraseña la palabra ”guest”.

Figura 7.9: Página de login del Distribuidor de mensajes

Al ingresar al portal de administración de RabbitMQ se visualizará un resumen de la

actividad del mismo, así como se muestra en la figura 7.10.
Una vez que se ha instanciado el Distribuidor de mensajes es momento de ejecutar
los Publicadores y Suscriptores. Cada Publicador y Suscriptor se deberá ejecutar en una
ventana independiente de la línea de comandos.
Para ejecutar el Publicador y los Suscriptores incluidos en el repositorio del sistema
SMAM puedes seguir las instrucciones incluidas en el repositorio mismo.
40 7. PATRÓN PUBLICA-SUSCRIBE

Figura 7.10: Página de resumen del Distribuidor de mensajes

Al ejecutar el Publicador se crearán un número finito de ”wearables” ficticios que simu-

larán el monitoreo de los signos vitales de un adulto mayor y se enviarán al Distribuidor
de mensajes. La figura 7.11 muestra un ejemplo de la ejecución del Publicador del sistema
SMAM.

Figura 7.11: Ejemplo de ejecución del componente Publicador

7.4. PREGUNTAS DE AUTOEVALUACIÓN 41

Por otro lado, en la figura 7.12 muestra la ejecución de un Suscriptor, que en éste caso
corresponde al procesador de temperatura. Este componente recibe los mensajes enviados
desde el Publicador a través del Distribuidor de mensajes y los procesa para detectar
valores superiores a los límites permitidos en los signos vitales de un adulto mayor.

Figura 7.12: Ejemplo de ejecución del componente Suscriptor