Point-to-Point Channel

Un message, un destinataire — le mode par défaut quand l'émetteur veut s'adresser à un partenaire identifié. C'est la sémantique qui caractérise AS2, SFTP partenaire-à-partenaire, et 99 % des connexions EDI bilatérales.

Problème

Un émetteur veut transmettre un message à un récepteur précis et une seule fois. Si l'on diffuse le message à plusieurs consommateurs, on risque qu'une commande soit traitée plusieurs fois : deux palettes expédiées au lieu d'une, deux factures émises. La sémantique recherchée est livraison exclusive : une et une seule application reçoit et traite chaque message.

Forces

• Garantie de non-doublon côté broker. Le canal lui-même garantit qu'un message lu et acquitté est retiré, pas seulement marqué.
• Asymétrie producteur/consommateur. Le producteur ne connaît pas l'identité physique du consommateur, juste le nom de la queue.
• Scalabilité horizontale. Plusieurs consommateurs peuvent concourir sur la même queue (competing consumers), tout en gardant l'exclusivité par message.
• Ordre préservable mais coûteux. Garder l'ordre strict d'arrivée impose un seul consommateur séquentiel (ou des partitions par clé).

Solution

EIP §103 (Hohpe & Woolf, 2003) définit le Point-to-Point Channel comme un canal dont la sémantique de livraison est exclusive : lorsqu'un consommateur lit et acquitte un message, ce message est retiré et ne sera plus jamais relu par aucun autre consommateur. C'est l'implémentation classique d'une queue (RabbitMQ, IBM MQ, SQS, Azure Service Bus queue, JMS queue), par opposition aux topics qui implémentent le pattern publish-subscribe.

one sender                      one receiver (exclusive)
   ──────────                      ──────────────────────────

   ┌────────┐     ┌──────────┐    ┌─────────────┐
   │ A      │ ──▶ │  queue   │ ──▶│ B           │
   └────────┘     └──────────┘    └─────────────┘
                  delete after
                  successful read

   Variant: competing consumers (still one delivery)
                  ┌──────────┐    ┌─────────────┐
                  │  queue   │ ──▶│ worker B1   │
                  │          │    └─────────────┘
                  │          │    ┌─────────────┐
                  │          │ ──▶│ worker B2   │
                  └──────────┘    └─────────────┘
                  (each msg goes to exactly one worker)

Implémentation EDI

En EDI, la majorité des canaux sont point-à-point :

• AS2 entre deux partenaires. Un fournisseur émet sur un AS2 dédié à un acheteur précis (Walmart, Stellantis…). Le message arrive dans le slot de réception unique, accusé par MDN. Une seule application destinataire le traite.
• OFTP2 multi-VAN. Les flux OFTP2 dans l'automobile (Stellantis, Renault) sont strictement bilatéraux entre deux stations OFTP nommées. Pas de diffusion.
• SFTP partenaire dédié. Un répertoire SFTP /in/walmart-edi/ sur lequel seul le pipeline d'intégration Walmart vient lire les fichiers. Une fois lu et acquitté en aval, le fichier est déplacé ou supprimé.
• VAN classique (GXS, Sterling). Une VAN historique pose chaque interchange dans la mailbox du destinataire ; aucun autre partenaire n'a accès à cette mailbox.

# AS2 partnership entry — un canal point-à-point typé
partnership "WALMART_BUYER -> SUPPLIER_GLN":
  channel-id: walmart-supplier-orders
  protocol: AS2
  url: https://walmart-edi.example.com/as2
  as2-from: WALMART_BUYER
  as2-to: SUPPLIER_GLN
  encryption: AES-256
  signing: SHA-256
  mdn: signed-async
  message-type: ORDERS / 850
  delivery-semantics: at-least-once  # MDN-retry path
  inbox-route: edi.orders.in.canonical
  retention-days: 2555  # ~7 ans conformité

Competing consumers

Hohpe distingue Point-to-Point de Publish-Subscribe par la sémantique de livraison, pas par le nombre de consommateurs. Une queue point-à-point peut être lue par N workers en compétition (pattern Competing Consumers EIP §502) : chaque message va à exactement un worker, mais N workers se partagent la charge. C'est ce mode qui rend les pipelines EDI horizontalement scalables sans sacrifier l'unicité de traitement.

Anti-patterns

• Plusieurs consommateurs non exclusifs sur une queue point-à-point. Si deux applications distinctes lisent la même queue, chacune attrape une part des messages — l'autre n'a rien. Symptôme classique : « j'ai déplacé l'app sur une seconde instance et la première a perdu la moitié des messages ».
• Auto-suppression sans acquittement. Le broker doit ne retirer le message qu'après ACK du consommateur, jamais à la lecture. Sinon un crash entre lecture et traitement perd définitivement le message.
• Pas de DLQ. Un message qui échoue N fois sur la queue principale doit basculer dans une Dead Letter Channel, pas tourner en boucle.
• Émetteur qui adresse un consommateur précis. Couplage : si l'émetteur sait que le worker s'appelle edi-worker-3, on perd l'intérêt du canal abstrait.

Patterns liés

• Message Channel — la généralisation.
• Publish-Subscribe Channel — l'alternative pour la diffusion.
• Dead Letter Channel — où vont les messages non traités après N essais.
• Idempotence — la défense en profondeur quand le broker est at-least-once.

Sources

• Hohpe G., Woolf B. — Enterprise Integration Patterns, pattern Point-to-Point Channel (§103). enterpriseintegrationpatterns.com — Point-to-Point Channel
• Hohpe G., Woolf B. — Competing Consumers (§502). enterpriseintegrationpatterns.com — Competing Consumers
• RFC 4130 — AS2, MIME-Based Secure Peer-to-Peer Business Data Interchange. IETF, juillet 2005.
• Apache Camel — JMS / RabbitMQ / SQS components. Chaque endpoint queue implémente le pattern point-à-point. camel.apache.org — JMS