Scenario di richiesta/risposta di IBM WebSphere MQ

Question

Attualmente sto lavorando a un progetto in cui è necessario interfacciarsi con un sistema IBM che comunica con il mondo esterno tramite WebSphere MQ. Ho bisogno di interrogare il sistema in modo "richiesta-risposta" usando le code, e lo farò attraverso un gestore code.

Tuttavia, non riesco a capire come funziona in termini pratici.

Dire che ho più istanze della stessa applicazione che inserisce un messaggio in una coda di richieste. Il messaggio riceve CorrelationId e MessageId all'uscita dall'applicazione e una proprietà ReplyToQueue viene impostata su ciascun messaggio per assicurarsi che il gestore code sappia su quale coda inserire la risposta.

Tuttavia, in che modo il gestore code gestisce la coda di risposta? Non vi è alcuna garanzia in merito alla tempistica delle risposte, quindi come è possibile che la risposta corretta ritorni all'istanza dell'applicazione che ha emesso la richiesta corrispondente?

Continuo a pensare a code di messaggi come una coda FIFO in cui i messaggi devono essere selezionati uno per uno. Tuttavia, ciò significherebbe che l'istanza A potrebbe scegliere una risposta intesa per esempio B. Ovviamente, questo non può essere il modo in cui funziona.

Poi, quando guardo l'API (com.ibm.mq.MQQueue) vedo che per prendere un messaggio che ho avuto la possibilità di fornire la CorrelationId e MessageId del messaggio di richiesta. Ciò significa che quando interrogo il gestore code per un messaggio (con questo set di ID), il gestore code esegue l'iterazione attraverso i messaggi nella coda e restituisce il messaggio corrispondente? Questo, d'altro canto, significherebbe che non stiamo parlando di una coda FIFO?

Answer 1

È prassi comune utilizzare CorrelationId per correlare i messaggi di richiesta e di risposta. Funziona in questo modo:

1) Supponiamo che ci siano due code, una coda di richiesta REQQ in cui i messaggi vengono inoltrati chiedendo a un'altra applicazione, applicazione di servizio, di prelevare ed elaborare e una RESPQ a cui l'applicazione di servizio invia le risposte.

2) L'applicazione richiedente (chiamiamola come REQAPP) inserisce un messaggio di richiesta (REQMSG) per richiedere la coda (REQQ). Prima di inviare il messaggio, REQAPP imposta la proprietà ReplyToQ sui messaggi a RESPQ. Quando viene inviato il messaggio di richiesta, il provider JMS aggiorna il messaggio inviato con un MessageId univoco. L'applicazione del richiedente memorizza nella cache questo MessageId univoco per un uso successivo.

3) Dall'altro lato del wold, l'applicazione di servizio recupera REQMSG da REQQ, legge la proprietà MessageId e ReplyToQ da quel messaggio, elabora la richiesta e prepara il messaggio di risposta appropriato RESPMSG. Quindi imposta la proprietà CorrelationId di RESPMSG sul MessageId letto dal REQMSG e pone la risposta a ReplyToQ.

4) La domanda richiedente durante la lettura risposte, utilizza il MessageId cache e di leggere messaggio di risposta

GET MESSAGE FROM RESPQ WHERE RESPMSG.CORRELATIONID==REQMSG.MESSAGEID 

Questo criterio di selezione imposta i criteri di selezione, come di seguito fa in modo che i messaggi di risposta corretta viene recuperato. La chiave qui è che l'applicazione di servizio deve impostare CorrelationId sul messaggio di risposta al messaggio MessageId del messaggio di richiesta.

Sebbene la coda sia di tipo FIFO, l'implementazione MQ fornisce il recapito dei messaggi su base Prioritaria in cui i messaggi con priorità alta vengono consegnati per primi o FIFO in base al quale viene inviato prima il messaggio in cima alla coda. I messaggi possono anche essere recuperati usando i criteri di selezione come spiegato nell'esempio sopra.

Spero che questo ha aiutato

Answer 2

risposta di Shashi è il posto giusto per molte situazioni, ed è di fatto il principale metodo di distribuzione di risposte tra i molteplici, relativamente a basso volume che richiede applicazioni.

Una scelta migliore per i servizi ad alto volume implicherebbe più RESPQ. È possibile fornire una RESPQ separata per ogni istanza di REQApp utilizzando le code dinamiche temporanee per ricevere RESPMsgs - ogni istanza di REQApp creerebbe il TDQ utilizzando la funzione MQOPEN e specificare il nome RESPQ nell'attributo ReplyToQ di ogni messaggio che invia .

Con questa configurazione non ci si deve preoccupare di sequenze e ID di correlazione, poiché i messaggi verranno restituiti ai singoli RespQ nello stesso ordine in cui vengono elaborati dall'applicazione di servizio.

Una nota importante è che i TDQ sono proprio questo: temporaneo. Quando l'applicazione OPENing chiude la coda, tramite MQCLOSE o terminando, tutti i messaggi nel TDQ vengono persi e non recuperabili. Se questo è un problema - che tutte le risposte devono essere elaborate indipendentemente da cosa - allora si vorrebbe allocare una volta una serie di code dinamiche permanenti (usando anche MQOPEN), una per ogni istanza di REQApp, e ogni istanza di REQApp deve riconnettersi a quella stessa coda ogni volta.

Spero che questo aiuti pure.