Ogni applicazione compie in fondo tre azioni principali: leggere dei dati, elaborarli, restituirli.
Se vogliamo che la nostra applicazione sia esportabile, ad esempio tramite Internet, dobbiamo assicurarci che ognuna delle tre azioni principali sia eseguibile su macchine di molti tipi diversi.
Per la parte di elaborazione molto è già stato fatto ai fini dell'esportabilità: Java e script in diversi linguaggi permettono di eseguire un'applicazione su qualsiasi sistema dotato rispettivamente di una Java Virtual Machine (JVM) e di un browser recente.
Meno evoluto è invece il livello di esportabilità dei dati. Di solito la lettura e la scrittura avvengono da e verso un data-base (DB), che registra i dati in un formato proprietario, in genere binario. Una applicazione esportabile dovrebbe quindi in teoria essere prodotta in tante versioni, una per ognuno dei DB più diffusi. In genere invece le soluzioni adottate sono di due tipi:
- se l'applicazione è destinata ad essere eseguita su di un determinato tipo di macchina, il formato di input e di output sarà fisso e toccherà all'utente fornirsi o del tipo di DB consigliato dal produttore o di un traduttore di dati, spesso a spese proprie;
- se invece l'applicazione è destinata a correre su Internet, la parte eseguita sul server utilizzerà il proprio DB, mentre la parte eseguita sul browser o sulla JVM del client dovrà fornire e ricevere dati on-line, in un lungo e dispersivo colloquio composto di tanti passaggi del tipo: modulo inviato - elaborazione - pagina html di risposta. Questa serie di scambi può essere frustrante, come tutti possiamo sperimentare quando ci connettiamo ad un sito congestionato.
Come aumentare l'esportabilità delle azioni di lettura/scrittura dati? Sarebbe ideale che ogni applicazione parlasse una sorta di "esperanto dei DB", cioè un linguaggio unico e semplice da tradurre da e verso altri formati proprietari. XML si candida seriamente ad essere questo esperanto e lo sta progressivamente diventando, grazie a degli indubbi punti di forza:
- XML si basa su testo ASCII, un formato diffuso da moltissimi anni in modo praticamente ubiquitario;
- XML è compattissimo, perchè si limita ad essere un contenitore di dati, senza le aggiunte legate all'elaborazione tipiche dei formati dei DB proprietari;
- XML è comunque leggibile e comprensibile direttamente dall'uomo; scrivere un piccolo DB XML a mano è un lavoro abbastanza facile.
Nei paragrafi che seguono descriveremo come utilizzare tutte le tecniche descritte per creare applicazioni pienamente esportabili. Riassumendo:
- la parte eseguibile sarà in Javascript;
- i dati letti e scritti saranno in formato XML.
Il pacchetto formato da Javascript + XML può viaggiare tranquillamente in Internet, come mostrato nella seguente figura:
E se invece non avessimo l'urgenza di esportare la nostra applicazione? Esistono comunque diversi motivi per cui la coppia Javascript + XML può esserci utile:
- i linguaggi di scripting sono in genere più facili da imparare ed usare e possono essere sufficienti per creare dei primi esempi funzionanti;
- uno script può comunque richiamare al suo interno codice più potente (come Applet Java o ActiveX);
- il codice è già pronto per essere esportato su un'altra macchina, un altro DB o per passare in Internet.