Utilisation dans le monde réel des files d'attente de messages / JMS?
Je ne faisais que lire quelques mots sur JMS et Apache ActiveMQ. Et vous demandiez-vous à quoi servent réellement les utilisateurs de JMS ou de technologies similaires de file d'attente de messages?
JMS (ActiveMQ est une implémentation de courtier JMS) peut être utilisé comme mécanisme permettant le traitement de requêtes asynchrones. Vous souhaiterez peut-être procéder ainsi, car la requête prend beaucoup de temps ou sa requête peut intéresser plusieurs parties. Une autre raison de l’utiliser est de permettre à plusieurs clients (potentiellement écrits dans différentes langues) d’accéder à des informations via JMS. ActiveMQ est un bon exemple ici, car vous pouvez utiliser le protocole STOMP pour autoriser l'accès à partir d'un client C #/Java/Ruby.
Un exemple concret est celui d’une application Web utilisée pour passer une commande pour un client particulier. Dans le cadre de la passation de cette commande (et de son stockage dans une base de données), vous pouvez effectuer un certain nombre de tâches supplémentaires:
- Stockez la commande dans une sorte de système back-end tiers (tel que SAP)
- Envoyez un email au client pour l'informer de sa commande
Pour ce faire, votre code d'application publierait un message dans une file d'attente JMS comprenant un identifiant de commande. Une partie de votre application écoutant la file d'attente peut répondre à l'événement en prenant le orderId, en recherchant l'ordre dans la base de données, puis en plaçant cet ordre auprès d'un autre système tiers. Une autre partie de votre application peut être chargée de prendre le orderId et d'envoyer un email de confirmation au client.
Utilisez-les à tout moment pour traiter de manière asynchrone des opérations de longue durée. Un utilisateur Web ne voudra pas attendre plus de 5 secondes pour qu'une demande soit traitée. Si vous en avez un qui dure plus longtemps, une conception consiste à envoyer la demande à une file d'attente et à renvoyer immédiatement une URL que l'utilisateur peut vérifier pour voir quand le travail est terminé.
Publier/souscrire est une autre technique efficace pour découpler les expéditeurs de nombreux destinataires. C'est une architecture flexible, car les abonnés peuvent aller et venir au besoin.
J'ai eu tellement d'utilisations étonnantes pour JMS:
Communication par chat Web pour le service client.
Débogage de la journalisation sur le backend. Tous les serveurs d'applications ont diffusé des messages de débogage à différents niveaux. Un client JMS peut ensuite être lancé pour surveiller les messages de débogage. Bien sûr, j'aurais pu utiliser quelque chose comme syslog , mais cela m'a donné toutes sortes de façons de filtrer la sortie en fonction d'informations contextuelles (nom de serveur d'application, appel d'api, niveau de journalisation, ID utilisateur, type de message , etc...). J'ai aussi colorisé la sortie.
Débogage de la journalisation dans un fichier. Comme ci-dessus, seules des pièces spécifiques ont été extraites à l'aide de filtres et enregistrées dans un fichier pour une journalisation générale.
Alerte Encore une fois, une configuration similaire à la journalisation ci-dessus, surveillant les erreurs spécifiques et alertant les gens par différents moyens (email, SMS, messagerie instantanée, Growl pop-up ...)
Configuration et contrôle dynamiques des clusters de logiciels. Chaque serveur d'application diffuserait un message "Configurez-moi", puis un démon de configuration qui répondrait avec un message contenant toutes sortes d'informations de configuration. Plus tard, si tous les serveurs d'applications devaient modifier leurs configurations en même temps, cela pourrait être fait à partir du démon de configuration.
Et les transactions habituelles en file d'attente pour les activités retardées telles que la facturation, le traitement des commandes, le provisioning, la génération d'e-mails, etc.
C’est génial partout où vous voulez garantir la livraison des messages de manière asynchrone.
Calcul distribué (a) synchrone.
Un exemple concret pourrait être un cadre de notification à l’échelle de l’application, qui envoie des courriers aux parties prenantes à différents moments de l’utilisation de l’application. Donc, l’application agirait comme un Producer en créant un objet Message, en le plaçant sur un Queue particulier et en allant de l’avant.
Il y aurait un ensemble de Consumers qui souscriraient au Queue en question et s'occuperaient de la gestion du Message envoyé. Notez qu'au cours de cette transaction, les Producers sont découplés de la logique de traitement d'un Message donné.
Les infrastructures de messagerie (ActiveMQ et autres) agissent comme une épine dorsale pour faciliter ce type de transaction Message en fournissant MessageBrokers.
Je l'ai utilisé pour envoyer des transactions intrajournalières entre différents systèmes de gestion de fonds. Si vous souhaitez en savoir plus sur la qualité de la messagerie technologique, je vous recommande vivement le livre " Modèles d'intégration d'entreprise ". Il existe des exemples JMS pour des éléments tels que demande/réponse et publication/abonnement.
La messagerie est un excellent outil d'intégration.
Nous l'utilisons pour lancer un traitement asynchrone que nous ne voulons ni interrompre ni entrer en conflit avec une transaction existante.
Par exemple, disons que vous avez une logique coûteuse et très importante comme "acheter des objets", une partie importante de ces achats serait "avertir magasin de produits". Nous faisons l’appel de notification de manière asynchrone, de sorte que la logique/le traitement impliqué dans l’appel de notification ne bloque pas les ressources avec la logique d’achat, ni ne les conteste. Résultat final, achat terminé, utilisateur satisfait, nous récupérons notre argent et, comme la livraison est garantie, le magasin en est informé dès son ouverture ou dès qu’un nouvel article est dans la file.
Je l'ai utilisé pour mon projet académique qui était un site Web de vente au détail en ligne similaire à Amazon. JMS était utilisé pour gérer les fonctionnalités suivantes:
- Mettez à jour la position des commandes passées par les clients, au fur et à mesure que l'expédition se déplace d'un endroit à un autre. Cela a été fait en envoyant en continu des messages à la file d'attente JMS.
- Alerte sur des événements inhabituels tels qu'un envoi retardé, puis envoi d'un courrier électronique au client.
- Si la livraison est atteinte sa destination, l'envoi d'un événement de livraison.
Nous avons également implémenté plusieurs clients distants connectés au serveur principal. Si la connexion est disponible, ils utilisent pour accéder à la base de données principale ou s'ils n'utilisent pas leur propre base de données. Afin de gérer la cohérence des données, nous avions implémenté le mécanisme 2PC. Pour cela, nous avons utilisé JMS pour échanger les messages entre ces systèmes, c’est-à-dire un coordinateur qui lancera le processus en envoyant un message dans la file d’attente et les autres répondront en conséquence en renvoyant un message dans la file d’attente. Comme d’autres l’ont déjà mentionné, c’était similaire au modèle pub/sub.
J'ai vu JMS utilisé dans différents projets commerciaux et académiques. JMS peut facilement entrer dans votre image, chaque fois que vous souhaitez disposer de systèmes distribués totalement découplés. En règle générale, lorsque vous devez envoyer votre demande depuis un nœud et que quelqu'un de votre réseau s'en charge, sans donner/à l'expéditeur aucune information sur le destinataire.
Dans mon cas, j’ai utilisé JMS pour développer un middleware orienté message (MOM) dans ma thèse, où des types spécifiques d’objets orientés objet sont générés d’un côté comme votre demande, puis compilés et exécutés de l’autre comme réponse. .
Apache Camel utilisé avec ActiveMQ est un excellent moyen de créer des modèles d'intégration d'entreprise
Nous avons utilisé la messagerie pour générer des devis en ligne
Nous utilisons JMS pour la communication avec les systèmes d'un grand nombre de sites distants sur des réseaux peu fiables. Le couplage lâche, associé à une messagerie fiable, crée un paysage système stable: chaque message sera envoyé dès que cela sera techniquement possible, de plus gros problèmes de réseau n'auront aucune influence sur le paysage système complet ...