Oggetti distribuiti, servizi e middleware

1. Middleware e trasparenza

Un middleware è uno strato software tra il sistema operativo e le applicazioni distribuite. Gira sui nodi con una vita propria, indipendente dalle applicazioni che lo usano, e offre loro servizi come la comunicazione, i nomi per trovare le risorse, la persistenza, così che le parti di un'applicazione interagiscano senza scendere al livello di socket e protocolli. Può essere a sua volta distribuito su un cluster, installato in casa o usato come servizio nel cloud.

Il modello canonico del capitolo 17 sono processi che si scambiano messaggi. La tentazione storica è stata continuare a programmare con il paradigma noto e lasciare al middleware il compito di rendere trasparente la distribuzione.

• Remote Procedure Call (anni '80). Il programma chiama una procedura che si trova su un altro nodo come se fosse locale. Un proxy (o stub) lato client impacchetta i parametri (marshalling) e li spedisce via TCP o UDP; dall'altra parte uno skeleton li spacchetta, esegue la procedura e rimanda il risultato.
• Distributed object computing (anni '80–'90). Lo stesso schema con gli oggetti: si invocano metodi su oggetti che vivono in un altro processo. CORBA aggiunge l'interoperabilità tra linguaggi diversi, Microsoft propone DCOM, Java aggiunge RMI nel 1997, con il JDK 1.1.

La comunicazione può essere transitoria, solo tra processi in esecuzione nello stesso momento (socket, RPC, RMI e CORBA, MPI), oppure persistente: i messaggi restano nel middleware finché il destinatario non li preleva, come nelle code dei MOM (sezione 4).

Write once, run anywhere?

Lo slogan di Java promette una trasparenza simile rispetto alla piattaforma: il bytecode gira uguale su ogni JVM. Regge per il codice sequenziale, non con i thread. I thread Java poggiano su quelli del sistema operativo, quindi scheduling, priorità, numero massimo di thread e memoria dipendono dal sistema: un programma che crea molti thread può fermarsi su un sistema operativo e non su un altro. E l'interleaving cambia da macchina a macchina, per cui una race condition mai vista su un computer può comparire su un altro con più core o uno scheduler diverso. La correttezza di un programma concorrente non può dipendere dalla piattaforma su cui è stato provato (capitolo 10).

2. Perché la trasparenza non basta

L'articolo A Note on Distributed Computing (Waldo et al., 1994) spiega perché applicare l'OOP al distribuito astraendo dalla distribuzione non funziona. Gli argomenti sono due.

I guasti parziali. Se durante una chiamata c.inc() la rete cade, il chiamante deve saperlo. Ma per il dominio inc() non ha motivo di sollevare eccezioni: bisogna aggiungerne una estranea al dominio (in Java RemoteException) e il codice per gestirla. Lo stesso codice non funziona quindi identico in locale e in remoto: il caso locale è un caso particolare del distribuito, non il contrario. Con gli attori il problema non si pone, perché send non ha mai promesso che il messaggio arrivi: se serve una conferma, fa parte del protocollo.

La latenza. Una chiamata locale costa un microsecondo o meno, una remota da un millisecondo in LAN a centinaia nel cloud: almeno tre ordini di grandezza in più. Trattare allo stesso modo le interazioni tra oggetti vicini e tra oggetti su nodi diversi ignora il principio di località. E con chiamate tutte sincrone, catene di chiamate che attraversano i nodi e tornano indietro portano facilmente a deadlock.

Le Lab Notes sui MOM riassumono i problemi dell'RPC tradizionale in quattro punti: accoppiamento stretto (ogni cambio di interfaccia va propagato a tutti), affidabilità (il modello sincrono reagisce male ai guasti), scalabilità (le chiamate bloccanti pesano sulle prestazioni), disponibilità (entrambi i partecipanti devono essere attivi). La direzione è quindi il controllo decentralizzato e l'interazione asincrona: message passing, attori, middleware a messaggi. Hewitt pensò gli attori (1973) proprio per il distribuito; Ricci li paragona all'assembly del distribuito, una base su cui costruire astrazioni più alte. RMI resta utile come mattone per altri middleware, non come modello generale.

3. Java RMI

Java RMI (Remote Method Invocation) permette a un thread di una JVM di invocare un metodo su un oggetto che vive in un'altra JVM, anche su un altro nodo, con la sintassi di una chiamata locale. È il middleware del secondo esercizio dell'assignment 4, il tris distribuito, discusso nella pagina di preparazione.

• Un oggetto remoto implementa un'interfaccia che estende java.rmi.Remote, un'interfaccia marcatore vuota. Ogni metodo dell'interfaccia dichiara throws RemoteException, anche quando per il dominio non avrebbe senso: la trasparenza non è completa. L'implementazione è una classe normale.
• Il server crea l'oggetto, lo esporta con UnicastRemoteObject.exportObject, che restituisce lo stub (il proxy per i client), e registra lo stub con un nome nel registry.
• Il registry è il servizio di nomi: rmiregistry deve girare su ogni nodo che ospita oggetti remoti e vederne le classi (il modo più semplice è lanciarlo da target/classes), oppure si avvia dal programma con LocateRegistry.createRegistry. Se manca, la registrazione fallisce con connection refused.
• Il client prende il registry dell'host remoto, fa lookup per nome e un cast all'interfaccia (nessun controllo di tipo alla registrazione), poi chiama i metodi come se l'oggetto fosse locale.

// Interfacce remote: estendono Remote, ogni metodo dichiara RemoteException
public interface Counter extends Remote {
  void inc() throws RemoteException;
  int getValue() throws RemoteException;
  void addListener(CounterListener l) throws RemoteException;
}
public interface CounterListener extends Remote {
  void countIncremented(int value) throws RemoteException;
}

// Implementazione: una classe normale. Il runtime RMI la chiama da più thread.
public class CounterImpl implements Counter {
  private int value;
  private final List<CounterListener> listeners = new ArrayList<>();

  public void inc() {
    int v; List<CounterListener> ls;
    synchronized (this) { v = ++value; ls = List.copyOf(listeners); }
    for (var l : ls) {                      // callback remote, fuori dal lock
      try { l.countIncremented(v); } catch (RemoteException e) { /* client irraggiungibile */ }
    }
  }
  public synchronized int getValue() { return value; }
  public synchronized void addListener(CounterListener l) { listeners.add(l); }
}

// Server: esporta l'oggetto (ottiene lo stub) e lo registra con un nome
var stub = (Counter) UnicastRemoteObject.exportObject(new CounterImpl(), 0);
LocateRegistry.getRegistry().rebind("countObj", stub);

// Client: cerca per nome, poi usa l'oggetto come se fosse locale
class MyListener implements CounterListener {
  public void countIncremented(int v) { System.out.println("nuovo valore: " + v); }
}
var c = (Counter) LocateRegistry.getRegistry(host).lookup("countObj");
var me = (CounterListener) UnicastRemoteObject.exportObject(new MyListener(), 0);
c.addListener(me);     // passa uno stub: il server potrà richiamare il client
c.inc();               // sincrona: il thread aspetta la risposta dalla rete

• La chiamata è sincrona. Il thread del client resta bloccato finché il risultato non torna. Lo stub solleva RemoteException se il nodo non è raggiungibile, ma anche se la connessione cade a richiesta già partita.
• Il passaggio dei parametri. Un oggetto normale passa per valore: viene serializzato e dall'altra parte arriva una copia, che le modifiche remote non toccano. La sua classe deve implementare Serializable; se non lo fa, né il compilatore né il registry se ne accorgono e l'errore (MarshalException) arriva alla chiamata. Un oggetto remoto esportato passa invece per riferimento, perché viaggia il suo stub: così il server richiama il client (pattern observer), e nel tris un giocatore riceve la mossa dell'avversario.
• La concorrenza lato server. RMI serve le richieste con un pool di thread, che possono eseguire in parallelo metodi dello stesso oggetto. L'oggetto remoto è stato condiviso e va protetto come un monitor. È un componente passivo: il flusso di controllo viene dai thread dei client e di RMI.

4. Middleware orientati ai messaggi

Un MOM (Message-Oriented Middleware) è qualunque infrastruttura middleware che offre messaggistica: i client inviano e ricevono messaggi da altri client, con garanzie di affidabilità, sicurezza e prestazioni. È un pilastro dei sistemi enterprise e può essere centralizzato o distribuito. Rispetto all'RPC rende i messaggi espliciti, l'interazione asincrona e la comunicazione persistente: il middleware sta in mezzo e disaccoppia i partecipanti.

Code, broker e modelli di messaggistica

Il concetto fondamentale è la coda di messaggi, che conserva i messaggi sulla piattaforma. Le code si collegano tramite router oppure tramite broker, server che ricevono, conservano e smistano i messaggi. I modelli di messaggistica sono due:

• Point-to-point: message passing asincrono puro; tipicamente più produttori depositano in una coda FIFO e ogni messaggio va a un solo consumatore.
• Publish/subscribe: diffusione tra produttori e consumatori che non si conoscono, uno-a-molti o molti-a-molti. I publisher pubblicano su un topic, i subscriber si abbonano ai topic che interessano, eventualmente con filtri.

Il consumatore riceve in pull, interrogando il provider, o in push, facendosi inviare i messaggi appena arrivano. Il filtraggio seleziona i messaggi ricevuti da un canale; i namespace gerarchici permettono di abbonarsi al livello giusto di un albero di sotto-canali, utile con grandi volumi di messaggi. Come qualità del servizio un MOM offre le garanzie di consegna già viste per gli attori: at-least-once, at-most-once, exactly-once (capitolo 15).

RabbitMQ

Il laboratorio usa RabbitMQ, un broker open source (si avvia comodamente con Docker). Un produttore pubblica su un exchange, che smista i messaggi nelle code: l'exchange di default consegna alla coda con il nome indicato (point-to-point), fanout copia il messaggio in tutte le code collegate (publish/subscribe), direct instrada in base a una chiave esatta, topic anche con pattern come kern.*.

var factory = new ConnectionFactory();
factory.setHost("localhost");

// Produttore: dichiara la coda e pubblica tramite l'exchange di default
try (var conn = factory.newConnection(); var ch = conn.createChannel()) {
  ch.queueDeclare("hello", false, false, false, null);
  ch.basicPublish("", "hello", null, "Hello World!".getBytes(StandardCharsets.UTF_8));
}

// Consumatore (un altro processo): la connessione resta aperta,
// la callback è eseguita da un thread del client RabbitMQ
var conn = factory.newConnection();
var ch = conn.createChannel();
ch.queueDeclare("hello", false, false, false, null);
DeliverCallback onMessage = (tag, delivery) ->
    System.out.println(new String(delivery.getBody(), StandardCharsets.UTF_8));
ch.basicConsume("hello", true, onMessage, tag -> {});   // autoAck = true

Con più consumatori sulla stessa coda i messaggi si distribuiscono tra loro (work queue); con autoAck = false il consumatore conferma a mano con basicAck dopo aver elaborato, così un messaggio non confermato torna in coda se il consumatore cade. L'esercizio opzionale dell'assignment 4 chiede di costruire su un MOM un piccolo middleware per sezioni critiche distribuite, con gli algoritmi del capitolo 18.

5. Servizi e architetture orientate ai servizi

I servizi sono oggi l'approccio principale ai sistemi distribuiti su Internet. Un servizio è un componente software fornito attraverso un endpoint raggiungibile in rete: un provider lo offre, dei consumer lo usano scambiando messaggi. Due visioni sono in concorrenza e in convergenza: la SOA dei «big» web service (lo stack WS-*), nata per l'enterprise, e i web service RESTful, che espongono risorse; a queste si aggiungono i microservizi.

Una SOA (Service-Oriented Architecture) separa le responsabilità scomponendo la logica di business in unità più piccole e distinte, che insieme formano una logica più grande, distribuita logicamente e fisicamente. I servizi sono autonomi, anche nei linguaggi e nelle tecnologie, e interoperano grazie a standard condivisi, interfacce e contratti tra chi offre e chi usa. La descrizione di un servizio serve a scoprirlo e funziona da contratto; la comunicazione avviene con messaggi, unità indipendenti.

La SOA è uno stile architetturale: definisce componenti, relazioni e vincoli su uso e interazioni. I componenti sono sei:

Otto principi guidano il progetto. I servizi sono:

• riusabili, progettati per il riuso anche se al momento non serve;
• legati da un contratto formale: per interagire non condividono nient'altro che un contratto che li descrive e fissa i termini dello scambio;
• debolmente accoppiati, senza dipendenze strette tra loro;
• astratti: dall'esterno si vede solo ciò che il contratto espone;
• componibili: un servizio può comporne altri, a più livelli di astrazione;
• autonomi: la loro logica sta dentro un confine esplicito, sotto il loro controllo;
• senza stato il più possibile, delegando lo stato altrove per restare disaccoppiati;
• scopribili (discoverability): la loro descrizione può essere trovata e capita da persone e da altri servizi che potrebbero usarli.

Il beneficio principale è eliminare l'integrazione punto a punto. Le aziende crescono per sistemi isolati, uno per reparto, e ogni volta che due devono condividere dati nasce un collegamento ad hoc (database, file, ETL, chiamate dirette), fino a uno «spaghetti di integrazione» ingestibile. Con i servizi migliorano l'adattabilità (l'interno si cambia rispettando i contratti), la manutenibilità (team piccoli e dedicati) e la riusabilità, intesa come non buttare via tutto quando serve altro, non come «write once, integrate anywhere». I confini espliciti sostituiscono anche la «zuppa di oggetti». Per il business ne derivano sostituzione più facile dei componenti, time to market più breve, integrazione dei partner, meno downtime, SLA configurabili.

6. Web service: SOAP, WSDL e REST

I «big» web service

Un web service è una SOA con scelte tecnologiche precise: XML, SOAP e WSDL, più gli standard WS-* per sicurezza, affidabilità, trust e altre qualità del servizio. Obiettivo: interoperabilità tra middleware eterogenei e disaccoppiamento tra consumer e provider, che si scambiano documenti autocontenuti con pochissime ipotesi su chi li riceve. A differenza di RMI e CORBA non ci sono riferimenti a oggetti remoti, quindi nessun broker che gestisca uno spazio di indirizzi distribuito; si supportano sia lo stile RPC sia quello a messaggi.

• SOAP è un linguaggio XML che definisce l'architettura e il formato dei messaggi: un elemento Envelope contiene un Header estensibile, per informazioni di infrastruttura come l'instradamento e la qualità del servizio (transazioni, sicurezza, affidabilità), e un Body con il contenuto. La struttura è descritta con XML Schema, così i motori SOAP ai due capi possono fare marshalling e unmarshalling.
• WSDL è il linguaggio XML che definisce l'interfaccia, cioè il contratto: il portType elenca le operazioni astratte con i loro messaggi di input e output, il binding le lega a un protocollo di trasporto e a un formato concreti, per esempio SOAP su HTTP. Gli endpoint si indicano con URI o con WS-Addressing.

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
  <soap:Body>
    <m:GetPrice xmlns:m="http://www.w3schools.com/prices">
      <m:Item>Apples</m:Item>
    </m:GetPrice>
  </soap:Body>
</soap:Envelope>

Implementazioni: .NET WCF, la specifica JAX-WS (per esempio Apache Axis2), Eclipse Web Tools Platform.

REST

REST (REpresentational State Transfer) è lo stile architetturale per sistemi ipermediali su larga scala introdotto da Roy Fielding nella tesi di dottorato: spiega la scalabilità di HTTP/1.0 e ha guidato il progetto di HTTP/1.1. Componenti debolmente accoppiati, indipendenti da tecnologie e piattaforme, comunicano tramite interfacce su protocolli web standard, con la semplicità come principio. Unendo architettura software e architettura di rete (banda, throughput, latenza) è adatto ai sistemi in cui conta la scalabilità, e i web service RESTful sono oggi lo standard di fatto delle API web.

In una SOA REST il contratto di un servizio si scompone in capability, una per funzione offerta, e tutti i servizi condividono un contratto uniforme di tre elementi:

• sintassi degli identificatori di risorsa: gli URI HTTP, {scheme}://{authority}{path}?{query}#{fragment}, per esempio http://customer.example.com/customer/C081;
• metodi: quelli di HTTP, POST per creare una risorsa, GET per leggerne una rappresentazione, PUT per modificarla, DELETE per eliminarla;
• media type: il formato dei dati trasferiti, XML o JSON.

Basta qualunque libreria HTTP, ma esistono API dedicate come JAX-RS (implementata per esempio da Jersey e RESTEasy; Spring e Vert.x, citati nelle slide, offrono API REST proprie). Le interfacce si specificano con OpenAPI, nato da Swagger, che genera anche stub client e skeleton server; alternative sono RAML e Restlet. GraphQL lascia al client descrivere query flessibili, così le API evolvono più facilmente. Le API web sono ormai attese da ogni applicazione, anche perché permettono ai fornitori di sapere chi usa i servizi e di farsi pagare a chiamata.

7. Microservizi e stili architetturali

I microservizi sono uno stile architetturale in cui una singola applicazione è una suite di piccoli servizi, ognuno nel proprio processo, che comunicano con meccanismi leggeri (API REST o messaggistica leggera). Sono costruiti attorno alle capacità di business, si rilasciano indipendentemente con deploy automatizzato, hanno una gestione centralizzata minima e possono usare linguaggi e database diversi. Anche i big web service sono servizi, ma standardizzano l'interoperabilità tra sistemi enterprise con uno stack pesante (SOAP, WSDL, WS-*); i microservizi scompongono una applicazione in servizi piccoli, con protocolli leggeri, deploy e dati indipendenti.

Stili architetturali

L'architettura di un sistema è l'insieme delle strutture necessarie per ragionarci: elementi software, relazioni e proprietà di entrambi (Bass et al.); serve a dividere il lavoro tra team e a soddisfare i requisiti di qualità. Uno stile architetturale definisce una famiglia di sistemi con lo stesso schema: il vocabolario di componenti e connettori e i vincoli su come combinarli (Garlan e Shaw). Le slide ne confrontano quattro:

API e interazioni

L'API di un servizio espone comandi, query ed eventi. Tutta l'interazione passa da lì, e questo rende i servizi debolmente accoppiati: l'implementazione può cambiare senza toccare i client. Le interazioni si classificano su due assi:

Le tecnologie di comunicazione sono REST, usato come trasporto per chiamate RPC (che accoppia) o in stile davvero RESTful (che disaccoppia), eventualmente con WebSocket per gli eventi; i messaggi su MOM, asincroni e disaccoppianti; gRPC e GraphQL tra le più recenti.

Come si organizzano

I servizi sono componenti fuori processo, a differenza delle librerie chiamate in memoria. Si rilasciano e scalano uno per uno, purché i contratti evolvano con giudizio, e hanno un confine di modulo netto, mentre in un monolite spesso solo la disciplina protegge l'incapsulamento. Il prezzo: le chiamate remote costano molto di più, quindi le API devono essere a grana più grossa.

La scomposizione è per capacità di business, non per tecnologia. Se i team si dividono per strato (interfaccia, logica, database), anche una modifica semplice diventa un progetto tra team; con i microservizi ogni servizio copre un'area dall'interfaccia ai dati, con un team cross-funzionale. Il riferimento è il Domain-Driven Design (Evans): un modello del dominio con il vocabolario del team (ubiquitous language), diviso in sottodomini; l'ambito di un modello è un bounded context, che diventa un servizio o un gruppo di servizi. L'approccio API-first scrive prima l'interfaccia con un IDL (OpenAPI, RAML), la rivede con i client e solo dopo implementa.

8. Cloud: dall'infrastruttura alle funzioni

Il cloud computing è una delle scelte principali per le applicazioni distribuite su larga scala, per scalabilità, apertura ed eterogeneità, disponibilità. È un cambio di paradigma nell'erogazione dei servizi informatici: servizi, calcolo e dati si spostano, per costo e convenienza, off-premise, in un impianto centralizzato e trasparente rispetto alla posizione, invece che on-premise. Lo hanno trainato Google, Yahoo, Amazon, che hanno insegnato al mondo a costruire architetture massivamente scalabili. I dati nel cloud sono più facili da raggiungere, costano meno e si prestano a collaborazione e analisi; restano da valutare prestazioni e sicurezza.

Da CapEx a OpEx

Prima, lanciare un servizio richiedeva una grande CapEx (spesa in conto capitale): comprare in anticipo l'infrastruttura per il picco di domanda. Il cloud fa seguire le spese all'uso effettivo delle risorse, e quindi agli incassi, in tre modi: trasforma la CapEx in OpEx (spesa operativa); elimina buona parte del personale che amministra i server; rende facile crescere in caso di successo, senza costose modifiche architetturali. Con costi di lancio bassi si provano più servizi senza rischiare investimenti in infrastruttura che potrebbe non servire.

I modelli di servizio

Salendo da IaaS a SaaS il fornitore gestisce sempre più livelli e il cliente sempre meno. I principali fornitori sono Amazon AWS, Google Cloud Platform, Microsoft Azure, Heroku; Cloud Foundry è una PaaS open source. Le PaaS hanno in comune un'architettura a servizi (REST, GraphQL, gRPC) e un insieme di servizi di base: memorizzare e recuperare dati, eseguire e gestire attività di lunga durata, comunicare, configurare e gestire le applicazioni.

FaaS e serverless

Il FaaS (Function as a Service) porta nel cloud codice organizzato in funzioni, attivate da eventi definiti dallo sviluppatore. È simile a una PaaS ma più leggero: più reattivo e con scalabilità automatica. Esempi: AWS Lambda, Google Cloud Functions. Oggi si parla di serverless computing, che ha quattro caratteristiche:

• nessun server né sistema operativo da configurare o gestire;
• fatturazione per invocazione;
• scalabilità automatica con l'uso;
• disponibilità e tolleranza ai guasti incorporate.

È adatto a problemi scomponibili in parti senza stato, piccole e dal comportamento prevedibile. Le funzioni sono effimere, con una durata nota e limiti di tempo imposti dalla piattaforma, e non conservano stato tra un'invocazione e l'altra: se l'applicazione ha uno stato, sta in un data store.

Verifica le tue conoscenze