Architetture software e web services: la guida che il prof non ti dà (e che ti salva all'orale)

Introduzione: perché l'architettura fa la differenza tra un'app che funziona e una che vola

Immagina di costruire una casa. Puoi avere i mattoni più resistenti del mondo, ma se la fondamenta è sbagliata, prima o poi crolla tutto. Lo stesso vale per il software. L'architettura software è lo scheletro, l'impianto idraulico e l'impianto elettrico della tua applicazione. Sceglierla bene significa decidere se la tua app reggerà 10 utenti o 10 milioni.

Oggi all'orale di informatica non ti chiederanno solo "cos'è un web service", ma ti interrogheranno sulle scelte architetturali: perché Netflix ha abbandonato il monolite? Perché il tuo bancomat usa SOAP mentre Instagram usa REST? Questa guida ti fornisce la mappa concettuale per rispondere con sicurezza, collegando la teoria alla pratica reale delle aziende tech.

Definizione chiave: Un'architettura software è l'insieme delle scelte strategiche riguardanti l'organizzazione di un sistema software, i suoi componenti, le loro relazioni e i principi che ne guidano la progettazione e l'evoluzione.

Prima di entrare nel vivo, se vuoi testare le tue conoscenze, prova il nostro Quiz Maturità AI dedicato proprio a questi argomenti.

Architetture software: dal monolite ai microservizi

Qui sta il primo bivio fondamentale. Negli anni '90 si costruivano monoliti: applicazioni uniche, giganti, dove tutto il codice (interfaccia, logica di business, database) viveva insieme come in un unico grattacielo. Funzionava, ma aveva un problema: per cambiare una finestra, dovevi chiudere l'intero palazzo.

L'architettura monolitica

Nella struttura monolitica, tutti i moduli sono compilati insieme e girano come unico processo. È semplice da sviluppare inizialmente, ma presenta il coupling (accoppiamento) massimo: ogni modifica può influenzare inavvertitamente altre parti.

• Vantaggi: Semplice da testare in locale, deployment unico, debugging lineare.
• Svantaggi: Scalabilità verticale costosa (devi potenziare l'intero server), rischio elevato di regressioni, stack tecnologico unico e rigido.

L'architettura Client-Server

La prima evoluzione verso la distribuzione. Il client (la tua app, il browser) richiede servizi al server (la macchina potente che ospita i dati). È un modello two-tier (due livelli) o three-tier se aggiungi il database come livello separato.

Questa è la base dei web services: il client non sa come il server elabora i dati, conosce solo l'interfaccia (l'API). Questo principio si chiama information hiding (incapsulamento) ed è fondamentale.

I microservizi: la rivoluzione dei "piccoli mattoni"

Introdotti da aziende come Netflix e Amazon intorno al 2010-2012, i microservizi spezzano l'applicazione in tanti piccoli servizi indipendenti. Ognuno ha il proprio database, il proprio stack tecnologico e comunica con gli altri via rete (tipicamente HTTP/REST o messaggistica asincrona).

Trucco mnemonico: pensa ai microservizi come a un ristorante con cucine separate: la pizzeria, la griglia, il bar. Se la griglia brucia, il bar continua a servire caffè. Nel monolite, se brucia la cucina, chiude tutto il ristorante.

• Vantaggi: Scalabilità orizzontale (aggiungi solo i server che servono), fault isolation (un guasto non blocca tutto), tecnologie eterogenee (puoi usare Python per l'AI e Node.js per il frontend).
• Svantaggi: Complessità operativa, latenza di rete tra servizi, necessità di orchestrazione (Docker, Kubernetes).

Non perdere neanche un argomento!

Con i Riassuntoni cartacei hai il programma completo di ogni materia, pronto per il ripasso finale.

Ordina il tuo Riassuntone

Web Services: quando le macchine parlano tra loro

I web services sono l'implementazione pratica delle architetture distribuite. Permettono a software diversi, su piattaforme diverse, di comunicare via internet. Esistono due filosofie principali: SOAP e REST.

SOAP: il peso massimo della formalità

Acronimo di Simple Object Access Protocol (anche se oggi si usa solo come nome, non più come acronimo), SOAP è un protocollo stretto e formale. Usa esclusivamente XML per i messaggi e richiede una definizione rigida del servizio tramite WSDL (Web Services Description Language).

SOAP viaggia tipicamente su HTTP (ma può usare anche SMTP o altri) e include header di sicurezza integrati (WS-Security). È pesante, verboso, ma robustissimo. Lo trovi ancora in banche, assicurazioni e sistemi legacy enterprise dove la sicurezza e le transazioni ACID sono prioritarie.

REST: l'architettura leggera del web moderno

Representational State Transfer, teorizzato da Roy Fielding nella sua tesi di dottorato del 2000, non è un protocollo ma uno stile architetturale. Si basa su pochi principi rigidi:

1. Client-Server: separazione netta tra interfaccia e dati.
2. Stateless: ogni richiesta dal client al server deve contenere tutte le informazioni necessarie per essere compresa. Il server non conserva lo stato della sessione (nessuna memoria tra una chiamata e l'altra).
3. Cacheable: le risposte devono definirsi esplicitamente come cacheabili o meno.
4. Interfaccia uniforme: uso standardizzato dei metodi HTTP.

I metodi HTTP fondamentali:

• GET: lettura di una risorsa (idempotente, cioè fare la stessa richiesta 100 volte dà lo stesso risultato).
• POST: creazione di una nuova risorsa.
• PUT: aggiornamento completo di una risorsa esistente (idempotente).
• PATCH: aggiornamento parziale.
• DELETE: eliminazione di una risorsa (idempotente).

REST usa tipicamente JSON (JavaScript Object Notation) come formato dati, più leggero e leggibile dell'XML. Ecco perché è preferito da app mobile e single-page applications.

GraphQL e gRPC: le evoluzioni moderne

Oltre ai "classici" REST e SOAP, all'orale potrebbero chiederti tecnologie recenti:

• GraphQL (2015): linguaggio di query sviluppato da Facebook. Il client specifica esattamente quali campi vuole ricevere, evitando over-fetching (ricevere dati inutili) o under-fetching (dovere fare più chiamate).
• gRPC (2015): framework RPC (Remote Procedure Call) sviluppato da Google. Usa Protocol Buffers (formato binario compatto) invece di JSON/XML, è molto veloce e tipizzato, ideale per microservizi interni.

Pattern architetturali: MVC, SOA e l'API Gateway

I pattern sono soluzioni "templatizzate" a problemi ricorrenti. Conoscerli dimostra maturità progettuale.

MVC (Model-View-Controller)

Pattern classico per applicazioni web. Separa:

• Model: i dati e la logica di business (interazione con database).
• View: la presentazione (HTML, interfaccia utente).
• Controller: l'intermediario che riceve input dall'utente, manipola il Model e aggiorna la View.

Esempio pratico: su Instagram, il Controller riceve il tap "mi piace", aggiorna il Model (database dei like), e la View aggiorna il cuoricino rosso.

SOA (Service-Oriented Architecture)

Predecessore dei microservizi. Anche qui il sistema è diviso in servizi, ma sono più "grandi" (macro-servizi), spesso condividono un database centrale e usano pesantemente SOAP. I microservizi sono considerati un'evoluzione più fine-grained (a grana fine) della SOA.

API Gateway

Nelle architetture a microservizi, il client non chiama direttamente i singoli servizi (che potrebbero essere centinaia). Chiama un API Gateway: un singolo punto di ingresso che instrada le richieste, gestisce l'autenticazione, il rate limiting (quante chiamate al secondo puoi fare) e bilancia il carico tra le istanze dei servizi. È come il portiere di un grande hotel: tu chiedi a lui, lui sa dove trovare la persona giusta.

Sicurezza, scalabilità e il Cloud Native

Un'architettura moderna non è completa senza considerare scalabilità e sicurezza.

Scalabilità verticale vs orizzontale

• Verticale (scale up): aumenti la potenza della macchina esistente (più RAM, CPU più veloce). Ha limiti fisici e costa molto.
• Orizzontale (scale out): aggiungi più macchine (server) e distribuisci il carico. È la filosofia del cloud: "scale to zero" (paghi solo quello che usi) o "auto-scaling" (il sistema aggiunge server automaticamente quando il traffico aumenta).

Sicurezza nelle API

Non puoi lasciare le tue API aperte a chiunque. I meccanismi fondamentali:

• HTTPS: tutto il traffico deve essere cifrato con TLS (Transport Layer Security), evoluzione di SSL. Non esistono più scuse per usare HTTP in chiaro.
• Autenticazione: JWT (JSON Web Token) è lo standard moderno. Dopo il login, il server ti dà un token firmato che includi in ogni richiesta successiva.
• OAuth 2.0: protocollo per l'autorizzazione delegata (quando fai "Login con Google", stai usando OAuth).
• CORS (Cross-Origin Resource Sharing): meccanismo di sicurezza che impedisce a un sito web malizioso di fare richieste a un API a cui non è autorizzato.

Container e Orchestrazione

Per gestire decine di microservizi si usano i container (Docker): ambienti isolati che contengono codice e dipendenze. Kubernetes (K8s) è il sistema di orchestrazione che li gestisce: li avvia, li spegne, li bilancia, li aggiorna senza downtime (rolling update).

Schema riassuntivo: l'essenziale da ricordare all'orale

Se il commissario ti ferma nel corridoio e ti chiede "mi spieghi le architetture software in 2 minuti", usa questo schema:

Trucco per non confonderti: REST è come ordinare al ristorante (prendi il menu, chiedi, ti portano il piatto); SOAP è come contrattare un matrimonio (ci sono documenti legali, firme, notai). Entrambi funzionano, ma per scopi diversi.

Collegamenti interdisciplinari per colpire il commissario

L'orale di maturità premia i collegamenti. Ecco come intrecciare questo argomento con altre materie:

• Inglese: i termini tecnici sono tutti in inglese (backend, frontend, deployment). Puoi citare Roy Fielding e la sua tesi del 2000, o parlare di come le Silicon Valley abbiano imposto standard globali.
• Diritto/Economia: il GDPR (Regolamento 2016/679) impatta direttamente sulle architetture: i dati personali devono essere pseudonimizzati, il consenso tracciato. Un'architettura monolitica rende difficile l'anonimizzazione selettiva, mentre i microservizi permettono di isolare meglio i dati sensibili.
• Fisica: la latenza di rete è un problema fisico: la luce impiega tempo a viaggiare nei cavi. I microservizi introducono latenza tra chiamate (overhead di rete), quindi per applicazioni real-time (trading finanziario, chirurgia robotica) si preferisce ancora il monolite o l'elaborazione edge (calcolo vicino alla sorgente).
• Storia: l'evoluzione delle architetture riflette la storia dell'informatica: dal mainframe centralizzato (anni '70), al client-server (anni '90), al cloud distribuito (oggi). È la democratizzazione del calcolo: da pochi computer enormi a tanti computer piccoli e cooperanti.

Per affinare questi collegamenti in vista dell'orale, utilizza la nostra Simulazione Orale AI: un modo sicuro per provare le tue risposte e ricevere feedback immediati.

FAQ: le domande più insidiose all'orale

Quando conviene usare REST e quando SOAP?

Usa REST quando hai bisogno di leggerezza, velocità, e client vari (app mobile, web, IoT). Usa SOAP quando hai bisogno di transazioni complesse, sicurezza a livello enterprise (WS-Security), e affidabilità assoluta (settore bancario, assicurativo).

Cosa significa che REST è "stateless"? È un vantaggio?

Significa che ogni richiesta è indipendente. Il server non tiene memoria che sei "loggato" tra una chiamata e l'altra: devi dimostrarglielo ogni volta (con il token). È un vantaggio per la scalabilità (qualsiasi server può risponderti, non serve stickyness), ma uno svantaggio per applicazioni che richiedono stato persistente (usa WebSocket in quel caso).

Perché i microservizi sono più sicuri dei monoliti?

Non sono intrinsecamente più sicuri, ma permettono una difesa in profondità. Se un microservizio viene compromesso (es. quello dei commenti), l'attaccante non ha automaticamente accesso ai dati di pagamento (servizio separato). Nel monolite, una vulnerabilità può esporre tutto.

Cos'è il "contratto" in un web service?

È l'accordo formale su come comunicare. In SOAP è il WSDL (file XML che descrive esattamente metodi e parametri). In REST è meno formale: può essere una documentazione OpenAPI (Swagger) che descrive gli endpoint, i metodi HTTP accettati e il formato JSON atteso.

Cosa cambia tra Docker e Kubernetes?

Docker "contenizza" un'applicazione (la mette in una scatola isolata). Kubernetes gestisce migliaia di queste scatole su migliaia di macchine, decidendo dove metterle, come collegarle e come farle rinascere se si rompono.

Hai bisogno di altri approfondimenti? Consulta la sezione Appunti Maturità per trovare materiale correlato su database, sicurezza informatica e programmazione.