Tout les message sont envoyé à l'exchange (topic) principal : agoram_exchange
C'est le consommateur qui met en place la topologie adapté à son usage.
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 :
- L'exchange d'évenement
- L'exchange de log
- Les exchanges de requêtes
- Les exchanges de réponses
L'exchange d'événement
Il n'y a qu'un seul exchange d’événement. C'est un exchange durable de type topic ayant pour nom agoram_event_exchange
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.
L'exchange de logs
Il n'y a qu'un seul exchange de log. C'est un exchange durable de type topic ayant pour nom log
Il a pour vocation à être inscrit à chacun des autres exchanges d'entrée sur le topic *. Cette inscription est à la charge du service responsable de l'exchanges d'entrée
Chacun des loggers peut ensuite s'inscrire à l'exchange de log, en spécifiant ou non une clé de routage pour n'écouter qu'une partie du traffic.
Le logger principal est abonné à l'exchange de log via la clé de routage *
Les exchanges de requêtes
Les exchanges de requêtes sont des exchanges créés par les services afin de recevoir des requêtes.
Un exchange de requêtes DOIT être de types topic.
Un exchange de requêtes DOIT être durable.
Un exchange de requêtes DOIT avoir un nom du type request.[identifiant_du_service]
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
Les exchanges de réponses sont des exchanges créé par les services afin de recevoir les réponses à leurs requêtes.
Un exchange de réponses DOIT être de types topic.
Un exchange de réponses DOIT être durable
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]
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