Publish-Subscribe Channel

Le dual du point-à-point : au lieu d'un récepteur exclusif, plusieurs abonnés indépendants reçoivent chacun leur copie du message. Le modèle d'événements internes du hub, et la base technique de la diffusion B2B multi-destinataires.

Problème

Un événement métier — la validation d'une facture, la confirmation d'une commande, la mise à jour d'un catalogue — intéresse plusieurs parties : l'entrepôt qui doit préparer, la compta qui doit enregistrer, le portail fournisseur qui doit afficher, le data warehouse qui doit indexer. Si l'émetteur doit appeler explicitement chacun, il finit avec un graphe en étoile fragile. Le couplage augmente chaque fois qu'un nouvel intéressé apparaît. Il faut un canal qui diffuse : l'émetteur publie une fois, le canal redistribue à tous les abonnés.

Forces

• Découplage du producteur. Le producteur ne connaît pas la liste des abonnés ; il publie sur le topic.
• Extensibilité. Ajouter un consommateur = souscrire au topic, aucune modification côté producteur.
• Copies indépendantes. Chaque abonné a son propre pointeur de lecture / offset. La consommation d'un message par A n'affecte pas B.
• Fan-out à fort coût. Le canal duplique le payload pour N abonnés. Combiner avec Claim Check pour les gros payloads.

Solution

EIP §106 (Hohpe & Woolf, 2003) définit le Publish-Subscribe Channel comme un canal qui diffuse : chaque message publié est livré à tous les abonnés courants. C'est l'implémentation classique d'un topic (Kafka, RabbitMQ exchange fanout, JMS Topic, AWS SNS, Azure Service Bus topic). Chaque abonnement maintient son propre état de progression : un abonné peut être en retard sans bloquer les autres ; il peut être réinitialisé pour relire l'historique sans réémettre.

one publisher                       N independent subscribers
   ─────────────                       ────────────────────────

                                     ┌─▶ subscriber A (warehouse)
                                     │
   ┌──────────┐    ┌──────────┐      │
   │ producer │ ──▶│  topic   │ ─────┼─▶ subscriber B (accounting)
   └──────────┘    └──────────┘      │
                                     │
                                     └─▶ subscriber C (analytics)

   Each subscriber gets its own copy; ack of A doesn't drop B/C.

Implémentation EDI

• SBDH UBL routé vers plusieurs AP PEPPOL. En B2B gouvernement, une facture UBL emballée dans un SBDH (Standard Business Document Header, ISO/IEC 15000-5) peut être adressée simultanément à un Access Point de l'acheteur et à un AP de l'autorité fiscale (modèle 5-coins). Le hub d'émission publie une fois ; le réseau PEPPOL achemine vers les deux destinations.
• Événements internes du hub. Un topic Kafka edi.events.invoic.validated est publié par le validateur ; trois consommateurs s'abonnent : le router qui sort la facture chez le partenaire, le moteur de KPI qui met à jour le dashboard, le service notification qui envoie un mail à l'opérateur. Aucun ne sait que les deux autres existent.
• Catalogue PRICAT broadcast. Un fournisseur publie une mise à jour de catalogue (EDIFACT PRICAT ou GS1 Catalog) qui doit atteindre 12 chaînes d'enseignes différentes. Diffuser via topic interne, le routeur sortant pousse chez chaque enseigne sur leur canal point-à-point respectif.
• Notifications GLN-based. Un événement « livraison constatée » (DESADV/ASN reçu et validé) est diffusé à toutes les applications qui s'y abonnent par GLN destinataire : portail fournisseur, ERP, traceur GS1.

<?xml version="1.0" encoding="UTF-8"?>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader">
  <StandardBusinessDocumentHeader>
    <HeaderVersion>1.0</HeaderVersion>
    <Sender>
      <Identifier Authority="iso6523-actorid-upis">0088:5798000000122</Identifier>
    </Sender>
    <Receiver>
      <Identifier Authority="iso6523-actorid-upis">0088:7300010000001</Identifier>
    </Receiver>
    <DocumentIdentification>
      <Standard>urn:oasis:names:specification:ubl:schema:xsd:Invoice-2</Standard>
      <TypeVersion>2.1</TypeVersion>
      <InstanceIdentifier>inv-202605140001</InstanceIdentifier>
      <Type>Invoice</Type>
      <CreationDateAndTime>2026-05-14T12:00:00Z</CreationDateAndTime>
    </DocumentIdentification>
  </StandardBusinessDocumentHeader>
  <Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
    <!-- payload UBL -->
  </Invoice>
</StandardBusinessDocument>

Lecture : le SBDH déclare un émetteur unique mais le couplage SBDH + AP PEPPOL permet à un même payload UBL d'être routé vers plusieurs destinataires (acheteur + administration), chacun reçoit sa copie. Le coin 5 (autorité fiscale en mode CTC, Italie, Pologne, France) est typiquement un abonné supplémentaire au canal publish-subscribe.

Abonnements durables vs. transitoires

Deux modes selon la criticité :

• Durable. L'abonnement persiste même si le consommateur est déconnecté ; les messages s'accumulent dans son tampon jusqu'à reprise. Indispensable en EDI métier (perte = facture non comptabilisée).
• Transient (non-durable). L'abonnement vit avec le consommateur : si déconnexion, perte des messages manqués. Acceptable seulement pour des flux purement informationnels (logs, télémétrie).

Anti-patterns

• Pub-sub là où point-à-point suffit. Si on a un destinataire, utiliser une queue. Un topic à un seul abonné ajoute du débit duplicaté inutile et casse les garanties d'unicité.
• Abonnement transient pour flux métier. Le premier redémarrage perd les messages reçus pendant la coupure. En B2B, toujours durable.
• Payload énorme sans claim check. Diffuser 10 MB à 12 abonnés = 120 MB de réseau et de stockage. Externaliser le payload en S3 + diffuser une référence.
• Ordre attendu cross-abonnés. Un abonné peut être en retard de plusieurs minutes sur un autre. Ne pas coupler logiquement deux abonnés via le timing du topic.

Patterns liés

• Message Channel — la généralisation.
• Point-to-Point Channel — l'alternative exclusive.
• Wire Tap — un abonné observateur greffé sur un canal existant.
• Claim Check — pour éviter de dupliquer le payload N fois.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Publish-Subscribe Channel (§106). enterpriseintegrationpatterns.com — Publish-Subscribe Channel
• ISO/IEC 15000-5 — ebXML Core Components Technical Specification, qui formalise le Standard Business Document Header (SBDH) utilisé par OpenPEPPOL pour identifier émetteur et destinataire(s).
• OpenPEPPOL — PEPPOL Network Architecture. Le modèle 4-coins (et son extension 5-coins en CTC) repose sur un adressage publish-subscribe par participant ID. docs.peppol.eu/edelivery
• Apache Kafka — Documentation. Le topic Kafka est l'implémentation moderne de référence du pattern, avec offsets per-consumer-group. kafka.apache.org/documentation