A quoi sert JMS ?

Question

Je cherche des exemples (simples) de problèmes pour lesquels JMS est une bonne solution, ainsi que les raisons pour lesquelles JMS est une bonne solution dans ces cas. Dans le passé, j'ai simplement utilisé la base de données comme moyen de transmettre des messages de A à B lorsque le message ne peut pas nécessairement être traité par B immédiatement.

Un exemple hypothétique d'un tel système est celui où tous les utilisateurs nouvellement enregistrés devraient recevoir un courriel de bienvenue dans les 24 heures suivant leur inscription. Pour les besoins de l'argumentation, supposons que la base de données n'enregistre pas l'heure d'enregistrement de chaque utilisateur, mais qu'une référence (clé étrangère) à chaque nouvel utilisateur soit stockée dans la table pending_email. La tâche d'envoi d'e-mail s'exécute toutes les 24 heures, envoie un e-mail à tous les utilisateurs de cette table, puis supprime tous les enregistrements de la table pending_email.

Cela semble être le genre de problème pour lequel JMS devrait être utilisé, mais je ne vois pas bien quel avantage JMS aurait par rapport à l'approche que j'ai décrite. L'un des avantages de l'approche DB est que les messages sont persistants. Je comprends que les files d'attente de messages JMS peuvent également être persistantes, mais dans ce cas, il semble y avoir peu de différence entre JMS et l'approche " base de données comme file d'attente de messages " que j'ai décrite ?

Qu'est-ce que je rate ? - Don

Answer 1

JMS et la messagerie sont en fait deux choses totalement différentes.

• publier et s'abonner (envoi d'un message à autant de consommateurs qu'ils sont intéressés - un peu comme l'envoi d'un courriel à une liste de diffusion, l'expéditeur n'a pas besoin de savoir qui est abonné).
• équilibrage de charge fiable et performant (files d'attente de messages)

Voir plus d'informations sur comment une file d'attente se compare à un sujet

Le cas dont vous parlez est le deuxième cas, où oui, vous pouvez utiliser une table de base de données pour simuler une file d'attente de messages.

La principale différence est qu'une file d'attente de messages JMS est un équilibreur de charge très performant et hautement concurrent, conçu pour un débit énorme ; vous pouvez envoyer des dizaines de milliers de messages par seconde à de nombreux consommateurs concurrents dans de nombreux processus et threads. Cela s'explique par le fait qu'une file d'attente de messages est fondamentalement très asynchrone. Un bon fournisseur JMS transmet les messages à l'avance à chaque consommateur. de sorte qu'il y a des milliers de messages disponibles pour être traités en RAM dès qu'un consommateur est disponible. Il en résulte un débit massif et une latence très faible.

Par exemple, imaginez écrire un équilibreur de charge web en utilisant une table de base de données :)

Lorsqu'on utilise une table de base de données, un seul thread a tendance à verrouiller l'ensemble de la table. On obtient donc un débit très faible lorsqu'on essaie de mettre en œuvre un équilibreur de charge performant.

Mais comme la plupart des intergiciels, tout dépend de vos besoins ; si vous avez un système à faible débit avec seulement quelques messages par seconde, n'hésitez pas à utiliser une table de base de données comme file d'attente. Mais si vous avez besoin d'une faible latence et d'un débit élevé, les files d'attente JMS sont fortement recommandées.

Answer 2

À mon avis, JMS et les autres systèmes basés sur les messages sont destinés à résoudre les problèmes qui en ont besoin :

• Asynchrone communications : Une application doit informer une autre qu'un événement s'est produit sans avoir besoin d'attendre une réponse.
• Fiabilité . Assurer la livraison des messages une fois et une seule. Avec votre approche DB, vous devez "réinventer la roue", surtout si vous avez plusieurs clients qui lisent les messages.
• Accouplement libre . Tous les systèmes ne peuvent pas communiquer en utilisant une base de données. JMS peut donc être utilisé dans des environnements hétérogènes avec des systèmes découplés qui peuvent communiquer au-delà des frontières du système.

Answer 3

L'implémentation de JMS est "push", dans le sens où vous n'avez pas à interroger la file d'attente pour découvrir les nouveaux messages, mais vous enregistrez un callback qui est appelé dès qu'un nouveau message arrive.

Answer 4

Pour répondre au commentaire initial, ce qui a été décrit à l'origine est l'essentiel du JMS (point à point) :

1. vous n'avez pas besoin d'écrire le code vous-même (et peut-être de bousiller la logique de sorte qu'elle ne soit pas aussi persistante que vous le pensez). de plus, l'implémentation par un tiers peut être plus évolutive que l'approche par base de données simple.

2. jms gère la publication et l'abonnement, ce qui est un peu plus compliqué que l'exemple point à point que vous avez donné.

3. vous n'êtes pas lié à une implémentation spécifique et vous pouvez la remplacer si vos besoins changent à l'avenir, sans avoir à modifier votre code Java.

Answer 5

L'un des avantages de JMS est de permettre un traitement asynchrone qui peut également être effectué par une solution de base de données. Cependant, voici quelques autres avantages de JMS par rapport aux solutions de bases de données

a) Le consommateur du message peut se trouver dans un endroit éloigné. Il est dangereux d'exposer la base de données à un accès distant. Vous pouvez contourner ce problème en fournissant un service supplémentaire pour lire les messages de la base de données, mais cela demande plus d'efforts.

b) Dans le cas d'une base de données, le consommateur de messages doit interroger la base de données pour obtenir des messages, alors que JMS fournit un rappel lorsqu'un message est arrivé (comme indiqué ci-dessus).

c) Équilibrage de la charge - si beaucoup de messages arrivent, il est facile d'avoir un pool de processeurs de messages dans JMS.

d) En général, la mise en œuvre via JMS sera plus simple et demandera moins d'efforts que la voie de la base de données.