|
Introduzione
Uno dei problemi che ha sempre afflitto la tecnologia
XML, ma che nello stesso tempo è uno dei
suoi maggiori punti di forza è l'utilizzo
di dati testuali per rappresentare le informazioni.
Grazie a questa caratteristica, l'osservatore
umano che vuole conoscere i dati presenti in un
documento XML, oppure in un messaggio di un Web
Service, è in grado di capire il contenuto
semplicemente osservando i dati XML. Ma questa
leggibilità è offerta ad un costo.
Riassumiamo gli svantaggi dell'utilizzo di XML
in generale e dei Web Services in particolare:
- parsing.
Un documento XML deve essere elaborato per poterne
utilizzare i dati. Sebbene tecnologie come SAX
e StAX siano molto efficienti, questa operazione
richiede una quantità anche minima di
potenza di elaborazione. Per contro i protocolli
binari sono più vicini alla rappresentazione
in memoria dei dati, quindi richiedono meno
elaborazioni per il loro utilizzo;
- memoria.
Un altro problema della tecnologia XML, che
si palesa soprattutto nell'archiviazione e trasmissione
dei dati, è la richiesta di memoria.
Un dato formattato in XML richiede più
spazio rispetto al corrispondente dato codificato
con uno standard binario. Questo maggiore overhead
si traduce in una maggiore durata della trasmissione
di dati XML, ad esempio relativi ad un messaggio
SOAP.
La
soluzione di SUN
Nel passato ci sono stati una serie di tentativi
di realizzare una codifica binaria di dati XML,
allo scopo di ottenere il meglio di entrambi i
mondi, soprattutto nell'utilizzo con i Web Service:
la leggibilità del formato XML con l'occupazione
di memoria di un dato binario. Si è cercato
dunque di combinare questi due approcci, per certi
versi diametralmente opposti, in una unica tecnologia.
Ma il problema di far convivere questi due mondi
così diversi ha richiesto un po' di tempo
prima di portare ad una soluzione soddisfacente.
Per SUN questa si chiama Fast Web Services, ed
è una tecnologia in fase di standardizzazione
da parte di ISO. Qual è il concetto chiave?
Con i Fast Web Services vengono trasmessi solo
i dati, presupponendo che in entrambi gli endpoint
siano presenti gli schemi XML necessari a decodificare
le informazioni trasferite. Risparmiando le informazioni
di formattazione, i dati trasmessi sono in numero
inferiore, e quindi l'overhead viene ridotto.
La decodifica viene assicurata dal fatto che i
metadati descrittivi delle informazioni sono disponibili
all'endpoint che riceve i dati. Per capirci, il
concetto è simile alla vecchia gestione
dei file a record che si faceva in C, BASIC o
Pascal. Si definisce prima un tipo di record:
struct
Record {
int id;
char[10] descr;
long timestamp;
char deleted;
}
e
poi si scrive su un flusso direttamente una variabile
con la struttura utilizzata. I dati scritti nel
flusso sono binari, come sapere dunque che i primi
due byte sono relativi ad un unico dato intero,
mentre l'ultimo byte è in realtà
un flag di cancellazione? L'unico modo per saperlo
è avere il codice sorgente della struttura
dati. Questo aspetto può sembrare estraneo
allo sviluppatore Java: serializzando una classe
infatti vengono trasferiti anche tutti i metadati
associati. Un modo per ovviare ai molti problemi
della classica gestione di file a record. Ad ogni
modo, questo è il concetto chiave dell'approccio
dei Fast Web Services.
All'interno
di Fast Infoset
Per molte applicazioni, però, la necessità
dei metadati è imprescindibile. D'altra
parte è uno dei vantaggi di XML è
proprio questo. Non c'è dunque da sorprendersi
se gli ingegneri di SUN abbiano dovuto tornare
al tavolo di lavoro per proporre una soluzione
che salvasse capra e cavolo.
Con Fast Infoset, SUN propone una soluzione che
può essere immaginata come una semplice
complessione GZIP di documenti XML. Con questo
approccio l'unica informazione indispensabile
per leggere i dati è sapere che il documento
è codificato: in questo caso il client
esegue una decompressione, al fine di ottenere
il dato non compresso.
La compressione non è però una standard
GZIP o JAR, ma una soluzione ottimizzata per dati
XML, che produce migliori risultati in termini
di tempo di codifica e di decodifica. È
una sorta di algoritmo di compressione studiato
specificatamente per la tecnologia XML. Ad esempio,
si potrebbe utilizzare il noto algoritmo LZH per
comprimere dati XML, ed il risultato sarebbe un
file più piccolo di quello prodotto con
Fast Infoset, ma i tempi di codifica e decodifica
sarebbero risultati maggiori. In altre parole,
si sarebbero appensantiti significativamente l'elaborazione
negli endpoint in modo da ledere alle performance
lato server.
Le caratteristiche principali della compressione
Fast Infoset sono:
-
mancanza di tag di terminazione, p.e. </element>.
Questo permette di risparmiare spazio;
- nessun
escaping dei caratteri, che permette di eseguire
meno operazioni di elaborazione ed occupare
meno spazio;
- indicazione
della dimensione nel prefisso. In questo modo
l'allocazione di memoria è precisa a
priori e permette a chi riceve eventualmente
di rimbalzare il messaggio se questo dovesse
essere considerato troppo lungo;
- indicizzazione
stringhe, che sostituisce stringhe che si ripetono
spesso, con interi, che occupano meno memoria;
-
indicizzazione dei nomi qualificati (namespace);
- inserimento
diretto di dati binari. Invece che utilizzare
la codifica Base64 per convertire dati binari
in testuali (con un'occupazione di circa il
doppio della memoria), i dati binari vengono
inseriti direttamente nel documento XML compresso;
- preservazione
dello stato di documenti con vocabolario similare.
In questo modo è possibile conservare
un vocabolario comune di stringhe indicizzate
attraverso diverse elaborazioni.
Il
cuore della tecnologia Fast Infoset è quindi
la compressione basata sulla sostituzione di stringhe.
È un interessante ritorno al passato: questo
algoritmo è forse uno delle prime e banali
tecniche di compressione che si studiano a scuola.
Gli ingegneri SUN hanno rilevato che questa soluzione
funziona bene con XML. Per chi non ricorda o non
conosce la compressione basata su sostituzione
di stringhe, ecco un esempio. Se il dato da comprimere
è il seguente:
<root>
<tag>one</tag>
<tag>two</tag>
<anotherTag>one</anotherTag>
</root>
con
la compressione Fast Infoset si ottiene quanto
segue:
{0}<root>
{1}<tag>{0}one</tag>
[1]<>{1}two</tag>
{2}<anotherTag>[0]</anotherTag>
</root>
gli
elementi cancellati non sono richiesti, dunque
il file risultante è da considerarsi senza
i tag di chiusura. Con l'utilizzo di identificatori
{} viene marcato un elemento di testo che si ripeterà;
con [] una occorrenza di quell'elemento. L'intero
contenuto nelle parentesi è l'identificativo
univoco.
Il
progetto FI
Per chi desidera sperimentare con questa nuova
ed interessante tecnlogia, SUN ha creato un progetto
open source all'interno di java.net, il Fast Infoset
Project, https://fi.dev.java.net/, come mezzo
di promozione della tecnologia sia all'interno
del mondo Java che verso l'esterno. D'altra parte,
se questo nuovo formato non diviene interoperabile,
la sua utilità si riduce notevolmente.
Un Web Service che lo utilizzi sarebbe accessibile
infatti solo a client Java che implementano Fast
Infoset, escludendo di fatto implementazioni open
source, datate o la piattaforma .NET.
Attualmente è presente l'implementazione
parziale delle specifiche Infoset con le API SAX
e StAX ed anche qualche benchmark a detta di SUN
incoraggiante (si parla di aumenti di velocità
di 3/4 volte e di un aumento del 50% in un benchmark
interno di SUN utilizzato per JAX-RPC). Ad un
certo punto Fast Infoset verrà integrato
in JAX-RPC.
Conclusioni
SUN inserisce una nuova parola chiave nelle tecnologie
XML e dei Web Services: Fast. I progetti Fast
Infoset e Fast Web Services vogliono portare una
codifica binaria per dati XML e messaggi SOAP
per ovviare ad uno dei problemi principali della
tecnologia XML: l'occupazione di memoria. L'approccio
di Fast Infoset si basa su un algoritmo di compressione
vecchio come il mondo: la sostituzione di stringhe.
Si ritiene infatti che venisse addirittura utilizzato
dagli egizi per ridurre il numero di geroglifici
incisi sui monumenti lapidari e prima finanche
dai sumeri nelle loro tavolette di argilla (era
solo una battuta :-).
Ad ogni modo, l'algoritmo è stato ottimizzato
per i dati XML ed i primi test dicono che i risultati
sono buoni, ma fino a che gli altri (leggi Microsoft
e .NET) non lo supporteranno, non sarà
possibile utilizzare veramente questa tecnologia
per i Web Services interoperabili.
Bibliografia
[1] Eduardo Pelegri Llopart - "Simple, fast,
no-loss binary XML - Fast Infoset", http://weblogs.java.net/blog/pelegri/archive/2004/06/simple_fast_nol.html
[2] Eduardo Pelegri Llopart - "The FI Project
- An open source implementation of a binary XML
standard", http://weblogs.java.net/blog/pelegri/archive/2005/01/start_using_bin.html
[3] Sandoz, Triglia, Pericas-Geertsen - "Fast
Infoset", http://java.sun.com/developer/technicalArticles/xml/fastinfoset/
Massimiliano
Bigatti é autore dei libri "Java
e Multimedia", "Da Visual Basic a Java",
"Da Visual Basic a C#" e "Java
Web Application". E' certificato, tra le
altre, come SUN Certified Enterprise Architect
for Java Platform, Enterprise Edition Technology.
E' content editor del portale dedicato ai Web
Services http://javawebservices.it
|
