Architettura client-server e modelli applicativi

📋 Obiettivi di apprendimento
Descrivere il modello client-server distinguendo i ruoli di client e server come processi, non come macchine fisiche
Illustrare l’evoluzione da architetture single-tier a multi-tier, spiegando i vantaggi della separazione dei livelli
Spiegare cosa sono i microservizi e come comunicano tramite API REST
Confrontare architettura monolitica e a microservizi, identificando vantaggi e limiti di ciascuna
📄
Slides
slide complete con diagrammi

Il modello client-server

Il modello client-server è il paradigma fondamentale delle applicazioni di rete. In questo schema un processo — il client — invia richieste, mentre un altro processo — il server — resta in ascolto e risponde fornendo servizi o risorse.

⚠️ Attenzione al malinteso comune

Client e server non sono macchine fisiche, ma processi in esecuzione. Lo stesso computer può eseguire contemporaneamente un browser (client) e un server web locale. La distinzione è logica, non hardware.

Ruolo del client

È un processo attivo — prende l’iniziativa della comunicazione
Usa un URL (Uniform Resource Locator) per identificare la risorsa richiesta
Specifica un indirizzo IP e un numero di porta del servizio desiderato
Invia la richiesta e attende la risposta dal server

Ruolo del server

È un processo passivo — rimane in ascolto finché non riceve una richiesta
È in ascolto su una specifica porta TCP (es. porta 80 per HTTP, 443 per HTTPS)
Elabora la richiesta e restituisce una risposta (risorsa o codice di errore, es. 404 Not Found)
Può servire più client contemporaneamente grazie al multithreading o multiprocessing
📌 Esempio pratico

Un server HTTP resta in ascolto sulla porta 80 (o 443 per HTTPS). Quando digiti un URL nel browser, il browser (client) apre una connessione TCP verso quell’indirizzo e porta, invia una richiesta HTTP e attende la risposta con il contenuto della pagina.

Evoluzione delle architetture applicative

Le architetture software si sono evolute nel tempo per rispondere a esigenze crescenti di scalabilità, manutenibilità e sicurezza.

SINGLE-TIER
🖥️

Tutto — interfaccia, logica e dati — risiede sullo stesso sistema. Semplice ma poco scalabile. Oggi poco diffusa.

TWO-TIER
🖥️ ↔ 🗄️

Client e server distinti. Il client gestisce presentazione e logica, il server i dati. Tipica dei primi sistemi di rete.

MULTI-TIER
🖥️ ↔ ⚙️ ↔ 🗄️

Separazione in livelli: presentazione, logica applicativa, dati. Migliora gestione, sicurezza e scalabilità.

Microservizi e API REST

Nelle applicazioni moderne Web e cloud si utilizzano architetture multilayer basate su microservizi. Invece di costruire un unico programma monolitico, l’applicazione è suddivisa in servizi piccoli, indipendenti e specializzati.

Ogni microservizio:

  • svolge una funzione specifica (es. autenticazione, pagamenti, catalogo prodotti);
  • comunica con gli altri tramite API REST;
  • può agire da client o server a seconda del contesto;
  • può essere sviluppato, aggiornato e scalato in modo indipendente.

Cos’è un’API REST?

Un’API REST (Representational State Transfer) è uno stile architetturale per la progettazione di servizi web che permette a diverse applicazioni di comunicare tra loro su rete, seguendo un insieme di regole per rendere le interazioni semplici, scalabili e standardizzate.

Caratteristiche di un’API REST
Metodi HTTP

Usa GET, POST, PUT, DELETE per gestire le risorse

Formato dati

Tipicamente JSON o XML per la rappresentazione delle risorse

Stateless

Ogni richiesta è indipendente; il server non mantiene stato tra le chiamate

Interoperabilità

Funziona tra sistemi, linguaggi e piattaforme diverse

Monolitica vs Microservizi — confronto

Aspetto
Monolitica
Microservizi
Deploy
Unico blocco da deployare
Ogni servizio indipendente
Scalabilità
Scala tutto insieme
Scala solo i servizi necessari
Complessità
Semplice da sviluppare inizialmente
Più complessa la gestione distribuita
Aggiornamenti
Richiede redeploy completo
Aggiorna solo il servizio modificato
📌 Riepilogo — Punti chiave
  • Il modello client-server descrive processi, non macchine fisiche
  • Il client è attivo (inizia la comunicazione), il server è passivo (ascolta e risponde)
  • Le architetture multi-tier separano presentazione, logica e dati, migliorando sicurezza e manutenibilità
  • I microservizi comunicano tramite API REST: stateless, con metodi HTTP e dati in JSON

Lascia un commento