Strutturazione di transazioni distribuite

Come per molti problemi di progettazione, la progettazione di un'applicazione di DTP comporta la gestione di diversi obiettivi contrastanti che devono essere attentamente bilanciati tra loro. Tra questi, le prestazioni, la facilità di manutenzione, l'affidabilità, la sicurezza, la connettività con le funzioni esistenti e il ripristino.

Evitare problemi di prestazioni

Se le prestazioni sono la priorità assoluta, è necessario progettare l'applicazione in modo che i dati vengano elaborati il più vicino possibile alla loro origine. In questo modo si evita la trasmissione inutile di dati attraverso la rete. In alternativa, se l'elaborazione può essere posticipata, si potrebbe prendere in considerazione il batching dei dati a livello locale prima della trasmissione.

Per mantenere le prestazioni della connessione intersistema, la conversazione deve essere liberata il prima possibile, in modo che la sessione possa essere utilizzata da altre transazioni. In particolare, evitate di conversare durante l'attesa di un terminale.

Nelle transazioni terminal-attached, la progettazione pseudo-conversazionale migliora le prestazioni riducendo il tempo in cui una transazione trattiene le risorse CICS®. L'utente di un terminale può impiegare secondi o addirittura minuti per rispondere a qualsiasi richiesta di input da tastiera. Al contrario, il ritardo di comunicazione associato a una conversazione tra transazioni partner è probabilmente di pochi millisecondi. Non è quindi necessario terminare una transazione front-end in attesa di una risposta da una transazione back-end.

Tuttavia, una transazione front-end può essere avviata dal terminale, nel qual caso potrebbe essere appropriato un design pseudo-conversazionale. Quando è richiesto l'input dell'utente del terminale, termina la transazione front-end e le sue conversazioni. Dopo la risposta dell'utente del terminale, la transazione front-end successiva può avviare una transazione back-end successiva. Se la prima transazione back-end deve passare informazioni al suo successore, le informazioni devono essere passate alla transazione front-end o memorizzate localmente (ad esempio, in una memoria temporanea).

Le informazioni memorizzate devono essere recuperabili tramite identificatori non associati alla particolare sessione utilizzata dalla conversazione. La transazione back-end non può utilizzare una COMMAREA, un RETURN TRANSID o un TCTUA per questo scopo. Invece, può costruire l'identificatore di una coda di archiviazione temporanea utilizzando le informazioni ottenute dalla transazione front-end. È possibile utilizzare il sysid della struttura principale e l'identificativo del terminale a cui è collegata la transazione front-end.

Facilitare la manutenzione

Per correggere gli errori o per adattarsi alle esigenze in evoluzione di un'organizzazione, i processi distribuiti devono inevitabilmente essere modificati. Sia che le modifiche vengano apportate dagli sviluppatori originali o da altri, questo compito sarà probabilmente più facile se i processi distribuiti sono relativamente semplici. Per questo motivo, è necessario ridurre al minimo il numero di transazioni coinvolte in un processo distribuito.

Puntare sull'affidabilità

Se siete particolarmente interessati all'affidabilità, considerate la possibilità di ridurre al minimo il numero di transazioni nel processo distribuito.

Protezione dei dati sensibili

Se il processo distribuito deve gestire dati sensibili alla sicurezza, è possibile collocare questi dati su un unico sistema. L'utilizzo di un unico sistema significa che solo una delle transazioni deve essere a conoscenza di come o dove sono archiviati i dati sensibili.

Mantenimento della connettività

Se si richiede la connettività alle transazioni in esecuzione in un sistema CICS di livello posteriore, verificare che le funzioni richieste siano compatibili in entrambi i sistemi.

I seguenti aspetti della progettazione di processi distribuiti differiscono dalle considerazioni relative a un singolo sistema:

conversione dati: Per le unità logiche APPC non-EBCDIC, potrebbe essere necessaria una conversione dei dati sia in ricezione che in invio.
Utilizzo di conversazioni multiple: Quando si utilizzano conversazioni multiple e seriali, CICS potrebbe fornire diversi identificatori di conversazione alla transazione. Non è quindi consigliabile utilizzare l'identificatore di conversazione per denominare le risorse, ad esempio le code di memoria temporanea.

Salvaguardia dell'integrità dei dati

Se per voi è importante poter recuperare i dati quando le cose vanno male, progettate le conversazioni per il livello di sincronizzazione 2 e mantenete le unità di lavoro il più piccole possibile. Tuttavia, questo non è sempre possibile, perché la dimensione di una UOW è determinata in gran parte dalla funzione che viene eseguita. Ricordate che l'elaborazione di CICS syncpoint non ha informazioni sulla struttura e sullo scopo dell'applicazione. In qualità di progettisti di applicazioni, dovete assicurarvi che i punti di sincronizzazione siano presi al momento e nel luogo giusti e per un buon scopo. In questo caso, è improbabile che le condizioni di errore portino a incongruenze nelle risorse di dati recuperabili.

Ecco un esempio di applicazione distribuita che trasferisce il contenuto di una coda di memoria temporanea dal sistema A al sistema B, utilizzando una coppia di transazioni (TRAA nel sistema A e TRBB nel sistema B) e una conversazione a livello di sincronismo 2:

La transazione TRAA nel sistema A legge un record dalla coda di memoria temporanea.
La transazione TRAA invia il record al sistema B e attende la risposta.
La transazione TRBB nel sistema B riceve il record dal sistema A.
La transazione TRBB elabora il record e invia una risposta al sistema A.
La transazione TRAA riceve la risposta e cancella il record dalla coda di memorizzazione temporanea.

Questi passaggi vengono ripetuti finché ci sono record nella coda. Quando la coda è vuota:

La transazione TRAA invia al sistema B un indicatore di "ultimo record".
La transazione TRBB invia una risposta al sistema A.

Ci sono diversi punti in cui si può considerare di prendere un punto di sincronizzazione. Ecco i vantaggi relativi dell'adozione di un punto di sincronizzazione in ciascuno di questi punti:

All'inizio dell'elaborazione: Poiché un UOW inizia a questo punto, un punto di sincronizzazione non ha alcun effetto. Infatti, se TRBB tenta di prendere un punto di sincronizzazione senza aver prima emesso un comando di ricezione dei dati, viene interrotto.
Dopo la transazione il TRAA riceve una risposta: Un syncpoint a questo punto fa sì che CICS esegua il commit di un record nel sistema B prima che sia stato cancellato dal sistema A. Se uno dei due sistemi (o la connessione tra di essi) si guasta prima che il processo distribuito sia completato, i dati potrebbero essere duplicati.
Immediatamente dopo l'eliminazione del record dalla coda di memorizzazione temporanea: Poiché è necessaria un'elaborazione minima prima che le risorse vengano impegnate, questo può essere un posto sicuro per prendere un syncpoint se la coda è lunga o i record sono grandi. Tuttavia, le prestazioni possono essere scarse perché viene preso un punto di sincronizzazione per ogni record trasmesso.
Dopo che la transazione TRAA ha ricevuto la risposta all'indicatore dell'ultimo record: Se si prende un syncpoint solo quando tutti i record sono stati trasmessi, un guasto precedente comporterà la necessità di ritrasmettere tutti i dati. Un processo distribuito che si sincronizza solo in questa fase si completerà più rapidamente di uno che si sincronizza dopo l'elaborazione di ogni record, a condizione che non si verifichino errori. Tuttavia, ci vorrà più tempo per recuperare. Se nel processo sono coinvolti più di due sistemi, il problema si aggrava.

Ricordate che un numero eccessivo di conversazioni all'interno di una transazione distribuita complica il recupero degli errori. Una struttura complessa può talvolta essere inevitabile, ma di solito significa che il progetto potrebbe essere migliorato se si pensasse a semplificare la struttura della transazione distribuita.

Un UOW deve essere recuperabile per l'intero processo di cui fa parte. Tutte le modifiche apportate da entrambi i partner in ogni conversazione devono essere annullate se l'UOW non si conclude con successo. I punti di sincronizzazione non sono divisioni arbitrarie, ma devono riflettere le funzioni dell'applicazione. Le unità di lavoro devono essere progettate per preservare risorse coerenti, in modo che quando una transazione fallisce, tutte le risorse vengano ripristinate al loro stato corretto.

Prima di terminare una conversazione di sincronizzazione level-2, assicurarsi che la transazione del partner sia in grado di comunicare eventuali errori riscontrati. In caso contrario, l'integrità dei dati potrebbe essere compromessa.