Comment JMS Receive fonctionne-t-il en interne?
J'ai étudié diverses technologies/architectures/modèles/implémentations de communication (mots à la mode), notamment les services Web (WCF, Axis2), ESB, SOA, et je voulais en savoir plus sur JMS en matière de messagerie.
Conceptuellement, JMS semble simple. Mon point de vue est que c'est un courtier intermédiaire qui gère les messages des éditeurs et les achemine vers les abonnés appropriés. Cela se fait en mettant en file d'attente les messages au fur et à mesure qu'ils sont publiés et en les mettant en file d'attente à la réception.
Question 1: Ma compréhension de base de JMS est-elle correcte?
Une des choses qui me dérange en lisant sur les technologies, c’est quand un certain niveau d’agitation manuelle (intentionnelle ou non) est appliqué à une fonctionnalité.
D'après mes connaissances de base, un fournisseur JMS doit être en cours d'exécution pour pouvoir envoyer ou recevoir des messages. Mon hypothèse de publication est que le fournisseur JMS attend simplement la publication d’un message, puis le stocke dans une file d’attente (sauvegardée en mémoire ou sur une base de données, selon l’implémentation). Cependant, je ne sais pas trop comment recevoir fonctionne.
Question 2: Est-ce que recevoir (généralement) bloque si aucun message n'est disponible?
Question 2b: Si oui, comment le blocage est-il obtenu? Le client interroge-t-il continuellement les messages? Est-ce que le serveur ne répond simplement pas jusqu'à ce qu'un message soit publié (comment cela fonctionne-t-il sans expiration du délai?) Le fournisseur initie-t-il un appel au destinataire?
Question 2c: Si non, comment s'assurer que les messages sont reçus en temps voulu, sans impact sur les performances?
La description de base semble s'appuyer sur un seul fournisseur JMS pour garantir que les messages sont gérés de manière centralisée et non perdus. Je peux voir la mise à l'échelle être un problème.
Question 3: Comment JMS évolue-t-il?
Lors de la mise à l'échelle, je constate des problèmes complexes pour garantir qu'un seul message soit remis à tous les abonnés appropriés, quel que soit le serveur physique qui reçoit le message.
Question 3b: Comment une implémentation JMS assure-t-elle une livraison fiable dans un environnement à l'échelle?
Veuillez noter que, bien que ces questions concernent JMS, elles s'appliquent probablement à toute infrastructure de messagerie. Je souhaite des réponses spécifiques à JMS, ainsi que des réponses plus générales, voire spécifiques à une autre technologie.
J'essaie de répondre à quelques questions en fonction de mon expérience avec JMS.
Réponse 1: - / JMS est l'API Java Message Service; Il fournit une interface uniforme aux clients Java pour accéder à la structure de messagerie. L'API JMS sous-jacente est un fournisseur de messagerie conforme à JMS, par exemple le fournisseur WebSphere MQ. JMS prend en charge le transport d'une charge utile via n'importe quel protocole de messagerie vers des destinations. File d'attente et sujet. Il s'agit des bases de JMS.
Comment fonctionne la réception? La spécification JMS fournit deux classes importantes: - MessageConsumer et MessageListener. La classe MessageConsumer permet à un client JMS de recevoir des messages JMS de manière synchrone en appelant l’une de ses méthodes receive(). Cet appel bloquera le fil jusqu'à la réception d'un message. Sinon, une réception asynchrone peut être effectuée en enregistrant un objet de MessageListener avec MessageConsumer. C'est JMSProvider qui apprend qu'un message est arrivé. dans sa destination locale et son travail consiste à remettre des messages au thread consommateur d'abonné interrogateur ou au thread écouteur d'écoute de message enregistré non interrogateur.
Réponse 2: - MessageConsumer L'API a deux variantes de réception: receive() et receive(long timeout). Cette dernière variante permet à un thread MessageConsumer de bloquer jusqu'à ce que le message arrive dans le délai imparti ou s'il arrive à expiration.
Différents frameworks de messagerie peuvent implémenter la fonctionnalité de blocage de différentes manières. Comme les objets JMS sont des objets administrés par JNDI et que des objets proxy spécifiques au fournisseur sont renvoyés au client JMS, cela signifie que le client ne sait pas comment le blocage se produit en arrière-plan. Une infrastructure de messagerie particulière peut choisir une interrogation de thread consommateur de message après une période donnée. Alternativement, il peut choisir de bloquer jusqu'à ce que la notification soit envoyée.
Je ne sais pas si vous recherchez une solution pour un framework de messagerie conforme à JMS?
Réponse 3: - Je suppose que, par la mise à l'échelle JMS, vous entendez la possibilité d'avoir plusieurs éditeurs/abonnés, plusieurs destinations sur plusieurs machines physiques. La mise à l'échelle JMS nécessite la prise en charge du fournisseur de messagerie sous-jacent pour prendre en charge une sorte de clustering/basculement. En tant que telle, la spécification JMS ne prend pas en charge l'évolutivité. Corrigez-moi si je me trompe? Par exemple, j'ai travaillé sur WebSphere MQ compatible JMS, qui fournit une prise en charge du clustering.
Question 1: Ma compréhension de base de JMS est-elle correcte?
Commençons par bien comprendre la terminologie. Vous ne pouvez pas dire JMS Provider must be running car le fournisseur est une entité qui a créé le serveur JMS et c'est le serveur JMS qui doit être en cours d'exécution. Par conséquent, lorsque nous parlons de JMS, nous entendons un ensemble d’API (plus techniquement - d’interfaces) que les fournisseurs implémentent. Donc, fondamentalement, les fournisseurs écrivent leur propre implémentation JMS. Par exemple, Active MQ is a JMS server fourni par Apache(provider)
Mon hypothèse de publication est que le fournisseur JMS attend simplement la publication d’un message, puis le stocke dans une file d’attente (sauvegardée en mémoire ou sur une base de données, selon l’implémentation).
Vrai dans une certaine mesure. Il existe différents modèles qui sont suivis. Le serveur JMS laisse un socket ouvert. Chaque fois qu'un client expéditeur doit envoyer un message, il ouvre simplement une connexion au socket et envoie le message. Comment recevoir se comporte est totalement différent. Vous avez tirez et poussez . En Push serveur transmettra les messages au client receveur direct dès qu'il recevra le message. Cela s'appelle également mode asynchrone . En modèle tiré, le destinataire envoie une demande au serveur pour obtenir des messages ( mode synchrone ).
Est-ce que recevoir (généralement) bloque si aucun message n'est disponible?
Comme je l'ai mentionné dans le point précédent, cela dépendra du modèle que vous utilisez. Le récepteur sera bloqué dans le modèle d'extraction ( réception synchrone ). Cela se produit également dans fil de session , pas le fil principal.
Si oui, comment le blocage est-il atteint? Le client interroge-t-il continuellement les messages?
Oui, le client interrogera continuellement le modèle tiré. Généralement, il y a un délai d'attente après lequel le client sera résilié.
Sinon, comment s'assurer que les messages sont reçus en temps voulu, sans impact sur les performances?
Utilisez le mode asynchrone . Vous devez simplement enregistrer un MessageListener et il recevra un message sur sa substitution onMessage (Message msg) lorsqu'il y aura des messages disponibles sur le serveur.
Question 3: Comment JMS évolue-t-il?
C'est vraiment une question à laquelle les prestataires doivent s'inquiéter. Lorsque vous dites qu'un message est reçu par tous les abonnés, vous vous référez àPUBSUBmodèle de communication (autre/PTP). En PUBSUB, le message envoyé à un sujet sera remis à tous les abonnés abonnés à ce sujet.
Question 3b: Comment une implémentation JMS assure-t-elle une livraison fiable dans un environnement à l'échelle?
Fiabilité? Pas toujours. Encore une fois, cela dépend du cas d'utilisation. Vous pouvez avoir persistent ainsi que non persistant Messages. En cas de messages persistants, les messages sont stockés dans une base de données (fichier ou autre) et leur livraison est assurée. En cas de messages non persistants, cette garantie n’existe pas. Une défaillance du serveur peut entraîner la perte de messages.
Je pense que la différence entre la file d'attente et le sujet doit être mentionnée car il existe des différences importantes dans la manière dont les messages sont remis.
File d'attente: un seul client recevra un message. Pour faire évoluer votre système, vous pouvez par exemple avoir 10 clients connectés à la même file d'attente, mais un seul d'entre eux recevra un message particulier. Si aucun client n'est connecté, le message restera dans la file d'attente jusqu'à ce que quelqu'un se connecte ou que le message expire.
Sujet: tous les clients recevront une copie de chaque message. Généralement utilisé dans un scénario d'abonné où plusieurs points de terminaison sont potentiellement intéressés par chaque message. Un abonné durable peut même être en panne pendant un certain temps; le message sera conservé jusqu'à ce que l'abonné soit de nouveau opérationnel ou que le message expire. Si aucun client n'est connecté et qu'il n'y a pas d'abonné durable, le message sera supprimé.
JMS prend en charge la consommation de messages avec une méthode synchrone (recevoir avec et sans dépassement de délai bloquant votre thread) ou avec un rappel déclenché par un événement (écouteur de message async)).
Vous pouvez choisir la méthode qui répond le mieux à vos besoins, mais vous devrez peut-être également jeter un coup d'œil à la mise en œuvre réelle. Par exemple, certaines implémentations JMS font un aller-retour réseau pour receive () et sont donc mieux utilisées avec un délai d'attente ou avec le programme d'écoute.
Avec le programme d'écoute des messages, le comportement et la suspension de la réception des messages ne sont pas aussi faciles à contrôler que lors d'un appel reçu bloquant. Généralement, la plupart des contrôles sont obtenus en disposant de votre propre pool d'appels de blocage receive () avec expiration du délai et en les envoyant à vos travailleurs.
Il existe deux types de domaines de messagerie dans JMS.
- Point -To -Point (PTP) Domaine de messagerie
- Domaine de messagerie éditeur/abonné
Dans le modèle PTP , un message est remis à un seul destinataire. Ici, Queue est utilisé en tant queMessageOinclinéMiddleware (MOM).
La file d’attente est responsable de conserver le message jusqu’à ce que le destinataire soit prêt.
Dans le modèle PTP, il n'y a pas de dépendance temporelle entre l'expéditeur et le destinataire.
Dans Pub/Sub model , un message est remis à tous les abonnés. C'est comme la radiodiffusion. Ici, Topic est utilisé en tant que middleware orienté message qui est responsable de la conservation et de la remise des messages.
Dans le modèle PTP, il existe une dépendance temporelle entre l'éditeur et l'abonné.
Modèle de programmation JMS
MessageDRivenBean (MDB)
- MDB est un bean contenant une logique métier. Mais, il est invoqué en passant le message. Donc, c'est comme JMS Receiver.
- MDB reçoit un message de manière asynchrone et le traite.
- La MDB reçoit un message de la file d'attente ou du sujet.
- MDB est comme un bean de session sans état qui encapsule une logique métier et ne conserve pas l’état du bean.
