Tout les message sont envoyé à l'exchange (topic) principal : agoram_exchange
C'est le consommateur qui met en place la topologie adapté à son usage.
| Sommaire |
|---|
Exchanges
Les exchanges sont les points d'entrée pour une Producteur de messages voulant envoyer un Message dans le système.
Dans l'architecture Gadz.org, on distingue 4 types d'exchanges :
...
Cet exchange reçoit l'ensemble des événements ayant lieu dans le système. Les services se s’inscrivent aux topics dont il souhaitent recevoir les notifications.
La manière dont le message est ensuite traité et la topologie en aval est définie par le service consommateur.
...
Un service DOIT ne presenter qu'un seul exchange de requêtes.
Un exchange de requêtes DOIT abonner l'exchange de logs au topic *
La topologie en aval de l'exchange de requêtes est définie par le service recevant les requêtes.
Les exchanges de réponses
...
Un service DOIT ne presenter qu'un seul exchange de reponses.
Un exchange de réponses DOIT avoir un nom du type reply.[identifiant_du_service]
Exemple de topologie
L'exemple ci-dessous ne satisfait pas les nouvelles spécifications
https://drive.google.com/a/gadz.org/file/d/0B6ucsDu49YbqTHJUc1ZQM3ZRLTQ/view?usp=sharing
Un exchange de réponses DOIT abonner l'exchange de logs au topic
*
La topologie en aval de l'exchange de requêtes est définie par le service ayant émis la requêtes
Service
Un service est un acteur de la SOA Gadz.org. Il vise a permettre le partage de fonctionnalités entre plusieurs applications et fournir une abstraction permettant de séparer la fonction métier des choix techniques (Choix de logiciel, de prestataire, etc.)
Un service peut être Producteur, Consommateur ou les deux.
Les services offre une abstraction permettant de définir des interfaces standards et un ensemble de règles de fonctionnement.
Exemples de topologies de services
Émetteur de message
Il s'agit du service le plus simple, il se contente d'émettre des événements ou des requêtes sans recevoir aucun message
Consommateur d’événement simple
Ce service consomme des évenements et logs éventuellement leur traitement.
La gestion des erreurs et des tentatives successives n'est pas gérée dans RabbitMQ.
Service multi instance avec gestion des Softfails
Ce service permet d'avoir plusieurs instances simultanées (pour augmenter la charge admissible) : service_cons1 avec service_prod1, service_cons2 avec service_prod2
En cas de soft fail, le message est envoyé dans service_delayed_in_x . Il est alors envoyé dans l'exchange de logs et dans une queue de stockage correspondant à la routing key d'entrée (par exemple request.service.action1 ).
Cette queue de stockage est configurée avec un TTL (durée de vie des message) et n'a pas de consommateur. Le message ne peut donc pas sortir de la queue avant son expiration. Le dead-letter-exchange de la queue a pour valeur service_delayed_out_x, un exchange fanout auquel la service queue est abonnée. Le message est ainsi réinjecté dans la queue principale après le TTL