Nous avons un système existant qui traite un grand nombre de fichiers sur une base continue. Grosso modo, environ 3 millions de fichiers par jour pouvant aller de quelques kilo-octets à plus de 50 Mo. Ces fichiers passent par différentes étapes de traitement, du moment où ils sont reçus jusqu'à la fin de la consommation, en fonction du chemin qu'ils empruntent. En raison du contenu et du format de ces fichiers, ils ne peuvent PAS être divisés en plus petits morceaux. Actuellement, le flux de travail de ces fichiers est rigide et dicté par le code avec des entrées et des sorties fixes (dans de nombreux cas, lorsqu'un abonné devient l'éditeur d'un nouvel ensemble de fichiers). Ce manque de flexibilité commence à nous causer des problèmes, alors je suis à la recherche d'une solution de pub/sous pour pouvoir gérer de nouvelles exigences.Publication/abonnement avec des fichiers volumineux en tant que charges utiles de messages
La plupart des solutions pub/sous traditionnelles ont les données dans la charge utile réelle, mais les grandes tailles de fichiers potentielles dépassent les limites de nombreuses plates-formes de messagerie. De plus, nous avons plusieurs plates-formes en jeu: les fichiers progressent à travers les niveaux Linux et Windows en fonction de leur chemin.
Quelqu'un at-il des recommandations de conception et/ou de mise en œuvre avec les objectifs suivants à l'esprit?
1. multiplateformes pour les pub et sous (Linux et Windows)
2. Le stockage persistant/stockage et avant le soutien
3. Peut gérer de grosses charges utiles d'événements et nettoie de façon appropriée une fois tous les abonnés ont été desservis
4 . routage/flux de travail se fait via la configuration
5. Les abonnés peuvent souscrire à un ensemble filtré d'événements publiés en fonction de critères changeants (par exemple, me donner uniquement les fichiers d'un type spécifique)
Je l'ai fait un tas de creuser dans un certain nombre de mises en œuvre de bus de service et MQ, mais n'ont pas encore été en mesure de raffermir assez d'une approche de conception pour évaluer correctement quel outil s ont le plus de sens. Merci pour toute contribution.
Intéressant. J'ai pensé à passer le chemin du fichier, mais je ne suis pas sûr comment concilier cela avec le nombre inconnu d'abonnés - comment puis-je savoir quand le dernier abonné a obtenu le fichier (pour que je puisse l'enlever)? Merci pour le pointeur WCF sur les messages en streaming. J'espère que les exigences 4 et 5 pourraient éventuellement être satisfaites par une mise en œuvre existante, mais c'est peut-être exagéré. – Joe
Nous avons eu de la chance: nous n'avions qu'une douzaine d'étapes de traitement, avec très peu de branches. Et, nous avons eu un moment précis où le traitement de tas d'éléments est terminé. – Soonts
Je pense que vos # 4 et # 5 sont trop spécifiques au projet pour faire partie d'un framework. J'ai vu plusieurs produits qui ont fait du routage/workflow via la configuration, ils utilisent tous des approches différentes: MS Visio intégré dans BizTalk, XML énormes dans certains frameworks Java, interface utilisateur sophistiquée dans Virtools, etc. IMO parce que la logique derrière routage et abonnement est très étroitement couplé avec la nature des choses que vous traitez. – Soonts