L’anagrafica autoritativa di una società scientifica vive sulla rete locale della sede, ma i servizi rivolti ai soci devono stare su un server pubblico: il problema è replicare il dato fra due macchine che non possono fidarsi della stessa rete. Sono settimane che ragiono su questo schema, applicato alla gestione dei soci della SIRM, la Società Italiana di Radiologia Medica, e queste sono le note tecniche che ne ricavo.

Contesto e problema

Una società di categoria con migliaia di iscritti, col tempo, accumula sistemi separati: un gestionale per l’anagrafica, fogli di calcolo per la contabilità, un mailserver per la posta, qualche pagina statica per il sito. Ogni sistema tiene una copia parziale dei dati del socio e nessuno è autoritativo. Riconciliare un indirizzo cambiato o una quota pagata vuol dire mettere mano a tre archivi.

Il vincolo che cambia il disegno è la posizione fisica. Il dato anagrafico autoritativo deve restare in sede — per ragioni di controllo, di responsabilità sul trattamento e perché chi lavora in segreteria opera sulla rete locale. I servizi verso l’esterno — pagamento della quota con carta, iscrizione a un evento formativo, votazioni societarie — devono invece stare su un server raggiungibile da Internet, che per definizione non si vuole esporre dentro la rete della sede.

Da qui la scelta di due nodi anziché uno: un server in sede con il database autoritativo, un server in hosting che ne tiene una copia per i soli servizi pubblici.

Architettura

Il dato di identità del socio — chi è, le sue credenziali, l’appartenenza a sezioni e gruppi di studio — sta in una directory LDAP. Qui LDAP è la scelta giusta perché il modello è una gerarchia di voci con attributi multipli, e perché la stessa directory autentica già la posta. Lo schema si appoggia alle classi standard di persona della RFC 2256, estese con attributi propri della società per matricola, sezione regionale e stato della quota. Il protocollo è LDAPv3 (RFC 2251).

Il dato transazionale — pagamenti, iscrizioni a eventi, abstract di congresso — sta invece in MySQL, dove la consistenza referenziale fra tabelle pesa più della struttura ad albero.

I servizi web girano su Zope: l’application server in Python tiene gli oggetti applicativi in ZODB, il suo database a oggetti, e parla con LDAP e MySQL per i dati strutturati. Ho scelto Zope perché la logica di una società — un socio appartiene a una sezione, che appartiene a un comitato — si modella più naturalmente come grafo di oggetti che come righe di tabella.

La replica fra i due nodi segue il verso del dato:

  • L’identità scorre da LDAP in sede a una copia LDAP in hosting. Il front-end pubblico legge da questa copia per autenticare il socio e non scrive mai sull’anagrafica autoritativa.
  • Le transazioni nascono in hosting — è lì che il socio paga e si iscrive — e risalgono verso il database in sede, dove la segreteria le riconcilia con l’anagrafica.

Il canale fra i due nodi è cifrato con SSL. Dove la connettività della sede non è permanente, la replica delle transazioni va in differita: accoda le scritture e le smaltisce alla riconnessione. L’identità in lettura tollera bene un ritardo, perché un socio nuovo che non riesce a pagare per qualche minuto è un fastidio, non un dato perso.

Punto critico

Il rischio di tutto lo schema è la direzione della scrittura. Se entrambi i nodi potessero scrivere sull’anagrafica, una modifica fatta in sede e una fatta in hosting sullo stesso socio porterebbero a un conflitto che nessuna regola automatica risolve bene: qual è l’indirizzo giusto, quello digitato dalla segreteria o quello aggiornato dal socio sul portale?

La risposta è togliere la simmetria. L’anagrafica ha una sola sorgente di verità, il nodo in sede. Il nodo in hosting è in sola lettura sull’identità e in sola scrittura sulle transazioni, che la sede importa ma non genera. Così non ci sono due scritture concorrenti sullo stesso campo, e la replica diventa un flusso a senso unico per ogni classe di dato, non una sincronizzazione bidirezionale da arbitrare.

La replica MySQL va in questa direzione: nel modello master-slave introdotto con la serie 4.0, le scritture vanno sul master e gli slave applicano in sequenza ciò che leggono dal log binario del master. Lo slave non accetta scritture che competano con il master. Lo stesso principio — un solo scrittore per ogni dato — vale anche per il ramo LDAP, dove la copia in hosting è un consumer e mai un master.

Implicazioni

Tenere LDAP come fonte dell’identità ha un effetto che va oltre la gestione soci: il mailserver già in produzione autentica le caselle contro la stessa directory. Casella di posta, quota disco, alias e regole di vacation diventano attributi del socio, non un sistema a parte da tenere allineato a mano. Quando la segreteria sospende un socio moroso, la sospensione della posta segue dallo stesso cambio di stato nella directory.

Sul piano degli obblighi, un sistema che gestisce eventi con crediti ECM — il programma di Educazione Continua in Medicina avviato dal Ministero della Salute nel 2002 — deve legare ogni partecipazione all’anagrafica del socio e conservarne lo storico, perché il credito formativo va certificato al singolo professionista. Con identità e partecipazione nello stesso impianto, anziché in archivi scollegati, quel certificato resta verificabile.

L’accessibilità non è un dettaglio da rimandare: un portale rivolto a una categoria professionale ricade sotto le linee guida AIPA per i siti di pubblica utilità e sotto le raccomandazioni WAI del W3C. Costruire le pagine con marcatura corretta fin dall’inizio costa meno che adeguarle dopo.

Limiti

Lo schema regge finché il verso della scrittura resta univoco. Nel momento in cui un requisito chiede che il socio modifichi da sé la propria anagrafica dal portale — non una transazione, ma il dato autoritativo — la separazione netta salta e serve un percorso di approvazione che riporti la modifica al nodo in sede prima di renderla effettiva. È una complicazione prevedibile, da progettare a parte e non da innestare sulla replica.

Il secondo limite è operativo. La replica in differita su connettività intermittente sposta il problema dalla disponibilità alla coda: se la sede resta offline a lungo, le transazioni si accumulano in hosting e la finestra di riconciliazione si allarga. Va monitorata la lunghezza della coda, non solo lo stato dei due server, perché due nodi entrambi attivi possono comunque essere fuori sincrono.

Resta poi la dipendenza dall’intero stack open source — Linux, Apache, Python, Zope, MySQL, il ramo LDAP — di cui questa architettura è figlia: qui nessuno di questi componenti è un dettaglio sostituibile a piacere, e la coerenza dell’insieme è parte del disegno.

Su questo impianto noze sta costruendo per la SIRM un sistema integrato di gestione soci, dove la replica master-slave si estende anche al mailserver Hermes già in hosting tramite la directory LDAP condivisa: https://www.noze.it/insights/sirm-sistema-gestione-soci/.

https://www.rfc-editor.org/rfc/rfc2251 https://www.rfc-editor.org/rfc/rfc2256 https://www.sirm.org/ https://www.zope.org/ https://www.mysql.com/ https://www.w3.org/WAI/

Immagine di copertina: Radiografia in bianco e nero di una mano umana con un anello al dito anulare; le ossa appaiono chiare su sfondo scuro — foto di Wilhelm Conrad Röntgen, pubblico dominio — https://commons.wikimedia.org/wiki/File:First_medical_X-ray_by_Wilhelm_R%C3%B6ntgen_of_his_wife_Anna_Bertha_Ludwig%27s_hand_-_18951222.jpg