La verità su .NET

Il 13 febbraio 2002 Microsoft ha dato una bella lucidata agli ottoni della sua fanfara per presentare la sua “soluzione .NET”. La casa di Bill Gates è riuscita molto bene nell’attività che i pubblicitari chiamano “branding”, e cioè far sapere che il nuovo prodotto esiste; ma ben pochi hanno capito di cosa si tratti.
Per saperne di più, cominciamo con il nome. Si pronuncia “dot net” e sottintende che tutti i prodotti Microsoft dell’ultima generazione si integrano con Internet. Microsoft ha deciso di aderire allo standard XML per l’interscambio di informazioni e farà in modo che tutti i suoi programmi (prima o poi) sino in grado di importare ed esportare documenti in XML. Ma XML può venire usato dal software per far transitare non solo dati ma anche domande e risposte. Per esempio, oggi chi vuole cercare il numero di telefono di una qualche lavanderia può certamente consultare il sito web delle paginegialle usando un PC: immaginate invece di star usando una agendina elettronica nella quale avete memorizzato il nome della lavanderia. L’agendina potrebbe attivare il vostro telefono cellulare, contattare il calcolatore che da vita a quel sito web, compilare una richiesta XML per il numero, ottenerlo e inserirlo nella sua memoria. Questa forma di servizio non sarà limitato agli utenti di Windows: XML è uno standard aperto anche a Macintosh e Unix, quindi una ottima opportunità per estendere l’utilità e l’interattività della Rete.
Più controversa l’idea chiamata “.NET My Services”: Microsoft vorrebbe creare una batteria completa di servizi XML, ospitarli sui suoi server e far pagare un abbonamento ai suoi utenti per il privilegio di utilizzarla. Taluni critici equiparano questa idea addirittura al Grande Fratello orwelliano: Microsoft in effetti intende registrare all’interno dei suoi server anche i dati più riservati dei suoi clienti, come informazioni riguardanti la privacy individuale o numeri di carta di credito. Pare innegabile che l’architettura “.NET My Services” sia tecnicamente criticabile. Un fanoso esperto americano di sicurezza, Bruce Schneier, edita un bollettino molto quotato nel settore chiamato “Cryptogram”. Nell’editoriale del numero di febbraio Schneier ha avuto parole molto dure, scrivendo addirittura: Microsoft dovrà dichiarare che l’intera iniziativa [.NET My Services] va bloccata, probabilmente per anni, mentre rivedono tutti i problemi di sicurezza. Dovrebbero fermare lo sviluppo delle funzionalità e controllare il codice esistente, riga per riga, eliminando le vulnerabilità, disabilitando le funzionalità insicure e aggiungendo caratteristiche di sicurezza.
D’altra parte questo problema pur scottante sta facendo perdere di vista ai critici i molti aspetti positivi, addirittura brillanti, dell’iniziativa. Per esempio -- sotto la bandiera .NET -- Microsoft sta rivedendo tutte le fondamenta del sistema operativo Windows per svecchiarle e renderle più stabili. L’ultima vera innovazione in questo campo era avvenuta con l’introduzione di Windows 95 e le sue cosiddette “API a 32 bit”, il protocollo che tutte le odierne applicazioni per PC usano per parlare al sistema operativo e fare richieste (come “disegna una nuova finestra” o “collegati a Internet”). Ma le API Win32 hanno numerosi difetti architetturali conosciuti, e Microsoft pone rimedio con le API .NET. Tanto per cominciare, sotto Win32 le applicazioni fanno affidamento sul concetto di librerie, blocchi di codice condiviso. Ma la condivisione rende il sistema fragile. Per esempio, il programma di posta elettronica Eudora usa le librerie di Internet Explorer per mostrare a video i messaggi di posta in formato HTML. Ma quando Microsoft aggiorna Explorer gli utenti rischiano di trovarsi con un PC instabile perché il vecchio Eudora si trova a usare una nuova librereria e l’accoppiata mai testata va incontro ad effetti collaterali imprevisti. Nelle API .NET le librerie vengono rimpiazzate con assemblaggi, componenti privati e non condivisi. Aumenta lo spazio richiesto in memoria e su disco, ma la stabilità cresce.
C’è un’altra importantissima novità. Oggi le API Win32 funzionano solo quando un programma viene compilato, (cioè realizzato in forma eseguibile), per l’uso su un PC sotto processore Intel Pentium. Le API .NET invece sono fatte per venire richiamate da un “linguaggio intermedio”chiamato MSIL (Microsoft intermediate language). I nuovi programmi quindi potranno girare sui PC che usano il sistema operativo Windows XP, (che è in grado di eseguire lo MSIL), ma in futuro e in forma invariata potranno funzionare anche su calcolatori palmari o grandi elaboratori, anche se questi dispositivi usano processori diversi dal Pentium. Microsoft si libera così dal giogo dei processori Intel, che negli ultimi anni sono cresciuti vertiginosamente in frequenza (cioè in megahertz) ma non tanto in velocità operativa, e che consumano troppa energia per l’uso in dispositivi portatili (per un confronto, si pensi che un PC portatile nuovo può funzionare con alimentazione a batteria per un massimo di due ore, mentre alcuni Macintosh arrivano a ben sei ore di utilizzo). A Intel la notizia non fa dispiacere, perché i dirigenti della società conoscono da anni i limiti architetturali dei loro processori più venduti e vedrebbero volentieri la transizione del mercato su modelli alternativi come l’Intel Itanium.
Microsoft è nota tra i suoi detrattori per l’abilità di imporre sul mercato prodotti mediocri e tra i suoi estimatori per l’abilità di arrivare col prodotto giusto nel momento giusto; con .NET una delle due caratteristiche probabilmente verrà a mancare: resta da vedere quale.