WebSphere Enterprise Service Bus, Versione 6.2.0 Sistemi operativi: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Proprietà delle transazioni e ripristino della soluzione

WebSphere ESB è basato su WebSphere Application Server e quindi supporta un modello transazionale per l'esecuzione delle transazioni di business.

WebSphere ESB è stato realizzato su questo modello transazionale e fornisce applicazioni SOA con legame debole e applicazioni BPM.

Tecnicamente, ciò significa due cose:

  1. WebSphere ESB si basa su database e sistemi di messaggistica per realizzare schemi esecutivi di applicazioni transazionali.
  2. Le transazioni nei sistemi di messaggistica e nei sistemi database sono obbligatori.

    Le transazioni sono compatibili con le proprietà ACID. Le transazioni devono essere compatibili con ACID quando includono atomicità, congruenza, isolamento e durevolezza.

    WebSphere ESB utilizza database e sistemi di messaggistica per realizzare schemi "con legame debole". WebSphere ESB aggiorna un database e invia un messaggio. Sia l'aggiornamento al database che il messaggio fanno parte della stessa transazione.

    Un'altra caratteristica di uno schema "con legame debole" è l'estrazione di un messaggio da un sistema di messaggistica e l'aggiornamento dei database. Se si verifica un errore durante questa elaborazione, l'evento torna nella coda messaggi come se non fosse stato letto. WebSphere ESB dispone di un meccanismo in base al quale dopo 5 tentativi l'evento torna al gestore eventi non riusciti. L'espressione "con legame debole" si riferisce al fatto che il lavoro non deve essere eseguito tutto in una grande transazione.

Evitare perdite di dati nei casi di malfunzionamento del sistema

Con un'ottimizzazione e una configurazione appropriate dei gestori risorse disponibili, i dati non andranno persi in caso di malfunzionamento di una parte specifica del sistema. L'integrità transazionale, inclusi i meccanismi di rollback e di ripristino, sono i componenti chiave di WebSphere che evitano la perdita di dati quando si verificano dei malfunzionamenti.

Perché i meccanismi di rollback e di ripristino di WebSphere funzionino, occorre impostare correttamente i gestori risorse (database e messaggistica). Ad esempio, i timeout di blocco nei database devono essere impostati correttamente, in modo che quando viene effettuato il ripristino di un server, questo può completare un commit o un rollback senza incontrare condizioni di blocco.

WebSphere ESB aggiunge delle ulteriori capacità che convertono quelle di WebSphere Application Server, per fornire una soluzione completa per il ripristino di dati da malfunzionamenti non previsti.

Descrizione di livello superiore dell'abilitazione delle funzioni di ripristino

Il modello di ripristino principale di WebSphere ESB si basa su unità di lavoro. Il sistema può gestire ed eseguire il ripristino da errori che si verificano durante le operazioni di sistema basate su una sola unità di lavoro da completare, fornendo un servizio ininterrotto. Questo tipo di ripristino si verifica mediante una serie di meccanismi di tentativi e code di errori. Parte della progettazione della propria applicazione deve includere la capability per la distinzione degli errori di sistema dagli errori dell'applicazione. Gli errori di sistema vengono reinviati all'infrastruttura che supporta il componente chiamante, dove è possibile provare ad eseguire un ripristino aggiuntivo del livello del sistema oppure si può verificare una conversione in un'eccezione di business più generica. È possibile configurare diversi meccanismi di tentativi perché vengano eseguiti automaticamente. Inoltre, WebSphere ESB fornisce una serie di console e interfacce di programmazione corrispondenti che consentono più interventi umani, quando necessario. Molte di queste capacità, e i malfunzionamenti che devono affrontare, possono essere utilizzati quando il server che contiene tale lavoro continua a elaborare nuove richieste.

Server non disponibile - Descrizione di livello superiore

Se un errore rende non disponibile uno o più server in un cluster di WebSphere ad elevata disponibilità, vengono richiamate delle capacità di ripristino aggiuntive all'interno del sistema nella seguente maniera:
  1. Il lavoro in entrata viene indirizzato via dal sistema malfunzionante

    Tale operazione viene eseguita utilizzando le funzioni di gestione del carico di lavoro fondamentali di WebSphere Application Server che possono variare in base al protocollo, alla topologia e alla configurazione.

  2. L'amministratore avvia le azioni

    Mentre il sistema nella sua interezza resta attivo e disponibile, l'amministratore può eseguire le operazioni di ripristino.

    Le azioni dell'amministratore hanno lo scopo di eseguire delle scelte di base, quindi di riavviare il server malfunzionante. Tale riavvio eseguirà nuovamente il log delle transazioni e dovrebbe eliminare la maggior parte delle situazioni di fermo del server.

    L'utilizzo dei meccanismi di gestione degli errori fornito da WebSphere ESB, è talvolta necessario per amministrare un ripristino completo.

Cluster non disponibile - Descrizione di livello superiore

Se l'intero cluster di server non è più disponibile o non risponde, sarà necessaria una serie di azioni di ripristino più complesse. Ad esempio, se una risorsa condivisa come un database non è più disponibile, tutti i server presenti in un cluster avranno le stesse difficoltà a completare il lavoro.

Le procedure che si occupano del ripristino delle risorse condivise dipendono dalla risorsa condivisa in cui si è verificato il malfunzionamento. È possibile applicare diverse tecniche di WebSphere per ridurre i tempi di disponibilità globala e riavviare il lavoro in stallo.

Malfunzionamento gravissimo - Descrizione di livello superiore

In situazioni gravissime, macchine intere potrebbero non essere più disponibili o determinati server vengono considerati non ripristinabili. In tali casi, è possibile fare affidamento sulle funzioni avanzate presenti in WebSphere per il ripristino dai malfunzionamenti di un server da eseguire su un altro server nello stesso cluster. Questo tipo di ripristino è possibile anche mediante l'utilizzo di questa funzione e il prerequisito di avere della memoria collegata mediante la rete o qualche altro meccanismo per condividere i log. Per ulteriori informazioni sul ripristino di un server in cui si è verificato un errore da un altro membro dello stesso cluster, consultare Ripristino peer.


concept Argomento Concetto

Termini di utilizzo | Feedback


Icona data/ora Ultimo aggiornamento: 02 Luglio 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/crec_trnsactional.html
Copyright IBM Corporation 2005, 2010. Tutti i diritti riservati.
Questo centro informazioni utilizza la tecnologia Eclipse. (http://www.eclipse.org).