Message Broker

Le hub étoile : un seul point d'échange au lieu d'un maillage N×N de connexions point-à-point.

Problème

Une chaîne EDI a 50 partenaires et 30 sous-systèmes internes. Sans broker, chaque émetteur doit connaître chaque destinataire — combinatoire ingérable, et un changement chez un partenaire impose recompilations chez tous les autres.

Forces

• Une intégration N×N coûte O(N²) liens et autant de tests.
• Un broker devient critique : son indisponibilité bloque toute la chaîne.
• Un broker doit être hautement disponible (cluster, multi-AZ).
• Le broker peut devenir un single point of failure ou un bottleneck.

Solution

Centraliser les échanges sur un Message Broker : un émetteur publie sur un topic / queue / channel ; le broker route au(x) destinataire(s) selon des règles (topic-based, content-based, partner-based). Le découplage temporal (sender et receiver pas connectés en même temps), spatial (sender connaît un broker, pas les receivers individuels), et synchrone (sender n'attend pas) est total. Implémentations : IBM Sterling, Kafka, RabbitMQ, AWS SQS+SNS, Apache Pulsar.

Implémentation EDI

En EDI moderne, l'architecture cible est : (1) partenaires → AS2/AS4 gateway → broker (Kafka, MQ) → (2) consumers internes (ERP, lake, portal) ; (3) inversement pour le sortant. Le broker porte tous les topics par type métier (`edi.orders`, `edi.invoices`, `edi.mdns`). Patterns complémentaires : Selective Consumer pour filtrer côté broker, Durable Subscriber pour ne rien perdre offline, Dead Letter Channel pour les exceptions. Le broker matérialise aussi le Message Store via la rétention (Kafka log retention = 7 jours par défaut).

Anti-patterns

• Broker single-instance sans HA — un crash bloque toute la chaîne.
• Broker mutualisé entre prod et test — un test load casse la prod.
• Broker comme DB — stocker l'état métier dans Kafka au lieu d'un store dédié.
• Sender qui contourne le broker via un appel direct — re-coupling.

Patterns liés

• Message Bus — topologie connexe — backbone plutôt que hub.
• Publish-Subscribe Channel — canal type du broker.
• Point-to-Point Channel — canal type du broker.
• Messaging Bridge — pont entre brokers.

Sources

• Hohpe G., Woolf B. — EIP, Message Broker (p. 322). www.enterpriseintegrationpatterns.com/patterns/messaging/MessageBroker.html
• Apache Kafka — Documentation. kafka.apache.org/documentation/