Cours Gratuit
Service de messagerie JMS
Dans les architectures distribuées hétérogènes, composées d’applications différentes implémentées dans des langages pouvant être différents, la communication entre applications peut être un problème. Parmi les nombreuses solutions à cette problématique, deux grands axes se dessinent. ● L’invocation de procédures distantes (RPC Remote Procedure Call), qui peut être effectuée avec des standards tels que RMI pour Java, DCOM pour Microsoft, ou CORBA. Le principe reste le même : invoquer un service sur une machine distante et traiter la réponse. ● L’échange de messages entre applications. Ces messages sont véhiculés par une infrastructure particulière, appelée MOM(Middleware Oriented Messaging). Ces messages sont beaucoup plus génériques que l’invocation de services distants et peuvent représentés tout type de contenu, objet sérialisé ou texte. L’invocation de procédures à distance impose un couplage fort entre les applications car les deux applications doivent être actives en même temps, pour pouvoir communiquer. Les MOM permettent de casser ce couplage car les applications ne communiquent plus directement entre elles. Il existe de nombreuses solutions, commerciales ou non, de service MOM : IBM. MQSeries, BEA MessageQ, Microsoft MSMQ, … L’API JMS permet de spécifier un standard pour l’utilisation des brokers MOM. Il existe deux modes de fonctionnement : ● le mode point à point (point to point) ; ● le mode publication/abonnement (publish/subscribe). L’application qui envoie un message est un producteur, celle qui le récupère est un producteur.
Mode point à point
Les messages sont échangés par l’intermédiaire d’une file d’attente (message queuing). L’application émettrice du message dépose celuici dans la file. Ce message reste dans la file, jusqu’à ce que l’application destinataire le récupère. Le producteur ne spécifie pas l’application cible, mais le nom de la file d’attente. Plusieurs producteurs peuvent mettre des messages dans la file, par contre un message n’est récupéré que par un seul consommateur. Entre le moment où le message est déposé et celui où il est consommé, le broker en assure la persistance. Ce type de middleware est caractérisé principalement par : ● la persistance des messages les messages sont stockés jusqu’à leur consommation ; ● la qualité de service garantie de livraison de message, gestion de priorités, durée de vie des messages. 2. Mode publication/abonnement C’est un mode de communication point à multipoints. Chaque message est associé à un sujet (topic). Le consommateur qui veut recevoir un message va s’abonner (subscribe) à un sujet. Le MOM envoie une copie du message à tous les abonnés. Le producteur du message ne connaît pas les consommateurs. C’est le MOM qui gère la liste des abonnés. Ce type de middleware est caractérisé principalement par : ● la rapidité d’échange des messages utilisation de protocoles dédiés comme IP multicast. 3. Spécification JMS Comme pour JDBC visàvis des bases de données, l’API JMS permet de normaliser l’accès aux différents MOM. Les interfaces principales de cette API sont : ● QueueConnection ou TopicConnection : interface de connexion à la structure MOM, la classe d’implémentation est créée via un Factory ; ● QueueSession ou TopicSession : session qui permet de créer les producteurs (QueueSender ou et les consommateurs (QueueReceiver ou TopicSubscripter) de messages ; ● Queue : la file de messages ; ● Topic : un sujet. 4. Modèle de programmation JMS Le modèle de programmation JMS est toujours sensiblement le même. 1. Localisation du driver JMS. Ce driver est accessible auprès de JNDI sous le nom « ConnectionFactory ». 2. Création d’une connexion JMS par l’intermédiaire d’un factory. Pour une connexion point à point, il faudra utiliser une QueueConnectionFactory, et pour une connexion publication/abonnement un TopicConnectionFactory. 3. Obtention de la session JMS auprès de la connexion. Il s’agira d’une QueueSession pour du point à point, ou d’un TopicSession pour du publication/abonnement. 4. Recherche auprès du service JNDI de la destination JMS, par exemple « queue/testQueue » ou « topic/testTopic ». 5. Création du producteur ou du consommateur. Le producteur enverra le message. Le consommateur sera averti de l’arrivée d’un message via l’implémentation d’un javax.jms.MessageListener. 6. Phase d’émission ou de réception du message.
Télécharger le document complet
