Jean FRANCOIS blog [Weblogic / Java EE / SOA]: JMS

vendredi 2 septembre 2011

JMS - PRINCIPES

07:58 |

Publié par Jean FRANCOIS |

Modifier l'article

JMS est une interface de système de message qui permet de définir des fonctionnalités des providers de message (MOM). Celle de Weblogic définit les fonctionnalités définit dans le standard plus celle spécifique éditeur.

JMS permet d’envoyer un message d’un producteur à un consommateur de deux façons différentes :

ü En point-to-point Ou le producteur ou sender envoie un message sur une queue destination au consommateur ou receiver indépendamment du type de message envoyé.

ü En publish-subscribe Avec plusieurs consommateurs actifs (sur le temps de durée de vie de son abonnement) ou subscriber en abonnement sur une topic sur certains types de messages (event), ou le message est publié par un producteur ou publisher.

Type	Producteur	Consommateur	file
Point-To-Point	Sender	Receiver	Queue
Publish-Subscrive	Publisher	Subscriver	Topic

Le message peut être persisté dans un fichier ou en base pour garantir de toute perte en cas d’incident sur l’instance. Les messages sont maintenus dans la queue jusqu'à ce que :

ü Un consommateur exécute correctement le message (pending message).

ü Le message expire dans le temps.

ü L’instance sur laquelle la queue non persistante est hébergée tombe.

ü La queue est supprimée.

Dans le cas de la souscription non persistante, la durée de vie du message est associée au temps de la connexion JMS, contrairement au mode persisté ou le message survie à une reconnexion.

Le consommateur ou receveur dépile les messages dans l’ordre d’arriver sur la queue (FIFO). Chaque message n’est exécuté que par un consommateur. Si plusieurs consommateurs sont en attachement sur une file unique, seul un consommateur traite le message.

EXTERNAL JMS Providers

Les spécifications JEE ne définissent pas la façon de communiquer avec des providers JMS externes. Certains définissent une API JMS pour faciliter ces intégrations. Dans Weblogic, deux stratégies sont possibles (direct ou indirecte) pour communiquer avec des providers interne (Weblogic) ou externe (Autre fournisseur).

Intégration	Fonctionnement	Caractéristique
Directe	L’application interagie directement avec la destination distante via le code applicatif ou le paramétrage des descripteurs (le plus optimisé, mais exposé aux interruptions et erreur du provider distant).	Choix de la rapidité, mais peux robuste.
Indirecte	Utilisant la stratégie du Store-And-Forward utilisant un agent intermédiaire (message forwarding agent) assurant la persistance locale et l’envoi du message asynchrone vers la destination distante. Elle assure les options de rejeux et de passivation garantissant l’envoi du message malgré les erreurs et interruption de la destination distante.	Choix de la robustesse, mais moins rapide.

Plusieurs possibilités sont offertes par l’architecture Weblogic, chacune offrant des avantages et inconvénients différents.

	DIRECT			INDIRECT
	Client JMS MDB	Foreign Server	Foreign JNDI Provider	Bridge	S.A.F
Destination et Version	WLS	WLS/Other	WLS/Other	WLS/Other	WLS>9 même version
Cas D’utilisation	Si pas de contrainte de robustesse dans un environnement Weblogic de même version.	Isoler le paramétrage local de la configuration distante en rendant visible le JDNI distant en local.	À utiliser pour des objets non JMS	Utilisation d’un mode Indirect sur des destinations Weblogic plus anciennes ou des providers distants différents	Utilisation avec des destinations Weblogic. Implémenter un client SAF. Plus optimisé sur les transactions (transaction ne nécessitant pas transaction distribuée).
Contre indication				Moins optimisé sur les transactions. Dans le cas où l’on reçoit d’une destination distante (Utiliser un client consommateur ou un MDB avec l’option retry). Envoi sur une destination local (plutôt envoyer directement à la destination locale). Environnement avec une faible tolérance de latence de message (envoi mono thread et donc potentiellement un point de contention). Si c’est un environnement Weblogic supérieur ou égal à 9 préférer SAF. Quand il y a beaucoup de destinations sur la partie distante avec beaucoup de serveurs, le paramétrage peut vite devenir complexe à mettre en place et à maintenir (préférer le SAF avec un agent par serveur).	Ne fonctionne qu’avec des destinations Weblogic. Ne peux fonctionner avec des destinations temporaires
Cluster	Utilise les Distributed Destination.			Utilise les Distributed Destination.	Utilise les Distributed Destination.

Les principales différences entre sur le mode indirecte entre le Bridge et le SAF sont que :

ü Le Bridge fonction avec un file source et destination alors que le SAF est une vue locale d’une file distante.

ü Le paramétrage du Bridge nécessite de déclarer autant d’entrées que de destination, alors que l’on peut regrouper plusieurs destinations dans un même SAF.

ü Le SAF et multithread et peut se passer de propagation de transaction alors que le Bridge fonctionne avec des transactions avec un envoi mono thread.

ü Le SAF offre un client de type Indirect.