Le applicazioni possono utilizzare i servizi di un broker inviando ad esso messaggi e ricevendo da esso messaggi, attraverso uno dei protocolli di trasporto supportati.
Il modo in cui eseguono questa operazione dipende dal protocollo stesso, dall'interfaccia di programmazione che esse utilizzano e dal modello di comunicazione che esse adottano.
WebSphere Message Broker supporta due modelli di comunicazione dell'applicazione utente finale:
Una singola applicazione può combinare i due stili, se appropriato. In uno scenario misto, il flusso di messaggi che elabora i messaggi per questa applicazione contiene almeno un nodo di output e almeno un nodo Publication, oltre a uno o più nodi di input.
Le interfacce di programmazione che è possibile codificare nelle applicazioni sono descritte in API (application programming interface).
Le applicazioni point-to-point utilizzano un modello richiesta/replica o client/server o trasmettono un messaggio a molte applicazioni di destinazione utilizzando elenchi di distribuzione. Altre applicazioni inviano traffico ad una via di tipo send-and-forget o datagram. Esse scambiano informazioni con partner conosciuti. Ogni applicazione è a conoscenza dell'identità di una o più applicazioni con le quali sta comunicando. E' possibile creare e configurare i flussi di messaggi per elaborare sia i messaggi send-and-forget che richiesta/replica e distribuirli ai propri broker.
Il testo e i diagrammi seguenti illustrano i modelli send-and-forget e richiesta/replica. I diagrammi ipotizzano che le applicazioni stiano utilizzando il protocollo WebSphere MQ Enterprise Transport. Il modello è identico per gli altri protocolli, anche se la risorsa attraverso cui viene inviato o ricevuto il messaggio non sarà una coda WebSphere MQ.
Nel modello send-and-forget, un'applicazione invia un messaggio ma non si aspetta una risposta. Facoltativamente, un'altra applicazione potrebbe ricevere un messaggio come risultato del messaggio inviato dalla prima applicazione. E' possibile che non venga inviato alcun messaggio dal flusso di messaggi (ad esempio, se il messaggio di invio ha appena richiesto un aggiornamento del database). Nel diagramma, il mittente inserisce un messaggio nella coda di input di un flusso di messaggi sul broker (1). L'output dal flusso di messaggi è inserito nella coda del destinatario (2), da cui il destinatario può prelevarlo (3).
Con la messaggistica richiesta/replica, una volta che il destinatario riceve un messaggio di richiesta, esso invia una replica al mittente. Il messaggio di richiesta è gestito come descritto per i messaggi send-and-forget. Esistono due possibilità di replica:
Nel seguente diagramma, il mittente inserisce il messaggio nella coda di input di un flusso di messaggi nel broker (1). L'output dal flusso di messaggi è inserito nella coda del destinatario (2), da cui il destinatario lo preleva (3). Il destinatario invia la replica direttamente nel ReplyToQ del mittente (4), da cui il mittente può prelevarla (5).
L'output di questo flusso di messaggi di replica deve andare nella ReplyToQ del mittente. Se il nome è fisso, non c'è problema; se non lo è, è necessario trovare il modo di associare questa coda al messaggio di replica.
E' possibile eseguire questa operazione, ad esempio, includendo un nodo Database o DataInsert nel primo flusso di messaggi che memorizza le informazioni sulla destinazione della replica, che possono essere richiamate da un secondo flusso di messaggi.
In alternativa, è possibile copiare i dettagli importanti presenti nel descrittore messaggi in una cartella nell'intestazione MQRFH2 e trasportarli con il messaggio.
Nel seguente diagramma, il mittente inserisce un messaggio nella coda di input del primo flusso di messaggi nel broker (1). L'output dal flusso di messaggi è inserito nella coda del destinatario (2), da cui il destinatario lo preleva (3). Il destinatario invia la replica alla coda di input del secondo flusso di messaggi sul broker (4). Una volta elaborata la replica, il broker la invia alla ReplyToQ del destinatario (5), da cui il destinatario può prelevarla (6). (In questo caso, è necessario che il nodo di output del secondo flusso di messaggi conosca la ReplyToQ del mittente.)
Le applicazioni esistenti che sono state scritte utilizzando il modello point-to-point possono funzionare invariate in un ambiente WebSphere Message Broker se utilizzano uno dei protocolli supportati per comunicare con il broker.
La funzionalità dell'applicazione può essere migliorata ed estesa utilizzando le funzioni del broker per includere partner aggiuntivi. Ad esempio, un'applicazione che gestisce dati simili ma in un formato differente può partecipare perché il messaggio originale può essere trasformato da un flusso di messaggi nel broker nel formato previsto, senza che sia necessario modificare l'applicazione di invio o ricezione.
Se si identifica un messaggio che necessita di un'elaborazione dell'applicazione aggiuntiva, è possibile creare un'altra copia del messaggio nel flusso di messaggi e inviarla ad una nuova applicazione sviluppata per fornire tale elaborazione. Le applicazioni originali non sono a conoscenza della nuova azione sul messaggio e continuano ad operare invariate.
Il modello di comunicazione dell'applicazione di pubblicazione/sottoscrizione coinvolge le applicazioni note come autori (publisher) e le applicazioni note come sottoscrittori. Gli autori (publisher) rendono i messaggi disponibili pubblicandoli in argomenti specifici. I sottoscrittori ricevono i messaggi effettuando una sottoscrizione agli argomenti. Una singola applicazione può essere sia un autore (publisher) che un sottoscrittore.
I messaggi pubblicati da un qualsiasi autore (publisher) possono essere ricevuti da un numero qualsiasi di sottoscrittori. I sottoscrittori potrebbero anche ricevere i messaggi, in uno stesso argomento o in uno differente, da un numero qualsiasi di autori (publisher).
Nel diagramma di seguito, l'autore (publisher) invia i messaggi Pubblica o Cancella pubblicazione al broker. Il broker inoltra il messaggio Pubblica ai sottoscrittori che hanno una sottoscrizione corrispondente. Il sottoscrittore può inviare i messaggi Registra sottoscrittore, Annulla registrazione sottoscrittore o Richiedi aggiornamento al broker. I messaggi di risposta facoltativi dal broker sono inviati all'autore (publisher) e al sottoscrittore.
Se si dispone di applicazioni utente finale esistenti scritte sul modello pubblicazione/sottoscrizione, ad esempio utilizzando MQI o AMI, si possono probabilmente integrare queste applicazioni in un dominio broker WebSphere Message Broker senza modifica.
E' anche possibile modificare queste applicazioni o scriverne di nuove, per sfruttare la sofisticata elaborazione pubblicazione/sottoscrizione fornita, in modo particolare per i sottoscrittori.
Il modello di pubblicazione/sottoscrizione e l'elaborazione fornita da WebSphere Message Broker, è descritto in dettaglio in ulteriori argomenti disponibili nei link correlati elencati di seguito.