Uso de canales de eventos#
Como se ha mencionado en la intrudicción, en esta nueva versión de la práctica nos encontramos dos nuevos problemas:
Los servicios que antes se comunicaban a través de comunicación directa ahora lo harán de manera indirecta, de uno a muchos.
Las distintas instancias de un mismo servicio deberán comunicarse entre ellas para mantener la coherencia entre ellas.
En esta sección analizaremos dónde están las comunicaciones que se verán afectadas por estos nuevos requisitos.
Anunciamientos#
En la primera parte de esta práctica, el único servicio interesado en recibir anunciamientos era el “Main”. Ahora, todos los servicios deberán recibir anunciamientos, ya que necesitan saber que servicios son legítimos y se están anunciando correctamente para aceptar mensajes que vengan de ellos.
Cada uno de nuestros servicios estará interesado en descubrir a otros, pero quizá no esté interesado en los anunciamientos de todos los servicios.
Para ello se definirá una nueva interfaz llamada Announcement que tendrá
un método ya conocido: announce:
interface Announcement {
void announce(Object* service, string serviceId);
};
Nombre del topic
El topic para publicar y recibir los anunciamientos de servicios deberá llamarse Announcements.
Recuerda utilizar ese nombre para recuperar el topic para asegurar la compatibilidad entre
diferentes implementaciones de los servicios.
Todos los servicios deberán enviar sus anunciamientos de la siguiente manera:
Utilizando la interfaz
Announcementen lugar deMain.Enviándolo al topic de nombre
"Announcements"disponible en IceStorm.Únicamente enviarán invocaciones del método
announce.En lugar de cada 30 segundos como máximo, deberán ser cada 10 segundos como máximo.
A su vez, todos los servicios, y no sólo el Main,
deberán subscribirse a ese mismo topic para recibir todos los anunciamientos.
Anunciamientos no relevantes
Que un servicio reciba los anunciamientos de todos los demás no significa que sean relevantes. Algunos servicios simplemente ignorarán los anunciamientos si vienen de servicios que no le interesen para nada.
Utilizando los anunciamientos como fuente de “servicios conocidos”#
Como se menciona anteriormente, las diferentes instancias de un mismo servicio utilizarán un topic de IceStorm para comunicarse y mantener la coherencia de los datos.
Es importante que sepamos que los datos, para ser aceptados por nuestra instancia, deberían venir siempre de una instancia que ya conociéramos anteriormente.
El canal de eventos de anunciamientos será nuestra fuente de “verdad” respecto a servicios conocidos: si recibimos una actualización de datos de nuestro servicio, pero el “serviceId” del mensaje no lo reconocemos, deberemos ignorar el mensaje.
Comunicación entre Authenticators#
Las diferentes instancias de Authenticator, de manera independiente,
son capaces de tener sus propias bases de datos de usuarios registrados y
los tokens de usuario activos. Para esta entrega,
se pedirá que ambas cosas se compartan entre las diferentes instancias a través de
un topic IceStorm.
Por ello, el servicio de autenticación deberá convertirse también en un publicador y subscriptor de mensajes en dicho canal de eventos, de acuerdo con esta interfaz:
// Interface to be used in the topic for user related updates
interface UserUpdate {
void newToken(string user, string token, string serviceId);
void revokeToken(string token, string serviceId);
void newUser(string user, string passwordHash, string serviceId);
void removeUser(string user, string serviceId);
};
Nombre del topic
El topic para publicar y recibir los cambios ocurridos en una instancia de Authenticator deberá llamarse UserUpdates.
Recuerda utilizar ese nombre para recuperar el topic para asegurar la compatibilidad entre
diferentes implementaciones de los servicios.
Actualizaciones no relevantes
Cada vez que se reciba un mensaje desde este topic,
el servicio deberá cerciorarse de que el servicio que lo envió es un servicio
conocido con anterioridad a través de su serviceId.
Comunicación entre MediaCatalogs#
Los MediaCatalog pueden recibir, desde un cliente,
cambios en el estado de sus datos: actualizaciones de tags o renombrado de archivos.
Estos cambios en los datos que maneja el servicio deben ser difundidos al resto de instancias a través de un topic en IceStorm, por lo que el servicio se convertirá también en un publicador y subscriptor de ese topic.
Los mensajes transmitidos a través de esa
// Interface to be used in the topic for catalog media changes
interface CatalogUpdate {
void renameTile(string mediaId, string newName, string serviceId);
void addTags(string mediaId, string user, StringList tags, string serviceId);
void removeTags(string mediaId, string user, StringList tags, string serviceId);
};
Nombre del topic
El topic para publicar y recibir los cambios ocurridos en una instancia de MediaCatalog deberá llamarse CatalogUpdates.
Recuerda utilizar ese nombre para recuperar el topic para asegurar la compatibilidad entre
diferentes implementaciones de los servicios.
Actualizaciones no relevantes
Cada vez que se reciba un mensaje desde este topic,
el servicio deberá cerciorarse de que el servicio que lo envió es un servicio
conocido con anterioridad a través de su serviceId.
Anunciamiento de archivos disponibles desde el FileService#
En el caso de los servicios de ficheros, no tenemos el problema de la consistencia de datos que hemos descrito en el resto de servicios, debido a que este tipo de servicio no tiene una base de datos local de ningún tipo.
Aún así, las instancias de los servidores de ficheros necesitarán notificar a
un número indeterminado de MediaCatalog sobre sus archivos disponibles,
para lo que utilizarán también IceStorm.
Para ello se publicará periodicamente en un topic la lista de identificadores de archivo
que están disponibles en cada instancia,
de modo que todos los MediaCatalog podrán saber qué cambios ha sufrido cada servidor de archivos.
// Interface to be used in the topic for file availability announcements
interface FileAvailabilityAnnounce {
void announceFiles(StringList mediaIds, string serviceId);
};
Nombre del topic
El topic para publicar y recibir los cambios ocurridos en una instancia de FileService deberá llamarse FileAvailabilityAnnounce.
Recuerda utilizar ese nombre para recuperar el topic para asegurar la compatibilidad entre
diferentes implementaciones de los servicios.
Actualizaciones no relevantes
Cuando un servidor de archivos envíe un anuncio,
los catálogos que estén subscritos deberán comprobar si ese servicio,
identificado por su serviceId, ya estaba siendo anunciado antes.
Además, la invocación no contiene el proxy al servicio, por lo que éste deberá ser deducido por el servicio de catálogo de los anunciamientos de servicio.