commençons par les terminologies. Vous ne pouvez pas dire JMS Provider must be running car provider est une entité qui a construit le serveur JMS et c'est le serveur JMS qui doit fonctionner. Par conséquent, lorsque nous disons JMS, nous entendons un ensemble D'API (interfaces plus techniques) que les fournisseurs mettent en œuvre. Donc, fondamentalement, les fournisseurs écrivent leur propre implémentation JMS. Par exemple, Active MQ is a JMS server qui est fourni par Apache(provider)

mon hypothèse sur la publication est que le fournisseur JMS attend simplement qu'un message soit publié, puis le stocke dans une file (mémoire ou 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 garde une socket ouverte. Chaque fois qu'un client expéditeur doit envoyer un message, il ouvre simplement une connexion à la socket et envoie le message. Le comportement de receive est tout à fait différent. Vous avez pull et appuyer sur. Dans push server poussera les messages vers le client récepteur en direct dès qu'il reçoit le message. Il est également appelé mode asynchrone. Dans pull model client receiver envoie la requête au serveur pour obtenir des messages ( mode synchrone).

reçoit-il (typiquement) un bloc si aucun message n'est disponible?

comme je l'ai mentionné au point précédent, cela dépendra du modèle vous êtes en utilisant. Récepteur bloqué dans le modèle d'extraction (synchrone recevoir). Aussi ce qui se passe dans session thread, pas le thread principal.

si oui, comment obtient-on le blocage? Le client Recherche-t-il continuellement des messages?

Oui, le client sondera en permanence en cas de modèle pull. Généralement, il y a un délai après lequel le client sera terminé.

Si non, comment s'assurer que les messages sont reçus en temps opportun, sans impact sur les performances?

Utiliser mode asynchrone. Il vous suffit de vous inscrire MessageListener et il recevra un message sur c'est substituée onMessage (Message msg) quand il y a disponibilité des messages sur le serveur.

Question 3: Quelle est l'échelle de JMS?

C'est vraiment une question pour les fournisseurs de s'inquiéter. Quand vous dites un message est reçu par tous les abonnés vous reportant à la section PUBSUB modèle de communication (Autre être PTP). Dans PUBSUB le message envoyé à un thème sera livré à tous les abonnés inscrits à ce thème.

Question 3b: comment la mise en œuvre d'un JMS assure-t-elle une livraison fiable dans un environnement gradué?

Fiabilité? Pas toujours. Encore une fois, cela dépend du cas d'utilisation. Vous pouvez avoir persistantes ainsi non persistants Messages. En cas de messages persistants, les messages sont stockés dans DB (file ou autres) et sa livraison est assurée. En cas de messages non persistants, il n'y a pas de garantie. Le serveur peut entraîner la perte de messages.

JMS supporte la consommation de messages avec une méthode synchrone (réception avec et sans temps mort bloquant votre thread) ou avec un callback piloté par un événement (async message listener)).

vous pouvez décider quelle méthode convient le mieux à vos besoins, mais vous devrez peut-être aussi jeter un coup d'oeil à la mise en œuvre réelle. Par exemple, certaines implémentations JMS font un aller-retour réseau pour le receive() et sont donc mieux utilisées avec un timeout ou avec l'écouteur.

avec le message le comportement du fil d'écoute et l'interruption de la réception du message ne sont pas contrôlés aussi facilement qu'avec un appel de réception de blocage. Typiquement la plupart du contrôle est réalisé en ayant votre propre pool de blocage des appels receive() avec des timeouts, dispatching à vos travailleurs.

je pense que la différence entre la File d'attente et le Sujet devrait être mentionnée, car il existe des différences importantes dans la façon dont les messages sont livrés.

File d'attente: un seul client recevra un message. À l'échelle, vous pouvez par exemple avoir 10 clients, tous 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 reste dans la file d'attente jusqu'à ce que quelqu'un se connecte ou que le message arrive.

Rubrique: tous les clients recevez une copie de chaque message. Généralement utilisé dans un scénario d'abonné où de nombreux paramètres sont potentiellement intéressés par chaque message. Une semelle abonné peut même être vers le bas pour un certain temps; message sera conservé jusqu'à l'abonné est nouveau ou le message. Si aucun client n'est connecté et qu'il n'y a pas d'abonnés durables, le message sera supprimé.

il existe deux types de domaines de messagerie dans JMS.

1. Ppoint- T o - Ppoint(PTP) Domaine De Messagerie
2. Domaine De Messagerie De L'Éditeur/Abonné

dans le modèle PTP, un message est transmis à un récepteur. Ici, la file d'attente est utilisée comme un M essage O riented M iddleware ( maman).

la file d'attente est responsable de maintenir le message jusqu'à ce que le récepteur 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 modèle, un message est envoyé à tous les abonnés. C'est comme la radiodiffusion. Ici, le sujet est utilisé comme un middleware orienté message qui est responsable de tenir et de livrer message.

dans le modèle PTP, il y a une dépendance temporelle entre l'éditeur et l'abonné.

JMS Modèle de Programmation

source

M essage Ddéchiré B ean (MDB)

• le MDB est un haricot qui contient une logique commerciale. Mais, il est invoqué en transmettant le message. Donc, c'est comme JMS Receiver.
• MDB reçoit de façon asynchrone un message et le traite.
• le BMM reçoit un message d'une file d'attente ou d'un sujet.
• le MDB est comme un haricot session apatride qui encapsule une logique d'affaires et ne maintient pas un État du haricot.