Sistemi distribuiti: Tipologie di Architettura Client-Server

Che cos’è una architettura Client-Server?

La caratteristica di una architettura Client-Server è quella di avere appunto un Server che fornisce dei servizi e un insieme di Client che usufruirà di quei servizi.

Bisogna fare attenzione però alla differenza fra aspetto logico e fisico, perché quando si parla di Client-Server ci si può riferire sia alla macchina sia al processo, ossia programma in funzione su quella macchina. Dal nostro punto di vista ci si riferisce ai processi, quindi parleremo di Client-Server sotto l’aspetto logico.

La caratteristica dei Client è che non percepiscono l’esistenza di altri Client mentre conoscono il Server poiché con esso interagiscono. Diversi processi server possono essere eseguiti su uno stesso processore, infatti se più client si collegano e chiedono diversi funzionalità, di quel server vengono eseguiti processi diversi ma su una stessa macchina ed è qui che sta la difficoltà di gestione.

Livelli logici in un’architettura Client-Server

Sappiamo che una qualunque applicazione deve essere in qualche modo strutturata, bisogna dare un impostazione al codice in modo che sia leggibile. In generale un’applicazione è organizzata in tre livelli logici:

• Presentazione;
• Elaborazione;
• Parte dati (gestione dei dati).

Dati questi tre livelli vediamo come un’architettura Client-Server si presta bene a implementare questo tipo di strutture.

Se stiamo realizzando un sistema distribuito, ogni strato dell’applicazione deve avere una strutturazione in tre livelli dell’applicazione che andiamo a realizzare.

Inoltre, le architetture Client-server possono essere a vari livelli. Posso avere un solo livello Client e un livello server, o tre livelli: client, server e terzo livello, oppure livelli multipli: Il client ed N livelli con caratteristiche affini ai Server.

Architettura client-server a due livelli

Se si ha un’architettura a due livelli essa può essere di due tipi:

• Thin Client (A Client leggero)
• Fat Client (A Client Pesante)

Se si ha un’architettura a Client leggero, il server sarà ovviamente pesante poiché su di esso cadrà tutta l’elaborazione mentre il Client svolgerà solo l’azione di Interfaccia e di invio dei comandi. Lo svantaggio è ovviamente l’appesantimento del server e il forte utilizzo della rete che verrà richiamato ogni qual volta verrà fatta una richiesta dal Client ed inoltre la potenza del Client non verrà sfruttata al massimo.

Se invece ho un’architettura a Client pesante, l’elaborazione è svolta in parte dal Client oltre al lavoro di presentazione. Il server oltre al lavoro di elaborazione gestisce le transizioni sul DATABASE. Un esempio classico è proprio quello del Bancomat, per un motivo di sicurezza e perché c’è una continua interazione. Lo svantaggio ovviamente sta proprio nella complessità, infatti una modifica comporterà un notevole lavoro di adeguamento.

In generale un organizzazione a due livelli avrà svantaggi a livello di scalabilità, prestazioni, e complessità.

Architettura client-server a tre livelli

L’altro tipo di architettura client-server è quella a tre livelli che si mappa perfettamente sulla struttura logica dell’applicazione: la presentazione sarà su client, l’elaborazione sarà sul livello centrale e la gestione dei dati su un terzo strato. I processi possono essere eseguiti su macchine distinte, ed alcuni livelli possono essere sulla stessa macchina ma il fatto che si abbia una maggiore strutturazione fa sì che le prestazioni aumentino.

Ad esempio se ci si trova davanti a un sistema di internet banking, si avrà il database dei clienti e quindi un mainframe che si occuperà solo della gestione dei dati, poi si avrà un server web che fornisce i servizi applicative (login, transazioni, gestione conto ecc) e infine il client dell’utente finale che grazie al browser interagisce con il resto del sistema.

Vantaggi: Separando il database dal server si possono usare protocolli più veloci, si ha migliore gestione dei dati soprattutto dal punto di vista della sicurezza e della protezione dei dati perché il server in tal modo non ha accesso ai dati. Miglior bilanciamento del carico.

Architettura client-server a N livelli

Estendendo il modello a tre livelli posso ottenere un architettura a n livelli, quando ad esempio le applicazioni devono accedere a dati di database diversi o se si struttura il server in più livelli server. E’ necessario nel caso in cui si abbiano più database server, un server applicativo che lavori per l’integrazione dei dati, in modo da unirli in un solo formato da inviare al resto dell’applicazione.

Confrontiamo quindi ora le architetture a tre livelli con quelle a due, analizzando i vantaggi e gli svantaggi dell’una e dell’altra.

Abbiamo già notato come le architetture a tre livelli garantiscano una maggiore scalabilità rispetto a quelle a due, e un maggiore bilanciamento del carico. Si ha un minore traffico di rete, infatti quelle a due livelli intasano la rete perché c’è una continua richiesta al server, invece se il server è su più livelli il traffico è più distribuito.

Più la struttura è a livelli, migliore sarà la manutenibilità, la facilità di aggiornamento e la modificabilità.

La latenza è minore in una struttura a tre livelli, perché essendoci una divisione dei compiti la risposta arriva più rapidamente, a differenza di quella a due livelli in cui fa tutto il server.

Quando è preferibile usare l’architettura a due livelli a client leggero, a due livelli a client pesante, o l’architettura a tre livelli?

Per quanto riguarda le architetture a Client leggero, esse si usano preferibilmente in sistemi ereditati, di vecchio stampo, realizzati con linguaggi obsoleti. Non avendo strumenti per modificarli, si usa un interfaccia di connessione per renderli accessibili in rete, senza stravolgere tutto il funzionamento. Il server è quella che era prima l’applicazione e si pone solo un’ interfaccia di connessione. Oppure in applicazioni a calcolo intensivo, come i compilatori, in cui nel client ho solo l’interfaccia, e l’elaborazione, che essendo complessa è difficile da rendere distribuita, in unico server. Oppure ancora applicazioni in generale che hanno intensa elaborazione sui dati.

E’ preferibile il Client pesante in applicazioni di calcolo grafico, matematico o in ambienti in cui è necessario che l’utente abbia interazione maggiore con il sistema.

A tre livelli invece quando si hanno dati memorizzati in database o elaborazione intensiva di dati. Oppure quando bisogna integrare dati provenienti da fonti diversi.

Il modello Client-Server ha però dei suoi svantaggi. Infatti esso è scarsamente flessibile, e la scalabilità e il bilanciamento del carico non sono impliciti.

Per questo esistono altre architetture, sempre basate su componenti, in cui però il vincolo che ci sia un componente che fornisce servizi e un componente che richiede servizi, decade. Si avranno più componenti in grado sia di richiedere che fornire servizi agli altri componenti. Una struttura abbastanza complessa, con tecnologie di implementazione altrettanto complesse. La caratteristica è che anche qui è presente un middleware, più complesso di quello presente su un Client-Server, che in architetture di questo tipo viene chiamato ORB, Object Request Broker.

Si tratta di un’architettura aperta, molto scalabile, flessibile. Il sistema può essere riconfigurato dinamicamente. L’aspetto progettuale importante è il fatto che le decisioni su dove devono essere collocati i diversi servizi, non devono essere stabilite a priori come nel Client-Server. Si può in corso d’opera aggiungere o modificare le funzionalità.

Studiamo per esempio un’applicazione di vendita al dettaglio. Essa può essere strutturata in base a diversi approcci:

• Modello logico di un’architettura a oggetti distribuiti, in cui le funzionalità sono i servizi o la combinazione di servizi (controllo merci, ordinazione, ecc).
• Modello Client-Server, in cui tutto va sul server e il client si occupa solo dell’interfaccia nei singoli punti vendita.

Esempi in cui è preferibile usare architetture a oggetti distribuiti: catena di negozi o sistemi data mining, ossia sistemi in cui a partire da diversi insieme di dati si vogliono ricavare informazioni su particolari aspetti.

Vantaggi e svantaggi:

• Maggiore complessità rispetto al Client-Server.
• Più efficiente, prestazioni migliori in determinati applicativi.

Una caratteristica importante dal punto di vista implementativo è data dalle tecnologie che devono essere utilizzate. Nell’architettura a oggetti distribuiti possono essere integrate componenti con linguaggi diversi. Il compito del middleware o il broker ha il compito di integrare queste differenze ed è proprio un pattern architetturale. In generale il Middleware deve garantire la comunicazione a livello logico e a livello di componenti.