Le applicazioni basate su Fat-Client si riferiscono alla categorie delle applicazioni multistrato dove (nel modello più semplice) la parte client del codice (ovvero tutta quella parte costituita dai programmi con cui l’utente finale interagisce direttamente) risiedono e “girano” nel contesto del Desktop PC mentre la parte server (generalmente i programmi che gestiscono l’interazione con i database relazionali) risiedono e girano sul server di rete.

Al contrario, nel modello basato su Thin-Client, si rifersice alle applicazioni multistrato dove la parte di codice con la quale l’utente integragisce risiede e viene fatta girare all’interno di un browser ma l’esecuzione del codice che l’utente invoca avviene interamente all’interno del server di rete, non nel PC.

Fatte queste precisazioni è bene prendere in esame quattro regole fondamentali :

1. Per applicazioni identiche, la migrazione dal modello Fat-Client al modello Thin-Client non riduce il fabbisogno di risorse di calcolo: queste vengono solo spostate dal PC desktop al Server;
2. Per applicazioni identiche, la migrazione dal modello Fat-Client al modello Thin-Client non riduce il fabbisogno di banda disponibile: al contrario questo viene spostato dalla infrastruttura LAN/WAN alla Intranet/Internet;
3. Per applicazioni identiche, le unità di calcolo necessarie per servire x utenti sono identiche sia per il modello Thin che per quello Fat;
4. Per applicazioni identiche, la migrazione dal modello Fat-Client al modello Thin-Client non riduce il costo dell’applicazione e, anzi, molto spesso lo aumenterà.

Nessuna riduzione nelle risorse di calcolo necessarie.

Una applicazione Fat-Client utilizza le risorse di calcolo e la potenza messa a disposizione dal desktop pc e dalla banda disponibile per la LAN. In un tipico modello Fat-Client, quasi tutto il carico di lavoro viene eseguito dal pc desktop.
Per esempio, in una applicazione Fat-Client che serva 500 utenti, quasi il 90% delle risorse di calcolo sono impegnate dai pc che, in modo asincrono eseguono l’applicazione, mentre solo il rimanente 10% viene impegnato dal server.

Il deployment di una applicazione Fat-Client generalmente comporta l’utilizzazione dei PC già esistenti nella struttura ed un server (database/application) relativamente piccolo. Solo qualora il numero di client dovesse aumentare significativamente, potrebbe essere necessario ampliare il database server.

Quando si migra da un modello Fat ad uno Thin-Client, le necessarie risorse di calcolo non spariscono per magìa: deve essere comunque disponibile la medesima capacità di calcolo. Ma siccome non si sta più utilizzando la potenza di calcolo offerta dal Pc è necessario dotare il server applicativo di quella potenza extra dovuta al numero di unità di processo che sono state spostate dal client al server. In altre parole il nuovo server deve essere in grado di svolgere anche le attività che svolgevano i singoli pc.

In conclusione la modifica del modello non comporta nessuna ottimizzazione delle risorse a parità di applicazione: si tratta solo di modificarne la distribuzione caricando di più i server nel modello Thin-Client.

Nessuna riduzione delle risorse di banda

E’ opinione tanto diffusa quanto errata che la migrazione ad un modello Thin-Client possa portare dei benefici in termini di risparmio su costose strutture di comunicazione. La realtà e molto diversa e per rendersene conto basta provare ad accedere ad un applicazione server web durante un momento di picco oppure parlare con un ISP su quali siano i costi da sostenere per ospitare un servizio applicativo in modo affidabile.

Una efficace soluzione Thin-Client richiede ingenti costi in infrastrutture: a partire dai server, dagli switch, dai router fino a considerare i costi elevatissimi di una Intranet geografica.

La potenza di calcolo complessiva non cambia.

Per applicazioni identiche ci vogliono sempre e comunque x unità di processo per servire un singolo utente sia nel caso di un Fat-Client che nel caso di un Thin-Client. Ma mentre nel primo caso è il PC che svolge la maggior parte del lavoro, nel secondo caso lo stesso lavoro viene ricaricato sul server.

La migrazione da un modello Fat-Client ad un modello Thin-Client sicuramente aumenterà i costi complessivi dell’applicazione.

Se immaginiamo di migrare 500 utenti da un modello Fat ad uno Thin la prima cosa che salta all’occhio è il fatto che, di certo, non si smonta la ram in eccesso dai PC per montarla sui server e non si può rimandare indietro mezza CPU per chiedere un rimborso. Non vi è nessun beneficio immediato in termini di risparmio economico che potrà avvenire se, e solo se, i prossimi pc verranno acquistati con caratteristiche di capacità di calcolo molto ridotte.

Se il modello Fat comporta l’installazione del codice dell’applicazione su ogni macchina si potrebbero ridurre i costi di manutenzione del software client adottando un modello Thin-Client, ma se, come dovrebbe essere, il codice viene distribuito mediante idonei application server, allora i risparmi offerti da un modello Thin sarebbero veramente minimi.
In realtà, in ogni caso, i risparmi sarebbero minimi comunque dato che la maggior parte delle risorse di manutenzione viene impiegata per il buon funzionamento della rete, delle applicazioni desktop come Microsoft Office, Outlook, Autocad ecc. e quindi fondamentalmente il numero di risorse uomo allocate per queste attività non cambia.

Perchè il costo di un’applicazione Thin client è di molto superiore ad una equivalente ma basata su Fat client ?

Dalla lettura delle prime quattro regole esposte all’inizio appare evidente come i principali problemi siano :

• Replicare la potenza di calcolo di un pc per ogni utente on-line
• Il costo incrementale di ogni utente aggiuntivo

Quando si aggiungono utenti ad una applicazione Fat, il 90% del carico di lavoro viene assolto dal Pc mentre l’aumento di carico di lavoro del server è marginale. Al contrario, in un modello Thin-Client, per ogni utente aggiunto da servire, il server dovrà fornire la maggior parte delle risorse di calcolo necessarie per la nuova sessione e, in assenza, tutti gli altri sperimenteranno un degrado generalizzato delle performance.

In una applicazione Fat la potenza di calcolo è decentralizzata al contrario di quanto avviene nel modello Thin che, per naturale conseguenza, a parità di hardware, raggiungerà molto prima il limite critico di utenti servibili.

Quindi perchè è sempre più alto il numero delle applicazioni Thin Client ?

Molte aziende adottano questo modello seguendo alcune linee guida

1. Riduzione dell’impegno totale di risorse disponibili per la WAN : purtroppo, come abbiamo visto questo non è assolutamente vero.
2. Riduzione dei costi di manutenzione dei singoli PC : vero in minima parte. Se si considera che i pc vanno comunque tenuti in buono stato anche solo per il loro sistema operativo e le applicazioni tipicamente desktop come Office allora il costo marginale dovuto alla manutenzione di una singola applicazione è praticamente azzerato.
3. Maggior controllo sull’applicazione: il gestore di una applicazione Thin ha sicuramente dei vantaggi nell’adozione di questo modello in termini di rapidità e facilità nel deployment di nuove release. Per converso si deve anche sobbarcare l’onere di gestire una struttura server più complessa.
4. Migliorare i tempi di risposta dell’applicazione : le risorse di banda e di calcolo non cambiano nei due modelli. Il problema non viene risolto adottando un modello piuttosto che un altro: semplicemente si spostano da un estremo all’altro.
5. Utilizzare le più recenti tecnologie hardware e software: è in dubbio che gli sviluppatori cercheranno di utilizzare al meglio sempre le migliori tecnologie disponibili che li aiuteranno in un più rapido sviluppo. Ed è indubbio che sia molto più realistico aggiornare i server di rete piuttosto che l’intero parco PC Client.
6. Risparmiare : è molto improbabile, direi impossibile, che si possa risparmiare denaro implementando la migrazione di una applicazione da modello Fat a Thin.

Tutto quanto sopra poi non sfugge ad una regola che impera sovrana nel mondo IT : il trend della moda. Fino a solo un paio d’anni fa lo sviluppo di applicazioni di Thin-Client era considerato il non plus ultra della modernità per raggiungere in modo uguale utenze disomogenee per quanto riguarda gli apparati e i sistemi operativi (un’applicazione Web funzionerà verosimilmente allo stesso modo sia con Windows che con Linux). Tuttavia l’evoluzione ha negato se stessa: l’avvento in massa degli smart-phone e dei piccoli PDA, a bordo dei quali il browser è molto poco efficiente, ha messo in gioco un terzo modello, il Tick-Client, che sfrutta al meglio le risorse di calcolo offerte dall’hardware presso cui è ospitato e rimanda al modello web solo per quanto riguarda l’effettiva trasmissione dei dati.

Non va sottovalutato anche un fatto essenziale : quasi tutte le applicazioni Thin-Client si basano sul paradigma web/http che, come noto, è un protocollo di comunicazione privo di congnizione di stato. Ne consegue che le applicazioni Thin, per quanto concerne il loro lato server, sono molto più onerose delle omologhe applicazioni basate su Fat-Client in quanto ad ogni richiesta di sessione devono ricostruire lo stato originario. Non ultima la sempre maggiormente estremizzata ricerca di far assomigliare le interfacce Thin a delle vere e proprie interfacce Fat iniettando nel codice HTML sempre più pesanti informazioni grafiche, codice di scripting ecc. che ha come effetto indesiderato quello di aumentare notevolmente la richiesta di banda.

Insomma … pensare che una nuova applicazione possa avere come unica soluzione quella di essere sviluppata necessariamente come Thin-Client può essere un grave errore.

Oggi è mancato Pineto Gelmini.

Non ho avuto occasione di frequentarlo molto, ma non posso fare a meno di ricordarlo e ringraziarlo per quel mio battesimo del volo che mi ha aperto a un mondo nuovo.
A volte il suo vocione un po’ sgraziato e la sua presenza ingombrante stridevano un poco con i nostri silenziosi alianti : ma era un uomo buono, che a suo modo ha condotto battaglie grandi e piccole … fino a quest’ultima che ha avuto la meglio su di lui.

Ciao Pineto … e grazie per i tanti traini in cielo. Ora ne avrai uno tutto per te … che ti porterà più in alto di quanto mai tu abbia potuto con un aeroplano.

>> La soluzione anticipata è arrivata : Client EPP per Registrar <<

Ormai siamo vicini … il prossimo 31.12.2010 tutti i Mantainer di domini .it , o saranno passati alla nuova modalità sincrona di interazione con il NIC (quindi diventando Registrar) oppure perderanno la loro qualifica di Mantainer e i domini ad esso associati dovranno essere passati in gestione a qualcuno che Registrar lo è già.

A guardarla superficialmente parrebbe solo una innovazione tecnologica da affrontare sotto il profilo, appunto, tecnico. Finalmente si potrà gestire la registrazione di domini in tempo (quasi) reale, come già avviene per quasi tutti gli altri TLD, senza il fastidioso andirivieni di fax e lettere (spesso rigettati perchè illegibili) con il CNR di Pisa.
Ma è davvero solo questo ? In realtà le cose sono un pochino più complicate.
La figura del Mantainer sparisce: ovvero sparisce quell’entità che funzionava come “custode/manutentore” del nome a dominio in virtù di un incarico assegnatogli congiuntamente dal Registrant (ovvero il titolare del dominio) e dal NIC. In pratica il Mantainer assolveva ad un compito totalmente passivo, sbrigando solo le pratiche “tecniche” per l’avviamento iniziale del dominio e la sua manutenzione. Il Mantainer non poteva dare l’avvio ad una procedura di registrazione: doveva essere sempre e comunque il titolare del dominio ad inviare una lettera (o un fax) al NIC con la richiesta di registrazione e l’indicazione del Mantainer scelto: successivamente, passati i controlli formali, il NIC inviava una richiesta al Mantainer per l’invio dei moduli elettronici di configurazione.

Ora le cose cambiano. La nuova figura del Registrar (notare la vicinanza con Registrant) è una figura attiva nel processo di registrazione e manutenzione del dominio. Il nuovo soggetto riceve in delega temporanea alcune delle prerogative che fino a ieri erano appannaggio esclusivo del NIC: intrattiene un rapporto diretto con il proprio cliente Registrante, attiva presso il NIC le procedure di registrazione e manutenzione dei domini ed interagisce direttamente con gli archivi dati del NIC tramite un sistema di comunicazione sincrona basato su protocollo EPP. E’ dunque la fine delle LAR (Lettere Assunzione Responsabilità) inviate via Fax ? Proprio NO.

E già … perchè come in tutte le cose … nuovi onori (vantaggi) si pagano con nuovi oneri. E l’onere più grosso è che ora i Registrar hanno ricevuto in delega anche il compito di mantenere correttamente e ordinatamente tutta la documentazione cartacea ed elettronica che giustifichi la registrazione di un nome a dominio. E quando si parla di documentazione cartacea … ovviamente si fa riferimento anche alla LAR che il cliente non invierà più al NIC ma al Registrar.

Dal punto di vista dell’utente finale questa è certamente una semplificazione : un solo soggetto con cui interloquire per la registrazione di sto benedetto dominio. Ma per il Registrar è una complicazione in più quella di dover organizzare idonei archivi che potranno essere soggetti a verifica da parte del NIC.

Fin qui … la parte filosofica.

Ma per la parte pratica cosa bisogna fare ? Come posso diventare Registrar ?
Oltre ad aver compreso molto bene le implicazioni di cui ho detto sopra, è necessario attrezzarsi tecnologicamente per poter diventare Registrar: bisogna cioè disporre degli strumenti che implementano il protocollo EPP (Extensible Provisioning Protocol) adottato dal NIC per le comunicazioni con i Registrar. In pratica bisogna imparare a parlare la loro lingua. E da qui le domande immediatamente successive …

Posso imparare EPP da solo per poi parlarlo ?
Certamente … come tutte le cose del mondo IT. Basta volerlo ed avere il tempo e le risorse per farlo. I criteri di definizione del protocollo sono fissati in esaustivi documenti RFC ed il NIC mette a disposizione gratuitamente: un documento di Linee Guida sull’implementazione del protocollo (con numerosi esempi) e un client EPP scritto in JAVA (in)utilizzabile da subito, via riga di comando, per mandare sequenze di comandi  (documentato anche un po’ ad-cazzum). Stop. Non c’è altro …

Ci sarà pure da qualche parte un programma open source che implementi il protocollo EPP già bello pronto così lo scarico e inizio a fare il Registrar.
In realtà qualcosa c’è, anche se non molto. Ma ci sono due fattori da considerare: l’implementazione ITALICA del protocollo EPP differisce leggermente dagli standard RFC quindi scartate subito tutti i client EPP che non siano stati espressamente progettati per dialogare con il NIC. A questo punto vi rimangono solo due/tre implementazioni libere/free/open-source/aggratis-da-scaricare che francamente vi sconsiglio a meno che non abbiate interessi puramente accademici sui principi del loro funzionamento. Dal momento che li considero poco più che hobbistiche esercitazioni di stile, non li citerò per non incorrere nelle ire dei rispettivi sviluppatori.

Soluzioni a pagamento ?
Qui la scelta si amplia un pochino … ma si complica pure. Ho trovato una sola soluzione per un desktop client sviluppato da una azienda il cui nome è simile “UAU” ma scritto in inglese che per modici 40 euro/anno offre il suo pacchettino per windows dall’interfaccia molto approssimativa e senza alcun tipo di trascodifica o controllo: in altre parole, codici, significati e regole di convalida dei campi li dovete conoscere. Ma la cosa più fastidiosa è che per far funzionare questo client … è necessario che il LORO (quello della UAU) server sia attivo e vi mandi i costrutti XML da inviare al NIC. In pratica … io faccio qualcosa con il programma, il loro programma completa questo qualcosa con i dati che richiede al loro server, infine il programma mette insieme il tutto e manda il messaggio al NIC. Un menage a trois. E se il loro server non funziona per qualsiasi motivo ? Magari è in manutenzione proprio mentre il mio cliente è in gara contro il tempo per registrare un nuovo dominio. Che faccio ? Gli dico di aspettare ? Bahhhhh. Certo … pagando di più potrete avere una soluzione che dicono essere stand-alone … ma per quello che ho visto meglio soprassedere.

Le altre soluzioni del parco sono quasi tutte hosted. Ovvero … pagando un canone di abbonamento accedete ad una piattaforma web (sviluppata e manutenuta da altri) che vi permette di gestire le vostre comunicazioni EPP. Anche qui ci sono dei problemi però : il contratto tra il Nic ed il Registrar è un contratto a due che comporta una serie di informazioni confidenziali prime su tutte le password di accesso al sistema che permettono la gestione dei VOSTRI dati. Adottando queste piattaforme “in affitto” consegnate a terzi queste chiavi perchè sarà il loro sistema che dialogherà in nome e per vostro conto. Se vi sentite sicuri … questa è una strada da percorrere. Ma ricordate sempre che quando vi affidate ad un servizio terzo, se per qualsiasi motivo questo non funziona, i registrar che invece hanno rapporti diretti con il NIC saranno sempre attivi.

Altre idee ?
C’è sempre la possibilità di non diventare registrar e di affidarsi a servizi che facciano il registrar per voi. Si tratta pur sempre di servizi a pagamento ma in questo caso non intrattenete nessun rapporto con il NIC e la sicurezza dei vostri dati è garantita dal rapporto con il vostro fornitore. Per contro, non avendo un rapporto con il NIC, pagherete i domini un poco di più e non avrete la vostra sigla registrar nel whois dei domini dei vostri clienti.

Quindi ?

Quindi … aspettate ancora qualche giorno e … tra poco la soluzione sarà nelle vostre mani.