à quoi sert JMS?
Je cherche des exemples (simples) de problèmes pour lesquels JMS est une bonne solution, et aussi des 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 passer 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 e-mail 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 s'est enregistré, mais à la place une référence (clé étrangère) à chaque nouvel utilisateur est stockée dans la table en attente_email. Le travail d'expéditeur de courrier électronique s'exécute une fois toutes les 24 heures, envoie un courrier électronique à tous les utilisateurs de ce tableau, puis supprime tous les enregistrements de messagerie en attente.
Cela semble être le genre de problème pour lequel JMS devrait être utilisé, mais je ne vois pas clairement quel avantage JMS aurait par rapport à l'approche que j'ai décrite. Un avantage de l'approche DB est que les messages sont persistants. Je comprends que les files d'attente de messages JMS peuvent également être persistées, mais dans ce cas, il semble y avoir peu de différence entre JMS et l'approche "base de données en tant que file d'attente de messages" que j'ai décrite?
Qu'est-ce que je rate? - Don
JMS et la messagerie, c'est vraiment 2 choses totalement différentes.
- publier et s'abonner (envoyer un message au plus grand nombre de consommateurs intéressés - un peu comme envoyer un e-mail à une liste de diffusion, l'expéditeur n'a pas besoin de savoir qui est abonné
- équilibrage de charge fiable haute performance (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 un peu une file d'attente de messages.
La principale différence est que la file d'attente de messages JMS est un équilibreur de charge hautement simultané hautes performances conçu pour un débit énorme; vous pouvez généralement envoyer des dizaines de milliers de messages par seconde à de nombreux consommateurs simultanés dans de nombreux processus et threads. La raison en est qu'une file d'attente de messages est fondamentalement très asynchrone - a n bon fournisseur JMS diffusera des messages à l'avance à chaque consommateur afin qu'il y ait des milliers de messages disponibles à traiter en 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 :)
Lorsque vous utilisez une table de base de données, un thread a généralement tendance à verrouiller toute la table, vous avez donc tendance à obtenir un débit très faible lorsque vous essayez d'implémenter un équilibreur de charge hautes performances.
Mais comme la plupart des middlewares, 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 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.
À mon avis, JMS et d'autres systèmes basés sur des messages sont destinés à résoudre des problèmes qui nécessitent:
- Asynchronous communications: Une application doit informer une autre qu'un événement s'est produit sans avoir besoin d'attendre une réponse.
- Fiabilité. Assurer une remise de message unique et unique. Avec votre approche DB, vous devez "réinventer la roue", surtout 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 assez bon pour être utilisé dans des environnements hétérogènes avec des systèmes découplés qui peuvent communiquer au-delà des limites du système.
L'implémentation JMS est "Push", dans le sens où vous n'avez pas à interroger la file d'attente pour découvrir de nouveaux messages, mais vous enregistrez un rappel qui est appelé dès qu'un nouveau message arrive.
Un avantage de JMS est d'activer le traitement asynchrone qui peut également être effectué par la solution de base de données. Cependant, voici quelques autres avantages de JMS par rapport à la solution de base de données
a) Le consommateur du message peut se trouver dans un endroit éloigné. L'exposition de la base de données pour l'accès à distance est dangereuse. Vous pouvez contourner cela en fournissant un service supplémentaire pour lire les messages de la base de données, ce qui nécessite plus d'efforts.
b) Dans le cas de la base de données, le consommateur de messages doit interroger la base de données pour les messages où JMS fournit un rappel lorsqu'un message est arrivé (comme mentionné ci-dessus)
c) Équilibrage de charge - s'il y a beaucoup de messages à venir, 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 nécessitera moins d'efforts que la route de la base de données
pour répondre au commentaire d'origine. ce qui a été décrit à l'origine est l'essentiel de JMS (point à point). les avantages de JMS sont cependant:
vous n'avez pas besoin d'écrire le code vous-même (et peut-être de bousiller la logique pour qu'elle ne soit pas aussi persistante que vous le pensez). en outre, un implément tiers peut être plus évolutif qu'une approche de base de données simple.
jms gère la publication/l'abonnement, ce qui est un peu plus compliqué que l'exemple point à point que vous avez donné
vous n'êtes pas lié à une implémentation spécifique et pouvez l'échanger si vos besoins changent à l'avenir, sans déconner avec votre Java.
JMS est une API utilisée pour transférer des messages entre deux ou plusieurs clients. Ses spécifications sont définies sous JSR 914.
Le principal avantage de JMS est la nature découplée des entités communicantes - l'expéditeur n'a pas besoin d'avoir des informations sur les récepteurs. Les autres avantages incluent la possibilité d'intégrer des plates-formes hétérogènes, de réduire les goulots d'étranglement du système, d'augmenter l'évolutivité et de réagir plus rapidement aux changements.
Les JMS ne sont que des interfaces/API et les classes concrètes doivent être implémentées. Ceux-ci sont déjà mis en œuvre par diverses organisations/fournisseurs. ils sont appelés fournisseurs JMS. L'exemple est WebSphere par IBM ou FioranoMQ par Fiorano Softwares ou ActiveMQ par Apache, HornetQ, OpenMQ etc. Les autres terminologies utilisées sont des objets d'administration (sujets, files d'attente, usines de connexion), JMS producteur/éditeur, client JMS et le message lui-même.
Pour en venir à votre question - what is JMS good for? Je voudrais donner un exemple pratique pour illustrer son importance.
Day Trading
Il y a cette fonctionnalité appelée LVC (dernier cache de valeur)
En cours de bourse, les prix des actions sont publiés par un éditeur à intervalles réguliers. Chaque partage a un sujet associé dans 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 où le message a été publié (exception étant les abonnés Durables qui reçoivent tous les messages publiés à partir du moment où il a été créé, mais là encore, nous ne voulons pas obtenir des prix des actions trop anciens qui écartent la possibilité de En l'utilisant). Donc, si un client veut connaître un cours boursier, il crée un abonné et il doit ensuite attendre la publication du prochain cours boursier (ce qui n'est pas encore ce que nous voulons). C'est là que LVC entre en scène. 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. Chaque fois qu'un abonné s'abonne à un sujet (sur lequel LVC est activé), l'abonné recevra tous les messages avec des clés LVC distinctes. Si nous conservons une clé distincte par société cotée, lorsque le client y souscrira, il obtiendra le dernier cours de l'action 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.
Il y a un bon article avec quelques exemples ici: http://www.winslam.com/laramee/jms/index.html
Guido a la définition complète. D'après mon expérience, tous ces éléments sont importants pour un bon ajustement.
L'une des utilisations que j'ai vues concerne la distribution de commandes dans les entrepôts. Imaginez une entreprise de fournitures de bureau qui possède un bon nombre d'entrepôts qui approvisionnent les grands bureaux en fournitures de bureau. Ces commandes arrivaient dans un emplacement central et étaient ensuite regroupées pour que l'entrepôt correct soit distribué. Les entrepôts n'ont pas ou ne veulent pas de connexions à haut débit dans la plupart des cas, donc les commandes leur sont envoyées via des modems commutés et c'est là qu'intervient l'asynchrone. Les lignes téléphoniques ne sont pas vraiment importantes non plus, donc la moitié des commandes peuvent arriver et c'est là que la fiabilité est importante.
Le principal avantage est de découpler les systèmes indépendants plutôt que de les faire partager des bases de données communes ou de créer des services personnalisés pour transmettre les données.
Les banques en sont un bon exemple, la messagerie intrajournalière étant utilisée pour transmettre les modifications des données en direct au fur et à mesure qu'elles se produisent. Il est très facile pour le système source de lancer un message "par-dessus le mur"; l'inconvénient est qu'il y a très peu de contrats entre ces systèmes, et vous voyez normalement l'hospitalisation mise en œuvre du côté du consommateur. Il est presque trop mal couplé.
D'autres avantages sont liés à la prise en charge de JMS prête à l'emploi pour de nombreux serveurs d'applications, etc. et à tous les outils qui l'entourent: durabilité, surveillance, génération de rapports et limitation.
JMS en combinaison avec JTA (Java Transaction API) et JPA (Java persistence API) 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'eux échoue, tout est annulé en utilisant le même mécanisme de transaction.
La solution "base de données en tant que file d'attente de messages" peut être lourde pour la tâche. La solution JMS est moins étroitement couplée en ce sens que l'expéditeur du message n'a pas besoin de connaître quoi que ce soit sur le destinataire. Cela pourrait être accompli avec une abstraction supplémentaire dans la `` base de données en tant que file d'attente de messages '', de sorte que ce n'est pas une énorme victoire ... vous essayez d'accomplir. C'est aussi une belle façon de découpler davantage vos composants. Si toute votre communication se fait dans un seul 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.