Messaging
Transcription
Messaging
Messaging Part II : Java Messaging Service (JMS) La Connexion J MS (Java Messaging Service) est la solution proposée par SUN pour l’accès aux brokers de messages depuis des applications Java. JMS est une sous-partie de la spécification J2EE (Java 2 Enterprise Edition), son implémentation par les éditeurs de produits J2EE est aujourd’hui facultative mais devrait probablement rapidement devenir obligatoire. JMS est une API constituée d’un ensemble de classes et interfaces facilitant l’accès et l’implémentation de services de Messaging en Java. Contrairement à ce qui se passe pour le reste de la plate forme J2EE (EJBs, Servlets, JSP), il n’existe pas d’implémentation de référence pour JMS il faut donc se tourner vers des produits commerciaux pour évaluer cette technologie. Le principal avantage de JMS réside dans le fait qu’en standardisant les interfaces d’accès aux brokers de messages les applications deviennent beaucoup moins dépendantes de ceux-ci. Il est en effet très simple de changer le broker utilisé car les modifications à apporter dans le code sont minimes. Les mécanismes d’envoi et de réception de messages deviennent indépendants du broker utilisé. La connexion au broker de message se fait par l’intermédiaire de l’interface javax.jms.Connection. Il existe deux sortes de connexions, une pour le mode point à point QueueConnection, et une pour le mode Publication/Abonnement TopicConnection. Cela signifie qu’une application souhaitant utiliser les deux modes devra ouvrir deux connections distinctes. QueueConnection et TopicConnection sont bien-sûr des sousinterfaces de javax.jms.Connection. Le rôle de l’objet connexion est d’assurer la liaison entre le broker de messages et l’application, c’est lui qui s’occupe de la couche transport de données. Le plus souvent le transport des données se fera par l’intermédiaire d’un socket et d’un protocole propriétaire. Il existe cependant des variantes avec par exemple l’utilisation de CORBA (protocole IIOP). La connexion est crée par une Connection Factory récupérée par l’intermédiaire d’un contexte de nommage JNDI. import javax.jms.TopicConnection; import javax.jms.TopicConnectionFactory; ... Présentation de Java Messaging Service JMS fournit un support pour la quasi-totalité des services que rendent les brokers de messages du marché à savoir : • Les messages persistants • Les messages transactés et non-transactés • Le mode de communication synchrone Requête/ Réponse • Les modes de communication asynchrones par File (Queue) et Rubrique (Topic) JMS est composée de classes et d’interfaces localisées dans le package javax.jms et ses descendants. Ces classes sont fournies avec les implémentations de JMS. L’API JMS définit des entités qui servent à la communication avec les brokers de message. Ces entités sont les suivantes : • Connection • Session • Message • MessageProducer • MessageListener Regardons de plus près chacune d’entre elles en détail. TopicConnectionFactory tcf = (TopicConnectionFactory)context.lookup("MyTConnectionFactory"); TopicConnection tc = tcf.createTopicConnection(); ... > Acquisition d'une TopicConnection import javax.jms.QueueConnection; import javax.jms.QueueConnectionFactory; ... QueueConnectionFactory qcf = QueueConnectionFactory)context.lookup("MyQConnectionFactory"); QueueConnection qc = qcf.createQueueConnection(); ... > Acquisition d'une QueueConnection La session La session est un contexte d’accès aux services d’envoi et de réception de messages. La session utilise les services d’une connexion. Il peut exister plusieurs sessions par connexion. Dans une application multithreads, il sera possible d’utiliser une connexion unique, à condition de créer une session par thread, et ceci, afin de protéger la connexion des accès concurrents. La Tous droits réservés - © Copyright 2000-2001 Neoxia S.A. session joue aussi un rôle dans l’utilisation des transactions car c’est elle qui possède les méthodes commit et rollback. La session s’acquiert à partir de la connexion. Il faut, dès sa création, spécifier si on souhaite utiliser ou non des transactions. Il n’est ensuite plus possible de revenir sur ce choix. Il existe un type de session par mode de communication, QueueSession pour le mode point à point et TopicSession pour le mode publication/ abonnement. sortes de Message Producers, les QueueSenders pour les files et les TopicSenders pour les rubriques. Ces messages producers sont dédiés à une ressource précise (file ou rubrique). Si l’on souhaite envoyer des messages sur plusieurs files, il faudra donc plusieurs QueueSender. QueueSession qs ; ... Queue q = (Queue)ctx.lookup("example/MQueues/queue1"); QueueSender qsd = qs.createSender(q); import javax.jms.TopicSession; javax.jms.TextMessage textMsg = qs.createTextMessage(); ... textMsg.clearBody(); TopicSession ts = tc.createTopicSession(false, textMsg.setText(this.jTextField1.getText()); Session.AUTO_ACKNOWLEDGE); ... qsd.send(textMsg); > Acquisition d'une TopicSession > Exemple d'utilisation d'un Message Producer et envoi d'un message import javax.jms.QueueSession; ... QueueSession qs = tc.createQueueSession(false, La réception de messages : Les Messages Listeners De la même façon que les Messages Producers, les Messages Listeners sont spécifiques au mode de communication utilisé. Il existe des TopicSubscriber pour les rubriques et des QueueReceiver pour les files. Avec JMS, la réception des messages peut se faire de deux manières différentes : Session.AUTO_ACKNOWLEDGE); ... > Acquisition d'une QueueSession Les messages Les messages JMS doivent obligatoirement implémenter l’interface javax.jms.Message ou l’une de ses sousinterfaces. Les messages possèdent trois parties distinctes : l’entête (header), des méta-données (properties) optionnelles et le contenu proprement dit du message. L’entête contient les informations nécessaires à l’acheminement du message par le broker (expéditeur, destinataire, durée de vie, …). Les méta-données, quant à elles, servent pour le filtrage éventuel des messages dans une file (queue) ou une rubrique (topic). Il existe cinq sous-interfaces de javax.jms.Message : • javax.jms.BytesMessage pour la transmission de données binaires sous forme de tableau d’octets. • javax.jms.TextMessage pour la transmission de messages textuels. • javax.jms.ObjectMessage pour la transmission d’objets java. Attention l’objet transmis doit être serialisable. • javax.jms.MapMessage pour la transmission de tableaux associatifs. Attention, ici aussi tous les objets contenus dans la Map doivent être serialisables. • javax.jms.StreamMessage pour transmettre, avec un message, le contenu d’un flux. Il est bien entendu possible de créer ses propres types de messages, mais attention car ces nouveaux messages devront être connus à la fois des expéditeurs mais aussi des destinataires. • Le mode de réception synchrone Dans ce mode, le récepteur utilise la méthode receive pour se mettre à l’écoute de l’arrivée d’un message. Tant qu’aucun message n’est arrivé, la méthode receive ne retourne pas de résultat. Il s’agit donc d’un appel bloquant pour le thread appelant. ... Topic t = (Topic)ctx.lookup("example/MQueues/topic1"); TopicSubscriber tsub = ts.createSubscriber(t); javax.jms.TextMessage textMsg = javax.jms.TextMessage)tsub.receive(); ... > Exemple de réception en mode synchrone • Le mode de réception asynchrone Avec ce mode, la réception des messages se fait par l’intermédiaire d’une callback préalablement enregistrée. Celle-ci s’exécute dans un thread différent de celui utilisé pour l’enregistrement. Ce mode présente l’avantage de ne pas bloquer inutilement le thread principal. ... javax.naming.Context ctx = new javax.naming.InitialContext(null); QueueConnectionFactory qcf = (QueueConnectionFactory)ctx.lookup("example/MQueueFactory"); L’envoi de messages : les Messages Producers La création et l’envoi de messages se font par l’intermédiaire de Message Producers. Il existe deux QueueConnection qc = qcf.createQueueConnection(); QueueSession qs = qc.createQueueSession(false, javax.jms.Session.AUTO_ACKNOWLEDGE); Tous droits réservés - © Copyright 2000-2001 Neoxia S.A. Queue q = (Queue)ctx.lookup("example/MQueues/queue1"); QueueReceiver qr = qs.createReceiver(q); qr.setMessageListener(this); ... standard avec le SGBDR Cloudscape pour le stockage des messages persistants. Les outils d’administration qui sont livrés comprennent une ligne de commande et une console graphique. Des fonctions de statistiques sont également disponibles. public void onMessage(javax.jms.Message message) { try { this.counter++; this.jLabel1.setText(String.valueOf(this.counter)); this.jLabel2.setText("Last message: " + ((javax.jms.TextMessage)message).getText()); } catch(Exception ex) { ex.printStackTrace(); > Figure 1 : La console d'administration de SONIC_MQ. } } > Exemple de réception en mode asynchrone JMS et les serveurs d'application Les services de Messaging sont le complément idéal des serveurs d’applications pour plusieurs raisons. D’abord, ils sont utilisés depuis longtemps dans les entreprises, il existe donc une base installée importante. Les systèmes d’information devant évoluer de façon progressive, la mise en place de serveurs d’applications doit se faire en tenant compte de l’existant. Ensuite, on ne trouve pas aujourd’hui, parmi les offres de serveurs d’applications disponibles, d’alternatives au brokers de messages pour la communication asynchrone. La tendance est même à l’intégration des MOM dans les serveurs d’application. C’est donc tout naturellement que SUN a prévu la communication entre ses composants distribués (les EJBs) et les brokers de messages. Il est en effet indispensable de disposer de moyens de connexion spécifiques entre EJB et brokers pour plusieurs raisons. Premièrement, l’accès au broker se fait par l’intermédiaire d’un socket TCP/IP, or ce type de programmation (l’accès aux ressources systèmes) est interdit dans le corps d’un EJB. Ensuite, les EJB étant des composants serveurs, il est possible qu’un grand nombre d’instances soient créées. Si chaque instance utilise une connexion au broker de message, les performances s’effondrent. Il faut donc un mécanisme de pooling pour gérer les accès (de la même manière que pour les accès aux bases de données). Concrètement, l’utilisation d’un MOM depuis un EJB passe par des classes qui gèrent un pool de connexions. Ces classes doivent être implémentées par le fournisseur du serveur d’application. Les implémentations du marchés SonicMQ de Progress Software Ce broker de messages est probablement un des plus rapides du marché dans le monde Java. Il est livré en Il existe de nombreuses extensions pour ce produit, on peut citer : • Un pont avec le protocole FTP. • Un pont avec MQ Series d’IBM • Un pont avec l’API JavaMail • Un pont vers d’autres implémentations de JMS. Une version d’évaluation de SonicMQ est disponible sur le site de l’éditeur. > Figure 2 : Les fonctions de statistiques de SONIC_MQ. VisiMessage de Borland Comme l’indique son nom (avec le préfixe Visi), ce produit appartient à la gamme de produits de VisiBroker, l’ORB CORBA de la société Borland. Cela signifie que VisiMessage utilise le protocole IIOP comme couche de transport des messages et que ses services sont accessibles via CORBA en plus de l’API JMS. VisiMessage est livré en standard avec le serveur d’application de Borland : Borland Application Server 4.5 (BAS 4.5). Celui-ci comprend outre VisiMessage les produits et services suivants : • ORB Corba VisiBroker • Un conteneur d’EJBs • Un serveur Web • Un moteur de servlets • Une base de données relationnelle (JDataStore) • Un moniteur transactionnel Tous droits réservés - © Copyright 2000-2001 Neoxia S.A. l’arrivée de nouveaux messages. Par ailleurs ces EJBs n’ont pas d’état (stateless). > Figure 3 : La console d'administration de VisiMessage. L’administration de VisiMessage se fait par l’intermédiaire de la console d’administration de BAS. Une version d’évaluation de BAS 4.5 est disponible sur le site de Borland. > Figure 4 : Les ressources de VisiMessage vues à travers le service de nommage de CORBA. Autres implémentations On peut également citer le produit de BEA (MessageQ) ou SwiftMQ, un broker de message gratuit qui fonctionne sans SGBDR. Il existe également des adaptateurs qui permettent l’utilisation de MQ Series d’IBM ou de Tibco Rendez-vous à partir de l’API JMS. > Figure 5 : Diagramme d'état d'un Message Driven Bean. Conclusion L’approche choisie par Sun pour la prise en charge du Messaging sur la plate-forme Java s’avère aujourd’hui payante si l’on en juge par le nombre d’implémentations disponibles sur le marché et la notoriété des éditeurs qui l’ont choisi (IBM, BEA, Borland, …). Les services de Messaging ont probablement encore de beaux jours devant eux avec l’avènement du B2B et les inter-connexions de plus en plus nombreuses entre systèmes d’informations. L’arrivée de frameworks spécialisés pour le B2B, basés sur l’échange de messages comme ebXML, devrait encore accentuer cette tendance. Le standard JMS devrait donc être un acteur majeur dans le monde des brokers de message. Dans un prochain article sur le Messaging nous aborderons la vision de Microsoft à travers l’offre actuellement disponible sous Windows avec MSMQ/COM+ et celle à venir à travers la future plateforme .Net en cours de bêta test. L'auteur : Médéric MOREL L'avenir de JMS Une nouvelle mouture de JMS est actuellement en cours de préparation. Elle se caractérise par une intégration beaucoup plus étroite avec les autres produits de la gamme J2EE. On notera en particulier deux nouveautés majeures. Le support de XA : il s’agit d’un protocole de propagation de contextes transactionnels entre processus. XA permet le support de transactions distribuées entres des SGBDR, des conteneurs d’objets (EJB) et des brokers de messages. Aujourd’hui le support de XA dans JMS est optionnel. Les Messages Driven Beans : il s’agit d’un nouveau type d’EJB qui vient compléter les EJB Session et les EJB Entity. Ces nouveaux EJBs sont destinés au traitement de messages arrivants dans une file (Queue). Ils se caractérisent par une méthode unique de traitement de message et par l’absence d’interface Home pour leur instanciation. En effet, celle-ci se fait automatiquement à Vous retrouverez l'ensemble des publications de Neoxia sur www.neoxia.com Vous pouvez être informé par mail de la parution des nouveaux articles Neoxia en vous inscrivant sur www.neoxia.com/fr/subscribe.php3 Il existe une liste de diffusion consacrée à l'architecture J2EE. Pour vous y abonner, référez vous à l'URL suivante http://www.neoxia.com/fr/mailinglists.php3 Tous droits réservés © Copyright 2000-2001 Neoxia S.A. Le présent article a été publié dans le numéro #30 de la revue "Programmez !" (groupe Sepcom) Tous droits réservés - © Copyright 2000-2001 Neoxia S.A. Références Le site de JMS http://java.sun.com/products/jms/index.html Progress Software Sonic MQ – http://www.progress.com/sonicmq/index.htm Neoxia Borland VisiMessage – http://www.borland.com/appserver/ techconsulting SwiftMQ - http://www.swiftmq.com/ BEA MessageQ http://www.bea.com/products/messageq/datasheet.sht ml IBM MQ Series - http://www4.ibm.com/software/ts/mqseries/ Tibco Rendezvous – http://www.tibco.com/products/rv/index.html 41, rue Boissy d'Anglas F-75008 Paris T +33 (0) 158.18.38.96 F +33 (0) 158.18.38.99 [email protected] www.neoxia.com Tous droits réservés - © Copyright 2000-2001 Neoxia S.A.