A 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 firebase database pour transmettre des messages de A à B lorsque le message ne doit pas nécessairement être traité immédiatement par B.

Un exemple hypothétique d’un tel système est celui où tous les utilisateurs nouvellement enregistrés doivent recevoir un courrier électronique de bienvenue dans les 24 heures suivant leur inscription. Par souci d’argument, supposons que la firebase database 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 pending_email. Le travail d’expéditeur du courrier électronique s’exécute une fois toutes les 24 heures, envoie un message électronique à tous les utilisateurs de cette table, puis supprime tous les enregistrements pending_email.

Cela semble être le type de problème pour lequel JMS devrait être utilisé, mais je ne vois pas clairement quels avantages JMS aurait par rapport à l’approche que j’ai décrite. L’un des avantages de l’approche de la firebase database est que les messages sont persistants. Je comprends que les files d’attente de messages JMS peuvent également être conservées, mais dans ce cas, il semble y avoir peu de différence entre JMS et l’approche “firebase database en tant que queue” que j’ai décrite?

Qu’est-ce que je rate? – Don

JMS et la messagerie sont vraiment deux 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 email à une liste de diffusion, l’expéditeur n’a pas besoin de savoir qui est abonné)
  • équilibrage de charge fiable et à hautes performances (files d’attente de messages)

Voir plus d’informations sur la façon dont une queue se compare à un sujet

Le cas dont vous parlez est le second, où vous pouvez utiliser une table de firebase database pour simuler une queue de messages.

La principale différence est qu’une file de messages JMS est un équilibreur de charge hautement concurrentiel à hautes performances conçu pour un débit élevé; Vous pouvez 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 de messages est fondamentalement asynchrone: un bon fournisseur JMS diffusera des messages à l’avance à chaque consommateur, de sorte que des milliers de messages soient disponibles pour ê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.

imaginez par exemple écrire un équilibreur de charge Web en utilisant une table de firebase database 🙂

Lors de l’utilisation d’une table de firebase database, un thread a généralement tendance à verrouiller l’intégralité de la table, de sorte que vous avez 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 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 firebase database en tant que queue. Mais si vous avez besoin d’une faible latence et d’un haut débit, 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:

  • Communications asynchrones : une application doit notifier à un autre qu’un événement s’est produit sans avoir à attendre une réponse.
  • Fiabilité Assurer la livraison d’une seule fois et unique des messages. 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 en utilisant une firebase database. JMS est donc très utile pour être utilisé dans des environnements hétérogènes avec des systèmes découplés capables de communiquer via les frontières du système.

L’implémentation JMS est “push”, dans le sens où vous n’avez pas à interroger la queue pour découvrir de nouveaux messages, mais vous enregistrez un rappel qui est appelé dès qu’un nouveau message arrive.

pour répondre au commentaire original. Ce qui a été décrit à l’origine est l’essentiel du 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 bousiller la logique pour que ce ne soit pas aussi persistant que vous le pensez). En outre, les applications tierces pourraient être plus évolutives que l’approche de firebase database simple.

  2. jms gère la publication / abonnement, ce qui est un peu plus compliqué que l’exemple 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 vous soucier de votre code Java.

L’un des avantages de JMS est de permettre un traitement asynchrone, qui peut également être effectué par une solution de firebase database. Cependant, voici quelques autres avantages de JMS sur la solution de firebase database

a) Le consommateur du message peut se trouver dans un emplacement distant. La firebase database d’exposition pour l’access à distance est dangereuse. Vous pouvez résoudre ce problème en fournissant un service supplémentaire pour la lecture des messages à partir de la firebase database, ce qui nécessite davantage d’efforts.

b) Dans le cas d’une firebase database, le consommateur de messages doit interroger la firebase database pour rechercher des messages où JMS fournit un rappel lorsqu’un message est reçu (comme mentionné par sk).

c) Équilibrage de la 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, l’implémentation via JMS sera plus simple et nécessitera moins d’effort que la route de la firebase database

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

L’une des utilisations que j’ai vues concerne la dissortingbution de commandes dans les entrepôts. Imaginez une entreprise de fournitures de bureau qui possède un bon nombre d’entrepôts qui fournissent des fournitures de bureau aux grands bureaux. Ces commandes arriveraient dans un endroit central et seraient ensuite regroupées pour le bon entrepôt à dissortingbuer. Dans la plupart des cas, les entrepôts n’ont pas ou ne veulent pas de connexions à haut débit, donc les commandes leur sont transmises via des modems téléphoniques. C’est là qu’intervient le mode asynchrone. c’est là que la fiabilité est importante.

Le principal avantage est le découplage des systèmes non liés plutôt que le partage de bases de données communes ou la création de services personnalisés pour transmettre des données.

Les banques en sont un exemple, la messagerie intra-journalière étant utilisée pour transmettre les changements de données en direct à mesure qu’elles se produisent. Il est très facile pour le système source de lancer un message “over the wall”; L’inconvénient, c’est qu’il y a très peu de contrats entre ces systèmes, et vous voyez normalement une hospitalisation du côté du consommateur. C’est couplé presque trop librement.

Les autres avantages sont la prise en charge de JMS prête à l’emploi pour de nombreux serveurs d’applications, etc., ainsi que tous les outils connexes: durabilité, surveillance, création de rapports et limitation.

Il y a une belle description avec quelques exemples ici: http://www.winslam.com/laramee/jms/index.html

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

 The major advantage of JMS is the decoupled nature of communicating entities - Sender need not have information about the receivers.Other advantages include the ability to integrate heterogeneous platforms, reduce system bottlenecks, increase scalability, and respond more quickly to change. 

Les JMS ne sont que des interfaces / API et les classes concrètes doivent être implémentées. Celles-ci sont déjà mises en œuvre par diverses organisations / fournisseurs. ils sont appelés fournisseurs JMS. Exemple: WebSphere par IBM ou FioranoMQ par les logiciels Fiorano ou ActiveMQ par Apache, HornetQ, OpenMQ, etc.

Donc, pour en venir à votre question, à what is JMS good for? Je voudrais donner un exemple pratique pour illustrer son importance.

Transactions du jour

Il y a cette fonctionnalité appelée LVC (cache de dernière valeur)

Dans Trading, les cours des actions sont publiés par un éditeur à intervalles réguliers. Chaque partage est associé à une rubrique à laquelle 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 sur les abonnés vivants au moment de la publication du message (les abonnés à Exception étant Durables reçoivent tous les messages publiés à partir du moment où ils ont été créés, mais nous ne voulons pas non plus En l’utilisant). Donc, si un client veut connaître un cours de bourse, il crée un souscripteur, puis il doit attendre la publication du prochain cours de bourse (ce qui n’est pas encore ce que nous voulons). 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. 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, le client recevra le dernier cours 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.

La solution «firebase database en tant que queue de messages» peut être lourde pour la tâche. La solution JMS est moins étroitement liée, car 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 firebase database en tant que queue de messages, donc ce n’est pas un gros gain … En outre, vous pouvez utiliser la file dans une méthode de publication et d’abonnement qui peut être utile vous essayez d’accomplir C’est aussi un bon moyen de découpler vos composants. Si toutes vos communications se trouvent 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.

JMS en combinaison avec JTA (Java Transaction API) et JPA (Java persistence API) peut être très utile. Avec une simple annotation, vous pouvez placer plusieurs actions de firebase database + envoi / réception de messages 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.