Progettazione e realizzazione di sistemi a oggetti distribuiti

Le metodologie adottate per la progettazione e realizzazione di sistemi a oggetti distribuiti derivano dall’evoluzione delle metodologie classiche di progettazione di sistemi informativi con i contributi derivanti dalle problematiche proprie dei sistemi distribuiti e dei sistemi orientati agli oggetti. La Figura qui di seguito mostra, su un impianto metodologico classico a cascata, le fasi principali che si innestano per trattare le tematiche della distribuzione di un sistema basato sugli oggetti.

In particolare, nella figura si evince che:

• a valle della produzione di una rappresentazione concettuale del sistema, ottenuta con tecniche tradizionali o object oriented, si produce lo schema basato su oggetti del sistema; questo processo è supportato dall’uso di euristiche di trasformazione per il passaggio dalla rappresentazione concettuale iniziale a quella basata su oggetti;
• lo schema ad oggetti così ottenuto è la base del progetto della distribuzione del sistema sulla rete di calcolatori disponibili; si individuano i nodi chiamati ad ospitare ogni oggetto del sistema e si risolvono le problematiche di frammentazione, replicazione, parallelismo ed allocazione che conducono alla configurazione ottimale del sistema sulla rete;
• ogni oggetto componente lo schema ad oggetti risultante è realizzato autonomamente, usando le metodologie e gli ambienti di sviluppo che meglio si adattano al compito da svolgere, all’ambiente elaborativo ospitante ed alla cultura del gruppo di sviluppo;
• i diversi oggetti realizzati sono integrati in modo da comporre il sistema complessivo, verificando il corretto funzionamento delle mutue connessioni e delle modalità di esecuzione dei servizi offerti dalle interfacce.

Nei prossimi paragrafi e articoli presenti in questo sito web vedremo dunque tutte le fasi necessarie per la progettazione e realizzazione di sistemi a oggetti distribuiti:

1. Progettazione dello schema a oggetti
2. Progettazione della distribuzione
3. Architetture layer e tier (architecture layer and tier)
4. La gestione di transazioni in ambiente distribuito

Ed infine descriveremo anche la progettazione di sistemi ad oggetti distribuiti basata su componenti e riuso degli stessi.

Progettazione dello schema a oggetti

In questa fase il prodotto del progetto concettuale del sistema complessivo effettuato durante la fase precedente (in generale costituito da schemi concettuali dei dati e delle funzioni, seguendo approcci tradizionali, o da schemi orientati agli oggetti, seguendo un approccio object-oriented) deve essere trasformato in uno schema basato su oggetti del sistema complessivo. Tenendo presente la definizione di oggetto, i criteri che si seguono nell’individuazione degli oggetti dello schema sono quelli della massima coesione interna fra dati e funzioni formanti i singoli oggetti e del minimo accoppiamento fra oggetti diversi. In tale modo, infatti, si minimizzano le necessità di comunicazione fra oggetti diversi in esercizio, allocabili su nodi elaborativi diversi e quelle di accordo fra gruppi di lavoro diversi che realizzino oggetti diversi.

Progettazione della distribuzione

In questa fase lo schema a  oggetti deve  essere distribuito  in  modo ottimale sulla rete di elaboratori.

Passo 1 – Identificazione delle alternative di configurazione della rete

In base alla realtà esistente e ai requisiti del nuovo sistema, si individuano le topologie di rete possibili e le caratteristiche dei nodi elaborativi. In questa fase è particolarmente importante individuare eventuali applicazioni legacy con cui interfacciarsi, che possono vincolare in modo significativo le scelte di allocazione.

Passo 2 – Progetto della frammentazione e della replicazione

In questo passo, ogni oggetto dello schema a oggetti originario può essere:

• frammentato, ovvero suddiviso in un insieme di oggetti cooperanti; la frammentazione è effettuata quando si desideri aumentare la “località” con la quale i servizi forniti da serventi sono erogati ai clienti; si pensi, a tale proposito, ai meccanismi dei proxy client e dei proxy server, che permettono di aumentare l’efficienza e la continuità di servizio diminuendo le comunicazioni in rete;
• replicato, ai fini di una maggiore continuità di servizio, di una maggiore tolleranza ai guasti e di maggiori livelli prestazionali; la replicazione è uno strumento ottimale qualora le repliche non condividano uno stato interno modificabile nel tempo e non abbiano quindi necessità di frequente sincronizzazione reciproca.

Quando si frammenta un oggetto, i sottocomponenti possono avere un grado di mutua coesione nullo (nessuna necessità di cooperazione) o non nullo. In questo ultimo caso la frammentazione avviene:

• senza replicazione: si osserva in tal caso comunicazione fra i componenti;
• con replicazione: ottimale quando le diverse repliche non abbiano uno stato interno da condividere.

Durante questo passo, inoltre, si identifica per ogni oggetto la necessità di essere:

• mono-processo: in questo caso l’oggetto è chiamato a risolvere le richieste di un solo cliente; oggetti di questa natura sono tipicamente gli oggetti di interfaccia utente;
• multi-processo: in questo caso l’oggetto è chiamato a risolvere richieste provenienti in parallelo da più clienti; oggetti di questa natura sono quelli che incapsulano risorse condivise e che richiedono, in sede di realizzazione, la risoluzione di problematiche di gestione della concorrenza.

Passo 3 – Allocazione degli oggetti sui nodi della rete

Durante questo terzo passo i diversi oggetti costituenti lo schema, eventualmente frammentati  e replicati, debbono essere allocati sui diversi nodi fisici della rete di calcolatori disponibili.

Il passo di allocazione tiene conto dei seguenti fattori:

• località degli oggetti rispetto a utilizzatori e risorse: gli oggetti usati direttamente dagli utenti (interfaccia utente) saranno allocati sulle macchine usate dagli utenti stessi; gli oggetti che gestiscono risorse legacy (basi di dati, transazioni) saranno collocati possibilmente sui sistemi legacy stessi;
• disponibilità sul nodo delle funzionalità necessarie per il funzionamento dell’oggetto: ogni oggetto, per funzionare, richiede risorse elaborative e di memorizzazione specifiche che debbono essere presenti sul nodo elaborativo che lo ospita, o comunque convenientemente raggiungibili da questo; per esempio, un oggetto che debba funzionare in modalità multi-processo deve essere allocato su un nodo dotato di un sistema operativo che permetta la presenza contemporanea di più processi in esecuzione; un oggetto che debba eseguire operazioni matematiche complesse si avvantaggerà della presenza di coprocessori matematici sulla macchina che lo ospita; un oggetto che debba gestire dati multimediali richiede un nodo elaborativo dotato di capacità e periferiche specifiche;
• ottimalità della collocazione di ogni oggetto in rapporto alle capacità elaborative e di memorizzazione dei singoli nodi e alle capacità di trasmissione dei canali di comunicazione fra nodi; uno schema di allocazione di oggetti su una rete di calcolatori è ritenuto accettabile se la potenza elaborativa richiesta a ogni nodo è inferiore di quella disponibile e se il traffico di dati su ogni tratta è inferiore alla sua capacità.

La verifica del progetto di allocazione si effettua conoscendo il grado di replicazione degli oggetti, la frequenza di invocazione dei diversi servizi offerti dagli oggetti serventi, il carico elaborativo richiesto nell’esecuzione dei singoli servizi, e confrontando il carico complessivo sugli elaboratori e sui canali trasmissivi con la capacità elaborativa, di memorizzazione e di trasmissione degli stessi.

Il progetto della distribuzione è un processo iterativo, in quanto non è detto che un primo schema a oggetti sia allocabile sulla rete di calcolatori data in modo da soddisfare tutti i requisiti e i vincoli che si evidenziano durante il passo di allocazione. Le indicazioni che emergono durante questo passo portano il progettista a rivedere lo schema a oggetti, usando in particolare gli strumenti della frammentazione e della replicazione spingendolo, in casi estremi, a proporre variazioni sulle dotazioni hardware e software della rete di calcolatori da adottare.

Architetture layer e tier (architecture layer and tier)

La progettazione della distribuzione nel caso più generale si presenta come un problema molto complesso. Nella maggior parte dei casi il problema generale viene perciò semplificato suddividendo il sistema da realizzare in tre livelli logici che trovano corrispondenza in altrettanti strati software nei quali vengono partizionate le applicazioni, in letteratura spesso indicati come application layer:

1. il layer che si occupa della logica di I/O da/verso l’utente (logica di presentazione);
2. il layer che si occupa delle regole di business (logica di business o logica applicativa);
3. il layer che si occupa dei dati (logica d’accesso ai dati).

Nei sistemi distribuiti questi layer sono installati su un numero, anche differente,  di livelli hardware (detti tier), dove un livello rappresenta in generale una macchina di differente potenza elaborativa. Da questo secondo punto di vista, un’applicazione può essere configurata come:

• Single Tiered (un livello di distribuzione): tutti e tre i livelli applicativi vengono assegnati ad un’unica macchina; questa configurazione è quella classica terminale- host;
• Two Tiered (due livelli di distribuzione): i livelli applicativi sono divisi tra una macchina di front-end (tipicamente un PC) ed una di back-end (mainframe o server mid-range); sul front-end è realizzata la logica di presentazione e sul back-end quella d’accesso ai dati; differenti scelte sono possibili sull’allocazione della logica di business;
• Three Tiered (tre livelli di distribuzione): i tre livelli applicativi vengono suddivisi tra altrettante macchine: una di front-end (un PC), una di mid-range (un minicomputer od un server Unix/WindowsNT) ed una di back-end (un mainframe).

La prima configurazione, pur rappresentando il vecchio modello centralizzato, mantiene ancora una sua validità. Infatti i sistemi mainframe, Single Tiered per eccellenza, hanno tutt’oggi un livello di prestazioni, affidabilità e sicurezza che le moderne soluzioni distribuite non hanno ancora pienamente eguagliato.

Relativamente alla seconda configurazione, in base a come vengono allocati i tre livelli applicativi, sono possibili cinque differenti architetture, come viene mostrato nella figura precedente, con differenti caratteristiche di traffico di rete, prestazioni con alti carichi transazionali, funzionalità del client (fat client ovvero thin client) e quindi flessibilità e facilità di modifica. Tra queste quella attualmente più comune (perchè è quella tipicamente indotta dai più diffusi ambienti di sviluppo RAD e dai 4GL tipici di molti produttori di DBMS) è quella della Gestione Dati Remota, che può avere impredicibili effetti sul traffico di rete e porta allo sviluppo di client ricchi di funzionalità (fat client) e quindi difficili da manutenere.

E’ infine da notare come la suddivisione in livelli hardware è ortogonale a  quella  in livelli software: tali suddivisioni sono del tutto indipendenti. Spesso infatti può capitare che applicazioni distribuite (e quindi in presenza di più livelli hardware) non presentino una chiara stratificazione in livelli software. Tale caratteristica si rivela spesso molto problematica nel momento in cui si debba modificare il sistema. Si può quindi affermare che la stratificazione di tipo “software” è concettualmente più importante di quella hardware, anche perché senza la prima risulta assai difficile riuscire a pervenire alla seconda.

La gestione di transazioni in ambiente distribuito

Una transazione è l’esecuzione di un insieme di operazioni su un sistema tali da far evolvere il sistema da uno stato valido verso un altro stato valido. In termini tecnici, una transazione di un sistema informatico è una unità indivisibile di lavoro che soddisfa le proprietà ACID (Atomicity, Consistency, Isolation, Durability), portando il sistema da uno stato consistente ad un altro stato consistente. Per la gestione di transazioni in ambiente distribuito è necessario che tutti i nodi elaborativi partecipanti giungano alla stessa decisione finale, per una descrizione più dettagliata si veda l’articolo: La gestione delle transazioni in ambiente distribuito.