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.