Introduction À JMS 2e Partie

JMS (2me partie)
Annick Fron
fron@essi.fr
Http://www.afceurope.com
Printemps 2004
Annick Fron JMS 2me partie
Rappels du cours prcdent
JMS (javax.jms) permet de communiquer par

messages (non structurs : pas d'interface)
2 modes d'mission : point point, publish/subscribe
2 modes de rception : synchrone (receive bloquant),
asynchrone (MessageListener>>onMessage)
En PtoP, les messages sont consomms par le
destinataire (<->TCP)
En publish/subscribe, le subscriber doit tre actif au
moment du publish (<->UDP)
Printemps 2004
Plan : pour une architecture

robuste
JMS est souvent reconnu comme une architecture de
communication fiable ( la diffrence du mail) avec
une forte qualit de service dont :
Le filtrage de messages
Les priorits, la persistance
Durable subscribers
Les accuss de rception : service, applicatifs
Les transactions (pas de transactions en RMI)
Printemps 2004
Le filtrage de messages
Printemps 2004
Filtrage de messages
Filtre
Prop = 'blue'
Printemps 2004
Prop = 'green'
Prop = 'yellow'
Filtrage des messages en PtoP

Ct metteur
message.setStringProperty(" myProp ", " blue ");
Ct rcepteur
queueReceiver = session.createReceiver(ioQueue,
"myProp = 'blue'");
// attention aux quotes
Nota : il est impossible de modifier le slecteur du

receiver aprs cration
2 signatures possibles :
createReceiver (queue)
createReceiver (queue, selector)
O selector est une expression logique

Printemps 2004
Expressions logiques pour le

filtrage
Proprits types (String, long, boolean, byte, ...)
message.setStringProperty(propName,propValue);
message.setIntProperty(size,10000);
Sous-ensemble de SQL92 : attention aux quotes

(Country = 'UK') OR (Country = 'US') OR (Country =
'France')
age >= 15 AND age <= 19
Printemps 2004
Filtrage des topics en pubsub

On peut dfinir des jokers
sur les Topics (* pour IBM ou
Sonic)
On peut filtrer sur
l'arborescence
Exemples :
Tous les rsultats
Sport/Football/*/Resul
ts
Toutes les quipes
Sport/Football/* (IBM)
Sport.Football.*
(Sonic)
Printemps 2004
Qualit de service
Printemps 2004
Qualit de service
La qualit de service est la charge du serveur JMS

Elle varie selon les implmentations :
IBM Websphere MQ
Joram
OpenJMS
SonicMQ
SwiftMQ
Etc
Dans la mesure o elle est implmente, il est

possible de la paramtrer au niveau du code
Vrifier les fonctionnalits de l'outil choisi
Printemps 2004
10
Structure d'un message
Entte
JMSDestination, JMSDeliveryMode, JMSMessageId,
JMSExpiration, JMSPriority, etc.
Proprits
Couple <nom, valeur>
Corps
TextMessage, MapMessage
StreamMessage, ObjectMessage
BytesMessage
Note : le corps n'est pas structur. Souvent XML
Printemps 2004
11
Header d'un message

Champ du header
JMSDestination
JMSDeliveryMode
JMSExpiration
JMSPriority
JMSMessageID
JMSTimestamp
JMSCorrelationID
JMSReplyTo
JMSType
JMSRedelivered
Printemps 2004
Dfini par
send ou publish method
Client
Client
Client
JMS provider
12
Le header d'un message
Le header transporte des proprits de service

notamment la priorit, la dure de vie, le mode de
livraison (persistant ou non)
Tous ces lments peuvent tre dcrits :
globalement au niveau du MessageProducer
de manire intermdiaire au niveau du Message
de manire locale au moment de l'envoi
Toutefois, les outils implmentent l'un ou l'autre

niveau mais pas forcment tous
Le niveau de l'envoi est le plus fin (send)
Printemps 2004
13
Niveaux de qualit de service

send
send
Message
Producer
send
send
Printemps 2004
Message
Message
14
Envoi d'un message
2 interfaces d'envoi
sender.send(message),
send(Message message, int deliveryMode, int
priority, long timeToLive)
Idem publisher.publish(message)
Idem avec JMS 1.1 unifi : producer.send(...)
Printemps 2004
15
Les priorits
Les priorits vont de 0 (basse) 9 (haute) : dfaut 4

Les priorits d'un message sont dfinies dans le
3me argument lors d'un envoi
producer.send(message,
DeliveryMode.NON_PERSISTENT, 3, 10000);
Nota : l'API mentionne aussi

Au niveau du message
message.setJMSPriority(7); // pas dans Sonic
Pour tous les messages d'un producteur (sender/publisher)
producer.setPriority(7);// pas dans Sonic
Printemps 2004
16
Persistance d'un message
2 valeurs possibles :
DeliveryMode.NON_PERSISTENT (rare)
DeliveryMode.PERSISTENT (dfaut)
2me argument du send(resp. publish)

publisher.publish(message,
DeliveryMode.NON_PERSISTENT, 3, 10000)
Idem prcdemment pour l'API
Message
Message.setJMSDeliveryMode(DeliveryMode.PERSISTENT)
MessageProducer
producer.setDeliveryMode(...)
Printemps 2004
17
Nota
Le mode de persistance est la discrtion du serveur
de messages.
Si le serveur tombe, les messages non persistants
sont perdus, les autres sont renvoys lors de la
restauration du serveur
Smantique "one only"
"A message is guaranteed to be delivered once and only
once by a JMS provider if the delivery mode of the
message is PERSISTENT and if the destination has a
sufficient message retention policy."
Printemps 2004
18
Dfinition de la dure de vie d'un

message
Exprime en ms
0 : le message n'expire jamais, 10000 au bout de 10s
(10000 ms) : par dfaut n'expire jamais
4 me argument du send
topicPublisher.publish(message,
DeliveryMode.NON_PERSISTENT, 3, 10000)
Idem pour l'API
Aussi sur le producteur

producer.setTimeToLive(10000);
Message
Message.setJMSExpiration(10000)
Printemps 2004
19
Question
A quoi sert de dfinir la dure de vie d'un message ?
Printemps 2004
20
DurableSubscribers
Printemps 2004
21
Publish/subscribe
En point point, le message est consomm par le

destinataire, dans le dlai de son expiration
En publish/subscribe, le nombre de destinataires est
inconnu : impossible de dterminer qui va louper le
message ni combien d'acquittements attendre !
Seuls les abonns actifs l'envoi du message le
reoivent le message
Nota : c'est aussi li sans doute UDP
Printemps 2004
22
La dure vie des abonns
M3 - M4 pas reus !
Printemps 2004
23
Les ''durable subscribers''
On n'a manqu aucun pisode !

Printemps 2004
24
Principe des durable subscribers
Les abonns durables peuvent recevoir un topic

mme s'ils n'taient pas connects au moment de
l'envoi
Ceci permet la fiabilit du point point en mode
publish/subscribe
Bien sr au dpend des performances
Printemps 2004
25
Scnario
Un subscriber s'abonne un topic

Lorsque le publisher publie un topic, il le reoit
Il ne reoit plus rien s'il quitte et relance
Un Durable subscriber au contraire reoit tous les
messages la reconnection
Printemps 2004
26
Durable subscribers : principe

crer une ID client sur la connexion avant de l'ouvrir
conn.setClientID("maConnexion");
conn.start()
Envoyer le topic comme persistant
producer.send
(mess,DeliveryMode.PERSISTENT,4,30000);
crer un abonn durable (durableSubscriber) avec
une rfrence d'abonnement:
session.createDurableSubscriber(topic,
"monAbonnement");
Printemps 2004
27
Suppression d'un abonnement

Fermeture de l'abonn
topicSubscriber.close();
// optionnel en Sonic
Suppression de l'abonnement
topicSession.unsubscribe("monAbonnement");
Printemps 2004
28
Question
On peut prconfigurer la ConnectionFactory avec le

client ID.
Comment s'assurer que l'application se connecte
toujours avec le mme client ID ?
Printemps 2004
29
Le top de la qualit de service
Publish and Subscribe

Durable Subscriptions
Persistent Messages (DeliveryMode.PERSISTENT)
ExceptionListener for Connection Failure
setPingInterval sur la connection (heartbeat)
Printemps 2004
30
Rsum : durable subscribers
Permettent la fiabilit du point point en mode

publish/subscribe
Ncessitent un ID de connexion, une rfrence
d'abonnement
Printemps 2004
31
Accuss de rception
Printemps 2004
32
Smantique one only

Serveur
Retrait 200$
!Conn. timeout
Retrait 200$
Printemps 2004
33
En JMS
2 types d'accuss de rception :

accus de "service" indiquant l'infrastructure que le
message peut tre supprim ; il n'est pas vu de
l'application. Ils sont lis la dure de vie du
message, son mode de livraison (persistant ou
non), et au mode d'envoi (point point, pub/sub)
accus de rception applicatif en direction de
l'metteur, programm la main
Printemps 2004
34
Rappel : mode point point
Il ne peut y avoir qu'un seul consommateur.

Le message est ensuite retir aprs acquittement
Printemps 2004
35
Rappel : mode pub/sub
Pour les durable subscribers comme point point ,

pour les autres subscribers message retir en fin de session
Printemps 2004
36
Acknowledge
Pour savoir quand le message a t consomm, on

utilise un acknowledge : implicite ou par programme
Le type d'acknowledge est associ la Session lors

de sa cration
queueConnection.createQueueSession(
transacted,
Session.AUTO_ACKNOWLEDGE)
Printemps 2004
37
Question
Question : pourquoi la session, pas le message ?
Printemps 2004
38
Rappels Session
Une Session peut grer plusieurs

metteurs/rcepteurs, envois/rceptions : scnario
receive
session
receive
send
send
Printemps 2004
39
Note : connexions et sessions

Client
Session
Session
Il peut y avoir plusieurs

session dans une connexion
Une connexion est lie
un serveur (ex : maui)
Session
Connexion
Printemps 2004
40
Acknowledge
Printemps 2004
41
Accuss de rception de service
Plusieurs types d'accuss de rception :

Session.AUTO_ACKNOWLEDGE : accus
automatique
Session.CLIENT_ACKNOWLEDGE : accus explicite
Session.DUPS_OK_ACKNOWLEDGE : accus
retard, plusieurs accuss possibles
Printemps 2004
42
Diffrents types d'acknowledge
Session.AUTO_ACKNOWLEDGE :
Envoy ds que le rcepteur termine onMessage en
asynchrone, receive en synchrone
Session.CLIENT_ACKNOWLEDGE
L'acknowledge est global au niveau de la session (pour tous
les messages jusqu' prsent) et dclench explicitement
ct rception par :
message.acknowledge()
Printemps 2004
43
Diffrents types (suite)

Session.DUPS_OK_ACKNOWLEDGE
Accus de rception "paresseux"
A n'utiliser que par les rcepteurs qui peuvent
accepter des messages dupliqus
Minimise le travail de la session pour viter les
doublons
=> plus de smantique "one only"
Printemps 2004
44
Modes d'accuss de rception

Nouveau AUTO
message !
CLIENT
J'ai reu
50 messages
jusqu' prsent
Tu accapares
la bande
passante !
Que fais-tu ? Je viens
d'envoyer 50
messages
DUPS_OK
Paresseux si tu veux,
Tu m'obliges envoyer
mais n'importe
les messages plusieurs
si je reois 2 fois
fois !
Printemps 2004
45
Rgles de retrait
Quand une QueueSession (ou une TopicSession

avec DurableSubscribers) termine sans
acknowledgement
Le serveur garde le message pour le relivrer lors de
l'ouverture de la session suivante
Les messages sans accus d'un non-durable

subscriber (en mode pub/sub) sont retirs lors de la
fermeture de sa session
Printemps 2004
46
Session sans ack
Printemps 2004
47
Non ack recovery
Printemps 2004
48
Mode non persistant : ack OK
Printemps 2004
49
Mode non persistant : pas d'ack
Printemps 2004
50
Accuss de rception : rsum

Dfini au niveau de la session
createQueueSession(boolean transacted,
int acknowledgeMode)
3 types :
AUTO_ACKNOWLEDGE
CLIENT_ACKNOWLEDGE
DUPS_OK_ACKNOWLEDGE
Si l'acknowledge est explicite, le client doit crire :
message.acknowledge();
Printemps 2004
51
Accuss de rception applicatifs
Printemps 2004
52
Accuss de rception applicatifs

Emet/rcept A
Emet/rcept B
1
2
3
4
5
Est-ce que 3 est la rponse 1 ? 2 ?
Printemps 2004
53
Destinations temporaires
On peut utiliser des TemporaryQueues pour faire le

lien : analogie enveloppe dans une enveloppe
Ct envoyeur
message.setJMSReplyTo(session.createTemporaryQueue())
Ct client
producer = session.createProducer(msg.getJMSReplyTo());
replyMsg = session.createTextMessage("Consumer " +
"processed message: " + msg.getText());
replyMsg.setJMSCorrelationID(msg.getJMSMessageID());
producer.send(replyMsg);
Les destinations temporaires n'existent que le temps de

la
connexion qui lesAnnick
a cres
Fron JMS 2me partie
54
Printemps 2004
Destination pour la rponse

metteur
rcepteur
Printemps 2004
55
QueueRequestor
Il existe un framework plus systmatique :
QueueRequestor
Le QueueRequestor utilise 2 principes :
la destination de rponse (TemporaryQueue dfinie
dans getJMSReplyTo())
une corrlation d'ID (rappelez-vous du header !)
getJMSCorrelationID()
Printemps 2004
56
QueueRequestor : ct envoyeur
queueRequestor = new QueueRequestor

(queueSession, queue)
Il n'y a pas d'envoi explicite du message, mais au

contraire, attente d'une rponse :
reply = (TextMessage)
queueRequestor.request(message)
Ceci remplace :
sender.send(message)
Printemps 2004
57
QueueRequestor : ct rcepteur
On reoit le message normalement :

queueReceiver.receive()
On extrait du message une queue temporaire dfinie

implicitement par le requestor (enveloppe de retour) :
tempQueue = (Queue) message.getJMSReplyTo();
On envoie un message classiquement dans cette Queue en

prenant soin de fournir l'ID de corrlation :
replySender = queueSession.createSender(tempQueue);
reply = queueSession.createTextMessage(texte mess);
reply.setJMSCorrelationID(message.getJMSMessageID());
replySender.send(reply);
Printemps 2004
58
QueueReceptor(3) : retour
l'envoyeur
On vrifie l'ID de corrlation du message de dpart
replyID = new String

(reply.getJMSCorrelationID());
messageID = message.getJMSMessageID()
replyID.equals(messageID) // oui
Printemps 2004
59
Rsum : accuss de rception

applicatifs
Il est possible d'implmenter des accuss de

rception applicatifs en utilisant des destinations
temporaires
Le header du message transporte MessageId et
MessageCorrelationID
Le mcanisme de QueueRequestor offre un
framework plus complet et permet de s'assurer de la
corrlation de deux messages en sens inverses
Printemps 2004
60
Les transactions
Printemps 2004
61
Les transactions : principe
Une session peut tre transactionnelle

Ct metteur :
Les messages envoys ne sortent pas tant avant "commit"
Les messages envoys sont retirs si "rollback"
Ct rcepteur
Les messages reus ne sont pas acquitts avant "commit"
Les messages reus sont relivrs lors de "rollback"
Printemps 2004
62
Les transactions
La connection cre d'abord une (Q/T)session avec

transaction (transacted = true):
connexion.createQueueSession(true,
Session.AUTO_ACKNOWLEDGE)
On peut alors utiliser :
queueSession.commit();
queueSession.rollback();
Printemps 2004
63
Transaction
Les transactions sont conscutives

transaction1
transaction2
Commit/rollback
Il est trs difficile de grer des transactions gigognes
(nested transactions)
Printemps 2004
64
Transactions locales
Printemps 2004
65
Transactions (suite)
2 clients ne peuvent partager la mme

transaction. Par contre un producteur peut envoyer
un message plusieurs rcepteurs dans la mme
transaction
Printemps 2004
66
Transactions (suite)
On appelle toujours le rollback sur exception
catch (Exception e) {session.rollback();

}
Printemps 2004
67
Exemple typique : cohrence d'un

workflow
receive
commande
send
Service achats
livraison
transaction
session.createReceiver( commande );
receiver.receive();
session.createSender( livraison )
sender.send(...)
session.commit()
Printemps 2004
68
2 phases commit
Le 2-phase commit est une gnralisation sur

plusieurs transactions : pas de commit global tant que
pas tous les commits individuels
stockage
paiement
livraison
BD
eStore
Note : pour le two-phase commit, il est possible de
complter avec l'interface JTA/XA, mais Sun
recommande d'utiliser les services propritaires de
l'implmenteur.
XAQueueConnectionFactory
Printemps 2004
69
Transactions : rsum
Une session JMS peut tre transactionnelle
connexion.createQueueSession(true, 0)
commit et rollback concernent l'ensemble des
messages de la session
Souvent utilis en workflow
Il existe des extensions JTA/XA
(XAQueueConnexionFactory) pour le 2-phase commit
(Java Transaction API) y compris avec des BD
Printemps 2004
70
Conclusions
Le point fort de JMS est la smantique one and

only one ainsi que la qualit de service (Qos)
On peut dfinir des priorits de messages, des dures
de vie de messages, la persistance
Les accuss de rception de service dterminent la
rtention des messages
Il existe un framework applicatif d'accus de rception
JMS supporte les transactions (-> EJB et MessageDriven Beans)
Printemps 2004
71
Rfrences
http://www.hartmannsoftware.com/JMS_Tutorial.pdf
http://www-106.ibm.com/developerworks/java/library/j-jms
http://java.sun.com/products/jms/tutorial/
Printemps 2004
72

Introduction À JMS 2e Partie

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction À JMS 2e Partie

Uploaded by

Copyright:

Available Formats

JMS (2me partie)

Annick Fron JMS 2me partie

Rappels du cours prcdent

JMS (javax.jms) permet de communiquer par

Annick Fron JMS 2me partie

Plan : pour une architecture

Annick Fron JMS 2me partie

Annick Fron JMS 2me partie

Annick Fron JMS 2me partie

Filtrage des messages en PtoP

// attention aux quotes

Nota : il est impossible de modifier le slecteur du

O selector est une expression logique

Annick Fron JMS 2me partie

Expressions logiques pour le

Sous-ensemble de SQL92 : attention aux quotes

Annick Fron JMS 2me partie

Filtrage des topics en pubsub

Annick Fron JMS 2me partie

Annick Fron JMS 2me partie

La qualit de service est la charge du serveur JMS

Dans la mesure o elle est implmente, il est

Annick Fron JMS 2me partie

Structure d'un message

Note : le corps n'est pas structur. Souvent XML

Annick Fron JMS 2me partie

Header d'un message

Le header d'un message

Le header transporte des proprits de service

Toutefois, les outils implmentent l'un ou l'autre

Annick Fron JMS 2me partie

Niveaux de qualit de service

Annick Fron JMS 2me partie

Envoi d'un message

Annick Fron JMS 2me partie

Les priorits vont de 0 (basse) 9 (haute) : dfaut 4

Nota : l'API mentionne aussi

Annick Fron JMS 2me partie

Persistance d'un message

2me argument du send(resp. publish)

Idem prcdemment pour l'API

Annick Fron JMS 2me partie

Annick Fron JMS 2me partie

Dfinition de la dure de vie d'un

Idem pour l'API

Aussi sur le producteur

Annick Fron JMS 2me partie

A quoi sert de dfinir la dure de vie d'un message ?

Annick Fron JMS 2me partie

Annick Fron JMS 2me partie

En point point, le message est consomm par le

Annick Fron JMS 2me partie

La dure vie des abonns

Annick Fron JMS 2me partie

Les ''durable subscribers''

On n'a manqu aucun pisode !

Annick Fron JMS 2me partie

Principe des durable subscribers

Les abonns durables peuvent recevoir un topic

Annick Fron JMS 2me partie

Un subscriber s'abonne un topic

Annick Fron JMS 2me partie

Durable subscribers : principe