PROJET JMS Christophe MOGENTALE Pierre PICHOT Master 2 STIC mention IRAD
TABLE DES MATIERES I. But du projet... 3 II. Installation préalable... 3 III. Approche de type "chat" : JMSChat... 3 1. Présentation de l application... 3 2. Compilation et exécution... 4 3. Développement... 6 4. Bilan sur JMSChat... 6 IV. Approche de type "newsgroup": JMSNews... 7 1. Présentation de l application... 7 2. Compilation et exécution... 7 3. Développement... 7 4. Bilan sur JMSNews... 9 V. Bilan global... 10 2
I. But du projet En introduction, il convient de rappeler les tenants et aboutissants de ce projet. Le but est de réaliser un environnement de discussion privé reposant sur Java et un serveur d'applications JBoss, grâce à la technologie JMS (Java Messaging Service). JMS permet l'envoi de messages sous forme de textes ou d'objets entre plusieurs applications, selon trois domaines : Point-To-Point : envoi simple d'un message via une queue, Request/Reply : envoi de message via une queue avec attente de réponse, Publish/Subscribe : envoi via un topic. Deux approches seront implémentées : approche "chat" pour JMSChat, et approche "newsgroup" pour JMSNews. II. Installation préalable Le service de messagerie JMS repose sur la technologie JBoss. Pour cela, un serveur JBoss doit être installé et correctement configuré sur la machine hôte, de préférence en version 4.0.x. Un kit de développement Java tel que J2EE 1.4 est nécessaire ainsi qu une machine virtuelle Java en version 5. La variable d environnement JAVA_HOME doit être correctement renseignée sur le répertoire d installation de J2EE. Le serveur JBoss peut être lancé soit grâce à un script prédéfini, soit en exécutant "run.bat" sur les systèmes Microsoft ou "run.sh" sur les systèmes de type Unix, se trouvant dans le dossier <bin> du répertoire d installation de JBoss. En cas d ouverture des fichiers source dans un environnement de développement intégré, ne pas oublier d inclure l archive "jbossall-client.jar" se trouvant dans le dossier <client> du répertoire d installation de JBoss sous peine d apparition d erreurs de types et méthodes introuvables. Il serait également souhaitable de rajouter dans la variable d'environnement PATH le chemin des binaires de java. III. Approche de type "chat": JMSChat 1. Présentation de l application JMSChat s'articule autour de trois applications : TopicServer : serveur de topics, permettant à l'utilisateur de connaître dynamiquement les différents sujets de discussion, ChatPublisher : client d'envoi de messages, ChatSubscriber : client de lecture des messages. 3
ChatPublisher et ChatSubscriber communiquent avec TopicServer via le domaine Request/Reply, tandis que les communications de ChatPublisher vers ChatSubscriber se font par le domaine Publish/Subscribe. 2. Compilation et exécution La compilation des différentes classes peut se faire via les scripts "compile.bat" ou "compile.sh", suivant le système d'exploitation. Ces scripts prennent en paramètre le nom du fichier.java à compiler. Il est tout à fait possible de compiler les fichiers source par l'intermédiaire d'un IDE. Au préalable de toute exécution, le serveur JBoss doit être lancé, et le fichier "jndi.properties" indiquer le chemin du serveur JBoss (localhost dans notre cas). De plus, afin de pouvoir envoyer des messages sur plusieurs topics, la création d'un topic intitulé "topic/topictest2" est conseillée via la console JMX accessible par le port 8080 de la machine hébergeant le serveur JBoss. Pour exécuter un programme les scripts "execjava.bat" et "execjava.sh", prenant en paramètre le nom de l'application, seront très pratiques. A noter que la variable PATH doit bien indiquer le dossier contenant les sources. Par la suite, il sera préférable d'utiliser une console par programme afin de surveiller les différents messages pouvant apparaître. Tout d'abord, il convient de lancer TopicServer, en mode console, sans lequel il sera impossible aux clients de trouver quels topics utiliser. Il est possible de lui passer un nom de queue en paramètre, sans quoi la queue "queue/a" est utilisée par défaut. Par défaut, deux topics sont utilisés : "Sport" sur la queue "queue/a", "Informatique" sur la queue "queue/b". TopicServer se quitte par la commande Ctrl+C. 4
ChatPublisher prend en paramètre le nom de l'utilisateur. L'interface se compose d'un sélecteur de topics, de champs de saisie de message (titre et message) et d'une zone affichant le log de l'application. Il suffit de choisir un topic de la liste préalablement téléchargée sur le serveur de topics pour s'y connecter et pouvoir y envoyer des messages. De la même manière ChatSubscriber prend en paramètre le nom de son utilisateur. Son interface est sensiblement la même que celle de ChatPublisher, la saisie de messages en moins. La sélection des topics repose sur le même principe de téléchargement sur un serveur. Les messages sont affichés dans une zone de texte. 5
3. Développement Afin de nous familiariser avec les différents domaine de JMS, quelques exemples simples ont été tout d'abord étudiés, puis nous avons réalisé de petites applications en mode texte. Dès lors, il a été plus simple de réaliser une organisation telle quelle : MessagePublisher Publish/Subscribe Subscriber ChatPublisher TopicChecker ChatSubscriber Request/Reply Replyer TopicServer Afin d'implémenter facilement le domaine Request/Reply, deux classes contenant les bases de ce moyen de communication, Requester et Replyer, ont été créées. La première est héritée par la classe TopicChecker, la seconde est utilisée dans TopicServer. Ainsi, TopicChecker peut émettre des messages par ce domaine en implémentant simplement une méthode d'envoi de messages. Quant à TopicServer, il implémente une classe privée nommée TopicRequestListener passée en paramètre de Replyer qui lui permettra de recevoir et traiter les différentes demandes qui lui arriveront. Afin de pouvoir télécharger la liste des topics, le message "Quels sont les topics?" est envoyé au serveur de topics qui répondra en renvoyant une HashMap avec en clé le nom du topic et en objet le nom de la queue à utiliser. Afin d'émettre des messages par le domaine Publish/Subscribe, une organisation similaire de classes nous a semblée intéressante, ChatPublisher utilise une classe MessagePublisher permettant l'envoi de messages sur le topic désiré. Cette classe hérite de Publisher qui pose les bases de ce service, en y ajoutant une méthode d'envoi de messages. ChatSubscriber implémente un écouteur de messages qui sera passé en paramètre d'un Subscriber, classe qui permettra à ChatSubscriber de recevoir les messages et de les afficher dans son interface. Les messages alors envoyés sont des objets de type JMSMessage, contenant le nom de l'émetteur du message, le titre du message et son contenu. Les interfaces graphiques ont été développées en utilisant la bibliothèque Swing. 6
4. Bilan sur JMSChat Cette première approche de JMS nous a permis de connaître et de comprendre le principe de fonctionnement de deux de ses trois domaines, à savoir Request/Reply et Publish/Subscribe. De plus, la programmation par brique nous permettra de réutiliser certaines de nos classes dans la seconde partie de ce projet. A l'avenir, il pourra être intéressant de permettre à l'utilisateur d'envoyer et de recevoir des messages de manière complètement libre, à l'instar des chat "classiques", ainsi que de pouvoir gérer dynamiquement les topics. IV. Approche de type "newsgroup" : JMSNews 1. Présentation de l'application A l'instar de JMSChat, JMSNews repose sur trois applications : GroupServer : serveur de groupe de discussion, qui se charge aussi de stocker les différents messages afin qu'ils soient lus par la suite, NewsPublisher : client d'envoi de messages, NewsSubscriber : client de lecture de messages. NewsPublisher et NewsSubscriber se connectent par Request/Reply au GroupServer pour télécharger la liste des groupes disponibles. Ensuite, NewsPublisher enverra ses messages par le domaine Point-to-Point au GroupServer qui les stockera. Pour consulter ces messages, NewsSubscriber demandera tout d'abord la liste des en-têtes des messages appartenant au groupe voulu, puis sélectionnera un message à partir de cette liste, qui sera téléchargée depuis le serveur de groupes. A noter que la séparation des fonctions de serveur de groupes et de stockage de messages de GroupServer en deux unités distinctes est possible. Comme nous le verrons plus tard, NewsSubscriber a été développé de manière à pouvoir s'adapter à cette possibilité. 2. Compilation et exécution La compilation des fichiers source se déroule de la même manière que décrite précédemment ; les scripts "compile.bat" et "compile.sh" sont indépendants du programme. Cependant, la création d'un topic supplémentaire est caduque car le domaine Publish/Subscribe n'est pas utilisé. Il en est de même pour l'exécution des différents programmes grâce aux scripts "execjava". 7
L'application GroupServer doit être lancée en premier, sans quoi NewsPublisher et NewsSubscriber ne pourront effectuer leurs transactions. GroupServer est une application en mode console, qui se quitte par la commande Ctrl+C : Par défaut, la queue utilisée est "queue/a", et deux groupes sont enregistrés : "Sport" et "Informatique". Le client d envoi de messages, NewsPublisher, s exécute en prenant comme paramètre le nom de l émetteur. Son interface a été calquée sur celle de ChatPublisher, et offre les mêmes fonctionnalités : sélection du groupe, saisie du message, affichage du log. 8
Enfin, NewsSubscriber permet à l utilisateur de lire les messages stockés sur le serveur. Pour cela, l utilisateur sélectionne l un des groupes proposés par le serveur de groupes et verra apparaître la liste des messages de ce groupe, s il en existe. Il ne lui reste plus qu à cliquer sur le bouton "Voir" pour que le message s'affiche : Pour vérifier la présence d'un nouveau message du groupe souhaité, un simple clic sur le bouton "Rafraîchir" suffit. 3. Développement JMSNews utilisant entre autres le domaine Request/Reply, la programmation par "briques" de JMSChat nous a permis de réutiliser ici les classes Requester et Replyer, ainsi que JMSMessage. De plus, JMSNews reposant aussi sur un principe de trois applications, une organisation relativement similaire nous a semblée pertinente : MessageSender GroupServer MessagesRequester NewsPublisher Point-To- Point Replyer Request /Reply Request /Reply NewsSubscriber GroupChecker 9
L'application GroupServer, comme nous l'avons vu précédemment, fait à la fois office de serveur de groupes et de stockages de messages. Celui-ci utilise donc un Replyer car les communications se font sur les domaines Request/Reply et Point-To-Point, auquel un écouteur de messages est passé en paramètre afin de traiter ces messages. Afin de pouvoir télécharger la liste des groupes disponibles, NewsPublisher et NewsSubscriber utilisent la classe GroupChecker, héritant de Requester, communiquant avec le Replyer de GroupServer via le domaine Request/Reply. Cette requête se fait en envoyant le message texte "groupes?" ; un vecteur de chaînes de caractères est alors renvoyé au client. L'émission de messages par NewsPublisher se fait en utilisant le domaine Point-To-Point, NewsPublisher n'ayant pas à attendre de réponse de la part du serveur stockant les messages. Pour cela, on utilise la classe MessageSender héritant de Sender, classe proposant les services de base d'un émetteur PTP, qui implémente une méthode d'envoi de messages. Ces messages sont de type NewsMessage, héritant de JMSMessage, disposant en plus d'un champ enregistrant le groupe auquel appartient le message. Une fois arrivé au serveur de groupes via le Replyer, l'en-tête du message (date et heure d'envoi et titre du message) est stocké dans une HashMap ayant comme clé le nom du groupe et comme objet un vecteur d'en-têtes. Le message en lui-même sera enregistré dans une autre HashMap ayant comme clé l'en-tête du message et comme objet le message complet. Quant à NewsSubscriber, il s'appuie sur le domaine Request/Reply pour télécharger les messages à lire, en utilisant une classe MessagesRequester héritant de Requester et implémentant une fonction d'envoi de messages. Afin de télécharger la liste des en-têtes de messages d'un groupe, le message "headers?<nom_du_groupe>" est émis au GroupServer qui renverra un vecteur contenant ces en-têtes stockés dans un de ses HashMap. Le téléchargement d'un message se fait par la requête "msg?<en-tête>". Celui-ci sera envoyé par le GroupServer qui ira le chercher dans la HashMap correspondante. 4. Bilan sur JMSNews Cette approche de type "newsgroup" nous a permis d'appréhender le troisième domaine de JMS, Point-To-Point. Il s'est avéré que ce domaine s'approchait très fortement du Request/Reply, notamment par l'utilisation de queues. En fait, la principale différence réside dans l'absence de réponse dans le domaine PTP. Concernant JMSNews, une amélioration possible pourrait être la séparation de GroupServer en deux entités distinctes. De plus, une gestion dynamique des groupes (création, suppression) se révèlerait intéressante. 10
V. Bilan global Pour conclure, ce projet nous a permis de découvrir une nouvelle facette de la programmation Java en utilisant le serveur d'application JBoss et la technologie d'envoi de messages JMS. Cette programmation par messages, que nous ne connaissions pas et dont l'intérêt ne nous semblait pas si évident au premier abord, s'est révélée très enrichissante. Comme nous l'avons vu dans les bilans intermédiaires, des améliorations de JMSChat et JMSNews sont possibles. Néanmoins, nous sommes satisfaits d'avoir pu produire des applications pleinement fonctionnelles. * * * 11