Endpoints Publish/subscribe

Matériaux préliminaires : Pub/sub architecture.

Introduction

Les points d'extrémité sont les entités qui envoient des messages aux sujets ou les reçoivent des files d'attente. Dans une architecture typique, un seul endpoint représentera une application particulière participant aux processus pub/sub, mais il n'est pas nécessaire qu'il y ait un seul endpoint par application et les utilisateurs sont libres de créer autant de points d'extrémité que nécessaire.

Il existe plusieurs types de points d'extrémité:

REST, SOAP et AMQP doivent être enregistrés par les administrateurs avant de pouvoir participer à la publish/subscribe. Les endpoints de ce type peuvent être configurés pour leur permettre de publier des messages, de s'y abonner ou les deux.

Les services Zato n'ont pas besoin d'être gérés par des administrateurs car ils peuvent toujours publier sur tous les sujets.

Les clients WebSocket n'ont pas besoin d'être abonnés au préalable par les administrateurs.

Les canaux de transfert de fichiers sont utilisés pour écouter les modifications apportées aux répertoires de votre choix, c'est-à-dire qu'il s'agit d'auditeurs de fichiers qui publient des informations sur les fichiers nouveaux ou modifiés, y compris éventuellement leur contenu. Les écouteurs de fichiers peuvent publier des messages vers des sujets, mais ils ne peuvent pas s'y abonner.

Les endpoints AMQP s'abonnent aux messages publiés dans les sujets, c'est-à-dire que chaque fois qu'un message est publié dans un sujet avec un abonné AMQP, un broker AMQP distant recevra son contenu.

Gestion des endpoints dans web-admin

Chaque endpoint défini dans web-admin possède un type, un nom et un rôle. Chacun est identifié par son nom qui est unique parmi tous les autres endpoints, quel que soit leur type.

Pour les endpoints REST et SOAP, des informations d'identification API, telles que HTTP Basic Auth, doivent leur être attribuées. Les applications qui se connectent aux sujets et aux files d'attente de Zato utiliseront ces informations d'identification pour l'authentification.

Les endpoints basés sur les WebSockets doivent pointer vers un canal WebSockets qui, à son tour, spécifiera éventuellement une définition de sécurité à utiliser pour l'authentification.

Un rôle de Publisher, de Subscriber ou Publisher/Subscriber peut être attribué à chaque endpoint. Cela détermine si un endpoint peut, en principe, publier ou s'abonner à des sujets.

L'accès aux thèmes est basé sur des modèles, c'est-à-dire qu'un seul modèle d'accès peut couvrir plusieurs thèmes, y compris ceux qui n'existent pas au moment de la création d'un endpoint.

Il est habituel d'organiser les noms de sujets et leurs modèles d'autorisation respectifs dans des structures hiérarchiques, allant des éléments les plus larges aux plus spécifiques en utilisant une barre oblique / comme séparateur, à l'instar des chemins de fichiers dans un système de fichiers.

Les symboles spéciaux qui peuvent être utilisés dans les modèles sont les suivants :

Symbole Nom Notes
* Astérisque Correspond à zéro ou plusieurs caractères, à l'exception de la barre oblique.
** Deux astérisques Correspond à zéro ou plusieurs caractères, y compris le slash.

Supposons qu'il y ait plusieurs sujets ..

Sujet Notes
/usa/va/richmond Evénements liés à Richmond, Virginie, Etats-Unis
/usa/va/washington Evénements liés à Washington, Virginie, Etats-Unis
/customer/address/changed Notifications sur les changements d'adresse des clients dans le CRM d'une entreprise.
/customer/telephone/changed Notifications sur les changements de téléphone des clients dans le CRM d'une entreprise.
/customer/telephone/deleted Notifications concernant les téléphones supprimés des clients dans le CRM d'une entreprise

.. il est possible de créer différents modèles d'accès en fonction de l'objectif visé:

Sujet Notes
/usa/va/richmond Parce qu'il n'utilise pas de symboles spéciaux, il correspond au nom exact du sujet.
/usa/** Recherche tous les sujets liés aux États-Unis, c'est-à-dire ceux qui commencent par ce préfixe.
/usa/va/* Correspond à tous les sujets liés à la Virginie, aux États-Unis. Actuellement, cela correspond à Richmond et Washington, mais si un autre sujet est ajouté, tel que /usa/va/arlington, il sera également pris en compte lors de l'exécution, même si ce sujet n'existe pas au moment de la création ou de la dernière modification du endpoint.
/usa/*/richmond Correspond à n'importe quelle ville de Richmond aux États-Unis
/customer/** Faire correspondre tous les sujets relatifs aux clients dans le CRM
/customer/*/changed Correspond à tous les sujets liés aux changements dans les clients
/customer/telephone/* Correspond à tous les sujets liés aux changements ou aux suppressions de clients

Notez que les modèles sont spécifiés séparément pour les publications et les abonnements et qu'il doit y avoir un rôle correspondant pour que le modèle soit pris en compte, c'est-à-dire que si un terminal a des droits de publication sur un sujet mais que son rôle est celui d'un abonné, il ne sera pas en mesure de publier le message malgré des droits d'accès corrects. Ceci peut être utilisé pour révoquer temporairement les droits de publication ou d'abonnement sans avoir à redéfinir les permissions.

Dans l'exemple ci-dessous, un endpoint REST appelé CRM a un rôle d'éditeur/abonné. Il utilise les informations d'identification définies dans une sécurité HTTP Basic Auth 'pubapi'. Il est autorisé à publier sur tous les sujets correspondant au motif /usa/va/* mais il n'est pas autorisé à s'abonner aux messages de ces sujets. Il est cependant autorisé à la fois à publier et à s'abonner à des messages correspondant au motif /customer/*/changed.

Il suffit de créer un endpoint et de lui donner les droits de publication pour que ce endpoint commence immédiatement à publier, aucune autre étape n'est nécessaire. Cependant, pour recevoir des messages, il faut d'abord créer un abonnement.

Sujets connexes