L'aggregazione è la creazione ed il fan-out delle richieste correlate derivate da un singolo messaggio di input e il fan-in delle repliche corrispondenti per produrre un singolo messaggio di replica aggregato.
La richiesta iniziale ricevuta dal flusso di messaggi, che rappresenta una raccolta di voci di richieste correlate, è divisa nel numero di singole richieste appropriato per eseguire le attività secondarie della richiesta iniziale. Questo processo è noto come fan-out ed è fornito dal flusso di messaggi che include i nodi di aggregazione.
Le repliche provenienti dalle attività secondarie sono combinate e integrate in un'unica replica che viene restituita al richiedente originale (o ad un'altra applicazione di destinazione) per indicare il completamento dell'elaborazione. Questo processo è noto come fan-in ed è anche fornito dal flusso di messaggi che include i nodi di aggregazione.
E' possibile iniziare l'aggregazione inviando un messaggio ad un flusso di messaggi da un'applicazione client connessa al broker attraverso qualunque protocollo supportato; la risposta aggregata può anche essere inviata ad un'applicazione client attraverso tutti questi protocolli. Il messaggio emesso dal flusso di messaggi di fan-out e le risposte ricevute dal flusso di messaggi di fan-in, devono essere messaggi di richiesta/replica. Ci si deve quindi limitare alle applicazioni client che si connettono utilizzando WebSphere MQ Enterprise Transport (inviando e ricevendo messaggi da e verso i nodi MQInput e MQOutput) o ai client che utilizzano un altro protocollo supportato da nodi di input e di output definiti dall'utente che sono conformi al modello di comunicazione richiesta/replica.
WebSphere Message Broker fornisce tre nodi del flusso di messaggi che supportano l'aggregazione:
Quando si includono questi nodi nei flussi di messaggi, più richieste di fan-out vengono emesse in parallelo dal flusso di messaggi. Questo è in contrasto con l'operatività standard del flusso di messaggi in cui ogni nodo esegue la propria elaborazione in sequenza.
E' possibile utilizzare questi nodi anche per inoltrare richieste ad applicazioni esterne all'ambiente del broker; i messaggi possono essere inviati in modo asincrono ad applicazioni o servizi esterni, le risposte possono essere richiamate da quelle applicazioni e possono venire associate per fornire un'unica risposta al messaggio di richiesta originale.
Questi nodi forniscono inoltre un'opportunità di migliorare i tempi di risposta, perché le richieste lente possono essere eseguite in parallelo e non devono succedersi in sequenza. Se le attività secondarie possono essere elaborate indipendentemente e non è necessario gestirle come parte di una singola unità di lavoro, esse possono essere elaborate da flussi di messaggi separati.
E' possibile progettare e configurare un flusso di messaggi che fornisce una funzione simile senza utilizzare i nodi di aggregazione, inoltrando le richieste di attività secondarie ad un'altra applicazione (ad esempio, utilizzando il nodo HTTPRequest) e registrando i risultati di ciascuna di esse in LocalEnvironment. Una volta completata ciascuna attività secondaria, è possibile integrare i risultati da LocalEnvironment in un nodo Compute e creare un messaggio di risposta combinato per la trasmissione all'applicazione di destinazione. Così facendo, tutte le attività secondarie sono svolte in sequenza e non forniscono i vantaggi per le prestazioni dell'operazione parallela che si possono ottenere utilizzando i nodi di aggregazione.
Esempi di flussi di aggregazione che utilizzano i nodi di aggregazione sono forniti nell'Esempio Aggregazione e nell'Esempio Prenotazioni per compagnie aeree. L'esempio relativo all'aggregazione dimostra una semplice aggregazione a quattro vie e l'esempio di prenotazione per compagnie aeree simula le richieste relative ad un servizio di prenotazione di compagnie aeree e illustra le tecniche associate ai flussi di aggregazione.
Nel precedente rilascio di WebSphere Message Broker, l'aggregazione usava una tabella nel database del broker per rendere permanenti le richieste di aggregazione. Da WebSphere
Business Integration Message Broker Versione 5.0 in poi, è possibile utilizzare WebSphere MQ. Il funzionamento esterno dei nodi di aggregazione non è cambiato, ma è possibile configurare un gruppo di esecuzione per utilizzare le code WebSphere MQ per la memorizzazione delle aggregazioni, invece di una tabella di database. Utilizzando WebSphere MQ in questo modo le prestazioni migliorano e l'aggregazione può essere fatta eseguire in modalità non persistente quando la persistenza delle richieste di aggregazione non è richiesta. Per ulteriori dettagli sulle modalità di migrazione e configurazione di un gruppo di esecuzione per l'utilizzo di WebSphere MQ, consultare Utilizzo di WebSphere MQ per la conservazione dello stato in nodi aggregati.
Nel passaggio da un tabella di database a WebSphere MQ per mantenere lo stato di aggregazione non si verifica nessuna migrazione di aggregazioni esistenti, dunque è importante assicurarsi che non siano presenti aggregazioni in uscita, perché queste non rientrerebbero nel processo di migrazione.
I nuovi nodi di aggregazioni utilizzano la scadenza del messaggio di WebSphere MQ per la gestione dei time out dei messaggi. Per consentire il funzionamento della scadenza del messaggio, le code del messaggio devono essere esaminate. I nodi di aggregazione esaminano le code automaticamente per assicurare che i messaggi scaduti vengano elaborati. Su z/OS, è possibile configurare WebSphere MQ per lanciare una elaborazione scavenger che esegue questo processo di analisi al posto dei nodi di aggregazione. Per abilitare il programma di scavenger, impostare la proprietà EXPRYINT del gestore code del broker su 5 secondi.
Se EXPRYINT non è impostato o è impostato su un valore maggiore di 10 secondi, le aggregazioni tornano al processo di analisi delle code di aggregazione automaticamente.