Uso di XML e SVG per l'accesso via Web ai dati di Cms

Introduzione

Abbiamo sviluppato una speciale rappresentazione 2D del tracker(la "mappa del tracker"). Questa non e' un'immagine statica ma va considerata come un'interfaccia utente ad alto livello per l'accesso di dati rilevanti per il monitoraggio online del tracker. Questa mappa dovrebbe funzionare non solo sul cluster dell'online (filter farm) o sui computer con software CMS ma su qualsiasi computer collegato a Internet. Possibilmente in un normale Web browser. Il problema e' analogo a quello affrontato e risolto da Google Maps. Google ha acquistato una societa' (la Keyhole) che ha un enorme database con mappe dettagliate di tutti gli Stati Uniti e inoltre immagini via satellite e deve renderli disponibili ai suoi utenti possibilmente senza usare speciali programmi da scaricare sul loro computer. Nel nostro caso abbiamo tutti i dati relativi al tracker CMS.

Il nostro problema e' duplice:

  1. Come accedere dal Web a tutti i dati del tracker
  2. Come rappresentarli nel browser senza usare speciali programmi.

Accesso Web ai dati di Cms

Prima di vedere come procedere e' necessario chiarire cosa si intende per "Applicazione Web" e per "interfaccia Web standard". Un'applicazione Web e' un'applicazione desktop che gira su un qualsiasi computer collegato a Internet senza richiedere l'installazione di software particolari.Essa prevede quindi un cliente "leggero" (ad es un programma Java o semplicemente un browser) che usa un'interfaccia (un vero e proprio Web Api) per collegarsi a uno o piu' server che forniscono i dati o il servizio richiesto.

Questa Web Api al momento attuale e' definita usando un'estensione del vecchio protocollo CGI. Mentre prima si inviava la richiesta con un URL con eventuale accompagnamento di file di testo e si riceveva indietro il risultato sotto forma di pagina Web in HTML, adesso si invia un URL con eventuale file XML di accompagnamento e si riceve la risposta con un file XML. Il grande miglioramento e':

In gergo tutta la serie di protocolli che assicurano il funzionamento di queste applicazioni Web , sono chiamati Web Services e sono a loro volta la base dei Grid services. La differenza tra un Grid e un Web service, e' che il Grid service si preoccupa anche di "questioni amministrative" come sicurezza, gestione di transazioni, autenticazione dell'utente,etc.

Ora possiamo vedere come procedere considerando la particolare applicazione Web relativa al monitoraggio del tracker di CMS. Questa applicazione ha bisogno di accedere alle seguenti sorgenti di dati:

Inutile dire che l'accesso a ognuno di questi necessita un diverso API e non e' definita nessuna interfaccia standard. Questa applicazione implementa la stessa "mappa del tracker" disponibile con l'applicazione desktop "IGUANACMS" e puo' essere usata per: Il trucco usato puo' essere visto nel grafico dell'architettura del sistema. Il cliente Java (o il broser Web)invece di collegarsi direttamente alla sorgente dei dati, si collega a un server che fa da gateway con la sorgente dei dati e coi computer dove gira il software di Cms. Questo server comunica attraverso un'interfaccia web standard col client Java (in pratica noi abbiamo definito il formato xml dei dati cms) Questi stessi server possono inviare i dati sia in xml al programma Java, ma anche trasformati direttamente nel formato grafico SVG. In questo caso il client non e' piu' il programma Java ma direttamente il server Web con il plugin di Adobe. Perche' tutto questo funzioni dobbiamo quindi:
  1. Creare un data server per ogni sorgente di dati.
  2. Definire un URL per ogni pezzo di dati che ci puo' interessare.

Perche' SVG

SVG (Scalable Vector Graphics) e' una specifica W3C che sta diventando a poco a poco una maniera standard per rappresentazioni grafiche 2D sul Web per qualsiasi tipo di informazione. Esso e' gia' usato nella fisica delle alte energie (ma anche fuori di essa) come una maniera standard di salvare immagini di grafica vettoriale 2D(ad esempio ROOT permette di salvare istogrammi nel formato SVG). In questo uso potrebbe rimpiazzare postscript in quanto puo' rappresentare ogni tipo di grafica vettoriale(forme,testi con la possibilita' di includere anche immagini bitmap). E' possibile comprimere il file SVG (un file di testo) ottenendo dei file piu' compatti dei files postscript. (SVG puo' anche in teoria sostituire completamente ,rendendoli obsoleti, sia Flash che Powerpoint).

In particolare usando SVG , e' possibile rappresentare dati statistici su mappe geografiche. La qualita' di queste mappe rivaleggia con quella delle mappe su carta.Inoltre il plugin permette di fare operazioni tipo zooming e scorrimento. Ulteriore interattivita' puo' essere ottenuta mandando assieme alla mappa in SVG del codice in Javascript. Sempre usando Javascript e' possibile aggiornare queste mappe in tempo reale(ad esempio una mappa con dati metereologici).

Noi abbiamo gia' sviluppato una mappa del tracker da usare per il monitoraggio e vorremmo vedere se e' possibile mostrare i dati del tracker usando la stessa mappa codificata in SVG. Questo approccio ha il vantaggio di evitare la necessita' di usare uno speciale programma in Java per vedere la mappa. Il servizio Web invece di mandare i dati della geometria del tracker in formato XML li manda direttamente in formato SVG con incluso il programma Javascript che realizza l'interattivita'. I dati di altro tipo sono mandati nello stesso formato XML in ambedue i casi.

La mappa SVG

Esempio di mappa del tracker con i moduli sovrapposti e coi moduli separati.Alle normali possibilita' interattive delle immagini SVG (zoom e scorrimento dell'immagine(panning)) sono state aggiunte le seguenti operazioni tramite Javascript: Questa interfaccia in Javascript e' stata "hackerata" dal sito www.carto.net dove essa e' spiegata passo a passo per l'uso con mappe geografiche.
Esempio di evento,il segnale di 50 eventi integrato(numero di rechits per modulo)

Collegamento del browser al servizio Web che fornisce i dati

Una volta che il browser (o il client Java) ha ottenuto i dati della geometria del tracker, come fa a ottenere i dati relativi alle informazioni del tracker da rappresentare? Esso si costruisce l'URL corrispondente al dato richiesto e lo invia via Web ottenendo un file XML . Se siamo in un programma Java non c'e' alcun problema: ad esempio, usando il software Castor, e' possibile trasformare immediatamente il file XML in un contenitore di oggetti che possono essere manipolati da Java. Se invece siamo in un programma Javascript bisogna distinguere due casi, a seconda che il programma Javascript sia eseguito dal browser o dal plugin SVG di Adobe.(Fra poco , quando Mozilla/Firefox avranno il supporto nativo di SVG, non essendo richiesto un plugin , non ci sara' piu' questa complicazione). Nel caso del plugin (che bisognera' sempre usare per I.E. in quanto Microsoft ha preferito definire il proprio SVG detto XAML), si usa la funzione Javascript geturl che manda una richiesta su Web. Se il risultato e' un file XML , esso puo' essere trasformato in un albero DOM e processato dal codice Javascript. Nel caso di Javascript del browser viene usato l'oggetto Javascript XMLHttpRequest per collegarsi al servizio web che fornisce i dati e per estrarre questi dal documento XML. Questo oggetto e' ormai disponibile sui piu' importanti browsers (I.E,Mozilla,Opera,Safari) ed ha una serie di metodi che permettono di stabilire il contatto col server, ricevere i dati in maniera asincrona e quindi usarli estraendoli direttamente dall'albero del documento XML (non e' necessario cioe' fare un parsing del file ricevuto).

Risultati

La mappa completa del tracker in SVG e' contenuta in un file di testo di circa 3MB. Il test e' stato fatto su un PC con CPU Pentium IV sia sotto Linux che sotto Windows . Ci vogliono 20 secondi per avere la mappa pronta sullo schermo del proprio computer. In questi 20 secondi e' incluso anche il tempo per trasferire il file che pero' nel nostro caso era trascurabile. La maggior parte del tempo e' persa dal plugin di Adobe(abbiamo usato la versione 3.01) per interpretare i dati del file SVG e creare l'albero Dom dell'immagine che contiene circa 100,000 nodi. Le varie operazioni previste sull'immagine sono veloci. Anche la stampa funziona in maniera eccellente.

Purtroppo invece l'aggiornamento dell'immagine con Javascript e' troppo lento e quasi inusabile a meno che non si debbano aggiornare solo pochi nodi per volta. L'esecuzione di un ciclo che traversi tutti i nodi dell'albero aggiornandoli richiede un minimo di 7 minuti! Per questo motivo e' preferibile avere altri dati gia' pronti in un formato SVG sul servitore dei dati remoti e aggiornare l'immagine SVG caricando una nuova immagine che rimpiazza la precedente. Almeno per questo tipo di applicazione non e' realistico leggere ad esempio un nuovo evento in formato xml ed usarlo per aggiornare l'immagine.Questo tipo di approccio e' facile da implementare ma la velocita' di esecuzione del codice Javascript sui computer attuali non lo rende fattibile. Da questo punto di vista un client Java e' molto piu' efficiente in quanto riesce a processare la stessa quantita' di dati (un albero XML con circa 100,000 nodi) in circa 10 secondi. Questo non significa che gia' adesso non si possa usare SVG ma e' conveniente mandare un'immagine gia' pronta e limitare le operazioni locali a quelle operazioni che non richiedono grosse modifiche dell'immagine. Per esempio nel nostro caso si potrebbero aggiungere tutta una serie di operazioni quali:

In definitiva, sebbene queste limitazioni rendano in questo caso l'uso di SVG molto meno attraente, il seguente caso di uso dovrebbe essere fattibile senza problemi: un programma di monitoraggio locale di CMS salva ogni pochi secondi su un server Web un'immagine SVG con la mappa del segnale del tracker integrata. Un esperto in qualsiasi parte del mondo puo' subito (entro 20 second secondi) accedere a quest'immagine senza la necessita' di avere speciali programmi e fare un controllo che tutto e' ok e in caso di problemi sapere esattamente quali parti del detector non funzionano e richiedere informazioni ulteriori (istogrammi) solo per queste parti.

References