Scatter-Gather

Le fan-out/fan-in — demander à 5 partenaires en parallèle et prendre la meilleure réponse.

Problème

Pour un Request For Quote (REQOTE), on veut interroger 5 fournisseurs en parallèle et choisir la meilleure offre. Comment paralléliser sans bloquer ?

Forces

• Séquentiel = N × latence individuelle (insupportable si N=10).
• Le client veut une réponse rapide même si certains destinataires sont lents.
• Stratégies différentes : tous (wait for all), n premiers, premier qui répond, meilleur résultat selon critère.
• EDI : certains partenaires peuvent ne pas répondre du tout — il faut un timeout.

Solution

Le coordinateur (Scatter-Gather) envoie le message en parallèle à N destinataires (via Recipient List ou Publish-Subscribe), démarre un timer, collecte les réponses arrivant en désordre, et applique une stratégie d'agrégation : 'all', 'first N', 'best per critère'. Retourne la réponse agrégée après timeout ou complétion.

Implémentation EDI

En EDI, cas typique : REQOTE à 5 fournisseurs, attendre 30 secondes, prendre les 3 premières QUOTES reçues et présenter à l'acheteur. Implémentation Camel : `multicast().parallelProcessing().aggregationStrategy(bestQuote)`. Pour PEPPOL multi-AP discovery, on interroge plusieurs SMPs en parallèle et on prend la première réponse cohérente.

Anti-patterns

• Pas de timeout — un destinataire silencieux bloque tout.
• Wait-for-all rigide quand certains destinataires sont chroniquement lents.
• Réponse partielle masquée — l'utilisateur final croit avoir 5 quotes alors qu'il en a 2.

Patterns liés

• Recipient List — destinataires statiques du fan-out.
• Publish-Subscribe — alternative de diffusion.
• Aggregator — composant de gather.

Sources

• Hohpe G., Woolf B. — EIP, Scatter-Gather (p. 297). www.enterpriseintegrationpatterns.com/patterns/messaging/BroadcastAggregate.html