Come assicurare che i messaggi non vadano perduti

E' importante salvaguardare i messaggi che passano attraverso il dominio broker. Questo è vero sia per i messaggi generati dalle applicazioni sia per quelli utilizzati internamente per la comunicazione tra i componenti. I messaggi utilizzati internamente tra i componenti utilizzano sempre il protocollo WebSphere MQ. I messaggi dell'applicazione utilizzano tutti i protocolli di trasporto supportati.

Per quanto riguarda i messaggi dell'applicazione e quelli interni che viaggiano su WebSphere MQ, due tecniche proteggono dalla eventuale perdita:

Per ulteriori informazioni su come utilizzare queste opzioni, fare riferimento al manuale WebSphere MQ System Administration Guide.

Messaggi interni

I componenti di WebSphere Message Broker utilizzano i messaggi WebSphere MQ per comunicare eventi e dati tra i sistemi secondari e le elaborazioni del broker da una parte e Gestione configurazione e il Server nomi utente dall'altra. I componenti assicurano che le funzioni di WebSphere MQ vengano sfruttate come protezione dalla perdita dei messaggi. Non è necessario eseguire alcuna ulteriore operazione per configurare WebSphere MQ o WebSphere Message Broker per la protezione dalla perdita di messaggi interni.

Messaggi dell'applicazione

Se la consegna dei messaggi dell'applicazione è di fondamentale importanza, è necessario progettare programmi applicativi e i flussi di messaggi che essi utilizzano per assicurare che i messaggi non vadano perduti. Le tecniche utilizzate dipendono dal protocollo utilizzato dalle applicazioni.

WebSphere MQ Enterprise Transport e WebSphere MQ Mobile Transport
Se si stanno utilizzando nodi di input integrati che accettano messaggi attraverso i protocolli WebSphere MQ o WebSphere MQ Everyplace, è possibile utilizzare i seguenti suggerimenti e linee guida:
  • Utilizzo dei messaggi permanenti

    I prodotti di messaggistica WebSphere MQ forniscono la permanenza del messaggio, che definisce la longevità del messaggio nel sistema e garantisce l'integrità del messaggio. I messaggi non permanenti vanno perduti nel caso si verifichi un errore del sistema o del gestore code. I messaggi permanenti sono sempre ripristinati in caso di errore.

    E' possibile controllare la permanenza del messaggio nei seguenti modi:
    • Programmare le applicazioni che inseriscono i messaggi nella coda utilizzando MQI o AMI per indicare che i messaggi sono permanenti.
    • Definire la coda di input con la permanenza del messaggio come impostazione predefinita.
    • Configurare il nodo di output per gestire i messaggi permanenti.
    • Programmare le applicazioni sottoscrittore per richiedere la permanenza del messaggio.

    Quando un nodo di input legge un messaggio dalla coda di input, l'azione predefinita è quella di utilizzare la permanenza definita in MQMD (intestazione dei messaggi WebSphere MQ), impostata dall'applicazione che crea il messaggio o dalla permanenza predefinita della coda di input. Il messaggio conserva questa permanenza per tutto il flusso di messaggi, a meno che non venga modificato in un nodo di elaborazione del messaggio successivo.

    E' possibile sovrascrivere il valore di permanenza di ogni messaggio quando il flusso di messaggi termina in un nodo di output. Questo nodo ha una proprietà che consente di specificare la permanenza del messaggio di ogni messaggio quando questo viene inserito nella coda di output, come valore richiesto o come valore predefinito. Se si specifica il valore predefinito, il messaggio assume il valore di permanenza definito per le code in cui sono scritti i messaggi.

    Se il messaggio passa attraverso un nodo Publication, la permanenza dei messaggi inviati ai sottoscrittori viene stabilita dalle opzioni di registrazione dei sottoscrittori. Se un sottoscrittore ha richiesto la consegna di messaggi permanenti ed è autorizzato a farlo da un ACL esplicito o implicito (ereditato), il messaggio viene consegnato in modo permanente indipendentemente dalla relativa proprietà di permanenza esistente. Inoltre, se l'utente ha richiesto la consegna di messaggi non permanenti, il messaggio viene consegnato come non permanente indipendentemente dalla relativa proprietà di permanenza esistente.

    Se un flusso di messaggi crea un nuovo messaggio (ad esempio, in un nodo Compute), la permanenza nell'MQMD del nuovo messaggio è copiata dalla permanenza nell'MQMD del messaggio in entrata.

  • Elaborazione dei messaggi sotto il controllo punto di sincronizzazione

    L'azione predefinita di un flusso di messaggi è quella di elaborare i messaggi in entrata sotto il controllo punto di sincronizzazione in una transazione controllata dal broker. Questo significa che un messaggio che per qualche motivo non riesce ad essere elaborato, viene ripristinato allo stato precedente dal broker. Poiché il messaggio è stato ricevuto sotto il controllo punto di sincronizzazione, il messaggio che ha dato esito negativo viene reinserito nella coda di input ed è possibile elaborarlo di nuovo. Se l'elaborazione ha esito negativo, vengono eseguite le procedure di gestione degli errori per questo flusso di messaggi (definite in base alla modalità di configurazione del flusso di messaggi o dal broker).

    Per tutti i dettagli sull'elaborazione del nodo di input, consultare Gestione degli errori nel nodo di input.

WebSphere MQ Telemetry Transport
Se si sta utilizzando il nodo di input integrato SCADAInput che accetta i messaggi dai dispositivi di telemetria attraverso il protocollo MQIsdp, questo protocollo non riconosce il concetto di code. I client si connettono al nodo SCADAInput specificando il numero di porta sul quale il nodo è in ascolto. I messaggi vengono inviati ai client utilizzando un clientId. Tuttavia, è possibile specificare un valore massimo di QoS (Quality of Service) all'interno di un messaggio di sottoscrizione SCADA, che è simile alla permanenza:
  • QoS0 Non permanente.
  • QoS1 Permanente, ma potrebbe essere consegnato più di una volta
  • QoS2 Unica consegna

Se un messaggio permanente SCADA viene pubblicato, potrebbe essere declassato al livello più alto che il client può accettare. In alcune circostanze questo potrebbe significare che il messaggio diviene non permanente.

WebSphere MQ Real-time Transport, WebSphere MQ Multicast Transport e WebSphere MQ Web Services Transport
Se si stanno utilizzando nodi di input integrati Real-timeInput e Real-timeOptimizedFlow che accettano messaggi da applicazioni multicast e JMS o i nodi HTTP Input e HTTPRequest che accettano i messaggi dalle applicazioni dei servizi Web, non vi sono funzioni disponibili per la protezione dalla perdita di messaggi. Tuttavia, è possibile fornire procedure di ripristino configurando il flusso di messaggi per la gestione dei propri errori.
Altri trasporti e protocolli
Se sono stati creati dei nodi input definiti dall'utente che ricevono messaggi da un altro protocollo di trasporto, è necessario basarsi sul supporto fornito da quel protocollo di trasporto o fornire le proprie procedure di ripristino.
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac00420_