JMS

- Mise à jour : 13/03/2015 - Copyright(C) 2015 - Laurent Chrétien

- Le serveur de messages, un service lourd - pp : 11/03/2015 - dm : 13/03/2015
- Connection, session, producteur, receveur - pp : 11/03/2015
- Queues et Topics, c'est "pareil" - pp : 13/03/2015


LE SERVEUR DE MESSAGES - UN SERVICE LOURD

Révisions : 2015 - 13/03, 11/03

Pour échanger des messages deux applications utilisatrices utilisent un service externe de haut niveau, un serveur de messages, qui est du même niveau qu'une base de données.

Cette comparaison et analogie est importante, car la logique d'usage du point de vue du client est effectivement la même à 90%. En gros, quand on a compris jdbc, on a compris jms.

On peut en fait tout à fait comparer la remise d'un message au service de messagerie, à celle d'une écriture dans une base de données.

Le service doit assurer un niveau de fiabilité et de capacité identique. C'est un service lourd, portant sur potentiellement des millions de messages quotidiennement, dont la remise à leur destinataire doit être garantie à 100%.

Encore plus concrêtement même, il s'appuie forcément sur une base de données, qui fournit en réalité 99% de ces foncionnalités de fond de sécurisation très complexes.

Un serveur de messagerie est donc un outil potentiellement cher à l'achat et à la maintenance, et utilisant des ressources importantes. Il peut résider sur un serveur dédié. Il s'apparente également en termes de complexité à un serveur d'applications Web/j2ee, tel que JBoss, GlassFish ou Websphere.

Partie cliente "infime"

Comparativement donc, en face de cela, la partie java client d'un serveur de messages, qui consomme pas mal de texte de présentation, est en fait bien entendu infiniment légère, exactement comme pour un accès jdbc.

Elle réside sur le noeud de l'application cliente et ne fait rien de plus que de s'adresser au serveur. Il ne s'agit que d'une simple interface, d'un "driver" jms, comme on parle de driver jdbc, chargé de dialoguer avec le serveur.


CONNECTION, SESSION, PRODUCTEUR, RECEVEUR

Pour envoyer et recevoir des messages, on doit d'abord établir une connection avec le serveur de messages (adresse ip du serveur, login principalement, comme pour une base de données).

A partir de cette connection on peut créer une session, qui permettra l'échange effectif. La session est similaire à une transaction pour une base de données. Elle garantit un échange complet (transactionnel) d'un petit ensemble de messages. Il faut la voir comme de courte durée.

A partir de là on demande à la session la création d'un objet d'émission de messages pour envoyer un message (MessageProducer) ou d'un objet de réception de messages (MessageReceiver).

 


QUEUES ET TOPICS, C'EST "PAREIL"

La différenciation, particulièrement lourde et encombrante, entre les deux modes de transmission des messages, en mode point à point (files, queues), ou en mode abonnement (topic), est réalité très secondaire.

Dans les deux cas une file de messages, en gros une simple table de la base de données sous jacente, est remplie, et le service doit ensuite gèrer un peu différemment la façon de remettre chaque message (à un seul destinataire dans le premier cas, à plusieurs abonnés dans le second).

Fonctionnellement il y a bien en effet une différence substancielle, mais du point de vue technique et architectural la différence est vraiment très faible.

Ceci explique que la version jms 1.1 uniformise enfin, se débarasse, une bonne fois pour toutes, de ces deux modes en les ramenant à un simple paramètrage de l'api redevenue légitimement commune.