Architecture de Publish/subscribe

Aperçu de haut niveau

Les fonctions de Publish/subscribe sont une partie intégrante de Zato qui permet de l'utiliser comme courtier de messages en plus des services SOA/API ou des API de gestion des utilisateurs et de SSO.

Les données métier peuvent être échangées entre les applications en utilisant une notion de sujets et de files d'attente de livraison. Les éditeurs produisent des messages qui sont acheminés par Zato vers les abonnés, en appliquant des règles de transformation ou de sécurité lors de leur passage sur la plate-forme.

Chaque application échangeant des informations à l'aide de la fonction de Publish/subscribe peut utiliser un protocole de connexion différent et un mécanisme de sécurité différent sans s'influencer mutuellement.

La prise en charge de Python, REST, SOAP et WebSockets est intégrée et chacun peut être utilisé indépendamment, ainsi, un environnement de Publish/subscribe basé sur Zato peut répondre à divers besoins d'intégration, qu'il s'agisse de grands systèmes CRM ou ERP, d'API en ligne ou de dispositifs IoT.

Les applications participant à l'échange de messages à l'aide de sujets et de files d'attente de messages sont collectivement appelées points d'extrémité. Chaque endpoint encapsule des informations sur l'application qui se connecte à pub/sub, ainsi que les autorisations d'accès du endpoint - les sujets qu'il peut publier et auxquels il peut s'abonner.

Chaque endpoint a un rôle - éditeur, abonné ou éditeur/abonné. En outre, chaque endpoint peut être configuré pour avoir accès à la publication ou à l'abonnement uniquement aux sujets correspondant à des modèles définis par l'utilisateur.

Pour chaque abonné et chaque sujet, une file d'attente de messages est maintenue automatiquement par Zato pour conserver les données jusqu'à ce que l'abonné confirme avoir reçu un message particulier.

Une file d'attente de messages peut être dans la RAM ou soutenue par un stockage persistant. Les deux types de files d'attente mettent en mémoire tampon les messages si l'abonné n'est pas disponible. De plus, le dernier type de file d'attente est appelé file d'attente à livraison garantie (GD) car son contenu sera disponible même si tous les serveurs Zato tombent en panne, ce qui n'est pas le cas avec les files d'attente in-RAM.

Les files d'attente in-RAM sont limitées par la quantité de RAM disponible pour les serveurs Zato. Les files d'attente GD stockent leurs données dans une base de données SQL et sont limitées par l'espace disque attribué à la base de données.

Les files d'attente GD survivront à un redémarrage complet de tous les serveurs Zato dans un environnement donné, car toutes leurs données sont conservées dans une base de données SQL. À l'inverse, les files d'attente in-RAM n'ont pas de stockage persistant et le redémarrage des serveurs entraînera la perte de tous leurs messages.

Les messages en transit peuvent être modifiés sur place - par exemple, si un abonné continue de rejeter un message, il est possible de le mettre à jour sans exiger de l'éditeur qu'il le republie, ce qui est parfois impossible.

Les abonnements peuvent être créés explicitement par les administrateurs ou, si elles y sont autorisées, les applications peuvent s'abonner par le biais d'appels API dédiés.

Une console d'administration Web permet d'accéder à toute la configuration et de parcourir le contenu des files d'attente, ainsi que les métadonnées les plus courantes, comme la date de la dernière publication d'un sujet.

Un log d'audit détaillé permet aux administrateurs de comprendre quand chaque message a été publié et délivré.

Sujets

Chaque thème a un nom unique qui identifie le thème et son objectif commercial parmi d'autres thèmes. Par exemple, dans la capture d'écran ci-dessus, le thème "customer.new.1" peut être utilisé pour publier des données sur les nouveaux clients ajoutés au CRM d'une entreprise avec les abonnés intéressés par la réception de cet événement commercial.

Un thème peut être actif ou inactif. Un thème actif peut être utilisé pour la publication de messages, tandis qu'un thème inactif rejettera tout nouveau message.

Chaque thème peut être activé ou non pour la GD. S'il l'est, chaque message publié sera par défaut couvert par la livraison garantie, bien que ce paramètre puisse être remplacé sur une base par message.

Les abonnements API peuvent être activés ou désactivés pour les sujets - dans le premier cas, les applications possédant les informations d'identification et les autorisations d'accès correctes seront autorisées à s'abonner aux sujets en utilisant des API telles que REST. Dans le premier cas, seuls les administrateurs seront en mesure de créer des abonnements.

Un sujet a sa profondeur maximale, qui est gérée séparément pour les messages in-RAM et GD. S'il y a des abonnements pour un sujet mais que les abonnés ne consomment pas les messages alors que les messages continuent d'arriver, à un moment donné, la profondeur du sujet sera atteinte et les nouveaux messages publiés seront rejetés jusqu'à ce que les messages précédents aient été consommés par les abonnés ou que le sujet ait été effacé par les administrateurs. Tous les messages GD supplémentaires seront rejetés et les messages non-GD seront enregistrés dans des fichiers journaux sur le disque.

Pour les messages activés par GD, la profondeur maximale est vérifiée globalement, quel que soit le nombre de serveurs dans un cluster Zato. Pour les messages in-RAM, la profondeur s'applique à chaque serveur séparément.

Si un sujet n'a pas d'abonnements - par opposition à un sujet qui a des abonnements mais qui n'a pas d'abonnés en train de lire des messages - tous les messages publiés dans le sujet seront traités comme des messages compatibles avec la GD, qu'ils aient été envoyés à l'origine comme des messages GD ou non GD.

Endpoints

Les endpoints - éditeurs et abonnés - représentent généralement une seule application prenant part aux processus basés sur la publish/subscribe et leurs noms le reflètent.

Un endpoint a un type qui représente la technologie et le protocole sous-jacents. Les types pris en charge sont REST, SOAP, Zato service, WebSockets et les canaux de transfert de fichiers.

Les points d'extrémité se voient attribuer un rôle qui leur permet de publier des sujets, de s'abonner à des sujets, ou les deux, peu importe lesquels en particulier. Par exemple, si un endpoint est uniquement un éditeur, il ne pourra jamais s'abonner à un sujet, il pourra envoyer mais pas recevoir des messages.

Les permissions basées sur des modèles dictent les sujets qu'un endpoint peut publier ou auxquels il peut s'abonner. Par exemple, dans la capture d'écran ci-dessus, le terminal ERP sera en mesure de publier des messages dans le thème 'customer.new.daily', si un tel thème existe, parce qu'il correspond au modèle 'customer.new.*', mais il ne sera pas en mesure de publier dans le thème 'customer.updates.hourly' parce qu'il n'y a pas de modèle d'accès correspondant.

Abonnements

Pour autant que les modèles d'autorisation soient corrects et que des sujets pertinents existent, chaque endpoint peut s'abonner à un ou plusieurs sujets.

La distribution des messages pour chaque abonnement est toujours effectuée par un seul serveur, appelé serveur de distribution pour cet abonnement. Cela permet de garantir l'ordre correct des messages : si plusieurs serveurs d'un cluster Zato reçoivent des messages destinés à l'abonnement, ils seront transmis en premier lieu au serveur de distribution de cet abonnement. Pour les messages en RAM, ils sont conservés dans la RAM du serveur de distribution.

Les messages peuvent être envoyés sur la base d'une notification ou d'une extraction. Dans le premier cas, Zato invoquera lui-même le endpoint avec de nouveaux messages, tandis que dans le second, Zato mettra les messages en file d'attente et le destinataire lira périodiquement le contenu de sa file d'attente. Quel que soit le type de livraison, les messages peuvent être envoyés un par un ou par lots d'une taille préconfigurée.

La livraison d'un message peut être répétée jusqu'à un nombre de fois configuré, avec un temps de repos entre les deux, configurable en fonction du type d'erreur rencontré - une erreur au niveau de la socket TCP ou une erreur différente.

Pour chaque type d'endpoint, les options spécifiques de ce type d'endpoint peuvent être fournies - par exemple, l'endpoint dans la capture d'écran ci-dessus est un REST, donc une méthode HTTP peut être spécifiée qui devrait être utilisée pour livrer les messages.

Chaque endpoint peut s'abonner à plusieurs types de sujets et reçoit à chaque fois une nouvelle clé d'abonnement - il s'agit d'un secret qui ne doit être connu que du participant à qui il a été délivré.

APIs

Nom Usage Lire la suite
Python Services Zato utilisant la fonction publish/subscribe Docs
REST Clients externes échangeant des messages en utilisant JSON sur HTTP Docs
AMQP Brokers AMQP recevant des messages de sujets Zato Docs

GUI

Les administrateurs ont accès à une interface graphique via le tableau de bord d'administration web intégré de Zato - il offre toutes les fonctionnalités nécessaires à la configuration et à la maintenance, notamment la possibilité de configurer les sujets, les endpoints, les abonnements, de parcourir les messages, de publier de nouvelles données ou de mettre à jour les messages existants en place.

Sécurité

L'intégrité et la sécurité des sujets de publish/subscribe sont protégées à plusieurs niveaux.

  • Chaque application doit être authentifiée à l'aide d'un mécanisme propre à son protocole. Par exemple, les applications REST enverront une clé API.
  • La capacité de publier ou de s'abonner à des sujets doit être explicite - par défaut, un endpoint n'a aucune permission pour aucun des sujets.
  • Les informations d'identification sont toujours stockées dans la base de données sous une forme cryptée (AES-128, CBC, PKCS7).
  • Comme c'est le cas pour d'autres parties de Zato, il n'y a pas de mots de passe par défaut.

Stockage persistant

Zato utilise une base de données SQL pour le stockage persistant des files d'attente de livraison garantie. Il s'agit de la même base de données que celle dans laquelle sont conservées les autres tables de la plate-forme. Les outils et installations SQL standard peuvent être utilisés pour sauvegarder et déplacer les données de publish/subscribe si nécessaire.

Journalisation

2022-01-02 18:26:59,636 - INFO - PUB. CID:`4e2cba065db64cc4c69f8f79`,
  topic:`zato.demo.sample`, from:`zato.pubsub.demo.endpoint`, ext_client_id:`n/a`,
  pattern:`pub=zato.demo.*`, new_depth:`n/a`, GD data:`[]`, non-GD data:`[{'data_prefix': None,
  'cluster_id': 1, 'data_prefix_short': None, 'size': 24, 'pub_time': 1522686419636.607,
  'has_gd': False, 'ext_pub_time_iso': None, 'sub_key': None, 'priority': 5,
  'expiration_time_iso': None, 'ext_pub_time': '', 'topic_id': 1,
  'expiration_time': 3670170066636.607, 'mime_type': '',
  'pub_msg_id': 'zpsmeb2e4ebe371e2bb75318de28', 'pub_time_iso': None,
  'pattern_matched': 'pub=zato.demo.*', 'published_by_id': 1, 'delivery_status': 'initialized',
  'in_reply_to': None, 'data': 'This is a sample message',
  'position_in_group': None, 'pub_correl_id': None, 'expiration': 2147483647, 'group_id': None,
  'ext_client_id': None}]

Pour chaque message publié, une nouvelle entrée est enregistrée dans le journal d'audit. Par défaut, ces informations sont enregistrées dans les fichiers logs mais il est possible de les reconfigurer pour envoyer les entrées vers d'autres destinations telles que syslog ou Sentry.

Chaque entrée contient des métadonnées complètes sur le message, par exemple, quel endpoint l'a publié, en fonction de quel modèle de sécurité l'accès a été accordé, quand le message expirera ou quelle était sa priorité.

En savoir plus