tutorial su jms java message service 2979
Post on 03-Jul-2015
101 Views
Preview:
TRANSCRIPT
RUGGERO RUSSO 2
JavaJava MessageMessage ServiceService
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 3
MessaggioMessaggio
In ambito JMS, un messaggio è un raggruppamento di dati che viene inviato daun sistema ad un altro
I dati sono solitamente utilizzati per notificareeventi e sono pensati per essere utilizzati daun 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 4
MessagingMessaging SystemSystem
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 messaggisticadifferisce 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 5
MessagingMessaging System (2)System (2)
E’ basato su paradigma peer-to-peer: un client può ricevere e spedire messaggi a qualsiasi altro clientattraverso 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 messagingsystem 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 6
MessagingMessaging System (3)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 devonoconoscere è il formato (message format) e la destinazione (destination) del messaggio
RUGGERO RUSSO 7
MessagingMessaging SystemSystem (4)(4)
ORB
CLIENT SERVER
Modello
ORB
(RMI)
Message system
CLIENT SERVER
destination
MODELLO
MESSAGE
ORIENTED
RUGGERO RUSSO 8
JMSJMS –– GeneralitGeneralitàà
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 9
JMSJMS –– GeneralitGeneralitàà (2)(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 10
Relazioni di JMS con Relazioni di JMS con Altre Java APIAltre 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 11
Architettura JMSArchitettura 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 12
AdministeredAdministered ObjectsObjects
Connection Factory: oggetto utilizzato da un clientper 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 13
AdministeredAdministered ObjectsObjects(2)(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 14
Architettura JMS (2)Architettura JMS (2)
Administrative
tools bind
JNDI Namespace
Dest CF
JMS Clientlookup
Logical
connection
JMS Provider
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 15
Modelli di Modelli di messagingmessaging(domini)(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 16
PointPoint--toto--pointpoint domaindomain
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 17
PointPoint--toto--pointpoint domaindomain(2)(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 18
PointPoint--toto--pointpoint domaindomain(3)(3)
PRODUCERCONSUMERQUEUE
INVIA
PRELEVA
NOTIFICA
CONSUMER
RUGGERO RUSSO 19
PublishPublish//SubscribeSubscribedomaindomain
Nel modello publish/subscribe (pub/sub) il producerpuò spedire un messaggio a molti consumers (One toMany), 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 20
PublishPublish//SubscribeSubscribedomaindomain (2)(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 21
PublishPublish//SubscribeSubscribedomaindomain (3)(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
22
PublishPublish//SubscribeSubscribedomaindomain (4)(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
RUGGERO RUSSO 23
PublishPublish//SubscribeSubscribedomaindomain (5)(5)
PRODUCERCONSUMER
TOPICINVIA
consegna
CONSUMER
CONSUMER
consegna
consegna
sottoscrive
24
ModalitModalitàà di ricezionedi 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 providerconsegna il messaggio chiamando il metodo “onMessage” del listener
RUGGERO RUSSO 25
Attori JMSAttori JMS
Administered Objects: ConnectionFactory Destination
Connection Session MessageProducer Message MessageConsumer
RUGGERO RUSSO 26
Connection FactoryConnection 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 27
Connection Factory (2)Connection Factory (2)
Nel caso di dominio point-to-point si utilizza l’interfaccia QueueConnectionFactory
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 deibinding 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
Context ctx
QueueConnectionFactory
(QueueConnectionFactory)ctx.look
= new InitialContext();
queueConnectionFactory =
up("MyQueueConnectionFactory");
RUGGERO RUSSO 28
Connection Factory (3)Connection Factory (3)
Nel caso di dominio publish/subscribe si utilizza l’interfaccia TopicConnectionFactory
Context ctx
TopicConnectionFactory
(TopicConnectionFactory)ctx.look
= new InitialContext();
topicConnectionFactory =
up("MyTopicConnectionFactory");
RUGGERO RUSSO 29
DestinationDestination
È 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_HOME\server\default\deploy(nella console di jboss appare la nuova coda)
RUGGERO RUSSO 30
miaCoda.service.xmlmiaCoda.service.xml
<server>
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=miaCoda">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
</server>
RUGGERO RUSSO 31
LookupLookup delledelleDestinationDestination
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 destinationfacendone il casting al tipo di destinazione utilizzato
Queue queue = (Queue) jndiContext.lookup(“miaCoda");
Topic topic = (Topic) jndiContext.lookup(“mioTopic");
RUGGERO RUSSO 32
ConnectionConnection
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 SessionObject)
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)
33
Connection (2)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 QueueConnectionsull’oggetto ConnectionFactory:
QueueConnection queueConnection = queueConnectionFactory.createQueueConnection();
TopicConnection topicConnection = topicConnectionFactory.createTopicConnection();
publish/subscribe domain: si ottiene un reference d’interfaccia TopicConnection
invocando il metodo createTopicConnection() sull’oggettoConnectionFactory:
34
Ciclo di vita delle Ciclo di vita delle ConnessioniConnessioni
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
RUGGERO RUSSO 35
SessionSession
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 topictemporanei (non gestiti amministrativamente)
Specifica il tipo di comunicazione (con notifica o meno)
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
36
MessageMessage
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
37
MessageMessage HeaderHeader
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 getXXX().
38
MessageMessage -- HeaderHeader (2)(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
39
MessageMessage BodyBody
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 textmessage, 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)
40
MessageMessage Body (2)Body (2)
Un oggetto message viene creato per mezzo dei metodi create<messageType>() fornitidall’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
41
MessageMessage ProducerProducer
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 producerdeve inviare i messaggi
Specializzando il tipo di messageProducer si ha:
QueueSender sender = queueSession.createSender(Coda);
TopicPublisher publisher = topicSession.createPublisher(Topic);
MessageProducer producer = session.createProducer(Mia_Coda);
MessageProducer producer = session.createProducer(Mio_Topic);
42
MessageMessage ConsumerConsumer
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
topicSubscriber
topicSession.createSubscriber(Topic);
receiver = queueSession.createReceiver(Coda);
subscriber =
MessageConsumer
MessageConsumer
consumer = session.createConsumer(Mia_Coda);
consumer = session.createConsumer(Mio_Topic);
RUGGERO RUSSO 43
ModalitModalitàà AsincronaAsincrona
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 cheimplementa l’interfaccia MessageListener
Utilizza il metodo onMessage() per definire le operazioni da effettuare all’arrivo di un messaggio
RUGGERO RUSSO 44
MessageMessage ListenerListener
Passi:
Generazione dell’oggetto listener
Settare l’oggetto listener creato passandolo come input al metodo setMessageListenerdell’oggetto Receiver
TopicListener topicListener = new TextListener();
QeueListener queueListener = new TextListener();
TopicSubscriber.setMessageListener(topicListener);
QueueReceiver.setMessageListener(queueListener);
45
MessageMessage ListenerListener
Il listener dopo essere stato connesso si mette in
ascolto di un messaggio avviando la connessione
All’arrivo di un messaggio viene invocato il metodo onMessage()
queueConnection.start();
topicConnection.start();
public class TextListener implements MessageListener {
public void onMessage(Message message) {
try {
if (message instanceof TextMessage) {
TextMessage txtMsg = (TextMessage) message;
System.out.println("Ricevuto: " + txtMsg.getText());
. . .
}
RUGGERO RUSSO 46
ModalitModalitàà SincronaSincrona
I prodotti di messaging sono intrinsecamente asincroni ma un MessageConsumer può ricevere i messaggi anche in modo sincrono
Il consumer richiede esplicitamente alladestinazione 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 47
ModalitModalitàà Sincrona (2)Sincrona (2)public Message receive() throws JMSException
public Message receive(long timeout) throws
JMSException
Esempio di ricezione sincrona:
while(<condition>) {
Message m = queueReceiver.receive(1000);
if( (m!=null)&&(m instanceof TextMessage) {
message = (TextMessage) m;
System.out.println("Rx:" + message.getText());
timeout
Indipendentemente dalla modalità di ricezione la
comunicazione viene conclusa invocando un’operazione di
close() sulla connessione
queueConnection.close();
topicConnection.close();
RUGGERO RUSSO 48
MessageMessage SelectorSelector
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 Stringche contiene un’espressione
RUGGERO RUSSO 49
Impostazione di Impostazione di MessageMessageSelectorSelector
I metodi createConsumer() ecreateDurableSubscriber() permettono di specificare un message selector, attraverso un opportuno argomento
La selezione dei messaggi avviene solamente sui valoricontenuti negli headers o nelle properties del messaggio. Nessuna selezione può esser fatta a livello di body delmessaggio da parte del provider JMS. Tale selezione può esser fatta invece a livello di applicazione
topicSubscriber subscriber = topicSession.createSubscriber(Topic,
String messageSelector);
RUGGERO RUSSO 50
DurableDurable SubscriberSubscriber
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 51
DurableDurable SubscriberSubscriber (2)(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 comandotopicSession.createDurableSubscriber(Mio_topic, userName)
Fino all’istante in cui viene cancellata con il comandotopicSession.unsubscribe()
Ciascuna durable subscription può avere un solo subscriber attivo per volta
RUGGERO RUSSO 52
DurableDurable SubscriberSubscriber (3)(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 53
DurableDurable SubscriberSubscriber (4)(4)
Legenda:
creazione di un subscriber chiusura di una sottoscrizione
creazione di un durable subscr. Unsubscribe durable subscr.
M1 M2 M3
RUGGERO RUSSO 54
DurableDurable SubscriberSubscriber (5)(5)
In t0 un subscriber ordinario ed uno durable vengonocreati
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 55
ESEMPIESEMPI
RUGGERO RUSSO 56
PointPoint--toto--pointpoint
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&name=jboss.mq%3Aservice%3DDestinationManager)
Creazione delle connection factory editando il file jndi.properties
RUGGERO RUSSO 57
miaCoda.service.xmlmiaCoda.service.xml
<server>
<mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=miaCoda">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager
</depends>
</mbean>
</server>
RUGGERO RUSSO 58
Jndi.propertiesJndi.properties
#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)
Modalita’ 1
RUGGERO RUSSO 59
PointPoint--toto--pointpoint
Passo2: compilare i file java Sender.java eReceiver.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 60
PointPoint--toto--pointpoint
Provare che: 1. Il messaggio resta memorizzato finché non c’è un
receiver che lo consuma2. 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 61
Pub/SubPub/Sub domaindomain
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=jboss.mq%3Aservice%3DDestinationManager)
Creazione delle connection factory editando il file jndi.properties
RUGGERO RUSSO 62
mioTopic.service.xmlmioTopic.service.xml
<server>
<mbean code="org.jboss.mq.server.jmx.Topic"
name="jboss.mq.destination:service=Topic,name=incendio">
<depends optional-attribute-name="DestinationManager">
jboss.mq:service=DestinationManager</depends>
</mbean>
</server>
RUGGERO RUSSO 63
Pub/SubPub/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 64
Pub/SubPub/Sub
Provare che: 1. I subscriber cominciano a ricevere messaggi dal
momento in cui sono attivi2. Se nessun subscriber è attivo il messaggio viene
perso3. I messaggi vengono inviati a tutti i subscriber attivi
e in ascolto sul topic specifico4. Provare il funzionamento di messaggi inviati su
topic differenti5. Provare il funzionamento dei selectors di subscriber
iscritti allo stesso topic
top related