Dans cette article nous allons essayer de voir quels sont les avantages et inconvénients de utilisation du JMS en java et dans quel cas nous pouvons utiliser.

Queue jms

1 personne à la fois lit dans la queue JMS dans le sens où une fois que le message JMS est consommé par un des clients celui-ci n’existe plus en temps que tel dans la queue.

• Avantages :

On sait ce qui est lu dans la queue JMS à instant T.
Mode transactionnel possible : On peut sauvegarder nos messages JMS en dans une base de données cela présente l’avantage de ne perdre aucun message à traiter.
On peut également utiliser le mode transacted = true cela permet notamment de reposter les messages dans la queue d’origine en cas de rollback .

Facilite les tests Test unitaires ou intégration d’un applicatif .

les queues JMS sont très largement utiliser dans les architectures SOA (service Oriented Architecture) afn de permettent aux différentes briques applicatives du SI de communiquer entre elles . Chacune de ses briques applicatives s’attachant de répondre à un besoin métier ou fonctionnelle distinct .

• Inconvénients :

Répartition de la charge sur le serveur

A noter : On peut également utiliser que des queues Jms, et avoir un serveur par processus métier cela permet notamment de garder une plus grande flexibilité et souplesse tant sur le déploiement applicatif que sur la répartition de charge des serveurs plus ou moins critiques.

Topic JMS

La différence majeur avec les queue JMS est que la topic JMS permet d’avoir plusieurs « subscriber » c’est à dire plusieurs personnes qui viennent lire sur la topic JMS . Nous définissons la configuration de celle-ci le nom du subscriber .

On entend parfois aussi parler de souscription durable permet de garantir que le message a bien été livré au subscriber .

Le problème majeur de la topic JMS est que nous ne pouvons avoir de visibilité sur ce qui se passe à instant T.

Afin de combiné les avantages et inconvénients des Queue et topic JMS nous allons introduire la notion de transaction XA.

La transaction XA permet de dispatcher nos messages dans différentes queue JMS cela permet de garantir une architecture physique plus robuste . Nous pouvons bien évidemment sauvegarder nos messages en base de données et imaginer une réplication de ses bases via différentes solutions (comme Oracle RAC pr exemple)