Tutorial su JMS (Java Message Service)

1. Java Message Service
ƒ Java message service (JMS) è l’insieme di
API che consentono lo scambio di messaggi
tra applicazioni Java distribuite sulla rete
ƒ La prima specifica JMS è stata rilasciata nel
1998, mentre l’ultima versione delle API è la
1.1 pubblicata nel 2002
ƒ La specifica è scaricabile dal sito della sun:
http://java.sun.com/products/jms/
RUGGERO RUSSO 2

2. Messaggio
ƒ In ambito JMS, un messaggio è un
raggruppamento di dati che viene inviato da
un sistema ad un altro
ƒ I dati sono solitamente utilizzati per notificare
eventi e sono pensati per essere utilizzati da
un programma su una macchina e non
direttamente da un utente umano
ƒ In un scenario distribuito un messaging
service può essere pensato come un
sistema distribuito di notifica di eventi
RUGGERO RUSSO 3

3. Messaging System
ƒ Con il termine messaging ci si riferisce ad un
meccanismo che consente la comunicazione
asincrona tra client remoti:
ƒ Un client invia un messaggio ad un ricevente (o ad un
gruppo di riceventi)
ƒ Il destinatario riceve il messaggio ed esegue le operazioni
corrispondenti, in un secondo momento
ƒ In questo senso un sistema di messaggistica
differisce da RMI in cui il mittente di un messaggio
(per esempio il client che invoca un metodo remoto,
che deve attendere la risposta dal server che
espone il metodo prima di continuare)
RUGGERO RUSSO 4

4. Messaging System (2)
ƒ E’ basato su paradigma peer-to-peer: un client può
ricevere e spedire messaggi a qualsiasi altro client
attraverso un provider:
ƒ Ciascun client si connette all’agente (gestore) della
messaggistica che fornisce gli strumenti per creare,
spedire, ricevere e leggere messaggi
ƒ In questo senso si può definire come messaging
system ogni sistema che consente la trasmissione di
pacchetti TCP/IP tra programmi client
ƒ Permette una comunicazione distribuita del tipo
loosely coupled (debolmente accoppiata)
ƒ Il mittente ed il ricevente, per comunicare, non devono
essere disponibili allo stesso tempo
RUGGERO RUSSO 5

5. Messaging System (3)
ƒ Grazie all’intermediazione del messaging agent (o
server) i client che inviano/ricevono messaggi non
hanno bisogno di avere conoscenza reciproca delle
caratteristiche dell’altro per poter comunicare
ƒ Differisce dalla comunicazione tightly coupled, e.g.
quella usata nel Remote Method Invocation (RMI),
che richiede ad un’applicazione client di conoscere i
metodi esposti su di un’interfaccia remota da un
applicazione server
ƒ Tutto ciò che il mittente ed il ricevente devono
conoscere è il formato (message format) e la
destinazione (destination) del messaggio
RUGGERO RUSSO 6

6. Messaging System (4)
ORB Modello
ORB
(RMI)
CLIENT SERVER
Message system
destination
MODELLO
CLIENT SERVER MESSAGE
ORIENTED
RUGGERO RUSSO 7

7. JMS – Generalità
ƒ Permettono comunicazioni di tipo:
ƒ Asincrono: il JMS provider consegna i messaggi al client
appena quest’ultimo si sia reso disponibile. Il provider li
consegnerà senza che il receiver abbia effettuato una
richiesta specifica
ƒ Affidabile: JMS può assicurare che un messaggio sia
consegnato una ed una sola volta.
ƒ Ulteriori livelli di robustezza sono garantiti in JMS:
ƒ Tramite il cosiddetto Guaranteed Message Delivery è
possibile prevenire una perdita di informazioni in caso di
malfunzionamento o di crash del message server,
rendendo i messaggi persistenti prima di essere recapitati
ai consumatori (per esempio mediante JDBC)
RUGGERO RUSSO 8

8. JMS – Generalità (2)
ƒ JMS non include:
ƒ Un sistema di Load balancing/Fault Tolerance: la
API JMS non specifica un modo in cui diversi
client possano cooperare al fine di implementare
un unico servizio critico
ƒ Notifica degli Errori
ƒ Amministrazione: JMS non definisce dei metodi
per la gestione di prodotti di messaggistica
ƒ Security: JMS non prevede API per il controllo
della privacy e dell’integrità del messaggio
RUGGERO RUSSO 9

9. Relazioni di JMS con
Altre Java API
ƒ Java DataBase Connectivity (JDBC) Software: per
garantire l’interazione con Data Base in modo
indipendente rispetto alla tecnologia sottostante
ƒ JavaBeans components
ƒ Enterprise JavaBeans Components: nella specifica
EJB 2.0 si definisce una forma asincrona di utilizzo
dei bean che vengono invocati quando un client JMS
invia un messaggio JMS
ƒ Java Naming and Directory Interface (JNDI): API
che fornisce i servizi di naming e directory (per
associare nomi a dati)
RUGGERO RUSSO 10

10. Architettura JMS
ƒ JMS Client: programma che manda o riceve i
messaggi JMS
ƒ Messaggio: ogni applicazione definisce un insieme
di messaggi da utilizzare nello scambio di
informazioni tra due o più client
ƒ JMS provider: sistema di messaggistica che
implementa JMS e realizza delle funzionalità
aggiuntive per l’amministrazione e il controllo della
comunicazione attraverso messaggi
ƒ Administered objects: sono oggetti JMS
preconfiguarti, creati da un amministratore ad uso dei
client. Incapsulano la logica specifica del JMS
provider nascondendola ai client, garantendo
maggiore portabilità al sistema complessivo.
RUGGERO RUSSO 11

11. Administered Objects
ƒ Connection Factory: oggetto utilizzato da un client
per realizzare la connessione con il provider
ƒ Destination (queue/topic): oggetto utilizzato da un
client per specificare l’origine del messaggio che
riceve o la destinazione del messaggio che invia
ƒ Sono sono vendor dependent, nel senso che la loro
implementazione specifica dipende dal provider del
servizio di messaggistica
ƒ Non sono gestiti all’interno del programma Java:
ƒ La creazione di ConnectionFactory e di Destination è
compito dell’amministratore JMS che deve inserirli all’interno
di un contesto JNDI in un opportuno namespace in modo
che possano essere recuperati da qualsiasi client mediante
le normali API JNDI
RUGGERO RUSSO 12

12. Administered Objects
(2)
ƒ Le interfacce JMS consentono allo sviluppatore di
astrarsi dai dettagli implementativi permettendo il
riutilizzo del codice al variare dell’implementazione
ƒ Per inviare messaggi (sender/publisher) o per
riceverli (receiver/subscriber), un’applicazione JMS
client utilizza i servizi JNDI per ottenere un oggetto di
tipo ConnectionFactory e uno o più oggetti di tipo
Destination (Queue o Topic)
ƒ Il “Naming” in JMS è gestito dall’amministratore di
sistema e non dai client al contrario di quanto accade
in RMI in cui alcune funzioni (e.g., bind) sono
espletate direttamente da server e client
RUGGERO RUSSO 13

13. Architettura JMS (2)
JNDI Namespace
Administrative
Dest CF
tools bind
up
ook
l
JMS Client
JMS Provider
Logical
connection
ƒ Gli AT associano (bind) agli oggetti destination e connection
factory un nome all’interno di un namespace attraverso le JNDI API
ƒI client JMS ricercano gli administered object (lookup) ed
instaurano una connessione logica ad essi tramite un JMS Provider
RUGGERO RUSSO 14

14. Modelli di messaging
(domini)
ƒ Point-to-point:
ƒ più client JMS possono condividere la stessa
destination (queue)
ƒ Un messaggio può essere consumato da un solo
destinatario
ƒ Permette una comunicazione uno-a-uno
ƒ Publish/Subscribe:
ƒ Un messaggio inserito nella destinazione (topic)
può essere inviato a tutti i destinatari (subscriber)
che si sono dichiarati interessati a riceverlo
ƒ Consente una comunicazione uno-a-molti
RUGGERO RUSSO 15

15. Point-to-point domain
ƒ Il modello di messaggistica point-to-point (PTP o p2p)
si basa sul concetto di coda, mittente (sender o
producer) e destinatario (receiver o consumer)
ƒ Ogni client JMS spedisce e riceve messaggi sia in
modalità sincrona che in modalità asincrona,
mediante canali virtuali conosciuti come “queues”
(code)
ƒ E’ un modello di tipo “pull- or polling-based”, ovvero i
messaggi vengono richiesti (prelevati) dalle code
anziché essere consegnati ai client in maniera
automatica
RUGGERO RUSSO 16

16. Point-to-point domain
(2)
ƒ Il modello PTP ha le seguenti caratteristiche:
ƒ Più produttori e più consumatori possono condividere la
stessa coda, ma …
ƒ Ogni messaggio ha solamente un “consumer”, ovvero
ogni messaggio può essere letto da un solo client
ƒ Mittente e destinatario non hanno nessuna dipendenza
temporale
ƒ Il ricevente notifica l’avvenuta ricezione e
processemento del messaggio (acknowledge)
ƒ Utile quando è necessario garantire che un
messaggio arrivi ad un solo destinatario che notifica
la corretta ricezione
RUGGERO RUSSO 17

17. Point-to-point domain
(3)
CONSUMER
PRELEVA
PRODUCER
QUEUE CONSUMER
INVIA
NOTIFICA
RUGGERO RUSSO 18

18. Publish/Subscribe
domain
ƒ Nel modello publish/subscribe (pub/sub) il producer
può spedire un messaggio a molti consumers (One to
Many), attraverso un canale virtuale chiamato topic
ƒ Uno stesso topic può essere condiviso da più
consumer ed utilizzato da più publisher
ƒ Per ricevere i messaggi, i consumer devono
“sottoscriversi” ad un topic
ƒ Qualsiasi messaggio spedito al topic viene
consegnato a tutti i consumer sottoscritti, ciascuno
dei quali riceve una copia identica di ciascun
messaggio inviato al topic
RUGGERO RUSSO 19

19. Publish/Subscribe
domain (2)
ƒ E’ principalmente un modello “push-based”:
ƒ i messaggi vengono automaticamente inviati in
broadcast ai consumer, senza che questi ne
abbiano fatto esplicita richiesta
ƒ E’ previsto la possibilità di consegnare
messaggi provenienti da più publisher (multi
publishers)
ƒ Secondo il modello pub/sub non c’è
dipendenza tra il producer e i consumer:
ƒ E’ il JMS provider che realizza l’operazione di
dispatching dei messaggi a tutti i client sottoscritti
RUGGERO RUSSO 20

20. Publish/Subscribe
domain (3)
ƒ Il Publisher ed i subscribers hanno una dipendenza
temporale:
ƒ Un client che si sottoscrive ad un topic può consumare
solamente messaggi pubblicati dopo la sua sottoscrizione
ƒ Il subscriber può continuare a consumare messaggi solo nel
periodo in cui rimane attivo. Durante il periodo di inattività i
messaggi che dovesse ricevere andrebbero persi
ƒ Per ovviare al problema il client JMS può usare una
sottoscrizione durevole, che gli consente di
disconnettersi e riconnettersi in un secondo momento
consumando i messaggi pubblicati durante il periodo
di disconnessione
RUGGERO RUSSO 21

21. Publish/Subscribe
domain (4)
ƒ Un subscriber ha due modi per specificare i messaggi
che è interessato a ricevere:
ƒ tramite una stringa che ne indichi il nome (nel caso più
semplice)
ƒ per mezzo di condizione booleane sui suoi parametri
ƒ Il modello publish/subscribe prevede due tipi di
interazione:
ƒ topic-based: le informazioni vengono suddivise in
argomenti (topic o subject), le sottoscrizioni e le
pubblicazioni vengono fatte scegliendo come
discriminante un argomento e viene utilizzato un canale
logico ideale (topic) che connette un publisher ai
subscriber
ƒ content-based: utilizza dei filtri per una selezione più
accurata delle informazioni da ricevere
22

22. Publish/Subscribe
domain (5)
a CONSUMER
n
eg
s
on
c
consegna
PRODUCER TOPIC
CONSUMER
INVIA sottoscrive
co
ns
eg
na
CONSUMER
RUGGERO RUSSO 23

23. Modalità di ricezione
ƒ Un messaggio JMS può essere consumato secondo
due modalità:
ƒ Modalità sincrona: il subscriber (o il receiver)
prelevano direttamente il messaggio dalla coda
(operazione di fetch del messaggio), tramite
l’invocazione del metodo receive(). Il metodo è
sospensivo, il client rimane bloccato finché non arriva
il messaggio o fino allo scadere di un timeout
ƒ Modalità asincrona: il client si registra presso un
message listener attraverso un oggetto consumer. Se
un messaggio arriva alla destinazione, il JMS provider
consegna il messaggio chiamando il metodo
“onMessage” del listener
24

24. Attori JMS
ƒ Administered Objects:
ƒ ConnectionFactory
ƒ Destination
Connection
ƒ
Session
ƒ
MessageProducer
ƒ
Message
ƒ
MessageConsumer
ƒ
RUGGERO RUSSO 25

25. Connection Factory
ƒ E’ l’oggetto utilizzato dal client per realizzare una
connessione con il message server
ƒ Incapsula un insieme di parametri di configurazione definiti
dall’amministratore
ƒ Ogni oggetto connection factory è una istanza delle
interfacce:
ƒ ConnectionFactory
ƒ QueueConnectionFactory o TopicConnectionFactory
(dipendentemente dal dominio)
ƒ Per poter recuperare un riferimento ad un connection
factory, il client JMS deve eseguire all’inizio una operazione
di lookup JNDI dell’oggetto
RUGGERO RUSSO 26

26. Connection Factory (2)
ƒ Nel caso di dominio point-to-point si utilizza l’interfaccia
QueueConnectionFactory
Context ctx = new InitialContext();
QueueConnectionFactory queueConnectionFactory =
(QueueConnectionFactory)ctx.lookup(quot;MyQueueConnectionFactoryquot;);
ƒ Context è l’intefaccia base per la specifica di un naming
context. Definisce le operazioni base e.g. aggiungere e
rimuovere un binding nome-oggetto, fare il lookup ad un
oggetto associato ad uno specifico nome, fare la lista dei
binding etc.
ƒ Si crea un oggetto di tipo context
ƒ Si ottiene il contesto specifico dell’applicazione (con il
casting a QueueConnectionFactory)
ƒ Si recupera il riferimento logico all’oggetto con il metodo
lookup
RUGGERO RUSSO 27

27. Connection Factory (3)
ƒ Nel caso di dominio publish/subscribe si
utilizza l’interfaccia
TopicConnectionFactory
Context ctx = new InitialContext();
TopicConnectionFactory topicConnectionFactory =
(TopicConnectionFactory)ctx.lookup(quot;MyTopicConnectionFactoryquot;);
RUGGERO RUSSO 28

28. Destination
ƒ È l’administered object che rappresenta l’astrazione di
una particolare destinazione
ƒ Anche in questo caso il client identifica la destinazione
mediante l’utilizzo delle API JNDI
ƒ Nel caso point-to-point, la destinazione è
rappresentata dall’interfaccia Queue
ƒ Nel caso di publish/subscribe, si usa l’interfaccia Topic
In JBoss la definizioni delle destination e l’attribuzione di un nome
alle varie code utilizzabili è gestita “dall’amministratore
dell’applicazion server” utilizzando la console oppure creando e
modificando opportunamente il file miaCoda-service.xml
Inserire il file creato in <JBoss_HOMEserverdefaultdeploy
RUGGERO RUSSO 29
(nella console di jboss appare la nuova coda)

29. miaCoda.service.xml
<server>
<mbean code=quot;org.jboss.mq.server.jmx.Queuequot;
name=quot;jboss.mq.destination:service=Queue,name=miaCodaquot;>
<depends optional-attribute-name=quot;DestinationManagerquot;>
jboss.mq:service=DestinationManager
</depends>
</mbean>
</server>
RUGGERO RUSSO 30

30. Lookup delle
Destination
ƒ Un message client deve ottenere il riferimento alla
Destinazione invocando il metodo lookup passando
come input il nome della coda precedentemente
creato ed assegnandolo alla opportuna destination
facendone il casting al tipo di destinazione utilizzato
Queue queue = (Queue) jndiContext.lookup(“miaCodaquot;);
Topic topic = (Topic) jndiContext.lookup(“mioTopicquot;);
RUGGERO RUSSO 31

31. Connection
ƒ Rappresenta l’astrazione di una connessione attiva di
un JMS client con uno specifico JMS provider
ƒ Caratteristiche:
ƒ Incapsula una connessione aperta con il JMS provider
ƒ Generalmente è rappresentata da un socket TCP/IP aperta
tra client e provider
ƒ Crea una session (attraverso la creazione di un Session
Object)
ƒ Supporta opzionalmente un ExceptionListener
ƒ Una connection implementa l’interfaccia
ConnectionFactory.
ƒ In generale i client JMS utilizzano una sola
connessione; ma in casi di applicazioni più avanzate è
possibile far uso di più connessioni (e.g., un client che
fa da gateway tra due JMS provider)
RUGGERO RUSSO 32

32. Connection (2)
ƒ Dopo aver fatto il lookup di una connection factory, è
possibile creare un oggetto di tipo Connection
ƒ point-to-point domain:
ƒ Si ottiene un reference d’interfaccia QueueConnection
invocando il metodo create QueueConnection
sull’oggetto ConnectionFactory:
QueueConnection queueConnection =
queueConnectionFactory.createQueueConnection();
ƒpublish/subscribe domain:
ƒsi ottiene un reference d’interfaccia TopicConnection
invocando il metodo createTopicConnection() sull’oggetto
ConnectionFactory:
TopicConnection topicConnection =
topicConnectionFactory.createTopicConnection();
33

33. Ciclo di vita delle
Connessioni
Setup:
ƒ
ƒ Quando la connessione viene creata è inizialmente in modalità
stopped, in attesa che il setup sia concluso:
ƒ Nessun messaggio può essere ricevuto
Start:
ƒ
ƒ La connessione viene lanciata invocando su un oggetto
Connection il metodo start()
ƒ I messaggi cominciano ad essere prodotti e consumati
Pausa:
ƒ
ƒ La consegna di messaggi può essere temporaneamente interrotta
invocando il metodo stop()
ƒ L’invio di tutti i messaggi è interrotta indipendentemente dalla
modalità (sincrona, asincrona, tramite listener)
Chiusura:
ƒ
ƒ La connessione è definitivamente chiusa tramite il metodo close()
ƒ Le risorse sono rilasciate
ƒ Non si prevede un meccanismo per gestire l’ultimo messaggio
ƒ Se ci sono listener attivi la connessione rimane aperta fino alla fine
del loro processamento 34

34. Session
ƒ Una session viene creata a partire dall’oggetto
Connection
ƒ E’ il canale di comunicazione con una destinazione
ƒ E’ contesto entro cui vengono creati i producer, i
consumer ed i messaggi stessi
ƒ Fornisce un modo per creare queue e topic
temporanei (non gestiti amministrativamente)
ƒ Specifica il tipo di comunicazione (con notifica o
meno)
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
RUGGERO RUSSO 35

35. Message
ƒ Cositutito da:
ƒ Header (obbligatorio): contiene
informazioni sul messaggio
ƒ Property (opzionale): contiene
alcune proprietà opzionali del
messaggio solitamente utilizzate
per gestire la compatibilità tra
sistemi di messaggistica differenti.
ƒ I suoi campi sono esaminati dai
un consumer mediante i
message selectors
ƒ Body (opzionale): contiene la
parte informativa trasferita
all’interno del messaggio
36

36. Message Header
ƒ L'header del messaggio contiene un numero
predefinito di campi, i cui valori vengono utilizzati sia
dal client che dal provider JMS per identificare ed
instradare il messaggio
ƒ JMSMessageID è l’identificatore che rappresenta
univocamente il messaggio
ƒ JMSDestination è il campo in cui vengono specificati la
coda o il topic di destinazione al quale il messaggio è
stato spedito
ƒ JMSTimestamp indica l'istante in cui il messaggio è stato
lanciato
ƒ JMSExpiration individua il tempo massimo in cui il
messaggio può rimanere memorizzato in una coda
ƒ JMSPriority attribuisce valori di importanza differenti a
seconda del tipo e del contenuto del messaggio
ƒ I valori di ciascun campo dell'header sono impostati o
prelevati tramite metodi del tipo setXXX() e
37
getXXX().

37. Message - Header (2)
Header Field Set By
JMSDestination Metodi di send or publish
JMSDeliveryMode Metodi di send or publish
JMSExpiration Metodi di send or publish
JMSPriority Metodi di send or publish
JMSMessageID Metodi di send or publish
JMSTimestamp Metodi di send or publish
JMSCorrelationID Client
JMSReplyTo Client
JMSType Client
JMSRedelivered JMSD provider
38

38. Message Body
ƒ Il Body è la parte che veicola l'informazione del
messaggio. In generale un messaggio JMS può
essere di diversi tipi:
ƒ Text Message: messaggio testuale
ƒ Map Message :coppie nome/valore in cui il nome è una
stringa ed il valore è un tipo primitivo java
ƒ Byte Message :uno stream di bytes
ƒ Stream Message: uno stream di valori primitivi java
ƒ Object Message: un oggetto di tipo serializable
ƒ Message: costituito dai soli campi header e properties
ƒ Buona prassi: utilizzare dove possibile text
message, in cui il body del messaggio sia un file
xml contenente il contenuto informativo da
trasferire e informazioni accessorie di gestione
della comunicazione (e.g. allarm_JMS)
39

39. Message Body (2)
ƒ Un oggetto message viene creato per mezzo dei
metodi create<messageType>() forniti
dall’interfaccia session per la produzione di ogni
singola tipologia di messaggio.
ƒ e.g.: in un dominio point-to-point per creare un
messaggio di tipo TextMessage utilizziamo il
seguente codice:
TextMessage txtMsg = queueSession.createTextMessage();
txtMsg.setText(“Ciao!”);
producer.send(txtMsg);
Si invoca il metodo
[…] createTextMessage() su
un oggetto queueSession
specifico per il dominio ptp
40

40. Message Producer
ƒ Il MessageProducer è l’oggetto che ha il compito di
inviare messaggi ad una destination
ƒ Implementa l’interfaccia MessageProducer ed è
generato da un oggetto session attraverso il
metodo createProducer()passandogli come
input il nome logico della destination a cui il producer
deve inviare i messaggi
MessageProducer producer = session.createProducer(Mia_Coda);
MessageProducer producer = session.createProducer(Mio_Topic);
ƒ Specializzando il tipo di messageProducer si ha:
QueueSender sender = queueSession.createSender(Coda);
TopicPublisher publisher = topicSession.createPublisher(Topic);
41

41. Message Consumer
ƒ E’ l’oggetto che ha il compito di ricevere i messaggi
provenienti da una destination
ƒ Come nel caso precedente è necessario conoscere la
session e la destination per inizializzare un oggetto di
tipo messageConsumer:
queueReceiver receiver = queueSession.createReceiver(Coda);
topicSubscriber subscriber =
topicSession.createSubscriber(Topic);
MessageConsumer consumer = session.createConsumer(Mia_Coda);
MessageConsumer consumer = session.createConsumer(Mio_Topic);
42

42. Modalità Asincrona
ƒ E’ la modalità standard di trasmissione di messaggi
in JMS
ƒ Il messageProducer non è tenuto ad attendere che
il messaggio sia ricevuto per continuare il suo
funzionamento e non è previsto un meccanismo di
consumo sequenziale di messaggi
ƒ Per supportare il consumo asincrono dei messaggi,
viene utilizzato un oggetto listener che
implementa l’interfaccia MessageListener
ƒ Utilizza il metodo onMessage() per definire le
operazioni da effettuare all’arrivo di un messaggio
RUGGERO RUSSO 43

43. Message Listener
ƒ Passi:
ƒ Generazione dell’oggetto listener
TopicListener topicListener = new TextListener();
QeueListener queueListener = new TextListener();
ƒ Settare l’oggetto listener creato passandolo come
input al metodo setMessageListener
dell’oggetto Receiver
TopicSubscriber.setMessageListener(topicListener);
QueueReceiver.setMessageListener(queueListener);
RUGGERO RUSSO 44

44. Message Listener
ƒ Il listener dopo essere stato connesso si mette in
ascolto di un messaggio avviando la connessione
queueConnection.start();
topicConnection.start();
ƒ All’arrivo di un messaggio viene invocato il metodo
onMessage()
public class TextListener implements MessageListener {
public void onMessage(Message message) {
try {
if (message instanceof TextMessage) {
TextMessage txtMsg = (TextMessage) message;
System.out.println(quot;Ricevuto: quot; + txtMsg.getText());
...
} 45

45. Modalità Sincrona
ƒ I prodotti di messaging sono intrinsecamente
asincroni ma un MessageConsumer può ricevere i
messaggi anche in modo sincrono
ƒ Il consumer richiede esplicitamente alla
destinazione di prelevare il messaggio (fetch)
invocando il metodo receive
ƒ Il metodo receive() appartiene all’interaccia
javax.jms.MessageConsumer ed è sospensivo,
cioè rimane bloccato fino alla ricezione del
messaggio, a meno che non si espliciti un timeout
finito il quale il metodo termina
RUGGERO RUSSO 46

46. Modalità Sincrona (2)
public Message receive() throws JMSException
public Message receive(long timeout) throws
JMSException
Esempio di ricezione sincrona: timeout
while(<condition>) {
Message m = queueReceiver.receive(1000);
if( (m!=null)&&(m instanceof TextMessage) {
message = (TextMessage) m;
System.out.println(quot;Rx:quot; + message.getText());
Indipendentemente dalla modalità di ricezione la
comunicazione viene conclusa invocando un’operazione di
close() sulla connessione
queueConnection.close();
topicConnection.close();
RUGGERO RUSSO 47

47. Message Selector
ƒ Oggetti utilizzati per filtrare messaggi in arrivo,
permettendo ad un consumer di specificare quali
sono i messaggi di suo interesse sulla base delle
informazioni contenute all’interno dei campi
property del messaggio
ƒ Assegnano il lavoro di filtraggio al provider JMS
anziché all’applicazione
ƒ Il filtraggio avviene a livello di server e permette di
inoltrare ai client lungo la rete i messaggi strettamente
necessari o utili, risparmiando così la banda del canale
ƒ Un message selector è una oggetto di tipo String
che contiene un’espressione
RUGGERO RUSSO 48

48. Impostazione di Message
Selector
ƒ I metodi createConsumer() e
createDurableSubscriber() permettono di
specificare un message selector, attraverso un
opportuno argomento
topicSubscriber subscriber = topicSession.createSubscriber(Topic,
String messageSelector);
ƒLa selezione dei messaggi avviene solamente sui valori
contenuti negli headers o nelle properties del messaggio.
Nessuna selezione può esser fatta a livello di body del
messaggio da parte del provider JMS. Tale selezione
può esser fatta invece a livello di applicazione
RUGGERO RUSSO 49

49. Durable Subscriber
ƒ Guaranteed Message Delivery:
ƒ Modalità che consente di prevenire perdita di informazioni
in caso di malfunzionamento o crash del sistema di
messaging
ƒ E’ necessario rendere persistenti i messaggi inviati prima di
essere recapitati, utilizzando file o JDBC: metodologia
store-and-forward
ƒ Il meccanismo di store deve essere impostato e richiesto
dal client JMS mentre viene materialmente realizzato dal
provider JMS
ƒ Un topicSubscriber semplice, diversamente da un
queueReceiver può ricevere messaggi solo nel periodo di
tempo in cui rimane attivo
RUGGERO RUSSO 50

50. Durable Subscriber (2)
ƒ Per rendere un subscriber persistente (durable) è
necessario creare delle sottoscrizioni durevoli
(durable subscriptions) in grado di ricevere messaggi
anche se il subscriber non è all’ascolto al momento
della generazione del messaggio
ƒ La sottoscrizione persistente dura dall’istante di
tempo in cui viene creata con il comando
topicSession.createDurableSubscriber(Mi
o_topic, userName)
ƒ Fino all’istante in cui viene cancellata con il comando
topicSession.unsubscribe()
ƒ Ciascuna durable subscription può avere un solo
subscriber attivo per volta
RUGGERO RUSSO 51

51. Durable Subscriber (3)
ƒ La creazione della durable subcription richiede di definire
univocamente la sottoscrizione attraverso:
ƒ Un clientID che rappresenta univocamente la connessione
ƒ Un topic ed un nome che rappresenta l’identificativo del
subscriber
ƒ L’identificativo univoco associato al durable subscriber serve al
JMS server per memorizzare i messaggi arrivati mentre il
subscriber non è attivo.
ƒ Quando il subscriber si riconnette il JMS server provvede a
inviare tutti i messaggi ancora validi accumulati fino a quel
momento
ƒ JBoss crea un file
<JBoss_HOME/db/jbossmq/Topic.mioDurableTopic.idxy-
nome.dat0 in cui vengono memorizzati finoa 1000 messaggi in
attesa di essere consumati
RUGGERO RUSSO 52

52. Durable Subscriber (4)
M1 M3
M2
Legenda:
creazione di un subscriber chiusura di una sottoscrizione
creazione di un durable subscr. Unsubscribe durable subscr.
RUGGERO RUSSO 53

53. Durable Subscriber (5)
ƒ In t0 un subscriber ordinario ed uno durable vengono
creati
ƒ In t1 viene inviato un messaggio ricevuto da entrambi
ƒ In t2 entrambe le connessioni vengono chiuse
ƒ In t3 viene lanciato un nuovo messaggio che viene
perso per il subscr. ordinario e memorizzato per il
subscr. Persistente
ƒ In t4 i due ricevitori tornano attivi, il primo si metterà
in ascolto di un messaggio mentre il secondo riceve
M2 precedentemente memorizzato
ƒ In t6 entrambe le connessioni vengono chiuse
(notare l’operazione di unsubscribe nel caso durable)
RUGGERO RUSSO 54

54. ESEMPI
RUGGERO RUSSO 55

55. Point-to-point
Passo1: creazione degli administered objects
ƒ Creazione della queue editando il file xml
miaCoda-service.xml o utilizzando gli strumenti di
gestione di JBoss (all’indirizzo:
http://localhost:8080/jmx-
console/HtmlAdaptor?action=inspectMBean&nam
e=jboss.mq%3Aservice%3DDestinationManager)
ƒ Creazione delle connection factory editando il file
jndi.properties
RUGGERO RUSSO 56

56. miaCoda.service.xml
<server>
<mbean code=quot;org.jboss.mq.server.jmx.Queuequot;
name=quot;jboss.mq.destination:service=Queue,name=miaCodaquot;>
<depends optional-attribute-name=quot;DestinationManagerquot;>
jboss.mq:service=DestinationManager
</depends>
</mbean>
</server>
RUGGERO RUSSO 57

57. Jndi.properties
Modalita’ 1
#jboss jNDI properties
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=jnp://localhost:1099
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
Modalita’ 2:
inserire le istruzioni per la creazione dell’Administ. Object
direttamente nel codice della classe (vedi esempio)
RUGGERO RUSSO 58

58. Point-to-point
Passo2: compilare i file java Sender.java e
Receiver.java
Passo3: eseguire Sender e Receiver
NOTA: in macchine in cui non esiste JBoss è necessario utilizzare
alcuni jar aggiuntivi da inserire nel classpath (esempio javax.jms)
RUGGERO RUSSO 59

59. Point-to-point
Provare che:
1. Il messaggio resta memorizzato finché non c’è un
receiver che lo consuma
2. Se viene lanciato un receiver prima che un
messaggio sia inviato, quello si mette in ascolto
della coda in attesa di un messaggio
3. Se due receiver sono contemporaneamente attivi
solo uno riceverà effettivamente il messaggio
RUGGERO RUSSO 60

60. Pub/Sub domain
Passo1: creazione degli administered objects
Creazione della queue editando il file xml mioTopic-
ƒ
service.xml o utilizzando gli strumenti di gestione di
JBoss (all’indirizzo: http://localhost:8080/jmx-
console/HtmlAdaptor?action=inspectMBean&name=jb
oss.mq%3Aservice%3DDestinationManager)
Creazione delle connection factory editando il file
ƒ
jndi.properties
RUGGERO RUSSO 61

61. mioTopic.service.xml
<server>
<mbean code=quot;org.jboss.mq.server.jmx.Topicquot;
name=quot;jboss.mq.destination:service=Topic,name=incendioquot;>
<depends optional-attribute-name=quot;DestinationManagerquot;>
jboss.mq:service=DestinationManager</depends>
</mbean>
</server>
RUGGERO RUSSO 62

62. Pub/Sub
Passo2: compilare i file java Publisher.java e
Subscriber.java
Passo3: eseguire Publisher e Subscriber
NOTA: in macchine in cui non esiste JBoss è necessario utilizzare
alcuni jar aggiuntivi da inserire nel classpath (esempio javax.jms)
RUGGERO RUSSO 63

63. Pub/Sub
Provare che:
1. I subscriber cominciano a ricevere messaggi dal
momento in cui sono attivi
2. Se nessun subscriber è attivo il messaggio viene
perso
3. I messaggi vengono inviati a tutti i subscriber attivi
e in ascolto sul topic specifico
4. Provare il funzionamento di messaggi inviati su
topic differenti
5. Provare il funzionamento dei selectors di subscriber
iscritti allo stesso topic
RUGGERO RUSSO 64