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  celui­ci  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.