à quoi sert JMS? [fermé]

Question

Je recherche 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-là. Dans le passé, j’utilisais simplement la base de données pour transmettre des messages de A à B lorsque le message ne peut pas nécessairement être traité immédiatement par B.

Un exemple hypothétique d'un tel système est celui où tous les nouveaux utilisateurs enregistrés devraient recevoir un courrier électronique de bienvenue dans les 24 heures suivant leur inscription. Par souci d'argument, supposons que la base de données n'enregistre pas l'heure à laquelle chaque utilisateur est enregistré, mais une référence (clé étrangère) à chaque nouvel utilisateur est stockée dans la table waiting_email. Le travail d'envoi de courrier électronique s'exécute une fois toutes les 24 heures, envoie un courrier électronique à tous les utilisateurs de cette table, puis supprime tous les enregistrements en attente.

Cela semble être le genre de problème pour lequel JMS devrait être utilisé, mais j’ignore 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 de messages JMS peuvent également être persistées, mais dans ce cas, il semble y avoir peu de différence entre JMS et la "base de données en tant que file d'attente de messages". approche que j'ai décrite?

Qu'est-ce qui me manque? - Don

Answer 1

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

• publier et vous abonner (envoyer un message à autant de consommateurs que cela intéresse - un peu comme envoyer un email à une liste de diffusion, l'expéditeur n'a pas besoin de savoir qui est abonné
• Equilibrage de charge fiable hautes performances (files de messages)

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

Le cas dont vous parlez est le deuxième cas, dans lequel vous pouvez effectivement utiliser une table de base de données pour simuler une file de messages.

La principale différence est qu'une file de messages JMS réside dans un équilibreur de charge hautement concurrentiel hautement performant, conçu pour un débit énorme; vous pouvez généralement envoyer des dizaines de milliers de messages par seconde à plusieurs consommateurs simultanés dans de nombreux processus et threads. La raison en est qu’une file de messages est fondamentalement hautement asynchrone - un Un bon fournisseur JMS transmettra les messages à l'avance à chaque consommateur afin que des milliers de messages puissent être traités dans la RAM dès qu'un consommateur est disponible. Cela conduit à 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:)

Lors de l'utilisation d'une table de base de données, un thread a généralement tendance à verrouiller l'ensemble de la table, ce qui vous permet d'obtenir un débit très faible lorsque vous essayez d'implémenter un équilibreur de charge hautes performances.

Mais, comme la plupart des intergiciels, tout dépend de ce dont vous avez besoin. 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 en file d'attente. Toutefois, si vous avez besoin d’une faible latence et d’un débit élevé, les files d’attente JMS sont vivement recommandées.

Answer 2

À mon avis, JMS et d'autres systèmes basés sur la messagerie sont destinés à résoudre les problèmes nécessitant:

• Communications asynchrones : une application doit notifier à une autre qu'un événement s'est produit sans qu'il soit nécessaire d'attendre une réponse.
• Fiabilité . Assurer la livraison d'un message une fois pour toutes. Avec votre approche DB, vous devez "réinventer la roue", en particulier si plusieurs clients lisent les messages.
• Couplage lâche . Tous les systèmes ne peuvent pas communiquer à l'aide d'une base de données. JMS est donc très utile pour être utilisé dans des environnements hétérogènes avec des systèmes découplés pouvant communiquer au-delà des limites du système.

Answer 3

L'implémentation JMS est "push", en ce sens que vous n'avez pas à interroger la file d'attente pour découvrir de nouveaux messages, mais que vous enregistrez un rappel qui est appelé dès qu'un nouveau message arrive.

Answer 4

pour adresser le commentaire d'origine. ce qui a été décrit à l’origine est l’essentiel de JMS (point à point). Les avantages de JMS sont toutefois les suivants:

1. vous n'avez pas besoin d'écrire le code vous-même (et éventuellement de foirer la logique pour qu'elle ne soit pas aussi persistante que vous le pensez). De plus, l'implication de tiers pourrait être plus évolutive qu'une simple approche de base de données.

2. jms gère la publication / la souscription, 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 l'échanger si vos besoins changent à l'avenir, sans modifier votre code java.

Answer 5

Un des avantages de JMS est de permettre le traitement asynchrone, qui peut également être effectué par une solution de base de données. Cependant, certains autres avantages de la solution JMS par rapport à la base de données sont les suivants

a) Le consommateur du message peut être dans un emplacement distant. Exposer la base de données pour un accès à distance est dangereux. Vous pouvez contourner ce problème en fournissant un service supplémentaire pour la lecture des messages de la base de données, ce qui nécessite davantage d'effort.

b) Dans le cas d'une base de données, le consommateur de messages doit l'interroger à la recherche de messages pour lesquels JMS fournit un rappel lorsqu'un message est arrivé (comme indiqué par sk)

c) Équilibrage de la charge: s'il y a beaucoup de messages, il est facile de disposer d'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 route de la base de données

Answer 6

JMS est une API utilisée pour transférer des messages entre deux clients ou plus. Ses spécifications sont définies dans JSR 914.

  

Le principal avantage de JMS réside dans la nature découplée des entités en communication: l'expéditeur n'a pas besoin d'informations sur les destinataires. Parmi les autres avantages, citons la possibilité d’intégrer des plates-formes hétérogènes, de réduire les goulots d’étranglement du système, d’accroître l’extensibilité et de réagir plus rapidement aux changements.

Les JMS ne sont qu'un type d'interface / API et les classes concrètes doivent être implémentées. Celles-ci sont déjà implémentées par diverses organisations / fournisseurs. ils sont appelés fournisseurs JMS. Exemple: WebSphere d'IBM ou FioranoMQ de Fiorano Software ou ActiveMQ de Apache, HornetQ, OpenMQ, etc. Les autres terminologies utilisées sont les objets d'administration (rubriques, files d'attente, objets de connexion), le producteur / éditeur JMS, le client JMS et le message lui-même.

J'en viens à votre question - à quoi sert JMS? J'aimerais donner un exemple concret pour illustrer son importance.

Day Trading

Cette fonctionnalité appelée LVC (cache de dernière valeur)

Les prix des actions In Trading sont publiés par un éditeur à intervalles réguliers. Chaque partage a un sujet associé sur lequel il est publié. Maintenant, si vous savez ce qu'est un sujet, vous devez savoir que les messages ne sont pas enregistrés comme des files d'attente. Les messages sont publiés pour les abonnés vivants au moment de la publication du message (Exception étant les abonnés Durables qui obtiennent tous les messages publiés depuis le moment de sa création, mais nous ne souhaitons pas non plus obtenir des cours de bourse trop anciens, ce qui écarte la En l'utilisant). Donc, si un client veut connaître le prix d'une action, il crée un souscripteur et doit attendre la publication du prochain cours (ce qui n'est pas ce que nous souhaitons). C'est là qu'intervient LVC. Chaque message LVC a une clé associée. Si un message est envoyé avec une clé LVC (pour un stock particulier), puis un autre message de mise à jour avec la même clé, le dernier remplace le précédent. Lorsqu'un abonné s'abonne à une rubrique (pour laquelle LVC est activé), il reçoit tous les messages avec des clés LVC distinctes. Si nous conservons une clé distincte par société cotée en bourse, lorsque le client s’y abonnera, il obtiendra le dernier cours de bourse et éventuellement toutes les mises à jour.

Bien sûr, c’est l’un des facteurs autres que la fiabilité, la sécurité, etc., qui rend JMS si puissant.

Answer 7

Guido a la définition complète. D'après mon expérience, tout cela est important pour un bon ajustement.

L’une des utilisations que j’ai vues est la distribution des commandes dans les entrepôts. Imaginez une entreprise de fournitures de bureau qui compte un grand nombre d'entrepôts et qui fournit des fournitures de bureau aux grands bureaux. Ces commandes arriveraient dans un emplacement central et seraient ensuite groupées pour le bon entrepôt à distribuer. Les entrepôts n’ont pas ou ne veulent pas de connexions à haut débit dans la plupart des cas. Les commandes leur sont alors envoyées via des modems commutés. C’est là que les lignes asynchrones entrent en jeu. Les lignes téléphoniques n’ont pas vraiment cette importance, de sorte que la moitié des commandes peuvent entrer et c’est là que la fiabilité est importante.

Answer 8

Le principal avantage est de découpler des systèmes indépendants, plutôt que de leur faire partager des bases de données communes ou créer des services personnalisés pour la transmission de données.

Les banques en sont un exemple frappant, la messagerie intra-journalière étant utilisée pour transmettre les modifications de données en temps réel au fur et à mesure qu'elles se produisent. Il est très facile pour le système source d'envoyer un message "par-dessus le mur"; L'inconvénient est qu'il y a très peu de contrats entre ces systèmes et que l'hospitalisation est normalement appliquée du côté du consommateur. Il est presque trop couplé.

Le support JMS prêt à l'emploi pour de nombreux serveurs d'applications, etc., ainsi que tous les outils nécessaires: durabilité, surveillance, génération de rapports et limitation, constituent d'autres avantages.

Answer 9

Voici un bel article avec quelques exemples ici: http: //www.winslam .com / laramee / jms / index.html

Answer 10

La solution "base de données en tant que file d'attente de messages" peut s'avérer lourde pour la tâche. La solution JMS est moins étroitement liée en ce sens que l'expéditeur du message n'a pas besoin de connaître le destinataire. Cela pourrait être accompli avec une abstraction supplémentaire dans la "base de données en tant que file d'attente", pour que ce ne soit pas un gain énorme ... De plus, vous pouvez utiliser la file d'attente de manière "publier et souscrire", ce qui peut être pratique selon ce que vous faites. vous essayez d'accomplir. C'est également un bon moyen de découpler davantage vos composants. Si toutes vos communications se font au sein d'un même système et / ou si un journal immédiatement disponible pour une application est très important, votre méthode semble bonne. Si vous communiquez entre des systèmes distincts, JMS est un bon choix.

Answer 11

JMS en combinaison avec JTA (API Java Transaction) et JPA (API de persistance Java) peut être très utile. Avec une simple annotation, vous pouvez mettre plusieurs actions de base de données + envoi / réception de message dans la même transaction. Donc, si l'un d'entre eux échoue, tout est annulé en utilisant le même mécanisme de transaction.