Dynamic Router

Le routeur qui ne sait pas où aiguiller — il demande aux consumers et apprend.

Problème

Un Content-Based Router classique a ses règles hard-codées. Comment évoluer quand on ajoute un nouveau partenaire ou un nouveau type de message sans redéployer le routeur ?

Forces

• Le routage doit pouvoir changer sans redémarrage du hub central.
• Les consumers connaissent mieux leurs capacités que le routeur central.
• Les capacités évoluent — versions de schémas, nouveaux subsets, deprecation de protocoles.
• Le hard-coding amène fatalement à des règles obsolètes que personne n'ose toucher.

Solution

Chaque consumer émet un message d'annonce sur un control channel : 'je sais traiter EDIFACT INVOIC D.96A, je sais traiter X12 850 v4010'. Le routeur indexe ces annonces dans une table en mémoire et route en fonction. Réannonce périodique (heartbeat) pour gérer les disparitions.

Implémentation EDI

En EDI, le Dynamic Router est utile pour les hubs multi-tenant SaaS où les partenaires sont configurés via API. Chaque service consumer (parser EDIFACT, validator X12, AS2 server) publie sur un topic edi.control.announce une description JSON de ses capacités. Le routeur consomme cette annonce et l'index. Avantage : ajouter un consumer = aucun changement central.

Anti-patterns

• Pas de heartbeat — un consumer crashed reste dans la table, messages perdus.
• Pas de versioning des annonces — un schema-breaking deployment casse tout.
• Annonces écrites en clair (texte libre) — impossible à indexer correctement.

Patterns liés

• Content-Based Router — version statique.
• Message Router — concept parent.
• Control Bus — canal des annonces.

Sources

• Hohpe G., Woolf B. — EIP, Dynamic Router (p. 243). www.enterpriseintegrationpatterns.com/patterns/messaging/DynamicRouter.html