4. Architettura Della Infrastruttura
4.2. Architettura dell’Infrastruttura
4.2.4. Local Catalogue Service
Tutti i servizi sopra presentati utilizzano meta informazioni47 per poter operare sui dati offerti da uno o più servizi OGC. Tali informazioni, riportate nei documenti di capacità dei servizi, sono accessibili tramite il servizio CAT di OGC.
Dato che non è stato possibile né reperire un’interfaccia per interagire con i servizi OGC CAT, né implementarne una in tempi brevi, è stato realizzato un servizio di catalogo,
Local Catalogue Service (LCS). Tale servizio è pubblicamente accessibile ed in grado di
fornire semplici operazioni per memorizzare le meta informazioni provenienti dalle istanze dei servizi WFS e WMS.
A differenza dei servizi GO-WS, questo non necessita la presenza di un motore GIS in quanto interagisce direttamente con i servizi tramite il protocollo HTTP. L’unico elemento software necessario è un DBMS in grado di garantire sia la serializzabilità che l’affidabilità per prevenire inconsistenze all’interno della base di dati.
L’architettura del servizio LCS prevede (figura 4.17), oltre ad un DBMS:
un’interfaccia verso il catalogo per offrire dei metodi di manipolazione sulla base di dati, Core Catalogue Interface;
un web service che espone operazioni per interagire con il catalogo.
Per quanto riguarda il DBMS, Microsoft JET SQL è stato ritenuto valido, data l’esigua entità dei dati coinvolti. L’impiego di ADO.NET consente di usufruire di un insieme di classi, organizzate all’interno del namespace System.Data, necessarie per interagire con il
DBMS.
Figura 4.17
Architettura del servizio Local Catalogue Service.
47 Notazione: in questo contesto è stato appositamente utilizzato il termine “meta informazioni” per non
4.2.4.1. La Base di Dati
Il nucleo del catalogo è una base di dati in cui sono memorizzate le meta informazioni riportate all’interno dei documenti delle capacita delle istanze dei servizi OGC.
Il catalogo è stato strutturato per mantenere meta informazioni riguardanti:
l’istanza di servizio OGC: dove si trova, di quale tipo di servizio OGC si tratta, i termini chiave ed il nome assegnatogli (per i dettagli relativi a questi attributi, vedere la tabella 2.1 di capitolo 2.1.3.1);
gli strati informativi: per ogni istanza di servizio OGC sono riportare informazioni relative ai layer, quali: nome, tipo di geometria, termini chiave, descrizione, posizione dei metadati e posizione del dataset;
il sistema di riferimento e box di contenimento di uno strato: per ogni strato informativo sono riportati i sistemi di riferimento spaziali supportati dal servizio OGC.
Lo schema illustrato in figura 4.18, mostra come è stato modellato il catalogo (Meta
Information Repository, MIR). La relazione Tbl_SRSBox riporta descrive le coppie
<“sistema di riferimento spaziale”,“bounding box”> (<SRS,BBox>) in cui un servizio fornisce gli strati informativi.
Figura 4.18
Schema ad oggetti del Meta Information Repository; per il relativo schema entità-relazioni vedere appendice F.
Gli attributi di ogni relazione fanno riferimento alle meta informazioni del documento delle capacità di un WFS o WMS; tranne i seguenti:
Lid: identifica univocamente uno strato informativo;
Bid: identifica le tuple che modellano le coppie <SRS,BBox>;
LatLon: indica se la coppia <SRS,BBox> corrisponde alla meta informazione
LatLongBoundingBox.
4.2.4.2. OWS-ServiceCrawler
Per poter riportare le meta informazioni contenute nel documento delle capacità all’interno del catalogo, è stato progettato un insieme di classi che costituiscono la libreria (ed il namespace) OWSServiceCrawler, che consente di creare una corrispondenza con il
documento delle capacità di un istanza di servizio WFS e WMS.
All’interno della libreria, sono definite tre classi astratte che si occupano di modellare gli elementi del documento delle capacità comuni a tutti i servizi:
ServiceClass: contiene caratteristiche comuni ai servizi, come: URL HTTP,
versione, tipo di servizio;
ServiceInfosClass: riporta le meta informazioni legate al servizio;
LayerClass: contiene le meta informazioni relative ad un layer esposto dal
servizio.
Da queste classi base, ne sono state derivate altre specializzate per i servizi WFS e WMS. La creazione della corrispondenza avviene istanziando una classe derivata da
ServiceClass che ha il compito avviare il processo di estrazione delle meta
informazioni istanziando la classe derivata da ServiceInfosClass. Questa estrae le
meta informazioni relative al servizio ed infine crea tante istanze della classi derivate da
LayerClass, quanti sono i gli strati informativi esposti dai servizi.
Per i servizi WMS (le classi evidenziate di giallo in figura 4.19) le categorie sono state modellate con una classe supplementare WMS_LayerHierarchyClass che può contenere istanze delle classi WMS_LayerClass oppure ulteriori istanze di se stessa.
Per maggiori dettagli sulle classi del namespace OWSServiceCrawler, vedere
Figura 4.19
Modello ad oggetti della libreria OWSServiceCrawler. In azzurro sono state evidenziate le tre classi astratte, in verde le classi derivate per gestire la corrispondenza con i servizi WFS ed in giallo per i servizi WMS; in arancio sono indicate le classi di utilità.
4.2.4.3. Core Catalogue Interface
L’interfaccia con la base di dati è costituita da un’unica classe, CoreManager, che
espone i metodi necessari a memorizzare e gestire le meta informazioni riportate all’interno dei documenti delle capacità. Il framework .NET offre supporto alla manipolazione dei documenti XML attraverso il namespace System.Xml, mentre
Il flusso di dati fra i due tipi di documenti delle capacità ed il MIR, è realizzato attraverso le classi del namespace OWSServiceCrawler che veicolano le meta informazioni dal documento delle capacità, verso il catalogo.
}
Figura 4.20
Architettura della classe CoreManager; è stato evidenziato il ruolo delle classi
appartenenti al namespace OWSServiceCrawlerrispetto al flusso dati XML.
I metodi che la classe CoreManager espone, sono raggruppati in due insiemi:
manipolazione del catalogo: sono i metodi che permettono di aggiungere, eliminare e sincronizzare le informazioni contenute nel catalogo in base alle meta informazioni del documento delle capacità:
AddService: memorizza le meta informazioni, ottenute istanziando una
classe derivata da ServiceClass, all’interno del MIR;
UpdateService: sincronizza le meta informazioni relative ad un’istanza di
servizio, memorizzate all’interno del catalogo, utilizzando la rappresentazione tramite ServiceClass della stessa istanza di servizio
disponibile in rete;
DeleteService: elimina le meta informazioni relative ad un’istanza di
servizio tramite:
la URL dell’istanza;
attraverso la chiave che lo identifica univocamente all’interno del catalogo.
recupero meta informazioni: metodi per recuperare meta informazioni memorizzate nelle relazioni del MIR:
GetWFSServiceFromCatalog: permette di rappresentare un servizio
memorizzato all’interno del catalogo attraverso la classe
GetWMSServiceFromCatalog: permette di rappresentare un servizio
memorizzato all’interno del catalogo attraverso la classe
WMS_ServiceClass;
ExecuteSFW: esegue un’interrogazione, espressa attraverso il costrutto
SQL “Select-From-Where”, sul catalogo. Restituisce un dataset implementato attraverso la classe DataSet del namespace System.Data di
.NET;
GetSingleValue: come il precedente metodo, tranne che è ottimizzato per
restituire un solo valore.
4.2.4.4. Il Servizio Web
Il servizio di catalogo utilizza l’interfaccia CoreCatalogueInterface per
implementare le operazioni di manipolazione remota del catalogo MIR.
Come precedentemente esposto nel capitolo 2, in generale un servizio è identificato attraverso la sua URL ed il tipo di servizio OGC. L’invocazione di un metodo del servizio “Local Catalogue Service” (che riguarda un inserimento od una sincronizzazione) scaturisce una richiesta HTTP-GET all’istanza del servizio OGC, per ottenere il rispettivo documento delle capacità. Se la richiesta si conclude con esito positivo, viene istanziata una delle classi derivate da ServiceClass (del namespace OWSServiceCrawler).
L’oggetto così creato, è fornito alla classe CoreManager invocando il metodo necessario ad implementare l’operazione del servizio. In figura 4.21 è illustrata l’architettura del servizio.
Figura 4.21
I metodi web esposti sono i seguenti:
Insert: inserisce le meta informazioni di un’istanza di servizio, data la sua
URL e il tipo di servizio;
DeleteByURL: elimina dal catalogo le meta informazioni relative all’istanza di
servizio identificata tramite URL e tipo di servizio;
DeleteByID: come il metodo precedente, solo che l’istanza di servizio è
identificata all’interno del catalogo in base alla sua chiave;
UpdateByURL: sincronizza le informazioni di un’istanza di servizio, contenute
all’interno del catalogo, tramite la URL e la tipologia del servizio;
UpdateByID: la sincronizzazione avviene identificando l’istanza di servizio
attraverso la sua chiave primaria relativa al catalogo MIR;
GetServiceList: restituisce una lista di triple <nome_servizio,
identificatore_servizio, tipo_istanza_servizio> ;
GetWFSServiceList: come il precedente metodo, tranne che la lista contiene
triple relative ad istanze di servizio WFS;
GetWMSServiceList: la lista delle triple restituita è relativa ad istanze di
servizio WMS;
GetDataFromCatalog: questo metodo ha la stessa semantica di ExecuteSFW;
Get_a_Value: come GetOneValue, restituisce un valore in base ad
un’interrogazione espressa in SQL.
Capitolo